Race Condition
Last updated
Last updated
Dünyanın en gelişmiş topluluk araçlarıyla desteklenen iş akışlarını kolayca oluşturmak ve otomatikleştirmek için Trickest kullanın. Bugün Erişim Alın:
Bu tekniği derinlemesine anlamak için orijinal raporu https://portswigger.net/research/smashing-the-state-machine adresinde kontrol edin.
Race condition'ları avantaja çevirmenin ana engeli, birden fazla isteğin işleme sürelerinde çok az farkla—idealde, 1ms'den az—aynı anda işlenmesini sağlamaktır.
İstekleri Senkronize Etmek için bazı teknikler burada bulunmaktadır:
HTTP/2: Tek bir TCP bağlantısı üzerinden iki isteğin gönderilmesini destekler, ağ jitter etkisini azaltır. Ancak, sunucu tarafındaki varyasyonlar nedeniyle, iki istek tutarlı bir race condition istismarına yeterli olmayabilir.
HTTP/1.1 'Son-Bayt Senkronizasyonu': 20-30 isteğin çoğu kısmının önceden gönderilmesini sağlar, küçük bir parçayı saklayarak, bu parça daha sonra birlikte gönderilir ve sunucuya eşzamanlı varış sağlanır.
Son-Bayt Senkronizasyonu için Hazırlık şunları içerir:
Akışı sonlandırmadan son bayt hariç başlık ve gövde verilerini göndermek.
İlk gönderimden sonra 100ms beklemek.
Son çerçeveleri gruplamak için Nagle algoritmasını kullanmak üzere TCP_NODELAY'i devre dışı bırakmak.
Bağlantıyı ısıtmak için ping atmak.
Saklanan çerçevelerin sonraki gönderimi, Wireshark ile doğrulanabilir şekilde tek bir pakette varış sağlamalıdır. Bu yöntem, genellikle RC saldırılarında yer almayan statik dosyalara uygulanmaz.
Hedefin mimarisini anlamak çok önemlidir. Ön uç sunucular, istekleri farklı yönlendirebilir ve zamanlamayı etkileyebilir. Önleyici sunucu tarafı bağlantı ısıtma, önemsiz istekler aracılığıyla istek zamanlamasını normalleştirebilir.
PHP'nin oturum yöneticisi gibi çerçeveler, istekleri oturum bazında serileştirir ve potansiyel olarak zafiyetleri gizleyebilir. Her istek için farklı oturum jetonları kullanmak bu sorunu aşabilir.
Bağlantı ısıtma etkili değilse, web sunucularının hız veya kaynak limit gecikmelerini kasıtlı olarak bir dizi sahte istekle tetiklemek, sunucu tarafında race condition'lara uygun bir gecikme oluşturarak tek paket saldırısını kolaylaştırabilir.
Tubo Intruder - HTTP2 tek-paket saldırısı (1 uç nokta): İsteği Turbo intruder'a (Extensions
-> Turbo Intruder
-> Send to Turbo Intruder
) gönderebilirsiniz, istekte %s
için brute force yapmak istediğiniz değeri değiştirebilirsiniz, örneğin csrf=Bn9VQB8OyefIs3ShR2fPESR0FzzulI1d&username=carlos&password=%s
ve ardından açılır menüden examples/race-single-packer-attack.py
'yi seçin:
Farklı değerler gönderecekseniz, panodan bir kelime listesi kullanan bu kodla kodu değiştirebilirsiniz:
Eğer web HTTP2'yi desteklemiyorsa (sadece HTTP1.1) Engine.BURP2
yerine Engine.THREADED
veya Engine.BURP
kullanın.
Tubo Intruder - HTTP2 tek paketli saldırı (Birçok uç nokta): Eğer 1 uç noktaya bir istek göndermeniz ve ardından RCE'yi tetiklemek için diğer uç noktalara birden fazla istek göndermeniz gerekiyorsa, race-single-packet-attack.py
scriptini şu şekilde değiştirebilirsiniz:
Ayrıca Burp Suite'teki yeni 'Grupları paralel gönder' seçeneği aracılığıyla Repeater'da da mevcuttur.
Limit-aşımı için gruba aynı isteği 50 kez ekleyebilirsiniz.
Bağlantı ısınması için grubun başına web sunucusunun bazı statik olmayan kısımlarına istekler ekleyebilirsiniz.
Bir isteği işleme ile diğerini işleme arasında süreci geciktirmek için, her iki isteğin arasına ekstra istekler ekleyebilirsiniz.
Çoklu uç nokta RC için, gizli duruma giden isteği göndermeye başlayabilir ve ardından gizli durumu istismar eden 50 isteği hemen arkasından gönderebilirsiniz.
Otomatik python scripti: Bu scriptin amacı, bir kullanıcının e-posta adresini değiştirirken sürekli olarak doğrulamak ve yeni e-posta adresinin doğrulama token'ı son e-posta adresine ulaşana kadar bunu yapmaktır (bu, kodda bir e-posta adresinin değiştirilip doğrulamanın eski adrese gönderilebildiği bir RC görüldüğü içindir çünkü e-posta adresini gösteren değişken zaten ilk e-posta ile doldurulmuştu). "objetivo" kelimesi alınan e-postalarda bulunduğunda, değiştirilmiş e-posta adresinin doğrulama token'ını aldığımızı biliyoruz ve saldırıyı sonlandırıyoruz.
Orijinal araştırmada bu saldırının 1,500 baytlık bir sınırı olduğu açıklanmıştır. Ancak, bu yazıda tek paket saldırısının 1,500 baytlık sınırlamasını IP katmanı parçalama (tek bir paketi birden fazla IP paketine bölme) kullanarak TCP'nin 65,535 B pencere sınırlamasına nasıl genişletilebileceği açıklanmıştır ve bunların farklı bir sırayla gönderilmesi, tüm parçalar sunucuya ulaşana kadar paketin yeniden birleştirilmesini engellemiştir. Bu teknik, araştırmacının yaklaşık 166ms içinde 10,000 istek göndermesine olanak tanımıştır.
Bu iyileştirmenin, aynı anda yüzlerce/binlerce paketin ulaşmasını gerektiren RC'de saldırıyı daha güvenilir hale getirdiğini unutmayın, ancak bazı yazılım sınırlamaları da olabilir. Apache, Nginx ve Go gibi bazı popüler HTTP sunucuları, SETTINGS_MAX_CONCURRENT_STREAMS
ayarını sırasıyla 100, 128 ve 250 olarak belirlemiştir. Ancak, NodeJS ve nghttp2 gibi diğerleri sınırsızdır.
Bu, temelde Apache'nin tek bir TCP bağlantısından yalnızca 100 HTTP bağlantısını dikkate alacağı anlamına gelir (bu RC saldırısını sınırlayarak).
Bu tekniği kullanan bazı örnekleri https://github.com/Ry0taK/first-sequence-sync/tree/main reposunda bulabilirsiniz.
Önceki araştırmadan önce, sadece paketleri mümkün olduğunca hızlı göndermeye çalışan bazı yükler kullanılıyordu.
Tekrar Edici: Önceki bölümden örneklere bakın.
Saldırgan: İsteği Saldırgana gönderin, Seçenekler menüsünde iş parçacığı sayısını 30 olarak ayarlayın ve yük olarak Null yükleri seçin ve 30 oluşturun.
Turbo Saldırgan
Python - asyncio
Bu, hareketi gerçekleştirebileceğiniz zaman sayısını sınırlayan yerlerde görünmeye başlayan zayıflıkların bulunduğu en temel yarış durumu türüdür. Örneğin, bir web mağazasında aynı indirim kodunu birkaç kez kullanmak. Çok basit bir örnek bu raporda veya bu hatada** bulunabilir.**
Bu tür saldırının birçok varyasyonu vardır, bunlar arasında:
Bir hediye kartını birden fazla kez kullanma
Bir ürünü birden fazla kez değerlendirme
Hesap bakiyenizden fazla nakit çekme veya transfer etme
Tek bir CAPTCHA çözümünü yeniden kullanma
Bir anti-brute-force hız limitini aşma
Karmaşık yarış durumlarını istismar etmek genellikle gizli veya istenmeyen makine alt durumlarıyla etkileşimde bulunmak için kısa fırsatları değerlendirmeyi içerir. İşte buna yaklaşmanın yolu:
Potansiyel Gizli Alt Durumları Belirleyin
Kullanıcı profilleri veya şifre sıfırlama süreçleri gibi kritik verileri değiştiren veya bunlarla etkileşime giren uç noktaları belirleyerek başlayın. Şuna odaklanın:
Depolama: Sunucu tarafında kalıcı verileri manipüle eden uç noktaları, istemci tarafında veri işleyenlerden daha fazla tercih edin.
Eylem: Mevcut verileri değiştiren işlemleri arayın; bunlar yeni veri ekleyenlere göre istismar edilebilir koşullar yaratma olasılığı daha yüksektir.
Anahtar: Başarılı saldırılar genellikle aynı tanımlayıcıya dayanan işlemleri içerir, örneğin, kullanıcı adı veya sıfırlama belirteci.
İlk Kez Test Yapın
Belirlenen uç noktaları yarış durumu saldırılarıyla test edin, beklenen sonuçlardan herhangi bir sapma olup olmadığını gözlemleyin. Beklenmedik yanıtlar veya uygulama davranışındaki değişiklikler bir zayıflığın sinyalini verebilir.
Zayıflığı Gösterin
Zayıflığı istismar etmek için gereken en az istek sayısını daraltın, genellikle sadece iki. Bu adım, hassas zamanlama gerektirdiğinden birden fazla deneme veya otomasyon gerektirebilir.
İsteklerin zamanlamasındaki hassasiyet, özellikle güvenlik belirteçleri için tahmin edilebilir yöntemler (örneğin, zaman damgaları) kullanıldığında zayıflıkları ortaya çıkarabilir. Örneğin, zaman damgalarına dayalı şifre sıfırlama belirteçleri oluşturmak, eşzamanlı istekler için aynı belirteçlerin oluşmasına neden olabilir.
İstismar Etmek İçin:
Eşzamanlı şifre sıfırlama istekleri yapmak için tek bir paket saldırısı gibi hassas zamanlama kullanın. Aynı belirteçler bir zayıflığın göstergesidir.
Örnek:
Aynı anda iki şifre sıfırlama belirteci isteyin ve bunları karşılaştırın. Eşleşen belirteçler, belirteç oluşturma sürecinde bir hatayı işaret eder.
Bunu denemek için PortSwigger Lab kontrol edin.
Bunu görmek için PortSwigger Lab kontrol edin, nasıl ödeme yapacağınızı ve ekstra bir ürünü ödemeden ekleyeceğinizi öğrenin.
Amaç, bir e-posta adresini doğrulamak ve aynı anda farklı birine değiştirmek; böylece platformun yeni değiştirilen e-postayı doğrulayıp doğrulamadığını öğrenmektir.
Bu araştırmaya göre, Gitlab bu şekilde bir ele geçirmeye karşı savunmasızdı çünkü bir e-posta için e-posta doğrulama belirtecini diğer e-postaya gönderebilir.
Bunu denemek için PortSwigger Lab kontrol edin.
Eğer 2 farklı yazma işlemi veri eklemek için kullanılıyorsa, veritabanına yalnızca ilk verinin yazıldığı küçük bir zaman dilimi vardır. Örneğin, bir kullanıcı oluştururken kullanıcı adı ve şifre yazılabilir ve ardından yeni oluşturulan hesabı onaylamak için belirteç yazılabilir. Bu, bir hesabı onaylamak için belirtecin null olduğu küçük bir zaman dilimi olduğu anlamına gelir.
Bu nedenle, bir hesap kaydetmek ve hemen onaylamak için boş bir belirteçle (token=
veya token[]=
veya başka bir varyasyon) birkaç istek göndermek, e-posta kontrolünüz olmayan bir hesabı onaylamanıza olanak tanıyabilir.
Bunu denemek için PortSwigger Lab kontrol edin.
Aşağıdaki pseudo-kod, çok kısa bir süre içinde 2FA'nın uygulanmadığı için yarış durumuna karşı savunmasızdır; bu süre zarfında oturum oluşturulmaktadır:
Birçok OAUth sağlayıcısı bulunmaktadır. Bu hizmetler, bir uygulama oluşturmanıza ve sağlayıcının kaydettiği kullanıcıları kimlik doğrulamanıza olanak tanır. Bunu yapmak için, istemci uygulamanıza OAUth sağlayıcısı içindeki bazı verilerine erişim izni vermelidir. Buraya kadar, sadece bir google/linkedin/github... ile giriş yapma durumu var; karşınıza "Uygulama <InsertCoolName> bilgilerinize erişmek istiyor, izin vermek ister misiniz?" diyen bir sayfa çıkıyor.
authorization_code
'da Yarış DurumuSorun, izin verdiğinizde ve otomatik olarak kötü niyetli uygulamaya bir authorization_code
gönderdiğinizde ortaya çıkar. Ardından, bu **uygulama, OAUth hizmet sağlayıcısındaki bir Yarış Durumunu kötüye kullanarak hesabınız için authorization_code
'dan birden fazla AT/RT (Authentication Token/Refresh Token) üretir. Temelde, uygulamanın verilerinize erişim izni verdiğinizi kötüye kullanarak birden fazla hesap oluşturur. Sonrasında, eğer uygulamanın verilerinize erişim iznini durdurursanız, bir çift AT/RT silinecek, ancak diğerleri geçerli kalacaktır.
Refresh Token
'da Yarış DurumuBir geçerli RT elde ettiğinizde, birden fazla AT/RT üretmek için bunu kötüye kullanmayı deneyebilirsiniz ve kullanıcı kötü niyetli uygulamanın verilerine erişim izinlerini iptal etse bile, birden fazla RT hala geçerli olacaktır.
WS_RaceCondition_PoC içinde, Yarış Durumlarını Web Sockets'te de kötüye kullanmak için websocket mesajlarını paralel olarak gönderen bir PoC bulabilirsiniz.
Trickest kullanarak dünyanın en gelişmiş topluluk araçlarıyla desteklenen iş akışlarını kolayca oluşturun ve otomatikleştirin. Bugün Erişim Alın:
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)