Cara meretas server Exchange yang belum ditambal dengan kode PowerShell nakal

Kurang dari dua bulan yang lalu, beberapa berita bug yang mengkhawatirkan muncul: sepasang kerentanan zero-day diumumkan di Microsoft Exchange.

Seperti yang kita disarankan pada saat itu, kerentanan ini, secara resmi ditunjuk CVE-2022-41040 dan CVE-2022-41082:

[adalah] dua hari nol yang [dapat] dirangkai bersama, dengan bug pertama digunakan dari jarak jauh untuk membuka lubang yang cukup untuk memicu bug kedua, yang berpotensi memungkinkan eksekusi kode jarak jauh (RCE) di server Exchange itu sendiri.

Kerentanan pertama mengingatkan pada yang merepotkan dan disalahgunakan secara luas lubang keamanan ProxyShell sejak Agustus 2021, karena mengandalkan perilaku berbahaya di fitur Autodiscover Exchange, dijelaskan oleh Microsoft sebagai protokol yaitu “digunakan oleh klien Outlook dan EAS [Exchange ActiveSync] untuk menemukan dan terhubung ke kotak surat di Exchange”.

Untungnya, kesalahan fitur Autodiscover yang dapat dieksploitasi dalam serangan ProxyShell oleh pengguna jarak jauh mana pun, baik yang masuk atau tidak, adalah ditambal lebih dari setahun yang lalu.

Sayangnya, tambalan ProxyShell tidak cukup untuk menutup eksploit ke pengguna yang diautentikasi, yang mengarah ke zero-day CVE-2022-40140 baru, yang segera singkat, jika menyesatkan, dijuluki ProxyNotShell.

Tidak berbahaya, tapi tetap berbahaya

Jelas, ProxyNotShell sama sekali tidak berbahaya seperti ProxyShell asli, karena memerlukan apa yang dikenal sebagai akses yang diautentikasi, sehingga tidak terbuka untuk disalahgunakan oleh sembarang orang dari mana saja.

Tetapi dengan cepat terungkap bahwa di banyak server Exchange, mengetahui nama masuk dan kata sandi pengguna mana pun akan cukup untuk lulus sebagai terotentikasi dan memasang serangan ini, bahkan jika pengguna itu sendiri perlu menggunakan otentikasi dua faktor (2FA) untuk masuk dengan benar untuk mengakses email mereka.

Sebagai pakar Sophos, Chester Wisniewski letakkan pada saat itu:

Ini adalah "kerentanan otentikasi tengah", jika Anda ingin menyebutnya begitu. Itu adalah berkat campuran. Artinya, skrip Python otomatis tidak dapat memindai seluruh internet dan berpotensi mengeksploitasi setiap server Exchange di dunia dalam hitungan menit atau jam, seperti yang kita lihat terjadi dengan ProxyLogon dan ProxyShell pada tahun 2021. […]

Anda memerlukan kata sandi, tetapi menemukan satu alamat email dan kombinasi kata sandi yang valid di server Exchange tertentu mungkin tidak terlalu sulit, sayangnya. Dan Anda mungkin belum dieksploitasi hingga saat ini, karena untuk berhasil masuk ke Outlook Web Access [OWA] memerlukan token FIDO, atau autentikatornya, atau faktor kedua apa pun yang mungkin Anda gunakan.

Tapi serangan ini tidak membutuhkan faktor kedua itu. […] Hanya memperoleh kombinasi nama pengguna dan kata sandi adalah penghalang yang cukup rendah.

Seperti yang mungkin Anda ingat, banyak dari kita berasumsi (atau setidaknya berharap) bahwa Microsoft akan segera memperbaiki lubang ProxyNotShell, mengingat masih ada dua minggu hingga Patch Selasa Oktober.

Tapi kami kecewa menemukan bahwa perbaikan yang andal ternyata lebih kompleks dari yang diharapkan, dan Oktober datang dan pergi dengan ProxyNotShell hanya ditangani dengan solusi, bukan dengan tambalan yang tepat.

Bahkan Patch Selasa November tidak secara langsung memberikan perbaikan yang diperlukan, meskipun tambalannya namun demikian keluar pada hari yang sama sebagai bagian dari pembaruan keamanan khusus Exchange yang dapat diambil dan diinstal secara terpisah:

Bukti konsep terungkap

Sekarang debu telah mengendap dan semua orang memiliki waktu untuk menambal server Exchange mereka (yang belum mereka lupakan, setidaknya), para peneliti di Zero Day Initiative (ZDI), yang kerentanan ini awalnya diungkapkan secara bertanggung jawab untuk diserahkan ke Microsoft, telah menjelaskan bagaimana bug dapat dieksploitasi.

Berita buruknya, bergantung pada pendapat Anda tentang pengungkapan eksploit terbuka, adalah bahwa tim ZDI kini telah secara efektif memberikan proof-of-concept (PoC) yang menjelaskan cara menyerang server Exchange.

Kabar baiknya, tentu saja, adalah:

• Kami sekarang dapat mempelajari dan memahami bug sendiri. Ini tidak hanya membantu kita semua untuk memastikan bahwa keseluruhan tindakan pencegahan yang telah kita ambil (tidak hanya terbatas pada penambalan) cenderung memberikan perlindungan yang kita harapkan, tetapi juga memberi tahu kita tentang praktik pemrograman yang ingin kita hindari di masa depan, jadi kita tidak jangan terjebak untuk membuka bug semacam ini di kode sisi server kami sendiri.
• Kami sekarang tidak memiliki alasan lagi untuk tidak menerapkan tambalan. Jika kita berlambat-lambat untuk memperbarui, penjelasan ZDI tentang mengapa serangan itu berhasil memperjelas bahwa penyembuhannya pasti lebih baik daripada penyakitnya.

Cara kerjanya

ZDI's penjelasan kerentanan ini membuat kisah yang menarik tentang betapa rumitnya untuk menyatukan semua bagian yang Anda butuhkan untuk mengubah kerentanan menjadi eksploitasi yang layak.

Ini juga layak dibaca untuk membantu Anda memahami mengapa menggali eksploit yang ada dapat membantu mengungkapkan cara lain di mana kerentanan dapat disalahgunakan, berpotensi mendorong tambalan tambahan, mendesak perubahan konfigurasi, dan mempromosikan praktik pemrograman baru yang mungkin tidak terlihat jelas hanya dengan memperbaiki lubang aslinya.

Penjelasannya, tentu saja, rumit dan cukup teknis, dan membawa Anda ke depan melalui serangkaian langkah panjang untuk mencapai eksekusi kode jarak jauh (RCE) di bagian akhir.

Dengan harapan dapat membantu Anda mengikuti detail tingkat tinggi dengan lebih mudah jika Anda memutuskan untuk membaca laporan ZDI, inilah ringkasan yang mudah-mudahan tidak terlalu disederhanakan dengan langkah-langkah yang tercantum secara terbalik…

…sehingga Anda akan mengetahui lebih awal mengapa cerita mengambil arah seperti itu:

• LANGKAH 4. Trik Exchange dari jarak jauh untuk membuat instance objek .NET pilihan Anda, dengan parameter inisialisasi pilihan Anda.

Dalam pengkodean modern, sebuah objek yang diinstansiasi adalah kata jargon untuk potongan memori yang dialokasikan, secara otomatis diinisialisasi dengan data dan sumber daya yang diperlukan saat sedang digunakan, dan terkait dengan serangkaian fungsi tertentu yang dapat beroperasi di dalamnya. (Memberi contoh hanya sebuah kata mewah untuk membuat.)

Objek dapat dikelola dan dikendalikan oleh sistem operasi itu sendiri, untuk membantu menghindari jenis kesalahan salah urus memori yang umum dalam bahasa seperti C, di mana Anda biasanya perlu mengalokasikan memori sendiri, mengisi bidang data yang relevan dengan tangan, dan ingat untuk lepaskan memori dan sumber daya yang Anda gunakan, seperti soket jaringan atau file disk, setelah selesai.

Objek umumnya memiliki fungsi terprogram yang terkait dengannya yang disebut a pembina, yang dijalankan secara otomatis saat objek baru dibuat untuk mengalokasikan jumlah memori yang tepat dan kumpulan sumber daya sistem yang benar.

Biasanya, Anda perlu meneruskan satu atau lebih parameter sebagai argumen ke konstruktor, untuk menunjukkan bagaimana Anda ingin objek dikonfigurasi saat dimulai.

Sederhananya, jika Anda memberi contoh, katakanlah, a TextString objek (kami membuat nama-nama ini, tetapi Anda mendapatkan idenya) menggunakan parameter yang merupakan string teks seperti example.com:8888...

... Anda mungkin akan berakhir dengan buffer memori yang dialokasikan untuk menampung teks Anda, diinisialisasi sehingga memiliki nilai yang sama dengan yang Anda berikan, yaitu teks mentah example.com:8888.

Dalam konteks itu, string teks yang diteruskan sebagai data ke konstruktor objek tidak segera menimbulkan ancaman keamanan siber yang jelas saat Anda memicu konstruktor dari jarak jauh, selain kemungkinan penolakan layanan (DoS) dengan berulang kali meminta string yang semakin besar ke mencoba menguras memori.

Tetapi jika Anda membuat contoh, katakanlah, a ConnectedTCPClient objek menggunakan parameter string teks yang sama dari example.com:8888, Anda mungkin berakhir dengan buffer memori yang siap untuk menyimpan data sementara, bersama dengan soket jaringan yang dialokasikan oleh sistem operasi yang siap untuk bertukar data dengan server example.com melalui port TCP 8888.

Anda dapat melihat risiko eksekusi kode jarak jauh di sana, bahkan jika Anda tidak pernah mengirim data apa pun ke soket terbuka, karena Anda telah mengelabui server agar menelepon ke rumah ke lokasi yang Anda kendalikan.

Anda bahkan mungkin menemukan objek bernama, katakanlah, RunCmdAndReadOutput, di mana string teks yang Anda kirim sebagai parameter, secara harfiah, adalah perintah yang ingin Anda jalankan secara otomatis segera setelah objek dibuat, sehingga Anda dapat mengumpulkan hasilnya nanti.

Bahkan jika Anda tidak pernah dapat memulihkan output dari perintah, hanya membuat instance objek seperti itu akan memungkinkan Anda memilih perintah untuk dijalankan, sehingga memberi Anda eksekusi kode jarak jauh generik dan menghadirkan risiko yang hanya dibatasi oleh hak akses dari proses server itu sendiri. .

Tentu saja, serangannya hanya semudah ini setelah Anda mencapai tahap terakhir, yang seharusnya tidak dapat Anda lakukan, karena Exchange memiliki daftar izin ketat yang mencegah Anda memilih objek lama apa pun untuk dibuat instance-nya.

Secara teori, hanya objek yang aman atau berisiko rendah yang dapat dibuat dari jarak jauh melalui PowerShell, sehingga membuat contoh imajiner kita TextString di atas, atau a SimpleIntegerValue, mungkin dianggap dapat diterima, sedangkan a ConnectedTCPClient atau RunCmdAndReadOutput pasti tidak akan.

Tetapi para peneliti ZDI memperhatikan bahwa sebelum memicu langkah terakhir, mereka dapat melakukan ini:

• LANGKAH 3. Trik dari jarak jauh Pertukaran dengan berpikir bahwa objek berisiko rendah yang lulus uji keamanan sebenarnya adalah objek lain pilihan Anda.

Meski begitu, Anda mungkin mengharapkan Exchange untuk mencegah pembuatan jarak jauh bahkan dari objek berisiko rendah, untuk meminimalkan ancaman lebih jauh.

Tetapi para peneliti menemukan bahwa mereka dapat:

• LANGKAH 2. Mengelabui Exchange dari jarak jauh untuk menggunakannya PowerShell Remoting fitur untuk membuat objek berdasarkan parameter inisialisasi yang dikontrol secara eksternal.

Dan itu dimungkinkan karena lubang mirip ProxyShell yang hanya setengah ditambal:

• LANGKAH 1. Menipu Exchange dari jarak jauh untuk menerima dan memproses permintaan web dengan kode dengan mengemas yang valid username:password bidang ke dalam permintaan juga.

Bahkan jika pengguna yang disebutkan dalam permintaan tidak benar-benar masuk, dan perlu melalui semacam proses 2FA untuk mengakses kotak surat mereka sendiri, seorang penyerang yang mengetahui username:password kombinasi akan memiliki informasi autentikasi yang cukup untuk mengelabui Exchange agar menerima koneksi web yang dapat digunakan untuk memulai rantai serangan yang dijelaskan pada langkah 2 hingga 4 di atas.

Secara longgar, apa pun valid username:password kombinasi akan dilakukan, mengingat bahwa "otentikasi" diperlukan hanya untuk mencegah Exchange menolak permintaan HTTP di muka.

Apa yang harus dilakukan?

Perhatikan bahwa serangan ini hanya berfungsi:

• Jika Anda memiliki server Exchange lokal. Microsoft mengklaim telah mengunci layanan cloud-nya sendiri dengan cepat, sehingga Exchange Online tidak terpengaruh. Pastikan Anda tahu di mana server Exchange Anda berada. Bahkan jika Anda sekarang menggunakan Exchange Online, Anda mungkin masih menjalankan server lokal, mungkin sisa dari proses migrasi Anda.
• Jika server Anda belum ditambal. Pastikan Anda memilikinya menerapkan Exchange Software Update 2022-11-08 untuk menutup kerentanan yang dibutuhkan eksploitasi.
• Jika server Anda masih menerima Autentikasi Dasar, dikenal juga sebagai autentikasi lawas. Pastikan Anda memilikinya memblokir semua aspek autentikasi lawas jadi server Anda tidak akan menerima username:password header yang disebutkan di atas, dan tidak akan menerima permintaan protokol Autodiscover yang berisiko. Ini menghentikan penyerang menipu server agar menerima trik instantiasi objek booby-trapped mereka, bahkan jika server itu tidak ditambal.

Anda dapat melacak saran pencegahan, remediasi, dan tanggapan resmi kami, dan pelanggan Sophos dapat melacak nama deteksi ancaman yang digunakan oleh produk kami, melalui umpan Twitter Sophos X-Ops (@SophosXOps).

Informasi baru telah dipublikasikan mengenai CVE-2022-41040 dan CVE-2022-41082: https://t.co/pHUVBjUeDI 1/3

— Sophos X-Ops (@SophosXOps) November 21, 2022

---

PELAJARI LEBIH LANJUT TENTANG OTENTIKASI EXCHANGE DAN OAUTH2

Dengan Paul Ducklin dan Chester Wisniewski
Musik intro dan outro oleh Edith Mudge.

---