Google Play Malwares Obfuscados LOL

Sem muitas delongas quero apresentar uma postagem de Luiz delgado sobre malwares em sistemas mobiles!
Um pouco mais de um mês e meio, eu era capaz de participar do Nome n º 2012 , com a apresentação ser mais inteligente que G00gle! onde você tinha uma técnica para injetar código malicioso em aplicações Android que, a priori, são inofensivos.

Este verão Nicholas J. Percoco e Sean Schulte apresentado na BlackHat EUA 2012 um documento intitulado "Adventures in Bouncerland" (você pode encontrar o whitepaper aqui ) em que explicou como isso poderia se transformar em um aplicativo inofensivo através JSBridge malicioso. Basta comentar que esta técnica tira vantagem da ponte criada entre código Javascript (doravante JS), que interpreta a aplicação via componente WebView e métodos de aplicação de código nativo. Dessa forma, você pode acessar os métodos de aplicação (como o envio de um SMS) através de JS, assim como aplicativos como o Facebook (versão HTML5).

A seguir é um exemplo simples que ilustra essa técnica:




Embora seja uma técnica muito interessante que permite modificar dinamicamente o comportamento do aplicativo (a partir de HTML / JS em páginas que abrem com componente WebView), executar o código nativo está sempre presente na aplicação e não ser alterado a menos que o aplicativo é atualizado.

Tendo a desvantagem de usar JSBridge, eu pensei que poderia ser interessante para aproveitar as possibilidades oferecidas em termos de carga dinâmica de classes Java na memória, criar malwares modular que mantém uma aplicação benigna (sem código comportamento suspeito ou malicioso) para que você adicionar as capacidades diferentes, dependendo das necessidades de todos os tempos (e, dependendo das características do firmware do dispositivo, e outro em que você está executando).

Além disso, o uso dessas técnicas, podemos evitar os mecanismos de segurança implementados no Google Play (a loja de aplicativos Android oficial) e mais recentemente no nível do dispositivo (versões 4.2 + verificar para aplicativos instalados de fontes desconhecidas contêm malware) como uma análise automática do aplicativo não é capaz de encontrar qualquer código ou comportamento malicioso que, a priori, não existe na aplicação (nem mesmo parte do código como com a técnica JSBridge).

Para ver mais em detalhes como esta técnica irá usar um exemplo de um aplicativo que simula uma galeria com os últimos sete fotografias utilizadas no motor de busca Bing.




A aplicação foi publicado em BingImages Google Play de 06 de setembro de 2012 (a apenas removido) para demonstrar que a utilização de tais técnicas é perfeitamente exequível. Também é importante notar que este tipo de situação (uso de bibliotecas) é normal e, portanto, não é executado como qualquer tipo de código malicioso durante a sua Bouncer análise, a sua detecção é complicada. Ele também poderia usar técnicas de recolha de impressões digitais para detectar se estamos sendo analisados ​​por Bouncer e, em caso afirmativo, camuflar ainda mais, se possível (você pode ler mais sobre PF na Bouncer whitepaper 'Android Dissecando Bouncer " de Charlie Miller e Jon Oberheide ).

O código do aplicativo (tanto como BingUpdater-Updater BingImages incluindo malicioso carga) pode ser baixado do meu site .

Com relação ao código usado em BingImages entrar em contato com o servidor de comando e controle que vai dizer se você precisa baixar uma carga útil e como executar e, em seguida, carregando na memória:




Basta comentar que se o servidor de comando e controle indica que há atualizações, baixar o APK indicado em JSON, carrega na memória usando carregador DexClassLoader (solicitado criar um caminho temporário onde a DEX e, posteriormente, remover-método cleanTemporalyFiles () -) e executa o método original (também indicado em JSON). Assim, a carga pode ter a estrutura que se pretende, sem ter de se tornar "ligado" para um limite fixo no futuro.

Ocultação é feito no aplicativo (indicado na DexClassLoader o caminho onde você tem que criar arquivos temporários DEX) fazendo com que o código malicioso a estar disponíveis apenas em memória durante a execução e só então porque o coletor de lixo do Java é responsável para removê-lo sem ter que liberar memória manualmente ou reiniciar o dispositivo. Embora sempre haja evidências (por exemplo, o cache Dalvik é armazenado DEX otimizado para evitar a sua criação, em cada corrida, e nós não poderíamos remover, exceto com uma exploração ou se o dispositivo é "rooteado'), esta técnica complica estudo nível de espécime de malware e / ou forense de dispositivos infectados (a priori seria encontrar um dispositivo que tenha sido infectado sem clara qual a aplicação é a culpa).

Um exemplo simples de uma carga pode ser um módulo que envia para o servidor de comando e controle, todos os arquivos que estão armazenados na pasta WhatsApp SDCard (permissões só precisa de internet, lendo o SDCard não têm quaisquer restrições -essa permissão teria que ser declarada na "aplicação padre'). E como eu disse Alex algum tempo, a criptografia não seria um problema .




Sempre que eu falo sobre este assunto, comentou que um dos usos desta técnica seria a criação de "pai" de um aplicativo que só tem permissão internet (facilmente justificá-lo) e que os módulos de tirar vantagem das vulnerabilidades que permitem a elevação de privilégios ( ações vulnerabilidades de aplicativos , vulnerabilidades no Android , a depuração ...) ou "desvio" permissões , etc.

Mais de uma semana que estamos falando sobre a vulnerabilidade descoberta no famoso móvel processadores Samsung Exynos 4210 e 4412 (você pode encontrar uma boa explicação da questão no artigo em um dia ). Basicamente vulnerabilidade reside na atribuição de permissões do arquivo / dev / mem Exynos, que permite o acesso a todos os dispositivos de memória RAM para qualquer usuário do dispositivo. Você pode acessar o exploit em este post no fórum do XDA-Developers .

O que se você baixar nossos cheques módulo de malware se entre os modelos afetados, para verificar este arquivo e suas permissões, e baixar o exploit? Teria um aplicativo na loja de aplicativos Android que é capaz de executar permissões como root sem o dispositivo de ter que estar rooteado ou notificar o usuário em pouco tempo!

No código postado no BingUpdater são dois exemplos, um no qual a cópia do banco de dados 'fb.db "do aplicativo do Facebook para SDCard (contém, entre outras informações muito tokens, autenticação) eo segundo faz 'root' do dispositivo. Abaixo está um vídeo de todo o processo (download de um aplicativo do Google Jogar ele acaba sendo um malware com acesso total ao dispositivo):


Você pode acessar o código da aplicação e outros materiais:


Cortesia do artigo de Luís Delgado
Google Play Malwares Obfuscados LOL Google Play Malwares Obfuscados LOL Reviewed by Kembolle Amilkar on terça-feira, janeiro 01, 2013 Rating: 5

Nenhum comentário