Testando a segurança do GSM

GSM security testing: where the action is

Autor original: Jonathan Corbet

Publicado originalmente no: lwn.net

Tradução: Roberto Bechtlufft

Historicamente, sempre houve um grande interesse pela segurança do protocolo TCP/IP. Mas existe um outro conjunto de protocolos – o de telefonia móvel GSM – que é tão difundido quanto o TCP, e embora sua segurança seja igualmente importante, há muito menos gente dando uma boa olhada nela. Harald Welte e um pequeno grupo de conspiradores decidiram mudar essa situação: em uma movimentada apresentação no evento Linux-Kongress (confira os slides em PDF), Harald descreveu o trabalho de sua equipe e seus progressos até o momento.

Embora não seja muito fácil de se encontrar, as especificações dos protocolos GSM estão disponíveis. Segundo Harald, a indústria do GSM tem uma mentalidade muito fechada. Só há quatro implementações (todas fechadas, naturalmente) da pilha GSM. Todo mundo que usa o GSM licencia uma delas. Não há documentos disponíveis para hardware GSM – ao menos não oficialmente. Há pouquíssimas empresas criando chips GSM ou 3G, e elas compram seu software de terceiros. Só os maiores fabricantes de telefones compram esses chips diretamente, e nem eles contam com uma documentação abrangente ou com o código fonte.

Na parte da rede, mais uma vez há poucas empresas fabricando equipamentos GSM. Além dos grandes fabricantes, há algumas poucas empresas de femtocell e um pequeno grupo de firmas fazendo equipamentos para agências de defesa da lei. Essas empresas têm um número pequeno de clientes – as operadoras de celulares – e há poucas vendas. Em outras palavras, os preços desses equipamentos são muito altos. Isso significa que quem estiver interessado em pesquisar o protocolo GSM vai ter que criar uma rede dedicada a esse propósito, e isso sai caro.

Nem as operadoras de celular sabem direito como as coisas funcionam em termos técnicos, já que terceirizam quase tudo o que precisam fazer. Segundo Harald, essas empresas são mais parecidas com bancos do que com empresas de tecnologia; a operação do equipamento de rede é terceirizada para outras empresas, que são as mesmas que vendem esses equipamentos. Com isso, quase ninguém tem muito conhecimento sobre os protocolos ou sobre os equipamentos que fazem uso deles.

As implicações desta situação são expressivas: o conhecimento dos do protocolo é limitado a um pequeno número de fabricantes. Não há quase nenhum trabalho de pesquisa na segurança no nível desses protocolos em andamento. A maior parte do que se vê é extremamente teórico, e focado na tecnologia de criptografia. A única pesquisa significante é em nível de aplicativos, várias camadas acima da pilha na qual Harald está interessado. Não há implementações de código aberto do protocolo, e isso é um problema: essas implementações são necessárias para que as pessoas aprendam sobre esses protocolos. A falta de implementações de referência abertas também restringe a inovação no GSM aos fabricantes.

E então, como deve proceder alguém interessado em pesquisar a segurança GSM? Uma possibilidade é concentrar a pesquisa na parte da rede, mas como eu já disse, essa brincadeira sai cara. Por outro lado, os protocolos de rede são relativamente bem documentados, o que ajudou os projetos OpenBSC e OpenBTS a progredir na área. Quem preferir investir no GSM na área dos telefones vai ter que lidar com um outro conjunto de obstáculos. Obviamente, o código do firmware e do protocolo usado nos processadores de telefones é fechado e proprietário. A camada 1 e o hardware e o software de processamento de sinal também são fechados. Também há um completo vazio na documentação das interfaces entre essas camadas: nem sequer sabemos como elas conversam entre si. Já ocorreram tentativas de se melhorar a situação – os projetos TSM30 e MADos foram mencionados – mas a coisa ainda está engatinhando.

Apesar dos pesares, Harald e sua empresa decidiram investir nessa área. O começo foi doloroso, e foi necessário estudar mais de mil documentos (cada um com várias páginas) para ir aprendendo gradualmente sobre os protocolos e sobre a forma como eles interagem. Depois dessa fase, veio a necessidade de se adquirir alguns equipamentos e começar a mexer neles.

Harald fez um breve resumo sobre os protocolos e acrônimos da telefonia celular. Na parte de rede, temos a BTS (a torre do celular), que conversa com o BSC (controlador de estação básica), capaz de lidar com centenas de torres. O BSC, por sua vez, conversa com o NSS (subsistema de rede), responsável pelo funcionamento da maior parte dos detalhes da telefonia móvel. O protocolo para conversas com telefones celulares se chama UM. Ele se divide em várias camadas, começando pela camada 1 (a camada de rádio, TS 04.04) e seguindo para a camada 2 (LAPDm, TS 04.06) e para a camada 3, com nomes como “recurso de rádio”, “gerenciamento de mobilidade” e “controle de chamadas”. A especificação da camada 3 é TS 04.08, que Harald julga ser a mais importante para os interessados em saber como a telefonia móvel funciona.

Diversas pessoas que viram as especificações já começaram a apontar problemas de segurança. Não existe, por exemplo, autenticação mútua entre o telefone e a torre do celular, o que possibilita ataques man-in-the-middle nessa comunicação. Os protocolos de criptografia são fracos (e opcionais), e não há como o usuário saber qual tipo de criptografia está sendo usada. Aliás, não dá para saber nem se alguma criptografia está sendo usada. E por aí vai.

Na parte dos telefones, esses protocolos são manipulados por um processador de banda base dedicado, geralmente algum tipo de processador ARM7 ou ARM9 executando um sistema operacional em tempo real. É claro que microkernels L4 são usados em vários desses processadores. A CPU não tem proteção de memória, e o software é escrito em C ou em assembly. Não há recursos de segurança, como proteção de pilha, memória não executável ou randomização de layout de espaço de endereços. É um monte de software rodando em um ambiente implacável; Harald descreveu o funcionamento desse processador em um PDF.

Um pesquisador de segurança GSM precisa ter um processador de banda base sob seu controle. Há algumas maneiras diferentes de se conseguir um desses, como por exemplo, montando um por conta própria usando componentes genéricos. Com um DSP e uma CPU você chega lá, mas vai dar um trabalho violento. A opção é usar um chipset banda base pré-existente, trabalhando com informações obtidas através de engenharia reversa ou documentação vazada. Essa abordagem pode ser mais rápida, mas você continua tendo que trabalhar com hardware caro e personalizado.

Os hackers da OsmocomBB não seguiram nenhuma das duas abordagens, preferindo o jeito “alternativo e preguiçoso” de adaptar um telefone que já existia. Esse método tem uma vantagem óbvia: já sabemos que o hardware funciona. Ainda é preciso fazer muita engenharia reversa, e os drivers de hardware precisam ser escritos, mas dá para ir tocando o trabalho. O truque é encontrar o telefone certo. Um bom candidato seria um que fosse o mais barato possível, com ampla disponibilidade, velho e simples, de preferência com um chipset banda base que já tenha tido ao menos parte de suas especificações vazadas.

A equipe escolheu o chipset TI Calypso, para o qual existe uma pilha GSM de código aberto disponível. Bom, na verdade esse código não é tão aberto assim: ficou rolando lá no SourceForge por quatro anos até a TI perceber. De qualquer forma, quem souber procurar vai encontrar o código. O chipset já saiu do mercado, mas é fácil encontrar telefones com ele no eBay. Para completar, o firmware não é criptografado, logo não há esquemas de DRM a serem derrubados.

Com esses dispositivos em mãos, o projeto OsmocomBB foi iniciado em janeiro de 2010, com o objetivo de criar “do zero” uma implementação de banda base GSM. Nesse sentido a equipe teve sucesso, pois já conta com quase tudo de que precisa para botar o telefone para funcionar. A abordagem atual da equipe é rodar a menor quantidade possível de código no telefone em si – é muito mais fácil depurar código rodando em um computador normal. Os drivers e o código de camada 1 rodam no telefone, o resto todo roda no PC. Mais cedo ou mais tarde, a maior parte do resto do código vai migrar para o telefone, mas pelo visto não há pressa em se fazer isso.

No momento, o firmware tem um conjunto de drivers de hardware para o rádio, a tela e outras partes do telefone. O código da camada 1 do GSM roda sem sistema operacional de base – não existe a necessidade de um. Trata-se de um conjunto relativamente simples de rotinas à base de eventos. Os desenvolvedores da OsmocomBB criaram um protocolo personalizado, o l1ctl, para conversar com o código da camada 1. As camadas 2 e 3 rodam no computador host, usando o l1ctl para conversar com o telefone; elas lidam com tarefas como a emulação do cartão SIM e com diversas “aplicações”, como a realização de chamadas.

Os telefones usados são da família Motorola C1xx. Os modelos preferidos para o desenvolvimento e os testes são o C123 e o C155. Um recurso interessante desses telefones é o fato de contarem com o mesmo modem GSM do telefone OpenMoko, o que facilitou muito as coisas. Eles também têm um conector para fones de ouvido que pode, ao controle do software, se transformar em uma porta RS-232; é por essa entrada que se carrega software no telefone.

Nesse ponto, os drivers de hardware do telefone são completos, e as implementações das camadas de 1 a 3 são “bastante completas”. A pilha da OsmocomBB é capaz de fazer chamadas de voz, e funciona com operadoras comuns de celular. A interface de usuário não é voltada para o grande público – tarefas como o registro do celular e a discagem são feitas via linha de comando – mas tudo funciona. O código é bem integrado ao wireshark, e há “dissecadores” para os protocolos no código principal do programa.

As coisas que não funcionam incluem a leitura de cartões SIM, o controle automático de energia (o telefone sempre opera com a mesma carga) e a transmissão de dados via GPRS. Obviamente vai dar muito trabalho botar o GPRS para funcionar, e não parece haver ninguém interessado em mexer nisso. Harald acha que “não há muito futuro” para o suporte a GPRS. O 3G também não é suportado, e como ele é bem diferente do GSM o suporte não vai pintar tão cedo. Naturalmente, a pilha como um todo não conta com aprovação oficial. Apesar disso, o sistema é bem articulado. Harald diz que ele é “uma placa Ethernet para o GSM”. Graças à OsmocomBB, os desenvolvedores que quiserem criar algo relacionado ao GSM já têm uma plataforma para usar como base.

Os desenvolvedores já descobriram que podem fazer algumas coisas “muito loucas”. Por exemplo, não existe autenticação para as mensagens de cancelamento de registro. Com isso, dá para tirar qualquer telefone celular da rede. Há algumas ferramentas “fuzzers” básicas disponíveis para quem quiser pôr os protocolos à prova, mas sua utilidade é limitada porque os desenvolvedores não contam com o feedback das operadoras de celular.

Segundo Harald, a indústria do GSM dificulta a análise de segurança. Logo, não é surpresa para ninguém que a segurança das pilhas de GSM existentes seja tão baixa. As coisas vão ter que mudar no futuro, e Harald espera que a OsmocomBB contribua com essa mudança. Porém, cabe à comunidade de segurança usar as ferramentas que foram criadas para ela, e Harald acredita que a comunidade vai aceitar esse desafio. Hoje em dia, a área de segurança TCP/IP é entediante: o quente mesmo é a segurança GSM.

Créditos a Jonathan Corbet – lwn.net

Tradução por Roberto Bechtlufft <info at bechtranslations.com.br>