RSSAtaques bem-sucedidos a partições criptografadas, usando leitura das chaves na RAM após desligar e religar o micro
Você imaginaria algo assim? Vários sites de notícias divulgaram nesta quinta-feira relatos de ataques bem-sucedidos a discos criptografados, usando uma técnica curiosa: desligar o micro com a partição montada, depois tornar a ligá-lo dando boot por outro sistema operacional com as ferramentas apropriadas para procurar as chaves que estavam armazenadas.
Segundo o texto, as memórias DRAM correntes costumam guardar por tempo limitado o seu conteúdo, de uma forma que pode ser acessada por software mesmo alguns minutos após um desligamento, desde que ela não seja reescrita - e como a maioria das BIOS não “zeram” a memória, um sistema operacional pequeno e capaz de gerar um dump completo da memória tem razoável chance de dar ao atacante a possibilidade de encontrar as chaves e qualquer outra informação que estivesse na RAM no momento do desligamento anterior.
Os pesquisadores testaram a técnica contra sistemas de criptografia de disco adotados pelo Vista, Mac OS X e Linux, com sucesso. O que é mais interessante: nem mesmo as plataformas de “Trusted Computing”, com seu hardware especial de suporte a criptografia (geralmente usado em esquemas de DRM) impediram os ataques.
Saiba mais (lwn.net).
![[FSF Associate Member]](http://trilux.org/img/fsf-member.png){kind=small}
Uma vez me disseram: “Acesso físico à máquina É falha de segurança.”
E o pior é que é uma falha que firewall ou antivírus algum consegue acabar.
É como a velha história da faxineira que derrubou um servidor de um provedor deixando cair detergente na CPU - ou mais ou menos assim ;-)
Mas que é uma bela de uma descoberta, isto é!
Muito interessante, não sabia sobre essa forma de ataque nem que os dados permanecessem na RAM por tanto tempo assim. Seguindo links na fonte e lendo os comentários, tem muita coisa interessante também sobre o assunto.
tenchi,
Porque encriptar um HD de um servidor? Só o deixaria lento. Se o invasor conseguir acesso remoto ele não vai nem perceber a criptografia porque já vai estar acessando um disco “mountado”. A aplicação da criptografia em disco é mais comum para notebook.
Na verdade uma política de segurança adequada deve prever se há necessidade ou não de se criptografar a memória RAM também, recurso permitido no GNU/Linux. Alguns servidores às vezes não necessitam de tanto desempenho e criptografar disco e memória RAM é uma alternativa viável. Sem contar que usar mídias alternartivas para iniciar/gerenciar o boot e só iniciar o sistema após comparação de chaves e no boot e nas partições, para saber se “não tentaram iniciar o sistema” de alguma outra forma é outro recurso para detecção de quebra de segurança.
Já havia visto notícia semelhante há bastante tempo atrás, usando esse método para recuperar senhas de sistema - nesse caso, é para criptografia de dados no disco.
É para isso que serve criptografia completa de hardware para casos extremos, mas no geral não é um problema já que os computadores no geral foram feitos para serem seguros contra ataques remotos, e fáceis localmente para os administradores terem controle total em casos de problema.
[...] poderia imaginar, mas esta notícia publicada do http://br-linux.org me abriu os [...]
Cada vez que sai uma notícia dessas de quebra de segurança, fico cada vez mais com medo de usar computador eheh. :P
“das BIOS” não existe. É “dos BIOS”.
BIOS = macho. Sistema Básico de Entrada/Saída.
interessante. tenchi disse tudo…
uma maneira super simples de corrigir isto é fazer uma atualização da BIOS fazendo com que ela zere todos o conteudo da ram antes de liberar pro SO.
Que vergonha que eu teria no lugar dos desenvolvedores que implementaram esses sistemas de criptografia. Desde o Nintendinho (NES, e depois tambem no Super Nintendo) existe esse comportamento de memoria em um Cold Boot e zerar memoria ou redefinir derivacao de dados relevantes na reinicializacao do software era indicacao da Nintendo.
Lembro ate de uma historia pra ilustrar isso, quando foi lancado o Battletoads, devido a dificuldade do jogo era previsivel que tentassem modificar o comportamento do game, e entao criaram uma chave de seguranca pra evitar a alteracao desses dados em memoria. Porem, a ideia da chave foi ma implementada e logo o Gamegenie (wrapper pra mod de games direto no console) conseguia modificar esses comportamentos e por exemplo colocar vida infinita pros sapos, permitir fases mais dificiceis como as do fundo do mar ficar invenciveis e a corrido dos jet ski flutuante ser em camera lenta e com mapa.
Ai a RARE games soltou uma segunda leva do mesmo jogo que fazia derivacao de funcoes pra codificar a area de memoria onde essas informacoes ficam. A derivacao por chave garantia que a cada nova inicializacao uma mesma chave geraria uma segunda chave com base em uma terceira chave aleatoria. Ou seja, uma constante e uma aleatoriedade geraria uma outra chave, imprevisivel. O Game Genie passou a nao funcionar mais nos cartuchos Battletoads mais novos, depois disso, e um Cold Boot permitia acesso a chave - a constante - e tambem a chave aleatoria bem como a chave resultante das duas. Porem, na proxima inicializacao do game a chave aleatoria seria outra, portanto resultando em uma terceira chave - a efetiva - tambem imprevisivel, ainda que a chave constante fosse sempre a mesma.
Essa historinha ‘e so’ pra ilustrar que a seguranca esta diretamente relacionada a capacidade, o prazer e o empenho de quem faz um sistema.
Agora voltando ao Topico, essa abordagem no Battle toads ‘e equivalente a especificada na Sessao 5 da RFC 2898 (Funcoes de Derivacao de Chave).
No FreeBSD o GELI criptografa os dados dessa maneira, permitindo que o usuario entre com uma passphrase ou um token, ou que ainda leia a chave de um arquivo. Seja como for essa nao e a chave de criptografia utilizada nas operacoes, a chave utilizada ‘e oriunda de um processo que obtem 2 outras chaves, uma com um algoritimo proprio e aleatoriedade baseada no /dev/random e outra com um algoritimo de derivacao indicado na RFC 2898. Portanto um padrao de fato (RFC) e algo exclusivo da implementacao, 2 chaves imprevisiveis, uma constante, resultando em uma quarta chave que ‘e de fato que vai codificar o acesso aos dados. Ainda que todas as 4 chaves sejam copiadas da memoria so 1 eh constante - a do input do usuario - e as outras nunca mais serao utilizadas. A nova inicializacao do device sera com chaves totalmente distintas.
Mas no FreeBSD existe outra implementacao, o GBDE. Dependendo da forma como o GBDE Device ‘e criado, alem de acontecer um processo similar ao do GELI, a chave de fato (aque efetivamente realiza a criptografia) alem de ser gerada de uma combinacao de chave constante com chaves derivadas, ainda requer que periodicamente (por padrao a cada 300 segundos) a chave de fato seja regerada.
Ou seja, escolha sua implementacao FreeBSD, seja qual for nao ‘e sucetivel a essa falha. Agora so me surpreende (negativamente) no Mac OS X nao ter implementacoes baseadas no GELI ou GBDE.
Ah, detalhe, no caso do GELI se disponivel, a chave e’ derivada do hardware de crypto (HIFN da Soekris por exemplo).
O interessante ‘e que o artigo so menciona as implementacoes vulneraveis. Nao disserta sobre as nao vulneraveis e os motivos.
Cabelo, isso nao seria uma solucao, seria um paleativo. O problema esta em evitar que as rotinas de termino acontecam nao em evitar rotinas de inicializacao mais efetivas.
Por exemplo, imaginemos que o recem roubado laptop da Petrobras contendo informacoes privilegiadas sobre a camada de pre-sal na bacia de Santos tenha esses dados em uma particao criptografada, e, apos um Cold Boot a memoria seja fisicamente removida e colocada em um outro device que nao tenha essa sua BIOS modificada, ou melhor que sequer tenha uma BIOS e a BIOS seja um linux do tipo busybox que controla e faz o memory dump necessario.
Alem do que como eh que se zera qualquer tipo de memoria? Uma coisa eh free(); outra coisa ‘e remover os dados de uma memoria. Impossivel. Teria que ter toda a regiao de memoria regravada. Ja pensou se uma BIOS fizesse isso? Se o usuario ja da ESC pq se irrita com a contagem de memoria, imagina um processo parecido com o mais basico do “memtest.org” pra garantir que a memoria esteja toda repleta de dados inuteis em cada POST?
Enfim, nao acho que a solucao seja por ai. A falha eh na implementacao de software, e eh a implementacao que deve ser melhorada.
Mesmo porque Cold Reboot ‘e so o foco do Research publicado. Nos sabemos que fazer dump completo da memoria nao eh um problema que requer um Cold Reboot e um sistema especial como o paper descreve.
Se alguma pessoa, quem quer q seja, sentar na frente do meu laptop agora, e eu esquecer de dar um lock, ou deslogar, ou ele simplesmente conhecer a senha de root conseguira fazer um memory dump.
Sobre a afirmacao de criptografia em servidor, o fato do device estar montado nao eh necessariamente sinonimo de que os dados possam ser irrestritamente acessados, nem mesmo pelo root. Essa duvida e suspeita e’ muito explorada fora do Pais, onde, devido ao baixo custo de banda cada vez mais larga, servicos de Remote Backup sao cada vez mais comuns.
Entao existem prestadores e outros prestadores desse servico, e a seguranca dos dados durante o processo de backup ‘e um fator muito discutido. Uma busquinha no google por online backup apresenta um milhao de empresas que oferecem o servico.
Em ambiente Trusted e’ possivel garantir que apenas um, e tao somente um processo, seja este do root ou nao, acesse uma determinada particao de disco. E se esse mesmo processo desmontar essa particao quando terminar o trabalho? Pois bem, esse eh o ambiente ideal.
No Brasil a unica empresa que eu sei que oferece servico desse tipo eh a FBSD Brasil, eles ate colocam uma explicacao simplista de como isso acontece aqui:
http://www.freebsdbrasil.com.br/home.php?area=18&conteudo=41&sub=75
Na verdade nem eh tao simplista, um usuario final nao entenderia nada.
Mas entao existe sim, a possibilidade de ter um device criptografado montado e que ainda assim garanta a seguranca do acesso a esses dados, restringindo ate mesmo o root. Logico que se o root puder trocar de kernel ou carregar modulos, a coisa muda de figura. Mas num ambiente seguro assumimos que isso tambem seja dificultado. No FreeBSD o modulo MAC BSD Partition e o bsd_extended permitem esse nivel de controle. No Mac OS X Leopard tambem ha esse tipo de controle. Igualmente ha no Solaris e no HP-UX. Portanto sequer eh algo novo ou exclusive de sistema X, Y ou Z.
Isso me lembra o que eu li uma vez, anunciando que haviam quebrado a segurança da máquina virtual Java, usando uma lâmpada para aquecer a memória e corromper os dados aleatoriamente (só as vezes funcionava, na maioria das vezes só travava a máquina). :P
silveira, a jvm foi apenas alvo da demonstração, pois o objetivo era mostrar que a técnica funcionava pra qualquer plataforma dita segura. Virou uma lenda urbana, ou quem ficou rico fazendo isso está mto quieto.