sábado, 17 de enero de 2015

Resolviendo el segundo reto de Amateria


Segundo reto relacionado con el wargame Amateria. En este caso se nos presenta un código en C (que divertidos son los segmentation fault :D).



El archivo del ejercicio luce así:


En el código podemos ver el método principal (main) y una función llamada flapmud. Para llegar a la función tenemos la siguiente línea:
signal(SIGSEGV, flapmud);
 Signal captura una señal SIGSEGV y entonces lanza la función antes mentada. Ésta ejecutará un GDB con los permisos propios del usuario 2 y entonces se podrá leer el archivo del password.

¿Qué es SIGSEGV?
Es un fallo de segmentación de toda la vida, esos que cuando empezabas a programar en C/C++ has visto miles, ¡ESOS!.

¿Cómo hacemos que salte?
Habiendo varias formas para lograrlo, en un principio pensé en lanzarlo con algún depurador, poner un breakpoint y lanzarle una señal (kill -11 pid) para que saltase, pero GDB por seguridad no permite el cambio de usuario sin ser root, así que descarté dicha forma.

Siendo, como he dicho antes, C/C++ los lenguajes con los que he visto cientos de segmentation fault, mediante uno de los diversos métodos de ejecución de otros programas que tiene, busqué como ejecutar este para que lanzase la señal buscada. Al final llegué a execve. Con una pequeña modificación del ejemplo que se proporciona en el enlace, es posible, pasando parámetros nulos ejecutar un fallo de segmentación y que se lance un GDB perteneciente al usuario del siguiente nivel:


Basta con pasarle el ejecutable (lolgdb) al programa y se lanzará una terminal del GDB. Aquí, mediante el comando shell es posible hacer un cat del fichero con el password:




Como siempre, los códigos se encuentran disponibles en el GitHub de 0verl0ad (directorio PornAetsuWargames):
https://github.com/0verl0ad/PornAetsuWarGames/tree/master/amateria


Un saludo y "nos leemos en breve",


5 0verl0ad Labs: enero 2015 Segundo reto relacionado con el wargame Amateria . En este caso se nos presenta un código en C ( que divertidos son los segmentation fault...

domingo, 11 de enero de 2015

Gorosaurus II: wp-knockout

¡Saludos!

    Como ya dije en la serie "The Walking WordPress", los plugins de seguridad que realizan funciones de monitorización de ficheros son absolutamente inútiles, puesto que si el atacante tiene acceso a la base de datos  y puede modificar archivos,  neutralizar cualquier plugin es trivial.

   Expliqué -y mostré partes de código- en este post The Walking WordPress I: defeating security plugins cómo con un par de líneas podías dejar K.O. cada uno de los plugins más famosos de WordPress. Ahora para Gorosaurus  he recogido esas mismas triquiñuelas relacionadas con la alteración de la base de datos, las he actualizado para que funcionen con la última versión de cada plugin, y las he puesto todas en un mismo fichero que he bautizado como wp-knockout.php.

     Simplemente hay que colocar el contenido del fichero dentro del archivo akismet.php (es decir, del plugin Akismet). Para ello podemos, desde el cliente en perl, descargarnos el fichero, lo editamos para añadirle el código de wp-knockout, y lo volvemos a subir al servidor.


    Pero... ¿y si no tenemos permisos de escritura para poder editar el archivo? :)

      Aquí viene la magia de WordPress al rescate: por defecto los usuarios con rol administrator pueden editar el contenido de los ficheros de plugins desde el panel de administración. Esto significa que si cuando estás realizando un pentest y consigues colar una webshell en un WordPress, pero tienes todas las vías capadas en cuanto a permisos -pero puedes ejecutar la webshell- símplemente debes de añadir un usuario con rol administrator usando las propias funciones de WordPress.

      En nuestro caso con gorosaurus podemos hacerlo ejecutando "wp_add_admin". Despues nos logueamos con el usuario creado y podremos editar cualquier archivo que pertenezca a un plugin. Una vez que hemos acabado de editar, usamos "wp_delete_user" para eliminar el usuario.

   Para deshabilitar que los administradores puedan editar archivos desde el panel de control hay que fijar el valor de la constante DISALLOW_FILE_EDIT como "true" en el archivo wp-config.


Byt3z
5 0verl0ad Labs: enero 2015 ¡Saludos!     Como ya dije en la serie "The Walking WordPress", los plugins de seguridad que realizan funciones de monitorizació...

lunes, 5 de enero de 2015

Resolviendo los retos de io.smashthestack.org con radare2 [8]

Level 8


       Vemos el codigo fuente. En la clase "number" hay una función (setAnnotation) que realiza un memcpy, limitado al tamaño de "a". Si miramos
más abajo en el código vemos como esta función es utilizada con el primer argumento que nosotros le pasamos al programa. Por lo tanto
nosotros podemos controlar el tamaño de "a", y en consecuencia podemos hacer que se copie un tamaño de bytes superior al de "annotation",
teniendo como consecuencia un overflow. Siendo C++, y viendo el percal, esto huele a que vamos a tener que trabajar sobre la virtual table. Lo primero, como siempre, es leer un poco ( https://defuse.ca/exploiting-cpp-vtables.htm ).

     Una vez que hemos leído sobre el tema, desempolvamos radare2 y nos ponemos con la faena. Hacemos r2 -d "./level08 AAAA" y empezamos a otear
por el desensamblado de la función main.




      Lo primero que me llamó la atención fue la función "Znwj" (que aparece señalada en la imagen de arriba). Al googlear llegué a este interesante artículo (http://resources.infosecinstitute.com/reverse-engineering-structures/). Esta función se encarga de crear una nueva estructura
en el HEAP, siendo el 108 el tamaño de dicha estructura. Mirando el desensamblado, podemos teorizar que en el HEAP nos vamos a encontrar algo tipo:

[Dirección donde está la vtable][108 bytes][Dirección donde está la vtable][108 bytes]
                     "five"                                                                         "six"

     Por lo tanto, la hipótesis inicial de cómo realizar la explotación sería colocar un shellcode en una variable de entorno, introducir 108 bytes de basura como argumento, y a continuación la dirección donde tenemos los NOPs + shellcode. De esa forma sobreescribiremos "six", haciendo que en vez de apuntar  a la vtable apunte a nuestro código. Así, pues, lo primero que deberemos de hacer es confirmar nuestra primera hipótesis. Buscamos en qué
dirección está la vtable, para ello desensamblamos sym._ZN6NumberC1Ei:


      En la parte resaltada vemos que la dirección es 0x80488c8. Pongamos un breakpoint cuando se llama a la función SetAnnotation (db 0x0804871b) y veamos que se cuece en la pila (dc):



    Miramos el dump de la dirección que hay en el registro ESP y vemos una dirección que huele a HEAP (0x0804a008). Echémosle un ojo:
     ¡Premio! Es exactamente lo que habíamos deducido previamente. Encontramos 0x80488c8 (que es la dirección de la vtable) + 108 byes [ esto corresponde a "five", y otra vez la vtable + 108 bytes [esto correspondería a "six"]. Let's break all the things!



   Un rico sigsegv, y si miramos la dirección que habíamos visto antes (0x0804a008) vemos que efectivamente hemos triunfado:


    Ahora sólo queda hacer un exploit efectivo. Como siempre metemos shellcode en una variable de entorno, sacamos donde está y leña al mono.


 

    Pues no... fiasco. Al parecer en algún punto EIP va a tomar el valor de parte de nuestro shellcode y da un sigsegv (¡se nos ha olvidado la dereferencia!). Si miramos la estructura del HEAP, vemos que ha quedado tal y como queríamos:


      Lo que deberemos de hacer es sustituir los 4 primeros NOPs por la dirección del inicio de los NOPs + 4, de tal forma que en EIP en vez de tomar el valor 0x90909090, tome el de la dirección donde continúan los NOPs. Problema: que como nosotros éramos más chulos que un ocho del revés, lo de usar una variable de entorno se nos jodió (casi puedo oir desde aquí las risas de Zlowram a mi costa). Tiremos de la opción que debiéramos haber elegido desde el principio: colocar el shellcode en "five" (es decir, en el propio argumento que le pasamos).

       En 0x0804a008 + 4 (0x0804a00c) estaría el inicio, por lo que ahí deberíamos de poner la dirección donde van a empezar nuestros NOPs (recordad lo dicho antes), y esa dirección sería 0x0804a008 + 8 (0x0804a010). Por lo tanto, el objetivo final del exploit será que donde antes estaba la dirección de la vtable ahora esté 0x0804a00c.

          Explicado de forma simplificada: pisamos la dirección de la vtable, la ejecución salta hasta 0x0804a00c que contiene la dirección donde empiezan los NOPs (0x0804a010), se hace la dereferencia, y la ejecución salta hacia 0x0804a010, que es donde empiezan los NOPs.




Byt3z!


5 0verl0ad Labs: enero 2015 Level 8        Vemos el codigo fuente. En la clase "number" hay una función (setAnnotation) que realiza un memcpy, limitado a...

domingo, 4 de enero de 2015

Gorosaurus I: introducción

¡Saludos!

     En estas fechas, entre comida y cena familiar amenizada con alcohol después de los postres, me surgió la necesidad de utilizar una webshell. Como no tenía ninguna a mano en ese instante empecé a codearme una sencillita que supliera las necesidades que tenía en ese momento. Básicamente necesitaba moverme entre directorios, subir y descargar ficheros, dumpear las bases de datos, y como es lógico ejecutar comandos del propio SO.

      Al día siguiente, mientras me recuperaba del cubata overflow, le añadí un par de detalles más y es la versión que voy a subir ahora mismo a GitHub. Es una versión bastante primitiva, que iré puliendo en esta semana que estoy libre, a la que iré añadiéndole más funcionalidades.

      La webshell, Gorosaurus -el nombre de Ethylic WebShell quizás hubiese sido más correcto dadas las circunstancias de cuando la hice-, consta de un archivo PHP que es el que se acaba subiendo al servidor y de un script en PERL que actúa como cliente para la comunicación. Dicha comunicación se establece enviando la contraseña y los comandos a ejecutar a través de cabeceras HTTP que deberemos de definir previamente. De esta forma en un análisis preliminar no debería de verse en los logs habituales, ya que únicamente vería peticiones GET hacia el archivo -en el siguiente capítulo hablaremos de como camuflar esto también-.

     Una vez que hemos definido los datos principales (contraseña, nombre de la cabecera HTTP que contendrá la contraseña y el comanod a ejecutar) y hemos subido el PHP al servidor con el que estamos trabajando, procederemos a conectarnos desde el script cliente:


    Estando "logueados" de forma correcta podremos empezar a interaccionar con el PHP. Le he añadido algunas funciones relacionadas con WordPress que, junto con un script que publicaré en siguientes capítulos para hacer knock-out a los plugins de seguridad, explicaré más detalladamente en el próximos capítulos. En este caso podemos ver como con el comando "server_info" se muestra información genérica del servidor y con "db_credentials" se busca el archivo wp-config.php para exponer los credenciales.



  El listado de funciones -que ampliaré esta semana- que admite ahora mismo son éstas:




   Algunos ejemplos de funciones: db_list (lista aquellas bases de datos a las que tiene acceso el usuario actual) y db_tables (lista las tablas de una base de datos dada)


    De forma automática la webshell busca el archivo wp-config.php para cargar de él los credenciales y así interactuar con la base de datos. En caso de que no se trate de un WordPress, o de que queramos entrar con otro usuario o pivotar hacia una DB alojada en otro servidor (imaginemos que hemos encontrado un archivo config.php y queremos acceder con esos datos) podemos indicar esos credenciales usando la función "db_def_credentials".

    Para navegar y realizar operaciones con los ficheros deberemos de entrar en el modo "browser". Al entrar en este modo, la primera vez deberemos de ejecutar "pwd" para que el script tome como punto de referencia el path actual donde se encuentra la webshell.


  Actualmente el modo browser soporta estas funciones -también serán ampliadas durante esta semana-.
 

    Y la ejecución de comandos en el servidor remoto, como si de una consola se tratase, podemos hacerla entrando en el modo "terminal". Este modo nos pedirá con qué función ejecutar los comandos. Para ver qué funciones tenemos disponibles podemos valernos de "allowed":





     Los dos scripts se encuentran en el GitHub del blog ( https://github.com/0verl0ad/gorosaurus ), y como ya digo, será documentado -y ampliado el código - más en profundidad durante esta semana.  Además colgaré un par de scripts interesantes para cuando toque penetrar WordPress.

Byt3z

5 0verl0ad Labs: enero 2015 ¡Saludos!      En estas fechas, entre comida y cena familiar amenizada con alcohol después de los postres, me surgió la necesidad de utili...
< >