Image: etnyk , cláusula CC-BY-NC 2.0 Nós fazemos o ND

O uso de smartphones na vida cotidiana não é limitado a chamadas de voz e SMS. A capacidade de baixar e executar programas, bem como acesso à Internet móvel têm levado ao surgimento de um grande número de aplicações móveis. A funcionalidade de um moderno navegadores de smartphones compõem, os programas cliente de redes sociais, aplicativos de escritório e vários serviços em execução na rede. Android-dispositivos tomaram a maior parte do mercado de smartphones devido à arquitetura aberta da plataforma Android eo conveniente desenvolvedor API. No momento, o Android é a quota de mercado do sistema operacional móvel mais popular de mais de 75%. O número de aplicativos baixados da loja Google Play, foi 65 bilhões em 2016 [1] .

observado um rápido crescimento paralelo do número de aplicações maliciosas: sua 2300000 foi descoberto em 2015 [3] . Além disso, cerca de 60% ANDROID-dispositivos operam sobre as versões do sistema operacional com vulnerabilidades conhecidas, e que pode potencialmente ser atacado por hackers [6] . Essas ameaças, por sua vez, levou ao desenvolvimento dos meios de protecção. loja oficial Google Play introduziu aplicações de filtragem usando a caixa de areia Google Bouncer. As empresas de antivírus começou a produzir seus produtos com Android (embora, como mostra a [8] , muitos deles em si mesmos contêm uma vulnerabilidade perigosa). O número de publicações científicas sobre o assunto também aumentou, um dos trabalhos do inquérito em 2015 sobre soluções de segurança Todos os apps [2] tem mais de 40 projetos e menciona nem todos conhecido na época do estudo. Devido ao fato de que os dispositivos móveis são a fonte e repositório de um grande número de dados confidenciais, problema do Android e suas aplicações de segurança do sistema operacional é particularmente aguda.

A plataforma Android é um software livre, a base de seu código-fonte é completamente aberto. fabricantes de dispositivos desenvolver sua própria base de código, criando um firmware especializado, a fim de alcançar uma maior funcionalidade e melhor desempenho. Subproduto destas atividades são as vulnerabilidades e fraquezas na implementação de algoritmos que não estão na base de código principal, mas existente no conjunto de dispositivos reais. Malware usa essa vulnerabilidade para melhorar os direitos e mecanismos de defesa superação. Identificar vulnerabilidades no firmware na fonte ausência é extremamente difícil. O principal problema é a falta de um desempenho ambiente controlado, que é necessário para a análise dinâmica.

Assim, um dispositivo de análise de segurança completa requer um estudo das propriedades de sistema e software de aplicação em conjunto. Este artigo apresenta uma classificação de seus próprios problemas de segurança do Android, bem como uma lista de requisitos para o sistema de análise plataforma Android de todo o sistema.

1. O dispositivo está sendo executado Android

O sistema operacional Android é baseado no kernel do Linux com algumas alterações de arquitetura que foram feitas por engenheiros do Google. Aplicativos para o sistema operacional Android desenvolvido em Java. A partir da versão 1.5 Android Android NDK conjunto de ferramentas foi introduzido, o que permite o desenvolvimento de módulos de aplicação em C e C ++ compilado e em código de máquina [4] . As aplicações estão disponíveis na forma de um formato especial de arquivo APK, que é um arquivo ZIP com uma certa estrutura de diretórios e arquivos. aplicativo APK-arquivo inclui:

  • manifesto;
  • módulos compilado em código de máquina (compartilhada .so bibliotecas);
  • vários recursos de aplicação;
  • DEX-lima;
  • outros arquivos necessários.

Começando com a versão Android 4.4 suporta dois ambientes de execução de aplicação: Dalvik VM e ART.Deve-se notar que o processo de preparação de APK-arquivo não foi alterado, apenas o processo de instalação do aplicativo alterado na nova arte de tempo de execução. A partir da versão 5.0 ART tempo de execução foi utilizado em vez do padrão Dalvik VM.

Runtime Dalvik VM Java-programas para o Android é muito diferente do “normal» Java VM. Em primeiro lugar, quando você compilar o Java-programa, ele é compilado em bytecode a máquina virtual Dalvik, que é muito diferente da máquina virtual bytecode HotSpot. máquina virtual Dalvik é baseada no registo, o que torna o seu desempenho em RISC-arquitetura, comumente usado em dispositivos móveis mais eficientes. E restrições de memória em conta no desenvolvimento de Dalvik em dispositivos móveis. Começando com a versão Android 2.2 inclui tempo de execução Dalvik JIT-compilador que compila os pedaços “quentes” de código Java-programa para código de máquina [5] .

bibliotecas Java padrão foram modificados ou substituídos pela biblioteca do pacote Apache Harmony ou escrita re-. Quando você compilar o Java-programa recebe formato de arquivo DEX (Dalvik Executable), que contém o código de byte para a máquina virtual Dalvik. formato de arquivo foi desenvolvido a fim de reduzir o uso de memória e significativamente diferente do formato JAR padrão. Para chamar os módulos implementados no código nativo de Java-programas usando a interface JNI. Note-se que é possível para carregar os módulos de máquina dinamicamente através da rede utilizando componente DexClassLoader.

2. Questões de segurança

processo pai para todas as aplicações no sistema operacional Android é o processo de zigoto. Este processo é a estrutura do aplicativo Android, que já está carregado com todas as bibliotecas necessárias ambiente Android, mas não há nenhum código para o próprio aplicativo. Executando o aplicativo Android com o ponto de sistema operacional de vista é a seguinte:

  1. Inicialmente, ocorre chamada de sistema fork para criar um processo filho do Zygote (ver Fig.. 1).
  2. Neste novo processo abre o arquivo do aplicativo para executar (chamada de sistema aberto).
  3. Lê as informações sobre os arquivos de classe (classes.dex) e recursos do arquivo do aplicativo. É aberto soquetes para IPC.
  4. chamada de sistema mmap é realizada para exibir os arquivos do aplicativo na memória.
  5. O ambiente de execução executa a configuração necessária e executa a aplicação (interpreta um código de bytes ou Dalvik passa funções de controlo no código executável no caso ARTE [7] ).

Ao nível do kernel do sistema operacional Android, cada aplicação é um processo separado com valores exclusivos de usuário / ID de grupo, que são dadas a ele durante a instalação. Assim, cada programa é executado em seu sandbox. A partir da versão 4.3, para além da componente política de segurança é adicionado SELinux controle de acesso obrigatório [10] .

Fig. 1. Iniciar um novo aplicativo para o sistema operacional Android

Por padrão, o aplicativo é limitado nas suas capacidades e não podia fazer nada para prejudicar outra aplicação ou utilizador: nenhum dado do utilizador ler ou modificar as aplicações do sistema; não há acesso à rede. Para obter acesso a vários recursos do aplicativo acessa os serviços do sistema operacional Android. As permissões de acesso são definidos estaticamente no arquivo de manifesto do aplicativo e deferiu o pedido, enquanto ele está sendo executado conforme necessário. O sistema solicita ao usuário autorização para a emissão das autorizações durante a instalação ou durante a atualização do aplicativo. Responsável pela emissão aplicação de acesso é o usuário, ele é livre para decidir qual aplicativo de dar permissão para certas ações, e que não se deve dar, – durante a instalação. Usando essa abordagem, em que todas as licenças são emitidas uma vez ao instalar o aplicativo, levou ao fato de que os usuários têm de distribuir aplicativos poderes, sem considerar as conseqüências. Por sua vez, as aplicações começaram a exigir mais e mais licenças para a expansão da sua funcionalidade. O Android 6 Marshmallow este sistema é substituído por outro: o aplicativo solicitar acesso aos recursos do usuário enquanto ele está executando, e o usuário pode permitir o acesso ou proibir-lo [11] .

Todos os apps aplicação consiste em quatro tipos de componentes e não contém uma função main (), ou algum outro único ponto de entrada. componentes do aplicativo interagir uns com os outros por meio de mensagens especiais, chamados de Intenção.

Componentes chamados Atividade definir a interface do usuário. Tipicamente, um é utilizado para descrever uma aplicação de écran único componente Actividade. Atividade pode iniciar outra atividade, passando parâmetros usando Intenção mecanismo. Durante a operação, apenas uma atividade pode executar e responder à entrada do usuário, o outro neste momento permanecem congelados ou destruídos, dependendo do modo selecionado da aplicação.

Componentes chamados Serviço [9] produzir processamento em background. Atividade Quando você precisa executar alguma operação, como download de arquivos ou tocar música, e continuar a trabalhar quando o usuário mudar para outro aplicativo ou virou atual, o aplicativo é iniciado o serviço, cujo objetivo – para realizar esta ação. Os desenvolvedores podem usar o serviço como um aplicativo daemon, que começa no momento da inicialização. componente de serviço geralmente suporta RPC (Remote Procedure Call), de modo que os outros componentes do sistema podem se referir a ele.

Componente provedor de conteúdo mantém e comunica usando uma interface de banco de dados relacional.Cada provedor de conteúdo tem um URI única para os dados e processa os pedidos para ele na forma de SQL (Select, Insert, Delete) fila.

componentes do receptor de transmissão funcionam como caixas de correio para mensagens de outros aplicativos.

Os problemas de segurança que surgem no sistema operacional Android, foram considerados em [ 2 , 12 , 13], mas a classificação dos problemas por categorias só é dada no artigo [2] . Esta classificação é muito detalhado e abrange uma série de problemas de segurança, mas tem algumas desvantagens significativas: algumas categorias abrangem uma ampla gama de vulnerabilidades, enquanto outros são especializados o suficiente; dada a categoria de vulnerabilidades não corresponde à arquitetura camadas de software OS Android; não coberta pela vulnerabilidade das fontes da Internet, bem como mal coberto vulnerabilidades em protocolos e equipamentos (Sec. 2.7 e 2.8 no nosso classificação). A seguinte proposta de classificação de vulnerabilidades elimina estes inconvenientes.

2.1. A vulnerabilidade do kernel do Linux e seus módulos

Esta categoria de problemas são as vulnerabilidades que são comuns a todos os sistemas operacionais baseados na mesma versão do kernel do Linux que o OS Android. Explora vulnerabilidades no kernel, pode receber dados do usuário ou privilégios de administrador do sistema. Elevar privilégios de processo para o administrador do sistema, o software malicioso pode desativar o sistema de segurança Android, para inserir em programas existentes códigos maliciosos e instalar um rootkit. Além disso, os fabricantes de vários dispositivos são adicionados aos módulos centrais para os dispositivos; estes módulos também podem ser vulneráveis. Exemplos de privilégio vulnerabilidades de elevação descrito em [ 14 , 15 , 16 , 64 ]. Também digno de nota é que a vulnerabilidade no componente ashmem foi descoberto recentemente para comunicação entre processos no All Android [62] .

2.2. Vulnerabilidades modificações e os fabricantes de dispositivos componente

Recentemente, os fabricantes têm uma variedade de dispositivos móveis começou a produzir seu firmware modificado Android. Estes firmware podem conter uma variedade de aplicações e serviços desenvolvidos pelo fabricante do dispositivo, que são muitas vezes impossível de remover. Por exemplo, um backdoor escondido no firmware Foxconn foi descoberto em outubro 2016 [63] . A análise destes serviços no artigo [17] mostra que elas contêm de 65 a 85% vulnerabilidades encontradas em todo o sistema. Além disso, é importante notar que as vulnerabilidades que foram encontrados e corrigidos no ramo principal Android, pode permanecer muito tempo nos ramos fabricantes de dispositivos [ 18 , 19 ].

2.3. Vulnerabilidades em módulos de código máquina

aplicações apoiadas pelo Android executar código nativo via interface JNI. Isto gera uma outra categoria de vulnerabilidade associada com as amplamente conhecidas fugas de memória vulnerabilidades nas linguagens de baixo nível (por exemplo, C ou C ++) [20] . Desde nível do processo OS Android não há restrições, exceto para o kernel Linux, bibliotecas de terceiros em código de máquina pode usar as licenças emitidas em todo o aplicativo, para realizar atividades maliciosas (ver. Como as seguintes categorias de vulnerável, par. 2.4).Além disso, os módulos da aplicação na linguagem de máquina utilizados pelos autores de aplicativos maliciosos para contornar as ferramentas de análise e de monitorização do nível do Android. Estes módulos também pode ser usado para combater as técnicas de análise utilizadas em programas convencionais.

2.4. Vulnerabilidades mecanismos de interacção de interconexão

Esta categoria inclui vulnerabilidades associados com a interacção entre os vários componentes da aplicação.Como o nível do sistema operacional está limitado ao processo de sandbox do aplicativo, ele precisa de um mecanismo para acessar os componentes do sistema operacional Android para se comunicar com eles. Isto ocorre através de / dev / pasta e vários outros serviços do sistema operacional Android do dispositivo. Como mencionado acima, os parâmetros deste acesso são especificados no arquivo de manifesto, um permissões em arquivos XML. Análise apresentado em [ 12 , 21 , 22 , 23 , 24 , 25 ], isto indica restrições do sistema de falhas e mostra soluções alternativas. Por exemplo, um aplicativo pode aproveitar os direitos de outras aplicações e tenha acesso com a ajuda de seus dados através do ICC. Também pode haver um problema de segurança com bibliotecas de terceiros. bibliotecas de terceiros utilizados na aplicação, recebem o mesmo conjunto de restrições que o próprio aplicativo. Portanto, bibliotecas de terceiros podem usar as licenças emitidas em todo o aplicativo, para realizar atividades maliciosas. Os aplicativos também podem interceptar os eventos do sistema enviados através de uma solicitação de broadcast, e armazenar informações sobre as chamadas e SMS.

2.5. Vulnerabilidades no os próprios aplicativos

Cada aplicação armazena alguns dados sobre o usuário. Estes dados devem ser protegidos adequadamente para eles não poderiam aceder a outras aplicações – mas tal proteção nem sempre é fornecido. Por exemplo, o Skype em uma versão do aplicativo armazena um banco de dados de contatos no clara sobre o disco.Assim, os contactos podem ser lidos por qualquer outra aplicação que tem acesso ao disco [26] . Os aplicativos também podem usar erros de biblioteca de criptografia [27] , ou quaisquer implementações proprietárias. Além disso, nem todos os aplicativos fazer para autenticação forte e autorização do usuário.Além disso, o aplicativo pode permitir que o SQL-Injection e XSS vulnerável a ataques. Também digno de nota que a maioria das aplicações desenvolvidas escritos em Java sem usar qualquer proteção para código binário e Java byte, como é conhecido, pode ser facilmente desmontada e análise. Note-se que esta categoria inclui também conhecido lista de vulnerabilidades Móvel OWASP-10. Muitas dessas vulnerabilidades são descritas em [ 28 , 29 ].

2.6. Vulnerabilidades no serviços incorporados e bibliotecas

Um conjunto padrão de bibliotecas e os serviços em execução no Android, também contém a vulnerabilidade.Por exemplo, a vulnerabilidade Stagefright foi descoberto recentemente na biblioteca para exibir o vídeo a quaisquer mensagens de MMS, que tenham sido expostos a todas as versões do Android, começando com 2.2 [30] . vulnerabilidade mais tarde componente MediaServer foi detectado, o que afeta todas as versões do Android c 2,3 a 5,1 [31] . O artigo [13] mostra a vulnerabilidade do tempo de execução Dalvik: a execução de um grande número de processos no sistema, podemos garantir que o processo subsequente será lançado com privilégios de administrador.

2.7. fontes da internet

Android-aplicativos são distribuídos através de uma ampla série de outros do que a loja oficial aplicativo fontes. Desde Android-aplicações são escritas principalmente em Java, eles são fáceis de reverter o desenvolvimento e reembalagem com código malicioso [ 32 , 33 ]. Além disso, como foi mostrado no papel [34] , uma análise de sandbox aplicações Bouncer utilizados no catálogo oficial, fácil de se locomover. Por isso, na loja oficial contém um grande número de programas maliciosos. Além disso, o Android suporta a instalação remota de aplicativos do Google Play em dispositivos conectados à-conta do Google. Assim, se a conta Google hack para o dispositivo pode ser instalado a partir do Google Play para a aplicação de malware que para pré-carregar o atacante. Ao mesmo tempo em seu telefone móvel não requer qualquer evidência dessas ações, como eles são solicitados no navegador eo aplicativo é instalado no telefone no fundo enquanto obter acesso à Internet. Também nesta categoria de vulnerabilidade incluem o uso de engenharia social, quando continuar a oferecer para instalar o aplicativo a partir de fontes não autorizadas [35] .

2.8. A vulnerabilidade dos equipamentos e módulos relacionados e protocolos

Os dispositivos móveis que executam o sistema operacional Android, tem uma ampla gama de dispositivos para se comunicar com o mundo exterior. vulnerabilidade apropriada pode ser explorada em uma estreita proximidade com o dispositivo, ou se você tiver acesso físico ao dispositivo.

Exemplos de tais ataques são ataques como “negação de serviço” com a tecnologia Wi-Fi Direct [36] , o roubo de dados de cartão de crédito através da NFC [37] , a execução remota de código via Bluetooth [38] , a instalação de aplicativos maliciosos sem o conhecimento do usuário através adb com por meio do mecanismo apoios [39] . No documento [13] mostra a vulnerabilidade através do qual é possível aumentar os benefícios da aplicação do erro no protocolo de implementação adb.

3. Ferramentas para análise do Android-aplicações

Desde então, como o primeiro telefone baseado no Android, foi escrito um grande número de ferramentas para a análise de Android-aplicações foram liberados. A revisão mais abrangente desses instrumentos está contido nos trabalhos [ 40 , 41 , 42 , 2 ]. As três primeiras fontes de instrumentos categorizadas por tipo de análise: estática, dinâmica e combiná-los (mista). O artigo [2] é utilizado por ferramentas de classificação fase implementar aplicações no Android-dispositivo. Em nosso papel que usamos a classificação dos tipos de análise.

análise estática

ferramentas de análise estática podem ser divididos nas seguintes categorias:

  • Ferramentas que extraem informações meta do manifesto do aplicativo e fornecem informações sobre a permissão requerente, componentes de atividade, serviços e receptores de difusão registrado. Meta-informação é frequentemente utilizado mais tarde em uma análise dinâmica das funções para iniciar o aplicativo.
  • Ferramentas para a modificação de um código de bytes aplicação existente usando instrumentação arte.Isso permite, por exemplo, para adicionar funcionalidade de rastreamento para aplicativos existentes.
  • Ferramentas que implementam decompiler e desmontador Dalvik bytecode.

Uma das ferramentas de engenharia reversa mais popular é Apktool [43] . Ele tem capacidades de decodificação de recursos da aplicação ao redor forma original, reembalagem aplicações de volta para os / JAR-arquivos APK, depuração bytecode smali. Para a compilação e decompiling em apktool código de bytes Dalvik utilizado outro projecto smali / backsmali vulgarmente conhecido [44] . ferramenta Dedexer também para a desmontagem do bytecode Dalvik usada frequentemente [45] .

Radare2 [46] – uma ferramenta com código aberto para desmontar, analisar, depurar e modificar arquivos de aplicativos Android-binários.

Uma das ferramentas mais versáteis para análise estática – Androguard [47] . Ele pode desmontar e descompilar o aplicativo de volta para o código-fonte Java. Depois de receber dois APK-arquivo, ele pode calcular o coeficiente de sua semelhança para detectar aplicações reembalados ou aplicativos maliciosos conhecidos. Devido à sua flexibilidade é usado em alguns instrumentos de análise misturados.

Uma lista mais completa de ferramentas de análise estática podem ser encontrados nos artigos acima mencionados. Deve-se notar que a análise estática tem uma série de limitações relacionadas ao fato de que há apenas uma idéia abstrata do programa. Por exemplo, a análise estática torna-se muito mais difícil se o programa aplicado obfustsiruyuschie conversão. Dependendo da complexidade da ofuscação alguns (ou talvez todos) da abordagem estática pode ser completamente inútil. Se a chamada de cada método é apenas indiretamente, é improvável para construir um gráfico de chamadas do programa. No Android, esta conversão pode ser feito usando a API de Reflexão Java para chamar métodos e criar objetos em vez de usar a chamada e instruções de costume para criar um novo objeto. No mercado de soluções para a proteção do código fonte é já disponíveis vários produtos para ofuscação arquivos Android do aplicativo que pode negar todos os benefícios da análise estática [ 48 , 49 ]. Mais detalhes sobre o contador de técnicas de análise estática pode ser lido em 50 .

ferramentas de análise dinâmicos e mistos

ferramentas de análise dinâmica monitorar o comportamento do aplicativo desconhecido em tempo de execução quando é iniciado em uma sandbox controlado por traço comportamental. Isso é feito por instrumentar o sandbox em diferentes níveis da arquitetura de seções de código que rastreiam o comportamento do aplicativo e do sistema operacional Android.

Fig. 2. Níveis de arquitetura sandbox Android

arquitetura sandbox Android representa o emulador Android (geralmente QEMU), dentro do qual roda o sistema operacional Android. Instrumentação é feita tanto no nível do emulador ou no nível do sistema operacional Android, ou em ambos os lugares. nível do sistema operacional Android também é dividido em quatro subníveis:

  • aplicações
  • ambiente de desenvolvimento de aplicações,
  • aplicações e bibliotecas ambiente de trabalho,
  • o kernel e seus módulos.

Técnicas utilizadas na análise dinâmica do aplicativo:

  • Rastreamento de dados rotulados. Estas ferramentas são usadas para monitorar possíveis vazamentos de informações confidenciais.
  • sistema de monitoramento de chamadas. Ferramentas pode gravar chamadas de sistema usando a máquina virtual instrumentação, strace ou módulo kernel. Isso permite o rastreamento de código de computador.
  • métodos de rastreio (funções). As ferramentas podem rastrear chamadas técnicas Java de aplicativos em uma máquina virtual Dalvik, chamadas de função em código de máquina através de JNI, chamadas e interrupções do sistema.

As ferramentas incluem uma ferramenta de análise mistos que combinam a tecnologia de análise dinâmica e estática.

4. O sistema ideal de análise de todo o sistema da plataforma Android

Artigo [ 40 , 41 , 42 , 2 ] há mais de 40 ferramentas diferentes para aplicações Android-análise, e para a análise do sistema operacional Android como um todo. Como observado em [ 34 , 60 , 61 ], as ferramentas de análise dinâmica existentes têm um certo número de deficiências sérias. Estas desvantagens também existem na ferramenta padrão para analisar aplicativos na loja do Google Play – Google Bouncer, em que aplicativos maliciosos podem ser distribuídos através da loja oficial, sem ser detectado.

Uma comparação das características das publicações, abordagens e sistemas analisados ​​nos permite formular os requisitos ideais para o sistema de análise de plataforma Android, que é capaz de analisar em conjunto todas as camadas da aplicação de software e sistema. O sistema toma emprestado alguns métodos eficazes dos trabalhos analisados, combinando-os a superar as limitações das soluções existentes.

A arquitectura de sistema é mostrada na Fig. 3. O principal componente é um simulador de todo o sistema, que pode ser baixado como firmware do sistema operacional Android com dispositivos reais, e a imagem do emulador Android oficial. O emulador mantém sensores de encaminhamento do dispositivo real, bem como porções de código de execução separados para dispositivos reais. Dentro do emulador módulos de trabalho que fornecem:

  • apoiar desempenho misto,
  • aplicações de rastreamento,
  • A análise dos dados marcados,
  • análise de comunicação inter-componente,
  • máquina de colagem e o código Java-aplicação,
  • interação com hardware real.

Lista de requisitos para o sistema:

1. Suporte para carregamento de firmware a partir dos fabricantes de diversos dispositivos

Uma desvantagem significativa de todos os existentes Android ferramentas de análise de sistemas operacionais e suas aplicações é a incapacidade de iniciar o firmware dos fabricantes de dispositivos em emuladores disponíveis. Como mostrado na Sec. 2.2, firmware modificado a partir dos fabricantes de dispositivos contêm de 65 a 85% vulnerabilidades encontrados em todo o sistema. No momento não existem ferramentas para análise, o que permitiria para executar o firmware do fabricante. Todas as soluções existentes estão trabalhando em uma assembleia especial para a plataforma virtual GoldFish Android.

2. A possibilidade de peças individuais de execução do código de máquina em um dispositivo real

De acordo com o artigo de [ 34 , 61 ], existem métodos para a detecção de trabalhar no interior do emulador.Tipicamente, o desempenho é detectada no modo emulador QEMU tradução binário, visto que se baseia na maioria das caixas de areia. Os métodos baseiam-se no diferente comportamento de certas partes do código de máquina no emulador e em um dispositivo real. Desde a mudança no mecanismo de tradução binária é uma tarefa difícil, a execução das peças individuais de código nativo em um dispositivo real seria uma boa abordagem para combater estes detecção de métodos emulador.

3. Transmissão de dados de sensores no hardware real emulador de dispositivo

Tal como descrito em [ 34 , 61 ], existem métodos para a determinação do emulador, com base em dados obtidos a partir dos sensores de equipamentos, tais como um acelerómetro, um giroscópio, GPS, sensor de luz, a gravidade. Os valores de saída destes sensores são baseados na informação recolhida a partir do ambiente e, portanto, sua emulação realista é um desafio. A presença de tais sensores – a principal diferença entre smartphones e computadores de mesa. Um número crescente de sensores em smartphones oferece novas oportunidades para identificar dispositivos móveis.

4. A análise conjunta em nível de código de máquina Java-código e

A dificuldade para a análise de muitos sistemas Todos os apps aplicação é que o aplicativo contém os módulos no bytecode Dalvik, e os módulos no código de máquina. A partir da análise das soluções existentes todos os módulos suportar apenas o implementado em DroidScope [57] e CopperDroid [ 58 , 59 ]. Um sistema de ensaio ideal deve ser capaz de controlar e de dados de controlo transmite o código de utilizador e do sistema.Para código personalizado, sempre que possível, deve ser o de elevar o nível de desempenho ao Java-código, que é um desenvolvimento da linguagem de alto nível. Também é necessário proporcionar “colar” de dados e de controle de fluxo na transição do código nativo de Java e vice-versa.

5. Apoio intercomponent análise da interação

O artigo de CopperDroid [58] mostra a implementação das interacções intercomponent suporte análise dentro Android-aplicação ou entre diferentes aplicações. Isso é feito por interceptar dados que passam através componente central Binder, uma vez que toda a comunicação passa por ele. A abordagem implementada em CopperDroid, não vamos fazer modificações no código fonte do Android, o que torna a possibilidade de sua transferência para a nova versão do sistema operacional Android eo novo ambiente, iniciar aplicações arte com alterações mínimas.

6. Protecção de detecção heurística estática

Como mostrado em [ [57] , 61 ], a maioria das caixas de areia para análise pode ser detectada simplesmente por controlo da quantidade de IMEI, IMSI números ou EEPROM a montagem do dispositivo. Além disso, o emulador pode ser detectada verificando na tabela de roteamento de valores padrão. As soluções existentes para proteção contra detecção de heurística estática implementadas único projeto ApkAnalyzer [65] .

7. Alterações mínimas de firmware Android

Também é importante notar que muitas das decisões são baseadas no código de análise de instrumentação dinâmica de vários componentes do sistema operacional Android, em particular a máquina virtual Dalvik. Isso complica seu contínuo apoio, bem como a migração para as novas aplicações arte do ambiente executado.Muitos sandbox análise limitada código do componente Java, em seguida, à medida que mais e mais aplicações utilizar os componentes do código de máquina.

8. Suporte para análise de todo o sistema com fluxos de controle de rastreamento de dados marcado

É interessante notar que muitas das ferramentas de análise dinâmica análise de dados rotulados usando a ferramenta TaintDroid utilizado [56] . No artigo [60] têm demonstrado formas de sucesso para contornar esta ferramenta de análise. A razão para o sucesso desses ataques são os seguintes fatos: 1) TaintDroid apenas as faixas fluxos de dados e não controla o fluxo de controle, 2) TaintDroid monitores fluxos de dados apenas no nível da máquina virtual Dalvik e que passam através da interface JNI. maneiras possíveis para permitir desvantagens descritas [60] e dar uma orientação para futuras pesquisas.

9. símbolo Apoio e desempenho da execução parcial de valores específicos utilizando dados obtidos a partir de uma análise estática do código (execução concolic – um modelo misto)

No artigo [51] meio de ensaio descrito implementa esta abordagem. Este meio combina arte análise estática do gráfico de fluxo de controle do programa, o programa de execução símbolo e executar o programa com valores específicos. Abordagens o símbolo combinando execução técnicas e executar o programa com os valores específicos descritos em [ 52 , 53 , 54 , 55 ]. O objetivo deste método é monitorar os caminhos de execução que levam a programar seções que compõem o código “interessante”. Por código de “interessante” para entender este código, cuja implementação depende de quaisquer eventos externos tenham ocorrido ou as configurações do ambiente do sistema. Por exemplo, o código de classe em Android, carregável dinamicamente via componente DexClassLoader ou as chamadas métodos “máquina” através da interface JNI.

conclusão

existem problemas de segurança móvel OS Android em todos os níveis de plataforma, e exigem uma abordagem mais abrangente do que as medidas de proteção que podem ser observados hoje. No desenvolvimento da classificação de vulnerabilidades descritas neste artigo, notou-se que um dos principais problemas – significativa a fragmentação do mercado, o que não permite a organizar a entrega atempada de atualizações de segurança para todos os dispositivos, como implementado no iOS.

Neste meios actualmente existentes de proteção, incluindo antivírus e caixa de areia, tem muitos inconvenientes e não pode proteger totalmente o usuário. Enquanto criar uma caixa de areia para a análise de todo o sistema do sistema operacional Android, sem as desvantagens descritas pode, se guiados por uma lista de créditos apresentada neste artigo.

Apesar deste quadro pessimista, recentemente tem havido algum movimento positivo no sentido de melhorar a segurança do Android. Em particular, o Google lançou um programa de liberação de atualizações de segurança: eles saem a cada mês, e alguns vendedores ainda adicioná-los ao seu firmware (dispositivo suportado pela Google, obter as atualizações em primeiro lugar). Além disso, os usuários podem configurar manualmente o dispositivo para a versão CyanogenMod Android do OS (agora LineageOS), que suporta essas atualizações de segurança. Além disso, o usuário pode reduzir os riscos, se limita a um conjunto de aplicativos populares só da loja oficial Google Play. Vulnerabilidades como RCE (a execução de código remoto) estão se tornando cada vez mais raro, por isso a entrega de aplicativos maliciosos no telefone muitas vezes ocorre através de sites de phishing, lojas de aplicativos não oficiais ou através de engenharia social. O usuário médio do Android OS, observando certas precauções de segurança pode ser relaxada sobre o seu smartphone.

Autor: Michael Romaneev (@ melão )

 

Links e materiais utilizados:

 

  1. statista.com/statistics/281106/number-of-android-app-downloads-from-google-play
  2. Tan DJJ et al. Protegendo Android: A Survey, Taxonomia e Desafios // Surveys ACM Computing (CSUR).2015. Vol. 47. 4. P. número 58.
  3. file.gdatasoftware.com/web/en/documents/whitepaper/G_DATA_Mobile_Malware_Report_H1_2016_EN.pdf
  4. developer.android.com/ndk/guides/stable_apis.html
  5. Os internos VM // as Dalvik sites.google.com/site/io/dalvik-vm-internals
  6. securityweek.com/overwhelming-majority-android-devices-dont-have-latest-security-patches
  7. Google I / O 2014 – o tempo de execução de à ART // youtube.com/watch?v=EBlTzQsUoOw
  8. media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Huber-Rasthofer-Smartphone-Antivirus-And-Security-Applications-Under-Fire.pdf
  9. developer.android.com/guide/components/services.html
  10. source.android.com/devices/tech/security/selinux
  11. developer.android.com/preview/features/runtime-permissions.html
  12. Enck W., Ongtang M., McDaniel P. Compreender android segurança // IEEE segurança e privacidade.Número 1. P. 2009. 50-57.
  13. Shabtai A., Mimran D., Elovici Y. Avaliação de soluções de segurança para sistemas Android // arXiv preprint arXiv: 1502,04870. – 2015.
  14. Hei X., Du X., Lin S. duas vulnerabilidades no sistema operacional Android do kernel // Comunicações (ICC), 2013 IEEE Conferência Internacional sobre. IEEE, 2013. P. 6123-6127.
  15. forum.xda-developers.com/showthread.php?t=2048511
  16. Zhou X. et al. Identidade, localização, doença e mais: Deduzir os seus segredos de recursos públicos android // Proceedings de 2013 conferência de ACM SIGSAC on Computer & Communications Security.ACM, 2013. P. 1017-1028.
  17. Wu L. et al. O impacto das personalizações de fornecedores em segurança android // Proceedings de 2013 conferência de ACM SIGSAC on Computer & Communications Security. ACM, 2013. P. 623-634.
  18. en.wikipedia.org/wiki/Stagefright_(bug)
  19. Zhou X. et al. O perigo de fragmentação: riscos de segurança em personalizações de driver de dispositivo android // Segurança e Privacidade (SP) de 2014 IEEE Symposium on. IEEE, 2014. P. 409-423.
  20. Sun M., Tan G. NativeGuard: Protegendo aplicativos do Android a partir de terceiros bibliotecas nativas // Anais da Conferência 2014 ACM sobre Segurança e privacidade em redes sem fio e móveis. ACM, 2014. P. 165-176.
  21. Octeau D. et al. mapeamento eficaz entre componentes de comunicação no android com EPICC: Um passo essencial para análise de segurança holística // USENIX Segurança 2013.
  22. Chin E. et al. Analisando a comunicação inter-aplicação em // Android Proceedings da conferência internacional 9ª em sistemas móveis, aplicações e serviços. ACM, 2011.
  23. Feltro AP et al. Permissão Re-delegação: ataques e defesas // USENIX Symposium Segurança. 2011.
  24. Bugiel S. et al. Xmandroid: Uma nova evolução android para mitigar ataques de escalação de privilégios // Technische Universität Darmstadt, Relatório Técnico TR-2011-04.
  25. Bugiel S. et al. Rumo Domar Ataques Privilege escalada no Android // NDSS. De 2012.
  26. cvedetails.com/cve/CVE-2011-1717
  27. Fahl S. et al. Por Eva e Mallory amo Android: Uma análise da SSL Android (in) segurança // Anais da Conferência de 2012 ACM no computador e comunicações de segurança. ACM, 2012. P. 50-61.
  28. owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks
  29. Lu L. et al. Chex: estaticamente habilitação aplicativos Android para vulnerabilidades seqüestro componentes // Anais da Conferência de 2012 ACM no computador e comunicações de segurança. ACM, 2012. P. 229-240.
  30. kb.cert.org/vuls/id/924951
  31. // 2015-3842-o CVE cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3842
  32. Zhou Y. et al. Ei, você, saia do meu mercado: Detecção malicioso Apps no oficial e alternativa Markets Android // NDSS. De 2012.
  33. android Nolan G. Decompiling. – Apress de 2012.
  34. Petsas T. et al. Raiva contra a máquina virtual: impedindo análise dinâmica do android de malware // Proceedings da Sétima Oficina Europeia de Segurança do Sistema. ACM, 2014. P. 5.
  35. Segurança Underpinnings // Todos os apps youtube.com/watch?v=NS46492qyJ8
  36. coresecurity.com/advisories/android-wifi-direct-denial-service
  37. securityaffairs.co/wordpress/37667/hacking/nfc-attack-credit-card.html
  38. zerodayinitiative.com/advisories/ZDI-15-092/
  39. securityfocus.com/archive/1/535980/30/150/threaded
  40. Neuner S. et al. Digite sandbox: comparação sandbox Android // arXiv preprint arXiv: 1410,7749. 2014.
  41. Hoffmann J. De Mobile para Segurança: Para Smartphones seguros: dis. – 2014.
  42. Faruki P. et al. Segurança Android: A Survey of Issues, Malware Penetração e defesas.
  43. ibotpeaches.github.io/Apktool
  44. github.com/JesusFreke/smali
  45. dedexer.sourceforge.net
  46. radare.org/r
  47. github.com/androguard/androguard
  48. dexprotector.com
  49. guardsquare.com/dexguard
  50. PANDORA aplica ofuscação não-determinístico aleatoriamente para Android, proteção Schulz Código P. no android // Insititute de Ciência da Computação, Rheinische Friedrich-Wilhelms-Universität Bonn, Alemanha. De 2012.
  51. Schütte J., Fedler R., Titze D. Condroid: alvejado análise dinâmica de aplicativos Android // em revisão. 2014.
  52. Sen K. DART: Dirigido Automated de exames aleatórios // Haifa Conferência de Verificação. 2009. Vol. 6405. P. 4.
  53. Sen K., D. Marinov, Agha G. bonitos: um motor de testes de unidade concolic para C. ACM, 2005. Vol. Número 30. 5. P. 263-272.
  54. Godefroid P. de exames aleatórios para a segurança: blackbox vs. whitebox fuzzing // Anais do 2º Workshop Internacional sobre testes aleatórios: co-localizados com 22 IEEE / ACM Conferência Internacional sobre Automated Software Engineering (ASE 2007). ACM, 2007. P. 1.
  55. Jayaraman K. et al. jFuzz: A Concolic Whitebox Fuzzer para Java // NASA Métodos Formais. 2009. P. 121-125.
  56. Enck W. et al. TaintDroid: um sistema de rastreamento de informações de fluxo para monitoramento em tempo real de privacidade em smartphones // Transações ACM em Sistemas de Computação (Tocs). 2014. Vol. Número P. 32. 2. 5.
  57. Yan LK, Yin H. DroidScope: Perfeitamente Reconstruir o sistema operacional e Dalvik Visualizações semânticas para Dynamic Android Malware Análise // USENIX Symposium Segurança. 2012. P. 569-584.
  58. Tam K. et al. CopperDroid: Reconstrução automática do Android Malware Comportamentos // Proc. do Simpósio de Rede e Distribuídos Segurança do sistema (NDSS). 2015.
  59. copperdroid.isg.rhul.ac.uk/copperdroid
  60. Sarwar G. et al. Sobre a eficácia da Análise Taint dinâmico para proteger contra vazamentos de informações privadas em dispositivos baseados no Android // SECRYPT. 2013. P. 461-468.
  61. Jing Y. et al. Morpheus: geração automática de heurística para detectar emuladores Android // Anais da 30ª Conferência Anual aplicações de segurança informática. ACM, 2014. P. 216-225.
  62. googleprojectzero.blogspot.ru/2016/12/bitunmap-attacking-android-ashmem.html
  63. bbqand0days.com/Pork-Explosion-Unleashed
  64. powerofcommunity.net/poc2016/x82.pdf
  65. apk-analyzer.net
  66. http://www.phdays.ru/program/fast-track/45984
Anúncios