… com a chegada do Android 4.4.
Com a chegada do Android 4.4 KitKat muitas novidades chegaram. Nova interface, novas funcionalidades, simplificação para os programadores e também a camada de segurança foi bem reforçada.
Já tínhamos falado há uns tempos que o SELinux vinha para dificultar quem quisesse fazer ROOT ou que algum malware se tentasse espalhar pelo sistema. Mas a Google não achou este mecanismo suficiente e incluiu um novo e poderoso sistema de segurança. 
O SELinux foi apresentado no Android 4.3 JellyBean de forma a reforçar a segurança do sistema, controlando as acções das aplicações que instalamos. Com a chegada do Android 4.4, a Google introduziu uma nova funcionalidade chamada de DM-Verity (device-mapper-verity).
O que é e como funciona o DM-Verity?
Trata-se de uma funcionalidade a nível do kernel que permite uma verificação transparente da integridade do sistema de ficheiros dos equipamentos. O DM-Verity ajuda a prevenir a modificação de ficheiros e da instalação de rootkits persistentes (Ex.: busybox) que podem comprometer a segurança do equipamento. Desta forma, sempre que for detectada uma alteração, este mecanismo deverá restaurar o sistema de ficheiros para o original, o que quer dizer que se fizerem ROOT, ficarão logo a seguir sem ele.
Esta funcionalidade pode ser aproveitada pelos fabricantes onde podem ser incluídos registos de tentativas de root, do mesmo género do Samsung Knox.
Cada bloco de armazenamento do dispositivo (um bloco é simplesmente uma unidade de endereço de armazenamento, normalmente de 4KB de tamanho) é verificado pelo dm-verity, aplicando um hash SHA-256. Ao longo das páginas, é gerada uma árvore de hashs e basta que o que esteja no topo da árvore (conhecido como o hash raiz) ser confiável para que todo o sistema de arquivos o ser também. Se qualquer um dos blocos for modificado, automaticamente o hash raiz será também alterado, o que irá quebrar a sequência e assim accionar o dm-verity.
Estrutura dos blocos de armazenamento e da árvore de hashs
A partição boot contém uma chave pública. Será aqui que, possivelmente, os OEMs irão verificar esta chave através do bootloader ou a partir de alguma funcionalidade do CPU. Esta chave pública é usada para assegurar a assinatura do hash no sistema de ficheiros e verificar se é válida e/ou que não foi modificada.
De forma a reduzir o tempo necessário para verificar o sistema de ficheiros, o DM-Verity foi implementado de forma a que os blocos sejam apenas verificados quando são utilizados e são verificados em paralelo com a operação de leitura normal (para eliminar essencialmente qualquer latência no acesso ao armazenamento). Se forem detectadas alterações na partição do sistema, é gerado um erro de leitura.
Todas as aplicações que necessitarem de acesso total ao armazenamento verão essa funcionalidade rejeitada, a não ser que esta funcionalidade permita escolher que tipos de acesso o programador quer dar à sua aplicação, se leitura e escrita crítica (acesso a todos os ficheiros incluindo aos de sistema) ou se leitura e escrita normal (leitura do armazenamento interno e externo). Sendo assim, aplicações que necessitem de ROOT e que façam leitura de armazenamento, são consideradas críticas, logo não irão funcionar devidamente.
Embora nada seja impossível, o enraizamento destes mecanismos no sistema, desbloquear bootloads, ou seja, onde sejam necessários exploits para desbloquear o bootloader ou mexer no kernel, pode levar a que seja muito mais difícil fazê-lo nesta versão do que nas versões anteriores do Android. Esta funcionalidade é semelhante ao boot seguro UEFI ou ao que foi implementado nos computadores com o Chrome OS.
No entanto, para quem comprar equipamentos sem bootloader bloqueado, esta funcionalidade pode ser desactivada através da alteração do kernel ou simplesmente o novo kernel utilizar chaves próprias para autenticar os hashs. Para os utilizadores que optam por comprar equipamentos com bootloader bloqueado, por exemplos os Sony Xperia, é melhor ter muito cuidado.
Não é de todo improvável que os OEMs implementem sistemas de controlo de alteração de hashs e assim verem a garantia do equipamento sem efeito. Se quer comprar um equipamento e depois querer alterar o sistema à sua maneira, é recomendável a compra de equipamentos sem bootloader bloqueado ou que possam alterar facilmente o kernel para desactivar o dm-verity.
O dm-verity está incluído no utilitário Veritysetup que ,quem utiliza o Linux, deve certamente conhecer bem. Este utilitário tem como principal função e explicada em cima, que se resume a configurar a verificação do sistema de ficheiros de armazenamento.
Para os que não sabem, o Android tem incluído os dois principais utilitários do projecto LUKS (Linux Unified Key Setup), o Veritysetup (dm-verity) e o Cryptsetup (dm-crypt), que é usado para encriptar o dispositivo. Este último já está incluído no Android desde há bastante tempo, já não é de certeza uma novidade.
O LUKS foi criado por Clemens Fruhwirth e tornou-se em, nada mais nem nada menos, do que o conjunto de especificações padrão de criptografia de discos rígidos no Linux.
Esquema de como o DM-Crypt funciona.
Nota: Em vez do EXT 2, o Android usa EXT 3.
Resumidamente, o DM-Verity será uma enorme dor de cabeça para os utilizadores que pretendam alterar o sistema à sua maneira, bem como para os programadores.
Apesar de actualmente já conseguirem fazer root em alguns modelos do Galaxy Note 3 sem que o Samsung Knox seja activado, este mecanismo parece bem mais poderoso e bem mais difícil de ultrapassar.
Podem consultar todas as informações sobre o dm-verity, aqui.
Para além do dm-verity, esta nova versão do Android trouxe mais reforços na segurança.
Modo Execução (Enforcing) do SELinux
O SELinux passou de modo permissivo (que simplesmente registava falhas), para o modo Execução (Enforcing).
O SELinux, que foi introduzido no Android 4.3, é um sistema de controlo de acesso que funciona sobre o kernel Linux, de forma a ajudar o utilizador a ter controlo sobre as permissões das aplicações.
Com este modo Enforcing, as permissões das aplicações serão devidamente controladas e bloqueadas se necessário.
Suporte para Elliptic Curve Digital Signature Algorithm (ECDSA) nas chaves de assinatura
Agora o sistema que fornece chaves de encriptação no Android já tem suporte para Eliptic Curve Cryptography. O ECC recebeu durante algum tempo maus comentários, no entanto não foram comprovados.
O ECC é a forma mais viável de fornecimento de chaves públicas para criptografia e pode ser visto como uma boa alternativa ao RSA e a outros algoritmos. Como a criptografia assimétrica não vai ter suporte para computação quântica, o Android 4.4 trouxe outra alternativa para os programadores.
Para armazenamento de dados a longo prazo, a criptografia simétrica continua a ser a melhor escolha.
Avisos para falsos SSL Certificate Authority
Vários sectores IT adoptam software de monitorização SSL, que adiciona uma Autoridade Certificadora (Certificate Authority, CA) ao computador ou ao browser, de forma a evitar não só que as sessões HTTPS sejam atacadas ou interceptadas mas também para questões de monitorização.
Isto já é possível no Android desde há muito, onde é possível adicionar explicitamente uma chave adicional CA, permitido que o gateway – que pode ser por exemplo uma empresa – se faça passar por qualquer site/destino.
No Android 4.4 os utilizadores são notificados sempre que é adicionado uma chave CA, evitando assim que a chave seja adicionada por algum exploit sem que o utilizador se aperceba.
Detecção automatizada de Buffer Overflow
Agora o compilador do Android compila o código com FORTIFY_SOURCE nível 2 e garante que todo o código C seja compilado com esta protecção bem como se for compilado com clang.
O FORTIFY_SOURCE é uma funcionalidade de segurança do compilador que tenta identificar algumas formas de Buffer Overflow (que pode ser explorado por software malicioso ou por utilizadores que pretendam ganhar acesso a execução de código arbitrário num dispositivo).
No entanto esta funcionalidade não tem capacidade de lidar com todas as possibilidades de Buffer Overflow, mas sempre é melhor ter esta funcionalidade do que não ter, pelo menos protege das formas mais conhecidas para executar este ataque.
Como sempre, atrás de grandes implementações de segurança, vêm também alguns problemas de segurança e desta vez não foi excepção.
Em Julho falámos aqui sobre como corrigir uma das maiores vulnerabilidades do Android que já vinha desde praticamente o seu aparecimento, a vulnerabilidade MasterKey.
A Google lançou um patch a corrigir duas vulnerabilidades relacionadas com o MasterKey e lançou o Android 4.3 também já corrigido. Ainda em Julho, uma empresa chinesa conhecida como Android Security Squad, descobriu outra variante desta vulnerabilidade.
Com o lançamento do Android 4.4 KitKat, a Google prometeu que esta vulnerabilidade estava totalmente corrigida, mas, infelizmente, nada é totalmente seguro.
O especialista em segurança Jay Freeman, também conhecido como Saurik na Cydia Software, descobriu uma nova vulnerabilidade relacionada com a verificação da assinatura das aplicações (MasterKey) e para demonstrar o que é possível fazer, desenvolveu, como exemplo, um exploit em Python. 
Now, last night, the source code for Android 4.4 was released to AOSP, which included a patch for yet another bug, #9950697, in the signature verification of Android application packages. This bug is somewhat weaker than the previous ones, but is still sufficient to support the general exploit techniques I have described. In this article, I describe this third bug and show how it can be used, providing both a proof-of-concept implementation in Python and a new version of Impactor that adds support for this signature bug.
Esta nova vulnerabilidade é semelhante à descoberta em Julho pela Android Security Squad, onde cada aplicação é assinada com a chave de encriptação privada dos seus criadores. O gestor de aplicações do Android determina que as aplicações podem partilhar informações, ou que permissões são capazes de as obter através da análise aos certificados usados para verificar a assinatura do autor.
Even the system software itself is signed by the manufacturer of the device; applications signed by that same key are thereby able to do anything that the system software can. Normally, this is only possible if you are the manufacturer; however, using bug #8219321, anyone could steal those signatures for their own. A key concern this raises is that applications in the wild might be signed with the system keys of your device; while you think you are just installing a harmless game, that application would look to the package manager as if it came from the manufacturer, giving it elevated and dangerous system permissions. The vulnerability involves discrepancies in how Android applications are cryptographically verified & installed, allowing for APK code modification without breaking the cryptographic signature; that in turn is a simple step away from system access & control.
Até ao momento ainda não se conhece que esta vulnerabilidade esteja a ser explorada. Uma vez que ainda nenhum equipamento recebeu o Android 4.4 oficialmente para além do Nexus 5, é possível que, com esta revelação, a Google esteja já a tratar de um patch bem como a CyanogenMod na CM11.
Para que a aplicação Cydia Impactor não seja “atacada”, Saurik já corrigiu a sua aplicação contra esta vulnerabilidade.
Enquanto não for lançado um patch a corrigir esta falha, é extremamente recomendado que só instalem aplicações a partir da Play Store e de programadores conhecidos e fidedignos.
Pode consultar todas as informações desta descoberta no site oficial do Jay Freeman (Saurik).