Posts Tagged ‘exploit’

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

Share via email
Share on Facebook+1Share on Twitter

Publicamos un 0-Day de InterScan Web Security Suite (IWSS)

Todo empieza en una tarde de auditoría. Después de un buen plato de callos uno se siente especialmente inspirado para jugar un poco con cositas tontas y tal vez darle la vuelta a una auditoría un poco sosa.

Buscamos ficheros con setuid bit para root, aunque nunca sale nada… oh wait…
Nos encontramos con: “/opt/trend/iwss/data/patch/bin/patchCmd” debe de ser algún producto comercial, búsqueda rápida y bingo, se trata de un software por parte de TrendMicro.

5 minutos de objdump (lo único que había instalado en la máquina a auditar) fueron suficientes para encontrarse con uno de esos fallos de seguridad y programación dignos de los 90′

Básicamente permitiría a un atacante (o un admin que se olvidase su clave de r00t, por ejemplo) obtener acceso con super usuario al sistema. A continuación una imagen de la reunión con el cliente al explicarlo.

Ahora al trapo, vamos a explicar un poco de que va todo esto:
Como se puede observar en esta imagen, el binario “patchCmd” tiene setuid de root con ejecución para todos los usuarios. ¡Esto huele a victory!

Descompilamos el binario, y ¡bazinga! el binario realiza un “setuid(0)” luego un “setguid(0)” y encima para terminar de rematar el evidente pwn3d que se avecina, nos encontramos un “system()”

Recapitulando, lo que se ejecute con el system tomará permisos de root (no cambia el uid) independientemente del usuario que lo ejecute ya que posee el setuid-bit para este usuario y claro, como no, ejecución para todos, total… It’s free!

El binario llama a dos scripts, en este caso “./PatchExe.sh” y “./RollbackExe.sh” dependiendo de los parámetros de ejecución de “patchCmd”.

Ahora es cuando contamos la historia del señor Mr. Lumbreras que ejecuta los scripts con ruta relativa y encima, con “./” pasándoselo a pelo en un “system()”. Seguramente él pensó que sería la mejor de las maneras, no vaya a ser que lo instalasen en otro PATH y total, como los binarios solo se pueden llamar desde el PWD y tampoco se puede cambiar el PATH (como todos sabemos) es una implementación totalmente segura.

Para explotar esta vulnerabilidad a modo de prueba de concepto creamos un script en el PATH de un usuario sin privilegios que simplemente abriría una nueva Shell.

Se ejecuta el binario con los parámetros adecuados para componer la cadena de ejecución y se escalan privilegios al ejecutar una Bourne Shell con el usuario “root”.

A modo de “disclaimer” tenemos que decir que esta vulnerabilidad fue reportada a Trend Micro el día 28/06/2011 y ya son cuatro meses sin respuesta por parte del proveedor, por este motivo publicamos el presente 0-day, que aunque evidente dedicando 5 minutos a ello (no es nada del otro mundo, la verdad) puede llegar a ser una brecha de seguridad muy importante. Con esto no queremos propiciar nuevos ataques ni que nadie la líe parda, sino concienciar sobre la importancia de la seguridad.

Sed chicos buenos y leer el advisory oficial en la siguiente url:
Trendmicro IWSS 3.1 privilege escalation

Salu2.

All Your Base Are Belong to Us!

Share via email
Share on Facebook+1Share on Twitter

Mejorando la seguridad de irssi

De las vulnerabilidades de cliente, la que más morbo tienen suelen ser las de cliente IRC, porque puedes hacer cachondeo entre los colegas en las salas de irc que frecuentas.
En linux, hay dos clientes de irc de modo consola muy utilizados, yo también he usado ambos y he scripteado un poco sobre ellos, se trata de BitchX e Irssi.

Hay que tener en cuenta, que de las vulnerabilidades en lado cliente, las de IRC, Jabber y Messenger son especialmente peligrosas, ya que no es como en el navegador, que han de visitar tu web para lanzarles el exploit. En IRC pueden ir directamente a por tí.

Voy a presentar en este post, tal como dirían los colegas de 48bits, un “0day de llorar“, porque sus vías de explotación son rebuscadas:

En el 2004 descubrí por casualidad un stack overflow en BitchX, aqui pueden ver el exploit:
http://www.badchecksum.net/code/exploits/put4.c

Lo gracioso es que en aquella época no era muy popular la técnica de guardar la shellcode en el environ para predecir su dirección exacta, (el nopear se va acabar pensé …)
Realmente, al ser una vulnerabilidad local, de un binario no setuidado, pues realmente era de llorar, bueno en realidad yo lo tenia setuidado por error y en mi maquina si era una vulnerabilidad peligrosa :)

Creo que a partir de entonces empecé a usar irssi, estaba mejor programado.

Irssi ofrece una API bastante interesante que permite hacer toda clase de bots, bruteforcers de passwords de canales, o cualquier cosa que puedas imaginar.
El otro día estaba scripteando un código que se conecta a múltiples serividores IRC y brutea el password del canal, tropecé con una vulnerabilidad de derreferencia a puntero nulo.

Una vía de ataque es la api: Irssi::server_create_conn(evil,1”,’aa’,”); aunque no descarto que el comando /server de toda la vida, tenga algún flag o incluso que el servidor remoto nos indique el flag.

La cuestión es que el primer parámetro (evil) es el chat_type, y que si contiene un valor incorrecto las consecuencias es un call a una derreferencia nula.En realidad la vulnerabilidad no está en la API, sino en el core, concretamente en la función create_addr_conn() ubicada en: ./src/core/servers-setup.c

En la siguiente lina, se inicializa la estructura proto (_CHAT_PROTOCOL_REC)

proto = chat_type >= 0 ? chat_protocol_find_id(chat_type) :
chat_protocol_get_default();
conn = proto->create_server_connect();

En la estrucutra proto, concretamente en el offse 0×20 tenemos el callback: create_server_connect()

struct _CHAT_PROTOCOL_REC {
int id;

unsigned int not_initialized:1;
unsigned int case_insensitive:1;

char *name;
char *fullname;
char *chatnet;

CHATNET_REC *(*create_chatnet) (void);
SERVER_SETUP_REC *(*create_server_setup) (void);
CHANNEL_SETUP_REC *(*create_channel_setup) (void);
SERVER_CONNECT_REC *(*create_server_connect) (void); <----- evil callback
void (*destroy_server_connect) (SERVER_CONNECT_REC *);

SERVER_REC *(*server_init_connect) (SERVER_CONNECT_REC *);
void (*server_connect) (SERVER_REC *);
CHANNEL_REC *(*channel_create) (SERVER_REC *, const char *,
const char *, int);
QUERY_REC *(*query_create) (const char *, const char *, int);
};

Pues como os imaginareis, la llamada chat_protocol_find_id(evil_chat_type) retorna un nulo, porque se cumple:

g_return_val_if_fail(id > 0, NULL);

El momento de explotación será el siguiente:

0x80daccc: call 0x80ca2d0
0x80dacd1: mov %eax,%edx <--- eax and edx will be null
0x80dacd3: mov %edx,-0x24(%ebp) <---- save edx
0x80dacd6: call *0x20(%edx) <----- call [0x00000020] It will jump to the address dereferenced on 0x00000020

Si mapeamos la dirección 0×00000000 y colocamos en 0×00000020 la dirección de donde tenemos la shellcode, esta será ejecutada.
La primera limitación es que 0×00000000 está restringida por el kernel, concretamente desde la funcion access_ok().
Casualmente esta función puede ser vulnerada con un clone: CVE-2010-4258
Aunque consigamos mapear esta dirección, sería una explotación local, ya que no podemos aprovechar ningún clone que ya tenga el Irssi.
Entocnes tenemos otra fuking local vulnerability de un no-setuid :/ no obstante es un caso didáctico.
Una forma de epxlotar esto, es hacer un Irssi plug-in, que tenga la shellcode en pila, que haga el bypasser clone, y desde el thread, que escriba la dirección de la shellcode en 0×20, y por último, la llamada a Irssi::server_create_conn(1,1,”,”,”);

Pero vamos, puestos a pasar un evil-plugin a alguien, para eso hacemos un exec() directo que irssi lo permite.

Conclusión: Para encontrar vulnerabilidades en software que es muy utilizado y que lleva muchos años existiendo, hay que rebuscar la funciones menos utilizadas, para evitar así el “natural fuzzing” por ejemplo la sycall open() se llama tantos millones de veces que el “natural fuzzing” hace que los bugs de concurrencia hayan salido ya.

Todo lo comentado ha sido reportado oficialmente a los creadores de Irrsi.

Share via email
Share on Facebook+1Share on Twitter

Nueva publicación de exploit: Joomla Scan

Recientemente, Jesús Olmos, uno de nuestros expertos en antifraude, publica en nuestra web, un script en python que contiene una agrupación de exploits públicos, los cuales, intentan explotar 58 vulnerabilidades de Joomla. Dichos exploits se basan en el método de RFI (Remote File Inclusion), el cual consiste en inyectar un código PHP remoto, que otorga acceso directo al sistema. Este scan ha tenido mucha repercusión en el ámbito de las redes sociales, siendo enlazado en númerosas cuentas por usuarios particulares.

Enlace: http://www.buguroo.com/exploits/joomScan.py

Share via email
Share on Facebook+1Share on Twitter