Provavelmente, todos os usuários do navegador Google Chrome conhecem a famosa janela que pergunta se queremos armazenar nossa senha ao fazer login em uma página web. Neste post, explicaremos o mecanismo que o Google Chrome usa para armazenar e proteger as senhas que concordamos em salvar e analisaremos alguns aspectos de segurança.

Como as informações de login são armazenadas no Chrome?

Ao clicar no botão "aceitar", estamos permitindo que o Google Chrome salve no computador o nome de usuário e a senha inseridos no formulário de login de um site. Mais especificamente, esses dados serão armazenados em um banco de dados SQLite3 que geralmente pode ser encontrado no seguinte endereço:

%LocalAppData%\Google\Chrome\User Data\Default\Login Data  

O arquivo que contém o banco de dados é usados apenas pelo Google Chrome, portanto, presume-se que nenhum outro software “benigno” irá acessá-lo. Quanto à estrutura interna desse banco de dados, suas tabelas possuem os seguintes campos:

Imagem 1. Tabelas e campos do banco de dados usado para armazenar senhas.

Essas tabelas contêm todas as informações necessárias para que o mecanismo de lembrança de senhas possa funcionar corretamente. Em seguida, nossos dados de login são armazenados principalmente na tabela "logins", sendo os campos "username value" e "password_value" aqueles que contêm as informações mais sensíveis. No entanto, esses campos por si só são inúteis, já que o Google Chrome também precisa saber a qual site essas credenciais correspondem. Aqui entra em jogo outro campo da mesma tabela: "origin_url", que contém o endereço do site no qual as senhas foram utilizadas. Os demais campos contêm outros elementos que contribuem para o correto funcionamento do mecanismo, mas sem tanta importância.

Deve-se observar que, por motivos básicos de segurança, as senhas não são armazenadas em texto simples - ou seja, todas as senhas são criptografadas. Ao contrário, em sistemas Windows, o Google Chrome usa uma função de criptografia fornecida pelo sistema operacional: CryptProtectData (Crypt32.dll).

Essa função tem a particularidade de ser projetada de forma que os dados criptografados só possam ser descriptografados pelo mesmo usuário do sistema operacional que estava logado quando a senha foi criptografada. Além disso, essa função também pode ser configurada para que os dados criptografados só possam ser descriptografados no mesmo computador em que foram criptografados. Ou seja, ao contrário das funções de criptografia em geral, essa função não usa uma chave em particular definida pelo usuário, mas usa as credenciais de acesso do usuário no próprio sistema operacional.

Portanto, se um cibercriminoso quisesse roubar essas credenciais, ele não teria outra escolha a não ser descriptografá-las fazendo login no computador e usando o mesmo usuário que as criou e transferindo-as posteriormente.

Quais são os riscos de usar esse mecanismo para armazenar senhas?

Se um atacante tiver acesso ao computador, ele pode facilmente obter as senhas, descriptografá-las e roubá-las em texto simples. Esse tipo de comportamento foi observado em vários códigos maliciosos e até mesmo em trojans bancários direcionados especificamente para a América Latina, onde se destinam a roubar credenciais de acesso de serviços home banking.

A dinâmica desses ataques é simples. É possível ter acesso ao conteúdo dessas tabelas da mesma forma como a estrutura interna das tabelas anteriores foram obtidas. Veja um exemplo:

Começamos tentando fazer login no Facebook com um nome de usuário e senha fictícios. Com a indicação do navegador, clicamos na opção para que o Google Chrome salve nossas credenciais.

Imagem 2. Janela do Google Chrome para armazenar as credenciais fictícias usadas neste exemplo.

Depois que nosso nome de usuário e senha são armazenados no banco de dados do Google Chrome, prosseguimos para localizar o arquivo no qual essas informações estão salvas.

Imagem 3. Arquivo correspondente ao banco de dados SQLite3 usado pelo Google Chrome.

Basta abrir o arquivo com algum programa que permite visualizar bancos de dados (neste exemplo: DB Browser for SQLite).

Imagem 4. Campos da tabela “logins” junto com seu conteúdo, no qual as credenciais de acesso utilizadas neste exemplo podem ser visualizadas.

Após abrir o arquivo com a ferramenta DB Browser, ao passarmos para a tabela "logins", podemos encontrar as entradas nas quais se encontram os dados para login, que incluem: URL, nome de usuário e senha. Como pode ser visto na caixa vermelha localizada à direita na Imagem 4, a senha armazenada é criptografada em uma estrutura BLOB e, ao clicarmos nesse campo, o programa nos mostra a representação hexadecimal dela.

Nesse momento, o atacante já possui o nome de usuário, o site e a senha criptografada – faltando apenas concluir a etapa final: descriptografar a senha. Para isso, o atacante se aproveita do fato de ter acesso (físico ou virtual) ao dispositivo, pois é bastante provável que o usuário ativo seja o mesmo usuário que salvou anteriormente a senha, permitindo que o atacante possa descriptografá-la usando a função: CryptUnprotectData (a função inversa à mencionada anteriormente).

Todas essas etapas podem ser realizadas por um malware de forma rápida e automática. No entanto, o malware não é o único risco que devemos ter em conta, uma vez que atualmente existem vários programas facilmente acessíveis por meio de uma pesquisa online que são capazes de realizar esses mesmos passos. Este não é um detalhe insignificante, já que esses programas permitem que qualquer pessoa sem nenhum conhecimento técnico, mas com acesso físico ao computador desbloqueado, roube as credenciais da mesma forma que o malware faria.

Conclusão

Embora seja verdade que o mecanismo de armazenamento usado pelo Google Chrome represente um risco de segurança apenas nos casos em que o computador já estava previamente comprometido ou exposto, o uso dessa funcionalidade adiciona um vetor de ataque extra que pode ser explorado por um atacante.

É importante ressaltar que todos os riscos citados acima se limitam exclusivamente a esse mecanismo, ou seja, ao risco de que as senhas armazenadas sejam roubadas. Portanto, o ideal é não usar essa funcionalidade e, caso seja necessário usá-la, não a use para salvar senhas de serviços como home banking, redes sociais, sites médicos ou que contenham informações pessoais.