TCP Split Handshake

Que mejor forma de retomar el blog que mandando un afectuoso salud a mis apreciados lectores, si los tuviera delante haríamos algo tal que así:

GigA --------->Hola:Lector

GigA:Hola + Mano<----------Lector

GigA:Mano<---------------->Mano:Lector

Etc.

Esto por si no lo habéis entendido es un saludo normal y corriente, que da paso a una conversación. Los humanos, fieles copiadores de lo que vemos en el mundo real decidimos trasladar esta forma de saludo a la informática, para que dos ordenadores pudieran iniciar su conversación lo harán de la misma forma. Es lo que conocemos como ThreeWay-Handsake , que originales somos:

Lo gracioso es que en el mundo virtual, al igual que en el real, pasamos del saludo a 3 bandas y pillamos a alguien desprevenido y le damos una colleja diciéndole: ¡ay maestro agujas!, ¡como vá capataz! (resto de saludos José Mota©), sin dejarle hablar ni nada. Esto entre colegas e incluso desconocidos puede ser gracioso, pero entre frías máquinas sin corazón es desastroso, tanto como que pueden reaccionar de formas raras, reiniciándose, parándose, ignorándote o accediendo a un nivel superior de funcionalidad (muchas veces esto también puede ocurrir con las mujeres), así una máquina se queda algo confusa cuando se le intenta abrir una conexión por ejemplo un SYN SEQ 1000, te responde con un SYN ACK 1000+1 SEQ 1500, y tu ignoras completamente su respuesta y vuelves a hacer otro SYN, y otro, y otro, y vas cambiando puerto, o le saturas un servicio a intentos de conexión, etc. Son muchas de las variedades de handshake que se pueden hacer en un escaner de puertos (para lo que vendría bien recordar esta entrada).

Sin embargo parecía que estaba todo inventado en lo que a saludos se refiere, cual es mi sorpresa cuando ayer me encontré esta interesante investigación de la gente de Macrothink, el TCP Split Handshake. Trasladado al lenguaje humano sería como realizar el saludo de forma normal, pero definir y recalcar cada una de las fases sin hacer nunca 2 cosas a la vez (¿?¿?), vale. Os pongo la imagen y me explico:

¿Qué es lo que se ha hecho?, separar el SYN, ACK que hace el servidor en dos pasos bien diferenciados, en dos paquetes distintos, algo que recoge perfectamente la RFC 793 en su página 27. Algo tan inocente como esto se ha probado con IDS/ IPS, routers, servidores, etc. con resultados más que soprendentes, y es que un servidor que tenga el protocolo de establecimiento de conexiones TCP alterado puede comprometer a sus clientes en una infinidad de casos. Veamos como reacciona el cliente cuando el servidor hace el split:

Lo que era un ThreeWay Handshake acaba convirtiéndose un FiveWay,,, de esto no decía nada la RFC 793. Otras curiosidades de esta particular forma de saludarse son que algunos IPS (lo probaron con un Juniper) no detectaron el ataque, sirviendo el splits tcp como técnica de evasión ya que, al no detectar la conexión como establecida no detectaba ataque alguno. En caso de NAT se encuentra de todo, desde un PIX-515 que era incapaz de hacer NAT y salir hacia otras redes con el splits TCP a un Cisco 2631 que se metía hasta Internet, luego parece que dependiendo del caso el NAT a priori no nos protegerá de este tipo de intentos de conexión. Finalmente, si estás ofreciendo un servicio en un puerto cualquiera, digamos el 22, y tu máquina es sometida a un escáner de red con un NMAP o similares no reaccionará tampoco de la forma habitual, pudiendo quedar oculto ese servicio o mal identificado:

Efectivamente esto para un atacante persistente no es un problema pero por ejemplo, para un barrido de un virus puede ser una “medida de seguridad”.

En resumen, este comportamiento anómalo en el establecimiento de conexiones por Split Handshake va a obligar a todo tipo de proveedores de equipos de comunicaciones, servidores, appliances de seguridad, etc. a añadir una excepción más o a contemplar que el ThreeWay Handshake no es la única forma de establecer una conexión TCP. Parece mentira que algo que lleva tantos años usándose no haya sido evaluado por muchos fabricantes en el 2010.

Ah, si queréis jugar tenéis scripts de ejemplo y capturas de Wireshark aquí, está hecho en Ruby y necesitareis las librerías libpcap para poder ejecutarlo.

Salu2

Firewall Rules Debugger

Si hay un elemento de seguridad que lleva años acompañándonos son los firewall, estos dispositivos que en un principio trabajaban solo hasta la capa 3 de la pila de protocolos OSI poco a poco fueron ganando complejidad, empezaron a trabajar con capas superiores e incluso a nivel de aplicación. Hoy en día hay appliances que incluyen IDS/IPS, te pueden establecer VPN’s y controlar el acceso a tu red mediante la terna AAA (Autenticación, Autorización y Auditoría).

Lo malo de estos cacharros es que pasa el tiempo, se van generando reglas y reglas, se implementan caducidades que luego nadie quita y su uso se degenera en el modelo de firewall suizo que vimos hace unos meses.

Hace poco tuve que trabajar en un proyecto donde tocaba auditar la configuración de varios firewall y como no, revisar las reglas compiladas y ver su consonancia respecto a las políticas de seguridad definidas. Me tocó lidiar con varios cientos de reglas así como estudiar los hits que se producían en reglas genéricas que en algún momento se habían consolidado. Para tan ardua tarea estuve buscando Tools que pudieran ayudarme, hay millares que quizás conocereis Flint, securetrack, FW auditor, etc. El caso es que no me acababa de convencer ninguna, yo lo que necesitaba era algo para hacer búsquedas, extraer las reglas que me interesaba, si fuese posible clasificarlas según el puerto y poco más, así que me curré esto:

Búsqueda de reglas...

Clasificando reglas,,,

Una pequeña aplicación que hace exactamente eso. Basta importar el archivo de logs requerido y comenzar a hacer búsquedas. Siempre que los puertos aparezcan después de “:” no tendrá muchos problemas para clasificaros las reglas y deciros el protocolo que debería haber por ahí dentro del rango de puertos reservados. También os pondrá un Warning cuando encuentre cositas raras o protocolos considerados “inseguros”, por ejemplo, Telnet.

Os dejo este link, descomprimir, instalar y cargar el archivo de reglas de ejemplo para poder comenzar a jugar. Está Beta, así que hay algunos errores y excepciones que todavía no he controlado y depurado, también da algún problema de compatibilidad visual en Windows 7 (no soy desarrollador. pero el .NET se debería llevar bien con este sistema operativo ¬¬), con todo ello la funcionalidad a grandes rasgos está implementada. Espero que os sea útil igual que lo fue para mí.

Salu2!

SSL Harden

En estos días donde parece que nada es seguro la tendencia es a cifrarlo todo, esto muchas veces no aplica solo a transferencias por redes inseguras (dice ser, Internet). Si no que también nos ocurre que comunicaciones por redes privadas como, una macrolan entre empresas, una conectividad intra-cpd, etc. requiere de ser cifrada. Con el uso cada vez menor de las VPN – IPSec que, por lo general, son consideradas menos seguras (hay quien diría que cómodas) que las VPN – SSL parece que la Secure Socket Layer se ha convertido en la panacea del cifrado para la transmisión de datos. Portales Web, conexiones a listeners de BBDD, redes privadas virtuales, etc. Nada más lejos de la realidad.

Hoy os presento una herramienta, SSL Harden que nos muestra todos los modos que SSL / TLS soporta, con los distintos algoritmos de intercambio de claves así como de cifrado simétrico soportados. Esta aplicación se basa en el paquete de SCHANNEL de Microsoft para detectar la forma en que implementa esta capa. Así podrá escanear un servidor y obtener toda la información sobre la configuración del servicio, detectando por ejemplo el soporte a Modolus 1, el cual si está activado hará que un servidor / cliente permita comunicaciones en las cuales la clave pública de RSA tiene exponente 1, estando la clave privada a 1 también. Esto es comunicaciones que parecen estar cifradas no lo son, van en claro.

Para escanear máquinas en el dominio necesitareis ser administrador del mismo, la aplicación si tiene los privilegios suficientes podrá configurar tu equipo editando las entradas de registro.

El SSL-Harden está en beta por lo que hay veces que se cuelga de forma absurda, aun así merece la pena echarle un ojo.

Salu2!

VPN PenTest

En el entorno maleable que se ha convertido el perímetro de nuestras organizaciones el uso de las tecnologías de Virtual Private Network, junto con un montón de cosas que vimos en la entrada de Trusted Network Connect supuso una especie de panacea en el acceso y consumo de servicios de nuestra organización.

Es tal la confianza que se tiene en la tecnología VPN (ya sea basada en IPSec, o en SSL) que muchas veces se caen en errores obvios que directamente exponen toda la organización. En el entorno actual de movilidad total para todos nuestros usuarios, todos nuestros proveedores, etc. auditar nuestros terminadores / servidores de túneles es casi una obligación. Hoy veremos algunos de los fallos más comunes y en los que casi nunca se caen.

Google

Una vez más el buscador se convierte en una herramienta de doble filo, por ejemplo, sabemos que los archivos de configuración de los terminadores de túnel CISCO tienen extensión .pcf, una pequeña búsqueda nos da resultados interesantes, con ficheros de configuración que albergan contraseñas codificadas:

…

AuthType=1

!GroupName=VPNeveryone

!GroupPwd=

!enc_GroupPwd=227CBC3037A8138A9C1

EnableISPConnect=0

ISPConnectType=0

ISPConnect=

ISPCommand=

Username=

!SaveUserPassword=0

UserPassword=

NTDomain=

EnableBackup=1

BackupServer= *************************************

EnableMSLogon=1

MSLogonType=0

EnableNat=1

TunnelingMode=0

…

Lo cual no sería un problema si no fuera por que existen herramientas que rompen el cifrado en poco tiempo, por ejemplo Cain:

Dándonos acceso completo a la intranet de una organización. No es un problema menor, ni el último de ellos.

Cliente VPN

Revisando el cliente VPN de CISCO que utilizamos en nuestro acceso podemos detectar (y aquí tenéis que hacer un acto de fe ya que he tenido que borrar bastante info) que nuestro usuario y password está en claro en memoria:

Los pasos para hacer este volcado se vieron en RAM Dumping

Lo cual es una debilidad adicional (en este caso poco podemos hacer, más que cambiar de cliente) que si no es compensada con otras medidas (¿bloquear la pantalla?) puede ser un problema.

Fingerprint

Los servidores VPN como todos los servicios también son sensibles al fingerprint, un sencillo nmap basta para detectar los servicios que corren en esa máquina y su versión:

Dándonos información más que jugosa. Aparte de los habituales Caín, Nmap, etc. existen herramientas especialmente dedicadas al pen-test de servidores VPN, como es Ike-Scan, capaces tanto de realizar ataques por fuerza bruta como de hacer fingerprint.

Como corolario os dejo un pequeño documento de auditoria de VPN, algo antiguo pero conserva totalmente su validez a día de hoy.

Salu2

Joomla SQL Injector & Bruteforce

Los sitios Web basados en el gestor de contenidos Joomla se han extendido como moscas, los éxitos en Internet son así. Hace 4 años nadie apostaba un duro por una compañía llamada youtube y hoy sus creadores nadan en piscinas de oro, con joomla ha ocurrido algo parecido, apareció en el 2005, gustó y triunfó. Ahora cualquiera tiene su sitio web basado en joomla (Powered with Joomla!).

Actualmente corre una versión estable 1.5, lo que significa que en 4 años no han existido grandes revoluciones en su motor, eso sí, las plantillas existentes se cuentan por miles. Basado en PHP Joomla también tiene sus “cositas” de Seguridad, RFI, SQL Injection, XSS, etc. concretamente ayer me encontré con un SQL Injector escrito en Python muy sencillo de usar, incluye las alrededor de 123 vulnerabilidades de este tipo disponibles, en la página de descarga van actualizando el script a medida que se hacen públicas más vulnerabilidades, lo ejecutamos indicándole que cargue la lista de sitios web de list.txt y:

|---------------------------------------------------------------|

| beenudel1986[@]gmail[dot]com |

| Joomla Sql Injection Scanner 2.5.6 |

| 11/2008 joomsq.py |

| Do Visit www.BeenuArora.com & darkc0de.com |

| Total: 123 Vulns |

|---------------------------------------------------------------|

Enter the DB prefix or press Enter to use default

Do you think target has salted or unsalted version ! press y for yes or n for n o y

[+] JoomlaPath: www.*********gital.es

[+] Vuln. Loaded: 123

[+] Testing...

[-] Done

[+] JoomlaPath: www.p******o.com

[+] Vuln. Loaded: 123

[+] Testing...

Decepción, no me encuentra nada. Y es que a no ser que encontréis una página desarrollada con un Joomla antiguo (anterior 1.5) no funcionará. Desanimado pruebo un Joomla BruteForce Cracker también disponible en el sitio de “Dark Codes”, me descargo un pequeño diccionario (23000 palabras), ejecuto y:

|----------------------------------------------|

| rsauron[@]gmail[dot]com v1.0 |

| 7/2008 joomlabrute.py |

| - Joomla Administrator Panel BruteForcer |

| Usage: joomlabrute.py [options] |

| -h help darkc0de.com |

|----------------------------------------------|

[+] Proxy Not Given

[+] BruteForcing:http://www.p*********.com/administrator/

[+] Username:pluks

[+] Words Loaded: 213560

[+] [12:10:47]

[!] Login Successfull: pluks:aa

[-] [12:10:49]

[-] Total URL Requests 1

[-] Done

¿Suerte? No lo creo, confirmo la sospecha, es un “falso positivo”. ¿Cómo puede ser?, bueno los mensajes de error en Joomla son configurables, el script solo busca en la página web si aparece la palabra “username”, si no está supone que hay autenticación exitosa (un poco cutre quizás), sustituimos esa palabra por nuestro mensaje de error, ejecutamos nuevamente y:

|----------------------------------------------|

| rsauron[@]gmail[dot]com v1.0 |

| 7/2008 joomlabrute.py |

| - Joomla Administrator Panel BruteForcer |

| Usage: joomlabrute.py [options] |

| -h help darkc0de.com |

|----------------------------------------------|

[-] Proxy Not Given

[+] BruteForcing: http://www.p**********o.com/administrator/

[+] Username: pluks

[+] Words Loaded: 213560

[+] [13:28:04]

[-] Login Failed: aa

[-] Login Failed: aal

[-] Login Failed: aalii

Esto tiene mejor pinta, ahora es solo cuestión de tiempo. Como vemos los administradores de sitios web basados en Joomla tampoco pueden relajarse en términos como robustez de contraseñas, actualización de parches, etc. Si no pueden encontrarse fácilmente con un deface :-p

Buen fin de semana!

Spider Windows

¡Hola!, Hoy os presento una herramienta interesante, todos conocemos spiders web que buscan y rastrean información valiéndose del motor de Google, Yahoo, Bing, etc. La herramienta de hoy hace algo similar pero en la máquina que le digamos, que puede ser local o estar en la misma red. Se llama Spider Windows y es muy sencilla:

Spider Windows buscará números de tarjeta de crédito, de teléfono, DNI, etc. en la partición o unidad que le indiques, esto incluirá por supuesto ficheros ocultos. Esta búsqueda es configurable permitiendo añadir los patrones que queramos:

Con los resultados que encuentre generará un fichero de log con el PATH de los ficheros que contienen información sensible, este será depositado en la ubicación elegida, si es un servidor externo lo enviará valiéndose del protocolo SYSLOG. ¡Es sorprendente las cosas que uno almacena en su equipo!, yo me he encontrado con números de teléfono que ni recordaba andaban por ahí. En un ambiente un poco más profesional esto nos puede valer por ejemplo para saber que información sensible tenemos en una máquina, para ayudarnos en el cumplimiento de PCI-DSS, LOPD, etc. Si hacemos una auditoría con los patrones apropiados encontraremos qué información está expuesta para un usuario no-administrador en un servidor (por ejemplo).

Hay una alternativa Linux que incluye funcionalidades forenses detectando archivos borrados también, está incluida dentro de la distribución de Helix y se llama Spider Linux. Habrá que tenerla en cuenta también en el análisis de incidentes.

Salu2

Sello Europeo de Privacidad

El proyecto para definir un programa de certificación de productos en lo que a seguridad y protección de datos a nivel europeo se refiere está a punto de terminar. A grandes rasgos este proyecto establece un proceso de certificación para que cualquier entidad que trabaje con sistemas o servicios que traten datos de carácter personal pueda certificar los mismos (sea una aplicación, sea un producto hardware, etc.), con un sello de confianza reconocido dentro de la Unión Europea, este proceso de certificación incluye:

- Evaluación del producto por expertos jurídicos.
- Auditoría del producto por expertos TI.
- Informe de conformidad con los criterios de evaluación del catálogo de criterios europeos.
- Aceptación del producto bajo el sello de privacidad europeo.

Como os podeis imaginar la definición y puesta en vigor del European Privacy Seal (Europrise) supondrá un valor añadido al que muchas empresas querrán subirse para certificar sus productos y servicios, exactamente igual como ya ocurrió con la ISO 9000 de calidad. En España el informe de auditoría y evaluación del producto técnica y legal será revisado por la Agencia de Protección de Datos de la Comunidad de Madrid, quien por ahora es la única entidad nacional que puede homologar el Europrise.

En la llamada "Sociedad de la Información" donde la penetración de las tecnologías en los ciudadanos es cada vez mayor, es absolutamente necesario la presencia de un producto como este que proporcione confianza a los ciudadanos en el uso de las TIC. Por si a alguien le quedan dudas por aquí tenéis el último barómetro de la Agencia Española de Protección de Datos de Septiembre 2009, en el figuran los siguientes datos:

- El 46% no conoce de la existencia de la AEPD.

- El 43% le preocupa bastane la protección de datos y el uso por terceras personas, al 30% mucho.

- El 56% considera que la privacidad de sus datos en Internet es baja o muy baja.

- Al 77% le da poca seguridad dar su número de tarjeta de crédito por Internet para hacer sus compras.

Contra estas cifras iniciativas como el Europrise son de agradecer, no obstante nunca podemos dejar las necesarias campañas de Sensibilización y Formación al ciudadano en lo que al buen uso y seguridad de Internet se refiere.

Si queréis profundizar en este tema el 3 de Noviembre se va a dar un seminario en la Casa de Correos en Madrid, la entrada es gratuita, solo limitada al número de plazas.

Buen fin de semana :)

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

Metasploit Unleashed

Os dejo otra pequeña reseña, los chicos de Offensive Security han publicado un curso gratutito de Metasploit que merece la pena echarle un ojo, está disponible aquí y abarca las materias habituales de la herramienta estrella en el manejo de exploits. El curso incluye:

- Information Gathering

- Vulnerability Scanning

- Writing a simple fuzzer

- Exploit Development

- Client Side Exploits

- MSF Posts Exploitation

- Meterpreter Scripting

- Maintaining Access

- Etc.

Está en inglés y aunque entra en detalle aportando pantallazos y explicaciones es necesario tener una buena base en programación y sistemas operativos para poder completarlo y entenderlo.

Espero que os guste.

Un saludo.

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