From rubensk at nic.br Wed Jan 18 19:45:22 2017 From: rubensk at nic.br (Rubens Kuhl) Date: Wed, 18 Jan 2017 19:45:22 -0200 Subject: [Eppnicbr] Fwd: [GTS-L] Divulgacao de Correcao de Vulnerabilidade - Registro.br - CSRF References: Message-ID: <65487FEA-D19F-4D78-B132-7F6F5B68844F@nic.br> 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 . 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 > para que a quest?o possa ser investigada. > > [1] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) > [2] https://registro.br/a/3/310 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: