Naše postřehy z auditů bezpečnosti ve firmách

Tento rok jsme objeli několik desítek firem a probírali s nimi zabezpečení jejich IT systémů. Tyto návštěvy (audit bezpečnosti) zpravidla iniciovalo vedení (chtěli mít jistotu, že IT se o síť dobře stará), IT oddělení (chtěli dodatečný pár očí), nebo hackeři.🙃

Byly to fajn návštěvy. Poznali jsme bezva lidi, hezká místa a rozšířili jsme si přehled o stavu IT ve firmách. V minulém čase o tom píši proto, že bych tuto aktivitu prozatím rád utlumil. Je to hodně časově náročné a jako introverta mě to posouvá lehce mimo komfortní zónu.

Nyní se potřebuji zaměřit na resty, které u nás ve firmě máme. Dotáhnout výběr vhodného EDR (viz můj článek „Proč chci nasadit EDR ke všem zákazníkům„), nasadit centrální log management a checky pro Office 365 tenanty (v rámci našeho monitorovacího systému, o kterém jsem už psal, Monitorovací systém: co všechno s ním dokážeme). A v poslední řadě, psaní závěrečných zpráv mě vůbec nebavilo.😴

Často zmiňuji, že cestu vpřed v IT bezpečnosti vidím ve vzájemné pomoci a sdílení informací mezi sebou. Proto bych se s vámi chtěl podělit o naše postřehy a často se opakující chyby, na které jsme při auditech naráželi. Snad vám to přinese hodnotu.

Záznam ze Cybercon 2022

V září mne z NÚKIBu pozvali jako řečníka na CyberCon 2022 (čehož si vážím a moc děkuji). Svoji přednášku jsem měl právě na téma našich zkušeností z auditů. Kdo tedy radši sleduje video, než čte text, může se podívat na záznam přednášky (obsah je podobný).

Co mě na auditech nejvíce překvapilo

Audity jsme měli rozdělené na dvě části. Teoretickou a praktickou. Dopoledne jsme se o podobě sítě, opatřeních, zabezpečení a nastavení bavili teoreticky. Odpoledne jsme si sedli k počítači a vše, co se předtím probíralo, si nechali ukázat.

Ještě minulý rok bych si nemyslel, jak se tyto dvě věci mohou lišit. V podstatě je pravidlem, že se skutečné nastavení sítě liší od popisovaného stavu. Proč tomu tak je? Netuším.🤷‍♂️ Ani nemám pocit, že by nám IT chtělo lhát, nebo uvádělo nepřesný popis naschvál. Možná toho je na práci tolik a neustále probíhají změny, že není jednoduché si vše udržet v paměti.

Myslím, že být technik, je při auditech velkou výhodou. Dokáži se podívat na nastavení sítě a přečíst tak její skutečnou podobu. Při kybernetických incidentech totiž nejde o to, jak si myslíme, že je síť zabezpečená, ale o to, jak skutečně zabezpečená je.

Na co jsme se při auditech zaměřovali

Při auditu toho můžeme kontrolovat spoustu a následně bazírovat nad jednotlivým nastavením. My se však nechtěli pouštět do dohadů o tom, jestli je lepší mít antivirus X, nebo Y a jestli je nutné mít jej nastavený v agresivním režimu, či postačí normální citlivost. Spousta těchto věcí záleží na kontextu a o správném řešení se dá diskutovat.

Při vymýšlení osnovy auditu jsme se snažili přinést co nejvíce muziky za co nejméně času (a peněz). Seznam věcí, které se dají kontrolovat, je dost dlouhý. Přičemž:

  • na kontrolu všeho není čas,
  • každá položka má jinou pravděpodobnost zneužití,
  • a potenciální škoda zneužití se liší položka od položky.

Proto jsme se rozhodli zaměřovat na věci, o kterých víme, že je útočníci zneužívají. Audity jsou tak další oblast, kde benefitujeme z našich zkušeností s řešením kybernetických incidentů (ransomware, kompromitované systémy). O těchto našich zkušenostech už jsem na blogu několikrát psal. Naposled tuším v článku:“Postřehy ze zásahů při ransomware útoku„.

Na jaké problémy jsme nejčastěji naráželi

A teď již konečně ta problematická místa, na která jsme nejčastěji naráželi.

Zálohy

Ano, vím, je to nudné téma, o kterém se mluví roky a roky. Nicméně i když je to nudné téma, tak zálohy jsou zásadní a je nutné je mít v nejlepším stavu. Dívejte se na to tak, že jakákoliv další opatření, která v rámci zabezpečení uděláme, vedou k tomu, aby nedošlo ke kompromitaci. Sítě jsou však rozsáhlé a komplexní. Každý tak hned druhým dechem dodá, že 100% bezpečnost neexistuje. I když tedy uděláte 90 % jiných opatření, ale útočníci stejně projdou, zálohy budou to poslední a jediné opatření, co vás zachrání. Proto i když jsou nudné, věnujte jim čas a ověřte si, že je máte dobře provedené.

U záloh narážíme na následující problémy:

  • Nejsou odolné vůči hackerům. V případě, kdy útočníci ovládnou síť, dokáží smazat i veškeré zálohy. Rychlé je to zejména, když samotný backup server je členem produkční AD. V takovém případě mají útočníci ihned pod kontrolou jak produkční data, tak i zálohy. ŘSD by mohlo vyprávět. Tomuto jsem věnoval celou přednášku „Přednáška: Zálohy, které nepřežijí ransomware„.
  • Neobsahují všechna data. Množství produkčních dat stále roste, až je není kam zálohovat. V tu chvíli se začnou zálohovat jenom některé servery. Následně se nezálohují ani celé servery, ale jen jednotlivé složky. Že nějaká data v zálohách chybí, se zjistí až ve chvíli, kdy z nich chcete obnovit, protože produkce je zašifrovaná (stresová situace 100% 🤯).
  • Nedostatečná rychlost obnovy. Oproti předchozím bodům je to jen kosmetika. Nicméně i tak je dobré vědět, až se vedení zeptá, kdy firma pojede, že obnovit všechna data bude trvat 4 dny. Ideální je si celou obnovu zkusit. V horším případě obnovit alespoň jeden střední server a zbytek si dopočítat (velikost serveru [TB] / doba obnovy [h] * celková velikost zálohovaných dat [TB] = odhadovaná doba obnovy dat v hodinách).

Chybějící antivirus na serverech

Častokrát na serverech nebyl nainstalovaný antivirus. Správci buď necítili potřebu ho tam mít (na server chodí jen oni sami), nebo v minulosti měli nějaké výkonové či funkční problémy.

Antivirus (či lépe EDR) s centrální správou nám slouží ke dvěma věcem:

  • Útočníkům ztěžuje práci. Někdy je dokáže i zastavit, ale spíše počítejme, že je jen zdrží a nám (obráncům) tak získá čas na reakci.
  • Upozorňuje nás, že se někde něco děje. To je možná ta důležitější funkce. Přestože útočníky nezastaví, dá nám informaci, že se někde něco děje, a my máme možnost situaci vyšetřit. Máme tak možnost útok zastavit dřív, než budou škody násobné.

Poslední dobou jsme řešili několik napadených firem, kde se na serverech pohybovali útočníci déle jak rok, aniž by si toho obránci všimli. Když by na serverech měli alespoň nějaký antivirus, všimli by si toho (útočníci používali známý malware/backdoory).

Samozřejmě místo antiviru můžete servery hlídat jinou technologií. Jde jen o to mít nějaký mechanismus jak poznat, že se na serveru děje něco nelegitimního. Antivirus zmiňuji z důvodu, že jde, dle mého názoru, o nejlevnější a nejjednodušší způsob, jak toho dosáhnout.

Důležité je ještě zmínit, aby byl antivirus napojený na centrální správu, do které se někdo kouká, a výstupy vyhodnocuje. Na Cyber Days 2022 jsem měl na toto téma celou přednášku (je to složitější, než to na první pohled vypadá).

Neaktualizované operační systémy

Jak se všude píše, je třeba operační systém i aplikace aktualizovat. Tento požadavek se dá krásně a jednoduše vyjádřit jednou větou. Správci však ví, že jeho naplnění je výrazně těžší (čím větší je síť, kterou spravují).

Jsem realista a nějak mě nepřekvapuje, že řada firem provozuje nepodporované operační systémy (Windows 7, Windows Server 200-2008 – zákazníka s placeným ESU programem jsem viděl jen jednou) a servery aktualizuje jednou za rok. Ve většině případů je ohrožen zpravidla jen ten daný server či stanice.

Nicméně je nutné si uvědomit, že některé servery mají v síti významnou pozici. Jejich kompromitace pak zpravidla znamená „game over“, protože útočníci skrze ně ovládnou celou síť. Mezi tyto servery patří doménové řadiče, backup servery, MS Exchange servery, AD FS servery, AD CS, servery s AD Connect a jakýkoliv další server, kde se dá najít uložený účet s Domain Admin právy. Pokud tedy chronicky nestíháte aktualizovat vše, tak výše zmíněné servery jsou kritické minimum.

Ubránit doménu, kde je nějaký Windows Server 2008 (R2) řadič je opravdu výzva. Namátkou bych zmínil CVE-2020-1472 (Zerologon), CVE-2021-42278+CVE-2021-42287 (sAMAccountName Spoofing) a CVE-2021–34527 (PrintNightmare). Vše jsou RCE, aktivně zneužívané a bez bezplatného patche pro daný OS.🤷‍♂️

Účet Administrator všude, kam se podíváš

Jedná se o více problémů současně, ale nechce se mi pro každý psát vlastní kapitolu.😇 Pojďme se na ně podívat:

  • Lokální (povolený) účet administrátor na serverech a stanicích se stejným heslem. V případě kompromitace stanice/serveru si útočníci téměř vždy vytahují hash hesla lokálního uživatele „Administrator“. Ten se dá použít k ovládnutí jakékoliv stanice/serveru (s Windows), kde je tento uživatel povolený a má stejné heslo („MITRE: T1550.002 Use Alternate Authentication Material: Pass the Hash„). Řešením je nasadit LAPS, lokální uživatele zakázat, nebo RemoteUAC + vynutit UAC i pro builtin adminy.
  • Správa stanic a serverů doménovým administrátorem. Správci častokrát používají ke správě celé sítě jeden uživatelský účet a to doménového administrátora. Problém je, že pokud se s ním přihlásí na kompromitovanou stanici/server, útočníci jim ho ukradnou, a tím opět skončí celá síť. Tohle je snad nejčastější důvod, proč hacknutí běžného severu v AD (Active Directory) končí kompromitací celé AD. Útočníci totiž na napadeném serveru najdou přihlášeného doménového administátora, ukradnou mu identitu a ovládnou celou síť. O této problematice jsem psal už v článku „Zabezpečení sítě: Tierování a PAW
  • Příliš mnoho privilegovaných uživatelů. Při procházení AD se koukáme i kolik existuje privilegovaných uživatelů (uživatelských účtu s příliš vysokými oprávněními). Chyba/kompromitace každého takového uživatele má za následek velké škody. Pokud se jedná o účty, které jsou použitý k provozu nějaké aplikace, tak ty rozšiřují seznam „kritických serverů“ (jak jsem psal výše). Tento uživatelský účet je na serveru (kde ta aplikace běží) uložen a pokud server někdo kompromituje, ovládne opět celou síť.
    Cílem tedy je se podívat na členy následujících skupin: Administrators, Domain Admins, Enterprise Admins, Schema Admins, Account Operators, Backup Operators, DnsAdmins, Exchange Windows Permissions, Organization Management [Exchange], Server Operators, Print Operators, Cert Publishers, Cert Operators, Remote Management Users. U každé z těchto skupin byste měli být schopni říci, proč tam každý jednotlivý člen je a zdali tam potřebuje být.
    Členové výše zmíněných skupin se totiž s trochou úsilí mohou stát správci domény. Trocha inspirace:

Závěr

Co si o tom myslíte? Překvapilo vás něco z toho, co jsem napsal? Vím, že pro spoustu z vás to nejsou novinky a máte to pokryté. Jak jsem psal u aktualizací, dokud se o těch věcech mluví/píše, tak zní jednoduše. Implementovat opatření a udržet ve věcech pořádek, je mnohem těžší. Jestli tedy máte vše pokryto, zasloužíte si uznání a pochvalu.👍

U firem často potkáváme i situaci, kdy všichni ví, co se má dělat a jak se to má nastavit. Jen se to měsíce či roky nedaří dotáhnout. Jako externí pozorovatel bych řekl, že se najednou honí moc zajíců po poli, až se žádný nechytí. Chce to snížit množství rozdělané práce a řešit úkol po úkolu (neustálé přepínání mezi úkoly vysiluje).

Ať jsou vaše sítě bezpečné,

Martin

Líbí se vám témata, o kterých píši?

Abyste nemuseli kontrolovat, jestli už vyšel nový článek, rád vám ho ihned po zveřejnění pošlu do e-mailu. Každý kontakt, který mi poskytnete, si nechám vždy jen pro sebe.

Diskuze k článku

Lukáš Gründel

21. 11. 2022 v 08:47

Ahoj, díky. Mně chtěl sekuriťák vyhodit Eset z DCček. Bojí se kompromitace přes ERA. To je u nich takový evergreen. Nejraději by všechno zakázali :).

Odpovědět

Odpovědět

Martin Haller

21. 11. 2022 v 09:28

Ahoj, pokud sekuriťák v rámci tier modelu považuje ERA server za níže postavený, pak to tak být samozřejmě může. Jen je potřeba:
* Aby ESET nebyl nainstalovaný na žádném jiném kritickém systému (backup, AD connect … a další, jak jsem psal v článku) a na servery (kromě DC) se nikdo nehlásil s DA právy.
* Pokud by na DC nebyl AV s centrální konzolí, tak jde o to, jakou technologií se bude hlídat zdraví/stav těch DC.

Záleží tedy, jestli bude mít sekuriťák na výše zmíněné body odpovědi 🤷‍♂️.

Odpovědět

Odpovědět

lgrundel

09. 01. 2023 v 10:25

Opožděně děkuji, to bude námětem dalších konzultací. Ještě bych se chtěl zeptat na tvůj názor ohledně zálohování DC pomocí VBR. Budu-li předpokládat, že veeam chce pro konzistentní backup adečka domain resp. built-in admina. pak se mi nabízí dvě možnosti: 1. Zálohovat všechny vm pomocí jednoho účtu s da právy, kde bude silné heslo (1x za měsíc se změní). Anebo tímto účtem zálohovat jen dc a na ostatní stroje – sql, exchange použít separe lokální admin účty. Z hlediska security mi to vyjde nastejno, možná ta druhá je o něco lepší, ale rád bych znal i názor někoho jiného . Díky moc za případnou odpověd 🙂

Odpovědět

Odpovědět

Martin Haller

09. 01. 2023 v 13:44

Když se jedná o VM, tak mi tohle napojení nepoužíváme – prostě to zálohujeme přímo z toho Hyper-V. O snapshot/konzistenci dat se pak postará VSS a integrační komponenty.

Když už by se tam museli zadávat přihlašovací údaje, tak bezpečnější by bylo mít separátní admin účty, avšak to je zároveň náročnější na údržbu. Asi bych se tedy rozhodl podle kritičnosti/cennosti té sítě (jak moc by byl incident drahý). Pokud to není nic vysoce důvěrného, tak bych to udělal jedním uživatelem.

Odpovědět

Odpovědět

Dawid

30. 01. 2023 v 04:58

Prosím, rozviedli by ste prvú vetu svojej odpovede: ako to myslíte resp. akým nastavením VBR „zálohujeme přímo z toho Hyper-V“?
Lebo aj my by sme veľmi radi odstránili z VBR všetky vysoko privilegované účty, ale VBR potrebuje pristup k admin$ (https://www.veeam.com/kb4185).
Ďakujem

Odpovědět

Odpovědět

Martin Haller

30. 01. 2023 v 09:25

Myslel jsem to tak, že pokud zálohujeme jen VM, tak nám stačí mít VBR na Hyper-V hostu a ve VM již nemáme žádné Veeam komponenty. Veeam pak pro snapshotování používá VSS a Hyper-V integrační komponenty (ty se starají o aplikačně konzistentní zálohy – do této doby byl problém jen s Oracle databází, kde to musíme řešit přes Application-Aware Processing https://helpcenter.veeam.com/docs/backup/vsphere/application_aware_processing.html?ver=110 ).

Odpovědět

Odpovědět

Aleš Blinka

21. 11. 2022 v 14:58

Oceňuji závěr článku. To je přesně ta svízel, těch mnoha zajíců a taky strach říznout do živého a vzdát se určitého komfortu. Nápadů je spousta, do toho přicházejí požadavky z operativy, které nikam neposouvají, jen udržují firmu v chodu. Já osobně se teď snažím tlačit IT metodou ŽÁVES, aby byly úkoly dotaženy do konce a nepřešlapoval jsem nad nimi, ale i tak je to boj.

Odpovědět

Odpovědět

petr

22. 11. 2022 v 17:24

ad „Správa stanic a serverů doménovým administrátorem“ – snažíme se mít oddělený účet pro a) stanice b) servery c) ADčko a hypervizory. U virtualizace vidíme hypervizory podobně důležité jako ADčko ve smyslu, že kdo je má, tak se probije i do virtuálek níže (pokud nejsou třeba typu shielded, což je ale docela komplikované pak na provoz).

Co si o tom bodě c) myslíte?

Odpovědět

Odpovědět

Martin Haller

23. 11. 2022 v 08:58

Souhlasím. Hypervizory jsou zpravidla stejně kritické jako DC. Někdy i trochu více (pokud na nich např. běží více AD).

Co se týče Shielded VM, tak je to technologie až pro velmi velké podnik. Pořízení a provoz stojí dost peněz – přínos je pak v oddělení odpovědnosti/rolí správců (týká se to velkých týmů, ne firem kde má každý správce ke všemu přístup).

Jinak u tierování vaším způsobem (zvlášť správce pro PC a servery) je v případě kompromitace jednoho zařízení ohrožen vždy celý tier. Pokud nepoužíváte nějaké další technologie co by to omezovali (RestrictedAdmin pro RDP, PVLAN/striktní host FW – síťová segmentace). Jde o to na to myslet.

Odpovědět

Odpovědět

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *

Hack The Box OSCP MCSE CHFI ECSA CCNP CCNA