Una PoC con Scapy para hacer un ICMP Redirect y el ataque MitM del pasado

Aprovechando que ayer anunciamos ya que está disponible nuestro libro de Ataques en Redes de Datos IPv4 & IPv6 (4ª Edición), hoy vamos a hacer algo hacking de redes. En el artículo de hoy vamos a hablar del conocidísimo ICMP Redirect, del que ya muchos sabéis que se puede utilizar para hacer un ataque de red. Podemos decir que es un poco ‘antiguo’ o que a día de hoy no afectará a la mayoría de sistemas que encontremos en un Ethical Hacking, porque vendrá deshabilitado por defecto. Y cierto es, en muchos sitios no lo encontraremos habilitado porque está deshabilitada la opción de aceptar redirecciones ICMP, pero...

Figura 1: Una PoC con Scapy para hacer un

ICMP Redirect y el ataque MitM del pasado

En "El lado del mal" ya hemos hablado de Scapy y su potencia junto a NetfilterQueue para hacer manipulación de paquetes al vuelo u ‘on the fly’. Scapy y NetfilterQueue es una forma de poner en práctica y aprender mucho sobre cómo funcionan los protocolos que forman parte de la pila TCP/IP, por lo que recomendamos que le echéis un ojo para poner en práctica toda la teoría que os puedan dar sobre TCP/IP.

Figura 2: Ataques en redes de datos IPv4&IPv6 (4ª Edición) de

JL. Rambla, ampliado y revisado por Pablo González y Chema Alonso

El artículo tiene un enfoque didáctico de enseñar en qué consiste el ataque y no de ponerlo en valor hoy en día, ya que, como he comentado, seguramente no puedas usarlo en un pentesting. Aunque como todo en la vida, podemos encontrar cualquier cosa en una empresa y cualquier tipo de configuración. Configuraciones heredadas, "legacy" o cómo queramos llamarla, por lo que nunca está de más conocer posibilidades en lo que ataques de tipo ‘Man in the Middle’ se refiere. Si observamos lo que dice evilsocket, creador de Bettercap, quizá una de las herramientas de ataques de red modernos más potente, el ICMP redirect es difícil de encontrar, pero todo puede ocurrir.

Figura 3: Debate sobre ICMP Redirect

Nosotros para este artículo vamos a montar un pequeño escenario y queremos explicar la parte más didáctica. Para ello utilizaremos lo siguiente:

• Máquina atacante: Una Kali Linux 2020, por ejemplo. Lo importante va a ser que tenga Scapy instalado.
• Máquina víctima: Una máquina con Ubuntu GNU/Linux de cualquier versión.
• Red: La red tendrá salida a Internet.

El ICMP Redirect nos permitirá indicar a la máquina víctima que hay una nueva ruta para un tipo de petición. Claro, existen algunas características en los sistemas operativos que intentan protegernos de que alguien pueda llegar y decir: ‘Oye para ir a esta dirección IP ahora tienes que enviarle el tráfico a esta otra dirección IP’.

Figura 4: Pentesting con Kali Silver Edition

A diferencia del ARP Spoofing, en el caso del ICMP Redirect podemos indicar ciertos paquetes o conexiones que deben ser enviadas por un router o por otro. Al final, el ARP Spoofing es más sencillo, pero también generamos más ruido. En ICMP Redirect, con un solo paquete para indicar la redirección podemos estar bastante tiempo con la ruta “envenenada”. Es un riesgo alto. Por ello, debemos conocer algunos conceptos previos en la máquina víctima, observando el fichero /etc/sysctl.conf o desde la ruta /proc/sys/net/ipv4/conf/all/*. Por ejemplo:

• net.ipv4.conf.all.accepts_redirects: Esto tiene que estar a 0, si está a 1 la máquina no aceptará redirecciones por ICMP.

• net.ipv4.conf.all.secure_redirects: Esto estará a 1. Esto quiere decir que una redirección solo será aceptada si viene una dirección de la lista. Es decir, validación de quién pide la redirección.

• En sistemas Microsoft Windows existen claves de registro para verificar esto.

Por la parte del atacante, solo debemos activar el forward en /proc/sys/net/ipv4/ip_forward o en el fichero /etc/sysctl.conf si lo queremos dejar persistente. Es recomendable verificar que no hacemos send_redirects a nivel de kernel, esto se puede verificar en el fichero /etc/sysctl.conf.

Montando el código en Scapy

Para mostrar un ejemplo sencillo de esta implementación, se utilizará Scapy para generar el paquete y poder enviar el ICMP de redirección. Una manera sencilla de verlo será a través del uso del intérprete de Python, que tanto utilizamos los pentesters.

Figura 5: Libro de Python para Pentesters 2ª Edición en 0xWord

escrito por Daniel Echeverry Montoy "Adastra".

La primera capa que vamos a construir es el datagrama IP. Para ello, solo indicaremos la dirección IP origen y la dirección IP destino. Todos los campos necesarios para que el datagrama tenga sentido, serán gestionados por Scapy. Si nos fijamos en la imagen, la dirección IP origen será la del router al que queremos “suplantar”. La dirección IP destino será la de la máquina víctima, en este caso, nuestro Ubuntu.

Figura 6: Construcción del datagrama IP en Scapy

Una vez hemos creado la capa IP y almacenado en una variable, vamos a generar la capa ICMP y la almacenaremos en una variable denominada icmp. La instrucción ICMP(type=X, code=Y) nos permite generar un paquete ICMP de tipo 5, en este caso, el cual indicará el redirect. Se puede ver en la imagen algunos de los tipos de paquetes en ICMP. Son más de los que en un principio seguro pensabas que habría en este protocolo, pero hay que pensar que ICMP es Internet Control Message Protocol, por lo que es un protocolo más importante que utilizarle solo para un ‘ping’.

Figura 7: Vamos al RFC de Tipo 5 Redirect

Bien, después hacemos un icmp.gw = “my-ip”. Asignando mi IP como nuevo Gateway en la notificación del protocolo ICMP. Y ahora viene lo divertido, dentro del ICMP encapsularemos el tipo de peticiones que queremos que la víctima nos reenvíe a nosotros. Es decir, si queremos que cuando la víctima haga un ping (ICMP de tipo 8) a una dirección IP en Internet nos lo envíe a nosotros en vez de al router original necesitamos indicárselo, ¿cómo?

Lo primero es crear una segunda capa IP que irá encapsulada en el ICMP de redirección. En esa capa IP indicamos cuál sería la dirección IP origen de la petición y cuál sería la dirección IP destino de dicha petición. En el caso de que ambas direcciones IP coincidan, se nos enviará a nosotros, pero podemos hilar más fino. Podemos añadir otra capa como, por ejemplo, aparte de controlar la IP origen y destino del paquete, si encima de dicho paquete es ICMP, UDP o TCP lo que se envía. Esto es muy interesante.

Figura 8: Direcciones montadas

Para este ejemplo, generamos un paquete con la primera capa IP y la capa ICMP que definimos anteriormente. Después, dentro del ICMP de redirección le metemos una segunda capa IP dónde le decimos a la máquina Ubuntu que cuando haga ‘match’ la IP origen y destino del datagrama tendrá que enviarlo a nosotros y, además, sea un ICMP de tipo 8, lo que esté encapsulado dentro de ese datagrama IP. Parece lioso, pero es sencillo.

Figura 9: Captura de la PoC en Wireshask

Una vez preparado, utilizamos la instrucción send(packet) para enviar un paquete, según el código presentado antes sería send(p). A la función send la podemos meter en bucle con send(p, loop=1, interval=1), haciendo que cada segundo se envíe un paquete. En la imagen anterior de Wireshark, desde nuestra Kali Linux, podemos ver cómo el mensaje ICMP nos está llegando a nosotros y podemos ver el ping que se hace desde Ubuntu al servidor en Internet. Tenemos funcionando el Man in the Middle.

Figura 10: MitM up & running

Otro apunte por el que podemos ver que nos han ‘envenenado el enrutamiento’ es mediante el uso del comando ip route get [dirección IP]. Como se puede ver en la imagen anterior podemos ver fácilmente que nos han modificado el enrutamiento. Y por tanto estamos sufriendo un ataque. Para evitar este ataque, nuestra máquina GNU/Linux debería estar fortificada, y así evitaríamos que estos esquemas nos pudieran afectar.

Figura 11: Libro de Hardening de Servidores GNU/Linux 4ª Edición

(Revisada y Ampliada) de Carlos Álvarez y Pablo González en 0xWord

Sin duda, cuando trabajamos con protocolos y ataques de red en un Ethical Hacking o en un forense es importante conocer los detalles que hay por debajo, para poder trabajar de forma más eficiente y más potente. Limitarse a ejecutar una herramienta automática está bien, sobretodo cuando se conoce lo que ocurre por detrás. Espero que el artículo didáctico de hoy os llame la atención para ponerse con Scapy a jugar y ver sus posibilidades.

Saludos,

Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters: Gold Edition", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell (2ª Edición)”, "Pentesting con Kali Silver Edition" y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González - Conseguir 100 Tempos Gratis en MyPublicInbox

 Contactar con Pablo González

Cómo construir un medidor ambiental para el CPD con Raspberry Pi [Parte 1 de 2] #RaspberryPi

La seguridad en el mundo de las tecnologías informáticas tienen una importancia brutal en la transformación digital de la empresas.. Cada día aparecen nuevas vulnerabilidades descubiertas por investigadores de seguridad que se han sentido atraídos por el mundo de los hackers y otras descubiertas y explotadas por cibercriminales. El interés por esta disciplina está en auge. Hablamos de seguridad defensiva y seguridad ofensiva y hay que tener en cuenta que la seguridad debe tener presente esfuerzos en todas las partes de Prevencion, de Detección, de Respuesta, y de Recuperación, y que hay que trabajar en todas ellas. Hoy vamos a hablar de una medida que tiene que ver con la seguridad preventiva.

Figura 1: Cómo construir un medidor ambiental para el CPD con Raspberry Pi [Parte 1 de 2]

Yo veo la seguridad preventiva como los sistemas “pasivos” que nos ayudan en el día a día a resguardar la información que deseamos proteger, formando parte de nuestras defensas. En este aspecto tenemos, por ejemplo, nuestros recolectores y secuenciadores de logs, sistemas DLP, etcétera. No es necesario que un cibercriminal nos ataque para poner en riesgo la información o los sistemas que la alberga… una simple caída de nuestro CPD conlleva un incidente de seguridad, dado que, como debemos tener presente, la seguridad de la información significa que tenemos que tener en cuenta los factores de confidencialidad, la disponibilidad e integridad de la misma.

Estos factores debemos cubrirlos de la mejor manera posible y, en ocasiones, podemos hacerlo por un bajo coste de inversión y esfuerzo, simplemente teniendo en cuanta que hay que tomar medidas para evitar esos riesgos controlables.

Figura 2: Arduino para Hackers: PoCs & Hackers Just For Fun

Por ello me he animado a iniciar un pequeño proyecto que quiero compartir con ustedes - y sobre todo para el mundo de los makers - que ya he visto que hay muchos tras ver el libro de Arduino para Hackers: PoCs & Hacks Just For Fun - y con el cual podemos monitorizar nuestro CPD en lo que a humedad y temperatura se refiere. Una vez implementado y usando un poco la imaginación, podemos incluir en el mismo sistemas de detección de movimiento, peso, humo, ruido, relés activadores, etc.

Monitor ambiental de un CPD

Este proyecto puede llevarse a cabo por un precio mínimo de alrededor de 70€ según donde compremos los materiales y un máximo de 170€ si optamos por la versión con TouchScreen.

Materiales

• RaspBerry PI 3 B+
• Tarjeta de memoria MicroSD de 8GB
• Sensor de temperatura y humedad DHT22
• Zumbador

Opcional

• TouchScreen 7” para RPi
• Carcasa para TouchScreen

Figura 3: Carcasa para TouchScreen compatible con Rapberry Pi

La opción de agregar la TouchScreen a nuestra RaspBerry Pi es interesante porque nos permite ver la temperatura y humedad si estamos trabajando dentro del CPD, y por ese motivo he agregado también el zumbador.

Figura 4: Ejemplo del resultado final del medidor en el CPD

Esto lo logramos gracias a Grafana ya que permite tener varios DashBoards y podemos montar uno para una monitorización remota y otro para la monitorización dentro del CPD que es el que mostraremos en la TouchScreen.

Figura 5: Esquema del monitor sin el zumbador

En el esquema del proyecto, que puedes ver en la imagen superior,  no aparece el zumbador dado que es opcional. Pero su conexión es muy sencilla… positivo conectado al GPIO 24 y negativo a GND.

Requerimientos

Este es una proyecto que está basado en Python, así que cuanto más conozcas la potencia de este lenguaje y cómo funcionan las librerías de gestión de los diferentes elementos que tenemos en la arquitectura mejor.

Figura 6: Libros de Python para Pentesters y Hacking con Python
(Esta semana con el 10% de descuento con el Cupón VERANO2019)

Esta es la lista detallada de requerimientos que tenemos que tener en nuestra Raspberry Pi para construirlo.

• Python para la ejecución de scripts
• Liberías y scripts Python para uso con el sensor DHT22
• InfluxDB para el almacenamiento de las métricas recogidas
• Chronograf para la administración de InfluxDB
• Grafana para la explotación de las métricas
• Certificado SSL/TLS (puede ser autofirmado)

Preparación del Medidor

Instalamos Raspbian en la RPi usando el método que prefiramos (Usando noobs o quemando la ISO de RaspBian directamente sobre la SD Card). Una vez hecho, conectamos la RPi a la red y le damos salida a Internet para actualizar todo el sistema con los comandos:

sudo apt update && sudo apt upgrade -y
sudo rpi-update

Cuando comprobamos que el sistema va bien comenzamos am preparar nuestra RPi para la poder realizar la medición. Tendremos que montar el esquema mostrado antes. Tras ello, instalamos algunas librerías de Pyhton y descargamos en nuestra RPi las librerías y scripts para usar el sensor con los siguientes comandos:

sudo apt-get install build-essential python-dev python-openssl -y
git clone https://github.com/adafruit/Adafruit_Python_DHT.git
cd Adafruit_Python_DHT
sudo python setup.py install

Tras esto, podremos lanzar nuestra primera prueba y verificar si el sensor funciona correctamente y/o está bien montado:

sudo python ./Adafruit_Python_DHT/examples/AdafruitDHT.py 22 4

En este caso, el parámetro 22 es el tipo de sensor (DHT22) y 4 es el puerto GPIO donde está conectado el pin “DATA” de nuestro sensor. Si todo está OK, deberíamos obtener una salida como esta:

Figura 7: verificación del sensor

Si no ha sido así, revisa el esquema y los pasos dados hasta ahora. Como podemos ver en el ejemplo, está leyendo correctamente. El sensor DHT22 tiene las siguiente características:

• Rangos de temperatura: -40°C to 80°C
• Rangos de Humedad: 0% to 100%
• Resolución: Temperatura y Humedad son de 16-bit
• Exactitud: Temperatura: ±0.5°C Humedad: ±1%

Este sensor es más exacto que el DHT11

Almacenamiento de métricas

Una vez que verificamos que todo está funcionando de forma correcta podemos proceder a montar en un equipo independiente, nuestro sistema de almacenamiento y explotación de métricas. Yo he decidido montarlo en un Ubuntu. La instalación y el sistema de métricas no va a ocupar demasiado espacio ni requiere de un gran uso de CPU ni RAM.

Podemos optar por montarlo todo en nuestro Raspbian, pero la experiencia me hace declinarme por separar el sistema de medición con el sistema de almacenamiento y explotación de datos, dado que las tarjetas SD fallan frecuentemente y perdería el histórico de métricas.

Teniendo en cuenta todo esto, nos movemos a nuestro Ubuntu y comenzamos instalando InfluxDB, que será nuestra BBDD de almacenamiento.

echo "deb https://repos.influxdata.com/ubuntu bionic stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
sudo curl -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add -
sudo apt-get update
sudo apt-get install influxdb -y

Si vamos a securizar las comunicaciones (recomiendo hacerlo) necesitamos que el servicio corra con los privilegios necesarios para poder acceder luego a los certificados SSL/TLS para securización de comunicaciones, con lo que para ello editamos el archivo /etc/init.d/influxdb y establecemos los siguientes parámetros:

USER=[Usuario_Con_Privilegios]
GROUP=[Grupo_Con_Privilegios]

Guardamos los cambios y cerramos el archivo. Ahora podemos reiniciar el servicio:

Tres esto, tendremos corriendo la instancia de BBDD de InfluxDB en nuestro sistema y la siguiente parte será crear usuarios y una BBDD. inicial. Para ello ejecutamos el CLI desde línea de comandos con el comando influx y una vez en la consola del CLI ejecutamos los siguientes comandos:

create database "sensor_data"
create user "admin" with password ""
grant all on "sensor_data" to "rpi-3"
create user "grafana" with password ""
grant read on "sensor_data" to "grafana"

Ya hemos creado nuestros primeros usuarios y la BBDD. El usuario “admin” lo utilizaremos para crear el resto de usuarios que administrarán la BBDD, a los cuales le deberemos establecer privilegios con “grant all privileges to [usuario_admin]”. El usuario “rpi-3” es el que usaremos para conectar desde nuestra RPi y el usuario “grafana” lo usaremos para conectar desde grafana. Es por ello que “rpi-3” tiene privilegios completos, pero solo en la BBDD creada “sensor_data” y el usuario “grafana” solo tiene privilegios de lectura sobre la misma BBDD.

Vamos a revisar si los parámetros de configuración son correctos y de paso vamos a establecer que la comunicación y la autenticación ha de ser segura. Podemos también cambiar los puertos TCP en los que se sirve el servicio por defecto. Para ello tendremos que editar el archivo /etc/influxdb/influxdb.conf. Los parámetros son:

bind-address = : #Yo he utilizado el puerto 8888

#Apartado [http]
enabled = true
bind-address = “:[Puerto]” #Yo he utilizado el puerto  8886
auth-enabled = false (true)
realm = “InfluxDB”
https-enabled = true/false (true)
https-certificate = "path_del_certificado" #Path al certificado
https-private-key = “path_de_la_key_del_certificado” #Path a la clave del certificado

Guardamos los cambios, cerramos el archivo y reiniciamos el servicio:

service influxd stop
service influxd start

Para poder administrar nuestra BBDD tenemos dos opciones, hacerlo por línea de comandos o a través de interface gráfica http con Chronograf. He decidido usar Chronograf por ser mas “user friendly” y por la facilidad de poder acceder desde un navegador. Para instalarlo hacemos lo siguiente:

wget https://dl.influxdata.com/chronograf/releases/chronograf_1.7.12_amd64.deb
sudo dpkg -i chronograf_1.7.12_amd64.deb
service start chronograf

Con esto ya tendremos instalado y corriendo el panel de control de Chronograf. Ahora toca hacer lo que antes… revisar configuración y securizar canales y acceso. Para ello, editamos el archivo /etc/default/chronograf y establecemos los parámetros:

HOST=[host_FQDN]
PORT= #Yo he usado el 9888
TLS_CERTIFICATE=[path_al_certificado] #Path al certificado
TLS_PRIVATE_KEY=[path_a_la_clave_del_certificado] #Path a la clave del certificado
#TOKEN_SECRET=[Token_que_queramos_usar] (Este parámetro no lo usaremos y lo dejamos comentado #)
LOG_LEVEL=debug #Establecemos “Debug” porque por ahora nos interesa que nos salga todo detalle en el log 

Editamos también el archivo /etc/init.d/chronograf y establecemos los siguientes parámetros:

export PORT=[”puerto”] #Yo he usado el 8888
RUNAS=

Ahora reiniciamos el servicio:

service stop chronograf
service start chronograf

Ya tendremos configurado y funcionando Chronograf con los parámetros establecidos, así que podemos pasar a configurar la BBDD que usaremos para el almacenamiento de las métricas. Accederemos vía navegador a Chronograf: https://[host_fqdn]:[puerto] (en el ejemplo yo usé el puerto 9888) y en el apartado de configuración (llave inglesa) agregaremos una conexión con el botón “+ Add Connection”

Figura 8: Añadiendo una conexión

Estableceremos los valores que hemos configurado:

Connection URL: https://[host_FQDN]: (Yo usé el Puerto 8886)
Connection Name: Nombre_Identificativo
Username: admin
Password: El que establecimos al crear el usuario  en nuestro InfluxDB
Telegraf Database Name: Lo dejamos por defecto
Defaul Retention Policy: default
Make this the defaul connection: habilitado
Unsafe SSL: habilitado (Si hemos habilitado SSL/TLS)

Hasta aquí la primera entrega de cómo construir tu propio medidor ambiental para tu CPD utilizando una Raspberry Pi. Continuamos en la segunda parte.

Saludos,

Autor: Jesús Suarez

******************************************************************************************************
- Cómo construir un medidor ambiental para el CPD con Raspberry Pi [Parte 1 de 2]
- Cómo construir un medidor ambiental para el CPD con Raspberry Pi [Parte 1 de 2]
******************************************************************************************************

El ‘hop’ de Empire que permite meter saltos en los agentes de post-explotación

Que me gusta Metasploit es algo que muchos ya saben, pero que también me gusta y mucho el proyecto de Empire es algo que pocos saben. He seguido jugando y viendo las posibilidades que ofrece Empire y en lo que a listeners y tipos de configuración se refiere es algo muy potente. Hoy quiero hablar sobre el listener de Empire de tipo hop.

Figura 1: El ‘hop’ de Empire que permite meter saltos en los agentes de post-explotación

Probablemente os sea muy útil, cuando se trate de ocultar la dirección IP desde la que se está realizando el pentesting, así que vamos a ver en detalle cómo se configura en Empire.

Listeners en Emprie

Un listener es un proceso que queda a la escucha en un puerto y que tiene un comportamiento ante las peticiones de conexión que nos llegarán de los agentes que se estén ejecutando en las máquinas comprometidas. La idea es sencilla, tenemos un servidor que hará labores de intermediario, el cual debe tener la característica de ser un servidor web.

La máquina dónde el agente es ejecutado, por ejemplo, tras una explotación de una vulnerabilidad, se conectará con el servidor intermedio, el cual tiene configurado unos recursos PHP que harán la redirección al listener de tipo HTTP, el listener más clásico, el cual se encuentra en la máquina Kali Linux dónde ejecutamos Empire.

Figura 2: Escenario de listener tipo hop en Empire

En la imagen superior, se puede visualizar el esquema comentado anteriormente. Si analizamos la primera conexión que hace el agente mediante el comando ‘netstat –na’ podríamos ver que hay una conexión entre la máquina intermedia y la máquina víctima. No aparece la máquina de Empire. Es más, cuando la máquina con Empire recibe la conexión del agente, se puede visualizar que la dirección IP de la que viene la conexión es la máquina intermedia.

Paso 1: Probando listerners

El escenario propuesto para la prueba que vamos a hacer es el siguiente:

• Máquina Kali Linux con Empire C2 en la dirección IP 10.0.0.1.
• Máquina Ubuntu, que será la máquina intermedia, en la dirección 10.0.0.20.
• Máquina Windows 7, en la que se ejecutará el agente, en la dirección 10.0.0.10.

El primer paso es configurar los listeners. En este caso debemos configurar dos listeners, el primero es un listener HTTP clásico de Empire, mientras que el segundo será un listener de tipo http_hop. En la imagen se puede visualizar como se configura el listener HTTP en el puerto 80 de la máquina con dirección IP 10.0.0.1, en este caso nuestro Kali Linux.

Figura 3: Configuración de listener http en Empire sobre Kali Linux

Una vez configurado el primer listener, vamos con el segundo. El listener de tipo http_hop generará una serie de archivos, los cuales son configurados en el host 10.0.0.20:80. En esa máquina tendremos un servidor web con PHP. Como se puede ver en la imagen, se obtiene una serie de archivos PHP los cuales saben gestionar las peticiones que reciban y reenviarlas, gracias al atributo RedirectListener, al listener http, el cual se encuentra configurado en la máquina 10.0.0.1.

Figura 4: Configuración de listener http_hop en Empire

Para subir los archivos al servidor intermedio se pueden utilizar diferentes formas, entre ellas la copia a través de SSH. Esto ya depende de cada uno y de las circunstancias, ya que en un Ethical Hacking podríamos hablar de una máquina comprometida y que queremos utilizar para hacer el ‘hop’ hacia el primer listener. Sea como sea, hay que subir los archivos PHP generados a la máquina intermedia.

Figura 5: Subida de archivos al servidor del listener http_hop

Paso 2. Recepción del stager a través de la máquina intermedia

Una vez tenemos todo preparado, hay que ejecutar el agente en la máquina víctima o comprometida. En otras palabras, un agente configurado mediante usestager apuntando al listener http_hop será ejecutado y éste emprenderá una conexión al servidor intermedio, el cual redirigirá la conexión al listener de la máquina 10.0.0.1.

Figura 6: Conexión desde la máquina intermedia

Cuando la conexión llegue, tal y como se puede ver en la imagen superior, la máquina 10.0.0.1 recibirá la conexión con el agente y la dirección IP que aparece es la 10.0.0.20, que es la máquina intermedia. En ningún caso se la dirección IP de la máquina víctima, que es la 10.0.0.10. Al ejecutar el comando agents, se puede ver la conexión y ejecución del agente en la máquina Windows 7. Aquí sí se puede ver que la dirección IP de la máquina Windows es la 10.0.0.10.

Figura 7: Prueba de listener http_hop en Empire

Os dejo un video en el que podéis ver todo el proceso desde cero, para que se entienda bien. Sin duda, este tipo de técnicas y usos son interesantes de cara al pentesting y el Ethical Hacking. Seguiré aportando más información sobre las posibilidades que ofrece Empire en su esplendor.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advance Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.

Hashtopolis: Cómo crackear contraseñas de forma distribuida

Una de las acciones más comunes durante la realización de un proyecto de Ethical Hacking, es el crackeo o descifrado de las contraseñas que el analista va encontrando en diferentes partes de los sistemas objetivo o intermedios, de los que va recabando hashes en diferentes algoritmos con una credencial válida que pueda dar paso al siguiente nivel. Y a veces es un proceso lento si la contraseña es robusta, el algoritmo de hashing es complejo o no tenemos suficiente potencia de cómputo.

Figura 1: Hashtopolis: Cómo crackear contraseñas de forma distribuida

En este artículo os traigo una herramienta muy interesante que nos permite, de una manera relativamente sencilla, utilizar hashcat para realizar tareas de descifrado distribuyendo el trabajo entre diferentes ordenadores que se encuentren en una misma red.

Instalando hashtopolis y configurando el entorno

La herramienta que vamos a utilizar para realizar esta tarea se llama Hashtopolis, y se puede acceder a ella en su repositorio de GitHub. Es un sistema cliente-servidor que permite distribuir tareas de hashcat entre diferentes ordenadores.

Figura 2: Hashtopolis en GitHub

Hashtopolis requiere la instalación de un servidor de aplicación (apache2) que albergará una aplicación web que permitirá al usuario gestionar todos los equipos que se estén utilizando para completar las tareas. En los equipos que se deseen utilizar para realizar las tareas, se debe instalar un agente, que no es más que un pequeño programa que se encargará de comunicarse con el servidor para recibir órdenes.

Instalando y configurando el servidor

Lo primero que vamos a hacer es instalar y configurar el servidor, para ello se recomienda utilizar una máquina virtual con un sistema operativo Ubuntu o Debian. Vamos a comenzar por la instalación de las dependencias principales que requerirá la aplicación, para ello ejecutamos los siguientes comandos:

$ sudo apt-get update 

$ sudo apt-get install mysql-server 

$ sudo apt-get install apache2 

$ sudo apt-get install libapache2-mod-php php-mcrypt php-mysql php * 

* (Si se utiliza php7.2 y se tiene problemas con la instalación de php-mcrypt, recomiendo que consultéis este enlace) 

$ sudo apt-get install git curl

Una vez instaladas todas estas dependencias, vamos a descargar hashtopolis desde su repositorio de GitHub para configurar la aplicación web. A continuación, se muestra el comando necesario para realizarlo.

$ git clone https://github.com/s3inlc/hashtopolis.git 

$ cd hashtopolis/src 

$ sudo mkdir /var/www/hashtopolis 

$ sudo cp -R * /var/www/hashtopolis/

$ cd /var/www 

$ sudo chown -R www-data:www-data hashtopolis

Una vez descargada la herramienta, y movida la aplicación web al directorio de servidor de aplicación, vamos a realizar algunas configuraciones en el directorio de apache2. Lo primero, abrimos el siguiente fichero e introducimos el nombre de archivo index.php a continuación de index.html.

$ sudo pico /etc/apache2/mods-available/dir.conf

También vamos a configurar el directorio (hashtopolis) que hemos creado dentro de /var/www como DocumentRoot. Para ello introducimos el comando que se muestra a continuación, y en la línea donde pone DocumentRoot /var/www/html lo modificamos por DocumentRoot /var/www/hashtopolis.

$ sudo pico /etc/apache2/sites-enabled/00*

Una vez realizadas estas configuraciones, si se han seguido todos los pasos, tras reiniciar apache2 mediante el comando sudo service apache2 restart deberíamos ver algo similar a la imagen que se muestra a continuación.

Figura 3: Inicio de la instalación de Hashtopolis

En este punto tenemos casi listo nuestro servidor, únicamente queda la configuración de la base de datos y añadir un usuario para utilizar la aplicación web, vamos a ello. Lo primero vamos a instalar phpmyadmin para que resulte más sencilla la administración.

$ sudo apt-get install phpMyAdmin

Dependiendo de la versión que estéis instalando es posible que tengáis que añadir la sentencia Include /etc/phpmyadmin/apache.conf al final del fichero /etc/apache2/apache2.conf. Una vez instalado phpmyadmin accedemos mediante el navegador introduciendo la dirección IP de nuestra máquina /phpmyadmin. Dentro de phpmyadmin vamos a añadir un nuevo usuario para que utilice hashtopolis, a continuación, se muestra la configuración del usuario.

Figura 4: Añadiendo un usuario en Hashtopolis

Una vez añadido el usuario, volvemos a la página de inicio de hashtopolis introduciendo la dirección IP de nuestra máquina en el navegador y comenzamos la instalación. Los parámetros que se requieren para la instalación se muestran en la siguiente imagen.

Figura 5: Parámetros de instalación

Si la creación de las tablas en la base de datos ha sido satisfactoria, hashtopolis nos mostrará una pantalla para crear un usuario administrador en la aplicación web.

Figura 6: Creación de usuario administrador

Tras crear el usuario administrador, nos aparecerá la pantalla de acceso en el navegador. Introduciendo los datos del usuario administrador tendremos acceso al sistema.

Figura 7: Sistema de Hastopolis

En este punto tendríamos el servidor completamente instalado y funcional. Ahora podemos pasar a la segunda parte. Añadir los agentes a nuestra red.

Instalación de los agentes

Los agentes son los programas que se encargarán de comunicarse con el servidor que hemos configurado previamente para recibir tareas que realizar, y deben instalarse en cada uno de los equipos de la red que queramos que participen en el proceso. Vamos a ver como instalar un agente en un equipo Ubuntu.

Lo primero que debemos tener instalado es hashcat, para ello, basta con ejecutar el siguiente comando:

$ sudo apt-get install hashcat

Una vez instalado hashcat, lo único que tendríamos que hacer es seguir las instrucciones que nos marca la Wiki del proyecto.

Figura 8: Wiki de hashtopolis

Tras ejecutar ese conjunto de comandos, vamos a la aplicación web que hemos configurando anteriormente y pulsamos sobre crear nuevo agente.

Figura 9: Añadir nuevo agente

Como puede observarse hay dos agentes disponibles, uno escrito en C Sharp y otro en Python. Vamos a utilizar el de C Sharp. Pulsamos el botón Create del New voucher y a continuación ejecutamos el siguiente conjunto de comandos.

Figura 10: Creación del agente de C# usando Mono

Si se han seguido todos los pasos anteriores, en este punto el agente estaría activo haciendo pulling cada ciertos segundos al servidor para recibir tareas.

Creación de una tarea para probar el agente

La características principales de la creación de tareas pueden encontrase en la Wiki del proyecto de hashtopolis, en este caso, veremos como crear una tarea sencilla para descifrar un Hash md5. En el siguiente video se muestra como crear una tarea y asignársela a un agente Python para que crackee una lista de hashes md5 haciendo fuerza bruta con un diccionario. Hay que tener en cuenta que el servidor y el agente no están en la misma máquina.

Figura 11: Demo de Hashtopolis

Como puede observarse, el uso de esta herramienta es una forma muy buena de aprovechar todos los recursos computacionales que tengamos para realizar una única acción de manera distribuida. Podemos crear listas muy amplias de contraseñas cifradas y asignarle la tarea a varios agentes que comenzaran a descifrar de manera coordinada, sin estar alojados sobre el mismo ordenador y sin disponer del mismo hardware o arquitectura.

Autor: Santiago Hernández, Security Researcher en ElevenPaths

Killing Bots: How to hack your company using your Telegram Bot #Telegram

Hoy en día se han puesto de moda los bots en Telegram, y es verdad que puede que nos faciliten algunas tareas. Tenemos bots para consultar los horarios del Tram, para obtener la previsión meteorológica, para consultar el precio de cualquier producto en Amazon, ejecutar un ping, convertir archivos multimedia, analizar URLS maliciosas con servicios como Virus Total, administrar servidores, crear y controlar una botnet y casi cualquier cosa que nos podamos imaginar se puede encontrar por Github o en la tienda de bots StoreBot.

Figura 1:  Killing Bots: How to hack your company using your Telegram Bot

Está claro, que estos bots son muy útiles, y en ocasiones divertidos y entretenidos, ya que incluso existen algunos con los que podemos jugar en los chats grupales con nuestros amigos, entre otras cosas.


Figura 2: Ejecutar un nmap remotamete vía un bot de Telegram

Cualquier usuario puede crear y/o programar un bot. Para los que no son desarrolladores, existen varias aplicaciones web para hacerlo de forma gráfica e intuitiva sin necesidad de programar, como puede ser ‘Manybot’, aunque esta opción obviamente tiene sus limitaciones.

Figura 3: Manybot

Para los que están dispuestos a quemar sus dedos y volverse locos a base de escribir código, hay una infinidad de posibilidades, pero esto puede traer de la mano algunos problemas en cuanto a la escritura de código seguro. Sobre todo, porque muchas de estas personas despliegan los bots en sus propios ordenadores de forma local, o peor aún, empresas que los utilizan para dar soporte a sus clientes, estando estos alojados en sus propios servidores.

¿Problemas?

Sí. Hay algunos bots que para realizar sus funciones deben ejecutar comandos en el sistema en el cual están corriendo, por ejemplo, como uno de los que hemos citado anteriormente. Un bot para hacer ping debe ejecutar el comando en el servidor a partir de los parámetros que envíe el usuario que lo utilice.

Si este bot está mal programado, es decir, con una exclusiva visión de funcionalidad dejando de lado la seguridad y las buenas prácticas, cosa por desgracia muy habitual, puede ser perfectamente un vector de entrada para poder tomar el control completo del sistema en el que corre (Command Injection).

En el caso que queremos mostraros hoy, vamos a crear un escenario (entorno controlado) como el que acabamos de describir. Desgraciadamente, es un escenario perfectamente posible en un entorno real.

Caso hipotético:

A un administrador de sistemas que hace labores de todo tipo como informático en una pequeña empresa, se le encarga el desarrollo de un bot para Telegram, que servirá para dar soporte a los clientes de dicha empresa. Entre las diversas funcionalidades que se requieren, hay una que permite que los usuarios ejecuten un ping a cualquier dominio. Este sysadmin, decide programarlo en Python y hostearlo en el servidor de la propia empresa. El programa ejecutará el comando ‘ping’ a partir de los parámetros que le lleguen desde el bot. Esto es un ejemplo, puede ser cualquier otro lenguaje de programación y otra funcionalidad que ejecute algún comando a través de los parámetros enviados por el usuario.

Figura 4;: Bot ejecuta comando /ping google.es

Este administrador de sistemas, sabe lo justo de programación y no se ha leído los libros de Hacking Web Technologies ni el de Hacking Web: SQL Injection, por lo que no ha sanitizado correctamente la entrada de parámetros. Ha tenido un fallo a la hora de programar dicha funcionalidad y no ha controlado correctamente que los parámetros que recibe no sean maliciosos o malignos.

Figura 5: Fragmento de código vulnerable en desarrollo Python del bot

Para que lo descrito anteriormente sea posible, se debe ejecutar un comando en el sistema, por lo tanto, vamos a probar concatenando otro comando a continuación para comprobar si es vulnerable a Command Injection, de esta forma:

Figura 6: Inyección de un comando ls -l

Como vemos, al concatenar el comando, el mismo se ha ejecutado sin ningún problema. Y mejor, el resultado se nos muestra en pantalla perfectamente.

Recolección de información y explotación

El usuario sobre el que corre el bot no tiene privilegios, pero podemos recopilar bastante información y ejecutar diferentes comandos. Aunque tampoco nos vamos a conformar simplemente con esto, ya que estamos aquí.

Figura 7: Inyección de un comando uname -a

Concatenando el comando ‘uname –a’, vemos que corre sobre un ‘Ubuntu 14.04’ con el Kernel ‘4.4.0-31-generic’. Con buscar un poco en Google , podremos comprobar, que es vulnerable a diferentes técnicas de escalación de privilegios.  Como sabéis, esto se puede hacer también con un herramienta escrita en Python llamada AutoLocalPriviligeEscalation que permite saber qué exploits son válidos para cada versión del kernel de Linux sin fortificar.

Figura 8: Podríamos inyectar la ejecución de auto_searchsploit si lo clonamos antes de su GitHub

Para tener un mayor control sobre el sistema que estamos tratando de comprometer, en vez de inyectar los comandos de elevación de privilegios a través de el bot, vamos a intentar obtener una shell en el mismo. Para ello, se nos ocurrió utilizar Netcat.

Obtención de una shell remota a través del Bot de Telegram

En nuestra máquina Kali Linux, vamos a poner netcat a la escucha de una conexión, para conectarnos desde la víctima. Con esto conseguiríamos una shell reversa, ya que la conexión sería establecida por parte del sistema vulnerado usando como vector de ataque al bot.

Figura 9: Netcat escuchando en el puerto 4444 en la máquina Kali Linux del atacante

A continuación, desde el bot, vamos a ejecutar el comando que se conectará al atacante. Pudimos comprobar que dicho comando NO requiere de privilegios.

Figura 10: Inyección de comando netcat. Si nc no está en el servidor habría que descargarlo.

También debemos redirigir STDIN y STDERR a /dev/null y añadir ‘&’ al final para que corra en segundo plano y no deje en pausa la ejecución del bot. Tras esto, podemos observar, que se ha establecido una conexión por parte de la máquina víctima.

Figura 11: Shell obtenida en la máquina Kali Linux del atacante

Una vez hemos obtenido la shell, podemos comenzar a ejecutar comandos. Como podéis ver, hemos conseguido a través de un bot vulnerable de Telegram, acceder a un sistema y obtener una shell en el mismo. Pero al estar corriendo sobre un usuario sin privilegios, tenemos grandes limitaciones.

Figura 12: Ejecución de comandos en el sistema. Aún no privilegiado

Para ello, debemos encontrar la manera de conseguir una escalación de privilegios. Como vimos anteriormente con el ‘uname –a’ podemos ver detalles del sistema como la versión del sistema operativo, versión del kernel, entre otras cosas.

Escalación de privilegios final con DirtyCow

Para escalar privilegios, podemos buscar información sobre vulnerabilidades conocidas para la versión específica del sistema que estamos atacando en este caso, un Ubuntu 14.04 usando la herramienta AutoLocalPriviligeEscalation. Con ell nos encontramos con que nuestra víctima corre una de las versiones vulnerables a ‘Dirty COW’, uno de los últimos exploits de escalación de privilegios para el kernel de Linux. Este exploit aprovecha una vulnerabilidad en el manejo de la memoria, causando un problema de condición de carrera, permitiendo así que podamos escribir en zonas de memoria, que en teoría deben ser de sólo lectura.


Figura 13: Ejemplo de explotación de DirtyCow

Descargamos el exploit desde un repositorio de Github en la máquina atacante. En nuestro caso metemos el zip en un servidor web Apache que hemos levantado. En un entorno real, un atacante podría utilizar un servidor propio, en el que almacenaría todo el malware que va a utilizar para comprometer un sistema determinado.

Figura 14: Publicación de exploit dirtycow en servidor Apache del atacante

Desde netcat, descargamos con ‘wget’ el zip en la máquina víctima y lo movemos a la carpeta /tmp, para que no esté a la vista y así evitar que la víctima pueda verlo. La shell que nos da netcat tiene sus limitaciones. Por ejemplo, no se puede hacer un ‘ssh’ o un ‘su’, también se presentan dificultades a la hora de tratar de editar archivos y no muestra los STDERR. Por lo tanto, también tendremos problemas a la hora de obtener la shell con root, tras explotarlo. Por supuesto, pasar un dirtycow.zip por la red podría hacer saltar los controles de seguridad e IDS, así que el zip mejor pásalo con password u ofuscado de alguna otra forma en un proyecto de Ethical Hacking real.

Ahora tendríamos que descomprimirlo, compilarlo y ejecutarlo, pero como acabamos de comentar, desde la terminal de netcat no es posible alguna de esas tareas. Primero tenemos que ‘upgradear’ la shell para obtener una terminal más completa en la que poder manejarnos mejor. Tenemos diversas posibilidades para esto, pero una muy sencilla es ejecutar una línea en Python que nos saque una pseudoterminal (pty). Haciendo uso de la librería pty, simplemente tenemos que llamar al método .spawn y añadir ‘bin/bash’ para obtener la shell.

Figura 15: Upgradeando la shell

Ya podemos observar el prompt en nuestra consola. Hay más formas de hacer esto, cabe la posibilidad de que, a diferencia de en este escenario, la víctima no tenga instalado Python, por tanto, deberíamos recurrir a otros métodos.

Figura 16: Extrayendo el contenido del exploit

Ahora hay que explotar el sistema para conseguir la escalación de privilegios que tanto anhelamos y así podernos hacer con el control del mismo. Extraemos el zip previamente descargado y movido a /tmp en la máquina víctima con ‘unzip’ como se ve en la imagen superior, y luego compilarlo, como se ve en la imagen siguiente.

Figura 17: Compilando DirtyCow

Y finalmente ejecutarlo con la opción ‘-s’ para un proceso más rápido y automático porque el exploit podría dejar bloqueado el sistema. Se puede observar, que hemos obtenido privilegios de superusuario, lo que quiere decir que poseemos control absoluto del sistema.

Figura 18: Ejecución de DirtyCow

Podríamos ir dejando backdoors para poder acceder de nuevo en próximas ocasiones, pero esto ya entraría en la fase de post-explotación de un proyecto de Ethical Hacking y nosotros solamente pretendemos mostrar lo que podría llegar a ocurrir simplemente porque a un programador se le olvide (o no tenga en cuenta) la seguridad desde el diseño. El resto de posibilidades, ya queda a la imaginación de cada lector.

Notas Finales sobre la seguridad de los bots de Telegram

En Github podemos encontrar una gran cantidad de bots o módulos hechos por la comunidad, los cuales ofrecen distintas funcionalidades. Aquí hay que tener especial cuidado ya que muchos de ellos son potencialmente vulnerables, y si lo descargamos y usamos alegremente, pueden acarrear problemas como los descritos anteriormente.

Ahora imaginemos en nuestro supuesto caso, que este es el servidor central de la pequeña empresa, y en él, están almacenadas las bases de datos, documentos e información confidencial de la misma. Podríamos robar dicha información, incluso hacer un DoS en los servicios que corre, por no hablar de técnicas de ‘pivoting’ y comprometer otros equipos de la red en caso de que el servidor no se encuentre en una DMZ con unos sistemas de seguridad acorde a las necesidades.

Algunas pocas recomendaciones podrían ser:

• Controlar el tamaño de los parámetros que se pasan a través del bot. Dado que solamente es un dominio debe ser máximo uno. 

• Controlar que los comandos se ejecuten solamente por los admins o personal autorizado. En Telegram cada usuario tiene un ID único, que puede usarse para evitar que otros usuarios ejecuten el mismo. 

• Usar una expresión regular para verificar y comprobar, que el parámetro efectivamente es un dominio y no otra cosa. 

• Usar funciones propias del lenguaje en el que se haya implementado el bot para mejorar la seguridad. En Python se puede usar shlex.quote(s). 

Figura 19: JSON con las peticiones del bot

• También se nos ocurre, que si sospechas que alguien está intentando hacerte un command injection, puedes apagar el bot y revisar las últimas peticiones realizadas a través del servidor de telegram, que se guardan durante 24 horas. Para ello puede ir al navegador y escribir: https://api.telegram.org/bot[token]/getUpdates donde se debe reemplazar el token del bot en [token] y si nos fijamos recibiremos un JSON con las peticiones pendientes y datos adicionales del posible atacante.

Conclusiones de este trabajo

Es conveniente reflexionar sobre las buenas prácticas y la visión de seguridad a la hora de diseñar e implementar un software, no prestando atención exclusivamente a la parte funcional. Es un matiz que hay que tener en cuenta desde el diseño. En muchos centros de enseñanza donde se aprende a programar esto apenas se tiene en cuenta o se deja en segundo plano, trayendo de la mano una gran inconsciencia por parte de los desarrolladores a la hora de crear sus aplicaciones. Finalmente, os dejamos una PoC en vídeo de todo este proceso de explotación:

Figura 20: Killing Bots: How to hack your company using your Telegram Bot

Autores: Adrián Fernández (@adrianfa5) y Mauricio Trujillo (@fm_trujillo) Estudiantes de Seguridad Informática y coorganizadores de @bitupalicante