Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-14 17:07:34 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/hacking-with-cookies
History
HackCommander b0a622ec41 Update /pentesting-web/hacking-with-cookies/README.md.
2022-11-13 02:25:30 +01:00
..
cookie-bomb.md Update cookie-bomb.md 2022-10-12 08:05:30 +06:00
cookie-jar-overflow.md Update cookie-jar-overflow.md 2022-10-12 07:51:47 +06:00
cookie-tossing.md Update cookie-tossing.md 2022-10-12 07:33:31 +06:00
README.md Update /pentesting-web/hacking-with-cookies/README.md. 2022-11-13 02:25:30 +01:00

README.md

Cookies Hacking

Support HackTricks and get benefits!

Hacking cookies

If you find some kind of custom cookie containing sensitive data (sessionID, username, emails, etc.) you should definitely try to exploit it

Decoding the cookie

If the cookie is using some Base encoding (like Base64) or similar you may be able to decode it, change the content and impersonate arbitrary users.

Session Hijacking

Steal a cookie and use it to impersonate the user inside an application

Session fixation

The attacker gets a cookie from a web page and sends a link to the victim to login using the very same cookie. If the cookie is not changed when a user logs in, this could be useful because the attacker could be able to impersonate the user through a cookie.

If you found an XSS in a subdomain or you control a subdomain, read:

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

Session donation

The attacker sends his own session to the victim. The victim will see that he is already logged in and will suppose that he is inside his account but the actions will be performed inside the attacker's account.

If you found an XSS in a subdomain or you control a subdomain, read:

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

JWT Cookie

Click on the previous link to access a page explaining possible flaws in JWT.

Checking Cookies

Basic checks

  • The cookie is the same every time you login.
  • Log out and try to use the same cookie.
  • Try to log in with 2 devices (or browsers) to the same account using the same cookie.
  • Check if the cookie has any information in it and try to modify it
  • Try to create several accounts with almost the same username and check if you can see similarities.
  • Check the "remember me" option if it exists to see how it works. If it exists and could be vulnerable, always use the cookie of remember me without any other cookie.
  • Check if the previous cookie works even after you change the password.

Advanced cookies attacks

If the cookie remains the same (or almost) when you log in, this probably means that the cookie is related to some field of your account (probably the username). Then you can:

  • Try to create a lot of accounts with usernames very similar and try to guess how the algorithm is working.
  • Try to bruteforce the username. If the cookie saves only as an authentication method for your username, then you can create an account with username "Bmin" and bruteforce every single bit of your cookie because one of the cookies that you will try will the one belonging to "admin".
  • Try Padding Oracle (you can decrypt the content of the cookie). Use padbuster.

Padding Oracle - Padbuster examples

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

Padbuster will make several attempts and will ask you which condition is the error condition (the one that is not valid).

Then it will start decrypting the cookie (it may take several minutes)

If the attack has been successfully performed, then you could try to encrypt a string of your choice. For example, if you would want to encrypt user=administrator

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

This execution will give you the cookie correctly encrypted and encoded with the string user=administrator inside.

CBC-MAC

Maybe a cookie could have some value and could be signed using CBC. Then, the integrity of the value is the signature created by using CBC with the same value. As it is recommended to use as IV a null vector, this type of integrity checking could be vulnerable.

The attack

  1. Get the signature of username administ = t
  2. Get the signature of username rator\x00\x00\x00 XOR t = t'
  3. Set in the cookie the value administrator+t' (t' will be a valid signature of (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00

ECB

If the cookie is encrypted using ECB it could be vulnerable.
When you log in the cookie that you receive has to be always the same.

How to detect and attack:

Create 2 users with almost the same data (username, password, email, etc.) and try to discover some pattern inside the given cookie

Create a user called for example "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" and check if there is any pattern in the cookie (as ECB encrypts with the same key every block, the same encrypted bytes could appear if the username is encrypted).

There should be a pattern (with the size of a used block). So, knowing how are a bunch of "a" encrypted you can create a username: "a"*(size of the block)+"admin". Then, you could delete the encrypted pattern of a block of "a" from the cookie. And you will have the cookie of the username "admin".

Cookies Attributes

Expires & Max-Age

  • Expires sets an expiry date for when a cookie gets deleted
  • Max-age sets the time in seconds for when a cookie will be deleted (use this, it’s no longer 2009)

Domain

The Domain attribute specifies which hosts can receive a cookie. If unspecified, the attribute defaults to the same host that set the cookie, excluding subdomains. If Domain is specified, then subdomains are always included. Therefore, specifying Domain is less restrictive than omitting it. However, it can be helpful when subdomains need to share information about a user.

For example, if you set Domain=mozilla.org, cookies are available on subdomains like developer.mozilla.org. But if you don't, the cookie won't be sent to subdomains.

Path

The Path attribute indicates a URL path that must exist in the requested URL to send the Cookie header. The %x2F ("/") character is considered a directory separator, and subdirectories match as well.

SameSite

This will indicate to the browser if the cookie can be sent from other domains. It has 3 possible values:

  • Strict: The cookie will not be sent along with a request by third party websites.
  • Lax: The cookie will be sent along with the GET request initiated by third party websites.
  • None: The cookie is sent from any third party domain
Request Type Example Code Cookies Sent When
Link <a href="..."></a> NotSet*, Lax, None
Prerender <link rel="prerender" href=".."/> NotSet*, Lax, None
Form GET <form method="GET" action="..."> NotSet*, Lax, None
Form POST <form method="POST" action="..."> NotSet*, None
iframe <iframe src="..."></iframe> NotSet*, None
AJAX $.get("...") NotSet*, None
Image <img src="..."> NetSet*, None

Table from Invicti and slightly modified.
A cookie with SameSite attribute will mitigate CSRF attacks where a logged session is needed.

*Notice that from Chrome80 (feb/2019) the default behaviour of a cookie without a cookie samesite attribute will be lax (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Notice that temporary, after applying this change, the cookies without a SameSite policy in Chrome will be treated as None during the first 2 minutes and then as Lax for top-level cross-site POST request.

Cookies Flags

HttpOnly

This avoids the client to access the cookie (Via Javascript for example: document.cookie)

Bypasses

  • Through the PHP info page if this is disclosed:

    https://hackcommander.github.io/pentesting-article-1/

  • This could be Bypassed with TRACE HTTP requests as the response from the server (if this HTTP method is available) will reflect the cookies sent. This technique is called Cross-Site Tracking.

    • This technique is avoided by modern browsers by not permitting sending a TRACE request from JS. However, some bypasses to this have been found in specific software like sending \r\nTRACE instead of TRACE to IE6.0 SP2.

  • Another way is the exploitation of zero/day vulnerabilities of the browsers.

  • It's possible to overwrite HttpOnly cookies by performing a Cookie Jar overflow attack:

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

Secure

The request will only send the cookie in an HTTP request only if the request is transmitted over a secure channel (typically HTTPS).

Support HackTricks and get benefits!