Mostrando entradas con la etiqueta PenTest. Mostrar todas las entradas
Mostrando entradas con la etiqueta PenTest. Mostrar todas las entradas

22 de febrero de 2010

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

14 de noviembre de 2009

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!

17 de octubre de 2009

Forensic Analysis of a Network Scan

¡Hola! Volvemos a la carga con una vieja asignatura que teníamos aparcada desde hace tiempo: Análisis Forense. En el día de hoy hemos cogido un sencillo reto “for beginners” de los muchos existentes en los “scan of the month” del honeynet Project. En el mismo nos proporcionan un fichero binario con un tcpdump de varios megas que incluye una serie de tráfico TCP/IP que deberemos analizar para averiguar que ocurrió, el reto incluye la respuesta a varias preguntas de creciente dificultad. En este “mini-reto” utilizaremos herramientas tan comunes como Wireshark (también vale Ethereal o el sniffer que a vosotros os guste) y nmap. Vamos para allá:

1.- What is a binary log file and how is one created?

Una teórica para empezar, un fichero binario no es más que un archivo generado por el NIDS (Network Intrussion Detection System) Snort que, apoyándose en las habituales librerías Libpcap / Winpcap es capaz de depositar el tráfico exactamente igual que circula por la red en un fichero. La presencia de copias exactas de los paquetes nos garantiza que nada es modificado, ¡el requisito más importante en cualquier investigación! Esto nos lleva a la siguiente cuestión.

2.- What is MD5 and what value does it provide?

Bueno, creo que esto lo sabéis todos ya, lo vimos en esta entrada. El MD5 no es más que un algoritmo de un solo camino que calcula un valor hash, ese valor es único para cada entrada, o eso se supone. Existe un verdadero debate (el cual me está dando una idea para una futura entrada) acerca de la validez de un hash como mecanismo que garantiza que una evidencia no ha sido comprometida, debate acrecentado a medida que se descubren colisiones en los principales algoritmos: MD5 y SHA1. Cuando nos descargamos los archivos del reto nos piden que confirmemos el hash, en este caso lo hemos hecho:

3.- What is the attacker’s IP address?

Se acabó la literature, tenemos que averiguar la dirección IP del atacante, para ello (y dado que no es un fichero grande) examinaremos todas las IP origen y destino con Wireshark. Rápidamente podemos observar que aparecen las siguientes IP source:

192.168.0.9, 192.168.09.9, 192.168.0.254, 192.168.0.199, 192.168.0.1

Y las siguientes IP de destino (IP.dst):

192.168.0.9, 192.168.0.99

En la siguiente captura hacemos filtrado para asegurarnos que no hay otras IP.dst:

De forma curiosa, la regla no filtra aquellos destinos inalcanzables (¡pero eso es una pista!), ahora bien, ¿Cómo sabemos la IP del atacante a partir de esta información? Deberemos examinar los paquetes, no obstante algo huele a chamusquina cuando el 99% del tráfico procede de 192.168.0.9 y tiene de destino 192.168.0.99. No obstante nos aseguramos comprobando el tráfico que sale de 192.168.0.99 y eliminando el que tiene de destino 192.168.0.9 (genera demasiado ruido), obteniendo que no hay tráfico de estas características. Lo cual quiere decir que no hay respuesta de 192.168.0.99 hacia otros destinos distintos de 192.168.0.9, en este caso la ausencia de evidencia es la evidencia de que el atacante (¿supuesto atacante?) proviene de 192.168.0.9, probablemente por que el resto de destinos no existían (¿IP spoofing?).

4.- What is the destination IP address?

Como hemos hecho nuestro trabajo bien en la anterior cuestión, sabemos que la IP que estaba respondiendo a todas las peticiones era la 192.168.0.9. Parece que vamos bien ;-)

5.- We scanned de honeypot using five different methods. Can you identify the five different scanning methods, and describe how each of five works?

Comienza a subir la dificultad del análisis, nos piden averiguar las distintas tácticas de escaneo utilizadas. Vayamos por partes, nada más comenzar la captura se observa un ping hacia 192.168.0.99, justo después (Time 10.346091) comienzan a hacerse peticiones de tipo SYN desde el puerto origen 52198 hacia puertos fuera del rango reservado, el host escaneado responde con trazas [RST, ACK], lo que significa que se ha llegado al puerto pero no hay nadie escuchando, este podría ser nuestro primer tipo de escaneo:

Correspondiente a un nmap –sS (TCP SYN Scan) 192.168.0.99, el cliente debería responder con un ACK pero no lo hace, se queda a medio camino (half-open scanning).

En el Time 148007 se vuelve a producir un ping hacia 192.168.0.99, en ese momento se arranca otro tipo de escaneo, el wireshark nos cambia los colores, lo que ayuda ya que es muy llamativo:

Parece que se están tratando de hacer fingerprinting del sistema operativo, es decir, detectar que tipo de máquina hay detrás, en este caso el escaneo se concentra en los puertos habituales de servicios Windows. Por ahora parece que no tiene suerte nuestro atacante :) sin embargo poco tiempo después, línea de tiempo 150563 comienzan a aparecer paquetes ACK duplicados (el Wireshark los pinta de un negro terrorífico), que tienen su cumbre en el 150626, donde se comienza a recibir [SYN-ACK] en servicios habituales de Windows, lo que parece un nmap –sX (Xmas scan) bastante exitoso:

Ahora bien, justo después (se puede apreciar en la imagen anterior) el atacante trata de establecer conexiones al puerto SSH, pero con todos los flags TCP sin determinar, esto significa que estamos delante de un “Null Scan”, también llamado nmap –sN, si pinchamos en cualquier paquete veremos esta información dentro de los flags del protocolo de control de transmisiones:

Terminamos con un último ataque, se llama decoy scanning y sirve para que el host remoto no sepa identificar (a priori) quien es el host destino, decoy significa señuelo en inglés y lo que hace es realizar la misma petición desde varias IP inexistentes como las que vimos en 3), está muy bien para pasar desapercibidos aunque obviamente no tiene sentido en un entorno como el que estamos viendo:

Puede reproducirse con nmap y la opción –D. Y con esto hemos repasado los escaneos que se han realizado, como vemos es importante conocer los tipos de escáneres que permiten las herramientas, para ello podemos acudir por ejemplo a las técnicas que explican en la página del escáner más famoso.

6) Which scanning tool was used to scan our honeypot? How were you able to determine this?

Bien, en el punto anterior vimos que opciones de nmap había que habilitar para cada ataque, pero eso no significa ni mucho menos que haya sido esta herramienta, ¿verdad? Necesitaremos utilizar un NIDS para analiza las trazas y verificar si detecta algún ataque y por parte de qué, para ello no hay nada como Snort, que nos devolverá algo parecido a esto:

[**] [111:10:1] spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection [**] - 22539

[**] [111:9:1] spp_stream4: STEALTH ACTIVITY (NULL scan) detection [**] - 3996

[**] [111:12:1] spp_stream4: NMAP FINGERPRINT (stateful) detection [**] - 9

[**] [1:628:1] SCAN nmap TCP [**] - 9

Luego ahí tenemos a nuestro principal sospechoso.

7) What is the purpose of port scanning?

Bueno, la razón de realizar un escáner de puertos es bastante sencilla. Identificar todos los servicios y puertos abiertos que el host “víctima” está ofreciendo. O dicho de otro modo, identificar los posibles puntos de entrada a su sistema. Es una definición algo tosca pero nos vale :)

8) What ports are open on our honeypot?

Tal y como vimos en 5) los mecanismos para establecer una conexión TCP/IP incluyen el famoso saludo “a 3 bandas” o 3-way handshake, de tal forma que cuando hay un puerto abierto y dependiendo del ataque lo podemos identificar de varias formas. A grandes rasgos para no extender la entrada en demasiado he recolectado todos los paquetes emitidos por 192.168.0.99 con [SYN,ACK], es decir donde hay servicios, con ello he identificado los puertos:

- 22 / SSH

- 53 / DNS

- 80 / HTTP

- 443 /HTTPS

- 111 / SUNRPC

- 32768 / FILENET

9) Bonus Question: What operating system was the attacker using?

Esta cuestión puede parecer a priori la más difícil de responder, obtener el sistema operativo origen a partir de unas trazas TCP/IP podría ser un problema si no fuese por herramientas como p0f, Ettercap o Network Miner, las mismas utilizan técnicas de fingerprinting pasivo a raíz de los valores TTL, el tamaño de la ventana, type of service, (TOS) etc. Se puede profundizar en estas técnicas aquí. Yo he escogido Network Miner, la cual nos podría haber facilitado el trabajo desde el principio (pero entonces no habría sido tan divertido ;-) ) ya que es una herramienta de análisis forense en red. Ella nos muestra que tanto host atacante como host atacado eran Linux:

Y esto es todo por hoy, el análisis forense es magnífico para repasar y profundizar en los habituales conocimientos de redes, sistemas operativos, etc.

Buen fin de semana :)

NdA: Estoy teniendo bastantes problemas para escalar las imágenes sin perder detalle, así que se ven bastante pequeñas, siento el inconveniente.

1 de octubre de 2009

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

22 de septiembre de 2009

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.

18 de septiembre de 2009

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 ;-)

16 de septiembre de 2009

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

16 de julio de 2009

Firefox Tunning: Top 10 plug-ins

Debates acerca de qué navegador Web es mejor hay casi todos los días, estadísticas sobre cual es más seguro también. Están aquellos que no salen de Internet Explorer, los amantes de Firefox, empieza a surgir un grupo numeroso (entre el que me encuentro) que les gusta la agilidad y rapidez del Chrome, los applemaniacos tienen su Safari, etc. Etc. Independientemente de cual utilices estarás conmigo en que hay uno de todos ellos que destaca por la cantidad ingente de complementos y plug-in de que dispone: Firefox.

De aquí surge la idea, ¿puede ser un navegador una buena herramienta de trabajo en nuestras auditorias? Por supuesto que si, es casi indispensable. Ahora bien, ¿puede agilizarnos el trabajo? También.

He hecho una pequeña lista con los 10 plug-ins más interesantes para hacer Firefox tunning, evidentemente no estaréis de acuerdo con algunos de ellos y otros los desconoceréis, de igual forma si conocéis alguno que puede venir bien, animaros a comentad :-)

1.- User Agent Switcher à Indispensable si quieres cambiar la forma en la que te presentas a los servidores web.

2.- Foxy Proxy à Muy útil para cambiar de proxy de forma ágil, si utilizáis herramientas como Paros es indispensable.

3.- FireGPG à Utilidad para incorporar cifrado y autenticación PGP a nuestro correo electrónico, lobosoft ya nos hablo de él cuando vimos el PGP Desktop.

4.- Secure Password Generator (Firefox 3.0) à Sencilla utilidad para generar nuestras password de forma robusta.

5.- Ghostery 1.5.1 à Este fantasmita se nos incorporará en la barra de tareas avisándonos cuando el sitio que visitemos intenta recuperar información “adicional” de nosotros. Muy util para proteger nuestra privacidad.

6.- Dr.Web anti-virus link checker 1.0.20 à Y que tal si en vez de bajarnos algo y pasarle el antivirus, lo hacemos “antes” de que ya esté en nuestro equipo, o de otra forma, antes de visitar una pagina web y cargarla, ¿por qué no revisamos el enlace? Dr.Web lo hace por nosotros.

7.- Access Me à Esta herramienta y las dos siguientes forman parte de un pack de auditoria web donde se tratará de acceder a links ocultos, hacer SQL injection en su forma básica y XSS, genera sus propios informes y todo :) proporcionado por Security Compass.

8.- SQL Inject-Me

9.- Exploit-Me

10.- Web Of Trust à Incorpora a tus busquedas en google, bint, etc. un indicador con la confianza que puedes tener al visitar un sitio web.

10 + 1.- Panic Button 1.1.2!! (este ya sabeis para que vale).

Es posible que al final os junteis con un monton de complementos y al final os salgan unas barras minimo como esta, pero a buen seguro ganareis en seguridad y agilidad :-)

Salu2!

*Nota del autor: Un link más completo de Firefox Tunning, lo teneis aquí: http://www.security-database.com/toolswatch/Turning-Firefox-to-an-Ethical.html hay algunos que ya los señalaba yo, y otras que efectivamente se echan de menos, habrá que subir de Top 10 a Top 30 :-)