na Synack, realmente gostamos de grandes vulnerabilidades, seja na web, no celular, no host ou mesmo em dispositivos e sistemas completamente ultrajantes (hackeando alguém por satélite?). Mas sempre mantemos Confidenciais as grandes descobertas que nós e a SRT fizemos para nossos clientes. Portanto, embora este não seja um post sobre um grande vuln em um cliente Synack, ele cobre o tipo exato de coisa que vemos semanalmente ou às vezes diariamente: uma vulnerabilidade em um sistema com milhões de usuários que leva a um comprometimento completo da segurança do sistema.

recentemente encontrei uma vulnerabilidade no Microsoft Live.com sistema de autenticação, que, se você tiver uma conta com qualquer serviço da Microsoft, provavelmente teria afetado você. Esta postagem descreve todos os detalhes da vulnerabilidade agora que a Microsoft corrigiu o problema.

introdução

a compreensão da pessoa média da segurança do computador sempre foi bastante limitada. Naquela época, se alguém ouvisse que você estava envolvido em segurança de computadores, a pergunta padrão seria “você pode hackear meu Hotmail” ou, mais frequentemente, “você pode hackear o Hotmail do meu amigo”. Suponho que naquela época as pessoas ainda usavam o Yahoo mail e a Microsoft ainda não havia adquirido o Hotmail, mas isso está um pouco longe demais! Inevitavelmente, você sugeriria que a pessoa apenas adivinhasse as perguntas de redefinição de senha da pessoa ou instalasse o Sub7. Na verdade, hackear o Hotmail era muito difícil, para não mencionar totalmente ilegal.O mundo da segurança da informação mudou muito nos últimos dois anos e, ao contrário dos anos anteriores, a Microsoft agora incentiva totalmente os pesquisadores de segurança a tentar “hackear o Hotmail”. Claro que o Hotmail foi transformado em Outlook.com, e hoje em dia todo mundo quer saber se você pode hackear seu Facebook, mas isso está fora do ponto.

O Microsoft Online Services programa de recompensas também foi recentemente atualizado para incluir a “Conta da Microsoft” como um alvo, que é basicamente o login sistemas hospedados em cada um desses domínios:
– login.windows.net
– login.microsoftonline.com
– login.live.com

Na lista acima, login.live.com é o sistema de autenticação que você vai passar se você está tentando autenticar Outlook.com e um grande número de outros serviços da Microsoft. Decidi examiná-lo primeiro para ver se poderia descobrir algum problema. Como esperado, as várias APIs usadas para processar um login pareciam estar bem endurecidas. Camadas adicionais de proteção existiam em muitos lugares; por exemplo, em alguns lugares, as senhas são criptografadas com uma chave pública antes da transmissão, apesar de todas as comunicações ocorrerem por HTTPS.

depois de testar por algumas horas, descobri alguns problemas menores que relatei, mas nada realmente digno de nota. Ao testar aplicativos da web, muitas vezes acho que o fluxo de trabalho mais comum também é o mais seguro, então me ramifiquei para examinar outras maneiras pelas quais um usuário poderia se autenticar live.com sistema. Quase um ano atrás, encontrei várias vulnerabilidades OAuth no Yammer, que também era um alvo de recompensas de Serviços Online da Microsoft, então foi aí que procurei a seguir live.com. é aqui que começam as descobertas interessantes!

Fundo de vulnerabilidade

Antes de entrar diretamente na vulnerabilidade descoberta, é necessária uma visão geral rápida do sistema de segurança equivocado conhecido como OAuth:

a Wikipedia me diz que”OAuth fornece aos aplicativos clientes um ‘acesso delegado seguro’ aos recursos do servidor em nome do proprietário de um recurso”. A Wikipedia também tem alguns comentários contundentes sobre sua evolução e segurança, que valem a pena ler para uma boa risada. Realisticamente, tudo o que o OAuth faz é permitir que um usuário conceda acesso a alguns ou a todos os acessos de sua conta a terceiros. Fiz um desenho do MS Paint para ilustrar isso porque não consegui encontrar um ótimo na Wikipedia.

Como pode ser visto na imagem acima, você tem um Servidor que o Usuário autorizado a dar acesso a uma conta de um Aplicativo Cliente. O mecanismo que lida com isso nos bastidores pode ser construído de várias maneiras diferentes, que são definidas no OAuth RFC. Uma maneira de construí-lo é para um fluxo de autenticação “implícito”, que envolve o servidor de autenticação dando uma chave de acesso diretamente para o cliente. Outra maneira popular é usar um procedimento de” código de autorização”, onde o servidor de autenticação fornece um código de autorização, que o sistema cliente recebe e, em seguida, troca por uma chave de acesso usando seu valor secreto do cliente. A Microsoft tem uma boa descrição de seu uso de como eles implementaram esses mecanismos para live.com aqui:
https://msdn.microsoft.com/en-us/library/hh243647.aspx

o gráfico que eles fizeram para o fluxo de “código de autorização” é assim:

uma imagem como essa é ótima para entender o processo, mas para mim, como testador de caneta, também mostra muitas oportunidades e lugares para as coisas darem errado. Então, com isso como pano de fundo, sobre o que foi descoberto!

O Que Poderia Dar Errado?

conforme observado na seção acima, há muitos lugares em que algo pode dar errado. Uma das etapas fundamentais no procedimento de autenticação OAuth é que um usuário opte por conceder acesso a um aplicativo. Isso geralmente é realizado por meio de um prompt como este:

Geralmente, um usuário só precisa aceitar este pedido, uma vez, mas até eles aceitarem, que o app não tem qualquer acesso à sua conta (se é ou não o usuário médio vai permitir Wes Mal do Aplicativo obtenha acesso é, talvez, uma questão diferente!).

pensando como um invasor, seria definitivamente ótimo se pudéssemos aceitar a solicitação em nome do Usuário. Infelizmente para mim, o cabeçalho” X-Frame-Options “foi definido como” negar ” (as configurações de X-frame-options também estavam fora de escopo para essa recompensa). Então, enquanto clickjacking está fora, eu decidi obter uma melhor compreensão de como o pedido em si funcionou. Se um usuário clicar em “Sim”, a seguinte solicitação será postada no servidor (além de alguns cabeçalhos chatos):

embora o caminho do URL acima inclua alguns tokens gerados, os testes mostraram que eles eram desnecessários para que a solicitação fosse bem-sucedida. Uma postagem no URL a seguir também funcionaria:

https://account.live.com/Consent/Update?ru=https://login.live.com/oauth20_authorize.srf%3flc%3d1033%26client_id%3d000000004C15E107% 26scope % 3dwl.basic%26response_type%3dcode%26redirect_uri%3dhttp:// exfiltrated.com&client_id=000000004C15E107&rd=exfiltrated.com & scope=wl.basic

o cookie enviado com a solicitação necessária para conter um token de sessão válido em”IPT”. Este valor de cookie é preenchido porhttps:/ / login.live.com / oauth20_authorize.srf antes que a página solicitando permissão ao usuário seja exibida. Isso acontece independentemente de um usuário clicar ou não em “Sim”, embora seja definido por algum código Javascript, portanto, se estivermos atacando esse processo, teríamos que forçar o usuário a carregar essa página em algum momento.

se você está acompanhando, espero que agora esteja perguntando: “OK, então e a própria solicitação POST e esse valor Canário?”. Eu examinei todos os outros parâmetros e fluxos de comunicação primeiro, pois ver um valor rotulado como “canário” sendo enviado com uma solicitação POST quase certamente significa que ele está sendo usado como um token para evitar ataques CSRF. O objetivo do teste de segurança, no entanto, é verificar se as suposições estão realmente corretas. Então eu modifiquei a solicitação POST e alterei o valor canary para”hacks_go_here”. Em vez de redirecionar para um erro 500, o servidor Enviou de volta uma resposta positiva!

CSRF para PoC

desde que o token CSRF foi a última coisa que eu tentei mexer, eu sabia com certeza que isso deveria fazer para uma vulnerabilidade CSRF válida. Tal como acontece com quase todos os ataques CSRF, o único pré-requisito era que a vítima estivesse logada e tivesse um token de sessão válido em seu cookie. Ao contrário de muitas outras vulnerabilidades da web, o impacto de uma vulnerabilidade CSRF depende inteiramente da função da API afetada. Este CSRF me permite ignorar a etapa de interação do usuário do sistema de autenticação OAuth, mas um PoC vale mais que mil palavras, então o próximo passo foi construir algum código para demonstrar adequadamente o impacto dessa vulnerabilidade.

no fluxo de autenticação OAuth normal, após o usuário conceder acesso, o servidor deve retornar um código de acesso ao usuário. O usuário passa isso para o aplicativo cliente, que pode usar as permissões concedidas. A live.com o aplicativo cliente pode solicitar uma ampla gama de permissões possíveis. Eu considerei apenas despejar os contatos do usuário ou algo assim, mas por que sacrificar o objetivo de hackear o Hotmail agora? As permissões que meu PoC precisava eram:

wl.offline_access + wl.imap

Offline não era tão necessário, mas joguei para mostrar que seria concedido.

com as permissões necessárias escolhidas, existem 4 etapas para obter acesso à conta de E-mail de um usuário:

1) precisamos fazer uma solicitação de autorização para nosso aplicativo cliente usando as permissões acima. O servidor solicitará que o usuário aceite ou recuse.
2) Quando um usuário aceita nossa solicitação para essas permissões, o servidor anexará um parâmetro “#access_token=<token>” ao redirecionamento que instruímos a fazer.
3) como nossos scripts do lado do servidor precisarão acessar esse valor, precisamos fazer uma página simples para pegar o token do campo URL do navegador e passá-lo para o nosso servidor.
4) finalmente, precisamos de alguns scripts do lado do servidor para pegar esse token e usá-lo para fazer login no IMAP. A Microsoft tem um processo um tanto complicado para usar o token OAuth para fazer login diretamente via IMAP. Existem algumas bibliotecas de amostra para isso e todo o processo é descrito nesta página:
https://msdn.microsoft.com/en-us/library/dn440163.aspx

esse fluxo de trabalho funcionaria bem, assumindo que o usuário opte por nos dar permissão. Agora só preciso modificar o fluxo de trabalho para incluir o CSRF. Como observado anteriormente, o live.com o servidor de autenticação estará esperando um token de sessão no cookie IPT. Podemos garantir que seja preenchido enviando primeiro o Usuário para uma página validhttps:/ / login.live.com / oauth20_authorize.srf. Imediatamente depois, podemos executar a solicitação CSRF que fará uso do valor do cookie recém-preenchido. Isso agora pode substituir a Etapa 1 e forçar o servidor a pular imediatamente para a Etapa 2.

Demo e impacto

a Microsoft agora corrigiu esse problema, mas aqui está um vídeo rápido mostrando-o em ação.

como pode ser visto no vídeo, tudo o que é realmente necessário é fazer com que a vítima Visite sua página maliciosa. A demonstração não foi projetada para ser sorrateira e executada no fundo de um site, ou como parte de algum anúncio de banner malicioso, mas certamente poderia ter sido feito dessa maneira.

usar isso como um ataque direcionado definitivamente tem um alto impacto, mas esse também é o tipo perfeito de vulnerabilidade para se transformar em um worm. Com o IMAP e o contact book access, um worm pode facilmente enviar e-mail para todos os contatos de um usuário (ou pelo menos aqueles que usam o Hotmail, Outlook.com, etc), com algo atraente, “ILOVEYOU” estilo de vírus, e se espalhou para todos os usuários que clicam no link.

Pensamentos finais e linha do tempo

caçar essa vulnerabilidade e fazer um PoC de trabalho envolveu uma boa quantidade de esforço cavando os vários live.com API. Olhando para trás, no entanto, isso realmente é apenas uma vulnerabilidade CSRF clássica. A única coisa que é surpreendente sobre isso é que ele está em um sistema de autenticação crítica que, em última análise, pode ser usado para assumir a conta de qualquer usuário.

como um testador externo, Não tenho ideia de quanto tempo essa vulnerabilidade pode ter existido ou se alguém tentou explorá-la. Ao mesmo tempo, são descobertas como essa que definitivamente mostram o valor de permitir que Testadores externos enviem vulnerabilidades à sua empresa antes que os invasores os aproveitem contra você. A Microsoft está muito à frente da maioria das empresas quando se trata de segurança e, no entanto, ainda é suscetível a problemas como este. A experiência da Synack tem sido que as vulnerabilidades são descobertas mesmo em sistemas aparentemente bem protegidos quando um grande grupo de pesquisadores externos testa esse sistema. Essa é essencialmente a premissa em que a Synack Opera e é por isso que mais e mais empresas estão oferecendo seus próprios programas de recompensas (eu, é claro, recomendaria o programa da Synack ao invés de administrar o seu próprio!).

como pode ser visto na linha do tempo abaixo, a Microsoft respondeu ao obter uma correção para esse problema, o que foi ótimo de ver.

linha do tempo:
23 de agosto de 2015: vulnerabilidade descoberta
25 de agosto de 2015: vulnerabilidade relatada à Microsoft
31 de agosto de 2015: Microsoft emite o número do caso para vulnerabilidade
15 de setembro de 2015: Microsoft libera correção para problema, emite $ 24.000 bounty (Double bounties promo)