Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
6 easy tests para evaluar la seguridad de tu web (o de tu empresa)
Normalmente, cuando hacemos un test de intrusión en Informática 64, antes de empezar y estimar más o menos el número de jornadas que vamos a tardar en realizar el análisis, miramos cosas como las tecnologías utilizadas en servidor, el tipo de información que maneja, el tamaño de la misma, y lo más importante, el nivel de concienciación en seguridad en el desarrollo.
Para mirar eso, comprobamos algunos trucos muy sencillos que os he ido contando a lo largo de mucho tiempo, pero os voy a resumir algunas pruebas que podéis realizar con vuestra web (o la de vuestra empresa) para saber si necesita un test de intrusión o no:
1. El test de la Viagra (o el software barato)
Este seguro que ya lo conocéis, es tan sencillo como buscar en Google en el site de vuestra web por “cheap viagra” o “cheap software” para ver si vuestra web está jodida por la viagra como la de Apple o por el software piata como la de la Nasa. Si esto aparece, es que hay un buen bug en el sitio web que alguien ha aprovechado.
Figura 1: Viagra en la web de Apple
2. Ficheros con usuarios en los metadatos
Podéis hacer un análisis de los metadatos de todos los documentos podéis utilizar FOCA, pero si queréis hacer una prueba rápida, basta con que miréis en Google los famosos ficheros PDF que tienen en el título la ruta al perfil del usuario, como hicimos con los espías. Esto implicaría que al ENS no le hacen mucho caso - y que no nos han comprado aún Metashield Protector }:) -
Figura 2: Usuarios del ejército americano
Nota: Si quieres mirar metadatos en ficheros en concreto, los Excel suelen ser los que más metadatos suelen contener.
3. La prueba de robots.txt
El domingo pasado os publiqué un ejemplo de lo que NO se debe hacer con un robots.txt, pero lo ideal es buscar los directorios que aparecen en ellos a ver si tienen alguna “sopresa” como un panel de administración, o una aplicación “escondida”.
Figura 3: Interesante robots.txt de Oracle.com
4. Listado de directorios abiertos
A veces los árboles no nos dejan ver el bosque, y lo más fácil es pedir el listado de directorios y obtener todos los ficheros allí almacenados. Para ello, basta con que busques las carpetas en las URL de la web y compruebes si te muestra la lista de ficheros. Esto no debería pasar nunca.
Figura 4: Listado de directorios abierto en EAJ-PNV.com
5. SQL Injection de libro en aplicaciones ASP o CFM con la comilla
El lenguaje ASP fue lanzado en 1996 mientras que el SQL Injection se descubrió en 1998, por lo que los ficheros ASP no traen una protección extra para los ataques de comilla. Para ello, busca en tu sitio ficheros asp con parámetros y añade al valor del parámetro algo como ‘asdf y mira a ver si canta algún error de aplicación o de ODBC. Si esto pasa, la web es vulnerable. Esta prueba puede realizarse de la misma marea con ficheros ColdFusion que también nacieron antes que el SQL Injection.
Figura 5: Búsqueda de aplicaciones ASP con parámetros
Figura 6: Ejemplo típico de error ODBC
6. Blind SQL Injection de Libro en ficheros PHP
En PHP añadieron las magic quotes, que hacen que se escapen las comillas, evitando los ataques con comillas. Sin embargo, nada protegen contra los ataques Blind SQL Injection en parámetros numéricos. Para hacer una prueba sencilla, busca en tu sitio ficheros PHP con parámetros numéricos y haz dos peticiones, una inyectando and 1=1 y otra inyectando and 1=2. Si los resultados son distintos, ese sitio es más que probable vulnerable a BSQLi. Una vez descubierto el Blind SQL Injection, ya le puedes dar caña a las tools.
Figura 7: Búsqueda de PHPs con parámetros numéricos. Hay que inyectar and 1=1 y and 1=2
Todas estas pruebas no son definitivas, y aunque la web de tu empresa las pase todas debería seguir haciéndose un test de intrusión de forma periódica pero, por el contrario, si alguna de ellas da resultado positivo, indica un fallo de seguridad y lo que es más gordo, una “preocupación” por la seguridad de la web “relajada”.
Saludos Malignos!
Para mirar eso, comprobamos algunos trucos muy sencillos que os he ido contando a lo largo de mucho tiempo, pero os voy a resumir algunas pruebas que podéis realizar con vuestra web (o la de vuestra empresa) para saber si necesita un test de intrusión o no:
1. El test de la Viagra (o el software barato)
Este seguro que ya lo conocéis, es tan sencillo como buscar en Google en el site de vuestra web por “cheap viagra” o “cheap software” para ver si vuestra web está jodida por la viagra como la de Apple o por el software piata como la de la Nasa. Si esto aparece, es que hay un buen bug en el sitio web que alguien ha aprovechado.
Figura 1: Viagra en la web de Apple
2. Ficheros con usuarios en los metadatos
Podéis hacer un análisis de los metadatos de todos los documentos podéis utilizar FOCA, pero si queréis hacer una prueba rápida, basta con que miréis en Google los famosos ficheros PDF que tienen en el título la ruta al perfil del usuario, como hicimos con los espías. Esto implicaría que al ENS no le hacen mucho caso - y que no nos han comprado aún Metashield Protector }:) -
Figura 2: Usuarios del ejército americano
Nota: Si quieres mirar metadatos en ficheros en concreto, los Excel suelen ser los que más metadatos suelen contener.
3. La prueba de robots.txt
El domingo pasado os publiqué un ejemplo de lo que NO se debe hacer con un robots.txt, pero lo ideal es buscar los directorios que aparecen en ellos a ver si tienen alguna “sopresa” como un panel de administración, o una aplicación “escondida”.
Figura 3: Interesante robots.txt de Oracle.com
4. Listado de directorios abiertos
A veces los árboles no nos dejan ver el bosque, y lo más fácil es pedir el listado de directorios y obtener todos los ficheros allí almacenados. Para ello, basta con que busques las carpetas en las URL de la web y compruebes si te muestra la lista de ficheros. Esto no debería pasar nunca.
Figura 4: Listado de directorios abierto en EAJ-PNV.com
5. SQL Injection de libro en aplicaciones ASP o CFM con la comilla
El lenguaje ASP fue lanzado en 1996 mientras que el SQL Injection se descubrió en 1998, por lo que los ficheros ASP no traen una protección extra para los ataques de comilla. Para ello, busca en tu sitio ficheros asp con parámetros y añade al valor del parámetro algo como ‘asdf y mira a ver si canta algún error de aplicación o de ODBC. Si esto pasa, la web es vulnerable. Esta prueba puede realizarse de la misma marea con ficheros ColdFusion que también nacieron antes que el SQL Injection.
Figura 5: Búsqueda de aplicaciones ASP con parámetros
Figura 6: Ejemplo típico de error ODBC
6. Blind SQL Injection de Libro en ficheros PHP
En PHP añadieron las magic quotes, que hacen que se escapen las comillas, evitando los ataques con comillas. Sin embargo, nada protegen contra los ataques Blind SQL Injection en parámetros numéricos. Para hacer una prueba sencilla, busca en tu sitio ficheros PHP con parámetros numéricos y haz dos peticiones, una inyectando and 1=1 y otra inyectando and 1=2. Si los resultados son distintos, ese sitio es más que probable vulnerable a BSQLi. Una vez descubierto el Blind SQL Injection, ya le puedes dar caña a las tools.
Figura 7: Búsqueda de PHPs con parámetros numéricos. Hay que inyectar and 1=1 y and 1=2
Todas estas pruebas no son definitivas, y aunque la web de tu empresa las pase todas debería seguir haciéndose un test de intrusión de forma periódica pero, por el contrario, si alguna de ellas da resultado positivo, indica un fallo de seguridad y lo que es más gordo, una “preocupación” por la seguridad de la web “relajada”.
Saludos Malignos!
10 comentarios:
Muy buena recopilación de pruebas. La verdad que son sencillas pero se descubren muchas cosas.
Yo siempre que veo parámetros en la URL tengo la tentación de poner una comilla o intentar el "or 1=1" jiji
NOTA: Borre el anterior porque se me había olvidado marchar el check de los emails de seguimiento :D
joder, q perdido ando en todo esto, así cuando m monto un joomla al minuto tengo 30 correos de robots q se registran, q inútil dios :'(
fossie, si alguna vez metes una inyección, hazla bien porfavor.
tocahuevos, las inyecciones no me las meto yo, se las meto a las webs ;)
akil3s me caes bien, normalmente la gente que comenta en este blog lo hace diciendo cualquier chorrada para que se vea que ellos ya controlan aquello que ha puesto el autor, que lo han leído pero no lo necesitaban.
Está bien ver algo de humildad de vez en cuando :)
Saludos!
@Mario, en un ataque BSQLi puedes buscar cualquier variación (hash de la página, códio de servidor, árbol html o tiempo) Hasta Cameron Hotchikies propueso el de suma linear de valores ASCII de las páginas de resultados. Lo que hace que sea a ciegas es que nunca ves los datos de la base de datos que extraes, por eso hay que inferirlos...
;)
Mario, yo tengo una duda, ¿porque dices "diferencias de timming" pudiendo decir "diferencias de tiempos"?
Parece más profesional decir "timming" pero somos muchos que no nos enteramos casi de nada cuando empezais a utilizar términos sajones para referiros a cosas que no son tan complejas.
Perdona la crítica Mario, te ha tocado a ti pero no eres el único. Se que estáis acostumbrados a eso.
@Marcos, usar < y > puede generar problemas en los filtros AntiXSS. De hecho hay tantas posibilidades que yo cree un artículo sobre como hacerlo sin operadores lógicos
Arithmetic Blind SQL Injection
Saludos!
Gracias Mario por tomártelo bien. Es que muchos de nosotros, pese a que nos gusta la informática no tenemos tantos conocimientos de ingles y/o no hemos leído tantas publicaciones informáticas en ingles y hay veces que no sabemos de que se habla precisamente por esos términos que si se escribieran en castellano nos seria mas fácil de entender.
En mi propio curro hay veces que no se de que me hablan porque hay "jefes" que aún no teniendo ni idea te sueltan una retaila de terminología que te quedas a cuadros pero cuando consigues "traducir" lo que han dicho al final hay veces que son dos chorradas pero ellos se llenan la boca con esos terminos y quedan "bien".
Estoy contigo, también me gusta lo de SECURIZAR
Publicar un comentario