S3 Ep102.5: „ProxyNotShell” Schimb de erori – un expert vorbește [Audio + Text] PlatoBlockchain Data Intelligence. Căutare verticală. Ai.

S3 Ep102.5: „ProxyNotShell” Schimb de erori – un expert vorbește [Audio + Text]

Marca temporală: 1 octombrie 2022 10:05

by
Paul Ducklin

NU ENTRATI IN PANICĂ… DAR FIȚI PREGATIT SĂ ACȚIONEAZĂ

Cu Paul Ducklin și Chester Wisniewski

Muzică intro și outro de Edith Mudge.

Faceți clic și trageți pe undele sonore de mai jos pentru a trece la orice punct. Poti de asemenea asculta direct pe Soundcloud.

Ne puteți asculta pe SoundCloud, Podcast-uri Apple, Podcast-uri Google, Spotify, stitcher și oriunde se găsesc podcasturi bune. Sau pur și simplu aruncați URL-ul fluxului nostru RSS în podcatcher-ul tău preferat.

CITIȚI TRANSCRIPTUL

[MODEM MUZICAL]

RAȚĂ.  Bună tuturor.

Bun venit la un alt mini-episod special al podcastului Naked Security.

Sunt Paul Ducklin, căruia i s-a alăturat din nou prietenul și colegul meu Chester Wisniewski.

Bună, Chet.

CHET.  [ACCENT AUSSIE FALS] Bună ziua, Duck.

RAȚĂ.  Ei bine, Chet, sunt sigur că toată lumea ascultă. dacă ascultă la scurt timp după ce a apărut podcastul, știe despre ce vom vorbi!

Și trebuie să fie asta cu dublu-tepă Microsoft Exchange zero-day care a ieșit la spălare aproape în ultima zi a lunii septembrie 2022:

Amicii noștri de vânzări spun: „Oh, este sfârșitul lunii, este sfârșitul trimestrului, este un moment frenetic... dar mâine toată lumea primește o resetare la 0 USD.”

Nu va fi așa în acest weekend pentru administratorii de sistem și managerii IT!

CHET.  Duck, cred, în cuvintele nemuritoare ale dragului decedat Douglas Adams, "NU VĂ PANICAȚI" ar putea fi în ordine.

Multe organizații nu își mai găzduiesc propriile e-mailuri on-premise pe serverele Exchange, așa că o mulțime de oameni pot respira adânc și pot lăsa puțin timp să treacă în acest weekend, fără a fi prea stresați din cauza asta.

Dar dacă rulați Exchange on-premise...

…dacă aș fi eu, s-ar putea să lucrez ore suplimentare doar pentru a pune în aplicare câteva atenuări, pentru a fi sigur că nu am o surpriză neplăcută luni sau marți când asta, după toate probabilitățile, se va transforma în ceva mai mult dramatic.

RAȚĂ.  Deci este CVE-2022-41040 și CVE-2022-41042… asta e destul de o gură.

Am văzut că se face referire la asta pe Twitter ca ProxyNotShell, deoarece are unele asemănări cu ProxyShell vulnerabilitatea care a fost marea poveste în urmă cu puțin peste un an,

Dar, deși are acele asemănări, este o pereche complet nouă de exploit-uri care se înlănțuiesc, dând potențial execuție de cod la distanță - este corect?

CHET.  Așa sună.

Aceste vulnerabilități au fost descoperite în timpul unui atac activ împotriva unei victime, iar o organizație vietnameză numită GTSC a dezvăluit aceste două noi vulnerabilități care au permis adversarilor să obțină acces la unii dintre clienții lor.

Se pare că au dezvăluit în mod responsabil acele vulnerabilități la Zero Day Initiative [ZDI], care este condusă de Trend Micro pentru raportarea responsabilă a vulnerabilităților zero-day.

Și, bineînțeles, ZDI a împărtășit, la rândul său, toată această informație cu Microsoft, cu puțin peste trei săptămâni în urmă.

Și motivul pentru care apare astăzi este că cred că grupul vietnamez...

…se pare că devin puțin nerăbdători și îngrijorați că au trecut trei săptămâni și că nu au fost emise alerte sau sfaturi care să ajute la protejarea oamenilor împotriva acestor presupuși actori ai statului național.

Așa că au decis să tragă un semnal de alarmă și să spună tuturor că trebuie să facă ceva pentru a se proteja.

RAȚĂ.  Și, ca să fiu corect, au spus cu atenție: „Nu vom dezvălui exact cum să exploatam aceste vulnerabilități, dar vă vom oferi măsuri de atenuare pe care le-am găsit eficiente.”

Se pare că oricare exploatare în sine nu este deosebit de periculoasă...

… dar înlănțuite, înseamnă că cineva din afara organizației, care are capacitatea de a citi e-mailurile de pe serverul dvs., ar putea folosi prima eroare pentru a deschide ușa și a doua eroare pentru a implanta, în esență, malware pe serverul dvs. Exchange.

CHET.  Și acesta este un punct foarte important de subliniat, Duck, că ai spus: „Cineva care poate citi e-mailurile pe serverul tău.”

Acesta nu este un atac *neautentificat*, așa că atacatorii trebuie să aibă ceva informații despre organizația dvs. pentru a executa cu succes aceste atacuri.

RAȚĂ.  Acum, nu știm exact ce fel de acreditări au nevoie, pentru că la momentul în care înregistrăm acest lucru [2022-09-30T23:00:00Z], totul este în mare parte secret.

Dar din ceea ce am citit (de la oameni în care înclin să cred), se pare că cookie-urile de sesiune sau jetoanele de autentificare nu sunt suficient de bune și că de fapt ai avea nevoie de parola unui utilizator.

După ce am furnizat parola, totuși, dacă a existat autentificare cu doi factori [2FA], primul bug (cel care deschide ușa) se declanșează *între punctul în care este furnizată parola și punctul în care ar fi codurile 2FA. solicitat*.

Deci aveți nevoie de parolă, dar nu aveți nevoie de codul 2FA...

CHET.  Se pare că este o „vulnerabilitate de autentificare medie”, dacă doriți să o numiți așa.

Aceasta este o binecuvântare mixtă.

Înseamnă că un script Python automat nu poate doar scana întregul internet și poate exploata fiecare server Exchange din lume în câteva minute sau ore, așa cum am văzut că se întâmplă cu ProxyLogon și ProxyShell în 2021.

Am văzut revenirea viermilor în ultimele 18 luni, în detrimentul multor organizații.

RAȚĂ.  „Vierme”?

CHET.  Vierme, da! [râde]

RAȚĂ.  Este un cuvânt?

Ei bine, dacă nu este, acum este!

Îmi place asta... S-ar putea să-l împrumut, Chester. [râde]

CHET.  Cred că acesta este ușor viermeabil, nu?

Aveți nevoie de o parolă, dar, din păcate, găsirea unei combinații de adresă de e-mail și parolă valabilă la orice server Exchange dat nu este probabil prea dificilă.

Când vorbiți despre sute sau mii de utilizatori... în multe organizații, unul sau doi dintre ei sunt probabil să aibă parole slabe.

Și s-ar putea să nu fi fost exploatat până în prezent, deoarece pentru a vă conecta cu succes la Outlook Web Access [OWA] este nevoie de tokenul lor FIDO, sau autentificatorul lor sau orice al doilea factor pe care îl utilizați.

Dar acest atac nu necesită acel al doilea factor.

Deci, doar obținerea unei combinații de nume de utilizator și parolă este o barieră destul de scăzută...

RAȚĂ.  Acum este o altă complexitate aici, nu-i așa?

Și anume că deși Ghidul Microsoft spune oficial că clienții Microsoft Exchange Online pot renunța la Blue Alert, este periculos doar dacă aveți Exchange on-premise...

…există un număr surprinzător de oameni care au trecut la cloud, probabil în urmă cu câțiva ani, care rulau atât serviciul lor on-premises, cât și serviciul lor cloud în același timp în timpul schimbării, care nu au ajuns niciodată să oprească serviciul on-premises Server de schimb.

CHET.  Exact!

Am văzut asta revenind la ProxyLogin și ProxyShell.

În multe cazuri, criminalii au intrat în rețeaua lor prin servere Exchange pe care credeau că nu le au.

De exemplu, cineva nu a verificat lista de VM care rulează pe serverul lor VMware pentru a observa că serverele lor migratoare Exchange care îi ajutau în timpul ridicării datelor între rețeaua locală și rețeaua cloud...

… erau încă, de fapt, activate, activate și expuse internetului.

Și mai rău, atunci când nu se știe că sunt acolo, este și mai puțin probabil să fi fost peticiți.

Adică, organizațiile care au Exchange cel puțin probabil își fac tot posibilul să programeze întreținerea lor în mod regulat.

Dar când nu știi că ai ceva în rețea „pentru că ai uitat”, ceea ce este foarte ușor cu VM-urile, te afli într-o situație și mai proastă, pentru că probabil nu ai aplicat actualizări Windows sau actualizări Exchange.

RAȚĂ.  Iar legea lui Murphy spune că dacă te bazezi cu adevărat pe acel server și nu ai grijă de el în mod corespunzător, se va prăbuși cu o zi înainte să ai cu adevărat nevoie de el.

Dar dacă nu știi că este acolo și că ar putea fi folosit de rău, șansele ca acesta să funcționeze ani și ani și ani fără probleme sunt probabil destul de mari. [râde]

CHET.  Da, din păcate, asta a fost cu siguranță experiența mea!

Sună prostesc, dar scanarea propriei rețele pentru a afla ce aveți este ceva pe care v-am recomanda oricum să faceți în mod regulat.

Dar cu siguranță, când auziți despre un buletin ca acesta, dacă este un produs pe care știți că l-ați folosit în trecut, cum ar fi Microsoft Exchange, este un moment bun să rulați acel buletin intern. Scanare Nmap...

… și poate chiar conectați-vă shodan.io și verificați-vă serviciile externe, doar pentru a vă asigura că toate aceste lucruri au fost oprite.

RAȚĂ.  Acum știm, din răspunsul propriu al Microsoft, că aceștia se îndepărtează frenetic să scoată patch-uri.

Când apar acele plasturi, ar fi bine să le aplicați destul de repede, nu-i așa?

Pentru că dacă vreun patch va fi vreodată vizat pentru inginerie inversă pentru a descoperi exploit, va fi ceva de genul acesta.

CHET.  Da, absolut, Duck!

Chiar și odată ce vei repara, va exista o fereastră de timp, nu?

Adică, de obicei Microsoft, oricum pentru Patch Tuesdays, își lansează patch-urile la 10.00:XNUMX, ora Pacificului.

Momentan, suntem la ora de vară, deci este UTC-7... deci, în jurul orei 17:00 UTC este de obicei momentul în care Microsoft lansează patch-uri, astfel încât majoritatea personalului lor are toată ziua pentru a răspunde apoi la interogările primite în Seattle. [Microsoft HQ este în Bellevue, Seattle, WA.]

Cheia aici este că există un fel de „cursă” de ore, poate de minute, în funcție de cât de ușor este de exploatat, înainte de a începe să se întâmple.

Și din nou, revenind la acele exploatări Exchange anterioare cu ProxyShell și ProxyLogon, am constatat adesea că chiar și clienții care au aplicat corecții în trei, patru, cinci zile...

…care, pentru a fi sincer, este oarecum rapid pentru un server Exchange, sunt foarte greu de corectat, fiind implicate multe teste pentru a vă asigura că este fiabil înainte de a vă întrerupe serverele de e-mail.

A fost suficient timp pentru ca acele servere să ajungă webshell-uri, cryptominers, tot felul de backdoors instalat pe ele.

Și astfel, când patch-ul oficial este lansat, nu numai că trebuie să acționați rapid...

…*după* acționați, merită să vă întoarceți și să verificați temeinic acele sisteme pentru dovezi că poate că au fost atacate în intervalul dintre momentul în care patch-ul a devenit disponibil și când ați putut să-l aplicați.

Sunt sigur că vor fi multe conversații despre Naked Security și mai departe Twitter și în alte locuri, vorbind despre tipurile de atacuri pe care le vedem, astfel încât să știți ce să căutați.

RAȚĂ.  În timp ce puteți merge să căutați o grămadă de hashe-uri de malware cunoscut care a fost distribuit deja într-un număr limitat de atacuri...

… într-adevăr, concluzia este că tot felul de malware sunt posibilități.

Și așa, așa cum cred că ai spus în ultimul mini-episod ceea ce am făcut, nu mai este suficient să așteptați alertele despre ceva rău care s-a întâmplat să apară în tabloul de bord:

Trebuie să ieși proactiv și să te uiți, în cazul în care escrocii au fost deja în rețeaua ta și au lăsat ceva în urmă (care ar fi putut fi acolo de secole!) pe care nu l-ai observat încă.

CHET.  Deci cred că asta ne conduce către, „Ce facem acum, în timp ce așteptăm plasturele?”

A fost lansat blogul Microsoft Security Research Center (MSRC). unele sfaturi de atenuare și detalii... atât cât este dispus să dezvăluie Microsoft în acest moment.

Aș spune, dacă ești un pur Microsoft Exchange Online client, sunteți destul de clar și ar trebui să fiți atenți în cazul în care lucrurile se schimbă.

Dar dacă vă aflați într-o situație hibridă sau încă mai rulați Microsoft Exchange on-premise, cred că probabil că există ceva de lucru care merită făcut în această după-amiază sau mâine dimineață, dacă nu altceva.

Desigur, la momentul înregistrării, aceasta este vineri după-amiază... deci, într-adevăr, când asculți asta, „Imediat, ori de câte ori o auzi, dacă nu ai făcut-o deja”.

Care sunt cele mai bune practici aici, Duck?

Evident, un lucru pe care îl puteți face este să dezactivați accesul web extern până când un patch este disponibil.

Ai putea doar să închizi serverul tău IIS și apoi asta o va face!

RAȚĂ.  Bănuiesc că multe companii nu vor fi în această poziție.

Și Microsoft enumeră două lucruri pe care le spun... ei bine, ei nu le spun, „Acesta cu siguranță va funcționa.”

Ei sugerează că vă va limita foarte mult riscul.

Una este că există o regulă de rescriere a URL-ului pe care o puteți aplica serverului dvs. IIS. (Înțeleg că IIS acceptă conexiunea de intrare care se transformă în acces la serviciile web Exchange [EWS].)

Deci, există o setare IIS pe care o puteți face care va căuta exploatările probabile ale primei gauri, ceea ce va împiedica pornirea declanșării PowerShell.

Și există câteva porturi TCP pe care le puteți bloca pe serverul dvs. Exchange.

Cred că este portul 5985 și 5986, care va opri ceea ce se numește PowerShell la distanță… va opri introducerea acestor comenzi necinstite de execuție la distanță PowerShell în serverul Exchange.

Rețineți, totuși, că Microsoft spune că acest lucru vă va „limita” expunerea, mai degrabă decât să promite că știe că rezolvă totul.

Și asta se poate datora faptului că bănuiesc că există și alte moduri prin care acest lucru ar putea fi declanșat, dar pur și simplu nu și-au dat seama încă ce sunt. [râde]

Nicio setare nu este ceva pe care îl faceți în Exchange în sine.

Unul dintre ele este în IIS, iar celălalt este un fel de regulă de filtrare a rețelei.

CHET.  Ei bine, asta ne ajută să trecem în următoarele câteva zile, în timp ce Microsoft ne oferă o soluție permanentă.

Vestea bună este că cred că o mulțime de software de securitate, fie că este un IPS care poate fi integrat în firewall-ul tău, sau produse de securitate endpoint pe care le ai, protejează infrastructura Microsoft Windows Server...

…atacurile pentru acest lucru, în multe cazuri (cel puțin rapoartele timpurii), arată foarte asemănător cu ProxyLogon și, ca urmare, nu este clar dacă regulile existente vor proteja împotriva acestor atacuri.

S-ar putea, dar în plus, majoritatea vânzătorilor par să încerce să le înăsprească puțin, pentru a se asigura că sunt cât mai pregătiți posibil, pe baza tuturor indicatorilor care au fost în prezent partajați public, astfel încât să detecteze și să vă trimită alerte dacă acestea ar avea loc pe serverele dvs. Exchange.

RAȚĂ.  Este corect, Chester.

Și vestea bună pentru clienții Sophos este că puteți urmări detectările specifice Sophos dacă doriți să vă uitați prin jurnalele.

Nu doar pentru IPS, fie că este vorba de IPS de pe firewall sau de endpoint, dar avem și o grămadă de reguli de comportament.

Puteți urmări acele nume de detectare dacă doriți să le căutați... urmați-le pe @SophosXops Feed Twitter.

Pe măsură ce primim noi nume de detectare pe care le puteți folosi pentru vânătoarea de amenințări, le publicăm acolo, astfel încât să le puteți căuta cu ușurință:

CHET.  Sunt sigur că vom avea mai multe de spus despre podcastul de săptămâna viitoare, fie că este vorba de Doug care ți se alătură sau dacă sunt din nou în scaunul de invitat.

Dar sunt destul de încrezător că nu vom putea pune asta în pat pentru o perioadă de timp acum...

RAȚĂ.  Cred că, la fel ca ProxyShell, ca Log4Shell, va fi un ecou care va reverbera de ceva timp.

Deci, poate că ar fi mai bine să spunem, așa cum facem întotdeauna, Chester:

Pana data viitoare…

AMBII.  Rămâi în siguranță.

[MODEM MUZICAL]

Timestamp-ul:

Mai mult de la Securitate goală