S3 Ep102.5: "ProxyNotShell" Exchange -virheet – asiantuntija puhuu [ääni + teksti]

Napsauta ja vedä alla olevia ääniaaltoja hypätäksesi mihin tahansa kohtaan. Voit myös kuuntele suoraan Soundcloudissa.

[MUSIIKKIMODEEMI]

---

ANKKA.  Hei kaikki.

Tervetuloa Naked Security -podcastin toiseen erityiseen minijaksoon.

Olen Paul Ducklin, johon liittyi jälleen ystäväni ja kollegani Chester Wisniewski.

Hei Chet.

---

CHET.  [FAKE AUSSIE ACCENT] Hyvää päivää, Duck.

---

ANKKA.  No, Chet, olen varma, että kaikki kuuntelevat. Jos he kuuntelevat pian podcastin ilmestymisen jälkeen, hän tietää, mistä puhumme!

Ja sen täytyy olla kaksipiippuinen Microsoft Exchangen nollapäivä joka ilmestyi pesussa aika lailla syyskuun 2022 viimeisenä päivänä:

Myyntiystävämme sanovat: "Voi, nyt on kuukauden loppu, on vuosineljänneksen loppu, on kiihkeää aikaa... mutta huomenna kaikki saavat nollauksen."

Se ei tule olemaan tällaista tänä viikonloppuna järjestelmänvalvojille ja IT-johtajille!

---

CHET.  Ankka, luulen, kuolleiden Douglas Adamsin kuolemattomilla sanoilla, "ÄLÄ HÄTÄÄNNY" saattaa olla kunnossa.

Monet organisaatiot eivät enää isännöi omaa sähköpostiaan paikan päällä Exchange-palvelimilla, joten suuri osa ihmisistä voi vetää syvään henkeä ja antaa kulua vähän aikaa tänä viikonloppuna stressaamatta siitä liikaa.

Mutta jos käytät Exchangea paikallisesti…

…jos olisin minä, voisin tehdä ylitöitä vain tehdäkseni muutamia lievennyksiä ollakseni varma, ettei minulla ole epämiellyttävää yllätystä maanantaina tai tiistaina, kun tästä todennäköisesti kehittyy jotain enemmän dramaattinen.

---

ANKKA.  Joten se on CVE-2022-41040 ja CVE-2022-41042… se on melkoinen suupala.

Olen nähnyt, että siihen viitataan Twitterissä nimellä ProxyNotShell, koska sillä on joitain yhtäläisyyksiä ProxyShell haavoittuvuus, joka oli suuri tarina hieman yli vuosi sitten,

Mutta vaikka siinä on näitä yhtäläisyyksiä, se on täysin uusi hyväksikäyttöpari, joka ketjuttaa yhteen ja mahdollistaa koodin etäsuorittamisen – pitääkö paikkansa?

---

CHET.  Tältä se kuulostaa.

Nämä haavoittuvuudet löydettiin uhria vastaan ​​tehdyn aktiivisen hyökkäyksen aikana, ja vietnamilainen organisaatio nimeltä GTSC selvitti nämä kaksi uutta haavoittuvuutta, joiden ansiosta vastustajat pääsivät käsiksi joihinkin asiakkaistaan.

Kuulostaa siltä, ​​että he ilmoittivat vastuullisesti niitä haavoittuvuuksia Trend Micron toteuttamaan Zero Day Initiative -aloitteeseen [ZDI], joka raportoi nollapäivän haavoittuvuuksista vastuullisesti.

Ja tietysti ZDI puolestaan ​​jakoi kaiken tämän tiedon Microsoftin kanssa hieman yli kolme viikkoa sitten.

Ja syy, miksi se ilmestyy tänään, on mielestäni se, että vietnamilainen ryhmä…

…kuulostaa siltä, ​​että he alkavat olla hieman kärsimättömiä ja huolestuneita siitä, että siitä on kulunut kolme viikkoa ja ettei mitään hälytyksiä tai neuvoja ollut lähetetty suojellakseen ihmisiä näiltä väitetyiltä kansallisvaltion toimijoilta.

Joten he päättivät nostaa hälytyskelloja ja kertoa kaikille, että heidän on tehtävä jotain suojellakseen itseään.

---

ANKKA.  Ja ollakseni rehellinen, he sanoivat varovasti: "Emme aio paljastaa tarkalleen, kuinka näitä haavoittuvuuksia voidaan hyödyntää, mutta aiomme tarjota sinulle tehokkaiksi katsomiamme lievennyksiä."

Kuulostaa siltä, ​​että kumpikaan hyväksikäyttö ei yksinään ole erityisen vaarallista…

…mutta ketjutettuna se tarkoittaa, että joku organisaation ulkopuolinen henkilö, joka pystyy lukemaan sähköpostin palvelimeltasi, voisi itse asiassa käyttää ensimmäistä virhettä oven avaamiseen ja toista virhettä käytännössä haittaohjelmien istuttamiseen Exchange-palvelimellesi.

---

CHET.  Ja se on todella tärkeä huomio, Duck, että sanoit, "Joku, joka osaa lukea sähköpostia palvelimellasi."

Tämä ei ole *todistamaton* hyökkäys, joten hyökkääjillä on oltava jonkin verran tietoa organisaatiostasi voidakseen suorittaa nämä hyökkäykset onnistuneesti.

---

ANKKA.  Nyt emme tiedä tarkalleen, millaisia ​​valtuustietoja he tarvitsevat, koska nauhoitettaessa tätä [2022-09-30T23:00:00Z] kaikki on vielä suurelta osin salaista.

Mutta sen perusteella, mitä olen lukenut (henkilöiltä, ​​joita olen taipuvainen uskomaan), näyttää siltä, ​​​​että istuntoevästeet tai todennustunnukset eivät ole tarpeeksi hyviä ja että tarvitset itse asiassa käyttäjän salasanan.

Salasanan antamisen jälkeen kuitenkin, jos käytössä oli kaksivaiheinen todennus [2FA], ensimmäinen bugi (se, joka avaa oven) laukeaa *salasanan antamisen ja 2FA-koodien välissä. pyydetty*.

Tarvitset siis salasanan, mutta et tarvitse 2FA-koodia…

---

CHET.  Kuulostaa siltä, ​​​​että se on "keskitason todennuksen haavoittuvuus", jos sitä haluaa kutsua.

Se on sekalainen siunaus.

Se tarkoittaa, että automatisoitu Python-skripti ei voi vain skannata koko Internetiä ja mahdollisesti hyödyntää kaikkia Exchange-palvelimia maailmassa muutamassa minuutissa tai tunnissa, kuten näimme tapahtuvan ProxyLogonin ja ProxyShellin kanssa vuonna 2021.

Näimme madon paluun viimeisten 18 kuukauden aikana monien organisaatioiden kustannuksella.

---

ANKKA.  "Wormage"?

---

CHET.  Wormage, kyllä! [NAurua]

---

ANKKA.  Onko se sana?

No, jos ei ole, niin nyt on!

Pidän siitä… Voisin lainata sitä, Chester. [NAurua]

---

CHET.  Minusta tämä on lievästi madottavaa, eikö?

Tarvitset salasanan, mutta yhden sähköpostiosoitteen ja salasanan yhdistelmän löytäminen jokaisella Exchange-palvelimella ei valitettavasti ole liian vaikeaa.

Kun puhutaan sadoista tai tuhansista käyttäjistä… monissa organisaatioissa, yhdellä tai kahdella heistä on todennäköisesti huono salasana.

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ää.

Joten pelkkä käyttäjätunnuksen ja salasanan yhdistelmä on melko pieni este…

---

ANKKA.  Tässä on nyt toinen monimutkaisuus, eikö niin?

Nimittäin vaikka Microsoftin ohje sanoo virallisesti, että Microsoft Exchange Online -asiakkaat voivat luopua Blue Alertista, se on vaarallista vain, jos sinulla on paikan päällä oleva Exchange…

...yllättävän paljon ihmisiä, jotka siirtyivät pilveen mahdollisesti useita vuosia sitten ja jotka käyttivät sekä paikan päällä että pilvipalveluaan samaan aikaan siirtymisen aikana, eivät koskaan päässeet sammuttamaan paikan päällä Exchange-palvelin.

---

CHET.  Tarkasti!

Näimme tämän palaamalla ProxyLoginiin ja ProxyShelliin.

Monissa tapauksissa rikolliset pääsivät verkkoonsa Exchange-palvelimien kautta, joita heillä ei luuli olevan.

Kuten joku ei tarkistanut VMware-palvelimellaan käynnissä olevien VM-laitteiden luetteloa huomatakseen, että heidän siirtyvät Exchange-palvelimensa, jotka auttoivat heitä siirtämään tietoja paikallisen verkon ja pilviverkon välillä…

…olivat itse asiassa edelleen päällä, käytössä ja Internetissä.

Ja mikä pahempaa, kun heidän ei tiedetä olevan siellä, he ovat vielä vähemmän todennäköisempiä, että ne on korjattu.

Tarkoitan, että organisaatiot, joilla on Exchange, tekevät kaikkensa ajoittaakseen niiden huoltoa säännöllisesti.

Mutta kun et tiedä, että verkossasi on jotain "koska unohdit", mikä on todella helppoa virtuaalikoneiden kanssa, olet vielä huonommassa tilanteessa, koska et todennäköisesti ole asentanut Windows- tai Exchange-päivityksiä.

---

ANKKA.  Ja Murphyn laki sanoo, että jos todella luotat tuohon palvelimeen etkä huolehdi siitä kunnolla, se kaatuu vain päivää ennen kuin todella tarvitset sitä.

Mutta jos et tiedä, että se on olemassa ja sitä voitaisiin käyttää huonoon käyttöön, mahdollisuudet, että se toimii vuosia ja vuosia ja vuosia ilman mitään ongelmia, on todennäköisesti melko korkea. [NAurua]

---

CHET.  Kyllä, valitettavasti, se on varmasti minun kokemukseni!

Kuulostaa typerältä, mutta oman verkkosi skannaaminen saadaksesi selville, mitä sinulla on, suosittelemme joka tapauksessa suorittamaan säännöllisesti.

Mutta kun kuulet tällaisesta tiedotteesta, jos se on tuote, jota tiedät käyttäneesi aiemmin, kuten Microsoft Exchange, on hyvä aika suorittaa sisäinen Nmap-skannaus...

…ja ehkä jopa kirjautua sisään shodan.io ja tarkista ulkoiset palvelusi varmistaaksesi, että kaikki nämä asiat on poistettu käytöstä.

---

ANKKA.  Tiedämme nyt Microsoftin omasta vastauksesta, että he yrittävät kiihkeästi saada korjaustiedostoja pois.

Kun nuo laastarit ilmestyvät, sinun on parasta kiinnittää ne melko iloisesti nopeasti, eikö niin?

Koska jos jokin korjaustiedosto koskaan kohdistetaan käänteissuunnitteluun hyödyntämisen selvittämiseksi, se tulee olemaan jotain tämän tyyppistä.

---

CHET.  Kyllä, ehdottomasti, Ankka!

Jopa kun korjaat, siellä on aikaikkuna, eikö niin?

Tarkoitan, että tyypillisesti Microsoft julkaisee korjauspäivitystiistaisin korjaustiedostonsa klo 10.00 Tyynenmeren aikaa.

Tällä hetkellä elämme kesäaikaa, joten se on UTC-7… joten noin klo 17 UTC on yleensä Microsoftin päivityspäivien julkaisu, joten suurimmalla osalla heidän henkilöstöstään on koko päivä aikaa vastata saapuviin kyselyihin Seattlessa. [Microsoftin pääkonttori on Bellevuessa, Seattlessa, WA.]

Avain tässä on, että on eräänlainen tuntien, ehkä minuuttien "kilpajuoksu", riippuen siitä, kuinka helppoa tätä on hyödyntää, ennen kuin se alkaa tapahtua.

Ja taas, kun palataan aikaisempiin Exchange-hyödykkeisiin ProxyShellin ja ProxyLogonin kanssa, huomasimme usein, että jopa asiakkaat, jotka olivat korjanneet kolmen, neljän, viiden päivän kuluessa…

...joka on rehellisesti sanottuna melko nopea Exchange-palvelimelle, niitä on erittäin vaikea korjata, ja siihen liittyy paljon testausta, jotta voidaan varmistaa, että se on luotettava, ennen kuin rikot sähköpostipalvelimia.

Se riitti noille palvelimille verkkokuoret, cryptominers, kaikenlaisia takaportteja asennettu niihin.

Ja niin, kun virallinen korjaustiedosto on julkaistu, sinun ei tarvitse vain toimia nopeasti…

…*kun* toimit, kannattaa palata ja tarkistaa nämä järjestelmät perusteellisesti todisteiden varalta siitä, että niihin on mahdollisesti hyökätty korjaustiedoston julkaisun ja sen asentamisen välisenä aikana.

Olen varma, että Naked Securitysta keskustellaan paljon ja niin edelleen Twitter ja muissa paikoissa, puhumme näkemistämme hyökkäyksistä, jotta tiedät mitä etsiä.

---

ANKKA.  Vaikka voit mennä etsimään joukkoa tunnettujen haittaohjelmien tiivisteitä, joita on jaettu jo rajoitetuissa hyökkäyksissä…

…todellakin lopputulos on, että kaikenlaiset haittaohjelmat ovat mahdollisuuksia.

Ja niin, kuten luulen, että sanoit viimeinen minijakso Sen jälkeen, kun teimme, ei enää riitä vain odottaa, että kojelautaan tulee ilmoituksia tapahtuneesta pahasta:

Sinun täytyy mennä ulos ennakoivasti, jos roistot ovat jo olleet verkostossasi ja he ovat jättäneet taakseen jotain (mikä olisi voinut olla siellä ikuisuuden!), jota et ole vielä huomannut.

---

CHET.  Joten mielestäni se johtaa meidät kohti "Mitä teemme nyt, kun odotamme laastaria?"

Microsoft Security Research Centerin (MSRC) blogi julkaistiin joitain lieventäviä neuvoja ja yksityiskohdat… niin paljon kuin Microsoft on valmis paljastamaan tällä hetkellä.

Sanoisin, jos olet puhdas Microsoft Exchange Online asiakas, olet melko selvä ja sinun tulee vain kiinnittää huomiota, jos asiat muuttuvat.

Mutta jos olet hybriditilanteessa tai käytät edelleen Microsoft Exchangea paikan päällä, mielestäni on luultavasti jotain työtä, joka kannattaa tehdä tänään iltapäivällä tai huomenna aamulla, ellei muuta.

Tietenkin nauhoitushetkellä tämä on perjantai-iltapäivä… joten todellakin, kun kuuntelet tätä: "Välittömästi, aina kun kuulet sen, jos et ole jo tehnyt sitä."

Mitkä ovat parhaat käytännöt täällä, Duck?

Ilmeisesti yksi asia, jonka voit tehdä, on vain sammuttaa ulkoinen verkkoyhteys, kunnes korjaustiedosto on saatavilla.

Voisit vain sammuttaa IIS-palvelimesi ja sitten se onnistuu!

---

ANKKA.  Epäilen, että monet yritykset eivät ole tässä tilanteessa.

Ja Microsoft listaa kaksi asiaa, jotka he sanovat… no, he eivät sano, "Tämä toimii varmasti."

He ehdottavat, että se rajoittaa suuresti riskiäsi.

Yksi on se, että on olemassa URL-osoitteen uudelleenkirjoitussääntö, jota voit soveltaa IIS-palvelimeesi. (Ymmärtääkseni IIS hyväksyy saapuvan yhteyden, joka muuttuu pääsyksi Exchange Web Services -palveluun [EWS].)

Joten voit tehdä IIS-asetuksen, joka etsii ensimmäisen reiän todennäköisiä hyväksikäyttöjä, mikä estää PowerShell-laukaisun käynnistymisen.

Ja on olemassa joitakin TCP-portteja, jotka voit estää Exchange-palvelimessasi.

Uskon, että se on portti 5985 ja 5986, jotka pysäyttävät ns PowerShell Remoting…se estää näiden väärien PowerShell-etäsuorituskomentojen työntämisen Exchange-palvelimeen.

Huomaa kuitenkin, että Microsoft sanoo, että tämä "rajoittaa" altistumistasi sen sijaan, että lupaisi tietävänsä sen korjaavan kaiken.

Ja tämä voi johtua siitä, että he epäilevät, että tämä voidaan laukaista muilla tavoilla, mutta he eivät vain ole vielä täysin selvittäneet, mitä ne ovat. [NAurua]

Kumpikaan asetus ei ole asia, jota teet itse Exchangessa.

Toinen niistä on IIS:ssä ja toinen on jonkinlainen verkon suodatussääntö.

---

CHET.  Se auttaa meitä selviytymään muutaman seuraavan päivän aikana, kun Microsoft antaa meille pysyvän korjauksen.

Hyvä uutinen on, että mielestäni monet tietoturvaohjelmistot, olipa kyseessä sitten palomuurin integroitu IPS tai Microsoft Windows Server -infrastruktuuriasi suojaavat päätepisteiden tietoturvatuotteet...

…tätä koskevat hyökkäykset näyttävät monissa tapauksissa (ainakin varhaiset raportit) hyvin samanlaisilta kuin ProxyLogon, ja sen seurauksena on epäselvää, suojaavatko nykyiset säännöt näiltä hyökkäyksiltä.

Ne voivat, mutta sen lisäksi useimmat toimittajat näyttävät yrittävän tiukentaa niitä hieman varmistaakseen, että ne ovat mahdollisimman valmiita kaikkien tällä hetkellä julkisesti jaettujen indikaattoreiden perusteella, jotta he havaitsevat ja lähettää sinulle hälytyksiä, jos niitä tapahtuu Exchange-palvelimillasi.

---

ANKKA.  Se on oikein, Chester.

Ja hyvä uutinen Sophos-asiakkaille on, että voit seurata Sophos-kohtaisia ​​havaintoja, jos haluat käydä läpi lokejasi.

Ei vain IPS:lle, olipa kyseessä palomuurin IPS tai päätepiste, vaan meillä on myös joukko käyttäytymissääntöjä.

Voit seurata näitä tunnistusnimiä, jos haluat etsiä niitä… seuraa sitä @SophosXops Twitter-syöte.

Koska saamme uusia tunnistusnimiä, joita voit käyttää uhkien metsästykseen, julkaisemme ne siellä, jotta voit etsiä ne helposti:

Sophos X-Ops on lisännyt seuraavat havainnot:

Troj/WebShel-EC ja Troj/WebShel-ED havaitsevat hyökkäyksissä käsitellyt verkkokuoret.

IPS-allekirjoitus sid:2307757 perustuu Microsoftin julkaisemiin tietoihin sekä Sophos XG Firewallista että Sophos Endpoint IPS:stä.

- Sophos X-Ops (@SophosXOps) Syyskuu 30, 2022

---

CHET.  Olen varma, että meillä on enemmän sanottavaa ensi viikon podcastissa, liittyikö Doug takaisin vai olenko taas vieraspaikalla.

Mutta olen melko varma, että emme voi laittaa tätä nukkumaan pitkään aikaan….

---

ANKKA.  Luulen, että kuten ProxyShell, kuten Log4Shell, kaikua tulee kaikumaan jonkin aikaa.

Joten ehkä meidän olisi parempi sanoa, kuten aina, Chester:

Ensi kertaan…

---

Molemmat.  Pysy turvassa.

[MUSIIKKIMODEEMI]