Cazando comandos remotos de versiones viejas de PowerShell con RemotePSpy

Ya sabéis que PowerShell es muy usado por los "rojirrins" debido a su poder y flexibilidad. Y también que no sólo los comandos y los scripts se pueden ejecutar en una sesión local de PowerShell, sino que también es posible (y muy normal) ejecutar PowerShell en un host remoto. Esto puede ayudar a un atacante a moverse lateralmente y evitar dejar un script en disco.

Desde el punto de vista de los "azulones", la dificultad para detectar y responder a una sesión de PowerShell remota varía mucho según la versión de PowerShell que se esté utilizando. Las versiones más modernas incluyen funciones de logging total que pueden incluir una transcripción completa de sesiones completas de PowerShell con todas las entradas y salidas. Pero las versiones anteriores tienen un registro mucho más rudimentario que puede hacer muy difícil saber exactamente qué sucedió en una sesión determinada.

Para enfrentarnos a esta situación como "hunters" podemos usar RemotePSpy, una herramienta que puede obtener el detalle completo de lo que sucede en las sesiones remotas de PowerShell, tanto en las versiones más nuevas de PowerShell como en las más antiguas.

RemotePSpy ofrece una vista que se aproxima a lo que se mostraría en la pantalla del atacante cuando está ejecutando PowerShell en remoto. En el siguiente GIF se muestra a la izquierda la pantalla del atacante y a la derecha la vista de RemotePSpy.


Una cosa interesante acerca de las sesiones interactivas es que realmente puede ver cuando el atacante usa la pestaña completa, que usa el comando TabExpansion por debajo.

Al mismo tiempo que se muestra la pantalla de forma interactiva, todas las entradas y salidas también se registran en RemotePSpy.log de forma más detallada:


Las sesiones no interactivas funcionan de la misma manera. Un script ejecutado desde un archivo o en un ScriptBlock pasado en la línea de comandos se enviará al host remoto, donde se registra su contenido, seguido de su salida.

identYwaf: una herramienta para identificar WAFs (firewalls de aplicaciones web)

identYwaf es una herramienta de código abierto para identificar firewalls de aplicaciones web (en adelante WAFs) escrita por el mismísimo Miroslav Stampar, creador de sqlmap.

Esta herramienta es capaz de reconocer más de 70 tipos de WAFs basándose en inferencias ciegas. ¿Qué significa ésto? Bueno, pues que identYwaf tiene un conjunto de payloads predefinidos y no destructivos que provocarán una respuesta del WAF que se está probando. Esta respuesta luego se compara con las "firmas" individuales de estos firewalls que se pueden encontrar en el archivo data.json del proyecto. Estas firmas no son más que simples cadenas conocidas como "1 AND 1 = 1" con las que reaccionan estos firewalls de aplicaciones web.

¿Qué firewalls puede identificar? Pues de momento tenemos la siguiente (e impresionante) lista:
  1. 360 Web Application Firewall (360)
  2. aeSecure
  3. Airlock (Phion/Ergon)
  4. Alibaba Cloud Security Server Guard (Server Security)
  5. Anquanbao Web Application Firewall (Anquanbao)
  6. Approach Web Application Firewall (Approach)
  7. Armor Protection (Armor Defense)
  8. F5 Networks (Application Security Manager)
  9. Amazon (AWS WAF)
  10. Barracuda Networks WAF
  11. BitNinja
  12. Bluedon Web Application Firewall
  13. CdnNs/WdidcNet (CdnNsWAF)
  14. WP Cerber Security
  15. Check Point Next Generation Firewall

Aztarna: una herramienta para encontrar robots vulnerables en Internet

Alias Robotics, una startup española especializada en ciberseguridad para robótica, ha lanzado una herramienta gratuita y de código abierto para detectar robots desprotegidos, no solo conectados a Internet, sino también a los entornos industriales en los que operan.

Bautizada como "Aztarna", se trata de un framework escrito en Python 3 y básicamente es un escáner de puertos con una base de datos integrada de fingerprints de routers industriales (incluidos Westermo, Moxa, Sierra Wireless y eWON), tecnologías y componentes robóticos, así como patrones para identificar varias vulnerabilidades conocidas y errores de configuración de seguridad.


Aztarna ha sido diseñada para funcionar en diferentes escenarios de tests de intrusión. Puede escanear una lista de direcciones IP dadas, un rango de IP de red, los resultados del motor de búsqueda Shodan e incluso todo Internet junto con otras herramientas de escaneo como ZMap o masscan.

"Motivados por la falta de herramientas dedicadas para la investigación de seguridad en el campo de la robótica, hemos desarrollado Aztarna, una herramienta destinada a ayudar en la detección y exploración de robots y tecnologías de robots (incluidos los componentes de software) en una red", comentan los investigadores de Alias Robotics.

Al realizar un escaneo rápido con Aztarna, los investigadores detectaron casi 106 sistemas ROS abiertos y 9.000 routers industriales inseguros en todo el mundo, un posible punto de entrada para que los atacantes comprometan robots vulnerables conectados a la red, a los que se puede acceder de forma remota utilizando las credenciales predeterminadas o incluso sin necesidad de autenticación.

"Algunas de las instancias de ROS encontradas correspondieron a sistemas vacíos o simulaciones, pero se identificó una proporción considerable de robots reales. Incluyendo una serie de máquinas orientadas a la investigación, pero también una serie de robots en entornos industriales", dijeron los investigadores.

La mayoría de los routers vulnerables identificados (alrededor de 1.586) se encontraron en países europeos, con Francia y España liderando el ranking de routers mal configurados.

Además, Aztarna puede configurarse fácilmente para recibir más fingerprints y patrones con futuras versiones y para admitir nuevos componentes de software o hardware de robot, lo que permite a los investigadores determinar la versión de firmware específica en robots y descubrir "bibliotecas de terceros" y sus versiones, por ejemplo, la versión de robot de software intermedio, infraestructura de comunicación, etc.

Alias Robotics notificó a los propietarios de los robots sobre los robots vulnerables, pero argumentó que el lanzamiento de Aztarna es "una consecuencia natural de la falta general de preocupación entre los fabricantes de robots hacia la seguridad y la ciberseguridad".

"No es solo que son muy lentos para corregir sus fallos cuando les avisamos. A muchos simplemente no les importa y dicen: sabemos que nuestros robots tienen un conjunto de vulnerabilidades reportada, pero dejamos la seguridad en manos del usuario final", dijeron los investigadores.

Los investigadores de Alias Robotics también lanzaron un paper [PDF] con el detalle Aztarna, cómo puede usarse y cómo permitir futuras extensiones.

Fuente: https://amp.thehackernews.com/thn/2019/01/robot-cybersecurity-tool.html

sqli-platform de Geospade: otra aplicación web vulnerable para practicar SQLi

En septiembre del año pasado os hablábamos del lab del holandés Audi-1 para practicar la explotación de vulnerabilidades SQLi y hoy, por si os habíais quedado con ganas, os traemos SQLi Platform de Geospace.

Se trata de otra aplicación WEB vulnerable para comprender los conceptos básicos de las inyecciones SQL.

La parte frontal expone un campo que permite al usuario buscar en una base de datos y recuperar nombres, alias, correos... Las entradas del usuario no están saneadas, lo que permite que un atacante inyecte código SQL y exfiltre las contraseñas.

Las consultas SQL se registran en el backend y también se muestran en la parte frontal, para que el atacante comprenda mejor lo que está haciendo.


Instalación

Para mayor comodidad se puede ejecutar la aplicación bajo contenedores Docker:

docker-compose up

De igual forma, podemos editar docker-compose.yml y modificar las siguientes settings:

MYSQL_ROOT_PASSWORD: Contraseña de la base de datos
SQL_HOST: Host de la base de datos, desde el punto de vista de la API
SQL_WAIT: tiempo que la API espera (en segundos) antes de conectarse a la base de datos

La aplicación es accesible en http://localhost:8080/.

Ejemplo de inyección (spoiler):

A continuación se muestra un ejemplo de payload que funciona, exponiendo todas las contraseñas en la tabla:

nothing%" UNION SELECT pass, nickname, email FROM users#

Resultando en la siguiente consulta completa:

SELECT id, nickname, email FROM users WHERE nickname LIKE "%nothing%" UNION SELECT pass, nickname, email FROM users#%"

Proyecto: https://github.com/Geospace/sqli-platform

Writeup QUAL CTF h-c0n 2019

Como sabéis este año hemos hecho una clasificación para el CTF de la h-c0n 2019 muy peculiar en cuanto el formato respecto al año anterior. Teníamos claro que queríamos poner en liza otro reto tipo 'boot2root' pero esta vez hemos podido servir la máquina online y además poder interactuar con ella y con el juego mediante un bot en Telegram. Gracias otra vez a César, Romam y Pablo respectivamente por hacerlo posible.

Y como siempre vuestra respuesta ha sido increíble y a dos días para cerrar la clasificación o qual ya tenemos el top 20 definitivo de usuarios que pasan a la siguiente fase, es decir, el CTF organizado por iHackLabs:

https://www.h-c0n.com/p/ctf.html#scoreboardqual

Enhorabuena a los clasificados y muchas gracias a todos los que habéis participado, con especial mención a aquellos que se han quedado a las puertas de poder entrar. ¡Seguro que el año que viene lo conseguís!

Por último os dejo con uno de los writeups recibidos por el bot, en este caso el de Joan M. aka magichk:

Tenemos 4 hosts idénticos para hacer el CTF con las siguientes direcciones IP:

X.X.X.70
X.X.X.71
X.X.X.72
X.X.X.73

Pues vamos primero de todo a enumerar. Para ello nos ayudaremos de la herramienta
nmap.


Encontramos cosas interesantes como el puerto 22, 80 y el 10000 abiertos.

Hacemos pruebas con dirb en el puerto 80 pero no encontramos nada relevante más que el index. Así que vamos al puerto 10000.

Por web ya vemos un error de python como este:

Clasificación para el CTF de la h-c0n 2019 - QUALS

Parece mentira que haya pasado ya un año... en un abrir y cerrar de ojos ya estamos de nuevo con la clasificación que dará derecho a participar en el CTF que realiza iHackLabs para la h-c0n 2019.

En esta ocasión podréis enfrentaros a una máquina estilo "Boot2Root" creada por Cesar Calderón aka @stuxnet, que se deberá vulnerar para conseguir las flags de usuario (user.txt) y de root (root.txt). 

Además este año y gracias también a Romam y Pabloko hemos levantado esta máquina de forma online y el juego se gestionará a través de un canal y bot en Telegram, abajo os detallamos el funcionamiento.

¿Estáis preparados? Sólo los 20 primeros se clasificarán para la final donde podrán optar a diferentes premios. 

La clasificación permanecerá abierta desde el martes 15 de enero a las 23:00 hasta el domingo 20 de enero a las 23:00 horas.

PARA PARTICIPAR SE DEBE ENTRAR AL CANAL DE TELEGRAM https://t.me/joinchat/AAAAAErBE50ArQ28Mh04yw DONDE SE PUBLICARÁ LA IP DE LA MÁQUINA Y EL SCOREBOARD.

GhostTunnel: establece un canal de comunicación encubierto a través de frames probe request y bacon (sin establecer una conexión WiFi)

GhostTunnel de 360PegasusTeam es una herramienta que usa un método de transmisión encubierto que puede usarse en entornos aislados: puede atacar a un objetivo a través de un dispositivo HiD WiFi para lanzar el payload/agente (luego puede quitarse el dispositivo correspondiente) con la particularidad de que GhostTunnel inserta datos en los frames 802.11 Probe Request y Beacon, pero no necesita establecer ninguna conexión wifi.

En el repo de Github teneis el servidor de GhostTunnel y el agente de Windows implementado en c/c++. El agente no necesita privilegios elevados, utiliza el api WiFi nativa del sistema para enviar el 'probe request' y recibir el beacon. También se puede implementar el agente correspondiente en otras plataformas. El servidor se ejecuta en Linux, necesita una o dos tarjetas wifi USB que sean compatibles con el modo monitor y la inyección de paquetes para ejecutarlo.

Ventajas
  • Sistema encubierto
  • No provoca ninguna interferencia con el estado de conexión existente y las comunicaciones del objetivo
  • Puede evadir los firewalls
  • Puede ser utilizado para atacar redes estrictamente aisladas
  • El canal de comunicación no depende de la conexión de red existente del objetivo
  • Permitir hasta 256 clientes
  • Alcance efectivo hasta 50 metros
  • Soporte multiplataforma
  • Se puede usar para atacar cualquier dispositivo con un módulo de comunicación inalámbrico; el ataque ha sido probado en Windows 7, Windows 10 y OSX.
Uso

- El servidor solo necesita una o dos tarjetas de red inalámbricas que sean compatibles con el modo de inyección de paquetes y monitor, como TP-LINK TL-WN722N, Alfa AWUS036ACH.
 ./ghosttunnel [interface]
 ./ghosttunnel [interface1] [interface2]

 COMMANDS:
     sessions = list all clients
     use = select a client to operate, use [clientID]
     exit = exit current operation
     wget = download a file from a client, wget [filepath]
     quit = quit ghost tunnel
     help = show this usage help

- El cliente lanza el payload al sistema objetivo y lo ejecuta

Funciones implementadas
  • Permite crear una shell remota
  • Descargas de archivos: el tamaño máximo del archivo es de 10M y solo puede descargar un archivo a la vez
  • Se pueden agregar otras funciones según sea necesario
Instalación

- Requisitos

apt-get install pkg-config libnl-3-dev libnl-genl-3-dev

- Compilado

Servidor:
    cd src
    make
Cliente Windows:
    Microsoft Visual Studio 2015

Proyecto Github: https://github.com/360PegasusTeam/GhostTunnel

Explotando Smasher (HTB): ROPeando para tocar el shellcode | Parte 1

Antes de nada, desear un feliz año 2019 a todos, que sea un gran año lleno de alegrías y mucho éxito. Después de esto y después de bastante tiempo, me dispongo a escribir la solución paso a paso para poder explotar satisfactoriamente el servidor vulnerable de la máquina Smasher de HackTheBox (ya descatalogada).

Como muchos ya saben por conversaciones en los grupos de Telegram y demás, el servicio que se debe atacar era vulnerable a un buffer overflow sin exploit público, por lo tanto deberemos elaborar nuestro propio exploit para conseguir ejecutar código en la máquina objetivo.

Esta explotación tengo pensada hacerla en dos partes: esta primera sobre una metodología de explotación más especifica sobre el binario, ciñendonos a las condiciones concretas del binario que veremos a continuación, y otro método un poco más general y que se puede emplear en más situaciones como es con la fuga de direcciones de funciones de la librería dinámica glibc...

No me pararé a explicar algunos conceptos, como el de ROP, dado que ya escribí otro entrada en la que explico todo de una manera más introductoria donde explico todo lo que se va a dar por entendido en esta entrada. Esta primera parte tratará por lo tanto de explotar el servicio de una manera más concreta, por lo tanto vamos a proceder con el análisis la vulnerabilidad y como podremos explotarla desde 0.

ANÁLISIS DE LA VULNERABILIDAD

Para empezar, explotando un LFI previo para poder descargar los ficheros correspondientes al servicio, tenemos la posibilidad de descargar el código fuente del binario (a pesar de ser público en Github), lo que nos facilitará cuantiosamente el análisis del binario.

Analizando la función main() se puede observar que tras aceptar una conexión al binario, se ejecuta una función llamada process() a la que se le pasa como argumentos el descriptor de la conexión aceptada e información relativa al socket.


Una de las primeras cosas que se realizan en esta función es "parsear" la petición que nosotros estamos realizando sobre el binario, esta acción se realiza a través de la función parse_request() que toma como argumentos el descriptor mencionado anteriormente y una estructura llamada http_request de la que hablaremos a continuación.


Ahora vamos a ver que sucede con la estructura http_request ya deberemos tenerla en cuenta en el futuro, en ella se almacenará información relativa a la petición que se realice, como por ejemplo, el fichero a abrir. Lo más llamativo de esta estructura es la declaración de un array de 512 caracteres donde se almacenará el nombre del fichero que deseamos abrir del servidor.


Siguiendo el hilo de la ejecución del programa, en la función, se puede observar que ser declarán diversos arrays de tamaño MAXLINE que en el programa está definido como 1024 (longitud máxima de una linea).