Há algum tempo, venho procurando vulnerabilidades na plataforma HackerOne e alocando uma certa quantidade de tempo fora do trabalho principal para verificar meus programas favoritos e novos. Inúmeras vezes me deparei com uma vulnerabilidade XSS baseada em cookie, que se tornará o personagem principal deste artigo. Esse tipo de vulnerabilidade ocorre quando o valor do parâmetro cookie é refletido na página. Por padrão, eles são considerados auto-XSS, a menos que, por sua vez, provemos seu perigo. Na verdade, hoje vou explicar como explorar vulnerabilidades XSS baseadas em cookies e também darei um exemplo ao testar uma empresa da qual recebi US $ 7300 no total para o estudo.
Para executar o javascript no lado do usuário, você precisa encontrar uma maneira de definir um cookie e, se necessário, atrair a vítima para uma página onde, por sua vez, o cookie está incorporado. Maneiras possíveis de explorar esse bug:
1. Injeção de CRLF. Essa vulnerabilidade ocorre quando não há verificação e bloqueio adequados dos caracteres de quebra de linha. Podemos implementar o cabeçalho Set-cookie em resposta com o nome desejado, bem como o valor do cookie e configurá-lo no navegador. Exemplo da vida real: injeção de CRLF escorregadia no twitter.com em um redirecionamento - https://twitter.com/login?redirect_after_login=/jjjkkk 嘊 嘍 Set-Cookie: jjjjj = a; domain = twitter.com
Os relatórios sobre esse tipo de vulnerabilidade podem ser lidos em HackerOne
hackerone.com/hacktivity?order_direction=DESC&order_field=popular&filter=type%3Apublic&querystring=crlf%20injection2. Vulnerabilidade XSS no subdomínio. O XSS deve estar acessível ao público e localizado no curinga * .vulnerabledomain.com. Para muitos programas de recompensas de bugs, os subdomínios estão fora do escopo, ou seja, na maioria dos casos, os bugs não são aceitos ou são recebidos com a marca "não elegível para a recompensa". Nesses casos, você não deve recuar, mas para se conectar ao XSS baseado em cookie, você pode investir seu tempo na procura de XSS para obter uma recompensa. Se o XSS for detectado, podemos definir ou remover o cookie usando a função document.cookie.
Aprimoramento de impacto: muitas vezes, a vítima confia no domínio principal do vulnerabledomain.com mais do que, por exemplo, jira.vulnerabledomain.com e até mesmo no URL /plugins/servlet/oauth/users/icon-uri?consumerUri=https://maliciousdomain.com . É mais provável que ele mude para o domínio principal do que para o subdomínio se esse subdomínio não estiver associado a uma conta ou autorização pessoal. Com base no exposto, podemos usar a funcionalidade de redirecionamento no site para redirecionar para o subdomínio
vulnerabledomain.com/login?redirectUrl=https : //jira.vulnerabledomain.com/path para obter um efeito melhor.
Se a vítima tiver uma sessão ativa, o redirecionamento será automático, caso contrário, será necessária autorização. Quando o usuário clicar nesse link, o cookie também será instalado a partir do subdomínio no qual o Reflected XSS está presente, podendo ser enviado ainda mais a montante - para a página com XSS baseado em cookie, onde a exploração poderia funcionar, que, por sua vez, capturaria o valor CSRF do token e complete a solicitação para alterar o endereço de email. Portanto, uma combinação de duas vulnerabilidades XSS pode levar a uma aquisição de conta se não houver problemas associados, como confirmação adicional da alteração da senha ou código do email da caixa de correio antiga.
3. Detecção de arquivos de teste que permitem a configuração de cookies. É o suficiente para descobrir a ferramenta de detecção de conteúdo (dirb, dirserach, etc.), começar a cavar e, se os desenvolvedores esquecerem de executar a limpeza, você poderá encontrar esses arquivos.
Recentemente, encontrei uma página html de servlet de teste na qual era possível instalar um cookie com um nome e valor arbitrários. A proteção na solicitação do POST, é claro, estava ausente; portanto, se a vítima visitar a exploração do CSRF (ou você pode alterar o POST para GET), seria possível instalar um cookie no navegador.
Esse bug foi qualificado como uma alternativa alternativa à injeção de CRLF, corrigido pela remoção de / examples / e pago US $ 150 por um bug de baixa gravidade. Embora o h1 triager tenha entregado mídia, os desenvolvedores ainda estavam inclinados a acreditar que isso é de baixa gravidade.
4. Homem no ataque do meio (MITM). Este método pode ser aplicado apenas se não houver sinalizador seguro no cookie. Se você não souber que tipo de sinalizador é ou apenas deseja atualizar sua memória, recomendamos que você visualize a apresentação da segurança de cookies com o OWASP London 2017
www.owasp.org/images/a/a0/OWASPLondon20171130_Cookie_Security_Myths_Misconceptions_David_Johansson.pdf .
Para um ataque bem-sucedido, é necessário que a vítima esteja na rede do invasor ou que a resolução do DNS possa ser afetada. Para verificar a vulnerabilidade, é necessário:
1) hospede o arquivo index.php com o seguinte conteúdo:
<?php if ($_SERVER['HTTP_HOST'] == 'non-existed-subdomain.vulnerabledomain.com') { setrawcookie("VID",'\'+alert(123123123)+\'', time()+36000, "/", ".vulnerabledomain.com",0,1); } ?>
2) Adicione a seguinte linha ao seu arquivo / etc / hosts /: 127.0.0.1 non-existed-subdomain.vulnerabledomain.com
3) Visite non-existed-subdomain.vulnerabledomain.com e depois abra a página na qual o cookie é refletido.
Um exemplo maravilhoso da exploração do MITM no e.mail.ru é https://hackerone.com/reports/312548, como você pode ver, o MITM foi suficiente para provar um pequeno perigo de vulnerabilidade, mas o prêmio não correspondia ao nível do XSS armazenado, pois foi mostrado apenas Modo de operação "local", isto é, não "in-the-wild". Se o pesquisador gaste um pouco de tempo pesquisando por injeção de XSS ou CRLF (que são inúmeras) localizadas em * .mail.ru, a recompensa poderá ser ligeiramente aumentada.
Mas nem todos os programas hackerone aceitam XSS baseado em cookie através do MITM. Se as exclusões do escopo disserem “Self XSS”, essa operação poderá ser considerada como Self XSS e configurada como informativo ou n / a, o que nem sempre é agradável. Agora vou falar sobre um incidente semelhante que aconteceu comigo durante a próxima caçada na plataforma.
Ao testar o site, repentinamente vi que o valor dos cookies editados é refletido em um dos subdiretórios do site. A primeira coisa que fiz foi verificar a exibição dos caracteres '"/ <>. Acabou que apenas os caracteres <> foram filtrados, e isso nos diz que não podemos ir além, mas também fica claro que os outros caracteres não são filtrados Sem pensar duas vezes, implementamos '-alert (document.domain) -' e js é executado.
Como os desenvolvedores não deram ao cookie o sinalizador seguro, nesse caso, o método MITM funciona. Decidiu-se enviar um relatório ao programa com o seguinte impacto:
A equipe do HackerOne (triager) deixou claro que isso é auto-XSS e eu tenho que me esforçar mais:
Depois disso, comecei a navegar no site e tentar encontrar injeção de CRLF ou XSS para provar o perigo.
⠀ Eu tive que expandir a lista de subdomínios com a ajuda de um grande dicionário, raspando subdomínios com certificados SSL e usando outros truques. O resultado não demorou a chegar, como a maioria das ferramentas que eu executo com o VPS. De tempos em tempos, outros bugs também eram detectados ao longo do caminho, que eu relatei, tornando o escopo fora do escopo, se necessário. Me deparei com muitos redirecionamentos abertos e até um bug de controle de acesso inadequado por US $ 5.000, mas ainda não consegui capturar as vulnerabilidades necessárias para o pacote. O bug acima mencionado é bastante interessante e perigoso, todo o subdomínio foi colocado offline imediatamente após o relatório, talvez no futuro eu abro o relatório em hackerone.com/w2w, se o programa se tornar público.
Uma semana depois, os resultados do script para detecção de conteúdo foram verificados, onde o ponto de extremidade / verificação foi encontrado, ao qual eu não atribuí uma importância particular a princípio, mas ainda assim defini o script - o subdiretório / selection / login foi encontrado. Após a transição, a página /verification/login/?redirect_uri=https://vulnerabledomain.com foi exibida, redirecionada para o valor redirect_uri após o logon ou imediatamente redirecionada se houver uma sessão. Depois de voar para o invasor, um desvio de proteção de redirecionamento aberto foi descoberto - vulnerabledomain.com@anotherdomain.com. Tentei desenrolar o bug no XSS - a carga útil do javascript: alert (1) falhou, javascript: alert (1) // também. Mas a carga útil do javascript: // https: //vulnerablesite.com/%250A1? Alert (1): 0 disparou, porque devido à presença de
vulnerablesite.com , o parâmetro passou na validação da lista branca.
Depois de passar freneticamente o mouse pela janela de notificação (eu sempre faço), imediatamente comecei a trabalhar no meu XSS baseado em cookie. Usando javascript: https: //vulnerabledomain.com/%0A1? Document% 2ecookie% 20% 3d% 20% 27SID% 3d137gf6g67f76fg6766123% 5c% 27-alert% 28document% 2edomain% 29-% 5c% 27% 3b% 20expires% 3dFri% 2c% 203% 20Aug% 202019% 2020% 3a47% 3a11% 20UTC% 3b% 20caminha% 3d% 2f% 3b% 20domínio% 3d% 2evulnerabledomain% 2ecom% 3b% 27% 3a0 O cookie foi instalado com sucesso em * .vulnerabledomain.com . Depois de ir para a página com o cookie, o alerta precioso decolou! Duplo XSS, felicidades! :) Complementei o relatório e esperei uma resposta.
No mesmo dia, “captura boa” voou do trio (se você pode chamar assim), e a recompensa foi paga. Deus abençoe as empresas que pagam na triagem!
Para o XSS baseado em DOM, com o qual eu instalei o cookie, a recompensa também chegou.
Resultados do teste
$ 1000 + $ 1000 + $ 200 (OR) + $ 100 (OR) =
$ 2300Este programa está em funcionamento há mais de um ano, mas em menos de um mês eu consegui ocupar o primeiro lugar e testar bastante - tentei fase da maioria dos pontos de extremidade, avalie sua reação, entenda como o site funciona e até testei o aplicativo de desktop. Este programa de recompensa de bugs se tornou um dos mais amados do HackerOne. Espero que você também um dia encontre o mesmo! :)
Além disso, foi esse programa que me deu um novo impulso (mail.ru - o primeiro), - com ele cheguei a 2500 reputação (olá moletom com capuz) e cheguei ao 36º lugar no ranking de reputação em 90 dias, o que deve dar novos apelos . Embora pareça que os enxertos chegam independentemente da presença na tabela de classificação, muitas vezes eu cancelo os enxertos antigos e espero por novos na fila.
Breve resumo
- O XSS baseado em cookie é totalmente explorável. Se você tentar se aprofundar um pouco mais, poderá obter uma recompensa em vez de n / a, destruindo o sinal e -5 de reputação.
- Se o programa for antigo, isso não significa que não haverá vulnerabilidades nele. Se os frutos ficarem pendurados na árvore por um longo período, eles serão colhidos e colhidos imediatamente (aquisições de subdomínios, etc.). Outras frutas continuam pendendo, mas mais altas. Para obtê-los, você precisa fazer algum esforço.
- Às vezes, é melhor focar em um programa por um longo tempo, encontrar o maior número possível de vulnerabilidades e monitorá-lo. É melhor encontrar o programa que você preferir e quebrá-lo.
- A perseverança e o desejo de entender como um aplicativo Web funciona, bem como certas funcionalidades e sua interação um com o outro, é a chave para a busca bem-sucedida de vulnerabilidades em uma recompensa por bug.
Se você quiser acompanhar os meus artigos e notícias mais recentes, aconselho a se inscrever no canal de telegrama / twitter, cujos links podem ser encontrados abaixo.