[Eppnicbr] Fwd: [GTS-L] Divulgacao de Correcao de Vulnerabilidade - Registro.br - CSRF

[Rubens Kuhl]

Para conhecimento, segue divulgação sobre correção de vulnerabilidade.
Cabe notar que ela não se aplicava à EPP, mas que pode ser prudente aos provedores EPP verificarem a possibilidade desse tipo de problema em seus sites de registro e gestão de domínios. 

Link para a divulgação:  https://registro.br/noticias.html#20170118 <https://registro.br/noticias.html#20170118> . 

Rubens



> 
> 
> ---------- Forwarded message ----------
> From: Frederico A C Neves 
> Date: 2017-01-18 19:39 GMT-02:00
> Subject: [GTS-L] Divulgacao de Correcao de Vulnerabilidade - Registro.br - CSRF
> To: Grupo de Trabalho em Seguranca de Redes 
> 
> 
> 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") [1]. 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 [2]) 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, https://registro.br/contato.html <https://registro.br/contato.html>
> para que a questão possa ser investigada.
> 
> [1] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) <https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)>
> [2] https://registro.br/a/3/310 <https://registro.br/a/3/310>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://eng.registro.br/pipermail/eppnicbr/attachments/20170118/10b96208/attachment.html>