WebRTC DoS
Aprenda e pratique Hacking AWS:
HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: 
HackTricks Training GCP Red Team Expert (GRTE)
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
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.
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.
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.
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Last updated