E como eu fiz isso? Tudo começou com um aplicativo que desenvolvi. Por razões óbvias, não publicarei o nome. O aplicativo é bastante simples, ele é projetado para pessoas que gostam de fitness e oferece opções como inserir dados de velocidade durante uma corrida ou complexos de treinamento de força já prontos. Como muitos outros produtos, exige que o usuário crie primeiro uma conta. Segundo analistas, cerca de 60% das pessoas, em vez de passar por todo o processo de registro, são tentadas pelo tentador botão "Faça login no Google".
Você provavelmente sabe em termos gerais o que acontece nesses casos: quando o usuário clica em um botão, uma janela do navegador para fazer login em uma conta do Google é aberta dentro do aplicativo.
Este usuário tem a identificação de dois fatores habilitada, então após ele inserir o e-mail e a senha, uma caixa de diálogo aparecerá perguntando se é ele. A localização e o tipo de dispositivo são iguais, então ele clica em "Sim".
Isso, na verdade, é tudo. Agora, uma pessoa pode usar o aplicativo com segurança, enquanto eu, enquanto isso, obtenho acesso total e ilimitado à sua conta de um servidor remoto. Ele nunca receberá nenhuma mensagem sobre isso. E se ele se revelar meticuloso e começar a estudar o tráfego da rede, verá que o dispositivo envia solicitações de rede única e exclusivamente para vários subdomínios do google.com.
Mas como isso é possível? Vamos voltar ao nosso botão Login com o Google. Vamos deixar uma coisa bem clara: para quem não sabe, ao clicar neste botão, o aplicativo pode fazer qualquer coisa. Lance o processo de autorização no Google, dê voz de trompete, mostre um gif com um gato. Nem todas as opções desta lista são igualmente prováveis, mas você pode sonhar.
No meu caso, ao clicar no botão, o aplicativo abre uma caixa de diálogo usando o WebView e define o endereço da web: accounts.google.com/EmbeddedSetup . Ele corresponde à página de login da conta do Google, apenas uma especial projetada para novos dispositivos Android. Esta circunstância terá seu papel mais tarde, quando nos for gentilmente prestados com todas as informações necessárias na forma de um cookie.
Infelizmente, esta página parece e age de maneira diferente da página de login padrão (pelo menos da maneira que deveria ser por padrão):
Observe a estranha faixa azul, as palavras Aprenda mais e assim por diante na imagem certa.
E agora a diversão começa. Eu uso as APIs padrão incorporadas ao iOS e ao Android para injetar uma parte bem escrita do código Javascript que fará as modificações necessárias para que a página não difira do padrão em termos de aparência ou comportamento.
Os mais astutos agora pensarão: "Pare, então se você pode injetar código JavaScript, o que o impede de simplesmente roubar seu login e senha diretamente dos campos de texto?" Absolutamente nada - de modo geral, já existe um código pronto para esse fim existir. Mas hoje em dia, o acesso ao login e senha não é mais suficiente. A menos que você tenha muita sorte, o servidor estará a algumas centenas de quilômetros da localização do usuário. Caso contrário, o usuário receberá uma carta e uma notificação com uma mensagem sobre "atividade suspeita" e a tentativa de hacking será interrompida. E a autenticação de dois fatores torna nossa vida ainda mais difícil.
Então, vamos falar sobre outra coisa, como o token mestre. À primeira vista, parece de alguma forma cruel, mas na segunda - acaba sendo ainda pior do que parecia.
Quando o dispositivo Android efetua login pela primeira vez, ele envia o token recebido da página de login integrada mencionada anteriormente para um endpoint especial. Aqui está um exemplo de solicitação típica:
POST /auth HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 349
Host: android.clients.google.com
Connection: Keep-Alive
User-Agent: GoogleLoginService/1.3 (a10 JZO54K);gzip
app: com.google.android.gmsapp=com.google.android.gms&client_sig=38918a453d07199354f8b19af05ec6562ced5788&callerPkg=com.google.android.gms&callerSig=38918a453d07199354f8b19af05ec6562ced5788&service=ac2dm&Token=oauth2_4%2F4AY0e-l5vPImYAf8XsnlrdshQQeNir3rSBx5uJ2oO9Tfl17LpsaBpGf1E2euc18UyOc8MnM&ACCESS_TOKEN=1&add_account=1&get_accountid=1&google_play_services_version=204713000
O token nesta solicitação é obtido dos cookies da página de login da conta e todo o resto são informações disponíveis publicamente (obrigado, microG !). A mesma página de login da conta lida com as coisas com autenticação de dois fatores - não precisamos fazer nada.
Depois disso, o ponto de extremidade mencionado acima envia o mesmo token mestre. Mas como obteria acesso a ele sem solicitações de rede suspeitas? Muito simples: por meio de um log no Google Firebase.
E o token mestre é poderoso. Tem validade ilimitada, desde que o usuário não altere as configurações de senha ou autenticação de dois fatores. Tanto quanto sei, não está sujeito a quaisquer verificações de segurança, independentemente da localização, IP e ações. Nunca provoca o sistema para enviar uma notificação ou carta ao usuário.
E o mais importante: abre-me o caminho a todos, sem exceção, os serviços que alguma vez estiveram disponíveis a partir de um dispositivo móvel, em nome do proprietário da conta correspondente. Uma solicitação POST é suficiente para eu fingir ser uma conta oficial do Google e obter um token OAuth para acessar qualquer coisa, incluindo APIs privadas (e provavelmente não publicadas em lugar nenhum). Posso ler e-mails, navegar no Google Drive, ver backups do meu telefone e fotos no Google Fotos e, ao mesmo tempo, ler o histórico da web do usuário e bater papo com seus amigos no Google Messenger. Até criei uma versão modificada do microG com a qual posso gerenciar todas essas contas de usuário diretamente de aplicativos regulares do Google.
E eu lembro a você, todo o processo se parece com isso... Convido a todos a fazerem a pergunta: você seria pego?
Exposição
Como muitos de vocês já devem ter adivinhado, nem tudo neste artigo é verdade. Não publiquei nenhum aplicativo de fitness na Play Store e não coletei milhões de Master Tokens. Obrigado a este post pela inspiração. Mas o método em si funciona. Eu, e qualquer outro desenvolvedor, definitivamente poderíamos fazer um aplicativo com essa surpresa (talvez alguém já tenha feito).
Perguntas frequentes
Mas a página é diferente do login normal. Eu teria notado!
As diferenças não são tão marcantes, então provavelmente eles não teriam notado. A página de login da conta do Google no Android geralmente tem uma interface "selecione uma conta", mas há exceções - por exemplo, muitos aplicativos da web, como aqueles que são feitos no Ionic e no Cordova. A maioria dos aplicativos iOS também prefere a versão da web, que é muito semelhante à opção acima. Além disso, mesmo que pareça que a ausência de uma tela com "tal e tal aplicativo está solicitando acesso ...", você definitivamente será alertado, então ele pode muito bem ser implementado ao custo de alguns extras horas de trabalho.
Isso funciona no iOS também?
Eu não tentei, mas não há razão para acreditar que não funcionará.
E o que fazer com isso?
Em geral, a questão é complexa. Nenhuma das minhas ações, estritamente falando, se enquadra na definição de um exploit, mas o resultado é, no entanto, muito perigoso. Para começar, o Google gostaria de resolver suas notificações de "entrar com um novo dispositivo" para que funcionem bem. Pessoalmente, eu os recebo quando tento fazer login em minha conta de um computador, mas enquanto eu testava este aplicativo, o sistema nunca funcionou. Outra boa ideia é atualizar as diretrizes para os botões "Sign in with Google"; agora não diz nada sobre os requisitos de implementação. Talvez eles devessem mergulhar mais fundo na selva de segurança através da obscuridade - um princípio, com todas as suas falhas, até agora serve bem à Apple para a segurança do iMessage.
Tenho de admitir: não tenho a certeza de que possa encontrar aqui uma solução técnica que elimine completamente o problema. Se o aplicativo oficial do Google tiver a capacidade de realizar alguma ação, os programas de terceiros, com a devida diligência, poderão repeti-la. No entanto, a empresa emprega pessoas inteligentes, então espere para ver.
Este problema é relevante para todos os sistemas de autorização em aplicativos de terceiros?
Bem possível. Não entendi bem em que casos as notificações foram enviadas e em que não foram, mas mesmo quando as notificações chegam, nem sempre fica claro para elas o que está a acontecer. A função "Sign in with Apple", no entanto, é equipada com diretrizes muito rígidas, e a administração da App Store (onde a função, acredito, é usada principalmente) monitora estritamente o cumprimento dos requisitos. Por outro lado, eles têm seus próprios problemas com a autorização, contra os quais isso desaparece.
História real
Mesmo se não fosse milhões, de alguma forma eu realmente coletei uma pequena quantidade de tokens mestres de usuários desavisados, e sem querer.
A verdadeira história da minha epifania começou quando desenvolvi o aplicativo Carbon Player; agora já caiu no esquecimento e não recebeu uma distribuição generalizada. O app foi pensado para substituir o Google Play Music (lembra dos dias em que ele existia?), Só que com um design bem mais bacana. Para acessar a pasta de música personalizada, traduzi gmusicapiSimon Weber em Java, mas, enquanto reescrevia o código, a princípio não entendi realmente como funciona o processo de autorização ali. Só percebi que precisava de um nome de usuário e senha, que solicitei por meio de uma caixa de diálogo simples, e então alguns pedidos vêm e alguns tokens que são adequados para eu extrair música caem.
Antes de transferir a primeira versão do aplicativo para um pequeno grupo de testadores, vasculhei o código, adicionei o registro em todos os lugares e também implementei um interceptor, que deveria carregar automaticamente todos os registros para o Firebase. Claro, fui inteligente o suficiente para não registrar senhas, mas prometi os três tokens recebidos por minha implementação gmusicapi por engano. Dois deles eram bastante inofensivos - eles só davam acesso a diferentes lojas de música. Mas o terceiro acabou sendo um token mestre.
Em geral, o aplicativo coletou no máximo vinte e cinco downloads durante toda a sua existência, e rapidamente acenei com a mão para não me distrair dos estudos. Mas antes disso, ele conseguiu lançar algumas atualizações, uma das quais era um redesenho da nova (bem, naquela época) página inicial do Google Play Música - um dos poucos elementos do produto original que parecia bom.
O processo acabou sendo muito mais confuso do que eu pensava e, inesperadamente, tive que fazer muita engenharia reversa de buffers de protocolo. Mais importante, por algum motivo, agora exigia um token completamente diferente, que não era mais implementado no gmusicapi. Como resultado, para implementá-lo, vasculhei o sistema de autorização por várias horas, tentando descobrir como ele funciona. Isso levou a um terrível momento de epifania, quando percebi que estava registrando as informações mais confidenciais que podia. Direi uma coisa: o registro parou. Vinte e cinco pessoas que baixaram o aplicativo, me perdoe, por favor (eu apaguei seus tokens do Firebase!).
Houve outro, não relacionado à primeira vez, quando trabalhei em uma startup criando um gerenciador de senhas. Uma das principais vantagens do aplicativo era que ele armazenava senhas estritamente no telefone, mas ao mesmo tempo permitia a autorização do computador graças a um bookmarklet JavaScript que “conectava dispositivos” por meio de um código QR. Para que tudo corra bem, quando um usuário abre um site em um computador, o aplicativo acessa o mesmo site do telefone e injeta um código JavaScript cuidadosamente escrito que captura logins, senhas e tudo o mais. Soa familiar?
No final, essas duas ideias se juntaram na minha cabeça. Eu tinha um protótipo do Carbon Player, mas não tive tempo de fazê-lo funcionar. Alguns anos depois, finalmente comecei a criar algo como uma versão demo com base nisso. Muita coisa teve que ser mudada no processo - o método descrito neste artigo é significativamente diferente do que foi implementado no protótipo, uma vez que o Google fez alterações no sistema de autorização. Mas o resultado final permanece o mesmo e não é menos assustador do que era então.
Se quiser, você pode baixar a versão demoe ver o sistema em ação; Dou minha palavra de que nada é registrado na nuvem. Lembre-se de que o aplicativo é muito simples e quase não foi testado, portanto, há uma boa chance de que o método não funcione se sua conta tiver uma configuração diferente. Obrigado por ler o artigo, espero que você tenha gostado de um pequeno lembrete da importância de questionar tudo. Mesmo as coisas mais inofensivas às vezes escondem algo não muito agradável por dentro (embora no caso do bolo de sorvete aconteça o contrário).