SkyShip Dusk oleh SeerLightPembangunan layanan apa pun harus mencakup pekerjaan keamanan yang konstan. Keamanan adalah proses berkelanjutan yang mencakup analisis terus-menerus dan peningkatan keamanan produk, pemantauan berita tentang kerentanan, dan banyak lagi. Termasuk - audit. Audit dilakukan sendiri dan oleh para ahli eksternal yang secara dramatis dapat membantu keamanan, karena mereka tidak tenggelam dalam proyek dan memiliki pandangan yang jelas.
Artikel ini tentang pandangan yang sangat tidak populer dari para ahli eksternal yang membantu tim Mail.ru Cloud Solutions (MCS) menguji layanan cloud, dan tentang apa yang mereka temukan. Sebagai "kekuatan eksternal" MCS memilih Keamanan Digital, yang dikenal karena keahliannya yang tinggi dalam komunitas keamanan. Dan dalam artikel ini kami akan menganalisis beberapa kerentanan menarik yang ditemukan sebagai bagian dari audit eksternal - sehingga Anda mendapatkan rake yang sama ketika Anda membuat layanan cloud Anda.
Deskripsi Produk
Mail.ru Cloud Solutions (MCS) adalah platform untuk membangun infrastruktur virtual di cloud. Ini termasuk IaaSs, PaaSs, pasar gambar aplikasi siap pakai untuk pengembang. Mempertimbangkan arsitektur MCS, penting untuk memeriksa keamanan produk di area berikut:
- perlindungan infrastruktur lingkungan virtualisasi: hypervisors, perutean, firewall;
- perlindungan infrastruktur virtual pelanggan: isolasi satu sama lain, termasuk jaringan, jaringan pribadi di SDN;
- OpenStack dan komponen-komponennya yang terbuka;
- Pengembangan S3 sendiri;
- IAM: proyek multi-tenant dengan model peran;
- Visi (visi mesin): API dan kerentanan saat bekerja dengan gambar;
- antarmuka web dan serangan web klasik;
- kerentanan komponen PaaS;
- API semua komponen.
Mungkin, semua yang penting untuk sejarah selanjutnya adalah segalanya.
Pekerjaan seperti apa yang dilakukan dan mengapa itu dibutuhkan?
Audit keamanan ditujukan untuk mengidentifikasi kerentanan dan kesalahan konfigurasi yang dapat menyebabkan kebocoran data pribadi, modifikasi informasi sensitif, atau mengganggu ketersediaan layanan.
Selama pekerjaan, yang berlangsung rata-rata 1-2 bulan, auditor mengulangi tindakan penyerang potensial 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 dalam komponen ini akan membantu segera masuk ke akun orang lain.
- Studi tentang model peran dan kontrol akses antara berbagai akun. Untuk penyerang, kemampuan untuk mengakses mesin virtual orang lain adalah target yang disambut baik.
- Kerentanan sisi klien. XSS / CSRF / CRLF / dll. Mungkin mungkin untuk menyerang pengguna lain melalui tautan jahat?
- Kerentanan di sisi server: RCE dan semua jenis suntikan (SQL / XXE / SSRF dan sebagainya). Kerentanan server biasanya lebih sulit ditemukan, tetapi mereka mengarah pada kompromi banyak pengguna sekaligus.
- Analisis isolasi segmen jaringan segmen pengguna. Untuk seorang penyerang, kurangnya isolasi secara signifikan meningkatkan permukaan serangan pada pengguna lain.
- Analisis logika bisnis. Apakah mungkin membodohi bisnis dan membuat mesin virtual secara gratis?
Dalam proyek ini, pekerjaan dilakukan sesuai dengan model Gray-box: auditor berinteraksi dengan layanan dengan hak istimewa pengguna biasa, tetapi sebagian memiliki kode sumber API dan memiliki kesempatan untuk mengklarifikasi detail dengan pengembang. Biasanya ini adalah yang paling nyaman, dan pada saat yang sama model pekerjaan yang cukup realistis: informasi orang dalam masih dapat dikumpulkan oleh penyerang, ini hanya masalah waktu.
Kerentanan Ditemukan
Sebelum auditor mulai mengirim berbagai muatan (payload, yang digunakan untuk menyerang) ke tempat-tempat acak, Anda perlu memahami cara kerjanya, fungsionalitas apa yang disajikan. Tampaknya ini adalah latihan yang sia-sia, karena di sebagian besar tempat yang diteliti tidak ada kerentanan. Tetapi hanya pemahaman tentang struktur aplikasi dan logika operasinya akan memungkinkan untuk menemukan vektor serangan yang paling kompleks.
Penting untuk menemukan tempat-tempat yang tampak mencurigakan atau sesuatu yang sangat berbeda dari yang lain. Dan kerentanan berbahaya pertama ditemukan dengan cara ini.
IDOR
Kerentanan IDOR (Referensi Objek Langsung Tidak Aman, tautan langsung tidak aman ke objek) adalah salah satu kerentanan paling umum dalam logika bisnis yang memungkinkan satu atau lain cara untuk mendapatkan akses ke objek yang aksesnya sebenarnya tidak diizinkan. Kerentanan IDOR menciptakan kemungkinan mendapatkan informasi pengguna dengan berbagai tingkat kekritisan.
Salah satu opsi IDOR adalah untuk melakukan tindakan dengan objek sistem (pengguna, rekening bank, barang dalam keranjang) dengan memanipulasi pengidentifikasi akses untuk objek ini. Ini mengarah pada konsekuensi yang paling tidak terduga. Misalnya, kemungkinan penggantian akun pengirim, yang dengannya Anda dapat mencuri mereka dari pengguna lain.
Dalam kasus MCS, auditor baru saja menemukan kerentanan IDOR yang terkait dengan pengidentifikasi non-sistem. Dalam akun pribadi pengguna, untuk akses ke objek apa pun, UUID digunakan, yang tampaknya, seperti yang dikatakan oleh petugas keamanan, sangat tidak-kotor (yaitu, dilindungi dari serangan brute force). Tetapi untuk entitas tertentu, ditemukan bahwa angka yang dapat diprediksi biasa digunakan untuk mendapatkan informasi tentang pengguna aplikasi. Saya pikir Anda menyadari bahwa Anda dapat mengubah ID pengguna dengan satu, mengirim permintaan lagi, dan dengan demikian mendapatkan informasi melewati ACL (daftar kontrol akses, aturan akses data untuk proses dan pengguna).
Pemalsuan Permintaan Sisi Server (SSRF)
Produk OpenSource bagus karena mereka memiliki sejumlah besar forum dengan deskripsi teknis terperinci tentang masalah yang muncul dan, jika Anda beruntung, dengan deskripsi solusinya. Tetapi koin ini memiliki sisi lain: kerentanan terkenal juga terperinci. Sebagai contoh, forum OpenStack memiliki deskripsi yang bagus tentang kerentanan
[XSS] dan
[SSRF] , yang karena alasan tertentu tidak ada yang terburu-buru untuk memperbaikinya.
Fungsionalitas aplikasi yang sering adalah kemampuan bagi pengguna untuk mengirim tautan ke server yang diklik server (misalnya, untuk mengunduh gambar dari sumber yang ditentukan). Dengan penyaringan keamanan yang tidak memadai dari tautan atau tanggapan itu sendiri dikembalikan dari server ke pengguna, fungsi seperti itu mudah digunakan oleh penyerang.
Kerentanan SSRF dapat sangat memajukan pengembangan serangan. Seorang penyerang bisa mendapatkan:
- akses terbatas ke jaringan lokal yang diserang, misalnya, hanya pada segmen jaringan tertentu dan pada protokol tertentu;
- akses penuh ke jaringan lokal, jika downgrade dimungkinkan dari tingkat aplikasi ke tingkat transportasi dan, sebagai akibatnya, manajemen muatan penuh di tingkat aplikasi;
- akses untuk membaca file lokal di server (jika file: /// skema didukung);
- dan masih banyak lagi.
OpenStack telah lama dikenal karena kerentanan SSRF "buta" nya: ketika Anda mengakses server, Anda tidak mendapat respons darinya, tetapi Anda mendapatkan berbagai jenis kesalahan / keterlambatan, tergantung pada hasil permintaan. Berdasarkan hal ini, Anda dapat memindai port pada host di jaringan internal, dengan semua konsekuensi berikutnya, yang tidak boleh diremehkan. Misalnya, suatu produk dapat memiliki API untuk back office, hanya tersedia dari jaringan perusahaan. Memiliki dokumentasi (jangan lupa tentang orang dalam), penyerang dapat menggunakan metode internal menggunakan SSRF. Misalnya, jika Anda entah bagaimana berhasil mendapatkan daftar perkiraan URL yang berguna, maka dengan menggunakan SSRF Anda dapat menjalaninya dan menjalankan permintaan - secara relatif, mentransfer uang dari akun ke akun atau mengubah batas.
Ini bukan kasus pertama mendeteksi kerentanan SSRF di OpenStack. Di masa lalu, dimungkinkan untuk mengunduh gambar VM ISO melalui tautan langsung, yang juga menyebabkan konsekuensi serupa. Fitur ini saat ini dihapus dari OpenStack. Tampaknya, masyarakat menganggap ini solusi termudah dan paling dapat diandalkan untuk masalah tersebut.
Dan dalam laporan yang tersedia untuk umum
ini dari layanan HackerOne (h1), eksploitasi SSRF non-blind dengan kemampuan untuk membaca contoh metadata mengarah ke akses Root ke seluruh infrastruktur Shopify.
Di MCS, di dua tempat dengan fungsi yang sama, kerentanan SSRF ditemukan, tetapi mereka hampir mustahil untuk dieksploitasi karena firewall dan perlindungan lainnya. Bagaimanapun juga, tim MCS memperbaiki masalah ini, tanpa menunggu komunitas.
XSS bukannya memuat kerang
Meskipun ada ratusan penelitian yang ditulis, dari tahun ke tahun XSS (serangan skrip lintas situs) masih merupakan kerentanan web yang paling
umum (atau
serangan ?).
Mengunduh file adalah tempat favorit bagi peneliti keamanan mana pun. Seringkali ternyata Anda dapat memuat skrip sewenang-wenang (asp / jsp / php) dan menjalankan perintah OS, dalam terminologi pentester - "load shell". Tetapi popularitas kerentanan seperti itu bekerja di kedua arah: mereka diingat dan dikembangkan alat melawan mereka, jadi baru-baru ini kemungkinan "memuat shell" cenderung nol.
Tim penyerang (diwakili oleh Keamanan Digital) beruntung. OK, di MCS, di sisi server, isi file yang diunduh diperiksa, hanya gambar yang diizinkan. Tapi SVG juga gambar. Dan apa gambar SVG yang berbahaya? Karena Anda dapat menanamkan fragmen JavaScript di dalamnya!
Ternyata file yang diunduh tersedia untuk semua pengguna layanan MCS - yang berarti Anda dapat menyerang pengguna cloud lainnya, yaitu, administrator.
Contoh menggunakan formulir masuk phishing menggunakan serangan XSSContoh mengeksploitasi serangan XSS:
- Mengapa mencoba mencuri sesi (terutama karena sekarang di mana-mana cookie HTTP-Only dilindungi dari pencurian menggunakan skrip js) jika skrip yang diunduh dapat segera mengakses API sumber daya? Dalam hal ini, payload dapat mengubah konfigurasi server melalui permintaan XHR, misalnya, menambahkan kunci SSH publik penyerang dan mendapatkan akses SSH ke server.
- Jika kebijakan CSP (kebijakan perlindungan konten) melarang implementasi JavaScript, penyerang dapat melakukannya tanpa itu. Dalam HTML murni, buat formulir login palsu dari situs dan curi kata sandi administrator melalui phishing tingkat lanjut: halaman phishing untuk pengguna berada pada URL yang sama, dan lebih sulit bagi pengguna untuk mendeteksinya.
- Akhirnya, seorang penyerang dapat mengatur DoS klien - mengatur cookie lebih besar dari 4 KB. Cukup bagi pengguna untuk membuka tautan satu kali dan seluruh situs menjadi tidak dapat diakses sampai Anda menebak secara khusus untuk membersihkan browser: dalam sebagian besar kasus server web akan menolak untuk menerima klien seperti itu.
Mari kita lihat contoh XSS lain yang terungkap, kali ini dengan operasi yang lebih rumit. Layanan MCS memungkinkan Anda menggabungkan pengaturan firewall ke dalam grup. XSS ditemukan dalam nama grup. Keunikannya adalah bahwa vektor tidak langsung bekerja, tidak ketika melihat daftar aturan, tetapi ketika grup dihapus:
Yaitu, skenarionya adalah sebagai berikut: seorang penyerang membuat aturan firewall dengan "memuat" dalam nama, administrator memperhatikannya setelah beberapa saat, memulai proses penghapusan. Dan di sini JS jahat juga memenuhi.
Untuk pengembang MCS, untuk melindungi terhadap XSS dalam gambar SVG yang dapat diunduh (jika tidak dapat ditinggalkan), tim Keamanan Digital merekomendasikan:
- Host file yang diunggah oleh pengguna di domain terpisah yang tidak ada hubungannya dengan "cookie". Script akan dieksekusi dalam konteks domain lain dan tidak akan menimbulkan ancaman bagi MCS.
- Dalam respons HTTP server, berikan tajuk "Content-disposition: attachment". Maka file akan diunduh oleh browser, dan tidak dieksekusi.
Selain itu, sekarang ada banyak cara yang tersedia bagi pengembang untuk mengurangi risiko pengoperasian XSS:
- menggunakan bendera "HTTP Only", Anda dapat membuat header sesi cookie tidak dapat diakses oleh JavaScript berbahaya;
- kebijakan CSP yang diterapkan dengan benar akan menyulitkan operasi XSS bagi penyerang;
- mesin templat modern, seperti Angular atau React, secara otomatis menghapus data pengguna sebelum menampilkannya di browser pengguna.
Kerentanan otentikasi dua faktor
Untuk meningkatkan keamanan akun, pengguna selalu disarankan untuk mengaktifkan 2FA (otentikasi dua faktor). Memang, ini adalah cara yang efektif untuk mencegah penyerang mendapatkan akses ke layanan jika kredensial pengguna telah dikompromikan.
Tetapi apakah penggunaan faktor otentikasi kedua selalu menjamin keamanan akun? Dalam implementasi 2FA, ada masalah keamanan seperti:
- Pencarian kasar kode OTP (kode satu kali). Terlepas dari kesederhanaan operasi, kesalahan seperti kurangnya perlindungan terhadap brute OTP juga ditemui oleh perusahaan besar: kasus Slack , kasus Facebook .
- Algoritma generasi lemah, misalnya, kemampuan untuk memprediksi kode berikut.
- Kesalahan logis, misalnya, kemampuan untuk meminta OTP orang lain di ponsel Anda, seperti halnya dengan Shopify.
Dalam kasus MCS, 2FA diimplementasikan berdasarkan Google Authenticator dan
Duo . Protokol itu sendiri telah diuji oleh waktu, tetapi implementasi verifikasi kode pada sisi aplikasi perlu diperiksa.
MCS 2FA digunakan di beberapa tempat:
- Saat otentikasi pengguna. Di sini ada perlindungan terhadap brute force: pengguna hanya memiliki beberapa upaya untuk memasukkan kata sandi satu kali, kemudian input diblokir untuk sementara waktu. Ini memblokir kemampuan untuk melakukan penghilang OTP.
- Saat membuat kode cadangan offline untuk menjalankan 2FA, serta mematikannya. Di sini, perlindungan terhadap brute force tidak diterapkan, yang memungkinkan dilakukannya regenerasi kode cadangan atau menonaktifkan 2FA sepenuhnya jika ada kata sandi untuk akun dan sesi aktif.
Mempertimbangkan bahwa kode cadangan terletak di kisaran nilai garis yang sama dengan yang dihasilkan oleh aplikasi OTP, peluang untuk mengambil kode dalam waktu singkat jauh lebih tinggi.
Proses memilih OTP untuk menonaktifkan 2FA menggunakan alat Burp: IntruderHasil
Secara umum, MCS sebagai produk ternyata aman. Selama audit, tim Pentester tidak dapat mengakses VM klien dan data mereka, dan kerentanan yang ditemukan dengan cepat diperbaiki oleh tim MCS.
Tetapi di sini penting untuk dicatat bahwa keamanan adalah pekerjaan yang berkelanjutan. Layanan tidak statis, mereka terus berkembang. Dan untuk mengembangkan produk sepenuhnya tanpa kerentanan tidak mungkin. Tetapi Anda dapat menemukannya tepat waktu dan meminimalkan kemungkinan pengulangan mereka.
Sekarang semua kerentanan yang disebutkan dalam MCS sudah diperbaiki. Dan untuk meminimalkan jumlah yang baru dan mempersingkat masa hidup mereka, tim platform terus melakukan ini: