Tweet
Segundo ele, na verdade esse foi o resultado de um trabalho iniciado mais de um ano antes, quando ao trabalhar na plataforma de publicação Drupal descobriu um bug no External Entity Expansion do XML que afetava a parte que interage com o OpenID. Essa brecha permitia que se tivesse acesso ao sistema de arquivos para leitura de qualquer arquivo, fazer conexões de rede à sua escolha e até fazer um ataque DoS ao servidor.
“Na época não me preocupei em verificar se alguém mais estava vulnerável”, relatou em seu blog. Sua primeira preocupação foi registrar essa vulnerabilidade (ganhou a identificação CVE-2012-4554) para poder colocá-la no currículo, mas cinco dias depois concluiu que o OpenID era muito utilizado e portanto haveria muitos outros lugares vulneráveis. O teste seguinte, no formulário de login do Stack Overflow comprovou sua tese: era vulnerável mesmo.
O teste seguinte foi nos servidores do Google – eles não estavam abertos para leitura de arquivos ou abertura de conexões, mas estavam sujeitos a DoS. Esse trabalho rendeu US$ 500 a Reginaldo. Os testes seguintes mostraram que o mesmo problema estava presente em implementações com bibliotecas de Java, C#, PHP, Ruby, Python, Perl outras – e segundo Reginaldo os servidores que as utilizam continuam em perigo.
Para que os patches fossem feitos, Reginaldo entrou em contato com os autores das várias bibliotecas e acabou postando um email na lista de segurança da OpenID Foundation, relatando o problema e esperando que os patches aparecessem, mas não foi bem assim.
Localizar na rede do Facebook um endpoint que usasse OpenID, segundo ele, foi bem trabalhoso. “Antigamente o Google mostrava muitos links apontando esses endpoints, mas eles haviam desaparecido. Até que um dia eu estava testando a funcionalidade do Forgot your password? e vi ‘Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar....
Isso fez Reginaldo suspeitar que o Face fosse vunerável ao mesmo XXE que havia descoberto um ano antes. “Para confirmar, eu tinha de trabalhar muito. Quando você esquece sua senha do Face, uma das maneiras de provar que você tem uma conta do gmail.com é entrar no seu email e autorizar o face a pegar suas informações de lá. Na prática, você está acessando o Face com a conta do gmail. E esse login acontece pelo OpenID. Eu sabia que para conseguir explorar o bug, o ‘Relying Party’ do OpenID (no caso o Facebook) tinha de fazer uma solicitação de sondagem Yadis ao provedor de OpenID sob controle do atacante – que poderia ser meu site, o Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar.... Então, ele responderia com o XML contaminado para ser processado pelo Relying Party, e então o ataque funcionaria.
Como a solicitação inicial ao OpenID (redirecionada do Facebook ao Google) acontecia sem a minha intervenção, não havia como inserir uma URL sob meu controle, que fosse meu identificador OpenID, para que o Facebook pedisse uma descoberta Yadis para aquela URL. Achei que o bug não ia funcionar de jeito nenhum, a não ser que eu fizesse o Google enviar o XML malicioso ao Facebook, o que era improvável. Por sorte eu estava enganado. Depois de ler com mais atenção as especificações do OpenID 2.0, encontrei a resposta na seção 11.2 – Verificando Informação Descoberta: “If the Claimed Identifier was not previously discovered by the Relying Party (the “openid.identity” in the request was “Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... or a different Identifier, or if the OP is sending an unsolicited positive assertion), the Relying Party MUST perform discovery on the Claimed Identifier in the response to make sure that the OP is authorized to make assertions about the Claimed Identifier”.
“Eu chequei e, de fato, o openid.identity na requisição foi Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar.... Então, depois de alguns minutos, eu já era capaz de fazer uma solicitação para Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... fazendo o Facebook fazer uma discovery Yadis numa URL sob meu controle, e a resposta daquela requisição conteria um XML malicioso”, conta ele.
Eu soube que tinha um XXE quando pedi ao Facebook que abrisse /dev/random, mas a resposta nunca vinha e eventuamente um request killer logo apareceria. Mas eu ainda não conseguia ler o conteúdo de nenhum arquivo. Tentei de tudo com os truques de XXE, incluindo combinações estranhas envolvendo entidades de parâmetros, e nada. Aí me dei conta de que havia um pequeno problema com o meu código. Consertei, e então…
Código:
$ bash exploit.sh
* About to connect() to www.facebook.com port 80 (#0)
* Trying 31.13.75.1... connected
* Connected to www.facebook.com (31.13.75.1) port 80 (#0)
> GET /openid/receiver.php?provider_id=1010459756371
&context=account_recovery&protocol=http&request_id=1
&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0
&openid.mode=id_res&openid.op_endpoint=...(redacted)... HTTP/1.1
