18 Haziran 2018 Pazartesi

Tarayıcı İstismarı - Session Hijacking




Birçok platformda keşfedilen XSS açıklarından söz edildiği gözünüze çarpmıştır. Özellikle bug bounty için konuşacak olursak, bug bounty programı kapsamındaki sayfada bir pop-up penceresi açtığımız anda, ödül bizimdir.

Fakat gerçek bir saldırıda, saldırganların bu tür bir işleme asla girişmeyeceğini göreceksinizdir.

Aşağıdaki XSS payload'unu daha önce görmüşsünüzdür. Kendisi XSS bulmak için kullanılan basit bir javascript kodu.




Eğer saldırgan stored XSS açığı olan bir forma yukarıdaki satırı girecek olursa, bulguyu ifşa etmiş olacağından büyük ihtimalle daha açıktan yararlanamadan açık kapatılacaktır. Benzer şeyler, sızma testleri için de geçerli olabilir.

Ve yine gerçek bir saldırıda olduğu gibi, sızma testlerinde de sadece alarm üreterek XSS açığını doğruladığımızda pek de açığı istismar etmiş olmuyoruz. Bug bounty ile gerçek bir saldırının ve bir sızma testinin aynı şey olmadığını bilmemiz gerekiyor. Birçok kişi XSS tespit edebilirken, bunu sistematik bir şekilde istismar edebilen ve bunu geçerli bir saldırı vektörü olarak kullanabilen kişilerin sayısı daha az. Eğer amaç bug bounty ise bile --ki bug bounty'ye karşı hiçbir şeyim yok, XSS açıklarının istismarında ustalaşmak(tespitinden söz etmiyorum) sizi daha iyi bir bug avcısı yapacaktır.

Açıkçası, bu serinin amaçlarından biri de bunu göstermek.

Eğer XSS'e yeniyseniz, buraya.


Şimdi basmakalıp payload'umuza dönelim.



Not: Yukarıdaki kısa payload hakkında söylemeyi unuttuğum bir şey var.  Kendisi XSS tespitinde en sık kullanılan payload. Bu kadar sık kullanıldığından bir WAF  veya IPS/IDS tarafından tespit edilmesi ve engellenmesi çok muhtemel. Bu nedenle çoğu saldırgan(ve siber güvenlik uzmanı) çeşitli filtre atlatma teknikleri geliştirir/kullanır. Bunlardan bir kısmına aşağıdaki link'ten ulaşabilirsiniz.

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet


Bir pop-up penceresi çıkarmak hoş. Bakalım ekrana başka neler basabiliriz.


Şimdi bu payload'u biraz değiştirerek, çok çok çok ama çok teknik bir payload oluşturuyorum.

(bkz: https://eksisozluk.com/mubalaga)


Şimdi karşımıza çıkan pop-up penceresinde sayfayı ziyaret eden kişinin çerez bilgilerini görüntüleyebiliriz. Bu durumda bizim için ekstra önem taşıyan bilgiler ise, oturum çerezleri, (session cookie).

Örneği DVWA üzerinden vereceğim. Eğer duymadıysanız kendisi çeşitli web saldırılarını deneyip görebileceğiniz bir lab ortamı. Fakat eksikleri var. XVWA'yı tavsiye ederim.


Ana sayfayı ziyaret ettiğimizde bir kullanıcı giriş sayfasıyla karşılaşıyoruz.



Formu doldurduğumuzda gönderilen POST isteğine bakacak olursak, bize daha giriş yapmadan bir Session ID atandığını göreceğiz. (Acaba üst üste çok sayıda GET isteği göndersek atayabileceği  Session ID değerlerini tüketebilir miyiz? )



An itibariyle bize atanan Session ID'nin giriş yapma yetkisi yok. Fakat POST isteğini gönderdiğimde, eğer kullanıcı adım ve parolam doğruysa bu oturum çerezi yetkili olarak tanımlanacak.

Giriş yaptıktan sonra XSS açığı olan forma gidiyorum ve  bahsettiğimiz süper-fantastik XSS payload'unu giriyorum





İsteği karşıya yolladığımda, kendi tarayıcıma atanan cookie değerlerini görebilirim.



Başka bir tarayıcı ile aynı sayfayı ziyaret edersem,  tarayıcıya farklı bir Session ID atandığını görürüm. Eğer bu değeri yukarıdaki değer ile değiştirirsem, başka bir kullanıcının oturumunu ele geçirmiş, yani başarılı bir Session Hijacking saldırısı gerçekleştirmiş olurum.

7 Farkı Bul


Buradaki sorun ne? Kendi tarayıcımın oturum çerezlerini ele geçirmemin bana bir faydası yok. Artık yavaş yavaş pop-up pencerelerinden vazgeçebiliriz.

Aşağıdaki gibi bir javascript kodu başka bir kullanıcının sahip olduğu cookie bilgilerini kendi IP adresimiz üzerinde sunduğumuz bir netcat bağlantısına basmakta kullanılabilir.

DVWA üzerinde Reflected XSS penceresine gidip bu payload'u bir GET isteği içinde karşıya gönderebiliriz. Fakat bu payload'u DVWA'ya girdiğimizde + karakterinin sorun oluşturduğunu göreceğiz. Bunun nedeni karşıya gönderilen karakterler arasından + karakterinin URL encode edilmiyor olması. (+) karakterini %2B şeklinde encode ettiğimiz zaman bu problemin çözüldüğünü görüyoruz.

Elde ettiğimiz komutun son hali,




Sayfayı ziyaret eden kullanıcıların çerezlerini elde etmek için, stismar ettiğimiz açığın bir stored XSS açığı olmasına gerek yok. Basit bir şekilde, oturumu devam etmekte olan kullanıcılara link yollayabiliriz. Burası sosyal mühendislik becerilerinin döktürüldüğü yer :) Bizi teknik anlamda ilgilendirmediği için üzerinde durmuyorum.

Öncelikle bize gelen bağlantıyı yakalaması için bir netcat listener açalım ve port 80 üzerinden gelen bağlantıları dinlemeye başlayalım. Tabii ki, bu sırada IP adresimizi not etmekte de fayda var.



Şimdi ise kullanıcıya göndereceğimiz link'i hazırlayalım.

Kullanıcı bu linki ziyaret ettiğinde (eğer aynı tarayıcı üzerinde süregelen bir oturumu varsa) cookie bilgileri tarafımıza iletilecektir.






Elde edilen oturum çerezi bir proxy aracılığıyla web uygulamasına gönderildiğinde, kullanıcının oturumu ele geçirilecektir. Bu işlemi kolaylaştırmak için eski sürüm bir Firefox üzerinde CookiesManager+ kullanabiliriz. Eski sürüm Firefox kurmakla ile uğraşmayayım, hacklenirim derseniz  aynı işlemi yapacak birçok başka aracın mevcut olduğuna eminim.

BONUS - Thanks to: (@rodoassis) A.K.A.  Brute 

Tarayıcı üzerinde ele geçirecek cookie değerleri olmayabilir veya çerezler HttpOnly ile korunuyor olabilir.

Çıkmaz Sokak?  

Kesinlikle hayır. XSS, iyi istismar edildiğinde güçlü bir saldırı vektörüdür. Çerezler çalınamıyor olsa bile, XSS üzerinden kullanıcının tarayıcısını ele geçirmek mümkündür.


Bunu gerçekleştirmek için sunucuya enjekte edeceğimiz bir payload'a ihtiyacımız olacak.

svg onload XSS vektörünü kullanarak oluşturulan javascript payload'unu biraz daha yakından inceleyecek olursak,
Öncelikle kodumuzun belirli aralıklarda çalışmasını sağlayacak bir fonksiyona ihtiyacımız var. 

setInterval() fonksiyonunun çalışması için bunu başka bir javascript fonksiyonu içine grupluyoruz.


Bir script elementi oluşturuyoruz.

Şimdi ise sıra tarayıcının bağlanacağı IP adresi ve port'u tanımlama zamanı


Şimdi ise elementi var olan HTML dosyasının gövde(body) kısmına gömmekte.

Payload'umuzu biraz daha kısaltacak olursak (7 byte deyip geçmemek lazım)

Şimdi ise saldırganın terminalinde çalışacak bir listener'a ihtiyacımız var.

Artık sayfayı ziyaret eden tarayıcı düzenli olarak saldırgana bağlanacak ve saldırganın sağladığı javascript komutlarını çalıştıracak.

Aşağıdaki video'da bunun nasıl işlediğini görebilirsiniz.


Eğer XSS saldırı vektörleri ilginizi çekiyorsa brutelogic.com.br'yi ziyaret etmenizi tavsiye ederim.

Bonus bölümünün orjinalini daha detaylı halde https://brutelogic.com.br/blog/using-xss-to-control-a-browser/ adresinde bulabilirsiniz.

Thanks to @rodoassis for letting me use his material and writing it in the first place.
on 18 Haziran by Berk Cem Göksel |   Edit