oleh SeerLight
Membangun layanan apa pun tentu mencakup upaya terus-menerus pada keamanan. Keamanan adalah proses berkelanjutan yang mencakup analisis terus-menerus dan peningkatan keamanan produk, pemantauan berita tentang kerentanan, dan banyak lagi. Termasuk audit. Audit dilakukan baik secara internal maupun oleh pakar eksternal, yang dapat membantu keamanan secara radikal karena mereka tidak terlalu mendalami proyek dan berpikiran terbuka.
Artikel ini membahas pandangan paling lugas dari pakar eksternal yang membantu tim Mail.ru Cloud Solutions (MCS) menguji layanan cloud, dan tentang apa yang mereka temukan. Sebagai “kekuatan eksternal”, MCS memilih perusahaan Keamanan Digital, yang terkenal dengan keahliannya yang tinggi di bidang keamanan informasi. Dan dalam artikel ini kami akan menganalisis beberapa kerentanan menarik yang ditemukan sebagai bagian dari audit eksternal - sehingga Anda terhindar dari dampak yang sama saat membuat layanan cloud Anda sendiri.
Описание продукта
adalah platform untuk membangun infrastruktur virtual di cloud. Ini mencakup IaaS, PaaS, dan pasar gambar aplikasi siap pakai untuk pengembang. Dengan mempertimbangkan arsitektur MCS, keamanan produk perlu diperiksa di bidang berikut:
- melindungi infrastruktur lingkungan virtualisasi: hypervisor, routing, firewall;
- perlindungan infrastruktur virtual pelanggan: isolasi satu sama lain, termasuk jaringan, jaringan pribadi di SDN;
- OpenStack dan komponen terbukanya;
- S3 desain kami sendiri;
- IAM: proyek multi-penyewa dengan panutan;
- Visi (computer vision): API dan kerentanan saat bekerja dengan gambar;
- antarmuka web dan serangan web klasik;
- kerentanan komponen PaaS;
- API semua komponen.
Mungkin hanya itu yang penting untuk sejarah selanjutnya.
Pekerjaan apa yang dilakukan dan mengapa hal itu diperlukan?
Audit keamanan ditujukan untuk mengidentifikasi kerentanan dan kesalahan konfigurasi yang dapat menyebabkan kebocoran data pribadi, modifikasi informasi sensitif, atau gangguan ketersediaan layanan.
Selama pekerjaan, yang berlangsung rata-rata 1-2 bulan, auditor mengulangi tindakan calon penyerang dan mencari kerentanan di bagian klien dan server dari layanan yang dipilih. Dalam konteks audit platform cloud MCS, tujuan berikut diidentifikasi:
- Analisis otentikasi dalam layanan. Kerentanan pada komponen ini akan membantu untuk segera masuk ke akun orang lain.
- Mempelajari role model dan kontrol akses antar akun yang berbeda. Bagi seorang penyerang, kemampuan untuk mendapatkan akses ke mesin virtual orang lain adalah tujuan yang diinginkan.
- Kerentanan sisi klien. XSS/CSRF/CRLF/dll. Mungkinkah menyerang pengguna lain melalui tautan berbahaya?
- Kerentanan sisi server: RCE dan segala jenis injeksi (SQL/XXE/SSRF dan sebagainya). Kerentanan server umumnya lebih sulit ditemukan, namun menyebabkan kompromi banyak pengguna sekaligus.
- Analisis isolasi segmen pengguna di tingkat jaringan. Bagi seorang penyerang, kurangnya isolasi sangat meningkatkan permukaan serangan terhadap pengguna lain.
- Analisis logika bisnis. Mungkinkah menipu bisnis dan membuat mesin virtual secara gratis?
Dalam proyek ini, pekerjaan dilakukan sesuai dengan model “Kotak Abu-abu”: auditor berinteraksi dengan layanan dengan hak istimewa pengguna biasa, tetapi sebagian memiliki kode sumber API dan memiliki kesempatan untuk mengklarifikasi detailnya dengan pengembang. Ini biasanya merupakan model kerja yang paling nyaman dan sekaligus cukup realistis: informasi internal masih dapat dikumpulkan oleh penyerang, hanya masalah waktu saja.
Kerentanan ditemukan
Sebelum auditor mulai mengirimkan berbagai muatan (muatan yang digunakan untuk melakukan serangan) ke tempat-tempat acak, penting untuk memahami cara kerja dan fungsi apa yang disediakan. Tampaknya ini adalah latihan yang tidak berguna, karena di sebagian besar tempat yang diteliti tidak akan ada kerentanan. Tetapi hanya memahami struktur aplikasi dan logika operasinya yang akan memungkinkan untuk menemukan vektor serangan yang paling kompleks.
Penting untuk menemukan tempat yang tampak mencurigakan atau sangat berbeda dari tempat lain. Dan kerentanan berbahaya pertama ditemukan dengan cara ini.
IDOR
Kerentanan IDOR (Referensi Objek Langsung Tidak Aman) adalah salah satu kerentanan paling umum dalam logika bisnis, yang memungkinkan seseorang mendapatkan akses ke objek yang sebenarnya tidak diizinkan untuk diakses. Kerentanan IDOR menciptakan kemungkinan memperoleh informasi tentang pengguna dengan berbagai tingkat kekritisan.
Salah satu opsi IDOR adalah melakukan tindakan dengan objek sistem (pengguna, rekening bank, item di keranjang belanja) dengan memanipulasi pengidentifikasi akses ke objek tersebut. Hal ini menyebabkan konsekuensi yang paling tidak terduga. Misalnya, kemungkinan mengganti rekening pengirim dana, yang melaluinya Anda dapat mencurinya dari pengguna lain.
Dalam kasus MCS, auditor baru saja menemukan kerentanan IDOR yang terkait dengan pengidentifikasi yang tidak aman. Di akun pribadi pengguna, pengidentifikasi UUID digunakan untuk mengakses objek apa pun, yang menurut pakar keamanan, tampaknya sangat tidak aman (yaitu, terlindung dari serangan brute force). Namun untuk entitas tertentu, ditemukan bahwa angka-angka reguler yang dapat diprediksi digunakan untuk memperoleh informasi tentang pengguna aplikasi. Saya rasa Anda dapat menebak bahwa ID pengguna dapat diubah satu per satu, mengirim permintaan lagi dan dengan demikian memperoleh informasi melewati ACL (daftar kontrol akses, aturan akses data untuk proses dan pengguna).
Pemalsuan Permintaan Sisi Server (SSRF)
Hal yang baik tentang produk OpenSource adalah mereka memiliki banyak sekali forum dengan penjelasan teknis rinci tentang masalah yang muncul dan, jika Anda beruntung, penjelasan solusinya. Namun koin ini memiliki sisi lain: kerentanan yang diketahui juga dijelaskan secara rinci. Misalnya, ada deskripsi bagus tentang kerentanan di forum OpenStack и , yang karena alasan tertentu tidak ada yang terburu-buru untuk memperbaikinya.
Fungsi umum aplikasi adalah kemampuan pengguna untuk mengirim tautan ke server, yang diklik server (misalnya, untuk mengunduh gambar dari sumber tertentu). Jika alat keamanan tidak memfilter tautan itu sendiri atau respons yang dikembalikan dari server ke pengguna, fungsi tersebut dapat dengan mudah digunakan oleh penyerang.
Kerentanan SSRF dapat mempercepat perkembangan serangan. Seorang penyerang bisa mendapatkan:
- akses terbatas terhadap jaringan lokal yang diserang, misalnya hanya melalui segmen jaringan tertentu dan menggunakan protokol tertentu;
- akses penuh ke jaringan lokal, jika penurunan versi dari tingkat aplikasi ke tingkat transportasi dimungkinkan dan, sebagai hasilnya, manajemen beban penuh di tingkat aplikasi;
- akses untuk membaca file lokal di server (jika skema file:/// didukung);
- dan banyak lagi.
Kerentanan SSRF telah lama diketahui di OpenStack, yang bersifat “buta”: ketika Anda menghubungi server, Anda tidak menerima respons darinya, namun Anda menerima berbagai jenis kesalahan/penundaan, tergantung pada hasil permintaan . Berdasarkan ini, Anda dapat melakukan pemindaian port pada host di jaringan internal, dengan segala konsekuensi yang tidak boleh dianggap remeh. Misalnya, suatu produk mungkin memiliki API back-office yang hanya dapat diakses dari jaringan perusahaan. Dengan dokumentasi (jangan lupakan orang dalam), penyerang dapat menggunakan SSRF untuk mengakses metode internal. Misalnya, jika Anda entah bagaimana bisa mendapatkan daftar perkiraan URL yang berguna, maka dengan menggunakan SSRF Anda dapat menelusurinya dan menjalankan permintaan - secara relatif, mentransfer uang dari satu rekening ke rekening lain atau mengubah batas.
Ini bukan pertama kalinya kerentanan SSRF ditemukan di OpenStack. Di masa lalu, image VM ISO dapat diunduh dari tautan langsung, yang juga menimbulkan konsekuensi serupa. Fitur ini kini telah dihapus dari OpenStack. Tampaknya, masyarakat menganggap ini sebagai solusi paling sederhana dan paling dapat diandalkan untuk masalah tersebut.
Dan di laporan yang tersedia untuk umum dari layanan HackerOne (h1), eksploitasi SSRF yang tidak lagi buta dengan kemampuan membaca metadata instance mengarah ke akses Root ke seluruh infrastruktur Shopify.
Di MCS, kerentanan SSRF ditemukan di dua tempat dengan fungsi serupa, namun hampir tidak mungkin untuk dieksploitasi karena firewall dan perlindungan lainnya. Dengan satu atau lain cara, tim MCS tetap menyelesaikan masalah ini, tanpa menunggu komunitas.
XSS alih-alih memuat shell
Meskipun ratusan penelitian telah ditulis, serangan XSS (cross-site scripting) dari tahun ke tahun masih menjadi yang terbanyak kerentanan web (atau ?).
Unggahan file adalah tempat favorit bagi setiap peneliti keamanan. Seringkali ternyata Anda dapat memuat skrip arbitrer (asp/jsp/php) dan menjalankan perintah OS, dalam terminologi pentester - “muat shell”. Namun popularitas kerentanan tersebut bekerja dalam dua arah: kerentanan tersebut diingat dan solusi dikembangkan untuk melawan kerentanan tersebut, sehingga saat ini kemungkinan “memuat shell” cenderung nol.
Tim penyerang (diwakili oleh Digital Security) beruntung. Oke, di MCS di sisi server isi file yang diunduh diperiksa, hanya gambar yang diperbolehkan. Tapi SVG juga sebuah gambar. Bagaimana gambar SVG bisa berbahaya? Karena Anda dapat menyematkan cuplikan JavaScript ke dalamnya!
Ternyata file yang diunduh tersedia untuk semua pengguna layanan MCS, artinya tidak menutup kemungkinan untuk menyerang pengguna cloud lain yaitu administrator.
Contoh serangan XSS pada form login phishing
Contoh eksploitasi serangan XSS:
- Mengapa mencoba mencuri sesi (terutama karena sekarang cookie Khusus HTTP ada di mana-mana, dilindungi dari pencurian menggunakan skrip js), jika skrip yang dimuat dapat segera mengakses API sumber daya? Dalam hal ini, payload dapat menggunakan permintaan XHR untuk mengubah konfigurasi server, misalnya, menambahkan kunci SSH publik penyerang dan mendapatkan akses SSH ke server.
- Jika kebijakan CSP (kebijakan perlindungan konten) melarang pengenalan JavaScript, penyerang dapat bertahan tanpanya. Dengan menggunakan HTML murni, buat formulir login palsu untuk situs tersebut dan curi kata sandi administrator melalui phishing tingkat lanjut ini: halaman phishing untuk pengguna berakhir di URL yang sama, dan lebih sulit bagi pengguna untuk mendeteksinya.
- Akhirnya penyerang bisa mengaturnya — mengatur Cookie yang lebih besar dari 4 KB. Pengguna hanya perlu membuka tautan satu kali, dan seluruh situs menjadi tidak dapat diakses hingga pengguna berpikir untuk membersihkan browser secara khusus: dalam sebagian besar kasus, server web akan menolak menerima klien tersebut.
Mari kita lihat contoh XSS lain yang terdeteksi, kali ini dengan eksploitasi yang lebih pintar. Layanan MCS memungkinkan Anda menggabungkan pengaturan firewall ke dalam grup. Nama grup adalah tempat XSS terdeteksi. Keunikannya adalah vektor tidak langsung terpicu, bukan saat melihat daftar aturan, tetapi saat menghapus grup:
Artinya, skenarionya adalah sebagai berikut: penyerang membuat aturan firewall dengan nama "memuat", administrator memperhatikannya setelah beberapa saat dan memulai proses penghapusan. Dan di sinilah JS jahat bekerja.
Bagi pengembang MCS, untuk melindungi terhadap XSS pada gambar SVG yang diunduh (jika tidak dapat ditinggalkan), tim Keamanan Digital merekomendasikan:
- Tempatkan file yang diunggah oleh pengguna pada domain terpisah yang tidak ada hubungannya dengan “cookie”. Skrip akan dijalankan dalam konteks domain yang berbeda dan tidak akan menimbulkan ancaman bagi MCS.
- Dalam respons HTTP server, kirim header “Disposisi Konten: lampiran”. Kemudian file tersebut akan diunduh oleh browser dan tidak dieksekusi.
Selain itu, kini ada banyak cara yang tersedia bagi pengembang untuk memitigasi risiko eksploitasi XSS:
- menggunakan tanda “HTTP Only”, Anda dapat membuat header sesi “Cookie” tidak dapat diakses oleh JavaScript berbahaya;
- akan mempersulit penyerang untuk mengeksploitasi XSS;
- mesin templat modern seperti Angular atau React secara otomatis membersihkan data pengguna sebelum mengeluarkannya ke browser pengguna.
Kerentanan otentikasi dua faktor
Untuk meningkatkan keamanan akun, pengguna selalu disarankan untuk mengaktifkan 2FA (otentikasi dua faktor). Memang benar, ini adalah cara yang efektif untuk mencegah penyerang mendapatkan akses ke layanan jika kredensial pengguna telah disusupi.
Namun apakah penggunaan faktor autentikasi kedua selalu menjamin keamanan akun? Ada masalah keamanan berikut dalam implementasi 2FA:
- Pencarian paksa kode OTP (kode satu kali). Meskipun pengoperasiannya sederhana, kesalahan seperti kurangnya perlindungan terhadap kekerasan OTP juga ditemui oleh perusahaan besar: , .
- Algoritma pembangkitan yang lemah, misalnya kemampuan memprediksi kode selanjutnya.
- Kesalahan logika, seperti kemampuan meminta OTP orang lain di ponsel Anda, seperti ini dari Shopify.
Dalam kasus MCS, 2FA diimplementasikan berdasarkan Google Authenticator dan . Protokolnya sendiri telah teruji oleh waktu, namun penerapan verifikasi kode di sisi aplikasi patut untuk diperiksa.
MCS 2FA digunakan di beberapa tempat:
- Saat mengautentikasi pengguna. Ada perlindungan terhadap kekerasan: pengguna hanya perlu beberapa kali mencoba memasukkan kata sandi satu kali, kemudian masukan diblokir untuk sementara waktu. Ini menghalangi kemungkinan pemilihan OTP secara brute force.
- Saat membuat kode cadangan offline untuk melakukan 2FA, serta menonaktifkannya. Di sini, tidak ada perlindungan brute force yang diterapkan, yang memungkinkan, jika Anda memiliki kata sandi untuk akun dan sesi aktif, untuk membuat ulang kode cadangan atau menonaktifkan 2FA sepenuhnya.
Mengingat kode cadangan terletak pada rentang nilai string yang sama dengan yang dihasilkan oleh aplikasi OTP, peluang menemukan kode dalam waktu singkat jauh lebih tinggi.
Proses pemilihan OTP untuk menonaktifkan 2FA menggunakan alat “Burp: Intruder”.
Hasil
Secara keseluruhan, MCS tampaknya aman sebagai sebuah produk. Selama audit, tim pentesting tidak dapat memperoleh akses ke VM klien dan datanya, dan kerentanan yang ditemukan segera diperbaiki oleh tim MCS.
Namun di sini penting untuk dicatat bahwa keamanan adalah pekerjaan yang berkelanjutan. Pelayanan tidak bersifat statis, namun terus berkembang. Dan tidak mungkin mengembangkan suatu produk sepenuhnya tanpa kerentanan. Namun Anda dapat menemukannya tepat waktu dan meminimalkan kemungkinan terulangnya kembali.
Sekarang semua kerentanan yang disebutkan di MCS telah diperbaiki. Dan untuk meminimalkan jumlah yang baru dan mengurangi masa pakainya, tim platform terus melakukan ini:
- secara rutin melakukan audit oleh perusahaan eksternal;
- mendukung dan mengembangkan partisipasi;
- terlibat dalam keamanan. 🙂
Sumber: www.habr.com