Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 13:43:24 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/hacking-with-cookies/README.md

20 KiB
Raw Blame History

Hacking de Cookies

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

Encontre vulnerabilidades que são mais importantes para que você possa corrigi-las mais rapidamente. O Intruder rastreia sua superfície de ataque, executa varreduras proativas de ameaças, encontra problemas em toda a sua pilha de tecnologia, desde APIs até aplicativos da web e sistemas em nuvem. Experimente gratuitamente hoje.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

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 os subdomínios são sempre incluídos. Portanto, especificar Domain é menos restritivo do que omiti-lo. No entanto, pode ser útil quando os 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 na URL solicitada para enviar o cabeçalho Cookie. O caractere %x2F ("/") é considerado um separador de diretório, e subdiretórios também são correspondidos.

Ordem

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

  • Aquele com o caminho mais longo que corresponde ao caminho da 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. Ele tem 3 valores possíveis:

  • Strict: 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.
  • None: O cookie é enviado de qualquer domínio de terceiros
Tipo de Solicitação Exemplo de Código Cookies Enviados Quando
Link <a href="..."></a> NotSet*, Lax, None
Prerender <link rel="prerender" href=".."/> NotSet*, Lax, None
Formulário GET <form method="GET" action="..."> NotSet*, Lax, None
Formulário POST <form method="POST" action="..."> NotSet*, None
iframe <iframe src="..."></iframe> NotSet*, None
AJAX $.get("...") NotSet*, None
Imagem <img src="..."> NetSet*, None

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

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

Flags de Cookies

HttpOnly

Isso impede 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 essa página e roubar os cookies da resposta (verifique um exemplo em https://hackcommander.github.io/pentesting-article-1/)
  • Isso pode ser burlado com solicitações TRACE HTTP como resposta do servidor (se esse método HTTP estiver disponível), os cookies enviados serão refletidos. Essa técnica é chamada de Cross-Site Tracking.
  • Essa técnica é evitada por navegadores modernos que não permitem o envio de uma solicitação TRACE a partir do JS. No entanto, foram encontradas algumas formas de burlar isso em software específico, como enviar \r\nTRACE em vez de TRACE para o IE6.0 SP2.
  • Outra forma é a exploração de vulnerabilidades zero/dia dos navegadores.
  • É possível sobrescrever cookies HttpOnly realizando um ataque de overflow do Cookie Jar:

{% content-ref url="cookie-jar-overflow.md" %} cookie-jar-overflow.md {% endcontent-ref %}

Secure

A solicitação enviará o cookie apenas em uma solicitação HTTP se a solicitação for transmitida por um canal seguro (geralmente HTTPS).

Prefixos de Cookies

Prefixo __Secure-: deve ser definido com a flag secure de uma página segura (HTTPS).

Prefixo __Host-: deve ser definido com a flag secure, deve ser de uma página segura (HTTPS), não deve ter um domínio especificado (e, portanto, não é enviado para subdomínios) e o caminho deve ser /.

Cookies com prefixo __Host- não podem ser enviados para superdomínios (cookies de subdomínios para domínios) ou subdomínios (cookies de domínios para subdomínios), então, se você deseja isolar os cookies de sua aplicação, prefixar tudo com __Host- não é uma má ideia.

Ataques a Cookies

Se você encontrar algum tipo de cookie personalizado contendo dados sensíveis (sessionID, nome de usuário, e-mails, etc.), definitivamente deve tentar explorá-lo.

Decodificando o cookie

Se o cookie estiver usando alguma codificação base (como Base64) ou similar, você pode ser capaz de decodificá-lo, alterar o conteúdo e se passar por usuários arbitrários.

Sequestro de sessão

Roubar um cookie e usá-lo para se passar pelo usuário dentro de um aplicativo.

Fixação de sessão

O atacante obtém um cookie de uma página da web e envia um link para a vítima fazer login usando o mesmo cookie. Se o cookie não for alterado quando um usuário faz login, isso pode ser útil porque o atacante pode se passar pelo usuário por meio de um cookie.

Se você encontrou um XSS em um subdomínio ou controla um subdomínio, leia:

{% content-ref url="cookie-tossing.md" %} cookie-tossing.md {% endcontent-ref %}

Doação de sessão

O atacante envia sua própria sessão para a vítima. A vítima verá que já está conectada e suporá que está dentro de sua conta, mas as ações serão realizadas dentro da conta do atacante.

Se você encontrou um XSS em um subdomínio ou controla um subdomínio, leia:

{% content-ref url="cookie-tossing.md" %} cookie-tossing.md {% endcontent-ref %}

Cookie JWT

Clique no link anterior para acessar uma página explicando possíveis falhas no JWT.

Cookie vazio

Os navegadores permitem um cookie com um nome vazio.

document.cookie = "a=v1"
document.cookie = "=test value;" // empty name
document.cookie = "b=v2"

Isso resulta no cabeçalho do 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 sem nome vazio, resultará no cabeçalho do cookie enviado:

a=b;

Significado, 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, o 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 da 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 interpretar incorretamente as strings de cookies devido ao suporte remanescente para o RFC2965, um mecanismo de citação de cookies desatualizado que usa o RFC2616 para a definição de uma string entre aspas.

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

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

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

Esses servidores interpretam esses valores 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 obtiver 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 http.cookie.SimpleCookie e http.cookie.BaseCookie da biblioteca padrão do Python, foram encontrados analisando incorretamente os 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 Python's SimpleCookie e BaseCookie 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 para a segurança. Por exemplo, se um aplicativo da web usa proteção CSRF baseada em cookies, um invasor pode injetar um cookie falsificado de CSRF-token para contornar essa proteção. Além disso, o último cookie com o mesmo nome nos pacotes http.cookie do Python substitui os anteriores, tornando esse tipo de ataque especialmente fácil.

Além disso, a falsificação dos 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 cookies 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 cookies vulneráveis

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 contém alguma informação 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 se a opção "lembrar-me" existe e veja como ela funciona. Se existir e puder ser vulnerável, sempre use o cookie de lembrar-me sem nenhum outro cookie.
  • Verifique se o cookie anterior continua funcionando mesmo depois de 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, então 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 pertencente ao "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 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. Nesse caso, a integridade do valor é a assinatura criada usando CBC com o mesmo valor. Como é recomendado usar um vetor IV nulo, esse tipo de verificação de integridade pode ser vulnerável.

O ataque

  1. Obtenha a assinatura do nome de usuário administ = t
  2. Obtenha a assinatura do nome de usuário rator\x00\x00\x00 XOR t = t'
  3. Defina 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 deve 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 o ECB criptografa com a mesma chave em 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). Portanto, sabendo como um monte de "a" é criptografado, você pode criar um nome de usuário: "a"*(tamanho do bloco)+"admin". Em seguida, 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

Encontre vulnerabilidades que são mais importantes para que você possa corrigi-las mais rapidamente. O Intruder rastreia sua superfície de ataque, executa varreduras proativas de ameaças, encontra problemas em toda a sua pilha de tecnologia, desde APIs até aplicativos da web e sistemas em nuvem. Experimente gratuitamente hoje.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

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