Cum să piratați un server Exchange nepattchat cu cod PowerShell nepoliticos

În urmă cu puțin mai puțin de două luni, au apărut câteva știri îngrijorătoare despre erori: o pereche de vulnerabilități zero-day au fost anunțate în Microsoft Exchange.

Așa cum am sfătuit la acea vreme, aceste vulnerabilități, desemnate oficial CVE-2022-41040 și CVE-2022-41082:

[au fost] două zile zero care [ar putea] fi înlănțuite, prima eroare fiind folosită de la distanță pentru a deschide suficientă gaură pentru a declanșa a doua eroare, care poate permite executarea codului de la distanță (RCE) pe serverul Exchange însuși.

Prima vulnerabilitate amintea de cea supărătoare și abuzată pe scară largă gaură de securitate ProxyShell din august 2021, deoarece s-a bazat pe un comportament periculos în funcția de descoperire automată a Exchange, descris de Microsoft ca protocol care este „utilizat de clienții Outlook și EAS [Exchange ActiveSync] pentru a găsi și conecta la cutiile poștale în Exchange”.

Din fericire, eroarea Descoperire automată care ar putea fi exploatată în atacul ProxyShell de către orice utilizator la distanță, indiferent dacă este conectat sau nu, a fost patched acum mai bine de un an.

Din păcate, corecțiile ProxyShell nu au făcut suficient pentru a închide exploit-ul pentru utilizatorii autentificați, ceea ce a condus la noul CVE-2022-40140 zero-day, care a fost în curând lacon, chiar dacă înșelător, numit ProxyNotShell.

Nu la fel de periculos, dar periculos totuși

În mod clar, ProxyNotShell nu era nici pe departe la fel de periculos ca ProxyShell original, având în vedere că necesita ceea ce este cunoscut sub numele de acces autentificat, așa că nu era deschis abuzului de către oricine de oriunde.

Dar a reieșit rapid că pe multe servere Exchange, cunoașterea numelui de conectare și a parolei oricărui utilizator ar fi suficient pentru a trece ca autentificat și pentru a declanșa acest atac, chiar dacă acel utilizator ar trebui să folosească autentificarea cu doi factori (2FA) pentru a se conecta corect pentru a accesa e-mail-ul lor.

Ca expert Sophos Chester Wisniewski pune-l atunci:

Este o „vulnerabilitate la mijloc de autentificare”, dacă vrei să o numești 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. […]

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ă. Ș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. […] Doar obținerea unei combinații de nume de utilizator și parolă este o barieră destul de scăzută.

După cum probabil vă amintiți, mulți dintre noi au presupus (sau cel puțin au sperat) că Microsoft se va grăbi să remedieze găurile ProxyNotShell, având în vedere că mai erau două săptămâni până la Patch-ul de marți din octombrie.

Dar am fost dezamăgiți să constatăm că aparent era o remediere fiabilă mai complex decât se aștepta, iar octombrie a venit și a plecat cu ProxyNotShell abordat numai prin soluții de soluționare, nu prin patch-uri adecvate.

Nici măcar Patch Tuesday din noiembrie nu a furnizat direct remedierile necesare, deși patch-urile a iesit totusi în aceeași zi, ca parte a unei actualizări de securitate specifice Exchange, care ar putea fi preluată și instalată separat:

Dovada de concept dezvăluită

Acum, că praful s-a așezat și toată lumea a avut timp să-și patcheze serverele Exchange (cele de care nu le-au uitat, cel puțin), cercetătorii de la Zero Day Initiative (ZDI), cărora aceste vulnerabilități au fost inițial dezvăluite în mod responsabil pentru a fi transmise către Microsoft, au explicat cum pot fi exploatate bug-urile.

Vestea proastă, în funcție de părerea dvs. despre dezvăluirile de exploatare, este că echipa ZDI a furnizat acum efectiv o dovadă de concept (PoC) care explică cum să atace serverele Exchange.

Vestea bună, desigur, este că:

• Acum putem studia și înțelege bug-urile noi înșine. Acest lucru nu numai că ne ajută pe toți să ne asigurăm că măsurile generale de precauție pe care le-am luat (nu doar limitate la corecție) sunt susceptibile de a oferi protecția pe care o așteptăm, dar ne informează și despre practicile de programare pe care vom dori să le evităm în viitor, așa că nu Nu rămâneți prinși în deschiderea unor bug-uri de acest fel în propriul nostru cod de pe server.
• Acum nu mai avem scuze pentru a nu aplica plasturii. Dacă ne-am târât din picioare în privința actualizării, explicația ZDI despre de ce funcționează atacul arată clar că vindecarea este cu siguranță preferabilă bolii.

Abordarea Noastră

ZDI-uri explicație Această vulnerabilitate face o poveste fascinantă despre cât de complex poate fi să înlănțuim toate părțile de care aveți nevoie pentru a transforma o vulnerabilitate într-o exploatare viabilă.

De asemenea, merită citită pentru a vă ajuta să înțelegeți de ce explorarea unui exploit existent poate ajuta la dezvăluirea altor moduri prin care o vulnerabilitate ar putea fi utilizată greșit, provocând eventuale corecții suplimentare, îndemnând modificări de configurare și promovând noi practici de programare care ar fi putut să nu fi fost evidente doar din remediere. gaura originală.

Explicația este, în mod necesar, complicată și destul de tehnică și vă conduce înainte printr-o serie lungă de pași pentru a realiza execuția codului de la distanță (RCE) la sfârșit.

În speranța de a vă ajuta să urmăriți mai ușor detaliile de nivel înalt dacă decideți să citiți raportul ZDI, iată un rezumat, sperăm, nu prea simplificat, cu pașii enumerați invers...

… așa că veți ști dinainte de ce povestea ia direcțiile pe care le face:

• PASUL 4. Înșelați de la distanță Exchange să instanțieze un obiect .NET la alegere, cu un parametru de inițializare la alegere.

În codificarea modernă, an obiect instanțiat este cuvântul jargon pentru o bucată de memorie alocată, inițializat automat cu datele și resursele de care va avea nevoie în timp ce este în uz și legat de un set specific de funcții care pot opera pe ea. (Instanțiați este doar un cuvânt de lux pentru crea.)

Obiectele pot fi gestionate și controlate de sistemul de operare însuși, pentru a evita tipul de erori de gestionare greșită a memoriei comune într-un limbaj precum C, în care, de obicei, trebuie să alocați singur memoria, să completați manual câmpurile de date relevante și să vă amintiți eliberați memoria și resursele pe care le utilizați, cum ar fi prize de rețea sau fișiere de disc, când ați terminat.

Obiectele au, în general, o funcție programatică asociată cu ele numită a constructor, care este executat automat atunci când este creat un nou obiect pentru a aloca cantitatea potrivită de memorie și setul corect de resurse de sistem.

De obicei, trebuie să transmiteți unul sau mai mulți parametri ca argumente constructorului, pentru a indica modul în care doriți să fie configurat obiectul când pornește.

Mai simplu spus, dacă instanțiați, să spunem, a TextString obiect (creăm aceste nume, dar ați înțeles ideea) folosind un parametru care este el însuși un șir de text, cum ar fi example.com:8888...

… probabil veți ajunge cu un buffer de memorie alocat pentru a vă păstra textul, inițializat astfel încât să păstreze aceeași valoare pe care ați transmis-o, și anume textul brut example.com:8888.

În acest context, șirul de text transmis ca date către constructorul obiectului nu reprezintă imediat nicio amenințare evidentă pentru securitatea cibernetică atunci când declanșați constructorul de la distanță, în afară de o posibilă refuzare a serviciului (DoS) prin solicitarea în mod repetat a unor șiruri din ce în ce mai mari pentru încercați să epuizați memoria.

Dar dacă ar fi să instanțiați, să zicem, a ConnectedTCPClient obiect folosind același parametru șir de text al example.com:8888, s-ar putea să ajungeți cu un buffer de memorie gata să rețină date temporare, împreună cu un soclu de rețea alocat de sistemul de operare care este gata să schimbe date cu serverul example.com peste portul TCP 8888.

Puteți vedea acolo riscul de execuție a codului de la distanță, chiar dacă nu reușiți să trimiteți niciodată date către soclul deschis, având în vedere că ați păcălit serverul să sune acasă la o locație pe care o controlați.

S-ar putea chiar să găsiți un obiect numit, să zicem, RunCmdAndReadOutput, unde șirul de text pe care îl trimiteți ca parametru este, la propriu, o comandă pe care doriți să o rulați automat imediat ce obiectul este creat, astfel încât să puteți colecta rezultatul acestuia mai târziu.

Chiar dacă nu reușiți niciodată să recuperați rezultatul comenzii, doar instanțiarea unui astfel de obiect v-ar permite totuși să alegeți o comandă pe care să o rulați, oferindu-vă astfel execuție generică de cod la distanță și prezentând un risc limitat doar de drepturile de acces ale procesului serverului însuși. .

Desigur, atacul este atât de ușor odată ce ajungi la ultima etapă, ceea ce nu ar trebui să poți face, deoarece Exchange are o listă strictă de permise care te împiedică să alegi orice obiect vechi pe care să îl instanțiezi.

În teorie, numai obiectele sigure sau cu risc scăzut pot fi create de la distanță prin PowerShell, astfel încât instanțierea imaginarului nostru TextString mai sus, sau a SimpleIntegerValue, ar putea fi considerat acceptabil, în timp ce a ConnectedTCPClient sau un RunCmdAndReadOutput cu siguranta nu ar fi.

Dar cercetătorii ZDI observă că înainte de a declanșa ultimul pas, ar putea face acest lucru:

• PASUL 3. Înșelați de la distanță pe Exchange să creadă că un obiect cu risc scăzut care a trecut testul de siguranță este, de fapt, un alt obiect la alegerea dvs.

Chiar și așa, vă puteți aștepta ca Exchange să împiedice crearea de la distanță chiar și a obiectelor cu risc scăzut, pentru a minimiza și mai mult amenințarea.

Dar cercetătorii au descoperit că ar putea:

• PASUL 2. Înșelați de la distanță Exchange să-l folosească PowerShell la distanță caracteristică pentru a crea un obiect pe baza parametrilor de inițializare controlați extern.

Și asta a fost posibil datorită găurii asemănătoare ProxyShell, care a fost doar semi-corticată:

• PASUL 1. Înșelați de la distanță Exchange să accepte și să proceseze o solicitare web cu cod prin împachetarea unui document valid username:password câmp în cerere, de asemenea.

Chiar dacă utilizatorul numit în cerere nu a fost de fapt conectat și ar trebui să treacă printr-un fel de proces 2FA pentru a-și accesa propria cutie poștală, un atacator care își cunoștea username:password combinația ar avea suficiente informații de autentificare pentru a păcăli Exchange să accepte o conexiune web care ar putea fi folosită pentru a declanșa lanțul de atac descris în pașii de la 2 la 4 de mai sus.

Vag vorbind, orice valabil username:password combinația ar fi potrivită, având în vedere că „autentificarea” era necesară pur și simplu pentru a împiedica Exchange să respingă cererea HTTP în avans.

Ce să fac?

Rețineți că acest atac funcționează doar:

• Dacă aveți servere Exchange locale. Microsoft susține că și-a blocat rapid propriile servicii cloud, așa că Exchange Online nu este afectat. Asigură-te că știți unde sunt serverele dvs. Exchange. Chiar dacă acum utilizați Exchange Online, este posibil să aveți în continuare servere locale care rulează, poate rămase din greșeală din procesul dvs. de migrare.
• Dacă serverele dvs. sunt nepattchizate. Asigura-te ca ai a aplicat Actualizarea software-ului Exchange din 2022-11-08 la închideți vulnerabilitățile pe care exploatarea o cere.
• Dacă serverele dvs. acceptă în continuare autentificarea de bază, cunoscută și sub numele de autentificare moștenită. Asigura-te ca ai a blocat toate aspectele autentificării vechi astfel încât serverele dvs. nu vor accepta username:password anteturile menționate mai sus și nu vor accepta, în primul rând, solicitări riscante de protocol Autodiscover. Acest oprește atacatorii păcălirea unui server să-și accepte trucurile de instanțiere a obiectelor capcane, chiar dacă acel server nu este corectat.

Poti urmărește de sfaturile noastre oficiale de prevenire, remediere și răspuns, iar clienții Sophos pot urmări numele de detectare a amenințărilor utilizate de produsele noastre, prin intermediul fluxului Twitter Sophos X-Ops (@SophosXOps).

Au fost publicate noi informații cu privire la CVE-2022-41040 și CVE-2022-41082: https://t.co/pHUVBjUeDI 1/3

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

---

AFLAȚI MAI MULTE DESPRE AUTENTIFICAREA SCHIMB ȘI OAUTH2

Cu Paul Ducklin și Chester Wisniewski
Muzică intro și outro de Edith Mudge.

---