Saya belum lama ini di IT, tetapi baru-baru ini saya terbawa oleh topik keamanan siber. Profesi pentester sangat menarik. Saat berselancar, saya melihat artikel keren "Bagaimana DB yang dikonfigurasi dengan buruk memungkinkan kita untuk memiliki seluruh cloud lebih dari 25K host" oleh Security Shenanigans. Terjemahan dari kedua bagian dan menarik perhatian Anda.
pengantar
Pada artikel ini, Anda akan mempelajari bagaimana kami berhasil melakukan koneksi sqlmap langsung ke database menggunakan BMC / IPMI untuk mengkompromikan klien besar.
Latar Belakang
Beberapa tahun lalu, tim kami menerima tugas: melakukan uji penetrasi infrastruktur di jaringan Openstack. Ini terdiri dari sekitar 2.000 server fisik yang menampung lebih dari 25.000 mesin virtual. Kami memulai pekerjaan kami di subnet kecil, di mana ada batasan jumlah lalu lintas keluar. Setelah pemindaian cepat, Nmap tidak dapat menemukan kerentanan yang jelas yang dapat dieksploitasi. Oleh karena itu, kami mulai mempelajari layanan yang tersedia bagi kami. Di antara mereka, kami menemukan server PostgreSQL yang tidak berdaya dihosting di server pengembangan. Setelah membuat daftar kata khusus dengan beberapa turunan dari nama perusahaan, kami dapat menyelinap ke sistem menggunakan data yang relatif sederhana dari akun. Nama pengguna adalah Postgres, dan kata sandi adalah "admin".
Selanjutnya, kami memutuskan untuk menggunakansqlmap . Alat ini dibuat untuk menggunakan injeksi SQL, tetapi juga dapat memberi Anda beberapa opsi saat membuat koneksi database langsung (saat Anda memiliki kredensial). Salah satu opsi ini adalah meluncurkan shell perintah terhadap database dalam produksi.
Setelah menguji shell, kami memutuskan untuk membuat payload (payload) kustom untuk mendapatkan koneksi balik. Ini akan memungkinkan untuk bekerja dengan lebih nyaman.
Kami membangun payload menggunakan msfvenom. Muatan dalam kasus ini adalah shell TCP terbalik untuk mesin Linux x64. Pada gambar sebelumnya, Anda dapat melihat bahwa kami perlu memilih arsitektur database.
Mengumpulkan muatan dengan msfvenom
Keuntungan dari payload ini adalah dapat digunakan untuk menghubungkan kembali menggunakan Netcat sederhana. Sebagian besar muatan lain memerlukan sesuatu seperti Metasploit (pilih exploit / multi / handler) untuk tugas yang sama.
Setelah menjalankan payload dengan sqlmap wrapper, kami mendapatkan koneksi ke server.
Meluncurkan Payload untuk Terhubung Kembali
dan Menguji Akses
Menggunakan perangkat BMC
Setiap kali Anda menjalankan uji penetrasi infrastruktur dan membahayakan mesin pada segmen jaringan baru, Anda harus memindai ulang untuk melihat apakah ada sesuatu yang baru yang muncul. Basis data ini memungkinkan kami untuk terhubung ke jaringan cloud perusahaan, termasuk sebagian besar mesin virtual dan host. Kami sangat senang dengan hasil pemindaian baru karena kami menemukan beberapa perangkat BMC.
Salah satu dari tiga perangkat BMC
BMC (Baseboard Management Controller, prosesor layanan) adalah perangkat tertanam pilihan yang terhubung ke server utama yang menyediakan pemantauan dan kontrol out-of-band. Ia bekerja secara independen dari CPU, BIOS dan sistem operasi. Kesalahan yang terjadi di salah satu elemen ini tidak dapat memengaruhi operasinya. Mikrokontroler memiliki prosesor, memori, antarmuka jaringan sendiri, sehingga tersedia meskipun server itu sendiri dimatikan. Semua pemasok peralatan utama memiliki BMC khusus untuk produk mereka:
- Dell DRAC
- IBM IMM
- HP iLO
- Supermicro IPMI
Istilah lain yang perlu Anda ketahui, IPMI (Intelligent Platform Management Interface) pada dasarnya adalah protokol yang Anda gunakan untuk berkomunikasi dengan perangkat ini. Tujuannya adalah untuk memantau dan mengelola perangkat keras server, apa pun sistem operasinya, bahkan ketika server dimatikan, tetapi terhubung ke sumber daya.
Anggap saja IPMI sejauh ini merupakan salah satu protokol paling tidak aman yang dapat Anda temukan. Untuk memberi Anda gambaran, IPMI 2.0 dirancang sedemikian rupa sehingga Anda dapat langsung meminta hash kustom dari server selama langkah otentikasi. Kerentanan lain muncul saat Anda meminta otorisasi dalam mode "cipher 0", yang memungkinkan Anda masuk dengan sandi apa pun.
Arsitektur blok IPMI
Perangkat BMC yang mungkin Anda temukan biasanya tidak terlindungi dengan baik, karena ini adalah jenis perangkat yang dikonfigurasi sekali, selama fase perakitan pusat data, dan kemudian digunakan hanya ketika server tidak tersedia dengan cara konvensional.
Kami dapat dengan mudah mengautentikasi pada beberapa perangkat yang cipher 0 diaktifkan .
Di sini Anda dapat melihat bagaimana kami masuk dengan kata sandi acak. Perhatikan bagian "-C 0".
Berhasil masuk ke perangkat dengan kata sandi acak
Informasi jaringan untuk perangkat
Meskipun sandi 0 tidak diaktifkan di beberapa perangkat, Anda masih memiliki cara lain untuk masuk. Dua yang paling terkenal adalah menggunakan kredensial default (yang biasanya tidak dicoba diubah oleh sysadmin) atau mengeksploitasi kerentanan pengungkapan hash (dan kemudian memecahkan hash). Yang terakhir harus dilakukan untuk sebagian besar perangkat.
Banal default username / password pairs untuk sebagian besar pengguna
Daftar kata yang berisi hash pengguna yang kami minta dari server
Memperluas hash khusus menggunakan metasploit
Segera kami mendapatkan data tentang hash biasa
Setelah melalui semua hash, kami mulai memecahkannya.
Memecahkan hash pertama
Dalam beberapa menit kami mendapat akses ke sekitar 600 BMC.
609 hash berhasil dipecahkan
Ada beberapa perangkat HP ILO yang tidak dapat kami pecahkan . Beruntung bagi kami, HP iLO 4 1.00 hingga 2.50 juga memiliki bypass otentikasi. Ini memungkinkan Anda untuk membuat akun administrator melalui buffer overflow di header koneksi HTTP yang diproses oleh server web. Eksploitasi menggunakan ini untuk mendapatkan akses istimewa ke seluruh API, yang pada gilirannya memberi Anda izin untuk membuat akun.
Menggunakan CVE-2017-12542
Setelah langkah-langkah ini, kami mendapatkan kendali penuh atas 90% perangkat BMC perusahaan. Jika Anda pernah membaca tentang perangkat BMC, Anda sekarang tahu bahwa mereka memungkinkan Anda untuk:
- Pantau
- Mulai ulang
- Instal ulang
- KVM (virtualisasi)
perangkat yang terhubung. Ini bagus dan semuanya, tetapi mereka hanya mensimulasikan akses fisik ke server, Anda masih perlu masuk. Ya, Anda dapat bermain-main dengan mematikan perangkat, tetapi kami pikir itu tidak cukup, jadi kami terus menggali.
Salah satu cara paling umum untuk meretas perangkat keras yang memiliki alamat fisik adalah dengan mem-boot ulang dan mengontrol autorun untuk shell root. Anda dapat melakukan ini di Unix, Mac dan Windows.
Kesulitan dengan pendekatan ini adalah bahwa setiap server biasanya menampung sekitar 2000 host virtual. Jadi, kami perlu mencari server yang tidak digunakan. Rencananya adalah mematikannya (atau hanya memulainya jika sudah mati) dan mengedit autorun untuk memberi kami akses root. Setelah itu, kami ingin melihat konfigurasi untuk menemukan bug / payload yang memungkinkan kami untuk menyusupi server lain juga.
Openstack memungkinkan Anda untuk menanyakan infrastruktur lokal dan menanyakan parameter tertentu. Salah satunya adalah status mesin virtual, yang dalam kasus perusahaan lokal ini didefinisikan sebagai ketersediaan VM (daftar putih / hitam untuk menerima lalu lintas) + status operasional (mulai / dinonaktifkan).
Kami perlu menemukan server yang masuk daftar hitam (status kerja tidak penting) dan kami menemukan satu server tidak berfungsi karena masalah disk. Untungnya, kami dapat melakukan booting, tetapi beberapa bagian dari sistem file berakhir dalam mode hanya-baca.
Permintaan Openstack untuk server yang cocok untuk diretas
Setelah kami menemukannya, kami masuk dengan kredensial yang kami temukan sebelumnya.
Menggunakan akses yang diperoleh sebelumnya
Akses ke antarmuka KVM
Antarmuka KVM mensimulasikan koneksi langsung ke server melalui BMC. Saat boot, Anda perlu mengedit Grub autoload dan menambahkan
ro init = / bin / bashke baris yang sesuai untuk boot ke shell root... Biasanya flag read / write (rw) digunakan, tetapi kami harus menggunakan flag read-only (ro) untuk mencegah masalah apapun dengan disk yang gagal.
Mengedit menu grub
Setelah masuk, kami memeriksa antarmuka jaringan untuk menguji konektivitas ke server. Seperti yang Anda lihat, ifconfig menunjukkan lebih dari 10 antarmuka aktif.
Setelah meluangkan waktu untuk menganalisis struktur jaringan dan memahami di mana kami berada, kami mulai mempelajari server.
Setelah beberapa menit, kami menemukan jalan tengah dengan bash_history (salah satu sumber terbaik informasi berharga yang dapat Anda temukan di mesin Linux)
kredensial novadb di bash_history
Bagi mereka yang tidak terbiasa dengan arsitektur Openstack, Nova adalah database manajemen yang menyimpan informasi administratif untuk seluruh cloud, seperti sertifikat, kuota, nama instance, metadata, dan banyak informasi penting lainnya .
Memeriksa kredensial
Setelah masuk, kami memeriksa akses admin menggunakan grants_MySQL.
Setelah melakukan ini, kita dapat melihat struktur internal NovaDB.
Tabel di database Novadb
Melihat informasi tentang VM, kami dapat melihat sekitar 34 ribu perangkat. Namun, sekitar sepertiga dari mereka tidak tersedia / tidak berfungsi. Jumlah tepatnya dapat dilihat di entri baris float_ips.
Izinkan saya menjelaskan mengapa data dari database ini sangat penting.
Jika Anda ingin menutup seluruh perusahaan, Anda dapat mematikan setiap server virtual melalui antarmuka BMC. Mereka tidak akan berfungsi sampai sysadmin mengaktifkan kembali semuanya.
Anda dapat menulis malware Anda sendiri untuk menginfeksi semua server, tetapi penyebaran massal melalui saluran BMC tidaklah mudah (ingat kami harus memulai server yang tidak digunakan untuk mengedit autorun Grub sebelum mengaksesnya).
Namun, dengan akses ke NovaDB, Anda cukup merusak database dan seluruh lingkungan cloud akan berhenti berfungsi. Bahkan dengan asumsi sysadmin cukup pintar untuk melihat sekilas database, jauh lebih sulit untuk memecahkan masalah database yang rusak daripada database yang hilang.
Selain itu, administrator sistem dapat mengetahui bahwa ada sesuatu yang salah dan hanya menimpa semuanya dengan cadangan terbaru, bukan? Kami juga memikirkannya. Inilah sebabnya kami melanjutkan dan membahayakan cadangan.
Pada awalnya kami mencoba untuk menanyakan database utama dengan sesuatu seperti
SELECT * FROM information_schema.PROCESSLIST AS p WHERE p.COMMAND = 'Binlog Dump'; , tetapi perusahaan menggunakan solusi cadangannya sendiri yang berjalan tidak teratur dan tidak menggunakan skema master / slave. Jadi kami terus memindai subnet tetangga, hanya untuk menemukan database cadangan yang berjalan di port yang sama dengan yang utama.
Bagaimana kami berhasil menemukan cadangan
Kami memeriksa kemungkinan menggunakan kredensial yang ada dan, tentu saja, mereka muncul.
Memverifikasi akses ke cadangan
Dengan cadangan kami sendiri, kami dapat membuktikan kompromi lengkap infrastruktur virtualisasi, serta cara untuk menyelesaikan operasi dalam hitungan menit.
Saya selalu ingin mengakhiri tinjauan / laporan dengan kemungkinan perbaikan untuk masalah yang ditemukan. Apalagi jumlahnya banyak, misalnya:
- Menggunakan kembali kredensial
- Tidak ada segmentasi jaringan
- Kata sandi banal
- Struktur cadangan tidak aman
- Firmware yang kedaluwarsa
Salah satu masalah penting yang tidak mudah diperbaiki adalah kelemahan dalam protokol IPMI.
Solusi yang paling berhasil adalah menempatkan server yang mendukung BMC di segmen jaringan yang berbeda dengan daftar alamat IP yang terbatas dan terkontrol. Inilah yang akhirnya dilakukan perusahaan ini.
Saya harap Anda menikmati cerita kami. Kami senang mempelajari topik ini.