miércoles, julio 27, 2011

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!

14 comentarios:

fossie dijo...
Este comentario ha sido eliminado por el autor.
fossie dijo...

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

akil3s dijo...

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 :'(

tocahuevos dijo...

fossie, si alguna vez metes una inyección, hazla bien porfavor.

fossie dijo...

tocahuevos, las inyecciones no me las meto yo, se las meto a las webs ;)

il Grande Meaplayas dijo...

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 Raúl PÉREZ dijo...

Chema, no entiendo lo del BSQLi, hasta donde sabia - de leerte de hace añares :) , El BSQLi es a ciegas, y la particularidad es que al inyectarlo, *no hay cambios* en la respuesta del servidor.

En el post dices "si los resultados son distintos".

Quizas falte aclarar que es si hay diferencias de timming, o que de esa manera confirmamos que es vulnerable a cualquier tipo de injection, no especificamente la SQLi a ciegas.

Saludos desde Argentina (y a proposito, muchas gracias por el video para 1hackparaloschicos!)

Mario Pérez

Maligno dijo...

@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...

;)

Marcos Vives dijo...

La mejor forma de comprobar una BSQLi es esta:

Si tenemos:
/index.php?id=5

Podemos comprobarlo asi:
- Este es verdadero. La pagina se debe ver igual:
/index.php?id=5 and 1<2
- Este es falso. Deberia desaparecer contenido, dar error...:
/index.php?id=5 and 1<2

Si se cumple, tienes probablemente una vulnerabilidad ante ti

fossie dijo...

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.

Maligno dijo...

@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!

Marcos Vives dijo...

Gasto < y > porque recuerdo haber tenido problemas con filtros anti-inyecciones chapuceros (de esos que sólo filtran ciertos caracteres, y el = era uno de ellos), y desde entonces sigo con esos

De todas formas sólo es un ejemplo, hay infinitas formas de poder comprobarlo :)

Mario Raúl PÉREZ dijo...

@maligno: Gracias por desasnarme, Yo creia que lo que lo hacia "a ciegas" era que en la respuesta se veia lo mismo. Lo de sacar toda una base de datos de a bits (mediante comparaciones binarias) tambien entonces es a ciegas entonces, y adivinar las columnas de las tablas tambien, resulta que siempre estube haciendo pruebas BSQLi y yo creia que eran simples SQLi nomas ;) gracias por la corrección, ahora me queda todo mas claro.

@fossie Las criticas son bien recibidas :)

No es por el profesionalismo de la palabra timming, es mas que nada la costumbre de leer -medio a lo indio- documentacion en ingles.

Quise decir, como bien apuntastes, diferencia de tiempos de respuesta.

Incluso, en ingles estaria mal escrito timming, es timing, y su significado es "el tiempo cuando pasa algo o la separación de eventos en el tiempo."

Ahora bien, de las palabras en español, yo seguire insistiendo junto con muchos para que la RAE apruebe "SECURIZAR", solo por que me suena bonita jaja, aunque podriamos decir proteger, fortificar, asegurar... tiene mas onda tener un termino propio en informatica :P

fossie dijo...

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

Entradas populares