tools

TOPERA – Ataques IPv6 invisibles a Snort

¿Qué es TOPERA?

Topera es una herramienta que realiza ataques IPv6 que no son detectados por Snort o sistemas basados en Snort.

¿Qué hace diferente a TOPERA?

En muchos foros, blogs, reddit e, incluso, la propia lista de correo de Sourcefire (empresa fundada por el creador de Snort) se ha cuestionado los ataques que lleva a cabo TOPERA y como estos podrían detectarse ajustando las reglas de detección de Snort.

TOPERA aprovecha un fallo de diseño de Snort en el tratamiento de ciertos paquetes de IPv6. Esto significa que no importa lo buenas que sean las reglas que se tengan configuradas, Snort no será capaz de detectar los ataques que se aprovechen de este fallo de diseño.

TOPERA no ha reinventado la rueda, en lo que ataques se refiere, pero les ha otorgado la capacidad de ser indetectables por Snort.

¿Qué hay de nuevo en la versión 2?

TOPERA se encuentra en su versión 2, que fue presentada en el XI foro de seguridad en RedIris, mejorando el anterior ataque e incorporando uno nuevo: slow HTTP.

TOPERA fue la primera en incorporar este ataque bajo IPv6 (que días más tarde fue añadido al proyecto slowloris) y, además, dotarlo invisibilidad ante Snort:

¿Qué consecuencias tiene TOPERA?

Si eres administrador de sistemas, probablemente ya te habrás echado a templar leyendo el nuevo ataque. Si no eres sysadmin o todavía no le ves el peligro real (más allá del propio ataque) esto tal vez te haga hacerte una idea:

Usando TOPERA puede inutilizar (durante todo el tiempo que se esté ejecutando el ataque) un servidor web vulnerable a slow HTTP attaks, como Apache. Al no ser detectado por el IDS (basado en Snort) no podrás tomar contramedidas para poder protegerte o tratar de mitigar el ataque. Por lo tanto: el sistema de seguridad en que delegas para proteger tu infraestructura será inútil y no podrás hacer nada, ya que todavía no hay forma de solucionarlo.

No está mal, ¿verdad? Creo que ahora ya todo el mundo entiende el porqué los sysadmin se echaron a templar :-P

Uso y disfrute

Usar TOPERA es muy sencillo. Está hecho en python y es multiplataforma (aunque en Windows os irá muy lento si usáis el intérprete oficial de python: CPython).

Tenéis toda la documentación y ejemplos del estilo “copy&paste” (lo que más nos gustan, ¿verdad? :-P) en la web del proyecto que tenemos publicada en github: http://toperaproject.github.io/topera/

Por si sois algo perezosos, no tenéis ningún sistema con IPv6 a mano o, sencillamente, no os apetece bajar la herramienta para verla en acción, aquí os dejamos el video oficial que hicimos de demo:

Y, como pone un poco más arriba, a usarlo y disfrutarlo. Eso si! Con moderación y no la lieis demasiado :)

—–
Autores:
Rafael Sánchez – @R_a_ff_a_e_ll_o
Daniel García A.K.A. cr0hn – @ggdaniel

smtp-enum: Enumerando usuarios de correo mediante el protocolo SMTP

Durante la realización de una auditoría de seguridad o un test de intrusión, especialmente en este último caso, es necesario obtener cuanta información acerca del objetivo sea posible, haciendo especial hincapié en recolectar la mayor cantidad de cuentas de usuario existentes. Para conseguir cuentas de usuario válidas existen diversas técnicas, en función de la metodología empleada o el servicio usado para enumerarlas, siendo una de ellas el servicio de recepción de correo mediante el protocolo SMTP. Tal y como se expone en el RFC 821, ya desde los comienzos el protocolo SMTP cuenta con diversos comandos que nos pueden ser de utilidad a la hora de comprobar si una cuenta de usuario existe o no (por supuesto siempre dependiendo de la propia configuración de dicho servidor SMTP); dichos comandos son los siguientes:

  • Comando VRFY: Se utiliza para consultar al servidor de correo si el usuario indicado existe o no.
  • Comando EXPN: Se utiliza para preguntar (expandir) por una lista de distribución de correo, si existe el servidor deberá devolver la lista de correos pertenecientes a dicha lista de distribución.
  • Comando RCPT TO: Se utiliza para indicar al servidor de correo el destinatario del mismo, según el comportamiento del servidor de correo puede sernos útil para enumerar direcciones de email.

A continuación pongo un ejemplo de cada uno de los métodos (por motivos obvios se han tachado ciertos datos): En el primer caso, el comando VRFY, se puede ver como primero se pregunta si existe el usuario “doesntexist” y el servidor responde negativamente para, posteriormente obtener una respuesta afirmativa para el usuario “root”:

El siguiente comando es EXPN, donde se puede observar que existe una lista de distribución “admin” con cuatro miembros nominales y una quinta cuenta llamada “backup”:

Por último, en algunos casos podemos utilizar el comando RCPT TO para enumerar cuentas, como en el siguiente caso:

Por supuesto, esto es porque el servidor de correo comprueba la existencia de la dirección de correo indicada antes de aceptar el email, en el caso de relays que acepten automáticamente todos los destinatarios, para el dominio gestionado se entiende, o servidores con un comportamiento similar, dicho método de enumeración no será útil puesto que sería imposible discernir si la cuenta indicada existe o no. Con el fin de automatizar la comprobación de los métodos que se pueden o no utilizar para enumerar las cuentas de correo electrónico así como dicha enumeración, se ha programado smtp-enum, una herramienta programada en Python y de licencia open source totalmente abierta a contribuciones. Veamos cómo funciona:

Los parámetros principales, y obligatorios por tanto, de la herramienta son únicamente cuatro: el dominio cuyas cuentas de correo queremos tratar de enumerar, el fichero de texto con el listado de cuentas a comprobar, el fichero de texto en el que queremos guardar las cuentas enumeradas y el método que queremos utilizar para realizar la enumeración. Aunque anteriormente no se ha comentado, la mayoría de los servidores de correo actuales soportan el método EHLO (Extended HELO) usado para indicar el soporte de ciertas extensiones de SMTP y que el servidor, en la mayoría de los casos, nos devolverá el listado de dichas extensiones soportadas (entre las que se pueden encontrar los comandos EXPN y VRFY):

En este caso se puede observar el método “EXPN”, lo que nos indica que, con casi toda certeza, podremos usarlo para enumerar direcciones. Aquí es necesario remarcar que, aunque a veces un método aparezca o no en la lista, no siempre es indicador fidedigno de que se pueda o no utilizar, no quedando más remedio en ciertos escenarios que la comprobación manual. Por último, un ejemplo de la herramienta en acción:

Como se puede observar, al no indicarle el servidor de correo a utilizar para la enumeración la herramienta obtiene los registros MX y los lista junto con la prioridad de cada uno para que nosotros decidamos cuál usar, a continuación prueba los métodos soportados (en base a la respuesta al comando EHLO mostrada anteriormente) y, por último, los usa para enumerar cuentas. En el caso de que queramos indicar un servidor concreto a utilizar para la enumeración podríamos hacerlo como en el ejemplo siguiente:

Como se ve en este caso se ha obviado el paso de la obtención de entradas MX y directamente se ha procedido a tratar de enumerar cuentas de correo electrónico para el dominio proporcionado (tachado por motivos de respeto).

Por último simplemente desear que os sea de utilidad la herramienta y que estaremos encantados de contar con vuestras colaboraciones al código así como sugerencias y/o críticas.

— Nos vemos en Twitter: z0mbiehunt3r

DNSSnoopy – Herramienta para hacer DNS Cache Snooping

A la hora de realizar una auditoría de seguridad el primer paso es obtener y recolectar la mayor cantidad de información posible acerca del objetivo que nos pueda ser de utilidad.

Entre dicha información se encuentran los dominios con los que los empleados de la entidad se relacionan de un método u otro, actualizaciones de software, envío de correos electrónicos, visitas a páginas web, etc.

La utilidad que le podemos dar a esta información es diversa dependiendo del tipo de dominio obtenido:

  • Direcciones de actualización para realizar ataques de evilgrade
  • Dominios de malware para saber si algún equipo está contactando con un servidor de malware (existen multitud de dominios de malware, pero puede ser útil para comprobar algunos en concreto)
  • Un atacante con fines lucrativos podría buscar ciertos dominios “para adultos” con el fin de chantajear
  • Búsqueda de redes sociales y profesionales. Por ejemplo, para buscar en ellas más información acerca de los empleados.
  • Para buscar tus propios dominios y saber si la empresa se ha interesado por tí. Por ejemplo, una entidad de gestión visitando páginas p2p o de detectives privados :)

La metodología para hacer “snooping” de los dominios cacheados en un servidor DNS es muy sencilla. Debido a la topología jerárquica de DNS, si realizamos una consulta DNS y el servidor consultado no tiene la entrada cacheada (esto dependerá de su configuración, obviamente), escalará la petición a un servidor DNS un nivel jerárquico por encima.

Es precisamente este comportamiento el que nos permite hacer el ataque de “snooping”, en la petición DNS podemos indicarle al servidor que no use recursividad, si no tiene la entrada en su tabla de DNS y/o caché no escalará la petición y devolverá una respuesta negativa. Debido a ello, cualquier petición no recursiva contra el servidor DNS y a un dominio del que no es autoritativo indicará que ese dominio se encuentra cacheado.

Para poder explotar esta vulnerabilidad de una forma sencilla y automatizada he desarrollado la herramienta DNSSnoopy (http://code.google.com/p/dns-snoopy/). El funcionamiento de la herramienta es el siguiente:

  1. Primero obtiene los servidores DNS del dominio solicitado.
  2. Comprueba si alguno de ellos es vulnerable al ataque de snooping, para ello se solicita un listado de los dominios más comunes hasta que se encuentra alguno cacheado o se acaba la lista.
  3. Si se ha obtenido uno o más servidores vulnerables se procede a probar una lista de dominios que se indique para encontrar los cacheados con anterioridad.
  4. Trata de calcular el tiempo que hace que se cacheó en el servidor vulnerable, para ello compara el TTL obtenido del servidor cacheado con el TTL original.

Os dejo un pantallazo de la herramienta en acción:

Esperamos que os resulte de interés y utilidad en alguna auditoría o simplemente para trastear, además el código está en Python y es open source, por lo que es muy fácil modificarlo para vuestras necesidades.

Podéis contactar con el autor a través de Twitter: https://www.twitter.com/z0mbiehunt3r

Mejorando los resultados de nmap – La bbdd de payloads.

Seguro que más de una vez, habéis observado la diferencia de tiempo necesario entre un escaneo de tipo UDP y un escaneo de tipo TCP, siendo el primero mucho más lento que el segundo.

Esto se debe a que UDP es un protocolo de transporte no orientado a conexión, al contrario que TCP. Ello quiere decir que en TCP, antes de mandar cualquier información a otro equipo a través de la red (en redes que usen TCP o UDP como protocolos de transporte), se establece un canal previo con el otro extremo, es lo que se conoce como fase de “three-way handshake”:

En cambio, cuando se usa UDP como protocolo de transporte, la información se manda sin realizar ningún tipo de establecimiento de canal previo, ni llevar ningún tipo de control de la información que se  pueda estar perdiendo por el camino. Se gana velocidad pero se pierde confiabilidad (en caso de que sea necesario hacerlo, será una capa superior del modelo de red, la encargada de ello).

Cuando hacemos un escaneo con nmap, por defecto se incluyen únicamente las cabeceras de los paquetes sin ningún tipo de carga de “aplicación”, esto es así para enviar menos tráfico y hacer el proceso lo más rápido posible. La desventaja que tiene este método de funcionamiento es, que ciertos dispositivos de seguridad, como un IPS o firewall, pueden descartar el paquete TCP si ven que no tiene carga útil, para ello nmap cuenta con la opción “–data-length” para indicar el número de bytes aleatorios que se incluirán en los paquetes.

Si bien, esto nos puede resultar útil para escaneos de tipo TCP, en escaneos UDP es totalmente inútil, además, la mayoría de los servicios UDP no responderán a un datagrama que no contenga carga útil. Para ello, nmap incorpora ciertos “payloads” para servicios UDP conocidos que se establecen en el fichero “nmap-payloads” (http://nmap.org/svn/nmap-payloads).

Ahora pongamos un caso útil, necesitamos detectar servidores DNS en un rango de red, para ello podríamos hacer algo parecido a lo siguiente:

Como vemos en la imagen, únicamente el primer servidor ha respondido con un datagrama, el resto aparecen como “abiertos|filtrados” ya que no se ha podido determinar.

En esta prueba, el payload utilizado es el que viene por defecto “\x00\x00\x00\x30\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00”.

Ahora, probamos a capturar otro payload mediante Wireshark, para ello capturamos la petición y en la parte de “Domain Name System (query)” seleccionamos “Copy, bytes, hex-stream” y obtendremos algo así “babd010000010000000000000377777706676f6f676c6503636f6d0000010001”, esto lo pasamos a notación hexadecimal y lo insertamos en la base de datos “nmap-payload”:

udp 53 “\x8d\x78\x01\x00\x00\[…]\x63\x6f\x6d\x00\x00\x01\x00\x01″ (Se ha recortado por motivos de espacio, descuadraba demasiado)

Y volvemos a lanzar el mismo escaneo:

Como podemos observar ahora, tanto el primer servidor como el segundo, han respondido con un datagrama, habiendo obtenido un puerto abierto más.

Todo es cuestión de probar distintas cargas y quedarnos con la que mejor resultados nos dé, espero que os resulte interesante y de utilidad.

Podéis contactar con el autor a través de Twitter: https://www.twitter.com/z0mbiehunt3r

Plugin de Ayuda en Línea MSDN para OllyDbg / Immunity Debugger

Hola a todos. En esta ocasión voy a presentar un plugin para el depurador OllyDbg / Immunity Debugger que va a facilitar la tarea de realizar la ingeniería inversa de un binario de Windows.

¿Qué es OllyDbg?

OllyDbg es un clásico depurador de binarios a bajo nivel para el sistema operativo Windows. Según muchos, es la herramienta ideal para hacer ingeniería inversa de programas de los que no disponemos del código fuente (por ejemplo, malware), y también es muy utilizado en el mundo del cracking.

Una de las características más atractivas que tiene es la posibilidad de cargar plugins. La mayoría están orientados a ayudar en el desempacado de binarios protegidos y evitar la detección del depurador por parte del código malicioso que estemos analizando, aunque los hay para muchas otras tareas.

¿Qué es Immunity Debugger?

Luego de varios años sin actualizaciones, y tras múltiples exploits publicados que no han sido corregidos por el autor, la empresa Immunity decidió comprar el código fuente para actualizarlo y mejorarlo. Así nació Immunity Debugger, que parece estar destinado a reemplazar al viejo Olly, especialmente en el terreno del exploiting que es donde se están concentrando más las nuevas características y los nuevos plugins.

¿La pega? Que los viejos plugins de OllyDbg en general ya no funcionan más. Si se dispone del código fuente se pueden actualizar e incluso hacer que funcionen en ambos. Si no, la cosa está más complicada, aunque hay una herramienta que ayuda bastante.

El plugin que presento hoy funciona correctamente en ambos programas. :)

¿Para qué sirve este plugin?

OllyDbg ya tiene sus años, y aunque se sigue usando no siempre ha envejecido con gracia. ;) Uno de sus puntos flacos es el soporte de ayuda de Windows.

Me explico. Al analizar un binario en Windows normalmente veremos código ensamblador y llamadas a funciones de la Win32 API, que es la interfase de programación de bajo nivel en Windows. Las funciones de la API son muchas y es imposible memorizarlas todas, por lo que es imprescindible poder consultar la documentación de Microsoft para saber qué hace cada una, qué parámetros llevan, etc.

Ahora bien. OllyDbg ya permitía desde sus comienzos consultar la documentación de Microsoft gracias a un archivo llamado “WIN32.HLP“, que venía con la SDK de Windows NT, y contenía la documentación más completa y detallada… de aquel entonces. Pero ya pasaron varias versiones de Windows y unos cuantos años, Microsoft dejó de dar soporte a ese manual para dar paso a la documentación online de la MSDN (Microsoft Developer Network), y lo que ocurre ahora es que al consultar la ayuda desde el Olly muchas de las cosas que buscamos no aparecen. :(

Este plugin viene a llenar ese vacío. Al instalarlo, cuando OllyDbg intente acceder a WIN32.HLP para mostrar la documentación, el plugin lo intercepta y lanza el navegador web en la página correspondiente de la documentación online. :)

¿Cómo se instala este plugin?

Es simple, hay que descargar el archivo zip, extraer el plugin (OllyMSDN.dll) y copiarlo a la carpeta de instalación del depurador.

En OllyDbg esta carpeta suele ser “C:Program FilesOllyDbg” (en castellano C:Archivos de ProgramaOllyDbg”).

En Immunity Debugger la carpeta suele ser “C:Program FilesImmunity IncImmunity Debugger” (en castellano nuevamente reemplazar “Program Files” por “Archivos de Programa”).

El siguiente paso es cargar el depurador, y desde el menú “Help” ir a la opción “Select API help file”. Allí hay que, o bien seleccionar el viejo WIN32.HLP (aunque no se vaya a usar), o al menos un archivo cualquiera que se llame exactamente igual (el contenido da lo mismo). El nombre es importante, porque es la manera en que el plugin se da cuenta de que el usuario está intentando consultar la documentación de Microsoft y no, digamos, la ayuda del propio OllyDbg.

Una vez hecho esto, ya está completa la instalación.

¿Cómo se usa este plugin?

Se usa exactamente igual que el viejo archivo WIN32.HLP. Es decir:

Para acceder a la documentación, vamos al menú “Help” y seleccionamos la opción “Open API help file”.

Para ver la ayuda de una llamada API en concreto, hacemos click derecho sobre la línea de código ensamblador y seleccionamos la opción “Help on symbolic name”.

¿Dónde consigo este plugin?

Se puede comprar por el módico precio de… nah, mentira, es completamente gratuito! :)

Se descarga siguiendo este link: OllyMSDN.zip

El archivo zip contiene el binario precompilado para Windows y el código fuente, liberado bajo la licencia GPL v2. El fuente compila bajo Visual Studio 2008, no lo he probado con otros compiladores.

Bueno, eso es todo por hoy. Que les aproveche! :)


Sígueme en Twitter: @Mario_Vilas | Linkedin: http://es.linkedin.com/in/mariovilas

Page 1 of 41234»