Posts Tagged ‘0day’

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