Baru-baru ini, saya mulai menerima proposal untuk memeriksa operasi berbagai layanan untuk kesalahan dan kerentanan. Dan dalam proposal seperti itu saya mencoba bekerja untuk hasilnya dan mendapatkan kesenangan maksimal dari proses tersebut. Tetapi hasil dari "proyek" terakhir mengejutkan saya untuk sedikitnya.
Saya diminta untuk menguji penyedia hosting.
Saya tidak akan mengungkapkan nama. Dan dalam cerita saya, saya akan menggunakan nama Hoster. Dengan situs itu sendiri, layanan hosting semua standar. Menawarkan untuk membeli VDS, Domain, sertifikat SSL.
Pertama-tama, saya terkejut melihat bagaimana akun pribadi pengguna diimplementasikan. Bukti kepemilikan alamat email saat pendaftaran tidak diperlukan. Artinya, Anda bisa mendaftar dengan alamat email steve.jobs@apple.com. Atau lebih baik lagi, support@hoster.com.
Tapi untungnya, dengan analogi dengan
cerita ini , pengungkapan informasi sensitif dari meja dukungan layanan tidak terjadi.
Namun, hal itu terjadi ketika saya membuat permintaan dukungan pengujian dan segera memeriksa ketersediaan permintaan ID tetangga untuk permintaan dukungan lainnya. Anehnya mereka tersedia. Dan itu mungkin untuk mengamati siapa dan apa yang mendaftar dengan hoster. Dan masalah apa yang dihadapi pengguna? Secara umum, kerentanan IDOR standar, yang sekarang tidak akan mengejutkan siapa pun. Tentu saja, dia langsung diperbaiki.
Ada juga beberapa tempat dengan Stored XSS. Ada juga Blind XSS yang mengembalikan Cookie Administrator Layanan kepada saya. Berkat XSS ini, saya dapat mengetahui di mana antarmuka administrator berada, dan secara umum, ini mengungkapkan banyak informasi menarik.
- Berapa banyak pengguna aktif.
- Berapa banyak domain dalam kendali.
- Berapa banyak VDS yang digunakan.
Dan masih banyak lagi ...
Ada berbagai kesalahan dengan token CSRF, yang memungkinkan pengguna melakukan banyak hal berbahaya di akun Anda. Dan jika ada tempat di mana token CSRF ditransfer, maka mereka hanya ditransfer. Tidak ada yang berencana untuk memeriksa mereka di backend. Sebagai hasil dari temuan saya, bagian dari fungsi itu sepenuhnya dinonaktifkan. Misalnya, otentikasi 2FA diputuskan untuk dihapus sementara, karena tidak terjadi dalam implementasi.
Dalam perjalanan pekerjaan saya, saya memperhatikan tidak hanya masalah keamanan, tetapi juga kesalahan implementasi atau masalah dalam pengoperasian beberapa fungsi. Saya suka QA tidak bisa lewat seperti ini. Akibatnya, pelacak masalah saya mencapai angka - 22. Begitu banyak masalah dalam agregat yang saya temukan dan perbaiki (sangat penting).
Hasilnya lebih dari meyakinkan. Dan saya sudah merencanakan untuk menyelesaikan proyek ini. Tetapi untuk beberapa alasan, saya kembali ingat masalah kurangnya konfirmasi dari pemilik alamat email saat pendaftaran. Dan dia mulai menemukan situasi di mana ini dapat menciptakan masalah maksimum untuk hosting dan pemiliknya. Pada titik tertentu, saya mulai berpikir tentang hubungan para pemilik layanan hosting ini dengan proyek-proyek lain dari perusahaan yang sama yang saya ketahui. Setelah beberapa menit, saya mendaftarkan akun dengan alamat email proyek lain dari perusahaan yang sama (biarkan itu menjadi support@example.com). Kemudian saya berhasil mengikat domain example.com ke akun saya yang dibuat suppot@example.com. Tapi saya masih belum bisa mengontrol konten dari domain yang terikat.
Tapi dia bisa memancing dengan email atas nama layanan example.com.
Tidak jelas ke mana surat jawaban datang. Karena saya menjawab satu surat ujian untuk diri sendiri. Tetapi saya tidak menerima jawabannya sendiri. Itu mungkin hilang sebagai tanggapan terhadap pemilik sebenarnya dari akun email support@example.com.
Dan kemudian sesuatu terjadi dimana saya memutuskan untuk menulis artikel ini.
Saya berhasil menyelesaikan subdomain yang terlupakan. Kerentanan pengambilalihan subdomain klasik. Anda dapat membaca lebih lanjut tentang ini di
sini .
Saya tidak tahu mengapa, tetapi saya mencoba menambahkan pengikatan ke domain yang tidak ada. Dan saya berhasil.
Subdomain berhasil ditambahkan dan saya bisa mengontrol konten subdomain ini. Dan kontennya ditampilkan.
Tetapi ini tidak bisa sama! Bagaimana bisa ?! Lagi pula, kerentanan pengambilalihan subdomain klasik hanya berfungsi dengan subdomain yang ada.
Situasi ini benar-benar tidak pas di kepalaku. Artinya, oke, saya bisa mem-bypass tingkat validasi hubungan saya ke example.com, yang tidak pernah menjadi milik saya (mungkin berkat
contoh .com atas nama akun saya). Tetapi bagaimana mungkin menambahkan subdomain sama sekali dan mengendalikannya tanpa komponen pemeriksaan di catatan A, TXT, CNAME ...?
Biasanya saya melihat ini - kami akan menambahkan subdomain kepada Anda, hanya Anda yang membuktikan bahwa Anda dapat melakukannya. Pergi dan tambahkan ke TXT hash
ololopyshpyshpyshbdysh123 ini .
Tapi tidak ada yang seperti itu. Ingin subdomain admin.example.com? Tidak masalah!
Seolah-olah kerentanan Subdomain Takeover V2.
Karena kemampuan untuk berkomunikasi dengan pemilik layanan hosting yang diuji dengan cepat - saya membuka kotak ini oleh Pandora.
Ternyata yang berikut ini. Hosting bekerja melalui CloudFlare. Dan dia bekerja dengan cara yang sangat licik.
Saya akan mencoba menjelaskan dengan kata-kata sederhana.
Secara kasar, saya katakan, datang kepada saya, saya akan menjamu Anda. Delegasikan domain Anda kepada saya.
Dan kemudian saya mengirim semua panggilan masuk tanpa pandang bulu ke CloudFlare, menganggapnya benar.
Dan jika saya dipercayakan dengan domain vasya.ru, dan seorang tetangga datang dan menyumbat situs dengan test.vasya.ru dan juga memberikannya kepada saya untuk hosting, maka server saya, memiliki akses ke CloudFlare dan sudah memiliki hak untuk vasya.ru, menambahkan level ketiga tanpa masalah domain untuk tetangga dan semua aturan, dengan cepat dan tanpa pertanyaan. Untuk semua DNS, informasi yang benar dari CloudFlare telah tiba. Dan CloudFlare mempercayai saya.
Biasanya, tentu saja, penyedia hosting mengkonfigurasi layanan DNS mereka. Tapi di sini ternyata mereka curang dan hanya mentransfer semuanya ke CloudFlare dari satu pengguna.
Jadi kami memiliki subdomain pengambilalihan god_mode. Benar, ini hanya berfungsi dengan alamat yang sudah dikendalikan hosting. Tetapi dalam hubungannya dengan panel admin layanan yang ditemukan sebelumnya - ini bisa memainkan trik pada kedua hoster dan klien layanan hosting.
Saat ini, hampir semua kerentanan dan kesalahan kritis telah diperbaiki. Dan saya berharap tidak ada yang akan memutuskan kelezatan arsitektur setelah membaca cerita ini.
PS: Komentar dan saran untuk artikel ini disambut baik. Terima kasih khusus kepada
Patriot2k untuk saran teknis! Saya juga terbuka untuk saran untuk menguji sesuatu yang menarik.