Registro.br - divulgação de correção de vulnerabilidade - csrf

[rubensk]

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.

 

[Fernando Ferenz]

Os intervalos de propagação de DNS continuam o mesmo? tenho um domínio que sempre esta em vermelho na propagação la como se tivesse recusado o dns mas continua entrando para todos, o erro é mais visual apenas no whois, ou existe um cache disso?

[rubensk]

1 hour ago, Fernando Ferenz said:

Os intervalos de propagação de DNS continuam o mesmo? tenho um domínio que sempre esta em vermelho na propagação la como se tivesse recusado o dns mas continua entrando para todos, o erro é mais visual apenas no whois, ou existe um cache disso?

A propagação DNS é alterada no minuto :00 e no minuto :30 de cada hora. 

Esse tipo de erro de verificação aparece apenas no WHOIS, mas se mantido por muito tempo pode gerar mensagem de alerta. Uma causa comum de "vermelho" é um warning de diferença de número de série, mas que não é nem impeditiva de registro nem geradora de alerta. O que o domínio em questão mostra especificamente ? 

[Fernando Ferenz]

5 minutos atrás, rubensk disse:

A propagação DNS é alterada no minuto :00 e no minuto :30 de cada hora. 

Esse tipo de erro de verificação aparece apenas no WHOIS, mas se mantido por muito tempo pode gerar mensagem de alerta. Uma causa comum de "vermelho" é um warning de diferença de número de série, mas que não é nem impeditiva de registro nem geradora de alerta. O que o domínio em questão mostra especificamente ? 

Confere ali pra min nrseg.com.br e veja no whois, ambos ns1 e ns2 pingam ao ip do servidor o site abre normal mas o vermelho ta la no whois.

[rubensk]

2 minutes ago, Fernando Ferenz said:

Confere ali pra min nrseg.com.br e veja no whois, ambos ns1 e ns2 pingam ao ip do servidor o site abre normal mas o vermelho ta la no whois.

 Servidor DNS:

ns1.agenciaidc.com.br

 

 Status:

17/01/2017 CREFUSED

 

 Último OK:

28/11/2016

 

 Servidor DNS:

ns2.agenciaidc.com.br

 

 Status:

17/01/2017 CREFUSED

 

 Último OK:

28/11/2016

CREFUSED é "Connection Refused", é bem grave isso... e não é só a partir do Registro.br, o Zonemaster (https://www.zonemaster.net/) do pessoal da França e Suécia também não consegue conectar. De fato resolução DNS funciona, como mostra o ISP Tools (http://www.isptools.com.br/dns#1!131!A!nrseg.com.br), mas parece que seu servidor ou seu datacenter tem implicância com testes de DNS.

O relatório deste teste do DNSViz sugere que seu servidor DNS não esteja aceitando conexão UDP 53: http://dnsviz.net/d/nrseg.com.br/WIAA5Q/dnssec/
Como em DNS há possibilidade de fall-back para TCP 53, pelo visto é o que está segurando ele no ar. 

[Fernando Ferenz]

10 horas atrás, rubensk disse:

 Servidor DNS:

ns1.agenciaidc.com.br

 

 Status:

17/01/2017 CREFUSED

 

 Último OK:

28/11/2016

 

 Servidor DNS:

ns2.agenciaidc.com.br

 

 Status:

17/01/2017 CREFUSED

 

 Último OK:

28/11/2016

CREFUSED é "Connection Refused", é bem grave isso... e não é só a partir do Registro.br, o Zonemaster (https://www.zonemaster.net/) do pessoal da França e Suécia também não consegue conectar. De fato resolução DNS funciona, como mostra o ISP Tools (http://www.isptools.com.br/dns#1!131!A!nrseg.com.br), mas parece que seu servidor ou seu datacenter tem implicância com testes de DNS.

O relatório deste teste do DNSViz sugere que seu servidor DNS não esteja aceitando conexão UDP 53: http://dnsviz.net/d/nrseg.com.br/WIAA5Q/dnssec/
Como em DNS há possibilidade de fall-back para TCP 53, pelo visto é o que está segurando ele no ar. 

O mesmo name server é usado em outros domínios e esta normal, é apenas neste domínio que aconteceu isso.

[chuvadenovembro]

@rubensk O teste foi feito em laboratório ou alguém fez isso propositalmente, acessou o registro.br e o site malicioso simultaneamente...

[rubensk]

2 minutes ago, chuvadenovembro said:

@rubensk O teste foi feito em laboratório ou alguém fez isso propositalmente, acessou o registro.br e o site malicioso simultaneamente...

As provas de conceito que foram mencionadas foram propositais, mas o episódio que foi citado de 2015 foi sim de acesso simultâneo ao registro.br e ao site malicioso. Sorte que o cara estava alerta e ainda logado viu o e-mail de mudança, e desfez a mudança. 

 

[ElderVinicius]

Pessoal, recentemente o Google WebMaster vinha me mandando notificação que havia sido detectado em alguns sites que estavam em minha VPS que tinha sido encontrado conteúdo de Engenharia Social.

E hoje, minha VPS simplesmente foi SUSPENSA porque segundo a Host1Plus estava sendo utilizada para  phishing.

Oque devo fazer?

Estou pensando em subir uma VPS em paralelo e restaurar o bkp que tinha sido feito de madrugada. 

Mas não sei onde estava o problema....

[Fernando Ferenz]

23 minutos atrás, ElderVinicius disse:

Pessoal, recentemente o Google WebMaster vinha me mandando notificação que havia sido detectado em alguns sites que estavam em minha vps que tinha sido encontrado conteúdo de Engenharia Social.

E hoje, minha vps simplesmente foi SUSPENSA porque segundo a Host1Plus estava sendo utilizada para  phishing.

Oque devo fazer?

Estou pensando em subir uma vps em paralelo e restaurar o bkp que tinha sido feito de madrugada. 

Mas não sei onde estava o problema....

Geralmente a empresa que suspende tem que mandar os motivos e quem estava fazendo a infração.