Fonte: https://registro.br/noticias.html#20170118

Em 5/1/2017 fomos informados de uma possível vulnerabilidade no sistema de registro que permitiria ataques do tipo CSRF ("Cross-Site Request Forgery"). Investigação sobre esse relato confirmou essa vulnerabilidade, o que deu início a uma revisão completa de todo o código do sistema para identificar e corrigir outras possíveis falhas. As correções de trechos mais críticos foram colocadas em produção já no mesmo dia 5/1/2017, enquanto funções de menor risco foram sendo corrigidas até o dia 17/1/2017.

Até a correção implementada em 5/1/2017, essa vulnerabilidade permitia, caso o usuário estivesse logado no sistema e, ao mesmo tempo, estivesse visitando um sítio malicioso que visa a ataque, tivesse os parâmetros de sua conta alteráveis. As alterações mais críticas que podiam ser feitas eram as de endereço de e-mail e senha de contatos. A janela de exposição dessa vulnerabilidade era bastante curta, devido ao limite do tempo de sessão, somada a exigência do acesso simultâneo a esse sítio controlado pelo atacante.

Verificação dos logs do sistema, observou que houve "prova de conceito" por conhecedores dessa vulnerabilidade em 30/10/2015. Poucos dias depois, em 2/11/2015, ocorreu o único caso conhecido de exploração dessa vulnerabilidade: um usuário teve seus dados cadastrais alterados através de um ataque CSRF. Como, porém, o registro envia imediatamente aviso de alteração e esse usuário ainda estava logado, ele pôde facilmente restabelecer sua configuração correta da conta. Esse usuário não nos reportou este episódio e, por isso, apenas as investigações iniciadas em 5/1/2017 possibilitaram esta descoberta.

Algumas outras "provas de conceito" foram efetuadas ao longo de 2016, mas nenhum ataque bem-sucedido deste tipo foi observado. A necessidade de personalização do ataque, a conjunção de fatores de baixa probabilidade de ocorrência, o tempo curto de sessão, o baixo número de vezes em que usuários típicos mantém sessões ativas no sistema de registro, o envio de e-mails avisando de cada alteração efetuada e a necessidade de uma estrutura de ataque com plantão 24 horas para reagir imediatamente a um possível sucesso do ataque, possivelmente tenham se somado para desestimular qualquer tentativa nesse sentido.

Apenas como ilustração, e dados os episódios recentes de maior repercussão envolvendo alterações de servidores DNS, especial atenção foi dada a verificar se havia ou não alguma conexão com essa vulnerabilidade. Todas as evidências presentes provam que não: são eventos sem nenhuma relação com ataques CSRF. Os episódios citados usaram credenciais e sessões válidas e se basearam em ataques de engenharia social, seja passando-se por um cliente pedindo a um intermediário "uma alteração", através de phishing ou, ainda, pelo comprometimento de uma conta de e-mail. Esses episódios poderiam ter sido evitados com os cuidados canônicos com senhas, "phishing" e detecção de engenharia social. Melhor ainda, teriam sido totalmente evitados se autenticação em duas etapas (Token) estivesse em uso ou nessas contas ou na qualificação de requisições efetuadas por prestadores de serviço.

Notar que a vulnerabilidade descrita e consertada não teria permitido acesso a contas usando Token, pois a remoção deste mecanismo exige um tipo de transação de maior dificuldade de implementação em ataques CSRF e é tipicamente bloqueada pelos mecanismos internos de segurança dos browsers. Com o Token ativo, a mudança de apenas um dos fatores de autenticação deteria o efeito prático desse ataque.

Gostaríamos de agradecer a Bruno Deves por trazer essa vulnerabilidade ao nosso conhecimento, e pedimos a usuários que caso descubram alguma vulnerabilidade ou se deparem com um comportamento estranho do sistema, entrem em contato conosco, para que a questão possa ser investigada.