/* Urbjam un lāpam */

Ko darīt ar uzlauztu Exchange epasta serveri?

2021. gads Exchange adminiem atnesa daudz darba.

Iepriekš par šiem serveriem varēja daudz nedomāt. Kā jau visos epasta risinājumos, ik pa laikam bija jāpavēro diska vieta un jāpielāgo spam filtri, bet savādāk kārtīgi sakonfigurēts Exchange serveru pāris varēja strādāt gadiem bez būtiskām izmaiņām.

Tā tas bija līdz šī gada martam, kad ķīniešu pētnieks Orange Tsai publicēja ProxyLogon ievainojamību kopu un daudzas organizācijas atklāja, ka viņu serveri ir tikuši uzlauzti caur šīm ievainojamībām vēl pirms Microsoft izlaida savus ielāpus.

Nu jau pusgada laikā katru mēnesi tiek publicēti jauni ielāpi, kas labo kārtējos caurumus. Daudzas no šīm ievainojamībām atklāja tas pats pētnieks, Orange Tsai, kas prezentēja savu metodoloģiju DEF CON konferencē: ProxyLogon — Just Tip of the Iceberg, New Attack Surface on Exchange Server. Bet Exchange auditēšanai ir pievērsušies arī citi pētnieki, kompānijas un pat NSA.

Nupat 9. novembrī tika atklāta kārtējā kritiskā ievainojamība CVE-2021-42321, ko atkal uzbrucēji izmantojuši vēl pirms Microsoft patchu publicēšanas un kas noved pie Remote Code Execution (attālinātas patvaļīgā koda palaišanas), ļaujot uzbrucējiem pārņemt kontroli pār uzlauzto serveri.

Ņemot vērā lielo ievainojamību skaitu un daudzas automatizētās uzbrukumu kampaņas, visiem Microsoft Exchange administratoriem jāzin kā atpazīt uzlauztu serveri un kā rīkoties, ja ir aizdomas par servera inficēšanu.

Kādi serveri ir riska grupā?

Ievainojamības skar web komponentes (OWA, ECP, EWS). Vairumā gadījumu tiek ekspluatētas universālas problēmas web framework’ā, ko izmanto Exchange (CSRF, nedroša deserializācija). Līdz ar to liedzot pieeju noteiktai sadaļai (piem ECP) var apturēt konkrētu eksploitu, kurš izmanto tieši šo sadaļu, taču citi uzbrucēji var izmantot citu eksploitu, kurš turpinās darboties.

Drošākais preventīvais risinājums būtu liegt pieeju Exchange web portiem (80, 443) ārpus koporatīvā tīkla (VPN), taču praksē tāda konfigurācija gadās reti, jo daļa Outlook/Exchange funkcionalitātes darbojas tieši caur HTTP protokolu (t.sk. Autodiscover, MAPI un ActiveSync).

Papildus aizsardzību var nodrošināt Web Application Firewall (WAF), taču ir redzēti gadījumi, kur tas nav nostrādājis pat pret masveida uzbrukumiem (dēļ aizkavētiem datubāzes atjaunojumiem). Nulles dienas un targetotu uzbrukumu gadījumā WAF vispār ir bezspēcīgs.

Vairākas reizes šogad Microsoft ir norādījusi, ka uzbrucēji izmantojuši ievainojamības savvaļā vēl pirms tās tika atklātas publiski un pirms tika publicēti atjauninājumi. Faktiski tas nozīmē, ka jebkurš publiski pieejams Microsoft Exchange serveris varētu tikt uzlauzts, pat ja administratori godprātīgi instalējuši atjauninājumus tikko tie bija publicēti.

Kā atpazīt uzlauztu serveri?

Tas, kas tiek darīts ar uzlauzto serveri, ir atkarīgs no uzbrucēju motīviem. Dažas darbības ir pamanāmākas kā citas:

  • servera šifrēšana ar izpirkuma naudas pieprasīšanu
  • uzbrukumi Active Directory tīklam
  • konfigurācijas izmaiņas, kuras nav administratori nav veikuši
  • inficētu epastu (QakBot/SquirrelWaffle) izsūtīšana

Dažreiz gadās, ka serveris tiek uzlauzts vairākas reizes. Sākot analīzi ar samērā acīmredzamu infekciju (spamošana, izvietots webshell) var atklāties, ka serveris bijis inficēts jau labu laiku un iepriekšējie uzbrucēji līdz šim palikuši nepamanīti.

Proaktīvi pētot Exchange serveri, par infekciju liecina:

  • IIS vai Exchange direktorijās izvietoti jauni faili vai esošo failu modifikācijas (var atklāt pārbaudot failu hešus un modifikācijas laiku)
  • veiksmīgi pieprasījumi (200 kods) pie neparastiem vai failu sistēmā neesošiem failiem IIS žurnālfailos (bet webshell/backdoor var modificēt arī esošos failus, kā arī var atgriest maldinošus statusa kodus)
  • neizskaidrojami procesi, kas palaisti uz servera (it īpaši w3wp.exe child-processes)
  • specifiski indikatori žurnālfailos (atkarībā no dotā CVE)

Ko darīt, ja esat uzlauzti?

Vairums šī gada Exchange eksploitu noved līdz SYSTEM līmeņa tiesībām uz servera, kas ļauj uzbrucējiem instalēt rootkitus (ļaunatūra, kas darbojas Windows kodola līmenī un ļauj operētājsistēmai “melot”, apslēpjot ļaundabīgos procesus, failus, utt) kā arī “pārlekt” uz citiem organizācijas serveriem, kas savienoti caur Active Directory.

Ņemot vērā šos aspektus, visi Exchange serveru uzlaušanas gadījumi jāuzskata par kritiskiem, kamēr nav pierādīts pretējais. Tas nozīmē, ka inficētais serveris jāatslēdz no tīkla (gan publiskā, gan iekšējā), no tā jāsavāc pierādījumi un jāveic servera pārinstalēšana.

Pierādījumu vākšana ir tēma atsevišķam rakstam, bet kā minimums ieteicams saglabāt sistēmas diska attēlu. Ja ir iespēja veikt operatīvās atmiņas attēlu, vēlams savākt arī to (pie tam šī operācija jāveic pēc iespējas agrāk, pirms servera pārstartēšanas).

Ja pieejamas uzticamas rezerves kopijas, pilnas pārinstalēšanas vietā var atjaunot serveri no šādas kopijas. Jāizmanto gana veca kopija, lai ir pārliecība, ka uz to brīdi serveris vēl nav bijis inficēts. Datuma izvēli apgrūtina tas, ka šogad vairākas no atklātajām ievainojamībām ir bijušas izmantotas pirms Microsoft ielāpu publicēšanas.

Pēc servera pārinstalēšanas tajā jāuzliek visi drošības atjauninājumi (atkarībā no sākotnējās versijas tas var būt vairāku soļu process, piem. var būt nepieciešams sākumā uzinstalēt jaunāko CU un tad vēl pa virsu instalēt drošības ielāpu). Ieteicams arī preventīvi nomainīt lietotāju paroles (t.sk. Windows lietotājiem).

Paralēli servera pārinstalēšanai var uzsākt savākto pierādījumu analīzi (patstāvīgi vai arī piesaistot ārējus ekspertus). Galvenie analīzes mērķi ir noteikt:

  • cik reizes serveris ir ticis uzlauzts, kuros datumos
  • sākotnējie uzbrukumu vektori (piem. dažiem CVE nepieciešami kāda lietotāja pieejas dati, t.i. uzbrukums sākas ar phishing, paroles piemeklēšanu vai darbinieka datora inficēšanu)
  • vai sākotnējā pieeja serverim tika izmantota tālāk (ja paveicas, uzbrukums tiek atklāts drīz pēc servera inficēšanas, — kad uzbrucēji tikko izvietojuši backdoor, bet vēl nav to izmantojuši)
  • ja uz servera ir veiktas darbības, vai zināms kādas (parasti pilnu sarakstu nav iespējams iegūt)
  • vai ir pierādījumi lietotāju datu vākšanai (piem. ar mimikatz)
  • vai ir pierādījumi lietotāju datu eksfiltrācijai (piem. epastu saturs, pielikumi)
  • vai ir pievienoti jauni lietotāji, izveidotas pāradresācijas vai mainīta kāda cita Exchange konfigurācija (kas var tikt pārmigrēta uz pārinstalēto serveri, ja netiks pamanīta)
  • vai ir pierādījumi uzbrukumiem uz Active Directory
  • vai ir pierādījumi uzbrukumiem uz Azure AD / Office 365

Noderīgi resursi

Menu