<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Para conhecimento, segue divulgação sobre correção de vulnerabilidade.<div class="">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. </div><div class=""><br class=""></div><div class="">Link para a divulgação: <a href="https://registro.br/noticias.html#20170118" class="">https://registro.br/noticias.html#20170118</a> . </div><div class=""><br class=""></div><div class="">Rubens</div><div class=""><br class=""></div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><br class=""><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_quote">---------- Forwarded message ----------<br class="">From: <b class="gmail_sendername">Frederico A C Neves</b> <br class="">Date: 2017-01-18 19:39 GMT-02:00<br class="">Subject: [GTS-L] Divulgacao de Correcao de Vulnerabilidade - <a href="http://Registro.br" class="">Registro.br</a> - CSRF<br class="">To: Grupo de Trabalho em Seguranca de Redes <br class=""><br class=""><br class="">Em 5/1/2017 fomos informados de uma possível vulnerabilidade no<br class="">
sistema de registro que permitiria ataques do tipo CSRF ("Cross-Site<br class="">
Request Forgery") [1]. Investigação sobre esse relato confirmou essa<br class="">
vulnerabilidade, o que deu início a uma revisão completa de todo o<br class="">
código do sistema para identificar e corrigir outras possíveis<br class="">
falhas. As correções de trechos mais críticos foram colocadas em<br class="">
produção já no mesmo dia 5/1/2017, enquanto funções de menor risco<br class="">
foram sendo corrigidas até o dia 17/1/2017.<br class="">
<br class="">
Até a correção implementada em 5/1/2017, essa vulnerabilidade<br class="">
permitia, caso o usuário estivesse logado no sistema e, ao mesmo<br class="">
tempo, estivesse visitando um sítio malicioso que visa a ataque,<br class="">
tivesse os parâmetros de sua conta alteráveis. As alterações mais<br class="">
críticas que podiam ser feitas eram as de endereço de e-mail e senha<br class="">
de contatos. A janela de exposição dessa vulnerabilidade era bastante<br class="">
curta, devido ao limite do tempo de sessão, somada a exigência do<br class="">
acesso simultâneo a esse sítio controlado pelo atacante.<br class="">
<br class="">
Verificação dos logs do sistema, observou que houve "prova de<br class="">
conceito" por conhecedores dessa vulnerabilidade em 30/10/2015. Poucos<br class="">
dias depois, em 2/11/2015, ocorreu o único caso conhecido de<br class="">
exploração dessa vulnerabilidade: um usuário teve seus dados<br class="">
cadastrais alterados através de um ataque CSRF. Como, porém, o<br class="">
registro envia imediatamente aviso de alteração e esse usuário ainda<br class="">
estava logado, ele pôde facilmente restabelecer sua configuração<br class="">
correta da conta. Esse usuário não nos reportou este episódio e, por<br class="">
isso, apenas as investigações iniciadas em 5/1/2017 possibilitaram<br class="">
esta descoberta.<br class="">
<br class="">
Algumas outras "provas de conceito" foram efetuadas ao longo de 2016,<br class="">
mas nenhum ataque bem-sucedido deste tipo foi observado. A necessidade<br class="">
de personalização do ataque, a conjunção de fatores de baixa<br class="">
probabilidade de ocorrência, o tempo curto de sessão, o baixo número<br class="">
de vezes em que usuários típicos mantém sessões ativas no sistema de<br class="">
registro, o envio de e-mails avisando de cada alteração efetuada e a<br class="">
necessidade de uma estrutura de ataque com plantão 24 horas para<br class="">
reagir imediatamente a um possível sucesso do ataque, possivelmente<br class="">
tenham se somado para desestimular qualquer tentativa nesse sentido.<br class="">
<br class="">
Apenas como ilustração, e dados os episódios recentes de maior<br class="">
repercussão envolvendo alterações de servidores DNS, especial atenção<br class="">
foi dada a verificar se havia ou não alguma conexão com essa<br class="">
vulnerabilidade. Todas as evidências presentes provam que não: são<br class="">
eventos sem nenhuma relação com ataques CSRF. Os episódios citados<br class="">
usaram credenciais e sessões válidas e se basearam em ataques de<br class="">
engenharia social, seja passando-se por um cliente pedindo a um<br class="">
intermediário "uma alteração", através de phishing ou, ainda, pelo<br class="">
comprometimento de uma conta de e-mail. Esses episódios poderiam ter<br class="">
sido evitados com os cuidados canônicos com senhas, "phishing" e<br class="">
detecção de engenharia social. Melhor ainda, teriam sido totalmente<br class="">
evitados se autenticação em duas etapas (Token [2]) estivesse em uso<br class="">
ou nessas contas ou na qualificação de requisições efetuadas por<br class="">
prestadores de serviço.<br class="">
<br class="">
Notar que a vulnerabilidade descrita e consertada não teria permitido<br class="">
acesso a contas usando Token, pois a remoção deste mecanismo exige um<br class="">
tipo de transação de maior dificuldade de implementação em ataques<br class="">
CSRF e é tipicamente bloqueada pelos mecanismos internos de segurança<br class="">
dos "browsers". Com o Token ativo, a mudança de apenas um dos fatores<br class="">
de autenticação deteria o efeito prático desse ataque.<br class="">
<br class="">
Gostaríamos de agradecer a Bruno Deves por trazer essa vulnerabilidade<br class="">
ao nosso conhecimento, e pedimos a usuários que caso descubram alguma<br class="">
vulnerabilidade ou se deparem com um comportamento estranho do<br class="">
sistema, entrem em contato conosco, <a href="https://registro.br/contato.html" rel="noreferrer" target="_blank" class="">https://registro.br/contato.<wbr class="">html</a><br class="">
para que a questão possa ser investigada.<br class="">
<br class="">
[1] <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)" rel="noreferrer" target="_blank" class="">https://www.owasp.org/index.<wbr class="">php/Cross-Site_Request_<wbr class="">Forgery_(CSRF)</a><br class="">
[2] <a href="https://registro.br/a/3/310" rel="noreferrer" target="_blank" class="">https://registro.br/a/3/310</a><br class=""><br class="">
</div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>