Mensajes

Un último detalle sería decir que para comprobar si funciona correctamente, sería mejor declarar una función que no se llamase en el programa, y hacer que se ejecute con el retorno. P. ej:
1. Dirección de func_oculta () = 0x08005f32
2. Ret-Buff = 32
$ perl -e 'print "\x90"x32 . "\x32\x5f\x00\x08"'

Hey Iván! Que tal?

Es una buena idea. Sagrini is back ! todo bien , vos?

Pero me refiero:

La dirección que escoge el compilador, es una dirección que al final en memoria no va a ser esa, si no que va a ser totalmente diferente, dependerá de la memoria libre etc etc etc.

Mi duda es, puesto que el SO al final abstrae la memoria para el programa de manera que el cree que tiene toda la memoria del mundo, aunque en realidad tenga sus cachitos en cada cacho de memoria y no se corresponda con sus direcciones, al final las direcciones del compilador son las que usa en esa memoria virtual???

Al final lo unico que ves son las virtuales. Tendrias que correrlo en gdb y depurarlo con si para ver bien a donde vas a parar y si  sobreescribis bien el ret.

Cómo coño va  afuncionar, esa dirección que saca el gdb, no tiene por qué coincidir con la que haya en tiempo de ejecución, no???

Si, esa direccion es la misma, esta en duro en la cabecera del ejecutable. Lo que te puede cambiar es la dir de la pila.

Código (bash) [Seleccionar] Expandir

readelf -S a.out | grep .text

Muy bien, esta es la salida del gdb:

Código [Seleccionar] Expandir


Dump of assembler code for funcion main:
0x080483d2 <main+0>: push %ebp
0x080483d3 <main+1>: mov %esp,%ebp
0x080483d5 <main+3>: call 0x80483b4 <return_inpu>
0x080483da <main+8>: mov $0x0,%eax
0x080483df <main+13>: pop%ebp
0x080483e0 <main+14>: ret


Entiendo que habría que lograr escribir la dirección 0x080483d5 que es donde se hace la invocación a return_input y para ello emplearía :
\xd5\x83\x04\x08

Tenes que poner la dir justo despues del call, la 0x080483da.

Saludos !

en cual debería de buscar las direcciones?

Podes buscar direcciones donde quieras, siempre y cuando sean ejecutables obvio. Ya sea en lib externas (propias al programa o de sistema) o dentro de la sección .text del programa. La sección ejecutable del proceso es estatica, la direccion virtual a donde se carga esta indicada en la cabecera del exe (PE). Lo mismo sucede con las libs proprias del programa. Por lo que buscar RETs ahi es de lo mas fiable que podes encontrar. Si usas libs de sistema, las direcciones pueden variar como te decia.
Digamos que de preferencia, deberias buscar dentro de todas las secciones ejecutables que aporta el programa. Luego ver por las del sistema.

Otra pregunta...

Estoy tratando de reproducir el exploit CesarFtp 099g en un lab que me he montado, y no veo que el programa tenga algún fallo.

probandolo instalado en un win xp el programa falla pero en un windows 7 no lo hace.

tiene algo que ver aqui el so?

Ni idea, tendria que probarlo. Es probable que sea por las protecciones en 7. Hay ciertas protecciones que en XP estan desactivadas por defecto.

Hola rockhound,

Todo depende de donde estes tomando la direccion de retorno. Si te basas en las librerias del sistema, te va a variar entre service packs _y_ versiones de windows. Inclusive tambien depende de la libreria, por ejemplo la msvcr71.dll no varia de direccion entre las versiones 2003/XP/Vista/7. Es mas, tampoco es compatible con ASLR ni DEP !
He visto varios browser exploits que tratan de cargarla para usarla de trampolin

No soy un experto en JBoss y ni siquiera lo conocia pero si entras en la pagina oficial (jboss.org) te tiran un alerta de seguridad importante que esta usando actualmente un worm para propagarse.
:http://community.jboss.org/blogs/mjc/2011/10/20/statement-regarding-security-threat-to-jboss-application-server

Fijate en el primer comentario, el usuario puso el request que genera el worm para explotar el error. Te deberia servir como para arrancar.

Saludos

Entonces debo compilar con un sistema de 32 para un sistema de 32? Creía que eso se podía solucionar con el compilador, diciéndole que compilará para 32bits en vez de 64.

Podes compilar para 32 (-m32) o 64 (-m64) en cualquier maquina siempre y cuando el compilador lo soporte.
Tenes un cpu de 64 pero seguro estas corriendo un linux de 32 por eso no tenes las libs y los headers de 64. Fijate si vienen en el paquete build-essential.

Edit: El exploit es para 64 bits asi mismo si lo compilas bien, no lo vas a poder correr en tu maquina. Proba con un live cd linux x86_64 sino.

Si buscas en google vas a encontrar que el header forma parte de la glibc de 64 bits. Si tenes un procesador de 32 no te sirve de nada compilar ese exploit, no vas a poder ejecutarlo. Podes saberlo viendo si tenes el flag "lm" (long mode 64bits) con:

Código (bash) [Seleccionar] Expandir

grep flags /proc/cpuinfo

r8 esta en las arch de 64 bits.

Código (bash) [Seleccionar] Expandir

gcc half-nelson.c -o half-nelson -lrt -m64

Si, es normal esos warnings.

Gracias por la explicación, por cierto, si el kernel es también 4096 en la otra máquina debería funcionar?

Bueno deberia, el problema que podes llegar a tener es con las libs dinamicas. Probalo nomas, como mucho se bloquea la maquina. Reinicias y listo.

Tenes que tener el source de tu kernel. Si es ese error solamente, podes fijarte el tamano de pagina virtual que tenes con

Código (bash) [Seleccionar] Expandir

getconf PAGESIZE

A mi por ejemplo me da 4096. Despues de los includes agrega el define y listo!

Código (cpp) [Seleccionar] Expandir

#define PAGE_SIZE 4096

Si queres probar el exploit en otra maquina, vas a tener que recompilarlo. Si son ubuntu las dos maquinas puede ser que funcione, tendrias que probarlo.

EDIT: ah y saca el include de page.h

Saludos