OWASP-IG-002: Search Engine Discovery / Reconnainse

Dentro del proceso de mapeo de nuestra aplicación Web tenemos la suerte de disponer del mejor de los aliados: Google. Este punto de control de OWASP tratará de aprovechar toda la información que el buscador de buscadores, y más concretamente sus arañas, nos proporciona. Este puede parecer a priori un punto trivial, al fin y al cabo todo el mundo sabemos hacer búsquedas, ¿verdad?

No exactamente, el dominio de las búsquedas avanzadas y lo que ha venido a llamarse Google Hacking es todo un arte sobre el que han caído ríos de tinta (literalmente) y donde los desarrolladores no han tardado mucho en automatizar las tareas teniendo como base la Google Hacking Database, ¿Cuáles son estas herramientas?, ¿Qué búsquedas tengo que completar para cubrir este control?, ¿Qué vulnerabilidades puedo descubrir? Como dijo Johny el destripador (nótese el humor retorcido del autor), vayamos por partes:

Google Dorks

¿Qué tienen en común todas estas búsquedas?

intitle:"Apache HTTP Server" intitle:"documentation"

intitle:"Welcome to IIS 4.0"

intitle:index.of passwd passwd.bak

filetype:xls username password email

intitle:"toshiba network camera - User Login"

Exacto, muestran mensajes predefinidos, archivos de instalación, errores bien conocidos, en definitiva: Buscan activos (pongámosle esa palabra) que no deberían ser públicos en Internet, a no ser que sea una Honeynet o un honeypot claro :) Por suerte hay quien se ha entretenido en recopilar toda esta información y crear una base de datos de Google Dorks, es la conocida como GHDB de Johny alias “ihackstuff.com”, de esta base de datos es de la que beben las aplicaciones que os voy a presentar hoy, que como veréis son muchas.

Google Hacking Tools

Athena, Wikto, Goolag, SiteDigger, DirBuster, Pipper, etc. Hay muchas herramientas que nos pueden ayudar en esta ardua tarea que hace unos años teníamos que hacer manualmente, cada una tiene sus pros y sus contras, en mi opinión se complementan bastante bien, echemos un vistazo a algunas de ellas:

DirBuster

Esta herramienta forma también parte del proyecto OWASP y es especialmente buena para el descubrimiento de directorios. Por ejemplo si sabéis que tenéis delante un servidor apache, o una aplicación Joomla bien conocida quizás tengáis una lista de directorios predefinidos. Solo tenéis que cargarla para que DirBuster busque si son accesibles por vosotros. Si no disponéis de esa información siempre podéis cargar de las listas que el incluye, aunque será un ataque por fuerza bruta prácticamente con más de 50000 peticiones. Demasiado escandaloso:

Wikto

Versión para Windows del popular Nikto, esta herramienta al igual que WebScarab y otras que ya hemos visto no solo hace Google Hacking, pero el que hace es muy bueno. Válida como Spider (por lo que nos valdrá para el control anterior OWASP-IG-001), incluye Data Mining y por supuesto utiliza la GHDB:

En el pantallazo se pueden ver algunas consultas a MySQL de donde se pueden comenzar a extraer cositas. Un detalle, la última versión no utiliza la API de Google, ahora se tiene que instalar SPUD: SensePost Unified Data API, que no es más que un gestor de las APIs de Google, Live Search (ahora Bing, supongo que lo actualizarán en la siguiente versión) y Yahoo, eso sí no es obligatorio tener ninguna licencia para que funcione, aunque si tenemos las tres los resultados serán algo más completos.

Goolag

Los chicos del culto a la vaca muerta (¿?) presentaron esta herramienta cuya principal novedad es que tiene su versión web en: http://www.goolag.org/ y no requiere de la API de Google (lo que viola las condiciones de Google), eso sí, el buscador puede banear tu IP si haces “muchas” consultas ya que es capaz de detectar actividad maliciosa:

Si os ha gustado os recomiendo el cliente pesado, cómodo y súper intuitivo.

Como habéis podido comprobar el abanico de herramientas es considerable, la información que hay en Internet, también. Os dejo un último link de la Universidad de Oviedo que explica las técnicas de Google Hacking paso a paso.

De forma paradójica en este post hemos visto que no son necesarios grandes conocimientos de técnicas de hacking para descubrir las primeras e importantes vulnerabilidades, y todo ello sólo accediendo a recursos públicos.

Salu2

OWASP-IG-001: Spiders, Robots and Crawlers

Comenzamos con nuestra revisión de OWASP, hoy toca Information Ghatering, Spiders, Robots y Crawlers. ¿Por qué este comienzo? Bien, es bastante sencillo. Antes de atacar cualquier sistema debemos hacernos la pregunta, ¿qué sistema es?, ¿qué servicios ofrece?, yo siempre digo que si somos capaces de resolver estas dos preguntas con garantía tendremos la mitad del trabajo hecho, por ello las empresas colocan sus máquinas detrás de firewalls, en DMZs, segmentan redes, crean ACLs, así solo permiten ver lo que debería de verse por quien debería verlo.

En el OWASP-IG-001 recopilaremos información de la aplicación Web que queremos atacar, nos haremos un mapa de la misma y sabremos que estructura tiene. Todo esto se puede hacer a través de Web Spiders o Crawlers o con la ayuda del archivo de robots que muchos sitios Web tienen, y que no es más que un archivo de configuración que indica a los robots lo que “en teoría” no tienen que indexar, también habla con los User Agent para indicar si pueden o no mostrar la Web. Por ejemplo, el archivo de robots.txt de www.ieja.net (una página que no tiene nada que ver con la legendaria expresión manchega) nos da estas carpetas:

User-agent: * 

Disallow: /administrator/

Disallow: /cache/

Disallow: /components/

Disallow: /editor/

Disallow: /help/

Disallow: /images/

Disallow: /includes/

Disallow: /language/

Disallow: /mambots/

Disallow: /media/

Disallow: /modules/

Disallow: /templates/

Disallow: /installation/

¿Protege esto en el acceso a carpetas internas? No, no es una solución de control de acceso ni provee autenticación ni autorización, tal como indican en www.robotstxt.org se podría crear una carpeta ieja.org/norobots/ y dentro de ella poner todas las sub-carpetas y archivos que no queremos sean visitados o indexados, pero ni siquiera eso sería una solución valida, los robots.txt no están para proveer control de acceso por lo que habrá que configurar el servidor http correctamente protegiendo el acceso a carpetas y archivos y añadiendo una solución de control de acceso.

Para realizar un mapa de la aplicación que queremos asaltar existen gran variedad de herramientas, algunas de ellas ya las hemos visto, como es el caso del Paros Proxy que, configurado como Proxy puede interceptar la URL a la que accedemos y desplegar su araña en busca de carpetas y subcarpetas:

Tanto esta herramienta como el WebScarab de OWASP tienen muchas funciones adicionales pero tiempo al tiempo, hoy no es el día ;-) Aunque creo que WebScarab no os la he presentado. En el proyecto OWASP no solo ofrecen una metodología de Test de Intrusión en Aplicaciones Web, también ofrecen herramientas de ayuda para su metodología. WebScarab hace una cosa que Paros no hace, también recopila enlaces a Webs externas, en esta en particular hay muchas:

La forma de hacerlo es la misma, configuramos el listener para que capture el tráfico y desde “Spider”, comenzamos a recopilar. Cuando tengamos los resultados es probable que sean distintos del anterior Spider, así que habrá que cruzarlos. Pero no solo de herramientas pre-fabricadas vive el hombre, si recordáis hace unos meses me fabriqué un Spider con unas pocas líneas en Perl para buscar todas las fotos que hicieron en una atracción de Terra Mítica en un día, muy similar al que hizo Lobosoft en C#. Por otro lado en PenTester.es hicieron una mucho más elaborada que mostraba todas las URL de un particular dominio objetivo, se llamaba TargetSearch y nos será muy util para siguientes entradas (estrechamente relacionadas con esta).

¿Qué cuales son las vulnerabilidades que exlotamos haciendo esto? Pues a priori y salvo excepciones, ninguna. Claro está, a veces hay administradores despistados que dejan la carpeta de administración visible a todo el mundo, o aplicaciones mal diseñadas con lapsus en su desarrollo, como fue el caso de los router Zyxel que no protegían la URL:

http://[Ip Router]/rpFWUpload.html

y permitían resetear el router fácilmente. Esta primera fase no suele reportar vulnerabilidades, pero si lo hace nos podemos dar una idea del ambiente “descuidado” que tenemos delante.

Buen fin de semana ;-)

From OSSTMM to OWASP

Fue a finales de 2006, comienzos de 2007. Estaba enfrascado en el proyecto final de carrera "Auditoria de Sistemas de la Información", donde tras varios meses pegándome con la extensa OSSTMM y otras tantas semanas de prácticas en una importante empresa de seguridad pude dar a luz el que sería uno de mis hijos pródigos, un proyecto de alrededor de 300 paginas donde se explicaba la metodología OSSTMM con un ejemplo "real" de auditoria basada en esta metodología sobre un cliente.

Desde entonces no he podido volver a dedicarme al Pen-Testing, sin salirme del mundo de la Seguridad he tenido la oportunidad de hacer otras muchas cosas, sin embargo el conocimiento tiende a diluirse como un azucarillo en el agua de la memoria si no es refrescado continuamente así que me he dicho, ¡volvamos a hacer Pen-Test! Eso sí, con un "pero", esta vez vamos a ser más prácticos y en vez de amasar un par de decenas de entradas hablando de OSSTMM y sus famosos 7 dominios de forma teórica y enriquecedora pero a fin de cuentas, algo aburrida, vamos a repasar la OWASP Testing Guide 3.0 y sus 9 sub-categorías y 66 controles de seguridad de forma práctica, con ejemplos reales (que en algún caso tendré que desarrollar por 1ª vez, por lo que os animo a corregirme o dar ideas si veis desvaríos varios). Antes de todo eso vamos a recordar cómo es OSSTMM, por qué es la metodología de auditoría más completa y por qué, a fin de cuentas, lo que se usa es OWASP (al menos desde mi experiencia).

OSSTMM, la metodología que lo abarca todo

Open Source Security Testing Methodology Manual (OSSTMM) es un manual de pen testing desarrollado por el ISECOM cuya primera versión salió allá por el año 2001. Este cuaderno de auditoría gratuito y bajo licencia Creative Commons abarca todos los aspectos que una auditoría de seguridad debe contemplar si quiere ser lo más completa posible. Esto queda perfectamente reflejado en lo que a mí me gusta llamar el “molino de Don Quijote”:

La imagen del molino me encanta por que muestra de forma transversal y extremadamente simple como todo está relacionado en nuestro negocio, en nuestros sistemas de información, procesos, etc. Y sobretodo en el centro de todo, la seguridad física (disciplina por la que siento debilidad). OSSTMM muestra el camino para chequear todas las acciones que nos aseguren el cumplimiento regulatorio, el cumplimiento legal y el cumplimiento con las políticas corporativas, todo ello sin dejar de lado otros aspectos como el hacking wireless o la seguridad en las comunicaciones. La metodología está dividida en 6 módulos que alcanzan diferentes objetivos en la auditoría:

1- Seguridad de la Información (presencia en Internet de cualquier tipo de información de una entidad).

2- Seguridad en los procesos (ingeniería social, “suggestion test”)

3- Seguridad en Tecnologías de Internet (IDS, firewall, router testing, DOS, passwork cracking, etc.)

4- Seguridad de las comunicaciones (Modem, FAX, PBX, etc.)

5- Seguridad Wireless (TEMPEST, hacking 802.11, bluetooth, infrarrojos, etc.)

6- Seguridad Física (perímetro de seguridad, alarmas de seguridad, test de control de accesos, estudio del entorno, etc.).

Hay ciertos módulos que hay que pensarse muy bien si se van a ofrecer, por ejemplo todo lo relacionado con Ingeniería Social puede provocar conflictos de los que es necesario estar prevenido legalmente, los ataques DOS se dan por hecho ¿merece la pena hacerlos?, quizás tampoco sea necesario revisar el entorno geo-político de nuestro cliente, a no ser claro que se encuentre en el antiguo cauce de un río, exista inestabilidad local o una alta tasa de delincuencia en la zona (yo no abriría una oficina en ciertos barrios de practicamente cualquier ciudad).

OWASP, hacking ético puro y duro

Por otro lado tenemos el Open Web Application Security Project, OWASP se centra exclusivamente en tests de intrusión para aplicaciones web, proporcionando un exhaustivo catálogo de 66 controles de seguridad a revisar en toda aplicación web. Podría coincidir con los puntos 1 y 3 de OSSTMM, rozando algún que otro punto pero sin tanto detalle. Esto es lo que suele contratar cuando se solicita un servicio de pen-testing, hacking ético o similares. OWASP es una metodología muy práctica que desde el primer punto va al grano, AJAX Testing, WSDL, Buffer Overflows, Stack Overflow, LDAP Injection, SQL Injection, CSS, escalado de privilegios, etc. Además te explica que hace ese ataque, te ofrece indicaciones sobre herramientas y técnicas a emplear, artículos que conviene leer, etc. Esto hace a OWASP una metodología válida tanto para principiantes como para usuarios avanzados, se divide en los siguientes dominios:

1- Recolección de información.

2- Test de Gestión de la Configuración.

3- Test de Autenticación

4- Test de Gestión de Sesiones

5- Test de Autorización

6- Test de validación de datos de entrada.

7- DOS testing.

8- Test de Web Services.

9- Test AJAX.

Finalmente deja un capítulo con indicaciones sobre como redactar los informes, valorar el riesgo de forma correcta (aparece la vieja fórmula de riesgo = probabilidad * impacto).

En próximas entradas y como proyecto a largo plazo iremos revisando cada uno de los 66 controles de seguridad y veremos ejemplos prácticos de ataques.

Salu2

Database Hardening

Haz 100 flexiones más, 200 abdominales y da 15 vueltas al campo de fútbol.

Respuesta: Ufff, si que es difícil endurecer los servicios.

Todos sabemos que donde nosotros vemos ladrillos, medidas de seguridad, obstáculos a saltar, etc. Los chicos malos ven grietas, agujeros y facilidades, después de casi un año leyendo estas líneas creo que no os sorprendo si digo que no hay ninguna medida de seguridad o herramienta que sea la panacea, así que la única solución es utilizar varias de ellas que trabajen codo con codo con un objetivo común. La estrategia utilizada para que todo esto funcione como un engranaje se llama “defensa en profundidad”, y ya la utilizaban los militares en la 2ª Guerra Mundial y posiblemente, mucho antes.

¿Cuál es la profundidad aquí? Pues hay muchas y depende de cómo se mire, pero nosotros lo vamos a llamar arquitectura multicapa (frontend – middleware – backend). Si ponemos un nuevo servicio en producción, es lógico y normal que hagamos “hardening” del mismo, eso se suele traducir en bastionar el equipo, eliminar usuarios y contraseñas por defecto, deshabilitar servicios innecesarios, configurar control de acceso, etc. etc. Todo esto está bien pero, ¿qué pasa con las otras capas? Estamos dando por sentado que nadie pasará la frontera de Bélgica y holanda, pero esto ya les pasó a los franceses y ya sabéis como acabó .

Hoy vamos a hacer hardening del backend y vamos a ver cómo nunca tenemos que perder de vista los datos, el verdadero foco de la cuestión. Redactar todas las cositas que hay que mirar en un backend puede ser un checklist bastante extenso que seguramente no aporte mucho, casi todos los sistemas tienen sus checklist publicados, ya sea vía proveedor, vía NIST, etc. Lo que vamos a hacer es concentrarnos en tres cosas:

-   Detectar fallos de configuración (cuentas por defecto, servicios innecesarios, etc.)

-   Detectar vulnerabilidades software (no hay una política de “critical path update”)

-   Detectar mal uso (cuenta de administrador compartida por varios usuarios, consultas al backend con excesivos privilegios).

Existen herramientas para automatizar estos análisis especializadas en bases de datos como son AppDetective o NGSSQuirrel, la diferencia de los escáneres tradicionales con estos radica en la especialización, si bien un Nessus te detectará vulnerabilidades de todo tipo en dispositivos de red, servidores, Workstation, etc. nunca podrá realizar exámenes tan exhaustivos como por ejemplo Nikto hace con servidores web o AppDetective con una base de datos. Pero no solo de escáneres vive el Consultor, aunque con ellos y nuestro conocimiento (valor añadido) podremos comenzar a detectar fallos y recomendar medidas de hardening.

Medidas adicionales que nos ayudarán a mantener todo securizado (la seguridad es un proceso, recordemos) será habilitar un detector de cambios en la configuración, para ello tenemos herramientas como Intrust de Quest Software (que ya nos contó Carles Matin) o algunas más sencillas como habilitar las opciones de auditoria de SQL Server (si es esa nuestra BBDD).

Finalmente tenemos los datos, el quiz de la cuestión, toda la estrategia “defense in depth” se basa en este tesoro que puede ser expuesto a pesar de todo lo dicho hasta ahora. Una puerta trasera, una copia no autorizada, una migración de backend, unas pruebas desde otros entornos como certificación, desarrollo, etc. y ya tenemos nuestra temida fuga de datos. La principal medida en estos casos pasa por hacer lo que en el CISSP llamaban “Data Sanization” y que se traduce en preparar esos datos sensibles para que no pierdan su estructura (claves foráneas, atributos, tablas relacionales, etc.) y sin embargo no se puedan entender o pierdan su significado, es decir, ofuscar los datos. Para ello me he guardado en último lugar una herramienta que descubrí hace unos días, se llama Data Masker y tiene una funcionalidad interesante. Permite conectarse a las bases de datos, obtener su estructura, crear reglas de ofuscado, ejecutarlas, etc:

DataMasker: Autenticación en las conexiones.

DataMasker: Tablas de ejemplo para jugar.

Y esto es todo por hoy, recordad, proteger el frontend está muy bien pero...¡el foco siempre en los datos!

Salu2

Pen Testing - Advance

¿Y qué dicen las metodologías de estos “pent testing basics”? Pues que quizás sea eso lo que se haga (en cierta forma) en la mayoría de las empresas. Pero que ni mucho menos es lo que se debería de hacer, existen multitud de cosas que un test de intrusión debe comprobar y estas no solo afectan a sistemas en producción. Ahí están la OSSTMM (V3) y OWASP (V3) con sus cientos de folios indicando metodologías de trabajo en los Pen-Test, y es que de la teoría a la práctica hay un trecho bastante grande que creo que esta imagen simboliza muy bien:

Y es que no es lo mismo saber que X aplicaciones tienen tantas vulnerabilidades y que el firewall de entrada a la DMZ de tu cliente tiene abiertos los puertos http / https, smtp, dns, 53748 y alguno del emule que saber todo eso y que hay dos directores generales que están buscando trabajo en Xing (eso es un riesgo también, ¿no?), que la puerta de entrada a las oficinas tiene un candadito que se abre con un imperdible y que el que es el producto estrella de su compañía (ultra patentado y ultra protegido) está documentado y disponible en una carpeta compartida del director general. De ahí que por ejemplo OSSTMM tenga su “molinico de la mancha” para determinar los dominios de un Pen – Test completito:

Pero esto no es todo, nuestra compañera OWASP establece directrices “pen test” en el ciclo de vida del desarrollo (lo que conocemos ahora como ciclo de desarrollo seguro):

Phase 1: BEFORE DEVELOPMENT BEGINS.

PHASE 1A: REVIEW POLICIES AND STANDARDS

PHASE 1B: DEVELOP MEASUREMENT AND METRICS CRITERIA

Phase 2: DURING DEFINITION AND DESINGS

PHASE 2A: REVIEW SECUTIRY REQUIREMENTS

PHASE 2B: REVIEW DESIGN AND ARCHITECTURE

PHASE 2C: CREATE AND REVIEW UML MODELS

PHASE 2D: CREATE AND REVIEW THREAT MODELS

Phase 3: DURING DEVELOPMENT

PHASE 3A: CODE WALKTHROUGHS

PHASE 3B: CODE REVIEWS

Phase 4: DURING DEPLOYMENT

PHASE 4A: APPLICATION PENETRATION TESTING

PHASE 4B: CONFIGURATION MANAGEMENT TESTING

Phase 5: MAINTENANCE AND OPERATIONS

PHASE 5A: CONDUCT OPERATIONAL MANAGEMENT REVIEWS

PHASE 5B: CONDUCT PERIODIC HEALTH CHECKS

PHASE 5C: ENSURE CHANGE VERIFICATION

Pero como las ofertas Carrefour, ¡Esto no es todo! Existe una metodología orientada exclusivamente a seguridad de aplicaciones (ISSAF) que divide la seguridad en:

1.- Network Security

2.- Host Security

3.- Application Security

4.- Database Security

Que parece que está muy escuchimizá, aunque adentra mucho en la parte técnica ya que indica los ataques que se pueden realizar, lo que se espera obtener de esos ataques, que herramientas utilizar, y algún ejemplo:

Por tanto los “Pen Testing Advance” no tienen nada que ver con los “Pen Testing Basic” de los que hablaba hace unos días, ¿ahora bien, qué es lo que quiere nuestro cliente?, ¿Por cuánto tiempo es válida una auditoria OSSTMM?

Salu2!