Kuinka hakkeroida korjaamaton Exchange-palvelin väärällä PowerShell-koodilla

Alle kaksi kuukautta sitten julkistettiin huolestuttavia bugiuutisia: Microsoft Exchangessa julkistettiin pari nollapäivän haavoittuvuuksia.

Kuten olemme neuvottiin tuolloin, nämä haavoittuvuudet on virallisesti nimetty CVE-2022-41040 ja CVE-2022-41082:

[oli] kaksi nollapäivää, jotka [voi] ketjuttaa yhteen, jolloin ensimmäistä vikaa käytettiin etänä avaamaan tarpeeksi aukko toisen bugin laukaisemiseksi, mikä mahdollisesti mahdollistaa koodin etäsuorittamisen (RCE) itse Exchange-palvelimella.

Ensimmäinen haavoittuvuus muistutti hankalaa ja laajalti väärinkäytettyä ProxyShell-turva-aukko elokuussa 2021, koska se perustui Exchangen Autodiscover-ominaisuuden vaaralliseen toimintaan, Microsoftin kuvaama protokollana se on "Outlook- ja EAS [Exchange ActiveSync] -asiakassovellukset käyttävät Exchange-postilaatikoiden etsimiseen ja niihin muodostamiseen".

Onneksi Autodiscover-virhe, jota kuka tahansa etäkäyttäjä saattoi hyödyntää ProxyShell-hyökkäyksessä, oli hän kirjautunut tai ei. korjattu yli vuosi sitten.

Valitettavasti ProxyShell-korjaukset eivät tehneet tarpeeksi sulkeakseen hyväksikäyttöä todennetuilta käyttäjiltä, ​​mikä johti uuteen CVE-2022-40140 nollapäivään, joka oli pian lakonisesti, joskin harhaanjohtavasti, dubattuna ProxyNotShell.

Ei niin vaarallista, mutta vaarallista kuitenkin

On selvää, että ProxyNotShell ei ollut läheskään yhtä vaarallinen kuin alkuperäinen ProxyShell, koska se vaati ns. todennettua pääsyä, joten se ei ollut avoin kenelle tahansa mistä tahansa.

Mutta nopeasti kävi ilmi, että monilla Exchange-palvelimilla kenen tahansa käyttäjän kirjautumisnimen ja salasanan tietäminen riittäisi hyväksymään todennetun ja käynnistämään tämän hyökkäyksen, vaikka kyseisen käyttäjän olisi itse käytettävä kaksivaiheista todennusta (2FA) kirjautuakseen sisään kunnolla päästäkseen sisään. heidän sähköpostinsa.

Kuten Sophos-asiantuntija Chester Wisniewski laita se tällä hetkellä:

Se on "keskitason todennuksen haavoittuvuus", jos sitä niin haluaa kutsua. Se on sekalainen siunaus. Se tarkoittaa, että automatisoitu Python-skripti ei voi vain skannata koko Internetiä ja mahdollisesti hyödyntää jokaista Exchange-palvelinta maailmassa muutamassa minuutissa tai tunnissa, kuten näimme tapahtuvan ProxyLogonin ja ProxyShellin kanssa vuonna 2021. […]

Tarvitset salasanan, mutta yhden sähköpostiosoitteen ja salasanan yhdistelmän löytäminen jokaisella Exchange-palvelimella ei valitettavasti ole liian vaikeaa. Etkä ehkä ole hyödyntänyt sinua tähän mennessä, koska onnistuneesti Outlook Web Accessiin [OWA] kirjautuminen vaatii heidän FIDO-tunnuksensa tai todentajan tai mitä tahansa käyttämääsi toista tekijää.

Mutta tämä hyökkäys ei vaadi sitä toista tekijää. […] Pelkkä käyttäjätunnuksen ja salasanan yhdistelmä on melko matala este.

Kuten luultavasti muistat, monet meistä olettivat (tai ainakin toivoivat), että Microsoft kiirehtisi korjaamaan ProxyNotShell-aukkoja, koska lokakuun korjaustiistaihin oli vielä kaksi viikkoa.

Mutta olimme pettyneitä huomatessamme, että luotettava korjaus oli ilmeisesti tehty odotettua monimutkaisempi, ja lokakuu tuli ja meni, kun ProxyNotShell käsiteltiin vain kiertotapojen avulla, ei oikeilla korjaustiedostoilla.

Jopa marraskuun korjaustiistai ei tarjonnut tarvittavia korjauksia suoraan, vaikka korjaukset tuli kuitenkin ulos samana päivänä osana Exchange-kohtaista tietoturvapäivitystä, joka voidaan noutaa ja asentaa erikseen:

Käsitteen todisteet paljastettiin

Nyt kun pöly on laskeutunut ja kaikilla on ollut aikaa korjata Exchange-palvelimensa (ainakin ne, joita he eivät ole unohtaneet), Zero Day Initiativen (ZDI), jolle nämä haavoittuvuudet alun perin vastuullisesti luovutettiin, tutkijat. Microsoft, ovat selittäneet miten vikoja voidaan hyödyntää.

Huono uutinen, riippuen mielipiteestäsi avoimista hyväksikäyttöpaljoituksista, on se, että ZDI-tiimi on nyt toimittanut käytännössä proof-of-conceptin (PoC), jossa selitetään, kuinka Exchange-palvelimia vastaan ​​voidaan hyökätä.

Hyvä uutinen on tietysti tämä:

• Voimme nyt tutkia ja ymmärtää vikoja itse. Tämä ei ainoastaan ​​auta meitä kaikkia varmistamaan, että toteuttamamme yleiset varotoimet (eivät rajoitu pelkästään korjaukseen) tarjoavat todennäköisesti odottamamme suojan, mutta myös tiedottaa meille ohjelmointikäytännöistä, joita haluamme välttää tulevaisuudessa, joten emme Älä jää loukkuun paljastamaan tämän tyyppisiä virheitä omassa palvelinpuolen koodissamme.
• Meillä ei ole enää tekosyitä olla kiinnittämättä laastareita. Jos olemme venyneet päivittämisessä, ZDI:n selitys hyökkäyksen toimivuudesta tekee selväksi, että parannuskeino on ehdottomasti parempi kuin sairaus.

Kuinka se toimii

ZDI:t selitys Tästä haavoittuvuudesta saa kiehtovan tarinan siitä, kuinka monimutkaista voi olla ketjuttaa yhteen kaikki tarvittavat osat muuttaaksesi haavoittuvuuden käyttökelpoiseksi hyväksikäytöksi.

Se on myös lukemisen arvoinen, jotta ymmärrät, miksi olemassa olevaan hyväksikäyttöön kaivautuminen voi auttaa paljastamaan muita tapoja, joilla haavoittuvuutta voidaan käyttää väärin, mikä saattaa pyytää lisäkorjauksia, kehottaa tekemään muutoksia kokoonpanoon ja edistämään uusia ohjelmointikäytäntöjä, jotka eivät ehkä ole ilmeisiä pelkästään korjaamisen jälkeen. alkuperäinen reikä.

Selitys on väistämättä monimutkainen ja melko tekninen, ja johdattaa sinut eteenpäin pitkän sarjan vaiheiden läpi päästäksesi etäkoodin suorittamiseen (RCE) lopussa.

Auttaaksemme sinua seuraamaan korkean tason yksityiskohtia helpommin, jos päätät lukea ZDI-raportin, tässä on toivottavasti ei liian yksinkertaistettu yhteenveto, jossa on käänteiset vaiheet…

…joten tiedät etukäteen, miksi tarina noudattaa ohjeita:

• VAIHE 4. Huijaa Exchange etänä instantoimaan valitsemasi .NET-objekti valitsemallasi alustusparametrilla.

Nykyaikaisessa koodauksessa an instantoitu objekti on ammattislangi varatulle muistipalalle, joka alustetaan automaattisesti datalla ja resursseilla, joita se tarvitsee käytön aikana, ja on sidottu tiettyyn joukkoon toimintoja, jotka voivat toimia sitä. (Instantioida on vain hieno sana luoda.)

Objekteja voi hallita ja ohjata käyttöjärjestelmä itse, jotta vältytään sellaisilta muistin väärinhallintavirheiltä, ​​jotka ovat yleisiä C:n kaltaisissa kielessä, jolloin joudut yleensä varaamaan muistia itse, täyttämään tarvittavat tietokentät käsin ja muistamaan vapauta käyttämäsi muisti ja resurssit, kuten verkkopistokkeet tai levytiedostot, kun olet valmis.

Objekteihin liittyy yleensä ohjelmallinen toiminto, jota kutsutaan nimellä a rakentaja, joka suoritetaan automaattisesti, kun uusi objekti luodaan, jotta voidaan varata oikea määrä muistia ja oikea joukko järjestelmäresursseja.

Yleensä sinun on välitettävä rakentajalle argumentteina yksi tai useampi parametri, joka osoittaa, kuinka haluat objektin määritettävän sen käynnistyessä.

Yksinkertaisesti sanottuna, jos instantoi esimerkiksi a TextString objekti (keksimme nämä nimet, mutta ymmärrät idean) käyttämällä parametria, joka on itse tekstimerkkijono, kuten example.com:8888...

…luultavasti päädyt muistipuskuriin, joka on varattu tekstillesi, alustettu siten, että siinä on sama arvo, jonka välitit, nimittäin raakateksti example.com:8888.

Tässä yhteydessä objektin rakentajalle datana välitetty tekstimerkkijono ei heti aiheuta ilmeistä kyberturvallisuusuhkaa, kun käynnistät rakentajan etänä, paitsi mahdollisen palveluneston (DoS) pyytämällä toistuvasti yhä suurempia merkkijonoja yritä tyhjentää muisti.

Mutta jos instantoisit esimerkiksi a ConnectedTCPClient objekti käyttää samaa tekstimerkkijonoparametria example.com:8888, saatat päätyä muistipuskuriin, joka on valmis säilyttämään väliaikaiset tiedot, sekä käyttöjärjestelmän varaaman verkkopistorasian, joka on valmis vaihtamaan tietoja palvelimen kanssa. example.com TCP-portin kautta 8888.

Näet siellä koodin etäsuorittamisen riskin, vaikka et koskaan saisi lähettää tietoja avoimeen pistorasiaan, koska olet huijannut palvelimen soittamaan kotiin hallitsemaasi sijaintiin.

Saatat jopa löytää esineen nimeltä esim. RunCmdAndReadOutput, jossa parametrina lähettämäsi tekstijono on kirjaimellisesti komento, jonka haluat suorittaa automaattisesti heti objektin luomisen jälkeen, jotta voit kerätä sen tulosteen myöhemmin.

Vaikka et koskaan saisikaan palauttamaan komennon tulostetta, pelkkä sellaisen objektin luominen antaa sinulle mahdollisuuden valita suoritettavan komennon, mikä antaa sinulle yleisen etäkoodin suorituksen ja aiheuttaa riskin, jota rajoittavat vain palvelinprosessin itsensä käyttöoikeudet. .

Tietenkin hyökkäys on vain näin helppoa, kun pääset viimeiseen vaiheeseen, mitä sinun ei pitäisi pystyä tekemään, koska Exchangessa on tiukka sallittujen luettelo, joka estää sinua valitsemasta mitään vanhaa objektia instantioitavaksi.

Teoriassa vain turvallisia tai vähäriskisiä objekteja voidaan luoda etäyhteydellä PowerShellin kautta, jolloin kuvitteelliset mallimme toteutuvat. TextString edellä tai a SimpleIntegerValue, voidaan pitää hyväksyttävänä, kun taas a ConnectedTCPClient tai RunCmdAndReadOutput ei varmasti olisi.

Mutta ZDI-tutkijat huomaavat, että ennen viimeisen vaiheen käynnistämistä he voisivat tehdä tämän:

• VAIHE 3. Huijaa Exchange ajattelemaan, että turvallisuustestin läpäissyt vähäriskinen esine on itse asiassa jokin muu valitsemasi kohde.

Siitä huolimatta saatat odottaa Exchangen estävän jopa vähäriskisten objektien etäluomisen, mikä minimoi uhan entisestään.

Mutta tutkijat havaitsivat, että he voisivat:

• VAIHE 2. Huijaa Exchange etäkäyttöön PowerShell Remoting ominaisuus, jolla voit luoda objektin ulkoisesti ohjattujen alustusparametrien perusteella.

Ja se oli mahdollista ProxyShell-tyyppisen reiän ansiosta, joka oli vain puolipaikattu:

• VAIHE 1. Huijaa Exchange etäältä hyväksymään ja käsittelemään verkkopyyntö koodilla pakkaamalla kelvollinen username:password myös pyyntöön.

Vaikka pyynnössä nimetty käyttäjä ei todellakaan olisi kirjautunut sisään ja hänen pitäisi käydä läpi jonkinlainen 2FA-prosessi päästäkseen omaan postilaatikkoonsa, hyökkääjä, joka tiesi heidän username:password yhdistelmällä olisi tarpeeksi todennustietoja huijatakseen Exchangen hyväksymään verkkoyhteyden, jota voitaisiin käyttää edellä kohdissa 2–4 ​​kuvatun hyökkäysketjun käynnistämiseen.

Löyhästi sanottuna mikä tahansa pätevä username:password yhdistelmä toimisi, koska "todennus" tarvittiin yksinkertaisesti estämään Exchangea hylkäämästä HTTP-pyyntöä etukäteen.

Mitä tehdä?

Huomaa, että tämä hyökkäys toimii vain:

• Jos sinulla on paikallisia Exchange-palvelimia. Microsoft väittää lukineensa omat pilvipalvelunsa nopeasti, joten Exchange Online ei vaikuta siihen. Varmista, että sinä tietää, missä Exchange-palvelimesi ovat. Vaikka käyttäisit nyt Exchange Onlinea, paikalliset palvelimet saattavat silti olla käynnissä, ja ne saattavat jäädä vahingossa siirtoprosessistasi.
• Jos palvelimesi ovat korjaamattomia. Varmista, että olet otti käyttöön Exchange-ohjelmistopäivityksen 2022-11-08 että sulkea haavoittuvuudet joita hyväksikäyttö vaatii.
• Jos palvelimesi hyväksyvät edelleen perustodennuksen, joka tunnetaan myös nimellä vanha todennus. Varmista, että olet esti kaikki vanhan todennuksen näkökohdat joten palvelimesi eivät hyväksy username:password yllä mainitut otsikot, eivätkä hyväksy riskialttiita Autodiscover-protokollapyyntöjä. Tämä pysäyttää hyökkääjät huijaamalla palvelimen hyväksymään heidän loukkuun jääneiden objektien luontitemppunsa, vaikka palvelinta ei olisi korjattu.

Sinä pystyt pitää kirjaa virallisista ehkäisy-, korjaus- ja reagointineuvoistamme, ja Sophos-asiakkaat voivat seurata tuotteidemme käyttämiä uhkien havaitsemisen nimiä Sophos X-Ops Twitter -syötteen kautta (@SophosXOps).

Uusia tietoja on julkaistu koskien CVE-2022-41040 ja CVE-2022-41082: https://t.co/pHUVBjUeDI 1/3

- Sophos X-Ops (@SophosXOps) Marraskuussa 21, 2022

---

LUE LISÄÄ EXCHANGE AUTENTICATION JA OAUTH2:sta

Paul Ducklinin ja Chester Wisniewskin kanssa
Intro ja outro musiikki Edith Mudge.

---