Exploiting básico (Buffer Overflow) [Ayuda]

[d00rt]

Lo siento .:UND3R:. y bueno a todos los que me habéis ayudado o aportado cualquier posible pista, ya solucione el problema, pero ando con la universidad bastante liado y ahora mismo no tengo tiempo para contestar, pero en cuanto pueda, escribo como resolví el problema.

Basicamente lo que pasaba es que cuando ejecuto con el gdb el programa, el gdb utiliza unas posiciones de memoria distintas a cuando lo ejecuto sin el gdb, ahora mismo no recuerdo como lo hacia (porque la solución no es que se me ocurriera a mi) pero cogía la dirección de ESP, ahora no recuerdo en que momento, y lo restaba con otra dirección que tampoco recuerdo cual ahora y después a la dirección que me daba ESP al ejecutarlo sin el gdb le restaba ese offset y era la dirección que necesitaba, a lo largo de esta semana subo exactamente como solucione el problema

Mil Perdones!

[SteelHern]

El problema es que están siendo muy cuadrados, la ing. Inversa junto con el exploiting es un arte de flexibilidad, debes moldearte al problema, al programa, al entorno, al sistema operativo.

El modo teórico es el siguiente:
- Encontrar en que zona se produce el desbordamiento:
luego de llamar a la función strcpy();

- Luego que sabes en donde está el problema, debes saber cuantos bytes copiar:
Usas un generador de patrones únicos y lo lanzas para ver que valor toma EIP (error al ejecutar dirección 0xXXXXXXXX) es ahí en donde debes calcular el desplazamiento.

- Con eso debes poner la dirección de que ejecutar, en este caso la dirección de la shellcode que puede ser al principio del overflow.

El problema es que me esta alojando el contenido del buffer en una parte muy baja de la pila, con un monton de cosas encima, entre ellas el EIP. Ya puedo hacer todo el overflow que quiera que es imposible que sobreescriba la dirección de retorno. Supongo que esto tendrá que ver con el mecanismo de aleatorización de direcciones de memoria, que aunque estoy tomando medidas para evitarlo, por lo visto no estan funcionando.

[.:UND3R:.]

Pareciera que fuese el mecanísmo de stackshield, no es ASLR pues no cambia el orden de las variables locales de una función, me imagino que compilaste el exploit bajo los parámetros utilizados en el libro, adicionado que la desactivación de ASLR se presenta en las 1eras páginas del libro, saludos.

[d00rt]

Pareciera que fuese el mecanísmo de stackshield, no es ASLR pues no cambia el orden de las variables locales de una función, me imagino que compilaste el exploit bajo los parámetros utilizados en el libro, adicionado que la desactivación de ASLR se presenta en las 1eras páginas del libro, saludos.

.:UND3R:. no se si te refieres a lo mio o a lo de SteelHern, pero lo mio creo que no tiene nada que ver con ningun mecanismo de proteccion (que yo sepa) ya que desactivo todo tal cual dice en el libro (lo de randomize), y las direcciones del programa al ejecutarlo con gdb siempre me da las mismas, y una vez que encuentro sin gdb la direccion de memoria del inicio de la variable, siempre es la misma y siempre puedo explotar la vulnerabilidad

[.:UND3R:.]

.:UND3R:. no se si te refieres a lo mio o a lo de SteelHern, pero lo mio creo que no tiene nada que ver con ningun mecanismo de proteccion (que yo sepa) ya que desactivo todo tal cual dice en el libro (lo de randomize), y las direcciones del programa al ejecutarlo con gdb siempre me da las mismas, y una vez que encuentro sin gdb la direccion de memoria del inicio de la variable, siempre es la misma y siempre puedo explotar la vulnerabilidad

Hola d00rt, no me refería a ti jaja saludos

[d00rt]

Bueno pues ahora que he tenido algo de tiempo y con motivo de ayudar a cualquiera que este intentando resolver este ejercicio, o que este teniendo los mismos problemas que yo, he creado este documento en el que explico poco a poco, como he ido resolviendo el problema. Seguramente se pueda explicar de mejor forma, pero tampoco tengo todo el tiempo del mundo digamos que es una primera versión la cual se puede ir mejorando algunos aspectos o algunos fallos (conceptuales u ortográficos) que se hayan cometido.

Agradecer a todos los que me habéis ayudado a resolver todas mis dudas y hasta la próxima.

Como no puedo adjuntar el documento (O no esta la opción o no la veo) dejo un enlace de google Drive desde donde os lo podéis descargar:

https://drive.google.com/file/d/0B522JOJrz48zcmhkRzJHQkpTQW8/view?usp=sharing

Si veis algún fallo o posible mejora o tenéis alguna duda me comentáis.

[metalerk]

De verdad siento mucho revivir este tema pero soy nuevo en esto también sigo el libro y creo entender la mayoria, pero la verdad es que no entendí porque tienen que ser exactamente 44 "A" como relleno. Les agradecería mucho si me pueden resolver esta duda.

Saludos !!

[furby86]

Buenas, yo también he empezado con el libro de linux exploiting y aunque aun no he probado el script hay un detalle en la página 27 y es que usa ubuntu 12, lo cual, ya puede ser una gran diferencia con la gestión de memoria que puede hacer debian.
Espero no meter la pata. Es solo una sugerencia.