LTESniffer: grampeador open source de downlink/uplink LTE

 (github.com/SysSec-KAIST)
1 pontos por GN⁺ 2024-10-23 | 1 comentários | Compartilhar no WhatsApp
  • LTESniffer é uma ferramenta open source que captura mensagens sem fio de downlink e uplink entre estações rádio base LTE e smartphones e, após obter primeiro DCI e RNTI no PDCCH, decodifica PDSCH e PUSCH para analisar o tráfego de dados
  • Não consegue descriptografar mensagens criptografadas; só é possível analisar partes não criptografadas, como cabeçalhos MAC e da camada física, além de mensagens de broadcast da estação rádio base e mensagens iniciais da conexão em texto claro
  • A API para pesquisa de segurança oferece três recursos: identity mapping, coleta de IMSI e profiling de capacidades de UE; a implementação busca complementar a exigência de sniffers passivos assumida em pesquisas anteriores de segurança LTE com decodificação de pacotes de protocolo PDSCH e PUSCH
  • O escopo funcional inclui LTE Advanced e LTE Advanced Pro, até 256QAM em uplink e downlink, FDD, estações rádio base de até 20MHz, formatos DCI 0/1A/1/1B/1C/2/2A/2B e modos de transmissão 1~4
  • A decodificação em tempo real exige CPU com múltiplos núcleos físicos e configuração SDR; para coletar tráfego de uplink, como o sinal do UE é fraco, o sniffer precisa estar próximo do smartphone ou contar com reforço de hardware, como antena direcional, front-end RF e amplificador

O que o LTESniffer faz

  • LTESniffer é um grampo open source que captura tanto o downlink quanto o uplink LTE
  • O fluxo de funcionamento primeiro decodifica o PDCCH para obter DCI e RNTI dos usuários ativos e, com isso, decodifica adicionalmente PDSCH e PUSCH para obter o tráfego de dados de uplink e downlink
  • Do ponto de vista de um usuário comum, é uma ferramenta que captura em ambas as direções as mensagens sem fio LTE trocadas entre a estação rádio base e o smartphone conectado
  • Não consegue descriptografar mensagens criptografadas
    • Em mensagens criptografadas, é possível analisar partes não criptografadas, como cabeçalhos MAC e da camada física
    • Mensagens de broadcast da estação rádio base transmitidas em texto claro ou mensagens iniciais da conexão podem ser analisadas por completo

API de pesquisa em segurança e objetivo da pesquisa

  • O LTESniffer oferece 3 funções de API para aplicações e pesquisas de segurança
    • identity mapping
    • IMSI collecting
    • UE capability profiling
  • Muitas pesquisas de segurança LTE assumem um sniffer passivo capaz de capturar pacotes relacionados à privacidade pelo ar, mas os sniffers open source existentes, segundo o projeto, não atendem a esse requisito porque não conseguem decodificar os pacotes de protocolo de PDSCH e PUSCH
  • Mais detalhes estão organizados no artigo
  • O principal objetivo do LTESniffer é apoiar pesquisas de segurança e análise de redes celulares
    • Como coleta dados de usuários em uplink e downlink, é preciso seguir as regulamentações locais sobre sniffing de tráfego LTE
    • Os desenvolvedores não se responsabilizam por uso com fins ilegais, como coletar deliberadamente informações relacionadas à privacidade de usuários

Recursos suportados e base de implementação

  • O LTESniffer foi implementado sobre o FALCON e usa a biblioteca srsRAN
  • O principal escopo de suporte é o seguinte
    • Decodificação em tempo real de uplink e downlink dos canais de controle e dados PDCCH, PDSCH, PUSCH
    • LTE Advanced e LTE Advanced Pro
    • Até 256QAM tanto em uplink quanto em downlink
    • Formatos DCI 0, 1A, 1, 1B, 1C, 2, 2A, 2B
    • Modos de transmissão 1, 2, 3, 4

    • Suporte apenas a FDD

      • Estações rádio base de até 20MHz
      • Detecção automática do esquema máximo de modulação UL/DL por smartphone
      • Detecção automática da configuração da camada física por UE
      • RNTI-TMSI mapping, IMSI collecting, UE Capability Profiling
      • A atualização v2.1.0 adiciona gravação de arquivos de IQ raw data de subframe, decodificação offline usando os arquivos gravados e ativação da API no modo downlink
      • A API do modo downlink se aplica apenas às APIs de identity collecting e mapping
      • Mais informações estão no branch LTESniffer-record-subframe e no README
      • A atualização v2.0.0 passa a suportar o uso de duas USRP B-series no modo de sniffing de uplink e corrige bugs
      • Mais informações estão no branch LTESniffer-multi-usrp e no README

Requisitos de hardware e software

  • Os sistemas operacionais com funcionamento estável são Ubuntu 18.04/20.04/22.04
  • A decodificação de tráfego LTE em tempo real exige uma CPU de alto desempenho com múltiplos núcleos físicos nos horários de pico, quando há muitos usuários ativos na estação rádio base
    • Há um caso de decodificação em tempo real do tráfego de uma estação rádio base com 150 usuários ativos em um PC com Intel i7-9700K
    • A configuração recomendada é CPU Intel i7 com 8 ou mais núcleos físicos, 16GB ou mais de RAM e SSD de 256GB
  • Ao sniffar apenas o downlink, é possível usar a maioria dos SDRs compatíveis com srsRAN
    • Exemplos: USRP ou BladeRF
    • O SDR deve ser conectado ao PC via USB 3.0
    • Para decodificar mensagens de downlink nos modos de transmissão 3 e 4, são necessárias 2 antenas RX
    • Se houver apenas 1 antena RX, só será possível decodificar mensagens de downlink no modo de transmissão 1
    • O GPSDO ajuda a melhorar a sincronização no sniffing de downlink, mas não é obrigatório
  • O sniffing de uplink precisa ouvir simultaneamente duas frequências, de uplink e downlink, então há duas configurações suportadas
    • USRP X310 único: 2 canais RX podem ser ajustados para frequências diferentes de uplink e downlink, e o GPSDO é opcional
    • 2 USRP B-Series: usa B210/B200 separadamente para uplink e downlink, e o GPSDO como clock source e time reference para sincronizar as duas USRP
    • Na configuração com 2 USRP B-Series, o GPSDO é obrigatório

Fluxo de instalação e execução

  • Antes de compilar o código-fonte, é necessário instalar UHD 4.0 ou superior, sendo recomendada a compilação a partir do código-fonte
  • Depois de instalar as dependências do srsRAN e do LTESniffer, o repositório é clonado e a compilação é feita com cmake e make -j 4
  • Após a compilação, o executável fica em <build-dir>/src/LTESniffer
  • Há 3 modos principais de execução
    • Sniffing do tráfego LTE de downlink vindo da estação rádio base
    • Sniffing do tráfego LTE de uplink indo do smartphone para a estação rádio base
    • API de segurança
  • Antes de usar em rede comercial, é preciso verificar as regulamentações locais sobre sniffing de tráfego LTE
  • Para verificar a estação rádio base à qual o smartphone de teste está conectado e as bandas de uplink/downlink, pode-se usar o Cellular-Z para Android
    • O LTESniffer também precisa estar conectado à mesma célula e frequência

Saída e análise

  • O LTESniffer fornece como saída arquivos pcap, que podem ser analisados posteriormente e rastreados no Wireshark
  • Os nomes dos arquivos gerados variam conforme o modo
    • Downlink: sniffer_dl_mode.pcap
    • Uplink: sniffer_ul_mode.pcap
    • API: api_collector.pcap
  • Os arquivos pcap são gerados no mesmo diretório em que o LTESniffer é executado
  • Para que o Wireshark analise corretamente os pacotes decodificados, é preciso consultar o guia de configuração em pcap_file_example/README.md
  • O arquivo pcap de uplink inclui mensagens tanto de uplink quanto de downlink
    • Para ver apenas uplink, use o filtro mac-lte.direction == 0
    • Para ver apenas downlink, use o filtro mac-lte.direction == 1

Limitações de distância no sniffing de uplink

  • O alcance efetivo de uplink do LTESniffer é limitado pelo desempenho do front-end RF, como o SDR
  • Como o UE é um dispositivo móvel otimizado para uso de bateria, a potência do sinal de uplink é muito mais fraca que o sinal de downlink da estação rádio base
  • Para capturar com sucesso o tráfego de uplink, a potência do sinal recebido pode ser aumentada das seguintes formas
    • Ficar fisicamente próximo ao UE
    • Usar hardware especial, como antena direcional, front-end RF dedicado e amplificador de sinal

Limitações e alternativas descritas no FAQ

  • O GPSDO é útil para uma sincronização mais estável, mas no sniffing de downlink é possível sincronizar com o sinal LTE e decodificar pacotes mesmo sem GPSDO
  • No sniffing de uplink, o GPSDO só é necessário ao usar 2 USRP B-series
    • A configuração com um único USRP X310 não exige GPSDO
  • O tráfego de downlink também pode funcionar tecnicamente em SDRs como o BladeRF, suportados pela biblioteca srsRAN
    • Porém, os testes do recurso de downlink do LTESniffer foram feitos apenas com USRP B210 e X310
  • A legalidade do uso do LTESniffer exige verificar as regulamentações locais sobre sniffing de tráfego LTE não criptografado
    • Como alternativa de teste, é sugerida a montagem de uma rede LTE privada baseada em srsRAN dentro de uma gaiola de Faraday
  • O conteúdo das mensagens entre dois usuários só pode ser visto nas partes não criptografadas
    • A maior parte do tráfego sem fio entre a estação rádio base e o usuário é criptografada
  • A literatura menciona vários identificadores expostos em texto claro em redes LTE, como TMSI, GUTI, IMSI e RNTI

Leituras relacionadas

1 comentários

 
GN⁺ 2024-10-23
Opiniões no Hacker News

  • É ótimo que os padrões de redes móveis sejam cheios de siglas
    Caso você não soubesse, o Q em PHICH significa "request"

    • Para quem ficou se perguntando do que estão falando acima: PHICH não aparece no projeto referenciado, mas é um exemplo de sigla esquisita de redes móveis, significando "Physical channel HybridARQ Indicator Channel"
      O "ARQ" ali provavelmente pode ser expandido como https://en.wikipedia.org/wiki/Automatic_repeat_request
      Algumas pessoas talvez digam que o "Q" em "ARQ" na verdade é "query", e que quem expande como "request" está presumindo um nível médio de vocabulário baixo
      Pessoalmente, pensando bem, acho mais provável que o Q não seja "request" nem "query", mas outro vestígio dos códigos Q convencionalmente opacos de https://en.wikipedia.org/wiki/Q_code
    • Achei que fosse piada
      Aqui está o Q dentro de PHICH: https://github.com/srsran/srsRAN_4G/blob/master/lib/src/phy/...
      Como no comentário irmão, q é o Q de reQuest

  • Parece bom
    Ele suporta apenas FDD, não TDD, e é limitado a 20 MHz, então há algumas restrições
    Também parece conseguir fazer algum grau de decodificação em tempo real, o que é interessante. Nas estações-base, uma parte grande do processamento é feita por processadores bastante genéricos, mas ainda assim eles são muito mais integrados ao hardware do que este software

  • Pena que o hardware para rodar isso é caro demais :'(

  • Saindo um pouco pela tangente, fico curioso se alguém já tentou fazer interceptação de DSL
    DSL moderno, especialmente VDSL2, é essencialmente um sinal de alta frequência trafegando por pares trançados sem blindagem, então, com coisas como derivações na linha, ele deve vazar e irradiar facilmente
    Ao que parece, isso de fato acontece a ponto de radioamadores no Reino Unido reclamarem bastante disso[1]. Fico me perguntando se ainda seria possível demodular esse sinal, ou se ele é apenas um ruído de referência irritante no espectro
    [1]: https://rsgb.services/public/publications/vdsl/measuring_and...

  • Um fato interessante e pouco conhecido é que as primeiras gerações de celulares digitais estão em uma zona cinzenta de dificuldade de descriptografia
    Não é nada fácil, mas é fácil o suficiente para ser quebrável. A criptografia foi de fato quebrada
    A rainbow table tem 2 TB e levou meses para ser criada: https://github.com/0xh4di/GSMDecryption?tab=readme-ov-file
    Agora fico me perguntando se também existem algumas brechas de descriptografia nas gerações posteriores, por estes ou aqueles motivos, ou por causa de determinados atores estatais

  • Trabalho divertido, e é bom ver esse tipo de open source ainda sendo usado
    Cerca de 10 anos atrás, em um laboratório universitário de pesquisa em segurança de redes, fiz interceptação de downlink
    Um dos projetos era medir quanto a atividade das células caía durante as férias de primavera; outro era ver se, para um número de telefone conhecido em uma localização conhecida, era possível extrair o ID temporário por meio de um ataque de temporização e, com chamadas repetidas, verificar se ele ainda estava naquela área
    Na minha opinião, aquele ID temporário não era temporário o suficiente. Dá vontade de mexer nisso de novo

  • Também existem alguns dongles 4G com modos de depuração quebrados conhecidos, que podem ser usados para extrair informações

  • O LTESniffer é chamado de open source, mas não parece haver um arquivo LICENSE no nível raiz nem uma configuração de licença no repositório do GitHub

    • A maioria dos arquivos-fonte tem cabeçalhos de copyright dizendo que o código é AGPLv3 e que foi bifurcado dos projetos existentes https://github.com/falkenber9/falcon e https://github.com/srsran/srsRAN_Project, que têm arquivo LICENSE no nível raiz
      O certo seria adicionar um arquivo LICENSE no nível raiz para cobrir também os arquivos de build e outros arquivos de suporte