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

(Español) DNSSnoopy – Herramienta para hacer DNS Cache Snooping

(Español) Mejorando los resultados de nmap – La bbdd de payloads.

MSDN Help Plugin for OllyDbg / Immunity Debugger

Hello everone. Today I’m showing you a new plugin for OllyDbg / Immunuty Debugger that I hope will help you when reversing Windows binaries.

What is OllyDbg?

OllyDbg is a classic user-mode debugger for the Windows operating system. According to many, it’s the idea tool for reverse engineering software when you’re not likely to get a hold of the source code (malware, for example), and it’s also widely used in the cracking scene.

One of its most appealing features is the possibility of loading plugins. While most of them are geared towards binary unpacking and avoiding detection from malicious code, there are plugins readily available for a multitude of tasks.

What is Immunity Debugger?

After many years went by, no updates were available. That meant no fixes for the multiple public exploits available on the Internet. That’s until Immunity decided to buy the source codes to OllyDbg in order to fix and improve it, under the new name Immunity Debugger. Today it seems to be mostly replacing the good old Olly, especially when it comes to exploit development which is where the focus is set for most of the new features and plugins.

So what’s the catch? Well, it turns out most of old Olly’s plugins don’t work anymore. However, if you have their sources you can update them, even make them work in both debuggers. If you don’t things get a bit hairy, although there’s a tool out there that helps quite a lot.
Today’s plugin works correctly under both debuggers, of course. :)

What’s this plugin for?

OllyDbg has been around for some time now, and it’s beginning to show its age. ;) One of it’s low points right now is it’s (rather lack of) Win32 API help support.

I’ll explain. When you’re reversing a binary on Windows you’ll tipically see a bunch of assembly code with Win32 API calls in between. The Win32 API is the low level interface for user-mode applications, so deep down inside, it all boils down to these function calls. There are simply too many of them and it’s impossible to memorize them all, so it’s necessary to consult the Microsoft documentation to know what they do, what arguments they expect, etc.

Now, OllyDbg had always allowed you to consult the documentation thanks to a nifty file called “WIN32.HLP” that was shipped with the SDK for Windows NT, and it contained the most up to date and detailed version… back then. But many OS versions and years went by, Microsoft stopped shipping that file since the new MSDN (Microsoft Developer Network) was all the rage, and what happens now when you try to use the OllyDbg help is that half the times the API you’re looking for doesn’t show up in the help file. :(

This plugin is meant to fill that void. After installing it, when OllyDbg tries to open WIN32.HLP to show the help, the plugin steps in and launches the default web browser instead, pointing it to the corresponding page in MSDN Online. :)

How to install this plugin?

It’s easy, just download the zip file, extract the plugin (OllyMSDN.dll) and copy it to the debugger’s program files folder. For OllyDbg this is tipically “C:Program FilesOllyDbg” and for Immunity Debugger it’s “C:Program FilesImmunity IncImmunity Debugger”.

The next step is to run the debugger, go to the menu “Help” and click on “Select API help file”. Then we have to select the old WIN32.HLP file, or at least any other file as long as it has the exact same name (it’s not going to be used anyway). The name matters because it’s the way the plugin can tell Olly is trying to load the Win32 API help and not just any other help file like, say, the user manual.

Once you’ve done this, the plugin is ready to use.

How to use this plugin?

It’s used just like the good old WIN32.HLP file. That is:

To show the Microsoft documentation, go to the “Help” menu and click on “Open API help file”.

To see the help for an API call in particular, right click on the assembly code line with the function call in the CPU pane and go to “Help on symbolic name”.

Where do I get this plugin?

You can purchase it online with your credit card… nah, no way! It’s 100% free of course! :)

Follow this link to download: OllyMSDN.zip

The zip file contains the precompiled Windows binary and the complete source code under GPL v2 license. The sources compile with Visual Studio 2008, I haven’t tried other compilers.

Well, that’s it for today. Enjoy! :)


Follow me on Twitter: @Mario_Vilas | Linkedin: http://es.linkedin.com/in/mariovilas

Page 1 of 41234»