Fala pessoal beleza?
No artigo de hoje vamos analisar um report que fez o Gitlab pagar um bounty de $1000 ao hunter chaosbolt por uma falha encontrada de open redirect, para quem não conhece essa vulnerabilidade é muito simples de ser entendida, mas o modo como foi encontrada e o valor do bounty me chamaram muito a atenção, então resolvi compartilhar com vocês.
O objetivo desta vulnerabilidade é conseguir redirecionar o usuário para um site malicioso, com isso pode-se criar uma página falsa e pedir para que ele faça login novamente, ou pedir os dados de seu cartão de crédito.
O seu escopo e aplicação são muito abrangentes, existem até casos em que esta falha pode escalar para um cross site scripting, mas vamos conversar sobre isso em outro artigo.
Na maioria das vezes, ela costuma ser encontrada em parâmetros de redirecionamento que não são devidamente filtrados, como por exemplo
https://example.com/login?redirect=https://evil.com ou https://example.com/?domain=https://evil.com
No primeiro exemplo se o usuário realizasse login com êxito ele seria redirecionado para https://evil.com que poderia pedir suas credenciais novamente
O mais interessante neste caso é que ela foi encontrada por meio de um iframe que tinha muitas permissões.
Para entender isso, vamos entender algumas coisas sobre essa tag hmtl quando enquadramos uma página em nosso site, existem um conjunto de regras que não podem ser violadas uma delas é que o iframe, que neste caso chamaremos filho, não pode se comunicar diretamente com a página pai, o inverso também ocorre.
Podemos comprovar isso com um exemplo, imagine que temos uma página com o seguinte código HTML
<!DOCTYPE html>
<html>
<body>
<iframe src="http://ruvlolmail.temp.swtest.ru/toplevel.html" id="child" />
<script>
var a = document.getElementById("child").contentWindow.document;
console.log(a.body.innerHTML);
</script>
</body>
</html>Caso tentemos pegar o código HTML contido dentro no body do iframe, o resultado no console do devTools é algo parecido com
Esse retorno basicamente nos diz que não podemos manipular os dados enquadrados pois estamos acessando-o de uma origem diferente
Neste caso, localhost está tentando acessar dados de ruvlomail
O sistema que não permite essa troca de informações é chamada de Same-Origin Policy ou SOP, ela é usada como mecanismo de segurança e restringe como um documento ou script carregado por uma origem pode interagir com um recurso de outra origem.
Entretanto, há um modo do filho manipular a página pai, e foi isso que nosso hunter usou para encontrar a vulnerabilidade no Gitlab.
Mas para entender isto devemos saber que o atributo do Iframe chamado sandbox permite que configuremos as restrições do conteúdo enquadrado, quando ele estiver configurado como allow-top-navigation o iframe pode manipular o conteúdo top-level, então basta inserir como código do iframe
<!DOCTYPE html>
<html>
<head>
</head>
<body>
<script>
top.window.location = "https://evil.com"
</script>
</body>
</html>Assim, ele pode manipular a janela principal e nos redirecionar para evil.
No caso do report, o hunter percebeu que o Gitlab usava uma WEBIDE online para edição de código ela funcionava por meio de um iframe que facilitava a edição do código, e advinhem?
Ele permitia este tipo de manipulação , então, chaosbolt resolveu testá-lo para ver se conseguia se redirecionar para outra págiina para isto ele executou o seguinte código dentro do iframe:
window.open("https://evil.com", "_top")Ao clicar em live preview o resultado foi esse:
Após o report da falha o time de segurança do GitLab demorou certa de 4 meses para lançar um patch que corrigisse a falha, já o chaosbolt foi remunerado pouco tempo depois
Caso esteja pensando em procurar por esta falha em cenários parecidos, tente imaginar como você pode “conversar” com o Iframe é possível inserir dados diretamente nele como é o caso desse report?
- Você pode enviar postMessage para ele?
- O Iframe aponta para um domínio expirado?
Todas essas informações são muito importantes para que você consiga executar com sucesso essa falha.