Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-18 09:03:30 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/generic-methodologies-and-resources/pentesting-network/webrtc-dos.md

5.5 KiB
Raw Blame History

WebRTC DoS

{% hint style="success" %} Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

Este problema foi encontrado neste post do blog: https://www.rtcsec.com/article/novel-dos-vulnerability-affecting-webrtc-media-servers/

A vulnerabilidade descrita nos servidores de mídia WebRTC surge de uma condição de corrida durante a inicialização das sessões de mídia, especificamente entre a verificação de consentimento de mídia ICE e a iniciação de tráfego DTLS. Aqui está uma análise detalhada:

Origem da Vulnerabilidade

  1. Alocação de Porta UDP: Quando um usuário inicia uma chamada WebRTC, o servidor de mídia aloca portas UDP para gerenciar os fluxos de mídia, com o IP e a porta comunicados via sinalização.
  2. Processos ICE e STUN: O navegador do usuário utiliza ICE para verificação de consentimento de mídia, utilizando STUN para determinar o caminho de conexão para o servidor de mídia.
  3. Sessão DTLS: Após a verificação bem-sucedida do STUN, uma sessão DTLS é iniciada para estabelecer chaves mestres SRTP, mudando para SRTP para o fluxo de mídia.

Mecanismo de Exploração

  • Exploração da Condição de Corrida: Um atacante pode explorar uma condição de corrida enviando uma mensagem DTLS ClientHello antes do usuário legítimo, potencialmente usando um conjunto de cifras inválido como TLS_NULL_WITH_NULL_NULL. Isso causa um erro DTLS no servidor, impedindo que a sessão SRTP seja estabelecida.

Processo de Ataque

  • Escaneamento de Portas: O atacante precisa adivinhar quais portas UDP estão lidando com sessões de mídia recebidas, enviando mensagens ClientHello com o conjunto de cifras nulo para essas portas para acionar a vulnerabilidade.
  • Diagrama do Ataque: A sequência envolve várias mensagens ClientHello enviadas pelo atacante para o servidor, intercaladas com sinalizações legítimas e mensagens DTLS, levando a uma falha de handshake devido ao conjunto de cifras errôneo.

Testes e Mitigação

  • Testes Seguros: Usando ferramentas como Scapy, os atacantes reproduzem mensagens DTLS ClientHello direcionadas a portas de mídia específicas. Para testes éticos, modificações no Chromium (por exemplo, JsepTransport::AddRemoteCandidates) foram usadas para imitar o comportamento da vítima de forma segura.
  • Medidas de Mitigação: As soluções envolvem descartar pacotes de endereços não verificados, conforme implementado em versões mais recentes de bibliotecas como libnice. A solução principal enfatiza confiar no processo de verificação ICE e processar apenas pacotes de combinações de IP e porta validadas.

Cenários Não Vulneráveis

  • Configurações do Servidor DTLS: Instâncias em que o navegador atua como um servidor DTLS ou quando o servidor de mídia não usa portas efêmeras para sessões de mídia não são suscetíveis a essa vulnerabilidade.

Conclusão

Essa vulnerabilidade destaca o delicado equilíbrio nos processos de inicialização de sessões de mídia e a necessidade de mecanismos de verificação e temporização precisos para prevenir a exploração. Os desenvolvedores são aconselhados a implementar correções de segurança recomendadas e garantir processos de verificação robustos para mitigar tais vulnerabilidades.

{% hint style="success" %} Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}