Záznam ze Vzdělávacího okénka HAVIT z 8. dubna 2020, kde Jiří Kanda mluvil o cookies, zejména pak volby SameSite a souvisejících věcí kolem zabezpečení.
Nahrávka je publikována na našem HAVIT YouTube Channelu.
Záznam ze Vzdělávacího okénka HAVIT z 8. dubna 2020, kde Jiří Kanda mluvil o cookies, zejména pak volby SameSite a souvisejících věcí kolem zabezpečení.
Nahrávka je publikována na našem HAVIT YouTube Channelu.
Záznam ze Vzdělávacího okénka HAVIT z 18. března 2020, kde jsem povídal o authentizaci a authorizaci v Blazoru.
Dotčená témata:
Nahrávka je publikována na našem HAVIT YouTube Channelu.
Ještě než se rozpoutala kauza Benešovské nemocnice, dostalo se návštěvy ransomware i nám v HAVITu. Klasický následek – zakryptování souborů na discích za účelem získání výkupného. Poslední dobou se to docela mele, za poslední tři měsíce víme o nejméně dvou dalších případech v našem bezprostředním okolí (naši zákazníci), dalšími případy se to po internetu hemží.
Vesměs mají tyto případy jedno společné – nikde se nedočtete, jak konkrétně se ke komu škodlivý software dostal. Vše bývá zahaleno do obecné mlhy a spekulací typu „závadné přílohy mailů“ či „nezabezpečený systém“. Proto jsem se rozhodl veřejně sdílet, co víme o našem vlastním případu, jaké byly následky a jaké plyne pro nás poučení. Věřím, že to může mnohé inspirovat k vylepšení vlastního uspořádání.
V úterý 26. listopadu ráno jsem přišel do práce zhruba stejně s kolegou, který po usednutí a pár kliknutích zahlásil cosi ve smyslu „Sakra, já mám zašifrovanej počítač.“ Skok po síťovém kabelu už bohužel nic nezachránil – jak se během následujících chvil ukázalo, zašifrovaný byl nejenom počítač jeho, ale taky všechny on-premise servery v naší firemní síti.
> Welcome. Please read this important instruction. Cant you find the necessary files? Is the content of your files not readable? Congratulations, you files have been encrypted. > Whats happened? Your documents, photos, databases and other important files have been encrypted with strongest encryption and unique key, generated for this computer Decrypting of your files is only possible with the private key and decrypt program The only copy of the private key, which will allow you to decrypt your files, is located on a secret server > To receive your private key follow instruction: 1) Write to our email: recovery.company@protonmail.com or rapid.file@tuta.io 2) Tell us your personal ID: KR5FLA6R1OPEI4
Zašifrovány nakonec byly:
Od prvního okamžiku bylo jasné, že cestou zaplacení výkupného jít nechceme. Vytrhali jsme všechny kabely ze switchů, vypnuli WiFi, stáhli bootovací USB pro základní kontrolu a začali obcházet jednotlivé počítače i servery.
Zkontrolované počítače jsme zapojovali zpět do čisté sítě, přísně oddělenou samostatnou síť jsme si vytvořili i pro práci se špinavými servery (tu jsme nakonec ani moc nevyužili, nebylo co zachraňovat).
Důležitější pro nás bylo, co zůstalo nedotčeno – kromě těch pár desítek vývojářských workstation to byla zejména naše kompletní cloudová infrastruktura:
Díky tomu jsme byli nakonec ochromeni jen relativně krátce a v zásadě nijak kriticky.
Po pár hodinách počátečního chaosu a zjišťování rozsahu bylo zřejmé, že jediný možný recovery plán je kompletní rebuild celé on-premise infrastruktury od nuly, protože
…z on-premise nezbylo opravdu nic, přišli jsme i o AD doménu bez náhrady. Naše zálohovací strategie byla primárně zaměřena na události spíše více pravděpodobné – selhání jednotlivých kusů hardware, náhodné izolované ztráty dat, atp. Co se stalo, svým rozsahem spíše připomínalo živelní katastrofu s jediným rozdílem – zbylo nám holé železo, na které jsme mohli začít stavět znovu.
Proběhla rychlá strategická porada o prioritách, o podobě nové infrastruktury, o rozdělení úkolů a pustili jsme se do toho:
V zásadě nám trvalo postupně zhruba týden než jsme se dostali na víceméně plnou původní funkčnost, pár detailů ladíme dodnes (např. změna VPN z Microsoft RRAS na IKEv2 přímo přes router, atp.)
I přesto, že jsme měli a máme nejdůležitější služby v cloudu, byli jsme první dva dny dost zásadně paralyzovaní (první den jsme odhadem jeli na 5% výkonu a řešili jen kritické požadavky zákazníků, druhý den možná na 30%, pak už se to nějak rozběhlo).
Přestože jsme měli od drtivé většiny věcí datové zálohy a přišli jsme v podstatě jen o opomenutý starý help-desk, jednalo se svým rozsahem o událost, která byla pro nás zcela mimořádná a srovnatelná s živelní katastrofou. V zásadě se ukázalo, jak obrovskou výhodou pro nás je strategie postupného cloudovatění našeho fungování. O kolik hůře bychom na tom byli, kdybychom zároveň přišli o kdysi u nás běžící Exchange a TFS, to si raději ani nepředstavuji.
No a jak se to k nám dostalo? Jistotu nemáme, protože jsme v tom zmatku napadený počítač smazali a na hlubší analýzu nedošlo. Myslíme si nicméně, že příčinou byla kombinace chybějících aktualizací Windows (kolega měl plný systémový disk a aktualizace se mu tak neinstalovaly) a publikovaného rozhraní RDP na veřejnou IP adresu (přímý port mapping na routeru).
Smůlou pak už bylo, že zrovna kolega zároveň občas pracuje se servery jako Domain Admin (intranet RDP), byť jinak pracuje pod neadministrátorským účtem.
Jiné běžné příčiny jsme vyloučili – žádný závadný soubor neotevřel, žádný nakažený soubor se nikde nenašel, uživatelské účty měly unikátní a netriviální hesla.
…neštěstí nechodí nikdy samo. :-)
Viselo to tak nějak ve vzduchu, po internetu se množily zprávy, kdo zrovna podlehl ransomware, už jsme věděli, že nikdo není neprůstřelný, jistota o způsobu první nákazy nebyla.
Jeden krásný podvečer 5.12. mi volá kolega: „Je to tu zas! XY má zakryptovaný počítač.“ (jiný kolega).
Cvičení se opakuje. Sprint k síťovému kabelu nakaženého PC, odpojení všech od sítě, kontrola všech strojů antivirem z bootovacího USB.
Zkrátím to – zašifrovaný byl jediný počítač (jiným ransomware, byť taky šifrující) a příčina se ukázala celkem rychle. V zápalu boje, jak jsme přišli o VPN a trvá nám připravit novou, tak jsme podlehli potřebám pár dalších kolegů a namapovali jsme jim pro vzdálený přístup RDP přímo na veřejnou IP adresu. Bylo otázkou hodin, nikoliv dnů, než došlo k průstřelu skrze zapomenutý lokální účet jednoho z nich – admin s heslem admin.
K žádnému rozšíření na další počítače nedošlo, stačilo přeinstalovat jedno PC.
V podstatě jsem za tento druhý případ rád, protože poměrně levně pomohl zviditelnit velmi slabé místo naší ochrany – RDP, resp. obecně chybu cokoliv vypublikovat do veřejné sítě, co není „pod kontrolou“.
Kdo mě zná, ví, že nejsem příznivce antivirů. Sám mám na svém počítači zakázaný i Windows Defender a opírám se v této oblasti o tři jiné pilíře:
Na první dva nelze plně spoléhat, klíčový pro přežití je zejména ten třetí – zálohování.
V našem případě se potvrdilo, že antivirus by zřejmě nic nevyřešil. První kolega měl aktivní Defender (byť možná se starší databází), ale z event-logu bylo vidět, jak si s ním ransomware obratně poradil a shodil ho (stejně obratně sundal i běžící VMs z HyperV hostů a zašifroval VHDX soubory).
A zálohování? Zachránilo nás, byť o trochu kostrbatěji než bych si ideálně představoval. Pár věcí uniklo naší pozornosti při definování zálohovacích scénářů a způsob obnovy byl díky zániku řídícího DPM zdlouhavý.
Skončili jsme naštěstí ve stavu, kdy jsme měli dvě použitelné zálohy:
Neměli jsme zálohu on-prem Active Directory. Mou strategií je eliminace/minimalizace závislosti na on-prem AD, nicméně nové AD vzniklo a zálohujeme ho nyní jako „celý VM“.
Pro zkrácení doby zotavení jsme přidali nejenom zálohování celých VHDX, ale pro některé klíčové servery zálohujeme i do Azure v režimu Recovery Services (tj. celý VM k rychlému rozjetí přímo z Azure). Obecně však prostě cloudovatíme a on-prem servery držíme jen pracovní s režimem „dvě HyperV repliky + v případě ztráty reinstall“ (no a holt když se to sejde všechno najednou, tak ten rebuild trvá).
Čerstvě jsme přidali další nezávislé zálohování na Synology NAS. Bude to taková naše off-site černá skříňka s konektivitou pouze „zevnitř ven“, u mě doma na fyzicky odděleném segmentu sítě.
(Přestavěl jsem nedávno domácí síť na Ubiquity UniFi a musím říct, že co je Ubiquity na síťařinu, to je Synology v NAS. Jsou to fakt pěkné ekosystémy.)
Cenné školení bojem se nám dostalo i v oblasti ochrany. Celá firma jsme v podstatě IT profesionálové, příčetného uživatelského chování, ale pořád jen lidi – chybující.
Pár věcí, které jsme po popsaných událostech změnili:
…no a samozřejmě vycházíme z toho všeho posilněni. Vyzkoušeli jsme si disaster recovery, objevili slabá místa, dostali přes prsty, získali nové zkušenosti.
Záznam ze Vzdělávacího okénka HAVIT z 25. dubna 2019, kde Jiří Kanda povídal o Azure Key Vault a jeho použití pro uchování secrets.
Záznam z interního vzdělávacího okénka HAVIT z 19.10.2017 je publikován na našem HAVIT YouTube Channel. Téma prezentoval Jiří Kanda:
Dotčená témata:
dcgpofix je „Default Group Policy Restore Utility“, utilita Windows Serveru 2003, která umožňuje obnovit Default Domain Security Policy (Zásady zabezpečení domény) a Default Domain Controllers Security Policy (Zásady zabezpečení řadičů domény) do výchozího stavu po instalaci, a to nejenom pokud si rozhážeme nastavení do neudržitelného stavu, ale i v případě, že jsou tyto GPO poškozeny, nebo smazány.
Základní syntaxe je
dcgpofix [/ignoreschema][/target: {domain | dc | both}]
Viz též podrobnější info o dcgpofix od Microsoftu.
Pro Windows 2000 existuje též postup, i když mnohem drsnější.
Naplánovaná úloha (Scheduled taks, např. zálohování) lze spustit pouze ručně (pravým tlačítkem Run), ale namísto naplánovaného spuštění je při detailním zobrazení označena stavem „Could not start“ („Nelze spustit“) a chybovým kódem 0x0.
Pokud se podíváme do logu scheduleru (Advanced ~ View log, Upřesnit ~ Zobrazit protokol), pak tam najdeme něco jako:
Backup.job" (NTBACKUP.EXE) 10/12/2006 3:00:00 AM ** ERROR ** The attempt to log on to the account associated with the task failed, therefore, the task did not run. The specific error is: 0x80070569: Logon failure: the user has not been granted the requested logon type at this computer. Verify that the task's Run-as name and password are valid and try again.
resp.
Zálohování.job (NTBACKUP.EXE) 18.11.2004 3:00:00 ** CHYBA ** Pokus o přihlášení k účtu přidruženému k úloze se nezdařil. Úloha nebyla spuštěna.. Příslušná chyba: 0x80070569: Přihlašovací chyba: Uživateli nebyl v tomto počítači udělen požadovaný typ přihlášení. Ověřte, zda jsou údaje Spustit jako a heslo platné, a akci opakujte..
Příčina je v zásadách zabezpečení. Účet, pod kterým se má úloha spouštět, nemá nastaveno právo„Logon as batch job“ („Přihlásit jako dávkovou úlohu“). Je tedy potřeba prohlédnout lokální a doménové zásadný zabezpečení a právo účtu přidělit.
Tento warning se nám může množit v Application event logu, po aplikaci šablony zabezpečení Basicdc.inf. Potíž je v tom, že se tato šablona odkazuje na proměnné %SYSVOL%, %DSDIT% a %DSLOG“, které však neexistují (existují jen během Dcpromo procesu).
Stačí tedy tyto environment variables vytvořit. Výchozí složky jsou následující
%SYSVOL% = C:\WINNT\SYSVOL
%DSDIT% = C:\WINNT\NTDS
%DSLOG% = C:\WINNT\NTDS
…a warning je pryč.
Poměrně často dostávám dotaz, jak nastavit práva na FTP složku pro příchozí soubory – složku /incoming (i když já doporučuji jiný název, viz dále).
V podstatě chceme dosáhnout toho, aby anonymní uživatel:
Právě z posledního uvedeného důvodu, kdy se roboti zaměřují převážně na složku /incoming a ostatní složky pro zrychlení ignorují, doporučuji pojmenovat složku pro příchozí soubory jinak. V českém prostředí například /prichozi.
A teď jak na práva:
Tím, že pravidlo aplikujeme pouze na objekty typu složka, nikoliv na soubory, dosáhneme právě toho, že uživatel sice všechno uvidí, ale nebude moct číst jednotlivé soubory.
Také si dejte pozor, jestli Vám nevznikají práva k souborům nějakým jiným děděním, klasickou chybou jsou třeba práva pro CREATOR OWNER.