O rootkit crítico da MediaTek afeta milhões de dispositivos Android

Na primeira segunda-feira de cada mês, o Google publica o Boletim de segurança do Android, uma página que divulga todas as vulnerabilidades de segurança e seus patches enviados pelo próprio Google ou por terceiros. Hoje não foi exceção: o Google acaba de tornar público o Boletim de Segurança do Android de março de 2020. Uma das vulnerabilidades documentadas no boletim mais recente é a CVE-2020-0069, uma exploração crítica de segurança, especificamente uma rootkit, que afeta milhões de dispositivos com chipsets da MediaTek, a grande empresa taiwanesa de design de chips. Embora o Boletim de Segurança do Android de março de 2020 seja aparentemente a primeira vez que o CVE-2020-0069 foi divulgado publicamente, detalhes da exploração estão abertos na Internet – mais especificamente, nos fóruns XDA-Developers – desde abril de 2019. Apesar da MediaTek disponibilizar um patch um mês após a descoberta, a vulnerabilidade ainda pode ser explorada em dezenas de modelos de dispositivos.

Pior ainda, a vulnerabilidade está sendo ativamente explorada por hackers. Agora, a MediaTek recorreu ao Google para preencher essa lacuna de patch e proteger milhões de dispositivos contra essa exploração crítica de segurança.

Para qualquer leitor que não esteja familiarizado com Desenvolvedores XDA, somos um site que abriga os maiores fóruns sobre modificações de software Android. Normalmente, essas modificações giram em torno da obtenção de acesso root em dispositivos para excluir bloatware, instalar software personalizado ou ajustar os parâmetros padrão do sistema. Os tablets Fire da Amazon são alvos populares para hackers amadores em nossos fóruns – eles estão cheios de recursos desinstaláveis bloatware, não têm acesso a aplicativos de software básicos como a Google Play Store e, o mais importante, são muito barato. O desafio de fazer root nos tablets Amazon Fire é que eles são fortemente bloqueados para evitar que os usuários saiam do jardim murado da Amazon; A Amazon não fornece um método oficial para desbloquear o bootloader de tablets Fire, que geralmente é o primeiro passo para fazer root em qualquer dispositivo Android. Portanto, a única maneira de fazer root em um tablet Amazon Fire (sem modificações de hardware) é encontrar uma exploração no software que permita ao usuário contornar o modelo de segurança do Android. Em fevereiro de 2019, isso é exatamente o que o membro sênior diplomático do XDA fez quando ele publicou um tópico em nossos fóruns de tablets Amazon Fire. Ele rapidamente percebeu que essa exploração tinha um escopo muito mais amplo do que apenas os tablets Fire da Amazon.

Depois de alguns testes realizados por membros diplomáticos do XDA e outros membros da comunidade, foi confirmado que esta exploração funciona em um grande número de chips MediaTek. O autor afirma que a exploração funciona em “praticamente todos os chips de 64 bits da MediaTek” e nomeia especificamente os seguintes como vulneráveis: MT6735, MT6737, MT6738, MT6739, MT6750, MT6753, MT6755, MT6757, MT6758, MT6761, MT6762, MT6763, MT6765, MT6771, MT6779, MT6795, MT6797, MT6799, MT8163, MT8167, MT8173, MT8176, MT8183, MT6 580, e MT6595. Devido à quantidade de chipsets MediaTek afetados por esta exploração, a exploração recebeu o nome de “MediaTek-su” ou “MTK-su”, abreviadamente. Em 17 de abril de 2019, a diplomacia publicou um segundo tópico intitulado "Raiz temporária incrível para MediaTek ARMv8" em nosso fórum "Diversos desenvolvimento Android". Neste tópico, ele compartilhou um script que os usuários podem executar para conceder-lhes acesso de superusuário no shell, bem como definir SELinux, o módulo do kernel Linux que fornece controle de acesso para processos, para os altamente inseguros "permissivos" estado. Para um usuário obter acesso root e definir o SELinux como permissivo em seu próprio dispositivo é surpreendentemente fácil de fazer: tudo que você precisa fazer é copiar o script para uma pasta temporária, altere os diretórios onde o script está armazenado, adicione permissões executáveis ​​ao script e, em seguida, execute o roteiro.

Os membros da comunidade XDA confirmaram que a exploração funcionou em pelo menos os seguintes dispositivos:

1. Acer Iconia One 10 B3-A30
2. Acer Iconia One 10 B3-A40
3. Série de tablets Alba
4. Alcatel série 1 5033
5. Alcatel 1C
6. Alcatel 3L (2018) série 5034
7. Alcatel 3T8
8. Alcatel A5 LED série 5085
9. Alcatel série A30 5049
10. Alcatel Idol 5
11. Alcatel/TCL A1 A501DL
12. Alcatel/TCL LX A502DL
13. Alcatel Tetra 5041C
14. Amazon Fire 7 2019 – somente até Fire OS 6.3.1.2 build 0002517050244
15. Amazon Fire HD 8 2016 – somente até Fire OS 5.3.6.4 build 626533320
16. Amazon Fire HD 8 2017 – somente até Fire OS 5.6.4.0 build 636558520
17. Amazon Fire HD 8 2018 – somente até Fire OS 6.3.0.1
18. Amazon Fire HD 10 2017 – somente até Fire OS 5.6.4.0 build 636558520
19. Amazon Fire HD 10 2019 – somente até Fire OS 7.3.1.0
20. Amazon Fire TV 2 – somente até Fire OS 5.2.6.9
21. ASUS ZenFone Max Plus X018D
22. ASUS ZenPad 3s 10 Z500M
23. Série ASUS ZenPad Z3xxM(F) baseada em MT8163
24. Tablet Barnes & Noble NOOK 7" BNTV450 e BNTV460
25. Tablet Barnes & Noble NOOK 10,1" BNTV650
26. Blackview A8 Max
27. Blackview BV9600 Pro (Helio P60)
28. BLU Life Max
29. BLU Life One X
30. Série BLU R1
31. BLU R2 LTE
32. AZUL S1
33. BLU Tank Xtreme Pro
34. BLU Vivo 8L
35. BLU Vivo XI
36. BLU Vivo XL4
37. Bluboo S8
38. BQ Aquaris M8
39. GATO S41
40. Coolpad Cool Play 8 Lite
41. Dragão Toque K10
42. Sentimento de eco
43. Gionee M7
44. HiSense Infinity H12 Lite
45. Huawei GR3 TAG-L21
46. Huawei Y5II
47. Série Huawei Y6II MT6735
48. Lava Iris 88S
49. Série Lenovo C2
50. Lenovo Tab E8
51. Lenovo Tab2 A10-70F
52. LG K8+ (2018) X210ULMA (MTK)
53. LG K10 (2017)
54. Dinastia Tributo LG
55. Série LG X power 2/M320 (MTK)
56. Série LG Xpression Plus 2/K40 LMX420
57. Lumigon T3
58. Meizu M5c
59. Meizu M6
60. Meizu Pro 7 Plus
61. Nokia 1
62. Nokia 1 Plus
63. Nokia 3
64. Nokia 3.1
65. Nokia 3.1 Plus
66. Nokia 5.1
67. Nokia 5.1 Plus/X5
68. Onn tablet Android de 7"
69. Onn série de tablets de 8" e 10" (MT8163)
70. OPPO A5s
71. Série OPPO F5/A73 – apenas Android 8.x
72. Série OPPO F7 – apenas Android 8.x
73. Série OPPO F9 – apenas Android 8.x
74. Oukitel K12
75. Proverdamente D7
76. Eu de verdade 1
77. Sony Xperia C4
78. Série Sony Xperia C5
79. Sony Xperia L1
80. Sony Xperia L3
81. Série Sony Xperia XA
82. Série Sony Xperia XA1
83. Sul Telecom Smartab ST1009X (MT8167)
84. TECNO Spark 3 série
85. Série Umidigi F1
86. Poder Umidigi
87. Passeio Wiko
88. Wiko Sunny
89. Wiko View3
90. Série Xiaomi Redmi 6/6A
91. Lâmina ZTE A530
92. Lâmina ZTE D6/V6
93. ZTE Quest 5 Z3351S

consulte Mais informação

Com exceção dos telefones baseados em MediaTek da Vivo, Huawei/Honor (após Android 8.0+), OPPO (após Android 8.0+) e Samsung, membros da comunidade XDA descobriram que MediaTek-su funciona com mais frequência quando tentado em dispositivos afetados chipsets. De acordo com o membro diplomático do XDA, os dispositivos Vivo, Huawei/Honor, OPPO e Samsung “usam modificações no kernel para impedir o acesso root via exploits", o que significa que o desenvolvedor precisaria se aprofundar no código-fonte do kernel desses dispositivos para criar "versões personalizadas" do explorar. Isso não valia o esforço adicional, então o desenvolvedor optou por não adicionar suporte para esses dispositivos, embora, “em teoria”, a exploração ainda pudesse funcionar.

Até agora, deve estar claro que esta exploração afeta um grande número de dispositivos no mercado. Os chips MediaTek alimentam centenas de modelos de smartphones econômicos e de gama média, tablets baratos e fora da marca decodificadores, muitos dos quais são vendidos sem a expectativa de atualizações oportunas do fabricante. Portanto, é improvável que muitos dispositivos ainda afetados pelo MediaTek-su sejam corrigidos por semanas ou meses após a divulgação de hoje, se é que conseguirão. Então, o que faz o MediaTek-su ganhar sua gravidade "Crítica" com um CVSS v3.0 pontuação de 9,3?

Por que o MTK-su é uma vulnerabilidade crítica de segurança

Para reiterar, a maneira típica de obter acesso root em um dispositivo Android é primeiro desbloquear o bootloader, o que desativa a verificação da partição de inicialização. Assim que o bootloader for desbloqueado, o usuário pode introduzir um binário de superusuário no sistema e também um aplicativo de gerenciamento de superusuário para controlar quais processos têm acesso ao root. Desbloquear o bootloader é desabilitar intencionalmente um dos principais recursos de segurança do dispositivo, e é por isso que o usuário deve permitir explicitamente que isso aconteça, normalmente ativando uma alternância nas Opções do desenvolvedor e, em seguida, emitindo um comando de desbloqueio para o carregador de inicialização. Com o MediaTek-su, entretanto, o usuário não precisa desbloquear o bootloader para obter acesso root. Em vez disso, tudo o que eles precisam fazer é copiar um script para o dispositivo e executá-lo no shell. O usuário não é o único que pode fazer isso. Qualquer aplicativo em seu telefone pode copiar o script MediaTek-su para seu diretório privado e executá-lo para obter acesso root no shell. Na verdade, o membro diplomático do XDA destaca essa possibilidade em seu tópico do fórum quando eles sugerem um conjunto alternativo de instruções usando o Emulador de terminal para aplicativo Android ou Termux em vez de ADB.

Com acesso root, o modelo de segurança do Android basicamente desmorona. Por exemplo, as permissões tornam-se sem sentido no contexto de root, pois um aplicativo com acesso a um shell de root pode conceder a si mesmo qualquer permissão que desejar. Além disso, com um shell raiz, toda a partição de dados – incluindo arquivos armazenados em diretórios de dados privados de aplicativos normalmente inacessíveis – fica acessível. Um aplicativo com root também pode instalar silenciosamente qualquer outro aplicativo que desejar em segundo plano e, em seguida, conceder a eles todas as permissões necessárias para violar sua privacidade. De acordo com o desenvolvedor reconhecido pelo XDA topjohnwu, um aplicativo malicioso pode até “injetar código diretamente no Zygote usando ptrace”, o que significa que um aplicativo normal no seu dispositivo pode ser sequestrado para cumprir as ordens do invasor. Esses exemplos abordam apenas algumas maneiras pelas quais um aplicativo pode violar sua confiança em segundo plano, sem o seu conhecimento. No entanto, aplicativos maliciosos podem causar estragos no seu dispositivo sem esconder o que estão fazendo. O ransomware, por exemplo, é extremamente potente com acesso root; se você não pagar, um aplicativo ransomware hipotético poderia total e irreversivelmente torne seu dispositivo inoperante limpando todo o dispositivo.

A única “fraqueza” do MediaTek-su é que ele concede ao aplicativo apenas acesso root “temporário”, o que significa que um processo perde o acesso de superusuário após a reinicialização do dispositivo. Além disso, em dispositivos com Android 6.0 Marshmallow e superior, a presença de Inicialização verificada e dm-verity bloquear modificações em partições somente leitura, como sistema e fornecedor. No entanto, esses dois fatores são, em sua maioria, apenas obstáculos para modders em nossos fóruns, e não para atores mal-intencionados. Para superar a limitação do root temporário, um aplicativo malicioso pode simplesmente executar novamente o script MediaTek-su a cada inicialização. Por outro lado, há pouca necessidade de superar o dm-verity, pois é improvável que modificações permanentes no sistema ou nas partições do fornecedor interessem a maioria dos autores de malware; afinal, já existem toneladas de coisas que um aplicativo malicioso pode fazer com um shell root.

Se você está se perguntando em nível técnico o que o MediaTek-su está explorando, a MediaTek compartilhou conosco o gráfico abaixo que resume o ponto de entrada. A falha aparentemente existe em um dos drivers Linux Kernel da MediaTek chamado “CMDQ”. A descrição afirma que, "ao executar IOCTL comandos no nó do dispositivo CMDQ", um invasor local pode "ler/escrever arbitrariamente na memória física, despejar [a] tabela de símbolos do kernel no buffer DMA pré-alocado, [e] manipular o buffer DMA para modificar as configurações do kernel para desativar o SELinux e escalar para 'root' privilégio."

De acordo com o gráfico que a MediaTek compartilhou conosco, esta vulnerabilidade afeta dispositivos MediaTek com Linux Kernel versões 3.18, 4.4, 4.9 ou 4.14 executando versões Android 7 Nougat, 8 Oreo ou 9 Pie. A vulnerabilidade não pode ser explorada em dispositivos MediaTek rodando Android 10, aparentemente, já que “a permissão de acesso do CMDQ nós de dispositivos também são aplicados pelo SELinux." Essa mitigação provavelmente vem de uma atualização do BSP da MediaTek, e não do Android em si. A única mitigação do Android 10 para esta vulnerabilidade é a sua restrição para aplicativos que executam binários em seu diretório inicial; no entanto, como observa topjohnwu, desenvolvedor reconhecido pelo XDA, um aplicativo malicioso pode simplesmente executar o código MediaTek-su em uma biblioteca dinâmica.

Embora a MediaTek tenha corrigido esse problema em todos os chipsets afetados, eles não podem forçar os fabricantes de dispositivos a implementar os patches. A MediaTek nos disse que tinha patches prontos em maio de 2019. A Amazon, sem surpresa, corrigiu imediatamente o problema em seus dispositivos assim que eles foram informados. No entanto, já se passaram 10 meses desde que a MediaTek disponibilizou uma correção aos seus parceiros, ainda em Março de 2020, dezenas de OEMs não consertaram seus dispositivos. A maioria dos dispositivos afetados está em versões mais antigas do Android com níveis de patch de segurança (SPLs) desatualizados do Android, e a situação de atualização é ainda pior quando você considera o centenas de modelos de dispositivos menos conhecidos usando esses chips MediaTek. MediaTek tem um sério problema em mãos aqui, então eles recorreram ao Google para obter ajuda.

Ao contrário da MediaTek, o Google pode forçar os OEMs a atualizar seus dispositivos por meio de contratos de licença ou termos do programa (como Android One). Para que um OEM declare que um dispositivo está em conformidade com o nível de patch de segurança (SPL) 2020-03-05, o dispositivo deve incluir toda a estrutura, Kernel Linux e correções de driver de fornecedor aplicáveis ​​no Boletim de segurança do Android de março de 2020, que inclui uma correção para CVE-2020-0069, ou MediaTek-su. (O Google não parece realmente impor isso Os OEMs realmente mesclam todos os patches ao declarar um determinado SPL.) Agora que o boletim de março de 2020 foi lançado, essa história deveria acabar, certo? Infelizmente, também temos que manter os pés do Google no fogo por demorarem a incorporar os patches.

A falha no processo de patch de segurança

Caso ainda não esteja claro, nem toda vulnerabilidade de segurança precisa acabar em um Boletim de Segurança do Android. Muitas vulnerabilidades são descobertas e corrigidas pelos fornecedores sem que elas apareçam no boletim mensal. MediaTek-su deveria ser um deles, mas por vários motivos, vários OEMs não conseguiram integrar os patches oferecidos pela MediaTek. (Existem muitas razões potenciais para isso, desde falta de recursos, decisões de negócios até falha na comunicação.) Quando eu anteriormente afirmou que a MediaTek "recorreu ao Google" em busca de ajuda, isso implicava que a MediaTek buscou ativamente a ajuda do Google para fazer com que os OEMs finalmente consertassem seus dispositivos. No entanto, esse pode não ter sido realmente o caso. Entendo que o Google não tinha conhecimento do MediaTek-su até que ele foi acidentalmente mencionado em um relatório de segurança de TrendMicro publicado em 6 de janeiro de 2020. No relatório, TrendMicro estava documentando outro vulnerabilidade de segurança, apelidada de "use-after-free no driver do fichário"vulnerabilidade, que estava sendo ativamente explorada em estado selvagem. TrendMicro observou como três aplicativos maliciosos obtiveram acesso root usando um de dois métodos, a vulnerabilidade “use-after-free in binder driver” ou MediaTek-su.

No código que TrendMicro compartilhados, podemos ver claramente como os aplicativos maliciosos tinham como alvo modelos de dispositivos específicos (por exemplo, Nokia 3, OPPO F9 e Redmi 6A) e empregando MediaTek-su neles.

Eu não posso falar por TrendMicro, mas parece que eles não sabiam que o MediaTek-su era um exploit ainda não corrigido. Afinal, o foco deles estava na exploração “use-after-free in binder driver”, e a descoberta do uso do MediaTek-su parece ter sido uma reflexão tardia. (tenho certeza que se TrendMicro estivessem cientes da situação em torno do MediaTek-su, eles teriam coordenado seus esforços de divulgação com o Google.) Fomos informados apenas de nós mesmos fizemos essa exploração em 5 de fevereiro de 2020 e, depois de investigarmos por nós mesmos o quão ruim era, entramos em contato com o Google sobre isso em 7 de fevereiro, 2020. O Google estava tão preocupado com as repercussões da divulgação do MediaTek-su que nos pediu para adiar a publicação desta história até hoje. Depois de considerar os danos irreparáveis ​​que podem ser infligidos aos usuários alvo de malware usando MediaTek-su, concordamos em suspender esta história até o anúncio do Android de março de 2020 Boletim de Segurança. Ainda assim, considerando quanto tempo muitos dispositivos levarão para obter a atualização de segurança mais recente, se algum dia se conseguir, é provável que haja uma tonelada de dispositivos ainda vulneráveis ​​ao MediaTek-su daqui a alguns meses agora. Isso deveria ser horrível para qualquer pessoa com um dispositivo vulnerável.

Embora esta vulnerabilidade muito séria e de gravidade "crítica" esteja sendo ativamente explorada, o Google apenas inserido na correção para esse problema no boletim de março de 2020, cerca de 2 meses depois de terem sido informados do emitir. Embora o Google informe seus parceiros Android sobre o último Boletim de Segurança do Android 30 dias antes de o boletim ser tornado público (ou seja, Os OEMs foram informados sobre o que está no boletim de março de 2020 no início de fevereiro de 2020). O Google pode, e frequentemente o faz, atualizar o boletim com alterações ou novas correções. Por que o Google não optou por agilizar a inclusão de um patch para um problema tão sério está além da minha compreensão, especialmente quando a MediaTek teve uma solução para isso há 10 meses. Se tal bug fosse descoberto nos dispositivos da Apple, não tenho dúvidas de que eles teriam emitido uma correção muito, muito mais rápido. O Google apostou essencialmente na aposta arriscada de que o MediaTek-su permaneceria aparentemente tão discreto como já era até o boletim de março de 2020. Embora o Google pareça ter tido sorte nesse aspecto, não temos ideia de quantos autores de malware já sabem sobre a exploração. Afinal, ele está em um tópico aleatório do fórum XDA há quase um ano inteiro.

Há mais uma parte neste desastre que não abordei muito, e é o autor da exploração, o membro diplomático do XDA. Para seu crédito, não acho que ele tenha tido qualquer intenção maliciosa ao publicar o MediaTek-su. Podemos claramente traçar a origem da exploração ao desejo diplomático de modificar os tablets Amazon Fire. Diplomatic me disse que seu objetivo principal ao desenvolver esse método raiz era ajudar a comunidade. Personalizar seu dispositivo é o objetivo do XDA, e os esforços diplomáticos na comunidade são o que as pessoas gostam nos fóruns. Embora a recusa diplomática em abrir o código do projeto suscite algumas preocupações, ele explica que queria que a comunidade aproveitasse o acesso root pelo maior tempo possível. Quando entrei em contato diplomático pela primeira vez, ele também afirmou que estava em colaboração com alguns parceiros que o impediam de compartilhar o código-fonte e a pesquisa do projeto. Embora não tenha conseguido obter mais detalhes sobre esta colaboração, pergunto-me se a diplomacia teria optado por divulgar esta exploração se a MediaTek oferecesse um programa de recompensas por bugs. Não consigo imaginar que uma vulnerabilidade desta magnitude não renderia uma grande quantia de dinheiro se a MediaTek realmente tivesse tal programa. Diplomático afirma que esta exploração tem sido possível desde o chipset MediaTek MT6580 do final de 2015, por isso é de se perguntar se o diplomático é mesmo a primeira pessoa a encontrar esta exploração. Ele me disse que não tinha ideia de que o MediaTek-su estava sendo explorado ativamente até a publicação deste artigo.

Se você quiser verificar se o seu dispositivo é vulnerável ao MediaTek-su, execute manualmente o script postado pelo membro diplomático do XDA neste tópico do fórum XDA. Se você inserir um shell root (você saberá quando o símbolo mudar de $ para #), saberá que o exploit funciona. Se funcionar, você precisará esperar que o fabricante do seu dispositivo lance uma atualização que corrija o MediaTek-su. Se o seu dispositivo relatar o nível de patch de segurança 2020-03-05, que é o SPL mais recente de março de 2020, é quase certo que ele esteja protegido contra MediaTek-su. Caso contrário, você terá que apenas verificar se o seu dispositivo está vulnerável.

---

Atualização 1 (02/03/2020 às 21h45 EST): Este artigo foi atualizado para esclarecer que o membro diplomático do XDA estava realmente ciente do escopo desta vulnerabilidade assim que ele descobriu-o em fevereiro de 2019, mas não sabia do uso do exploit na natureza até a publicação deste artigo. Também corrigimos nosso texto em relação a um dos motivos pelos quais a diplomacia se recusou a compartilhar o código-fonte do projeto.