A recente história de backdoor na biblioteca NPM mais popular levou muitos a pensar em quanto confiamos no código de terceiros e na ousadia de usá-lo em nossos projetos (potencialmente substituindo os usuários de nossos produtos).
Mas mesmo meses antes do "trovão",
Felix Kraus (conhecido pelos desenvolvedores móveis como criador do Fastlane) falou em nossa conferência Mobius 2018 Piter sobre o mesmo: confiança dos desenvolvedores móveis nos SDKs de terceiros. Se fizermos o download do popular SDK de uma empresa conhecida, está tudo bem lá ou algo também pode dar errado? Onde está o vetor de ataque e o que devemos pensar a esse respeito?
E agora transcrevemos e traduzimos o relatório dele. Portanto, você pode pelo menos assistir ao vídeo original, pelo menos ler a versão em texto em russo. Como o Kraus está envolvido no desenvolvimento do iOS, todos os exemplos também são do iOS, mas os desenvolvedores do Android podem ignorar exemplos específicos e também pensar nisso.
Segurança do SDK
Depois de ver quais SDKs são mais populares no desenvolvimento do iOS hoje, decidi investigar como eles são vulneráveis aos ataques de rede mais comuns. Até 31% deles foram vítimas em potencial de ataques simples do tipo man-in-the-middle, o que significa que o hacker injeta seu código malicioso no SDK.
Mas, em geral, vale a pena ter medo? Qual é o pior que ele pode fazer com seu SDK? Isso tudo é tão sério? Você deve entender que o SDK incluído no pacote configurável do seu aplicativo é executado em seu escopo - ou seja, o SDK obtém acesso a tudo em que seu aplicativo opera. Se o usuário permitir que o aplicativo acesse dados de localização geográfica ou, digamos, fotos, esses dados também estarão disponíveis para o SDK (não são necessárias permissões adicionais). Outros dados que podem ser acessados a partir do SDK: dados criptografados do iCloud, tokens de API e, além disso, todas as exibições do UIKit que contêm muitas informações diferentes. Se um hacker intercepta um SDK que tem acesso a esse tipo de dados, as consequências, como você sabe, podem ser bastante sérias. Ao mesmo tempo, todos os usuários do aplicativo serão afetados simultaneamente.
Como exatamente isso pode acontecer? Vamos dar um passo atrás e falar sobre coisas básicas da rede e seus abusos.
Rede
Eu aviso que minhas explicações não serão 100% precisas e detalhadas. Meu objetivo é transmitir a essência, por isso apresentarei tudo de uma forma um tanto simplificada. Se você estiver interessado nos detalhes, recomendo que você olhe no meu blog ou explore você mesmo o tópico.
Como você se lembra, a principal diferença entre o protocolo HTTPS e o protocolo HTTP é a criptografia de dados durante a transmissão. A falta de criptografia no HTTP, em geral, significa que qualquer host localizado dentro da rede, se desejado, pode ouvir e modificar livremente quaisquer pacotes transmitidos por ela; ao mesmo tempo, não é possível verificar se a integridade do pacote foi violada. Tudo isso é verdade para redes Wi-Fi públicas, redes Ethernet protegidas por senha e locais.
Ao usar HTTPS, os hosts de rede também podem ouvir os pacotes transmitidos, no entanto, eles não têm a capacidade de abri-los - apenas os metadados do pacote são visíveis, em particular os endereços dos hosts de envio e recebimento. Além disso, o HTTPS fornece verificação: após receber o pacote, você pode verificar se ele sofreu alterações durante a viagem.
Anteriormente, tudo funcionava da seguinte maneira. Quando você inseriu "google.com" na barra de endereços sem especificar um protocolo, por padrão, o navegador enviou sua solicitação via HTTP. Mas como o servidor do Google prefere se comunicar via HTTPS, em resposta a ele, você recebeu um novo link (redirecionamento) com o prefixo "https: //". Aqui está uma tela do Charles Proxy (uma ferramenta de monitoramento de tráfego HTTP / HTTPS) que demonstra isso:
No entanto, o novo link foi enviado pelo protocolo HTTP. É fácil entender o que pode dar errado aqui: a solicitação e a resposta são transmitidas via HTTP, o que significa que você pode, por exemplo, interceptar o pacote de resposta e substituir a URL do local por "http: //". Esse tipo simples de ataque é chamado de faixa SSL. Até o momento, os navegadores já aprenderam a trabalhar de uma maneira um pouco diferente. Mas entender o que é uma faixa SSL é útil para nós.
Às vezes você pode se lembrar do modelo de rede OSI. Eu a via como algo insuportavelmente chato. Mais tarde, porém, ele descobriu que, curiosamente, o modelo OSI não existe exatamente assim e pode até ser útil.
Não o consideraremos em detalhes. O principal a entender: tudo consiste em várias camadas que são responsáveis por coisas diferentes e, ao mesmo tempo, estão em constante interação entre si.
Uma das camadas está tentando determinar qual endereço MAC corresponde a um endereço IP específico. Para isso, é feita uma solicitação de transmissão especial, o primeiro dispositivo respondido é gravado e os pacotes subsequentes são enviados a ele.
O problema é que o hacker pode responder à solicitação mais rapidamente: "sim, envie-me todos os pacotes". Isso é chamado de falsificação de ARP ou envenenamento de cache de ARP. Nesse caso, o esquema de sua interação com a Internet se transforma neste:
Todos os pacotes agora passam pelo dispositivo do hacker e, se o tráfego não estiver criptografado, ele poderá ler e escrever. No caso do HTTPS, há menos possibilidades, mas é possível rastrear quais hosts você está acessando.
Curiosamente, de fato, os mesmos poderes têm provedores de Internet e VPN. Eles são intermediários na sua interação com a Internet e da mesma maneira representam uma ameaça potencial de falsificação de ARP.
Não há nada de novo na própria abordagem do homem do meio. Mas como exatamente tudo isso se aplica aos SDKs móveis?
Especificações para celular
CocoaPods é uma ferramenta de gerenciamento de dependência padrão usada no desenvolvimento do iOS. Usar o CocoaPods para código-fonte aberto é considerado praticamente seguro - geralmente é hospedado no GitHub, geralmente acessado via HTTPS ou SSH. No entanto, eu consegui encontrar uma vulnerabilidade baseada no uso de links HTTP.
O fato é que o CocoaPods possibilita a instalação do SDK com código fonte fechado, e você só precisa especificar o URL. Não há verificação de que o tráfego será criptografado e muitos SDKs oferecem um endereço HTTP.
Nesse sentido, enviei várias solicitações de recebimento aos desenvolvedores do CocoaPods e logo eles concluíram a conclusão. Agora, novas versões do CocoaPods verificam o link especificado pelo usuário e, se não estiver criptografado, eles exibem um aviso. Portanto, meu conselho é: sempre atualize as versões do CocoaPods e não ignore os avisos.
É ainda mais interessante considerar como a instalação de SDKs não sensoriais que não são do CocoaPods prossegue. Tome, por exemplo, a plataforma Localytics.
A página docs.localytics.com não está criptografada. Parece que, neste caso, isso pode ser negligenciado, porque isso é apenas documentação. Mas observe que a página, entre outras coisas, contém um link para baixar os binários. O link pode ser criptografado, mas isso não garante nenhuma segurança: como a própria página será transmitida via HTTP, ela poderá ser interceptada e o link poderá ser substituído por um não criptografado. Os desenvolvedores do localytics foram notificados dessa vulnerabilidade e ela já foi corrigida.
Você pode fazer o contrário: não altere o link para HTTP, mas deixe HTTPS, mas substitua o próprio endereço. Descobrir isso será muito difícil. Veja estes dois links:
Um deles pertence a mim. Qual deles é de desenvolvedores reais e qual não é? Tente entender.
Verificação prática
Decidi testar minhas suposições, tentando, na realidade, substituir o conteúdo do SDK usando um ataque MITM. Descobriu-se que isso não é tão difícil. Para construir e operar meu circuito, levei apenas algumas horas para configurar as ferramentas públicas mais simples.
Confiei o Raspberry Pi usual para interceptar. Incluído na rede local, ele podia ouvir o tráfego nela. Nos pacotes interceptados, ele primeiro substituiu todos os links HTTPS por links HTTP e, em seguida, todos os arquivos .zip do Localytics iOS pelo arquivo hack.zip. Tudo isso acabou sendo simples e funcionou com um estrondo.
O arquivo trollface.jpg apareceu no arquivo resultante e a linha “Modified by KrauseFx” apareceu no arquivo Info.plist. Quanto foi necessário para esse ataque? Apenas duas condições:
- Eles conseguiram obter acesso à sua rede (lembre-se de que, para provedores de Internet e VPN, isso não é uma questão). A quantas cadeias de café e hotel nos conectamos?
- O download iniciado não é criptografado.
Você diz: "mas estou apenas olhando para o ícone Seguro no navegador, o que significa que ficarei bem". E se você está na Amazon, tudo deve ficar bem, certo?
Sugiro considerar o site da Amazon. O AWS Mobile SDK é o SDK pessoal, que eles fornecem aos desenvolvedores para interagir com o serviço.
O ícone "seguro", um site conhecido, parece pressagiar nada. Mas infelizmente - apenas à primeira vista. O link para baixar o SDK é indicado sem um prefixo (nem https: // nem http: //). E, ao mesmo tempo, deve levar o usuário para outro host. Portanto, o navegador mudará de HTTPS para HTTP. Como você pode ver, aqui o download do SDK não é criptografado! No momento, a vulnerabilidade já foi corrigida pelos desenvolvedores da Amazon, mas realmente tinha um lugar para estar.
Devo dizer que o desenvolvimento de navegadores modernos também é realizado não sem atenção a problemas de segurança. Por exemplo, se você carregar uma página usando HTTPS e qualquer imagem for especificada por meio de um link HTTP, o Google Chrome notificará você sobre o chamado "conteúdo misto". Mas essa medida de segurança não é fornecida para downloads: os navegadores não rastreiam qual protocolo é acionado para o link de download indicado na página. Portanto, como parte deste projeto, escrevi para desenvolvedores de navegadores com uma solicitação para fornecer o rastreamento de conteúdo misto e notificar os usuários sobre ele.
Roubo de dados Apple ID
Agora vamos ver outro problema. Os usuários do iPhone devem estar familiarizados com esta janela pop-up regularmente:
À esquerda, você vê a versão original do iOS, à direita - minha cópia. Sobre como é fácil simular uma janela semelhante,
escrevi no meu blog há alguns meses atrás. Foram necessários 20 minutos para recriar a exibição.
O iPhone geralmente solicita dados de autenticação do iCloud e, para o usuário, o motivo da solicitação geralmente permanece incerto. Os usuários estão tão acostumados a isso que inserem a senha automaticamente. A questão de quem está pedindo a senha - o sistema operacional ou o aplicativo - simplesmente não lhe ocorre.
Se você acha difícil obter o endereço de e-mail ao qual o Apple ID está anexado, exagera: isso pode ser feito através do catálogo de contatos e dos contêineres do iCloud (se você tiver acesso ao aplicativo iCloud, sobre o qual você pode descobrir UserDefaults deste aplicativo). E a opção mais simples é pedir ao usuário que digite seu email pessoalmente: em teoria, isso não deveria surpreendê-lo, porque no iOS existe realmente uma espécie de janela solicitando não apenas uma senha, mas também um email.
Pensei: “E se eu pegar esse código do formulário de solicitação que tenho e, com a ajuda da falsificação do SDK, penetrar em muitos aplicativos diferentes para roubar todas as senhas do iCloud?” Quão difícil é essa tarefa?
Suponha que tenhamos um Mac completamente limpo, sem nenhuma VPN ou proxy instalado, mas na mesma rede, temos o nosso Raspberry Pi. No Mac no Xcode, temos um projeto de projeto iOS aberto contendo um mínimo absoluto de código - uma simples exibição de mapa da área e nada mais.
Agora abra o navegador, acesse Amazon Web Services. Encontre a página do AWS Mobile SDK e siga o link de download. Descompacte o binário baixado e arraste todas as estruturas para o nosso projeto no Xcode. Então importamos as bibliotecas. Não precisamos nem chamar qualquer código - basta que seja baixado. Observo que durante todo o processo o Xcode não emitiu nenhum aviso.
O que acontece ao recompilar o aplicativo? A mesma cópia da janela aparece na tela, solicitando que eu faça login na iTunes Store. Eu digito a senha, a janela desaparece. Ao mesmo tempo em que observo o registro do aplicativo, vejo como a senha inserida é exibida instantaneamente - a interceptação de dados do ID Apple é concluída. Seria fácil enviar esses dados para algum lugar no servidor.
Aqui você pode dizer: "Bem, durante o desenvolvimento, eu notaria imediatamente esse formulário de entrada e entenderia que algo está errado". Mas se você tiver uma audiência de milhões de usuários, poderá fazê-lo sair apenas uma vez por mil e passar despercebido durante o teste.
E, novamente, quanto nos levou a realizar o ataque? Era necessário que nosso computador estivesse na rede (e o Raspberry Pi era suficiente). HTTP ou HTTPs - nesse caso, não importava, a criptografia não salvaria a situação. Todas as ferramentas de software que usei - as mais simples, foram tiradas por mim do acesso público. Ao mesmo tempo, sou um desenvolvedor comum, sem muito conhecimento e experiência em hacks.
Aquisição da gestão
O exemplo anterior introduziu código malicioso no aplicativo iOS. Mas e se pudéssemos obter o controle do computador do desenvolvedor em geral? A capacidade de executar código no seu dispositivo, como você sabe, dá ao hacker um poder tremendo. Ele poderá ativar o acesso remoto via SSH, instalar um keylogger, etc. Ele poderá observá-lo a qualquer momento, registrar suas ações, usar o sistema de arquivos. Ele também poderá instalar novos certificados SSL e usá-los para interceptar todas as solicitações feitas à rede. Em uma palavra, alguém tem a oportunidade de executar código no seu computador - e você está completamente comprometido.
Pensei: "Qual SDK do iOS posso usar para isso?" Há um serviço que fornece ao SDK o comando curl e um link HTTP com saída redirecionada para o comando sh. Ou seja, seu terminal fará o download e executará o shell script.
Por si só, esse método de instalação já coloca você em risco, não faça isso. Mas, neste caso, o protocolo HTTP também foi usado. O que é então possível fazer?
Suponha que você seja um usuário. Você vai para a página de documentação oficial. Preste atenção ao fato de que a página está criptografada com o protocolo HTTPS - ótimo! Você copia o comando, executa-o em casa. O comando é executado dentro de alguns segundos. O que aconteceu durante esse tempo?
E durante esse tempo, um mecanismo de ataque simples envolvendo meu Raspberry Pi conseguiu funcionar. O script de shell updateSDK carregado pelo usuário continha um pequeno toque do meu próprio código. E agora tenho permissão para acessar seu computador remotamente via SSH, e você também tem um keylogger instalado.
À esquerda, você vê o seu terminal e, à direita, está o meu Raspberry Pi, que em tempo real já mostra tudo o que você digita no teclado. Após iniciar o Raspberry Pi SSH, efetuei login usando o login e a senha recém-registrados usando o keylogger e, dessa forma, tenho acesso total para controlar o seu Mac e seu sistema de arquivos. E também, provavelmente, sua empresa empregadora tem acesso a muito.
Em conclusão
Qual a probabilidade de isso acontecer com você? Afinal, os desenvolvedores ainda tentam usar Wi-Fi seguro, compram uma VPN.
Pessoalmente, também pensei em ter cuidado até que um dia abri as configurações do meu Mac e descobri na história de mais de 200 conexões com redes Wi-Fi inseguras. Cada conexão é uma ameaça em potencial. E mesmo usando uma rede confiável, você não pode ter 100% de certeza de sua segurança, porque não pode saber se algum dos dispositivos dessa rede foi comprometido (como acabamos de ver).
Ataques em redes Wi-Fi inseguras são muito comuns. Eles são fáceis de realizar em locais públicos, como hotéis, cafés, aeroportos e, a propósito, conferências :) Imagine um palestrante falando sobre algum tipo de SDK e, como sempre, parte da platéia tenta instalá-lo em paralelo, conectando-se ao Wi-Fi fornecido aqui. . E como eu disse, é muito fácil abusar dos seus direitos a um provedor de rede.
Da mesma forma com uma VPN - você apenas se entrega ao provedor. E quem melhor para confiar - o provedor de VPN ou sua rede local e seus usuários? Claro.
Em novembro de 2017, conduzi minha pesquisa e analisei a presença das vulnerabilidades listadas nos 41 SDKs mais populares para iOS (sem contar os SDKs do Google e do Facebook, todos eles estão protegidos).
Como você pode ver, 31,7% dos SDKs não passaram nos testes. Consegui informar sobre quase todos os fornecedores sobre os problemas existentes. De uma delas, recebi uma resposta literalmente imediatamente, o problema foi resolvido em três dias. Cinco equipes também reagiram, mas passaram um pouco mais de tempo na revisão - cerca de um mês. Sete não se deu ao trabalho de responder ao meu relatório e não corrigiram nada até hoje. Deixe-me lembrá-lo de que não se trata de alguns projetos pouco conhecidos. Todos eles estão entre os SDKs mais famosos e têm dezenas de milhares de usuários desenvolvendo aplicativos iOS usando esses SDKs, que, por sua vez, são usados por milhões de usuários do iPhone.
É importante entender que os usuários de aplicativos fechados estão sempre sujeitos a maiores riscos, enquanto os usuários de aplicativos de código aberto usam menos. Você não pode verificar como um aplicativo fechado funciona. É extremamente difícil julgar se há soluções seguras. Você pode comparar hashes e somas de hash, mas, ao fazer isso, poderá verificar o sucesso do download. Pelo contrário, você pode pesquisar produtos de código aberto minuciosamente, ao longo e transversalmente, o que significa que você pode se oferecer mais proteção.
Além dos ataques man-in-the-middle, existem outros. Um hacker pode atacar o servidor do qual o SDK está sendo baixado. Também acontece que a empresa que fornece o SDK deliberadamente inclui as chamadas backdoors no código por meio do qual pode posteriormente acessar não autorizado aos dispositivos do usuário (talvez o governo local exija a instalação de backdoors, ou talvez seja essa a iniciativa da própria empresa).
E somos responsáveis pelo produto que fornecemos. Devemos ter certeza de que não estamos decepcionando o usuário e que estamos cumprindo o GDPR. Os ataques através do SDK são graves principalmente porque são maciços - eles são direcionados não a um desenvolvedor, mas a um milhão de dispositivos de cada vez. Esses ataques podem passar quase despercebidos por você. O código-fonte aberto ajuda você a se proteger disso, com o código-fonte tudo fica muito mais complicado - use-o apenas quando puder confiar em segurança. Obrigado pela atenção.
Se você gostou deste relatório, preste atenção: o próximo St. Petersburg Mobius será realizado de 22 a 23 de maio, os ingressos já estarão à venda e, gradualmente, ficarão mais caros.