Q
RC OD
E através de um aplicativo móvel para digitalizar os crachás de expositores de projetos de segurança da informação.
No ano passado, visitamos uma grande exposição de projetos de segurança da informação em Londres. Em preparação, recebemos nossos passes na forma de PDFs "imprima você mesmo".
Percebemos imediatamente dois tipos de códigos de barras. Curiosamente, o código QR parecia muito denso, pois basta armazenar apenas o ID do participante. Por natureza, curiosos, lançamos um scanner QR e recebemos o conteúdo do código:
{"CJe";"BHEEZST","DO";"Cvmmfuqsppg","G";"upn","KU";"Qfofusbujpo uftufs","T";"xzbuu"}
Acabou sendo quase-mas-não-muito-JSON. Uma das vantagens de um nome tão curto quanto o meu é que ele chama sua atenção em tais situações. Portanto, notei imediatamente que meu nome estava codificado no ROT-25 ("tom" transformado em "upn"). Também é conhecida como Cifra de César, onde cada letra é substituída por outra com um deslocamento fixo (nesse caso, a letra do alfabeto foi usada em vez de cada letra). Após executar a linha através do decodificador (levando em consideração a marcação JSON), obtivemos:
{"BId";"AGDDYRS","CN";"Bulletproof","F";"tom","JT";"Penetration tester","S";"wyatt"}
Isso é mais legível.
Quebre isso?
Curiosamente, o código QR armazena informações que parecem estar relacionadas ao campo BId no banco de dados. Porque Bem, isso é bem simples. Os organizadores fizeram um aplicativo móvel para fornecedores que os ajuda a coletar os contatos dos participantes durante a exposição. Assumimos que os dados são criptografados em um código QR, caso o sinal Wi-Fi ou celular seja instável.
Até o momento, podemos fazer pouco com essas informações, exceto para alterar nossos dados, a fim de evitar spam dos fornecedores do evento. Seria engraçado, mas dificilmente digno de um email para o desenvolvedor do sistema. Então, fomos ao Play Market e instalamos o aplicativo apropriado para ver o que ele faz.
E aqui encontramos um problema: não tínhamos os dados necessários dos organizadores do evento. Pensamos que poderíamos falsificar a resposta do servidor usando o proxy MiTM, e o aplicativo nos deixará ir. Montamos o Burpsuite e gravamos algumas tentativas malsucedidas de login, na esperança de interceptar o tráfego e brincar com ele.
Infelizmente, não tivemos sucesso. O aplicativo direcionou todas as solicitações usando SOAP, e as respostas não foram óbvias. No entanto, o servidor publica documentos WSDL para o aplicativo.
Este não é o fim
Por que não escrever um serviço da Web falso para que você não possa mais acessar o servidor de aplicativos real? Poucas horas depois, tínhamos esse serviço e todo o tráfego estava ligado a ele. Isso funciona! O aplicativo autenticado com todos os dados e conectado a um evento falso.
Examinamos alguns emblemas e tudo parecia funcionar corretamente. Progresso! Depois de vagar pelo aplicativo por algum tempo, ficou claro que ele estava usando algum tipo de estrutura baseada no WebView. Cavando um pouco no APK, encontramos várias menções ao Sencha e Ext.js, que confirmaram nossa suposição.
E agora - o mais interessante. Se um aplicativo consiste em uma mistura regular de HTML e JavaScript, ele pode ser vulnerável a ataques padrão da Web? Embrulhámos alguns XSS no "não-bastante-JSON" que o aplicativo espera, os digitalizou e ...
Nós quebramos
Ótimo! A injeção de HTML no campo "JT" mostrou a imagem. Podemos adicionar o atributo "onerror" a essa tag para obter a execução do script, mas estamos limitados pela restrição no comprimento máximo do código QR. Como resultado, criamos uma carga útil que baixou o arquivo JS do servidor e o executou no dispositivo. Aqui, por exemplo, está o teste alert () padrão:
A digitalização de um código de barras aciona o XSS e executa o código:
Nós o picamos para que ele se encaixe perfeitamente no tamanho máximo de um código QR legível, não muito denso para impressão em um passe. Depois de ler a documentação da API Ext.js e compará-la com o código APK descompilado, conseguimos criar um código de barras que:
- Faça o download de um arquivo JS de um servidor remoto
- Lê as chaves da sessão de um smartphone e as envia para o servidor
- Lê o conteúdo do banco de dados de contatos em cache do aplicativo, incluindo os nomes e endereços de e-mail de todos cujos passes foram verificados por este dispositivo
- Exclui sua gravação de um smartphone
Em seguida, o ataque se resume ao seguinte: o fornecedor digitaliza meu código QR em troca de uma caneta gratuita e recebo uma lista completa de todos os contatos verificados por este dispositivo.
Carga útil:
Pedidos para o servidor web:
Tudo está bem quando acaba bem
Chamamos a atenção dos fornecedores na exposição e, após algumas discussões, eles decidiram não usar o aplicativo este ano. Apenas algumas pessoas no evento se aproveitaram do aplicativo, enquanto os mais pequenos e preferidos eram pequenos scanners de código de barras. O aplicativo do Market foi baixado apenas cerca de 500 vezes. No entanto, esse é um vetor interessante para o XSS, que mostra que você realmente precisa filtrar os dados antes do uso, independentemente de sua origem.
Embora esse aplicativo em particular não tenha sido amplamente utilizado, imagine se a vulnerabilidade estivesse em um aplicativo usado por milhares ou baixado por milhões? Todos esses dados seriam para invasores que os descartariam a seu critério: de campanhas de phishing a ataques de força bruta.