RSA Security Invadida, Segredos Técnicos Vazaram

[deadcow]

A respeitadíssima empresa RSA Security chocou a comunidade de segurança da informação há algumas horas com a publicação de uma Carta Aberta aos Clientes RSA informando terem sido vítimas de um "ataque persistente e extreamente sofisticado" e que estariam trabalhando ativamente com seus clientes para minimizar o impacto.

Na comunidade de segurança de informação, a RSA goza de uma reputação muito particular, por ter sido fundada por alguns dos acadêmicos pioneiros da área de criptografia, inventores do criptossistema de chaves públicas de mesmo nome e que hoje é usado em milhares de aplicações e cenários diferentes – a esmagadora deles totalmente invisível para o público leigo.

O grande público conhece a RSA pelos tokens de senhas descartáveis SecurID, adotados por vários bancos brasileiros, que os distribuiem a seus clientes para usarem como meio de identificação para movimentar suas contas via Internet. O anúncio surpreende um pouco ao mencionar que houve algum tipo de vazamento de informações relacionado a esse sistema, embora seja rápido em dizer que "estão confiantes que as informações vazadas não viabilizam um ataque direto ao SecurID".

Naturalmente, o anúncio em si é meio vago – não diz exatamente a extensão dos problemas e contém zero detalhes técnicos. Mas isso é compreensível: provavelmente a direção da empresa deve estar enfrentando o clássico dilema entre dizer demais e piorar o potencial impacto ou dizer de menos e ser posteriormente acusada de encobrimento. Nesse tipo de situação, a onda de especulações é inevitável.

Os tokens de autenticação por senhas descartáveis funcionam gerando uma senha diferente a cada minuto (no caso do SecurID da RSA; outros modelos de outros fabicantes requerem que você pressione um botão). As senhas são geradas baseadas na data e hora atual e em uma fórmula matemática (relativamente complicada para um ser humano mas trivial para um computador). Assim, o site do banco é capaz de saber a todo momento qual o número que está aparecendo na tela do seu token. Todavia, se você (ou um atacante) anotar a sequência de números exibida, ela lhe parecerá totalmente aleatória, tornando-lhe incapaz de prever os próximos números.

Essa tecnologia nem é novidade; ela foi originalmente desenvolvida nos anos 80, mas só se popularizou de verdade aqui no Brasil recentemente, digmaos, de uns cinco anos pra cá.

Os tokens de autenticação são muito melhores do que senhas estáticas e vêm contribuindo com a diminuição de vários tipos de fraudes. Certamente não são perfeitos – são um pouco inconvenientes, porque você lembrar de trazê-los consigo, especialmente se você tem várias contas em vários bancos. Diretores financeiros e o pessoal administrativo de várias empresas podem ser vistos carregando chaveiros cheios deles. Além disso, não resolvem todos os problemas de segurança; eles foram projetados para resistir a certos tipos de ataques, mas não a outros.

Por exemplo: os tokens SecurID da RSA, por não terem botões, não são vulneráveis a um certo tipo de ataque de negação de serviço que eu descrevi anteriormente. E, como eu disse, são explicitamente projetados para que seja incrivelmente difícil de alguém ser capaz de prever os próximos números. Também são projetados de forma que nada útil possa ser aprendido caso o dispositivo seja desmontado e analisado. Mesmo sabendo a fórmula matemática exata, ela depende de parâmetros que variam de usuário para usuário. Assim, no improvável evento de você conseguir prever a sequência de senhas gerada por um dispositivo, isso não lhe ajudará a prever as sequências geradas pelos dispositivos dos demais usuários.

Apesar disso, esses sistemas têm alguns "tendões de Aquiles". Um deles é o processo de inicialização do dispositivo (chamado de "provisionamento", no jargão da área). Para que um site passe a ser capaz saber quais as senhas estão sendo exibidas na tela de um token específico, o número de série do dispositivo precisa ser cadastrado. Esse número de série é usado em um processo complicado para se obter a chamada "semente" (jargão da área) ou "chave secreta" (jargão acadêmico) que permite calcular a sequência de números. Esse processo de cadastro é melindroso e propenso a algumas vulnerabilidades, especialmente quando usado em grande escala.

Se eu tivesse de especular qual segredo da RSA vazou, eu chutaria que tem algo a ver com esse processo. Minha pista é a estrutura do texto do anúncio – o CEO da RSA diz que (tradução minha) "essa informação potencialmente pode ser usada como parte de um ataque amplo para reduzir a eficácia de implementações atuais de autenticação baseada em dois fatores". (O lance dos "dois fatores" é um jargão da área, pois os tokens e sua senhas descartáveis são o "segundo fator" , sendo normalmente combinados com a senha estática comum, que seria o "primeiro fator"). Esse é mais ou menos o impacto que seria de se esperar caso se descobrisse alguma vulnerabilidade no processo de provisionamento (cadastro inicial) dos tokens. Se nada fose feito, futuros tokens poderiam ser comprometidos, ao passo que os anteriores continuariam sem problemas. Ao meu ver, isso se encaixa razoavelmente bem na parte do texto onde se diz que a informação vazada não viabiliza um ataque direto.

Há um outro tipo de ataque clássico a sistemas que usam geradores de senhas descartáveis: o chamado ataque "man-in-the-middle". Para entendê-lo, imagine que você está com seu token consigo e precisa fazer uma transação bancária que não pode esperar, mas está em um lugar sem acesso à Internet. Você então liga, via telefone convencional, para uma pessoa de sua confiança e você passa a senha que está aparecendo no visor do seu token para ela, e ela faz a transação por você. Essa pessoa é o tal "man-in-the-middle" ('homem-no-meio', ao pé da letra, ou 'intermediário', idiomaticamente). Isso não é considerado um ataque porque você envolveu o intermediário por que quis.

Considere, porém, um cenário ligeiramente diferente: um atacante monta um site visualmente idêntico ao do seu banco e o induz a acessá-lo (digamos, mandando-lhe um email falso dizendo que você deve se recadastrar). Você cai na esparrela, acessa o site impostor e você digita a senha descartável que aparece no visor do seu token. O atacante recebe essa senha e acessa sua conta bancária por você, tal como no intermediário consentido do exemplo anterior. A diferença aqui é que você julga não haver intermediário algum.

Eu não acho muito provável que a informação que vazou da RSA tenha a ver com ataques tipo "man-in-the-middle". Apesar dos sistemas de senhas descartáveis tentarem mitigá-lo (por exemplo, no sistema do SecurID, cada senha descartável perde a validade em poucos mais de um minuto), esse tipo de ataque é considerado "fora da escopo" da proteção oferecida pelos sistemas de senhas descartáveis. As técnicas e produtos para se evitar ou minimizar os efeitos desse tipo de ataque vão por outros caminhos totalmente diferentes.

Em um dos comentários sobre a matéria que saiu na Slashdot, há o que parece ser uma cópia do email enviado pela RSA para seus clientes. O email explicitamente diz que os produtos afetados são "implementações do RSA SecurID", mas as recomendações de ações mitigativas é tão somente uma lista de boas práticas de segurança de sistemas de informação. Não dá pra inferir dela nenhuma pista que nos permita chegar mais perto da raiz do caso.

Voltando ao incidente em si, há também a questão de como, exatamente, eles foram invadidos – quais as técnicas, mecanismos e pessoas envolvidas no processo. Tenho esperança quase zero de que esses dados venham à tona – normalmente essas coisas ficam restritas ao grupo que investigou o caso. O que provavelmente vermos é algum outro comunicado anódino dizendo que algo nas linhas de "após um estudo aprofundado do caso por um comitê de especialistas internos e externos, sentimo-nos confiantes de termos tomado todas as medidas cabíveis para mitigar os impactos e prevenir novas ocorrências deste tipo no futuro."

Em situações como essa, é comum que as empresas cedam à tentação de tentar encobrir o problema. Por isso, não deixa de ser louvável que a RSA tenha tido a iniciativa de trazê-lo a público, embora os cínicos de plantão (grupo do qual eu me excluo) tendam a se perguntar há quanto tempo eles já sabiam disso e se eles só o fizeram porque o bafafá seria inevitável mesmo. Por enquanto, só nos resta ficarmos ligados para ver como a coisa toda vai se desenrolar.


fonte: tempest.blog

[Satangos]

eu uso token da RSA no itau


pra gente acho que não afeta muita coisa né?

[colher]

odeio esse token filho da puta do itau
tem que levar essa merda pra todo canto, vsf

[Sabbath]

nossa colher... heaoaheoaehae eu acho tão de boa.. difícil é carregar 4928428 chaves tetra pra todo lado e descobrir qual é qual..

[Rath]

cartaozinho de senhas eh mais pratico

[Chronos]

run to the hills

[DeMolay]

run for you lives

[Stranger]

e nada de valor foi perdido.

[SsjGohan]

culpa dos veio q não sabe trocar senha
e usam a mesma pra cadastrar no bocha.com.br
e a mesma em projetos milionários :/
e ainda devem escrever a senha nos e-mail de gatos

[colher]

Postado por Sabbath

nossa colher... heaoaheoaehae eu acho tão de boa.. difícil é carregar 4928428 chaves tetra pra todo lado e descobrir qual é qual..

ai que tá, eu nao quero ser obrigado a carregar essa porra de chaveirinho feio pra onde vou...

[Sephiroth]

Entrei no topico achando q era run to the hills a situacao

[Never Ping]

E a vida se segue.

[Renegade]

contagem regressiva pra eles acharem o cara, e contratarem..

[marz]

tldr
resumo?

[serjaum]

gosto do hsbc
vc tem q decorar uma imagem hue