Cara hack server Exchange sing ora ditambal nganggo kode PowerShell nakal – Keamanan Naked

Kurang saka rong wulan kepungkur, sawetara warta bug sing kuwatir: sepasang kerentanan nol dina diumumake ing Microsoft Exchange.

Minangka kita menehi saran ing wektu, iki kerentanan, resmi ditetepake CVE-2022-41040 lan CVE-2022-41082:

[were] rong dina nul sing [could] dirantai bebarengan, karo bug pisanan digunakake mbatalake kanggo mbukak cukup bolongan kanggo micu bug kapindho, sing duweni potensi ngidini eksekusi kode remot (RCE) ing server Exchange dhewe.

Kerentanan pisanan kaya bolongan keamanan ProxyShell sing ngganggu lan akeh disalahake wiwit Agustus 2021, amarga ana hubungane karo prilaku mbebayani ing fitur Autodiscover Exchange, sing diterangake dening Microsoft minangka protokol sing “Digunakake dening Outlook lan EAS [Exchange ActiveSync] pelanggan kanggo nemokake lan nyambung menyang kothak layang ing Exchange”.

Untunge, kesalahan Autodiscover sing bisa dimanfaatake ing serangan ProxyShell dening pangguna remot, manawa mlebu utawa ora, ditambal luwih saka setahun kepungkur.

Sayange, tambalan ProxyShell ora cukup kanggo nutup eksploitasi kanggo pangguna sing wis dikonfirmasi, sing ndadékaké CVE-2022-40140 nul-dina anyar, sing enggal-enggal kanthi laconically, yen misleading, dijuluki ProxyNotShell.

Ora kaya mbebayani, nanging mbebayani

Cetha, ProxyNotShell ora ana sing mbebayani kaya ProxyShell asli, amarga mbutuhake akses sing diarani minangka akses asli, mula ora bisa disalahake dening sapa wae saka ngendi wae.

Nanging kanthi cepet katon manawa ing pirang-pirang server Exchange, ngerti jeneng lan sandhi logon pangguna apa wae bakal cukup kanggo lulus minangka otentikasi lan masang serangan iki, sanajan pangguna kasebut kudu nggunakake otentikasi rong faktor (2FA) kanggo mlebu kanthi bener kanggo ngakses. email sing.

Minangka ahli Sophos, Chester Wisniewski, ing wektu kasebut:

Iku “kerentanan mid-authentication”, yen sampeyan pengin nyebataken. Kuwi berkah campuran. Iki tegese skrip Python otomatis ora mung bisa mindai kabeh internet lan duweni potensi ngeksploitasi saben server Exchange ing saindenging jagad sajrone sawetara menit utawa jam, kaya sing kedadeyan karo ProxyLogon lan ProxyShell ing taun 2021. […]

Sampeyan mbutuhake tembung sandhi, nanging nemokake siji alamat email lan kombinasi tembung sandhi sing bener ing server Exchange apa wae mbokmenawa ora angel banget, sayangé. Lan sampeyan bisa uga ora entuk eksploitasi nganti saiki, amarga kasil mlebu menyang Outlook Web Access [OWA] mbutuhake token FIDO, utawa authenticator, utawa faktor liya sing bisa digunakake.

Nanging serangan iki ora mbutuhake faktor liya. […] Mung entuk kombinasi jeneng pangguna lan sandhi minangka alangi sing sithik.

Kaya sing sampeyan ngerteni, akeh sing nganggep (utawa paling ora ngarep-arep) yen Microsoft bakal cepet-cepet ndandani bolongan ProxyNotShell, amarga isih ana rong minggu nganti Patch Selasa Oktober.

Nanging kita padha kuciwa kanggo nemokake sing fix dipercaya ketoke luwih Komplek saka samesthine, lan Oktober teka lan lunga karo ProxyNotShell ditangani mung dening workarounds, ora dening patch tepat.

Malah Patch Selasa Nopember ora langsung nyedhiyakake perbaikan sing dibutuhake, sanajan patch kasebut metu ing dina sing padha minangka bagean saka nganyari keamanan khusus Exchange sing bisa dijupuk lan diinstal kanthi kapisah:

Bukti-konsep dicethakaké

Saiki bledug wis rampung lan kabeh wong duwe wektu kanggo nambal server Exchange (paling ora, sing ora dilalekake), peneliti ing Zero Day Initiative (ZDI), sing kerentanan kasebut diwiwiti kanthi tanggung jawab kanggo dikirim menyang Microsoft, wis nerangake carane kewan omo bisa dieksploitasi.

Kabar ala, gumantung saka pendapat sampeyan babagan pambocoran eksploitasi sing jelas, yaiku tim ZDI saiki kanthi efektif nyedhiyakake bukti-konsep (PoC) sing nerangake carane nyerang server Exchange.

Kabar apik, mesthi, yaiku:

  • Saiki kita bisa sinau lan ngerti kewan omo dhewe. Iki ora mung mbantu kita kabeh kanggo mesthekake yen pancegahan sakabèhé sing wis dijupuk (ora mung winates kanggo patching) kamungkinan kanggo nyedhiyani pangayoman kita nyana, nanging uga ngandhani kita bab laku programming sing bakal pengin supaya ing mangsa, supaya kita ora. ‘t njaluk kepepet menyang mbukak munggah kewan omo jenis iki ing kita dhewe server-sisih kode.
  • Saiki ora ana alesan kanggo ora nglamar patch kasebut. Yen kita wis nyeret sikil babagan nganyari, panjelasan ZDI babagan sebabe serangan kasebut bisa nggawe manawa obat kasebut luwih disenengi kanggo penyakit kasebut.

Cara kerjane

Panjelasan ZDI babagan kerentanan iki ndadekake crita sing nggumunake babagan carane kompleks bisa nggabungake kabeh bagean sing dibutuhake kanggo ngowahi kerentanan dadi eksploitasi sing sregep.

Sampeyan uga kudu diwaca kanggo mbantu sampeyan ngerti sebabe ngeduk eksploitasi sing wis ana bisa mbantu mbukak cara liya yen kerentanan bisa disalah gunakake, sing bisa nyebabake patch tambahan, ndesek owah-owahan konfigurasi, lan promosi praktik pemrograman anyar sing bisa uga ora jelas mung didandani. mbenakake bolongan asli.

Panjelasan kasebut, perlu, rumit lan cukup teknis, lan ndadékaké sampeyan maju liwat sawetara langkah sing dawa kanggo entuk eksekusi kode remot (RCE) ing pungkasan.

Kanthi pangarep-arep bisa nulungi sampeyan ngetutake rincian tingkat dhuwur kanthi luwih gampang yen sampeyan mutusake maca laporan ZDI, iki ringkesan sing muga-muga ora gampang banget kanthi langkah-langkah sing kadhaptar kanthi mbalikke…

…supaya sampeyan bakal ngerti luwih dhisik kenapa crita kasebut njupuk arah:

  • STEP 4. Mbatalake trick Exchange menyang instantiating obyek .NET Sampéyan, karo parameter initialization Sampéyan.

Ing coding modern, an obyek instantiated iku tembung jargon kanggo cuwilan diparengake memori, kanthi otomatis initialized karo data lan sumber daya sing bakal perlu nalika iku dienggo, lan disambungake menyang pesawat tartamtu saka fungsi sing bisa operate ing. (enggal iku mung tembung apik kanggo nggawe.)

Obyek bisa diatur lan dikontrol dening sistem operasi dhewe, kanggo ngindhari kesalahan manajemen memori sing umum ing basa kayata C, sing biasane sampeyan kudu ngalokasi memori dhewe, ngisi kolom data sing relevan kanthi tangan, lan elinga. ngeculake memori lan sumber daya sing sampeyan gunakake, kayata soket jaringan utawa file disk, yen wis rampung.

Obyek umume nduweni fungsi terprogram sing digandhengake karo sing diarani a tukang gawesing dieksekusi kanthi otomatis nalika obyek anyar digawe supaya bisa nyedhiyakake jumlah memori sing tepat lan sumber daya sistem sing bener.

Biasane, sampeyan kudu pass siji utawa luwih paramèter minangka bantahan kanggo konstruktor, kanggo ndudohke carane sampeyan pengin obyek diatur nalika diwiwiti.

Cukup, yen sampeyan instantiate, ngomong, a TextString obyek (kita nggawe jeneng kasebut, nanging sampeyan entuk ide) nggunakake parameter sing minangka senar teks kayata example.com:8888

…sampeyan bisa uga bakal entuk buffer memori sing diparengake kanggo nahan teks sampeyan, diinisialisasi supaya nduweni nilai sing padha karo sampeyan, yaiku teks mentah. example.com:8888.

Ing konteks kasebut, string teks sing dikirim minangka data menyang konstruktor obyek ora langsung nyebabake ancaman keamanan siber sing jelas nalika sampeyan micu konstruktor saka jarak jauh, kajaba ana kemungkinan penolakan layanan (DoS) kanthi bola-bali njaluk senar sing luwih gedhe lan luwih gedhe. nyoba ngilangi memori.

Nanging yen sampeyan pengin instantiate, ngomong, a ConnectedTCPClient obyek nggunakake parameter senar teks banget padha saka example.com:8888sampeyan bisa uga duwe buffer memori sing siap kanggo nahan data sauntara, bebarengan karo soket jaringan sing diwenehake dening sistem operasi sing siap ijol-ijolan data karo server. example.com liwat port TCP 8888.

Sampeyan bisa ndeleng risiko eksekusi kode remot ana, sanajan sampeyan ora tau ngirim data menyang soket sing mbukak, amarga sampeyan wis ngapusi server supaya nelpon menyang lokasi sing sampeyan kontrol.

Sampeyan bisa uga nemokake obyek sing diarani, ngomong, RunCmdAndReadOutputngendi senar teks sing dikirim minangka parameter, cukup secara harfiah, printah sing pengin mbukak kanthi otomatis sanalika obyek digawe, supaya sampeyan bisa ngumpulake output mengko.

Sanajan sampeyan ora nate bisa mbalekake output saka printah kasebut, mung instantiating obyek kasebut bakal ngidini sampeyan milih perintah sing bakal ditindakake, saéngga menehi eksekusi kode remot umum lan menehi risiko mung diwatesi dening hak akses saka proses server kasebut. .

Mesthi, serangan iki mung gampang yen sampeyan tekan ing tataran pungkasan, sing lagi ora mestine bisa nindakake, amarga Exchange wis allowlist ketat sing ngalangi saka milih sembarang obyek lawas kanggo instantiate.

Ing teori, mung obyek sing aman utawa beresiko rendah sing bisa digawe saka jarak adoh liwat PowerShell, supaya bisa nggawe imajiner kita. TextString ndhuwur, utawa a SimpleIntegerValuebisa dianggep bisa ditampa, dene a ConnectedTCPClient emas wis RunCmdAndReadOutput mesthi ora.

Nanging peneliti ZDI ngelingi yen sadurunge micu langkah pungkasan, dheweke bisa nindakake iki:

  • LANGKAH 3. Ngapusi Exchange saka adoh supaya mikir yen obyek beresiko rendah sing lulus tes safety, nyatane, obyek liyane sing dipilih.

Sanajan mangkono, sampeyan bisa uga ngarepake Exchange kanggo nyegah nggawe remot sanajan obyek sing beresiko rendah, kanggo nyuda ancaman kasebut.

Nanging para peneliti nemokake yen bisa:

  • STEP 2. Mbatalake trick Exchange menyang nggunakake sawijining Powershell Remoting fitur kanggo nggawe obyek adhedhasar parameter initialization kontrol externally.

Lan bisa uga amarga bolongan kaya ProxyShell sing mung ditambal:

  • STEP 1. Ngapusi Exchange kanggo nrima lan ngolah panjalukan web kanthi kode kanthi ngemas sing bener username:password lapangan menyang panyuwunan uga.

Sanajan pangguna sing dijenengi ing panyuwunan kasebut ora mlebu log, lan kudu ngliwati sawetara proses 2FA kanggo ngakses kothak layang dhewe, penyerang sing ngerti username:password kombinasi bakal duwe informasi otentikasi cukup kanggo trick Exchange kanggo nampa sambungan web sing bisa digunakake kanggo kick mati chain serangan diterangake ing langkah 2 kanggo 4 ndhuwur.

Loosely ngandika, sembarang sah username:password kombinasi bakal ditindakake, amarga “asli” dibutuhake mung kanggo nyegah Exchange nolak panjaluk HTTP ing ngarep.

Apa sing kudu ditindakake?

Elinga yen serangan iki mung bisa digunakake:

  • Yen sampeyan duwe server Exchange ing panggonan. Microsoft ngaku wis ngunci layanan maya dhewe kanthi cepet, mula Exchange Online ora kena pengaruh. Priksa manawa sampeyan ngerti ngendi server Exchange sampeyan. Sanajan sampeyan saiki nggunakake Exchange Online, sampeyan bisa uga duwe server ing panggonan sing mlaku, bisa uga ditinggalake kanthi ora sengaja saka proses migrasi sampeyan.
  • Yen server sampeyan unpatched. Priksa manawa sampeyan duwe aplikasi Exchange Software Update saka 2022-11-08 kanggo nutup kerentanan sing dibutuhake eksploitasi.
  • Yen server sampeyan isih nampa Otentikasi Dasar, uga dikenal minangka otentikasi warisan. Priksa manawa sampeyan duwe diblokir kabeh aspek otentikasi warisan supaya server sampeyan ora bakal nampa username:password header kasebut ing ndhuwur, lan ora bakal nampa panjalukan protokol Autodiscover beboyo ing Panggonan pisanan. Iki nyegah panyerang ngapusi server supaya bisa nampa trik instantiasi obyek sing kepepet, sanajan server kasebut ora ditambal.

Sampeyan bisa nglacak saka saran pencegahan, remediasi lan respon resmi, lan pelanggan Sophos bisa nglacak jeneng deteksi ancaman sing digunakake dening produk kita, liwat feed Twitter Sophos X-Ops (@SophosXOps).


Sinau luwih lengkap babagan Authentication Exchange lan OAUTH2

Klik-lan-seret ing gelombang swara ing ngisor iki kanggo skip menyang sembarang titik. Sampeyan uga bisa ngrungokake langsung ing Soundcloud.

Kanthi Paul Ducklin lan Chester Wisniewski
Musik intro lan outro dening Edith Mudge.


.

Leave a Comment

Your email address will not be published. Required fields are marked *