Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 21:53:54 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/hacking-with-cookies/README.md
Translator workflow c928d8e52e Translated to Portuguese
2023-06-06 18:56:34 +00:00

16 KiB
Raw Blame History

Hacking de Cookies

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Atributos de Cookies

Expires & Max-Age

  • Expires define uma data de expiração para quando um cookie será excluído
  • Max-age define o tempo em segundos para quando um cookie será excluído (use isso, não é mais 2009)

Domain

O atributo Domain especifica quais hosts podem receber um cookie. Se não especificado, o atributo padrão é o mesmo host que definiu o cookie, excluindo subdomínios. Se Domain for especificado, então subdomínios são sempre incluídos. Portanto, especificar Domain é menos restritivo do que omiti-lo. No entanto, pode ser útil quando subdomínios precisam compartilhar informações sobre um usuário.

Por exemplo, se você definir Domain=mozilla.org, os cookies estarão disponíveis em subdomínios como developer.mozilla.org. Mas se você não definir, o cookie não será enviado para subdomínios.

Se um subdomínio sub.example.com definir um cookie com o atributo domain de .example.com, ele será enviado em solicitações para o domínio pai.

Path

O atributo Path indica um caminho de URL que deve existir no URL solicitado para enviar o cabeçalho Cookie. O caractere %x2F ("/") é considerado um separador de diretório, e subdiretórios também correspondem.

Ordem

Quando 2 cookies têm o mesmo nome, aquele que é enviado é:

  • Aquele com o caminho mais longo correspondente ao caminho do URL
  • O mais recente se ambos tiverem o mesmo caminho

SameSite

Isso indicará ao navegador se o cookie pode ser enviado de outros domínios. Tem 3 valores possíveis:

  • Estrito: o cookie não será enviado junto com uma solicitação por sites de terceiros.
  • Lax: o cookie será enviado junto com a solicitação GET iniciada por sites de terceiros.
  • Nenhum: o cookie é enviado de qualquer domínio de terceiros
Tipo de solicitação Código de exemplo Cookies enviados quando
Link <a href="..."></a> Não definido*, Lax, Nenhum
Prerender <link rel="prerender" href=".."/> Não definido*, Lax, Nenhum
Formulário GET <form method="GET" action="..."> Não definido*, Lax, Nenhum
Formulário POST <form method="POST" action="..."> Não definido*, Nenhum
iframe <iframe src="..."></iframe> Não definido*, Nenhum
AJAX $.get("...") Não definido*, Nenhum
Imagem <img src="..."> NetSet*, Nenhum

Tabela de Invicti e ligeiramente modificada.
Um cookie com o atributo SameSite irá mitigar ataques CSRF onde é necessária uma sessão iniciada.

*Observe que a partir do Chrome80 (fev/2019) o comportamento padrão de um cookie sem um atributo samesite de cookie será lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Observe que temporariamente, após a aplicação dessa alteração, os cookies sem uma política SameSite no Chrome serão tratados como Nenhum durante os primeiros 2 minutos e depois como Lax para solicitações POST entre sites de nível superior.

Flags de Cookies

HttpOnly

Isso evita que o cliente acesse o cookie (por exemplo, via Javascript: document.cookie)

Bypasses

  • Se a página estiver enviando os cookies como resposta de uma solicitação (por exemplo, em uma página PHPinfo), é possível abusar do XSS para enviar uma solicitação para esta página e roubar os cookies da resposta (verifique um exemplo em https://hackcommander.github.io/pentesting-article-1/)
  • Isso pode ser contornado com solicitações HTTP TRACE se a resposta do servidor refletir os cookies enviados (se este método HTTP estiver disponível). Essa técnica é chamada de Cross-Site Tracking.
    • Essa técnica é evitada por navegadores modernos por não permitir o envio de uma solicitação TRACE de JS. No entanto, alguns contornos para isso foram encontrados em software específico, como o envio de `\
document.cookie = "a=v1"
document.cookie = "=test value;" // empty name
document.cookie = "b=v2"

Isso resulta no cabeçalho de cookie enviado:

a=v1; test value; b=v2;

Mais interessante ainda, se você tiver um vetor que de alguma forma permita definir o cookie vazio, você pode controlar qualquer outro cookie:

function setCookie(name, value) {
    document.cookie = `${name}=${value}`;
}

setCookie("", "a=b"); // this sets the empty cookie to a=b

Embora internamente no navegador, isso seja definido como o cookie nomeado vazio, resultará no cabeçalho do cookie enviado:

a=b;

Significando que todo servidor web irá interpretá-lo como o cookie a sendo definido com o valor b.

Bug do Chrome - corrupção do document.cookie

Se um ponto de código de substituto Unicode estiver em um cookie definido, document.cookie será permanentemente corrompido e retornará uma string vazia.

document.cookie
// "a=b;"
document.cookie = "\ud800=meep";
document.cookie
// ""

Contrabando de Cookies

Vários servidores web, incluindo os servidores Java Jetty, TomCat, Undertow e o framework web Python Zope, bem como servidores/frameworks web Python como cherrypy, web.py, aiohttp server, bottle e webob, são encontrados para analisar incorretamente as strings de cookie devido ao suporte restante para RFC2965, um mecanismo de citação de cookie desatualizado que usa RFC2616 para uma definição de string citada.

Especificamente, esses servidores continuam lendo uma string de cookie quando encontram um valor de cookie entre aspas duplas (dquoted), mesmo que um ponto e vírgula seja encontrado. Isso é problemático porque pontos e vírgulas devem separar pares chave-valor na string de cookie.

Por exemplo, se um navegador envia três cookies, RENDER_TEXT, JSESSIONID e ASDF:

RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";

esses servidores os interpretam como parte de um único valor de cookie em vez de três cookies separados.

Isso leva a um risco de segurança: se um invasor ganhar acesso de script entre sites (XSS), ele pode usar esse bug para extrair cookies sensíveis como cookies HttpOnly.

Injeção de Cookie

Muitos servidores da web, incluindo o Undertow do Java, o Zope do Python e aqueles que usam o http.cookie.SimpleCookie e http.cookie.BaseCookie do stdlib do Python, foram encontrados para analisar incorretamente cookies, usando delimitadores errados para iniciar o próximo par de nome/valor do cookie. Isso permite que um invasor falsifique vários cookies enquanto controla apenas um valor de cookie.

No caso do Undertow, ele começa a analisar o próximo cookie imediatamente após o final de um valor de cookie entre aspas, sem esperar por um ponto e vírgula:

LANGUAGE="en-us" CSRF_TOKEN="SPOOFED_VALUE"

Zope começa a analisar o próximo cookie em uma vírgula:

LANGUAGE=en-us,CSRF_TOKEN=SPOOFED_VALUE

E o SimpleCookie e o BaseCookie do Python imediatamente começam a analisar o próximo cookie em um caractere espaço.

LANGUAGE=en-us CSRF_TOKEN=SPOOFED_VALUE

Como resultado, servidores como cherrypy, web.py, servidor aiohttp, bottle e webob (Pyramid, TurboGears) são todos vulneráveis a esse tipo de ataque.

Esse problema apresenta implicações significativas de segurança. Por exemplo, se um aplicativo da web usa proteção CSRF baseada em cookie, um invasor pode injetar um cookie de token CSRF falsificado para contornar essa proteção. Além disso, o último nome de cookie duplicado nos pacotes http.cookie do Python substitui todos os anteriores, tornando esse tipo de ataque especialmente fácil.

Além disso, a falsificação de cookies __Secure- e __Host- pode ser explorada em um contexto inseguro. Além disso, em uma configuração em que os cookies são passados para um servidor backend, a injeção de cookie pode levar a bypasses de autorização se o servidor backend for suscetível a falsificação, mas o servidor frontend não for.

Verificações extras de vulnerabilidade de cookies

Verificações básicas

  • O cookie é o mesmo toda vez que você faz login.
  • Faça logout e tente usar o mesmo cookie.
  • Tente fazer login com 2 dispositivos (ou navegadores) na mesma conta usando o mesmo cookie.
  • Verifique se o cookie tem alguma informação nele e tente modificá-lo.
  • Tente criar várias contas com nomes de usuário quase iguais e verifique se você pode ver semelhanças.
  • Verifique a opção "lembrar-me" se ela existir para ver como funciona. Se existir e puder ser vulnerável, sempre use o cookie de lembrar-me sem nenhum outro cookie.
  • Verifique se o cookie anterior funciona mesmo depois de você alterar a senha.

Ataques avançados de cookies

Se o cookie permanecer o mesmo (ou quase o mesmo) quando você fizer login, isso provavelmente significa que o cookie está relacionado a algum campo da sua conta (provavelmente o nome de usuário). Então você pode:

  • Tente criar muitas contas com nomes de usuário muito semelhantes e tente adivinhar como o algoritmo está funcionando.
  • Tente forçar o nome de usuário. Se o cookie salvar apenas como um método de autenticação para o seu nome de usuário, você pode criar uma conta com o nome de usuário "Bmin" e forçar cada bit do seu cookie porque um dos cookies que você tentará será o que pertence a "admin".
  • Tente o Padding Oracle (você pode descriptografar o conteúdo do cookie). Use o padbuster.

Padding Oracle - Exemplos do Padbuster

padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
# When cookies and regular Base64
padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf

# If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example:
padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2

O Padbuster fará várias tentativas e perguntará qual é a condição de erro (aquela que não é válida).

Em seguida, ele começará a descriptografar o cookie (isso pode levar vários minutos).

Se o ataque for bem-sucedido, você poderá tentar criptografar uma string de sua escolha. Por exemplo, se você quiser criptografar user=administrador.

padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator

Essa execução irá fornecer o cookie corretamente criptografado e codificado com a string user=administrator dentro.

CBC-MAC

Talvez um cookie possa ter algum valor e ser assinado usando CBC. Então, a integridade do valor é a assinatura criada usando CBC com o mesmo valor. Como é recomendado usar um vetor nulo como IV, esse tipo de verificação de integridade pode ser vulnerável.

O ataque

  1. Obter a assinatura do nome de usuário administ = t
  2. Obter a assinatura do nome de usuário rator\x00\x00\x00 XOR t = t'
  3. Definir no cookie o valor administrator+t' (t' será uma assinatura válida de (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00

ECB

Se o cookie for criptografado usando ECB, ele pode ser vulnerável.
Quando você faz login, o cookie que você recebe tem que ser sempre o mesmo.

Como detectar e atacar:

Crie 2 usuários com dados quase iguais (nome de usuário, senha, e-mail, etc.) e tente descobrir algum padrão dentro do cookie fornecido.

Crie um usuário chamado, por exemplo, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" e verifique se há algum padrão no cookie (como ECB criptografa com a mesma chave a cada bloco, os mesmos bytes criptografados podem aparecer se o nome de usuário for criptografado).

Deve haver um padrão (com o tamanho de um bloco usado). Então, sabendo como um monte de "a" é criptografado, você pode criar um nome de usuário: "a"*(tamanho do bloco)+"admin". Então, você pode excluir o padrão criptografado de um bloco de "a" do cookie. E você terá o cookie do nome de usuário "admin".

Referências

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥