Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > default
říjen 23
Proč ransomware funguje?

Záznam z mé přednášky ​na konferenci CyberCon 2020. Povinnost vidět pro každého, kdo doufá, že ho antivirové produkty ochrání:

Proč ransomware funguje - CyberCon 2020

říjen 22
SAPHA ad scanner

Kdo má zájem vyzkoušet můj SAPHA (Sevecek AD and password hash analysis) AD scanner, který jsem prezentoval na WUG Days 2020, zde je několik poznámek:

  1. stáhněte si celý balík SAPHA AD scanneru zde
  2. jsou uvnitř i zdrojové kódy v adresáři SRC, které nepotřebujete k provozu samotnému
  3. všechno co jde, je digitálně podepsáno mým podpisovým certifikátem, který je součástí balení v adresáři Certificates
  4. kdyby tomu někdo nevěřil, tak thumbprint podpisového certifikátu je 0754e7dfdac37f067d5f8e5f24239505fbe508cc, thumbprint CAčky je b1edc75e1e4572ad493899a593c2f7cca0d5095b a ID klíče CAčky je 1a7304060d3638d36f4de171aa14657c77a0d0c9
  5. dále je tam seznam SHA256 heší všech souborů v souboru signed-catalogue.csv, který je sám také podepsaný
  6. ideálně přímo na nějakém DC, které má online konektivitu na ostatní DC a další TIER0 servery, spustíte celý AD scan včetně PWD scanu:
saphaADscanner.bat
mon -all
  1. pokud nemáte online konektivitu na ostatní DCčka, tak to můžete spustit postupně na každém zvlášť. Ideálně na každém z nich vytvoříte jen DC scan:
saphaADscanner.bat
mon -dcOnly
  1. jednotlivé DC scany je nejlepší dělat postupně, vždy na jednom DC a potom to celé, včetně OUTPUT adresářů, překopírovat na další DC a znovu spustit další DC scan. Už se totiž nebude muset dělat znovu SYSVOL scan ani FOREST scan.
  2. pokud to někde selže, možná přes síť, nebo lokálně, poznáte to jednoduše podle toho, že odpovídající OUTPUT adresář bude mít jméno obsahující error.interrupted. A stačí to prostě na tom počítači spustit znovu, pokud se jednalo o problém přístupu přes síť.
  3. až máte kompletní výstup adresářů OUTPUT-DC tak můžete končeně spustit zbytek, tak jako na začátku:
saphaADscanner.bat
mon -all
  1. pokud adresáře existují, tak se to znovu neskenuje. Kdybyste chtěli vyvolat nové skenování, tak buď smažete odpovídající OUTPUT adresáře, nebo použijete parametr:
saphaADscanner.bat
mon -all -rescanAll

 

Prozatím jsem nepublikoval verzi se skenováním lokálních hesel serverů a DSRM admin hesel, protože je tam jedna muška, vydám snad během zbytku týdne. V adresáři budou vždycky všechny vydané verze, takže si prostě stáhnete tu nejnovější.

Jakékoliv vady hlaste, fíčr requesty požadujte a užívejte!

říjen 22
WugDays 2020 aka Conšvindr 2020 aka GešvindrFest 2020

Děkuji za možnost zúčastnit se!!! A nejvíc děkuji Davidovi Gešvindrovi, že to uspořádal a natočil nás. Takový objem práce pro komunitu jsem snad ještě neviděl!!!

K přednášce o PowerShellu najdete ukázkový skript zde​.

K přednáškám o SAPHA AD scanneru a SAPHA Machine Admins (aka LAPS) budou samostatné přízpěvky.

září 18
NUKIB CyberCon dodělávky

Předně děkuji za možnost zúčastnit se!

a) teď jsem znovu vyzkoušel tu ne úplně podařenou schránku. Nevím proč, ale i v tom VMCONNECT klientovi RDP to teď funguje normálně tak, jako v případě MSTSC klienta RDP.

Okno se skenerem schránky ve vzdáleném RDP (ať je to MSTSC nebo VMCONNECT) můžete mít klidně i minimalizované. Pokud v jiném okně VMCONNECT dáte něco do schránky, 1-2 sekundy to tam necháte, dáte tam něco jiného a takhle několikrát dokola, můžete se následně jít přesvědčit do toho prvního minimalizovaného okna, že všechny schránky to vycucalo v průběhu. A to aniž by to okno bylo vidět.

Důvod proč to včera fungovalo až s tou poslední schánkou nevím, možná jsem ten první text do schránky korektně nevložil, nebo to bylo vytuhlé, nebo možná moc rychlé, teď jsem tomu dával 1-2 sekundy čas. Nebo to prostě někdy přes minimalizovaná okna nefunguje. Ale teď ve vlaku to opět funguje :-)

b) prý byly nějaké dotazy, které jsem nestihl zodpovědět v tom online systému a po přednášce jsem je tam už neviděl. Kdokoliv cokoliv, pište emailem prosím.

c) po přednášce, ještě než jsem zdrhal zpátky do práce, jsem stihl promluvit s jedním pánem, co mi říkal senzační UAC bypass a další věci. Kdybyste ho někdo znali, řekněte mu, ať se mi ozve :-) Nemám na něj bohužel kontakt. Chtěl jsem původně nasprejovat na zeď v podchodu něco ve stylu "hledám simonu z čochu ze soboty, ozvi se. značka ten co ti držel vlasy". Ale pak jsem si říkal, že jsme dospělí lidé :-DDD

 

květen 25
Poznámky k heslovníčkům a jejich bezpečnosti

Měl jsem na GOPAS TechEd Online přednášku o ransomware, kde jsem vyhrožoval :-) ohledně heslovníčků. Po několika dotazech bych to rád trošku uvedl na pravou míru.

Cílem části přednášky bylo uvědomit si, že samotné použití heslovníčku (bacha to se vtahuje i na PAM - provileged access management), ať už cloudového nebo lokálního, vás proti krádeži přihlašovacích údajů neochrání. Pokud už se spyware spustí, vždycky to ukradne. I když se všichni pyšní tím, že mají databázi šifrovanou, nebo že je to cloudové řešení a má to více-faktorové (MFA) přihlašování. Pokud s tím můžete pracovat vy, může s tím pracovat i spyware.

Šifrovací klíče jsou v paměti. Řekněme, že by to bylo celé v cloudu a pracovalo se s tím přes webový prohlížeč, nebo jinou GUI aplikaci. Jak jste mohli vidět, vždycky si něco dáte do schránky a použijete to v nějakém programu. Jaký je problém, aby si to spyware vzal?

Při nejhorším to za vás spyware celé prokliká. Nevím jestli to už existuje, ale odhaduju to tak na 1 den práce, udělat automatický proklikávač prohlížeče pro každý cloudový heslovníček, který se nabízí. Porovnejte to s cenou dat v nemocnici :-) Máte tam MFA (multi-factor ověření)? Jenže to MFA zadáváte jenom jednorázově při vstupu a potom je přístup dlouhodobě otevřený. Pokud se ten spyware integruje do prohlížeče, nemůže mít problém. Porovnejte s elektronickým bankovnictvím, kde děláte MFA pro každou platbu, což provádíte jen velmi sporadicky.

Jsou tedy heslovníčky špatné?

Nejsou. Je to o něco lepší než zašifrovaný Excel. Umožňuje to nepamatovat si hesla. Mít striktně různá hesla do různých služeb. Mít kvalitní, automaticky generovaná hesla. Schránku to čistí po několika vteřinách. Může to mít MFA pro vstup do heslovníčku. Můžete to mít na více zařízeních.

Prostě všechno super. Jen to má limity, které si člověk musí uvědomit.

Je lepší lokální nebo cloudový heslovníček?

Mě je to fakt jedno. Jde spíš o osobní zvyk práce, jestli to umí MFA a přístup na internet, který to případně vyžaduje.

Jak tedy bezpečněji?

Ke správě počítačové sítě je potřeba mít vyhrazené čisté a zabezpečené prostředí (SAE - secure administration environment), kde je jen malá šance, že by se objevil spyware. Podle obrázku z mého GOC159. Heslovníček máte až na něm. Bez volného připojení do internetu (samozřejmě na cloudový heslovníček ano :-)) Na takovém SAE buď pracujete přímo lokálně, nebo se do něho připojujete přes RDP, ideálně samozřejmě bez schránky...

květen 05
Třešnička na závěr TechEd Online 2020

Aktuálně probíhá naše první online konference GOPAS TechEd Online 2020. ​Zítra budu mít přednášku a mám ještě jednu ukázečku, která se mi tam už nevešla. Tak kdo to budete poslouchat zítra, tak klidně počkejte, ostatní se třeba podívejte :-)

sevecek-teched2020-tresnicka.mp4

únor 27
Vlastní řešení změny lokálních admin účtů o hodně lepší než LAPS

Už to začíná být docela vyladěné, takže jsem se rozhodl zveřejnit vlastní řešení na řízení hesel lokálních admin účtů na stanicích a serverech. Je to něco podobného jako LAPS od Microsoftu, ale je to lepší. Samozřejmě :-) Obsahuje to fíčury, které jsem vyvíjel vždycky pro nějakého zákazníka, takže všechno má smysl :-)

O co jde?

Na počítačích v síti, ať už jsou doménové, nebo ne, nebo jsou spravované Intune apod. potřebujete mít nějaký lokální účet, nebo účty, které jsou lokálními Administrators. Říkám schálně lokální účty, protože pokud nejede síť, nebo doménové ověřování, tak byste se tam nepřihlásili. Někdy počítač odpojíte z domény kvůli údržbě, a pokud neznáte heslo lokálního správce, už se tam nedostanete. Někdy vám počítače vypadávají z domény i samy. Pokud nemáte doménu nebo Azure, je to jasné samo o sobě.

Na jednotlivých strojích nechcete mít stejná hesla těchto účtů. Pokud někdo jedno zjistí, dostal by se s tím na všechny ostatní stroje. Potřebujete tedy náhodné heslo admin účtu na každém počítači. Také ho chcete občas změnit. Nebo ho chcete změnit i rovnou brzy po jeho občasném použití.

Co to umí?

  • hesla ukládat do trezorů, kterými je Active Directory, FTPS server ve formě souborů, nebo Azure Key Vault
  • měnit automaticky heslo zabudovaného účtu Administrator (SID -500) na náhodné
  • přejmenovat, nebo úplně zakázat zabudovaný účet Administrator (SID -500) a klidně mu u toho taky měnit heslo
  • vytvořit vlastní účet, který bude členem skupiny Administrators a bude mu měněno heslo (lze vytvářet více takových účtů)
  • vytvořit další vlastní účty, které třeba ani nebudou členem skupiny Administrators, a budou mít náhodné heslo (například kvůli nějakým naplánovaným úlohám, nebo autologon na kiosku)
  • zapnout daný účet rovnou na autologon
  • měnit hesla opakovaně po několika dnech
  • měnit hesla rovnou brzy po jejich použití. Jakmile se jednou použije, po několika hodinách se rovnou heslo změní. Nemusí se čekat na pravidelný interval změny
  • pamatovat si historie všech hesel, takže pokud se změna nepovede, nebo se nezapíše do trezoru (síťové výpadky), tak se dá použít předchozí heslo
  • pokud počítač obnovíte ze zálohy, nebo snapshot, nebo checkpoint, nebo imidž, tak máte tehdejší heslo v trezoru
  • různé kombinace předchozího. Můžete mít více účtů, něco v AD, něco v FTPS a něco v Azure Key Vault. Současně autologon apod.

Jak na to?

Tady si to stáhnete. Případně zdrojové kódy jsou vidět po jednom zde. Celé to dělá skript nazvaný JOB. Spouští se stejně pojmenovaným BATákem. Pokud chcete trezor v ADčku, musíte si rozšířit schéma pomocí SCHEMA-UPDATE souboru. Do Active Directory se to zapisuje pod účtem počítače, pod kterým to je také potřeba spouštět.

Pokud chcete trezory v FTPS nebo Azure stačí zadat login a heslo. V případě těchto dvou trezorů je generováno náhodné jméno souboru nebo tajemství (secret), samozřejmě odpovídající jménu počítače, ale obohocené o náhodné číslo. Tím se brání DoS útoku, protože na všech počítačích budete mít nejspíš stejná hesla do FTPS nebo Azure Key Vault. Stačí udělat takový účet, který má zakázané čtení v tom FTPS nebo Azure. Stačí mu tam jenom zapisovat. Nemusí být schopen z toho nic přečíst.

Na ruční zkoušení jsou tam BATáky nazvané USE. Loginy a hesla jsou v nich, to si musíte upravit a můžete zkoušet. Pokud použijete heslo ve formě hvězdičky (*) zeptá se vás to.

září 03
Jak připojit shadow copy jako písmenko disku

V dávném článku jsem psal o tom, jak ručně vytvářet volume shadow copy (VSS snapshot) pomocí PowerShellu a WMI. Tam se využíval příkaz MKLINK k připojení stínové kopie oddílu do nějakého adresáře (directory symbolic link, nebo junction). Dneska se podíváme, jak připojit shadow copy přímo jako písmeno disku/svazku (disk volume letter):

$src = @'
namespace Sevecek {

  using System.Runtime.InteropServices;

  public class Win32Api {

    [DllImport("kernel32.dll", SetLastError = true, PreserveSig = true, CharSet = CharSet.Auto)]
    public static extern bool DefineDosDevice(uint dwFlags, string lpDeviceName, string lpTargetPath);
  }
}
'@

if (-not ('Sevecek.Win32Api' -as [Type])) { Add-Type $src }

[Sevecek.Win32Api]::DefineDosDevice(0, 'S:', '\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy38')
květen 27
Zdrojové kódy mých výukových prográmků

​Už delší dobu se chystám uveřejnit nějak souhrně zdrojové kódy svých ukázkových programů, které používám na školeních v GOPASu a na přednáškách. Například teď na konferenci TechEd jsem ukazoval fake logon :-)

Obsahuje například toto:

- WS-Fed ukázku, která vypisuje claimy, zvlášť vhodné pro testování ADFS

- SAMLP ukázka, která generuje SAML-P požadavek a dekóduje jeho odpověď

- OAuth příklady ​testovací webové aplikace a jejího back-endu

- MFA adapter pro AD FS

- Fake Logon z TechEdu

Všechno je to ke stažení tady. Odkaz naleznete také na stránce spolu se slajdy a prezentacemi:

Všechny zdrojové kódy ukázkových aplikací

 

květen 27
Prezentace z letošní konference TechEd 2019

​Moje prezentace z letošní konference GOPAS TechEd jsou ke stažení zde:

Zabezpečení RDP

Přihlašování do Windows pomocí TPM

duben 02
Windows Update a restarty serverů

Klasický požadavek. Nechceme, aby se nám servery po automatické aktualizaci restartovaly. S Windows 2016 se to trošku změnilo, tak je každý zmatený a neví, čeho se chytit. Tak tady je čeho se chytit. Připomínám, že se bavíme o serverech a nikoliv o Windows 10 stanicích.

Ten požadavek je špatně. Musíte to chápat opačně. Musíte restartovat ihned po aktualizacích.

Jakmile už Windows Update nainstaluje aktualizace, tak je restart neodkladný. Dříve to možná šlo technicky odložit, dneska už to po několika dnech ani nejde. Na Windows 2016 náhodou kliknu zaktualizovat, potom na to zapomenu, a pak se divím, že se to samo po několika dnech v horkém čase otočilo. Tak na to zapomeňte.

Jakmile se nainstaluje aktualizace, tak je restart nutný z principu. Něco jste v systému změnili a neúplně jste to zavedli. Restartovat musíte stejně. A to co nejdřív. Jinak se to může chovat nestabilně.

Takže otázka není, jak odložit restart. Restart chcete automaticky hned (co nejdříve) po instalaci.

Otázka je pouze o tom, kdy instalovat aktualizace. To jde pro serverové edice v pohodě nastavit přes GPO pomocí volby:

Computer Configuration
  Administrative Templates
    Windows Components
      Windows Updates
        
        Configure Automatic Updates
          2 - notify for download and autoinstall
          3 - auto download and notify for install
          4 - auto download and schedule the install

        Allow automatic updates immediate installation = DISABLED
Registry to jsou tyto:
  HKLM\Software\Policies\Microsoft\WindowsUpdate\AU
    AUOptions = DWORD = 2/3/4
    AutoInstallMinorUpdates = DWORD = 0

Z tohoto si vyberte. Volba 2 znamená, že musíte přijít a ručně tu aktualizaci spustit, navíc se to bude teprve potom stahovat. S volbou 3 to bude už samo staženo a připraveno, zahájit aktualizaci musíte i nadále ručně. Při nastavení 4 se to celé bude dělat ve stanovený čas, například jednou týdně někdy v noci.

Aktualizace bude chvilku trvat, asi nejdéle v případě volby 2.

Takže jediné, co k tomu potřebujete pořešit je co nejrychlejší následný automatický restart. K tomu máte tyto volby:

Windows 2019, Windows 2016, Windows 2012 R2, Windows 8.1, Windows 2012, Windows 8

  Always automatically restart at scheduled time = 15 min
  No auto-restart with logged on users for scheduled automatic updates installations = DISABLED

Těch 15 minut je minimum, ale znamená to, že celý proces aktualizace včetně restartu bude trvat něco jako půl hodinky plus železný restart, pokud to je hardware. Pro starší systémy to buď necháte ve výchozím stavu, nebo nastavíte následující:

Windows 2008 R2, Windows 7, Windows 2008, Windows Vista, ...
    
  Delay restart for scheduled installations = 5 min
  No auto-restart with logged on users for scheduled automatic updates installations = DISABLED

Doporučena kombinace pro všechny server OS - pouze ruční instalace plus restart ihned

Computer Configuration
  Administrative Templates
    Windows Components
      Windows Updates

        Configure Automatic Updates
          3 - auto download and notify for install

        Allow automatic updates immediate installation = DISABLED

        Always automatically restart at scheduled time = 15 min
        Delay restart for scheduled installations = 5 min

        No auto-restart with logged on users for scheduled automatic updates installations = DISABLED

        Reschedule automatic updates scheduled installation = DISABLED
        Allow non-administrators to receive update notifications = DISABLED

Doporučena kombinace pro všechny server OS - automatická instalace v noci plus restart ihned

Computer Configuration
  Administrative Templates
    Windows Components
      Windows Updates

        Configure Automatic Updates
          4 - auto download and schedule the install
          schedule install day: saturday, 3:00

        Allow automatic updates immediate installation = DISABLED
    
        Always automatically restart at scheduled time = 15 min
        Delay restart for scheduled installations = 5 min

        No auto-restart with logged on users for scheduled automatic updates installations = DISABLED

        Reschedule automatic updates scheduled installation = DISABLED
        Allow non-administrators to receive update notifications = DISABLED
listopad 15
Na co je a na co není biometrika

Zase vyšel jeden článek, který nějak nerozumí biometrice. V článku je zajímavá jenom ta technologie. Veškerá ostatní omáčka je nesmysl.

Biometrické ověřování vždycky trpělo a bude trpět tím, že ho lze oblbnout a že svoje biometrická data zanecháváme kudy chodíme. Ať to bude dokonalé jakkoliv, tak vždycky půjde udělat falešný otisk, obličej, hlas, nebo prd, pokud seženeme ten správný vzorek od skutečného majitele. Má to i technicky prostě vždy nějakou false acceptance rate (FAR) - pustí to někoho jiného - a false rejection rate (FRR) - nepustí to toho správného.

Je tedy kravina chtít používat biometriku na placení v obchodě, nebo výběr z bankomatu. Nebo na vstup do budovy, nebo přihlašování na libovolné počítače ve společných (open space) prostorách. Biometrika je naopak velmi pohodlná pro uživatele vlastních zařízení, jako jsou mobily, osobní notebook, nebo hardware multifaktorové předměty, kde to nahradí PIN.

Jenže to je ten rozdíl. Mobil nebo notebook máte pořád při sobě a nikdo cizí se k němu nedostane. Čipovou kartu nebo token máte také při sobě a biometrika omezuje jeho použití při náhodné ztrátě a nálezu cizincem.

Takže útok na můj mobil s nějakým master otiskem neexistuje. Na zdraví!

srpen 06
Ukládání tajných informací a hesel pro skripty a naplánované úlohy

To je věčná otázka. Máte skript, nebo naplánovanou úlohu, nebo třeba dokonce službu, a potřebujete, aby měla k dispozici nějakou tajnou informaci, jako je třeba heslo k nějakému účtu, nebo šifrovací klíč k datům v databázi. Jak ho na počítači "bezpečně" uložíte?

Internet se hemží různými návody, jak uložit například PSCredentials do XML, nebo používat jakýsi cizí Get-PnPStoredCredential a ukládat hesla do takového toho zabudovaného trezoru na hesla.

To jsou všechno zbytečné obezličky. Já používám rovnou to nejjednodušší, přímo DPAPI, nad kterým jsou všechny ty ostatní metody stejně postaveny, a které je používáno libovolnými systémovými službami i aplikacemi. DPAPI je už minimálně od Windows 2000 zabudováno do systému a .NET Framework má pro něho už od verze 2.0 (a PowerShell 2.0 tedy také) statickou metodu, takže pohoda.

Jednoduché vysvětlení DPAPI

Detaily si můžete poslechnout na letošním hackerfest od Michaela Grafnettera. Mě zajímá princip. DPAPI (Data Protection API) vám jednoduše zašifruje cokoliv si řeknete svým náhodným klíčem. Každý počítač má svůj náhodný klíč per-machine. Tento klíč je uložen v systémových registrech počítače, nebo v systémovém profilu na disku (%windir%\system32\config\systemprofile) - Grafi bude vědět přesněji - je prostě na disku.

Každý uživatel má ve svém profilu (nejspíš opět v jeho registrech) také svůj náhodný profilový klíč, tedy per-user-profile. Schválně píšu per-user-profile, protože bez cestovního profilu máte na každém počítači jiný klíč, zatímco s profilem cestovním (roaming profile) máte všude klíč stejný. Také je důležité, že se jedná o profil, protože například IIS pracovní procesy (app pool) se ve výchozím stavu startují bez profilu a pokud u nich chcete DPAPI využívat, musíte jim profil zapnout ve vlastnostech apppool (processModel.loadUserProfile).

V uživatelském profilu je tento šifrovací náhodný klíč chráněn ještě navíc uživatelovým přihlašovacím heslem a paralelně AD záchraným klíčem. Je to tedy imunní proti offline krádeži profilu a díky AD klíči i proti resetu hesla správcem v AD. Lokální účty naopak nejsou imunní proti reset hesla správcem. Opět Grafi bude vědět detaily, předpokládám.

DPAPI umí použít buď tento per-machine, nebe per-user-profile náhodný klíč k tomu, aby vám zašifrovalo nějaká data. Pokud si to necháte zašifrovat per-machine, na daném počítači si to dešifruje úplně kdokoliv, nemusí být ani členem skupiny Administrators (příkladem je například SharePoint passphrase, jak už jsem tu o ní dávno psal). Pokud se k OS disku někdo dostane offline, také to dešifruje.

Pokud použijete klíč per-user-profile, tak to dešifruje pouze stejný uživatel na stejném počítači pokud nemá cestovní profil (roaming profile). Pokud cestovní profil má, tak na libovolném jiném počítači také.

Jak to použít z PowerShellu? Nejprve jeho obvyklé typy a práce s nimi

Člověk sbírá tajné údaje z hvězdiček jako SecureString:

$tajemstvi = Read-Host 'Zadej heslo nebo jine tajemstvi' -AsSecureString
$tajemstvi.GetType().FullName   # System.Security.SecureString

Nebo si to zkonvertuje z plaintextu:

$tajemstvi = ConvertTo-SecureString 'tajemstvi co je tajne' -AsPlainText -Force
$tajemstvi.GetType().FullName   # System.Security.SecureString

Nebo se zeptá rovnou na PSCredential:

$loginHeslo = Get-Credential -UserName 'gps\kamil' -Message 'Zadej heslo chlapku'
$loginHeslo.GetType().FullName   # System.Management.Automation.PSCredential

PSCredential lze rovnou založit přímo z plaintextu:

$loginHeslo = New-Object System.Management.Automation.PSCredential 'gps\kamil', (ConvertTo-SecureString 'Pa$$w0rd' -AsPlainText -Force)
$loginHeslo.GetType().FullName   # System.Management.Automation.PSCredential
$loginHeslo.UserName             # string
$loginHeslo.Password             # System.Security.SecureString

Poznámka. Už tady se používá DPAPI, sice jen paměťové, ale hodnota System.Security.SecureString je uložena v paměti opět v zašifrované formě (per-machine), aby to nešlo jenom tak prohlížet.

Ale bez problémů heslo dostanete ven i v čisté formě plaintextu:

$loginHeslo.GetNetworkCredential().Password   # Pa$$w0rd

Takže práce s tajnými údaji v PowerShellu by byla. Jak to uložit na disk, nebo do registrů, nebo do databáze?

Jak si nechat zašifrovat data pomocí DPAPI?

Jednoduše. Použijeme třídu System.Security.Cryptography.ProtectedData. Žádný klíč ani heslo nepotřebujete. Všechno je v počítači nebo ve vašem profilu samo od sebe. Jediné co ještě můžete přidat, když moooc chcete, je sůl (salt), neboli inicializační vektor (IV). Akorát tím zajistíte, že dvě stejné hodnoty by nemusely být zašifrovány stejným klíčem stejně (ale ony stejně nebudou, protože DPAPI samo vždycky zasolí nějakým náhodným číslem). Spíše tím zkomplikujete kreking, řekněme. Osobně necítím potřebu, vždycky je tam systémová sůl.

$tajnyText = 'Tohle je megasuper tajne'
$bajty = [System.Text.Encoding]::Unicode.GetBytes($tajnyText)

# per-user-profile
$zasifrovaneBajty = [System.Security.Cryptography.ProtectedData]::Protect($bajty, $null, 'CurrentUser')
[Convert]::ToBase64String($zasifrovaneBajty)

# per-machine
$zasifrovaneBajty = [System.Security.Cryptography.ProtectedData]::Protect($bajty, $null, 'LocalMachine')
[Convert]::ToBase64String($zasifrovaneBajty)

Dobrá, slanější je vždycky chutnější:

$tajnyText = 'Tohle je megasuper tajne'
$sul = 'Hlavne to Jiriku nepresol'
$bajty = [System.Text.Encoding]::Unicode.GetBytes($tajnyText)
$iv = [System.Text.Encoding]::Unicode.GetBytes($sul)

# per-user-profile
$zasifrovaneBajty = [System.Security.Cryptography.ProtectedData]::Protect($bajty, $iv, 'CurrentUser')
$tohleSeDaUlozit = [Convert]::ToBase64String($zasifrovaneBajty)
$tohleSeDaUlozit    # proste pekny ulozitelny text ve formatu Base64

# per-machine
$zasifrovaneBajty = [System.Security.Cryptography.ProtectedData]::Protect($bajty, $iv, 'LocalMachine')
$tohleSeDaUlozit = [Convert]::ToBase64String($zasifrovaneBajty)
$tohleSeDaUlozit    # proste pekny ulozitelny text ve formatu Base64

Předpokládám, že uložit to Base64 zašifrované monstrum už zvládnete sami, ne?

Dešifrování DPAPI chráněných Base64 řetězců

Co jste si před chvilkou uložili ve formě Base64 zašifrovaného textu, si načtete a podle chuti přidáte původní inicializační vektor (IV):

$sul = 'Hlavne to Jiriku nepresol'
$iv = [System.Text.Encoding]::Unicode.GetBytes($sul)

# per-user-profile
$desifrovaneBajty = [System.Security.Cryptography.ProtectedData]::Unprotect(([Convert]::FromBase64String($tohleSeDaUlozit)), $iv, 'CurrentUser')
[System.Text.Encoding]::Unicode.GetString($desifrovaneBajty)

# per-machine
$desifrovaneBajty = [System.Security.Cryptography.ProtectedData]::Unprotect(([Convert]::FromBase64String($tohleSeDaUlozit)), $iv, 'LocalMachine')
[System.Text.Encoding]::Unicode.GetString($desifrovaneBajty)

A jak by řekl Babica, když nemáte inicializační vektor, dáte tam něco jinýho. Akorát dejte bacha, aby vám z toho nevyšla nějaká ta jeho dobrota.

červenec 24
Vypadávání počítačů (a DC) z domény

Zrovna včera jsem řešil problém s počítačem, jehož účet do domény se nějak "poškodil" a on přestal s doménou komunikovat. Jedná se vcelku běžný problém, který si každý nejspíš několikrát zažil. Včera to bylo ještě trošku speciálnější, protože šlo o řadič té domény (DC - domain controller). Projevilo se to tak, že jeho služby běžící pod účtem SYSTEM a Network Service prostě nedokázaly komunikovat s jeho vlastním, lokálně běžícím, Active Directory. Například nenabíhal DNS server a hlásil, že se nemůže dostat do domény, i když Active Directory normálně běžela.

O účtech počítačů jsem tu už psal, takže to se rozepisovat nebudu kromě malého připomenutí a shrnutí. Ale chtěl bych vysvětlit, proč a kdy se tyto chyby občas dějí, a že to není vlastně nic divného.

Fakta o účtu počítače

Počítače mají svoje heslo v registrech ve formě LSA secret v klíči MACHINE$.ACC. Tam je v plné formě. Toto heslo se uloží na účet počítače v Active Directory při připojení počítače do domény a poté si ho počítače každých 30 dnů samy mění. V Active Directory je heslo uloženo normálně ve formě hash, stejně jako všechno ostatní hesla.

Po změně má v registrech počítač svoje aktuální heslo a pro hladkost běhu ještě i heslo předchozí, aby ještě dokázal přijímat dříve vydané Kerberos TGS tickety svých klientů (pokud je to server pro nějaké klienty). Sám používá hned a pouze jen to nové heslo při komunikaci s DC - AD replikační prodlevy tu nehrají roli, protože máte PDC, a tudíž se to chová stejně jako v případě normálních uživatelských účtů.

Hesla počítačových účtů nikdy nevyprší. To znamená, že počítače si hesla mění samy dobrovolně. Pokud si heslo z nějakého důvodu počítač nezmění, prostě používá i nadále to původní. Například není problém, abyste měli stroj třeba rok vypnutý, po startu se s doménou spojí v pořádku. I když bude počítač několik měsíců mimo vnitřní síť (bez VPN), tak se zase nic neděje, i když celou dobu jede. V průběhu své nepřítomnosti se pokouší heslo změnit, nemůže kontaktovat AD, tak si ho samozřejmě nezmění.

Heslo počítače používají služby běžící pod účtem SYSTEM, Network Service, IIS APPPOOL a NT SERVICE pro přístup do sítě. Pokud by se heslo nějak poškodilo, tak nebude počítači fungovat například:

  • dynamická aktualizace vlastních DNS A záznamů v DNS, pokud to obvykle vyžaduje secure dynamic update
  • vydávání certifikátů počítače z AD CS
  • aktualizace zásad skupin (group policy) počítačového účtu. Zatímco uživatelské zásady se dříve stahovaly pod účtem uživatele, dnes už se nebudou stahovat ani ty
  • lokální interaktivní přihlašování (ctrl-alt-del) uživatelů, kteří nejsou nakešovaní. Účty uživatelů, které jsou na počítači nakešované od předchozích přihlášení se normálně přihlásí a dokonce se mohou pohybovat po síti, protože jejich účet je v pořádku. Lidé to sami moc tedy nepoznají, takže to bývá mnohdy dost dlouho neviditelné
  • ze sítě se na počítač s ověřením nedostanete a je jedno, jestli to je Kerberos, nebo NTLM
  • tím pádem nelze na počítač nic vzdáleně instalovat, ani se k němu nepřipojí žádný manadžovací server typu SCCM, SCOM, antivirový server apod.
  • na počítač se nedostanete ani přes RDP, protože NLA vás dál nepustí (to je to stejné, jako že se tam nedá dostat ze sítě na sdílené adresáře ani do WMI, PS Remoting apod.)

Obvyklé chybové hlášky při pokaženém hesle jsou:

Trust relationship between this workstation and primary domain failed

Target principal name is incorrect

Event ID: 5722
Source: NETLOGON
Event Type: Error
The session setup from the computer ComputerName failed to authenticate. The name of the account referenced in the security database is Computer$.

Oprava hesla se provede odpojením a opětovným připojením počítače do domény, nebo pomocí NETDOM RESETPWD, nebo pomocí Reset-ComputerMachinePassword. Samozřejmě pouze lokálně, protože vzdáleně se na mašinu nedostanete.

Proč se to proboha děje?

A dostáváme se konečně k jádru článku :-) Jak se to stane? Jak se to staně i DC samotnému? Jednoduše. Změna hesla není transakčně bezpečná.

Uvědomte si, o co se jedná při změně hesla počítače. Jde o distribuovanou transakci mezi dvěma mašinami. Vstupuje do toho počítač a DC. Počítač si vytvoří TCP spojení na DC a uvnitř nechá provést změnu hesla (ověří se, provede změnu buď přes SMB, DCOM nebo Kerberos). DC provede kontrolu kvality hesla a případně ho pomocí nějakého password filteru odešle do dalších připojených systémů. Následně si DC vypočítá jeho hash a tuto si uloží do Active Directory.

Když je heslo uloženo v AD, tak se po tom stejném TCP spojení pošle klientovi informace, že všechno je ok. Až tuto informaci klient dostane, uloží si nové heslo do registrů a původní heslo si pošoupne v registrech do zálohy. A je hotovo.

Jenže co se stane, když třeba:

  • data na disk se z Active Directory zapisují asynchronně, takže pokud DC zrovna klekne/zdechne/spadne/vypadne elektřina, tak se nové heslo do AD ve skutečnosti neuloží. Po příštím náběhu je v AD stále ještě heslo staré, zatímco stanice už chce používat jen to novější. V tomto případě se třeba i nadále dá na stanici dostat ze sítě, zatímco stanice si už nedokáže stahovat sama politiku.
  • co když upadne TCP spojení zrovna v okamžiku, kdy si AD uložilo heslo u sebe? V ADčku je heslo nové, stanice ale nedostala potvrzení o změně. Stanice tedy nové heslo u sebe neuloží a bude používat i nadále heslo starší. Což už použít nejde, protože AD má heslo novější, které ovšem stanice nezná. A šmitec.
  • stejně tak registry na stanici, ty se také zapisují na disk asynchronně. Takže pokud hned po změně dojde k výpadku proudu na počítači, tak se registry neuloží a opět stanice nové heslo nezná, zatímco na DC je přepsané.

A tak bych nmohl pokračovat. Nicméně síťové výpadky jsou nejspíš ten nejčastější důvod. Uvědomte si, jak často lidé přechází s notebookem z kabelu na wifi a na jinou wifi, a která také často padá. Síťová zařízení jsou občas přetížena atd.

Je to jen občas, ale ochrana proti tomu není žádná. Samozřejmě by mohl Microsoft vyvinout nějaký robustní transakční systémy, kdy se jak na AD, tak na počítačích tyto změny dokázaly roll-backnout v případě výpadků, ale to je tak složité a přitom neúspěch tak málo pravděpodobný, že to prostě řešit nechtěli.

Jednoduše si heslo resetnete, když se to projeví a hotovo.

Zajímavé je samozřejmě, že se to děje i na DC samotných. DC má také svůj účet, heslo v registrech a heslo v AD. Sice oboje na jedné mašině lokálně, ale procedura je stejná. I lokálně můžete mít výpadky proudu, pády služeb, nebo výpadek síťového spojení (zakvedlejte kabelem, nebo vypněte switch, uvidíte).

Snapshot, imidž, checkpoint

Prosím vás, i tohle je jeden z důvodů, proč nepoužívat virtualizační snapshoty, checkpointy, nebo diskové image, a jak je to nejisté. Možná vám virtualizace nabízí různé ochrany typu GenerationID, ale pokud vrátíte staré heslo, tak není cesta, jak to "samo"opravit a musíte stejně zasáhnout ručně.

1 - 14Next
>