Do tradutor e TL;DR
TL;DR:
Parece que o VoLTE está ainda mais vulnerável do que os primeiros clientes Wi-Fi com WEP. Um erro arquitetônico que permite manipular um pouco o tráfego e recuperar a chave. O ataque é possível se você estiver próximo da pessoa que está fazendo a ligação e essa pessoa fizer chamadas com frequência.
Obrigado pela dica e TL;DR
Pesquisadores desenvolveram um aplicativo para verificar se seu operador é vulnerável, veja mais detalhes . Compartilhe nos comentários os resultados; na minha região, o VoLTE está desativado no MegaFon.
Sobre o autor
Matthew Green.
Sou criptógrafo e professor na Universidade Johns Hopkins. Desenvolvi e analisei sistemas criptográficos usados em redes sem fio, sistemas de pagamento e plataformas de proteção de conteúdo digital. Em minhas pesquisas, exploro várias maneiras de usar criptografia para melhorar a privacidade dos usuários.
Faz tempo que não escrevo um post do tipo , e isso me incomodava. Não porque não houvesse ataques, mas principalmente porque não havia ataques a algo amplamente utilizado que me tirasse da crise criativa.
Mas hoje me deparei com chamado ReVoLTE em protocolos cuja vulnerabilidade me deixa particularmente satisfeito, ou seja, os protocolos de redes móveis (voice over) LTE. Fico empolgado com esses protocolos – e este novo ataque – porque é muito raro observar a exploração de protocolos reais e implementações de redes móveis. Principalmente porque esses padrões são desenvolvidos em salas fumacentas e documentados em documentos de 12.000 páginas que não são acessíveis a qualquer pesquisador. Além disso, a implementação desses ataques exige que os pesquisadores utilizem protocolos de rádio complexos.
Assim, sérias vulnerabilidades criptográficas podem se espalhar pelo mundo e podem ser utilizadas apenas por governos, antes que algum pesquisador preste atenção nelas. Mas de vez em quando há exceções, e o ataque de hoje é uma delas.
Autores : David Rupprecht, Katharina Kohls, Thorsten Holz e Christina Pöpper da Universidade de Ruhr em Bochum e da Universidade de Nova York em Abu Dhabi. Este é um excelente ataque à reinicialização da chave em um protocolo de voz que você provavelmente já está usando (supondo que você seja da geração mais velha que ainda faz chamadas telefônicas usando o celular).
Para começar – uma breve excursão histórica.
O que é LTE e VoLTE?
A base para nossos padrões modernos de telefonia móvel foi estabelecida na Europa nos anos 80 com o padrão (Sistema Global para Comunicações Móveis). O GSM foi o primeiro padrão importante de telefonia celular digital que introduziu uma série de funções revolucionárias, como o uso de para proteger as chamadas telefônicas. O GSM inicial foi desenvolvido principalmente para comunicação de voz, embora, por uma taxa, fosse possível .
À medida que a importância da transmissão de dados em telefonia móvel aumentava, foram desenvolvidos padrões de Long Term Evolution (LTE) para otimizar esse tipo de comunicação. O LTE baseia-se em um grupo de padrões mais antigos, como GSM, e e destina-se a aumentar a velocidade de troca de dados. Nesta área, há muita marcação e , mas TL;DR é que LTE é um sistema de transmissão de dados que serve como uma ponte entre os antigos protocolos de transmissão de dados e as futuras tecnologias de transmissão de dados móveis .
Obviamente, a história nos diz que assim que houver largura de banda (IP) suficiente, conceitos como “voz” e “dados” começarão a se confundir. O mesmo se aplica aos protocolos móveis modernos. Para tornar essa transição mais suave, os padrões LTE definem (VoLTE), que é um padrão IP para a transmissão de chamadas de voz diretamente pela camada de dados do sistema LTE, contornando totalmente a parte comutada da rede móvel. Assim como nas chamadas padrão as chamadas VoLTE podem ser terminadas pelo operador da rede móvel e conectadas à rede telefônica convencional. Ou (o que está se tornando cada vez mais comum) elas diretamente de um cliente de celular para outro, e até mesmo entre diferentes provedores.
Assim como o VoIP padrão, o VoLTE é baseado em dois protocolos populares baseados em IP: o protocolo de iniciação de sessão ( – SIP) para estabelecer a chamada, e o protocolo de transporte em tempo real (, que deveria ser chamado de RTTP, mas na verdade é chamado de RTP) para processar os dados de voz. O VoLTE também adiciona algumas otimizações adicionais de largura de banda, como compressão de cabeçalhos.
Bem, qual é a relação disso com a criptografia?
O LTE, assim como , possui um conjunto padrão de protocolos criptográficos para criptografar pacotes enquanto são transmitidos pelo ar. Eles são principalmente destinados a proteger seus dados enquanto estão se movendo entre o telefone (chamado de 'equipamento do usuário', ou UE) e a torre de celular (ou onde quer que seu provedor decida finalizar a conexão). Isso ocorre porque os provedores de celular veem dispositivos de escuta externa como inimigos. Bem, claro.
(No entanto, o fato de que as conexões VoLTE podem ocorrer diretamente entre clientes em diferentes redes de provedores significa que o próprio protocolo VoLTE tem alguns protocolos de criptografia adicionais e opcionais que podem ocorrer em níveis de rede mais altos. Isso não se aplica ao artigo atual, exceto pelo fato de que eles podem estragar tudo. Vamos falar brevemente sobre eles a seguir).
Historicamente, a criptografia no GSM teve : criptografias ruins, ‘Stingray’ Vamos começar pela própria criptografia. Se assumirmos que a criação da chave já ocorreu — e vamos falar sobre isso em um minuto — então cada pacote de dados é criptografado usando um modo de fluxo de criptografia com um certo criptógrafo chamado 'EEA' (que na prática pode ser implementado com coisas como AES). Essencialmente, o mecanismo de criptografia aqui é
CTR , como mostrado abaixo:
O algoritmo principal de criptografia de pacotes VoLTE (fonte: ). EEA – cifra, “COUNT” – contador de 32 bits, “BEARER” – identificador único da sessão que separa conexões VoLTE do tráfego de internet convencional. “DIRECTION” indica a direção do tráfego – do UE para a torre ou vice-versa.
Como o próprio algoritmo de criptografia (EEA) pode ser implementado usando uma cifra forte como AES, é improvável que haja um ataque direto à própria cifra, como isso No entanto, é óbvio que, mesmo com uma cifra forte, esse esquema de criptografia representa uma excelente maneira de se auto-sabotar.
Em particular: o padrão LTE usa uma cifra de fluxo (não autenticada) com um modo que será extremamente vulnerável se o contador – e outras entradas, como “bearer” e “direction” – forem usados novamente. No jargão moderno, o termo para esse conceito é “ataque de reutilização de nonce”, mas os riscos potenciais aqui não são modernos. Eles são conhecidos e antigos, remontando à época do glam metal e até disco.
Ataques de reutilização de nonce no modo CTR existiam desde a época em que o Poison se tornou conhecido.
Para ser justo, os padrões LTE dizem: “Não reutilize esses contadores, por favor”. Mas os padrões LTE ocupam cerca de 7000 páginas, e, de qualquer forma, é como implorar para crianças não brincarem com uma pistola. Elas inevitavelmente o farão, e coisas terríveis acontecerão. Neste caso, a pistola descarregada é o ataque de reutilização do fluxo de chave, onde duas mensagens confidenciais diferentes são XORadas com os mesmos bytes do fluxo de chave. Sabe-se que isso .
O que é ReVoLTE?
O ataque ReVoLTE demonstra que, na prática, essa construção de criptografia extremamente vulnerável está sendo mal utilizada por equipamentos reais. Especificamente, os autores analisam chamadas VoLTE reais feitas com equipamentos comerciais e mostram que podem utilizar algo chamado “ataque de reinstalação de chave”. (Grande mérito na identificação desse problema vai para (Raza & Lu), que foram os primeiros a apontar uma vulnerabilidade potencial. Mas as pesquisas ReVoLTE transformam isso em um ataque prático).
Deixe-me mostrar brevemente a essência do ataque, embora você deva também dar uma olhada no .
Pode-se supor que assim que o LTE estabelece uma conexão de transmissão de dados, a tarefa de transmitir voz via LTE se torna apenas uma questão de roteamento dos pacotes de voz por essa conexão junto com todo o seu outro tráfego. Em outras palavras, VoLTE será um conceito que existe apenas sobre [modelos OSI – exemplo.] Isso não é bem assim.
Na verdade, o nível de enlace do LTE introduz o conceito de "bearer". Bearer são identificadores de sessões separados que diferenciam vários tipos de tráfego de pacotes. O tráfego normal de internet (seu Twitter e Snapchat) passa por um bearer. A sinalização SIP para VoIP passa por outro, enquanto os pacotes de tráfego de voz são processados em um terceiro. Eu não sou muito bem versado nos mecanismos de canais de rádio e roteamento de rede do LTE, mas suponho que isso é feito dessa maneira porque as redes LTE querem garantir a operação dos mecanismos de QoS (qualidade de serviço), para que diferentes fluxos de pacotes sejam tratados com diferentes níveis de prioridade: ou seja, suas conexões TCP secundárias com o Facebook podem ter prioridade mais baixa do que suas chamadas de voz em tempo real.
Isso não é essencialmente um problema, mas as consequências são as seguintes. As chaves de criptografia do LTE são geradas separadamente cada vez que um novo "bearer" é estabelecido. Em princípio, isso deve ocorrer novamente toda vez que você faz uma nova chamada telefônica. Isso resulta na utilização de uma chave de criptografia diferente para cada chamada, o que elimina a possibilidade de reutilizar a mesma chave para criptografar dois conjuntos diferentes de pacotes de chamadas de voz. De fato, o padrão LTE diz algo como "você deve usar chaves diferentes toda vez que estabelecer um novo bearer para processar uma nova chamada telefônica". Mas isso não significa que isso realmente aconteça.
Na verdade, em implementações reais, duas chamadas diferentes, ocorrendo em proximidade temporal imediata, usarão a mesma chave - mesmo que novos bearer (com o mesmo nome) sejam configurados entre elas. A única mudança prática que ocorre entre essas chamadas é que o contador de criptografia é redefinido para zero. Na literatura, isso é às vezes chamado de . Pode-se argumentar que, em essência, isso é um erro de implementação, embora, nesse caso, os riscos pareçam em grande parte derivar do próprio padrão.
Na prática, esse ataque leva à reutilização do fluxo de chave, onde um invasor pode obter pacotes criptografados $inline$C_1 = M_1 oplus KS$inline$ e $inline$C_2 = M_2 oplus KS$inline$, o que permite calcular $inline$C_1 oplus C_2 = M_1 oplus M_2$inline$. Melhor ainda, se o invasor conhecer um dos $inline$M_1$inline$ ou $inline$M_2$inline$, ele pode imediatamente recuperar o outro. Isso lhe dá um forte incentivo para descobrir um dos dois componentes não criptografados.
Isso nos leva ao cenário de ataque mais completo e eficaz. Vamos considerar um invasor que pode interceptar o tráfego de rádio entre o telefone alvo e a torre de celular, e que de alguma forma 'teve a sorte' de gravar duas chamadas diferentes, onde a segunda ocorre imediatamente após a primeira. Agora imagine que ele pode adivinhar o conteúdo não criptografado de uma das chamadas. Com tal sorte repentina nosso invasor pode descriptografar completamente a primeira chamada, usando um simples XOR entre dois conjuntos de pacotes.
Naturalmente, a sorte não tem nada a ver com isso. Como os telefones são projetados para receber chamadas, um invasor que pode escutar a primeira chamada será capaz de iniciar a segunda chamada exatamente no momento em que a primeira terminar. Essa segunda chamada, se reutilizar a mesma chave de criptografia com o contador redefinido para zero, permitirá recuperar os dados não criptografados. Além disso, como nosso invasor controla efetivamente os dados durante a segunda chamada, ele pode recuperar o conteúdo da primeira chamada – graças a uma série de pequenas particularidades, que trabalham a seu favor.
Aqui está uma imagem do plano geral do ataque, tirada de :
Visão geral do ataque de . Este esquema assume que duas chamadas diferentes ocorrem usando a mesma chave. O atacante controla um sniffer passivo (no canto superior esquerdo), bem como um segundo telefone, com o qual pode fazer uma segunda chamada para o telefone da vítima.
Então, o ataque realmente funciona?
Por um lado, essa é a verdadeira questão para um artigo sobre ReVoLTE. Teoricamente, todas as ideias mencionadas acima são ótimas, mas deixam muitas perguntas. Como por exemplo:
- É possível (para pesquisadores acadêmicos) realmente interceptar uma conexão VoLTE?
- As reais sistemas LTE realmente reinstalam as chaves?
- Você pode realmente iniciar uma segunda chamada rápida e confiavelmente o suficiente para que o telefone e a torre reaproveitem a chave?
- Mesmo se os sistemas reinstalarem as chaves, você pode realmente saber o conteúdo não criptografado da segunda chamada – considerando que fatores como codecs e recodificação podem mudar completamente (bit a bit) o conteúdo dessa segunda chamada, mesmo que você tenha acesso aos "bits" que vêm do seu telefone atacante?
Algumas dessas perguntas são respondidas afirmativamente pelo trabalho da ReVoLTE. Os autores usam um sniffer de fluxo de rádio comercialmente reconfigurável chamado para interceptar a chamada VoLTE do lado descendente. (Acho que dominar o software e entender aproximadamente como ele funciona custou meses da vida dos pobres graduandos – o que é típico em pesquisas acadêmicas deste tipo).
Os pesquisadores descobriram que, para que a reutilização da chave funcione, a segunda chamada deve ocorrer rapidamente após a conclusão da primeira, mas não muito – cerca de dez segundos para as operadoras com as quais eles experimentaram. Felizmente, não importa se o usuário atende a ligação nesse período – a "chamada", ou seja, a própria comunicação SIP, faz com que a operadora reutilize a mesma chave.
Assim, muitos dos problemas mais graves giram em torno da questão (4) – obter os bits do conteúdo não criptografado da chamada iniciada pelo atacante. Isso ocorre porque pode acontecer muito com seu conteúdo enquanto ele transita do telefone do criminoso para o telefone da vítima através da rede celular. Por exemplo, truques como a reencodificação do fluxo de áudio criptografado, que mantém o som o mesmo, mas muda completamente sua representação binária. Em redes LTE, a compressão de cabeçalhos RTP também é utilizada, o que pode alterar substancialmente grande parte do pacote RTP.
Finalmente, os pacotes enviados pelo criminoso devem se alinhar aproximadamente com os pacotes que foram enviados durante a primeira chamada telefônica. Isso pode ser problemático, já que a modificação do silêncio durante a chamada torna as mensagens mais curtas (o chamado ruído de conforto), o que pode não se alinhar bem com a chamada original.
vale a pena ler em todos os detalhes. Nela, muitas das questões mencionadas acima são discutidas – em particular, os autores descobriram que alguns codecs não são reencodificados, e que aproximadamente 89% da representação binária da chamada alvo pode ser recuperada. Isso é relevante para pelo menos dois operadores europeus que foram testados.
É um nível de sucesso surpreendentemente alto e, francamente, muito mais alto do que eu esperava ao começar a trabalhar neste documento.
Então, o que podemos fazer para corrigir isso?
A resposta urgente a essa pergunta é extremamente simples: uma vez que a essência da vulnerabilidade está no ataque de reuso (reinicialização) da chave, basta corrigir esse problema. Certifique-se de que uma nova chave seja obtida para cada chamada telefônica e nunca permita que o contador de pacotes reinicie para zero usando a mesma chave. Problema resolvido!
Ou talvez não. Isso exigiria a modernização de uma grande quantidade de equipamentos e, sinceramente, essa solução sozinha não é super confiável. Seria bom se os padrões conseguissem encontrar uma maneira mais segura de implementar seus modos de criptografia, que não seja, por padrão, catastróficamente vulnerável a problemas semelhantes de reutilização de chaves.
Uma das possíveis opções é o uso de . Isso pode ser muito caro para alguns equipamentos modernos, mas é definitivamente uma direção que os projetistas devem considerar no futuro, especialmente levando em conta que os padrões 5G estão prestes a dominar o mundo.
Esta nova pesquisa também levanta a questão geral de por que , muitos dos quais usam construções e protocolos muito semelhantes. Quando você se depara com o problema de reinstalar a mesma chave em vários protocolos amplamente utilizados, como WPA2, não parece que talvez seja hora de tornar suas especificações e procedimentos de testes mais confiáveis? Já passou da hora de tratar os implementadores de padrões como parceiros reflexivos, atentos aos seus avisos. Trate-os como (não intencionais) adversários que inevitavelmente vão implementar tudo errado.
Ou, como alternativa, podemos fazer o que empresas como Facebook e Apple estão fazendo cada vez mais: fazer com que a criptografia de chamadas de voz ocorra em um nível mais alto da pilha de rede OSI, sem depender dos fabricantes de equipamentos de telefonia móvel. Podemos até promover a criptografia de ponta a ponta para chamadas de voz, como WhatsApp fez com Signal e FaceTime, supondo que o governo dos EUA simplesmente pare de . Então (exceto por alguns metadados), muitos desses problemas simplesmente desapareceriam. Esta solução é especialmente relevante em um mundo onde .
Ou podemos simplesmente fazer o que já fizeram nossos filhos: parar de responder a essas chamadas de voz irritantes.
Fonte: habr.com
