Técnicas de detección de VMs y contramedidas

Los desarrolladores de malware saben que sus artefactos va a ser irremediablemente analizados por threat hunters, forenses y demás "azulones" que intentarán destriparlos para obtener el detalle de su funcionamiento y obtener los IoCs correspondientes para contenerlos.  También saben que la mayoría serán analizados en  sandboxes con máquinas virtuales que pueden proporcionar un entorno aislado para que el malware se active, para que sus acciones puedan ser controladas e interceptadas.

Por ello los programas maliciosos de esta era detectan que se están ejecutando en una máquina virtual y actúan en consecuencia: se abstienen de inyectar código dentro de las aplicaciones, mantienen cifrado o encodeado el código malicioso, no conectan con los servidores de C&C, etc. y buena parte de sus esfuerzos se centran en utilizar técnicas más avanzadas para la detección. Por ejemplo, las últimas versiones del ransomware Locky añadían un nuevo "truco" anti-VM bastante curioso: realizaba dos llamadas a la API de Windows, GetProcessHeap () y CloseHandle () y dependiendo del tiempo de respuesta determinaba si estaba o no en una VM.

Pero veamos las técnicas más genéricas utilizadas por el malware de hoy en día para detectar el entorno virtualizado:

TÉCNICAS PARA DETECTAR ENTORNOS VIRTUALIZADOS

ARTEFACTOS DE UN ENTORNO VIRTUALIZADO

- Comprobación del registro: cada vez que generamos una nueva máquina virtual en el sistema operativo invitado hay muchas entradas en el registro relacionadas con el producto de virtualización utilizado y, como no podía ser de otra manera, el malware consulta la presencia de estas entradas. Por ejemplo en VMWare:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\0000\DriverDesc
VMware SCSI Controller
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\0000\ProviderName
VMware, Inc.

- Verificación de memoria: la ubicación de varias estructuras de memoria, especialmente la IDT (Interrupt Descriptor Table), varía en la máquina virtual en comparación con una máquina física.
El malware verifica el uso de varias estructuras de memoria como:

     . Almacenar tabla de descriptor de interrupciones (SIDT): en una máquina virtual, normalmente se encuentra en 0xffXXXXXX, mientras que, en una máquina física, se ubica algo más bajo que la típica alrededor de 0x80ffffff.

     . Otras estructuras que a menudo son controladas por malware son:
Store Local Descriptor Table (SLDT)
Store Global Descriptor Table (SGDT)
Store Task Register (STR)

- Verificación de procesos y archivos/directorios: por ejemplo, en todas las máquinas virtuales creadas con VMWare hay varios procesos que se siguen ejecutando en segundo plano, como VMwareService.exe, VMwareTray.exe, etc. Además, a veces VMware también instala algunas herramientas en la máquina virtual creada. También hay algunos drivers del sistema específicos para software de virtualización, que se pueden ubicar en la ruta: %windir%\system32\drivers\ con algunos nombres como: vmci.sys, vmhgfs.sys, vmmouse.sys, vmscsi.sys, vmusbmouse.sys, vmx_svga.sys, vmxnet.sys, VBoxMouse.sys. El software malicioso vigila todos los procesos y archivos para detectar el entorno VM.

Inmersión en la post-explotación tiene rima (by @CyberVaca_ #hc0n2019)

Vamos a empezar a publicar las presentaciones de las charlas de la h-c0n 2019 con la de uno de los ponentes mejor valorados durante la primera edición: Luis Vacas aka CyberVaka, compañero de batallas de nuestro grupo l1k0rd3b3ll0t4 y severo "castigador" de Güindous xD

En su charla de este año nos traía la suite Salsa Tools, un conjunto de herramientas escritas en C# que nos permitirán tener una shell reversa en cualquier entorno de Windows sin la necesidad de tener PowerShell para su ejecución. Esta suite está enfocada a tener mayor versatilidad, bypassear el antivirus y dificultar que obtengan el código.

La idea es separar el loader del payload, cifrar el payload, cargarlo en memoria y añadir métodos de transferencia. El payload siempre lo usaremos como string.

El resultado es un crypter, un payload y el loader:

- EncrypterAssembly: cifra el payload usando RC4. Tenemos la versión en python o exe.

- EvilSalsa: es el payload. Básicamente, lo que hace es cargar  System.Management.Automation.dll. Crea un espacio de ejecución con cuatro tipos de shells (TCP/UDP/ICMP/DNS). Cuando se carga EvilSalsa en el sistema, lo primero que hace es verificar si se encuentra "c:\windows\system32\amsi.dll" en el sistema, si lo está parcheado :D. El parche es una variante del parche de CyberArk y Rastamouse.

- SalseoLoader: se encarga de cargar el payload cifrado. SalseoLoader puede compilarse como una librería o como un ejecutable. En el caso de que se compile como ejecutable, solo debemos pasar el argumento que queremos ejecutar. Si lo compilamos como una librería tendremos que realizar una exportación del descriptor "main", y la forma de crear el argumento se realiza a través de la lectura de variables de entorno.

Podéis encontrar todo el software en el repo de Github: https://github.com/Hackplayers/Salsa-tools/

Os dejo la presentación y los videos de demo que usó en su charla de la h-c0n 2019:


Bashfuscator: un framework para ofuscar Bash


Bashfuscator es un framework modular y extensible escrito en Python 3 para ofuscar Bash. A través de esta herramienta dispondremos de muchas formas diferentes de hacer que los one-liners o scripts en bash sean mucho más difíciles de entender. Esto se logra generando un código Bash aleatorio y enrevesado que, en tiempo de ejecución, se evalúa en la entrada original y la ejecuta. Bashfuscator hace que la generación de comandos y scripts Bash muy confusos sea fácil, tanto desde la línea de comandos como desde una librería de Python.

El propósito de este proyecto es dar a un Red Team la capacidad de evitar las detecciones estáticas en un sistema Linux, y el conocimiento y las herramientas para escribir mejor las técnicas de ofuscación de Bash. Aunque también este framework fue desarrollado teniendo en cuenta al Blue Team, ya que puede generar fácilmente miles de comandos o comandos ofuscados únicos para ayudar a crear y probar las detecciones de la ofuscación de Bash.

Soporte de payloads

Aunque Bashfuscator funciona en sistemas UNIX, muchos de los payloads que genera no lo harán. Esto se debe a que la mayoría de los sistemas UNIX utilizan utilidades basadas en BSD, y Bashfuscator fue construido para funcionar con utilidades basadas en GNU. En el futuro, se puede agregar el soporte de payload BSD, pero por ahora los que se generan con Bashfuscator deberían funcionar en sistemas GNU Linux con Bash 4.0 o más reciente.

Requisitos de instalación

Bashfuscator requiere Python 3.6+.

En una distribución basada en Debian, ejecuta este comando para instalar las dependencias:

sudo apt-get update && sudo apt-get install python3 python3-pip python3-argcomplete xclip

En una distribución basada en RHEL, ejecuta este comando para instalar las dependencias:

sudo dnf update && sudo dnf install python3 python3-pip python3-argcomplete xclip

Luego, ejecuta estos comandos para clonar e instalar Bashfuscator:

git clone https://github.com/Bashfuscator/Bashfuscator
cd bashfuscator
python3 setup.py install --user

Solo se admiten las distribuciones basadas en Debian y RHEL. Aunque Bashfuscator ha sido probado en algunos sistemas UNIX no llega ser todavía compatible.

#hc0n2019 : Crónica de la segunda conferencia de @Hackplayers


Cuando era pequeño recuerdo que una vez mi padre me dijo que era mucho más difícil y valioso construir algo que destruirlo. Él era albañil así que usó el símil de una pared de ladrillos: reventar un muro a mazazos es mucho más fácil y rápido que tener que construirlo... y realmente es así, crear es más laborioso y debe hacerse "ladrillo a ladrillo", desde la base del suelo hacia el cielo, tan alto como quieras o te empeñes que llegue. Así nació Hackplayers hace 10 años, desde abajo del todo, empecé con un ladrillo, luego con otro, después otro tras otro y hoy todavía esa construcción sigue creciendo, un viaje en el que muchos amigos se han ido sumando poniendo también ladrillos, levantando juntos nuevos proyectos como nuestra propia conferencia: la h-c0n.

No sé cuánto tiempo resistirá en pie esta parte del muro, ni qué tan alto llegará; sólo que estoy tremendamente satisfecho de lo que hemos construido hasta ahora, un evento con una gran acogida donde todos los participantes terminan contentos (nuestro mayor logro) para convertirse en un punto de encuentro entre profesionales, estudiantes y en definitiva apasionados por un interés común: el hacking y la in-seguridad informática.

En esta nuestra segunda edición, que tuvo lugar el 8 y 9 de febrero, intentamos ser bastante continuistas con respecto a la anterior. ¿Por qué?, pues porque creemos que el año pasado salió todo muy bien y porque teníamos prácticamente la posibilidad de contar con los mismos ingredientes, lo que se traducía en una oportunidad de consolidar el Congreso y dar un pasito más. Así que el formato fue similar: mismo escenario, mismo tipo de CTF, sorteos y descuentos para los asistentes y la posibilidad de disfrutar de 12 charlas y 4 talleres de una temática amplia y diversa. Precisamente porque una de las novedades de este año fue poner en liza un "Call For Papers" para poder elegir análisis de malware, Threat intelligence, Red Team, Wireless hacking, Exploiting, Reversing, Hardware, IoT, Pentesting, Mobile, Radio, Privacidad y anonimato... casi nada.


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.