Kamis, 01 Agustus 2019

Subdomain takeover lead to stored XSS pada a***h****.com


Oke kali ini saya akan bercerita tentang subdomain takeover yang saya temukan pada salah satu web marketplace terbesar asal indonesia.

Setelah melakukan scanning menggunakan beberapa tools terkait subdomain seperti sublist3r, knockpy, massdns dll. saya menemukan subdomain yang menarik.

Menarik, karena ketika saya melakukan lookup CNAME pada subdomain tersebut, ternyata mengarah kepada sebuah domain eksternal, dan ketika diakses, mendapat pesan error Server not found.

Saya kemudian mengecek beberapa web penyedia domain seperti namecheap, dll. tentang status kepemilikan domain tersebut. Ternyata domain tersebut belum ada yang memiliki dan bisa dibeli.

Awalnya saya masih ragu, karena sebelumnya telah menemukan kasus yang sama pada sebuah private program, bedanya CNAME mengarah ke penyedia layanan server Amazon AWS. Ketika saya coba takeover, ternyata gagal.

Saya kemudian bertanya kepada para pawang-pawang Web seputar CNAME untuk memahaminya dari sudut pandang mereka (Cheers for mas Ijul and Zurin), karena terkadang pemahaman manusia lebih mudah dimengerti daripada apa yang kita baca. Tidak lupa juga saya membaca beberapa write-up seputar subdomain takeover untuk lebih memantapkan teori.

Setelah benar-benar yakin, akhirnya dengan bermodalkan nekat dan siap untuk gagal lagi, karena waktu itu saya sama sekali tidak memegang uang (Gaji terlambat turun, wkwk). Saya meminjam $9 pada teman saya untuk membeli domain tersebut di namecheap (Cheers for mas Norris, akwkwk).

Setelah pembelian domain berhasil kemudian saya cek lagi, ternyata subdomain marketplace tersebut mengirimkan response yang berbeda, yaitu blank putih, sehingga saya (setengah) yakin subdomain takeover bisa dilakukan.

Saya kemudian mengarahkan domain yang saya beli tadi ke server yang saya miliki, setelah sebelumnya menyetting LAMP dan mengupload file HTML sederhana menggunakan FTP, sebagai indikator.

Ketika subdomain tersebut saya akses lagi, ternyata gagal, subdomain tersebut tidak mengarah ke server saya. :(

Nggak kok, bercanda wkwk, dugaan saya ternyata benar, subdomain tersebut berhasil saya ambil alih, dan mengarah ke server saya, yay!

Jujur, sampai disini saya agak blank selama beberapa waktu, adrenalin rush, tangan gemetar (iya, serius :v). Karena ini berpotensi jadi Bounty pertama saya setelah sekian bulan fokus mempelajari InfoSec, setelah sekian duplicate, invalid, dan not applicable report. Dengan bug yang cukup fatal, hampir tidak mungkin duplicate (karena domainnya sudah saya beli duluan :v), dan bahkan dari salah satu Marketplace terbesar di indonesia, damn!

Setelah sejenak menenangkan diri, menyeruput kopi, menikmati senja (naq indie indie club), kemudian menghisap rokok (eh nggak deng, nggak punya duit buat beli rokok bgst), saya mulai menulis report dan membuat PoC untuk berbagai attack vector yang bisa digunakan dengan memanfaatkan vulnerability ini.

Stored XSS


Yep, Stored XSS langsung melintas di pikiran, karena server milik saya, jadi saya bisa mengirim response apapun dengan mengatasnamakan subdomain ini.

Saya kemudian browsing ke domain utama, dan mengintercept response yang diterima. Ternyata benar, 'Set-cookie' disetting ke wildcard subdomain, dengan kata lain semua subdomain menggunakan cookies yang sama, termasuk subdomain yang saya takeover.

Namun anehnya ketika saya bandingkan cookies subdomain yang saya takeover dengan domain utama, ada beberapa cookies yang tidak muncul. Setelah memperhatikan lebih detail, ternyata ada beberapa cookie yang memiliki flag 'Secure', sehingga hanya akan di set apabila koneksi menggunakan HTTPS, sedangkan server saya masih menggunakan HTTP.

Ketika melakukan setting HTTPS menggunakan certbot, saya menjumpai sebuah masalah yaitu saya tidak bisa menerbitkan SSL certificate mengatasnamakan subdomain tersebut karena sudah dipegang oleh perusahaan marketplace tersebut. Akhirnya terpaksa saya menggunakan sertifikat dari domain asli.

Ketika diakses melalui subdomain tadi, terdapat warning dari browser yang mengatakan bahwa domain berbeda dengan yang tercantum pada sertifikat SSL, namun jika diabaikan, session hijacking terbukti bisa dilakukan. Well that's all i can do for now, move on.

Phising


Phising, atau membuat halaman palsu yang seolah-olah merupakan halaman asli dengan fungsi lain yang berbahaya, menjadi pilihan kedua saya. Menggunakan subdomain asli yang terpercaya, phising bisa menjadi attack vector yang amat sangat kuat.

Karena agak malas (akwkwkwk), saya mendownload halaman login dari marketplace tersebut, memodifikasi beberapa fungsinya, kemudian mengupload ulang pada server saya.

Setidaknya cukup lah untuk dijadikan Proof of Concept bahwa pencurian credentials memanfaatkan phising bisa dilakukan.

Clickjacking


Mitigasi clickjacking biasanya dilakukan dengan menyetting header 'X-Frame-Options' ke 'Deny' atau 'Sameorigin'.

Karena saya telah melakukan takeover pada salah satu subdomain, berarti semua halaman yang diproteksi dengan 'Sameorigin' bisa di bypass.

Namun setelah membaca ulang peraturan bug bounty perusahaan tersebut, clickjacking termasuk Out of Scope sehingga saya tidak tertarik untuk membuat PoC lebih jauh.

Setelah dirasa cukup, saya kemudian mengirimkan report beserta seluruh PoC dan mitigasi kepada email team security yang dicantumkan.

Oiya, beberapa tips penting ini saya dapatkan setelah melakukan research seputar subdomain takeover:

- Jangan membuat halaman index yang aneh-aneh. Dengan sekian juta visitor yang datang setiap harinya, tentunya bukan tidak mungkin ada yang secara 'kebetulan' mengakses subdomain tersebut. Kita tidak mau merusak user experience dan menjatuhkan nama baik perusahaan tersebut bukan? Pada kasus ini, saya memilih hanya menampilkan tulisan "Under maintenance" pada halaman utama.

- Ketika membuat halaman Proof of Concept, gunakan nama file yang random dan tidak mudah ditemukan, contohnya 'https://sub.domain.com/ak773739hdjsbdh737383.html'. Alasannya sama, yaitu untuk meminimalisir kemungkinan user yang secara 'kebetulan' mengakses halaman tersebut, sehingga tidak merusak user experience atau membahayakan mereka dengan flow PoC yang kita buat.

Timeline:

- 27 Juli 2019 : Report beserta PoC dan mitigasi terkirim.

- 28 Juli 2019 : Mendapat balasan dari team IT bahwa report sudah diterima, telah di forward ke team pentest dan akan dilakukan investigasi, meminta agar tidak mempublikasikan tanpa izin. Saya rasa artikel ini tidak dihitung karena tidak menyebut identitas, lagipula ini bukan blog publik. 
¯\_(ツ)_/¯

- 29 Juli 2019 : Mendapatkan update bahwa report dinyatakan Valid dengan Severity High (dammn :'D), diminta bersabar karena masih dalam proses perbaikan.

- 31 Juli 2019 : Menyampaikan bahwa bug sudah diperbaiki dan meminta saya melakukan test lagi untuk memastikan. Setelah saya konfirmasi, mereka meminta data diri saya untuk mengirimkan bounty. Karena selama berkomunikasi menggunakan bahasa inggris, awalnya saya dikira orang India dan diminta mengirimkan foto passport dsb. Proses juga tertunda karena saya belum memiliki NPWP.

- 1 Agustus 2019 : NPWP sudah jadi, permintaan pembayaran telah diajukan ke bagian finance. Diminta menunggu maksimal 3-4 Minggu hari kerja.

Let's dig deeper,
Warm regards.


Subdomain takeover lead to stored XSS pada a***h****.com
4/ 5
Oleh