Posts Tagged ‘exploits’

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

Share via email
Share on Facebook+1Share on Twitter

Análisis de vulnerabilidad y exploit para CVE-2011-4130 en ProFTPd < 1.3.3g/1.3.4 – (Parte I)

Introducción

En este artículo vamos a explicar los detalles de la vulnerabilidad CVE-2011-4130 basándonos el advisory oficial.

La finalidad de este artículo es permitir al lector poder reproducir la excepción de violación de segmento mediante la cual es posible tomar el control de la aplicación y ejecutar código tal y como se verá en las siguientes partes de este artículo.

Preparando la mesa de trabajo

La vulnerabilidad afecta a las versiones de ProFTPd anteriores a 1.3.3g ó 1.3.4. Así que vamos a utilizar como servidor de pruebas un Ubuntu Desktop 10.04-LTS, ya que en su repositorio a día de hoy la versión actual es la 1.3.2c afectada por la vulnerabilidad en cuestión.

Para el código fuente de la aplicación, he descargado la 1.3.2e también vulnerable, por lo que nos sirve igualmente.

Explicación de la vulnerabilidad

Tal y como podemos ver en el advisory oficial la vulnerabilidad se produce al manejar incorrectamente el pool de estados para los comandos introducidos por el usuario.

El servidor FTP permite ejecutar acciones solicitada por el cliente mientras atiende nuevas peticiones. Para ello utiliza un pool donde va almacenando la lista de estados sobre los comandos solicitados por el cliente. De esta forma puede llevar un control de las peticiones que le quedan por atender. Cuando recibe un comando, guarda el estado en el pool mientras lo ejecuta y sigue recibiendo comandos del cliente. Una vez finalizan las tareas, el servidor restaura el estado para poder indicar al cliente el resultado y continuar atendiendo más comandos.

El problema sucede al solicitarle una petición, y mientras este la atiende, enviarle otra petición con un comando no esperado, por ejemplo un comando inexistente. En este caso, el servidor sale de una función sin restaurar el estado del pool y la lista de estados queda descompensada, al restaurar el estado anterior a este, la lista esta corrupta y cuando finalmente se intenta acceder al dicho estado se hace sobre un puntero ya liberado, produciéndose el Use-After-Free.

Para más detalles en el código, se puede ver como sucede esto en la función pr_cmd_dispatch_phase():

src/data.c:672

int pr_cmd_dispatch_phase(cmd_rec *cmd, int phase, int send_response) {


pool *resp_pool = NULL;


resp_pool = pr_response_get_pool(); // XXX: Almacena el pool actual

/* Set the pool used by the Response API for this command. */

pr_response_set_pool(cmd->pool); // XXX: Establece el pool a usar


if (phase == 0) { // XXX: pr_cmd_dispatch lo invoca con phase=0

/* First, dispatch to wildcard PRE_CMD handlers. */

success = _dispatch(cmd, PRE_CMD, FALSE, C_ANY);

if (!success)    /* run other pre_cmd */

success = _dispatch(cmd, PRE_CMD, FALSE, NULL);

if (success < 0) { // XXX: Si ha ocurrido un error

/* Dispatch to POST_CMD_ERR handlers as well. */

_dispatch(cmd, POST_CMD_ERR, FALSE, C_ANY);

_dispatch(cmd, POST_CMD_ERR, FALSE, NULL);

_dispatch(cmd, LOG_CMD_ERR, FALSE, C_ANY);

_dispatch(cmd, LOG_CMD_ERR, FALSE, NULL);

pr_response_flush(&resp_err_list);

return success; // XXX: Sale sin restaurar el pool inicial

}


/* Restore any previous pool to the Response API. */

pr_response_set_pool(resp_pool); // XXX: Restaura el pool inicial

return success;

}

Según el código anterior es posible salir de la función apuntando al pool cuyo comando es uno inexistente introducido por nosotros, en lugar de salir apuntando al pool que tenía antes de invocar dicha función. Esto provoca un error al intentar restaurar el pool anterior a este.

Para poder reproducir la vulnerabilidad es necesario llevar al servidor en un estado donde tenga que atender un nuevo comando mientras realiza otras acciones. En un servidor FTP esto puede provocarse al realizar una transferencia de datos, ya sea subiendo información al servidor o bien descargándola de la misma.

Cuando ejecutamos un comando de transferencia de información para descargar (RETR) o para subir información (STOR) la función encargada de manejar dichos datos es pr_data_xfer() que se muestra a continuación. Esta función es la encargada de transferir los datos y de analizar los comandos que hay en el pool de estados para ver si es capaz de atenderlos sin entrar en conflicto con la transferencia actual tal y como se puede ver en el código siguiente:

src/data.c:875

int pr_data_xfer(char *cl_buf, int cl_size) {


     //XXX: Comandos que no pueden ser atendidos durante la transferencia

     if (strcmp(cmd->argv[0], C_APPE) == 0 ||

strcmp(cmd->argv[0], C_LIST) == 0 ||

strcmp(cmd->argv[0], C_MLSD) == 0 ||

strcmp(cmd->argv[0], C_NLST) == 0 ||

strcmp(cmd->argv[0], C_RETR) == 0 ||

strcmp(cmd->argv[0], C_STOR) == 0 ||

strcmp(cmd->argv[0], C_STOU) == 0 ||

strcmp(cmd->argv[0], C_RNFR) == 0 ||

strcmp(cmd->argv[0], C_RNTO) == 0 ||

strcmp(cmd->argv[0], C_PORT) == 0 ||

strcmp(cmd->argv[0], C_EPRT) == 0 ||

strcmp(cmd->argv[0], C_PASV) == 0 ||

strcmp(cmd->argv[0], C_EPSV) == 0) {

pool *resp_pool;


} else if (strcmp(cmd->argv[0], C_NOOP) == 0) {


} else { // XXX: Comandos que si pueden ser atendidos

pr_cmd_dispatch(cmd); // XXX: Atiende el comando


destroy_pool(cmd->pool); // XXX: Destruye el pool

Como se puede ver, si durante la transferencia se introduce un comando inexistente, y pr_cmd_dispatch() sale sin restaurar el pool, como hemos visto anteriormente, en este punto se destruye el pool anterior al que acabamos de atender.

Para provocar la excepción solo necesitamos saber dónde se va a utilizar este pool que ha sido liberado inadecuadamente. Para ello vemos como pr_data_close() que es invocado al finalizar la transferencia hace una llamada a pr_response_add():

src/data.c:616

void pr_data_close(int quiet) {


if (!quiet)

pr_response_add(R_226, _(“Transfer complete”)); //XXX

}

es en esta función, encargada de mostrar el mensaje de transferencia finalizada, dónde se hace uso del pool liberado y se produce la vulnerabilidad Use-After-Free.

src/response.c:143

void pr_response_add_err(const char *numeric, const char *fmt, …) {



// XXX: Vemos como se accede al pool (res_pool) ya liberado

resp = (pr_response_t *) pcalloc(resp_pool, sizeof(pr_response_t));

resp->num = (numeric ? pstrdup(resp_pool, numeric) : NULL);

resp->msg = pstrdup(resp_pool, resp_buf);


}

Para provocar el error, debemos enviar un comando incorrecto cuyos argumentos sean matcheados por el filtro. Para ello debemos consultar la expresión regular que filtra los argumentos antes de enviárselos al comando y así poder formar el comando que buscamos. Esto podemos verlo en el fichero de configuración /etc/proftpd.conf dónde podemos ver la siguiente línea:

/etc/proftpd/proftpd.conf:30

DenyFilter            *.*/

Por ello cualquier argumento que cumpla esta condición, servirá para alcanzar el código vulnerable y provocar la excepción.

NOTA: Es curioso ver como en el código fuente, aparece el siguiente comentario del desarrollador. Lo que indica que eran conscientes de que existía un error aquí. Buscar este tipo de comentarios en el código fuente de las aplicaciones es una manera más de descubrir vulnerabilidades ;D

src/main.c:659

int pr_cmd_dispatch_phase(cmd_rec *cmd, int phase, int flags) {


/* Get any previous pool that may be being used by the Response API.

*

* In most cases, this will be NULL. However, if proftpd is in the

* midst of a data transfer when a command comes in on the control

* connection, then the pool in use will be that of the data transfer

* instigating command. We want to stash that pool, so that after this

* command is dispatched, we can return the pool of the old command.

* Otherwise, Bad Things (segfaults) happen.

*/

Estrategia a seguir

Para poder reproducir la excepción necesitaremos conectarnos al servidor, autenticarnos, y solicitarle un fichero de datos. Durante el lapso de tiempo en que recibimos los datos del fichero debemos introducir un comando no esperado por el servidor.

Para poder hacer esto de manera eficiente, deberemos programar un par de scripts que lo hagan por nosotros. El primero pone a escuchar un puerto superior al 1024, tras recibir la conexión lee 2 bytes, espera 5 segundos para permitir al otro script enviar el comando inexistente y tras ese lapso de tiempo continua recibiendo los datos para finalizar la conexión. Obviamente el fichero solicitado debe existir.

Por otro lado otro script que conecte con el servidor, se autentica, le dice al servidor la IP y el puerto al que debe enviar los datos del fichero y le pida que lo envíe. Tras esta acción es cuando puede enviar el comando inexistente durante los 5 segundos que le permite el primer script.

Script que queda a la escucha para recibir los datos del servidor (dataServerExploitFTPd.py):

http://pastebin.com/Uuk9LwjN

Script que envía los comandos al servidor para provocar la excepción (exploitProftpd.py).

http://pastebin.com/iJAFCd8e

Capturando la excepción

En primer lugar vamos a levantar el servidor ProFTPd y vamos a comprobar que está funcionando. Para ello basta con utilizar un cliente FTP cualquiera y acceder al mismo con las credenciales pertinentes. Para poder provocar la excepción, es necesario crear un fichero en el home del usuario FTP con el nombre ‘nada‘ (este será el fichero a descargar por el exploit) con algunos bytes de contenido. Una vez hemos hecho esto podemos pasar a ejecutar los scripts. Una vez finalizado, podemos ver el siguiente mensaje tras ejecutar el comando dmesg:

usuario@ubuntu:~$ dmesg


[86470.833018] proftpd[5106]: segfault at 10 ip 0000000000415efe sp 00007fff3dcde270 error 4 in proftpd[400000+97000]

Ahora vamos a capturar dicha excepción con el debugger. Primero vemos los procesos activos de ProFTPd:

usuario@ubuntu:~$ ps -aux | grep proftpd

Warning: bad ps syntax, perhaps a bogus ‘-’? See http://procps.sf.net/faq.html

proftpd 2242 0.0 0.1 73968 1932 ? SNs Mar11 0:01 proftpd: (accepting connections)

Cuando se conecta un nuevo cliente, se crea otro nuevo proceso con un id más alto, este es el proceso que nos interesa.

usuario@ubuntu:~$ ps -aux | grep proftpd

Warning: bad ps syntax, perhaps a bogus ‘-’? See http://procps.sf.net/faq.html

proftpd 5595 0.0 0.1 75680 1996 ? Ss 17:17 0:00 proftpd: (accepting connections)

proftpd 5683 0.0 0.2 75680 2684 ? S 17:38 0:00 proftpd: connected: ::ffff:192.168.1.11 (::ffff:192.168.1.11:40222)

Para que nos dé tiempo de hacer todo rápido, vamos a crear un fichero de comandos para GDB (gdbCommands) que inicialmente no existe, con estos dos únicos comandos:

usuario@ubuntu:~$ echo handle SIGSEGV nopass >> gdbCommands

usuario@ubuntu:~$ echo c >> gdbCommands

Ahora vamos a ejecutar el primer script (dataServerExploitFTPd.py) en una shell, abrimos otra shell y lanzamos el segundo script (exploitProftpd.py) y durante el lapso de tiempo que nos da el primer script, abrimos una tercera shell (como root) y ejecutamos el siguiente comando:

root@ubuntu:/home/usuario# gdb –p `pidof proftpd | cut –c’ ‘ –f 2` -x gdbCommands

Con esto nos attacheamos al proceso creado para atender nuestros comandos ftp, y ejecuta automáticamente los comandos del fichero (gdbCommands), lo único que hace es decirle al debugger que no pase las señales de SIGSEGV al programa, ya que queremos que las capture el debugger para analizarlo y luego le decimos que continúe con el proceso. Tras unos segundos finaliza la transmisión de ficheros y podemos ver lo siguiente:

root@ubuntu:/home/usuario# gdb -p `pidof proftpd | cut -d’ ‘ -f1` -x gdbCommands

GNU gdb (GDB) 7.1-ubuntu

Copyright (C) 2010 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law. Type “show copying”

and “show warranty” for details.

This GDB was configured as “x86_64-linux-gnu”.

Para las instrucciones de informe de errores, vea:

.

Adjuntando a process 5713

Leyendo símbolos desde /usr/sbin/proftpd…(no se encontraron símbolos de depuración)hecho.


0x00007f84881defd3 in select () from /lib/libc.so.6

Program received signal SIGSEGV, Segmentation fault.

0x0000000000415efe in ?? ()

(gdb) bt

#0 0x0000000000415efe in ?? ()

#1 0x000000000041700a in pstrdup ()

#2 0x000000000042d927 in pr_response_add ()

#3 0×0000000000450985 in ?? ()

#4 0x000000000042fbc2 in pr_module_call ()

#5 0x00000000004133a6 in ?? ()

#6 0x00000000004139ab in pr_cmd_dispatch_phase ()

#7 0x0000000000414fdc in ?? ()

#8 0x00000000004107ae in ?? ()

#9 0×0000000000412769 in ?? ()

#10 0x000000000041494d in main ()

(gdb) i r

rax 0×0    0

rbx 0x127e130    19390768

rcx 0×0    0

rdx 0×0    0

rsi 0×4    4

rdi 0x127e130    19390768

rbp 0x127e130    0x127e130

rsp 0x7fff81136690    0x7fff81136690

r8 0x47dc02    4709378

r9 0×101010101010101    72340172838076673

r10 0x7f848847e14c    140207198822732

r11 0x7f8488185962    140207195707746

r12 0×4    4

r13 0×69    105

r14 0x7fff811368bc    140735358920892

r15 0xc    12

rip 0x415efe    0x415efe

eflags 0×10202    [ IF RF ]

cs 0×33    51

ss 0x2b    43

ds 0×0    0

es 0×0    0

fs 0×0    0

gs 0×0    0

(gdb) x/8i $rip

=> 0x415efe:    mov 0×10(%rcx),%rdi

0x415f02:    jle 0x415f23

0x415f04:    lea -0×1(%rsi),%r12d

0x415f08:    and $0xfffffffffffffff8,%r12d

0x415f0c:    add $0×8,%r12d

0x415f10:    movslq %r12d,%rbp

0x415f13:    lea (%rdi,%rbp,1),%rax

0x415f17:    cmp (%rcx),%rax

(gdb) set disassembly-flavor intel

(gdb) x/8i $rip

=> 0x415efe:    mov rdi,QWORD PTR [rcx+0x10]

0x415f02:    jle 0x415f23

0x415f04:    lea r12d,[rsi-0x1]

0x415f08:    and r12d,0xfffffffffffffff8

0x415f0c:    add r12d,0×8

0x415f10:    movsxd rbp,r12d

0x415f13:    lea rax,[rdi+rbp*1]

0x415f17:    cmp rax,QWORD PTR [rcx]

Como se puede ver en el código que ha producido la excepción, se intenta acceder al registro RCX cuyo valor es 0.

En el próximo capítulo

Ahora que ya hemos sido capaces de analizar la vulnerabilidad revisando el código fuente y conseguido reproducir la excepción, pasamos a cosas más interesantes, analizar con el debugger como trabajan las funciones que reservan y liberan los pool y de qué manera podemos aprovechar esto para ejecutar código ;D Así que ir preparando vuestro entorno de trabajo que aún nos queda lo más duro.

Follow me on Twitter: @Boken_

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

El equipo de Buguroo descubre 4 Zero Days

El equipo de Buguroo a través de su laboratorio I+D ha descubierto 4 importantes vulnerabilidades en aplicativos web.
Desde su creación, Buguroo ha apostado firmemente por la innovación y el desarrollo, para lo cual ha creado un laboratorio de I+D, dedicado exclusivamente a la investigación y desarrollo en diversos campos de la seguridad informática.
Fruto de estas investigaciones el equipo técnico de Buguroo ha descubierto 4 importantes vulnerabilidades en aplicativos web ampliamente utilizados en Internet. Estas vulnerabilidades afectan a la disponibilidad, integridad y confidencialidad del software en cuestión.

Buguroo se ha puesto en contacto con los fabricantes para apoyarlos en el desarrollo de parches que solventen dichos fallos.
Buguroo porporcionará información pública sobre estas vulnerabilidades cuando los fabricantes implicados publiquen las actualizaciones que solventen las vulnerabilidades encontradas.

La política de Buguroo en este sentido es clara, “el fruto de las investigaciones no perjudicará a terceras partes”. El descubrimiento de nuevas vulnerabilidades se comunicarán en primera instancia, a los fabricantes implicados.

Share via email
Share on Facebook+1Share on Twitter