Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > default
únor 05
Rizika spouštění PowerShell skriptů a jak je (ne)omezit plus úvahy o možnostech black-listingu

Pořád tu píšu o PowerShellu. Uveřejnil jsem mnoho demonstračních proof-of-concept hacking skriptů (jako je třeba neviditelné registrové hodnoty, čtení seznamu uživatelských účtů/loginů pomocí zkoušení SID a RID a následné zamykání, čtení LSA secrets z registrů běžícího počítače, nebo skenování IP a MAC adres a určitě i jednoduchý Keylogger).

Je tedy možné, že byste chtěli uživatelům zabránit ve spouštění PowerShell skriptů. Jde to? V podstatě to nejde úplně. Můžete se pokusit trošku to omezit nebo to více zkomplikovat, ale nejspiš tomu úplně nezabráníte. Taky uvažte, že musíte dovolit spouštět skripty správcům a kdoví jakým instalacím a programům.

Jaké máte tedy možnosti?

Použití Group Policy (GPO) na vynucení podepsaných skriptů (code signing) a úplné zakázání

Před Group Policy (GPO, zásady skupiny) můžete vnutit na počítače zásadu takovou, že se spouštěcí politika (PowerShell execution policy) nastaví na AllSigned. To by znamenalo, že se dají spouštět pouze digitálně podepsané skripty. Digitální podpisy do skriptů můžete dávat i sami pomocí Code Signing certifikátu, který si buď koupíte, nebo si vydáte vlastní z Windows AD CS autority. Tuto politiku najdete v počítačové i uživatelské části objektu a dá se tedy řídit i jen pro některé uživatelské účty:

User Configuration - Policies - Administrative Templates - Windows Components - Windows PowerShell
Computer Configuration - Policies - Administrative Templates - Windows Components - Windows PowerShell
  Turn on script execution
    Allow only signed scripts

nebo česky

Konfigurace uživatele - Zásady - Šablony pro správu - Součásti systému Windows - Windows PowerShell
Konfigurace počítače - Zásady - Šablony pro správu - Součásti systému Windows - Windows PowerShell

Výsledek nastavení na stanici, kde se promítá nějaká centrální zásada a současně tam je třeba něco nastaveno lokálně, se dá prohlédnout pomocí Get-ExecutionPolicy -List. Tahle zásada je dokonce silnější, než parametr -ExecutionPolicy pokud spouštíte powershell skript z příkazové řádky nebo BAT souboru. Takže je to poměrně slušné omezení. Akorát to nefunguje

Pokud byste chtěli spouštění skriptů zakázat úplně, touto politikou to nejde. Museli byste pomocí Group Policy Preferences distribuovat registrovou hodnotu:

User Configuration - Preferences - Windows Settings - Registry
  HKCU\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
  ExecutionPolicy = REG_SZ = Restricted

Computer Configuration - Preferences - Windows Settings - Registry
  HKLM\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
  ExecutionPolicy = REG_SZ = Restricted

nebo česky

Kongigurace uživatele a Konfigurace počítače - Předvolby - Nastavení systému Windows - Registr

To je sice pěkné, ale bohužel tahle možnost už není ani silnější, než parametr -ExecutionPolicy pro powershell.exe. Takže pokud někdo spouští skript nikoliv poklikem, ale z příkazové řádky například takto, tak to projde a neomezíte ho:

powershell -ExecutionPolicy Bypass -File "mujskript.ps1"

Parametr -Command, -EncodedCommand a copy-paste metoda

Nicméně, i když cokoliv omezíte, nebo zablokujete v politice, stejně vám to nepomůže. Powershell.exe má parametr -Command na jehož obsah se execution policy vůbec nevztahuje. Takže každý si spustí klidně celý skript přímo napsaný jako parametr powershell.exe.

Mohlo by se zdát, že by mohl mít problémy se zadáváním různých speciálních znaků přímo z CMD příkazové řádky, ale to není problém, protože -EncodedCommand prijímá Base64 zakódovaný skript a tím se to krásně vyřeší.

Ještě pěknější je metoda copy-paste. Prostě si člověk hodí zdroják svého skriptu do schránky a do powershell příkazového okna ho paste vloží pravým tlačítkem myši. Opět totálně bez vlivu execution policy.

Cesta přes RDP RemoteApp

Provozujete terminal server (TS, RDS - remote desktop services) ve formě vzdálených aplikací (RemoteApp). To znamená, že uživatelé vidí pouze okno vzdálené aplikace a dokonce se nemohou dostat vůbec na celou plochu RDP serveru.

Člověk by si řekl, že takto není možné spustit powershell, protože se k němu nemáte jak proklikat. Pokud ho náhodou správce nevypublikoval jako jednu z RemoteApp (nebo tedy cmd.exe). Omyl.

Pokud má vaše vzdálená aplikace k dispozici normální Windows průzkumníkové (explorer) ukládací dialogové okno, tak se stačí proklikat do C:\Windows\System32\WindowsPowerShell, najít tam powershell.exe a pravým tlačítkem zvolit Open / Otevřít. Následující obrázek to snad dostatečně dokumentuje:

Napadlo mě proti tomu použít další zásadu, která blokuje přístup průzkumníka (Windows Explorer neboli ponovu File Explorer) na různé disky, ale stejně to nepomůže. Sice se k adresáři C:\Windows\System32\WindowsPowerShell neproklikáte, ale pokud rovnou nahoru ručně do adresního řádku napíšete celou cestu, tak se PowerShell spustí. Dokonce vám doskakují nabídky podadresářů, i když na disk údajně nemůžete. Ale i tak to může být zajímavá zásada, zablokovat z průzkumníka jednoduchý přístup na disk C:

User configuration - Policies - Administrative templates - Windows components - File Explorer
  Prevent access to drives from My Computer

nebo česky

Konfigurace uživatele - Zásady - Šablony pro správu - Součásti systému Windows - Průzkumník souborů
  Zabránit přístupu k jednotkám ze složky Tento počítač

Použití Software Restriction Policies na zakázání powershell.exe

Už od Windows XP máte na všech verzích operačních systémů technologii Software Restriction Policies (SRP, Zásady omezení softwaru), které umožňují blokovat spouštění jednotlivých EXE podle jejich celé diskové cesty, nebo i jen jména, nebo například hash (otisku) jejich binárního obsahu. Tyto zásady jsou jak v části uživatele, tak i v části počítače GPO.

Uživatelská část hodí výborně, protože umožňuje cílit toto omezení přímo na konkrétní skupinu uživatelů (například pomocí security filtering aplikovaného na celé GPO, nebo podle organizační jednotky OU). Celé nastavení najdete tady:

User Configuration or Computer Configuration
Policies - Windows Settings - Security Settings - Software Restriction Policies
  Additional Rules
    c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe
    c:\windows\system32\WindowsPowerShell\v1.0\powershell_ise.exe
    powershell.exe
    powershell_ise.exe

 neboli česky

 Konfigurace uživatele - Zásady - Nastavení systému Windows - Nastavení zabezpečení - Zásady omezení softwaru
   Další pravidla

Zakázal jsem také ISE, což je snad pochopitelné. Upozorňuji, že powershell se takto nespustí ani v případě, že kliknete pravým tlačítkem na PS1 soubor, i kdyby byl digitálně podepsán. Nespustí se ani z BAT/CMD skriptu. Hláška bude něco jako This program is blocked by group policy - Tento program byl zablokován vaším správcem systému, nebo Tento program je blokován zásadami skupiny.

Všimněte si, že jsem zakázal cestu do WindowsPowerShell adresáře, ale také samotné jméno procesu powershell.exe. Tady právě narážíme na problém.

Když zakážete program přesnou cestou, tak stačí uživateli jeho EXE prostě zkopírovat někam jinam. Třeba k sobě na plochu. Odtud už spustit půjde, protože to má jinou diskovou cestu. Snažím se jim to tedy trošku zkomplikovat tím, že jsem zakázal i powershell.exe jenom jako jméno programu. Takže nepůjde spustit od nikud. Samozřejmě se útočníkovi nabízí úplné přejmenování souboru.

Tomu už bohužel nezabárníte, pokud používáte black-listing a nikoliv white-listing, tak s tím nic nenaděláte. Mohlo by vás napadnout blokovat všechny možné verze powershell.exe podle jeho hash, ale to se dá také krásně obejít například digitálním podpisem EXE. Metoda black-listing prostě není nikdy absolutní. Takto je to snad dost velká obstrukce alespoň pro začátečníky. Otázka je, kdo je hacker powershellista začátečník...

Použití AppLocker (Application Control Policies - Zásady řízení aplikací) k omezení spouštění a běhu powershell.exe

Technologie AppLocker je novější a vylepšená verze SRP, je k dispozici až od Windows Vista a Windows 2008, ale hlavně je jen na serverových edicích (terminal server, RDS) a na Enterprise edicích stanic. Takže použití je omezené. A samozřejmě v režimu black-listing vám nabízí v podstatě to stejné jako SRP, které jsou dostupné kdekoliv.

Má to nějaké podružné výhody, zvláště pokud nechcete stritknější white-listing, tak se věci jako audit-only režim na nic moc nehodí. Group policy object obsahuje jen počítačovou konfiguraci, takže se to sice aplikuje na počítače, ale pravidla se dají specifikovat podle jednotlivých uživatelských skupin.

Opět můžete vyjmenovat spustitelný program pomocí jeho plné cesty (Path rule), ale nemůžete už určit jenom jméno souboru, musí mít plnou cestu. To se ale udělá pomocí jiného typu pravidla - Publisher rule - tedy podle jméno vydavatele, který digitálně podepsal powershell.exe a/nebo podle jména souboru. Teď už bude složitější to powershell.exe někam vykopírovat, protože nestačí ten soubor ani přejmenovat, ani třeba podepsat nějakým svým vlastním podpisovým certifikátem - musela by se odstranit původní signatura, což je o něco náročnější (pracuju na tom :-)).

V group policy (zásadách skupiny) najdete AppLocker nastavení zde (nezapomeňte zapnout službu Application Identity (appidsvc), která se o tuto technologii stará):

Computer Configuration - Policies - Windows Settings - Security Settings - Application Control Policies - AppLocker

nebo česky

Konfigurace počítače - Zásady - Nastavení systému Windows - Nastavení zabezpečení - Zásady řízení aplikací - AppLocker

Auditování a sledování procesů

Pokud byste si zařídili nějaké sledování bezpečnostních událostí například přes SCOM, tak můžete auditovat události Detailed tracking - Audit process creation (Podrobné sledování - auditovat vytvoření procesu), kde se dá zachytávat spouštění procesů. A to už můžete nějak sledovat a případně reagovat.

Kdo se chce naučit sledovat události pomocí SCOM, dojde na můj kurz GOC170, který se zabývá vytvářením management pack balíčků právě pro System Center Operations Manager.

Závěr

Zakázat powershell pro uživatele není úplně sranda, ale za pomoci AppLocker dosáhnete poměrně kvalitního výsledku i pokud používáte jen black-listing namísto tvrdého white-listingu, kterým byste zakázali všechno a jenom povolovali výjimky.

Při přístupu black-listing samozřejmě uživatelům nic nebrání stáhnout něco z internetu a spustit to, ale už tím omezením powershellu vyblokujete primární utočný povrch dneška. Zvláště na RDS (remote desktop services).

Pokud zavedete ještě sledování (auditing), máte velmi slušnou ochranu, protože ani členové skupiny Administrators nezvládnou jednoduše vypnout auditování bez předchozího spuštění nějakého procesu, nebo právě powershellu.

únor 01
Správné použití Get-Random a Random třídy nebo raději něco lepšího

X krát jsem se setkal s tím, že skriptaři, ale ani programátoři nesprávně používají generátor náhodných čísel, který mají k dispozici v NET framework a tedy i v PowerShellu. Dokonce jsme v jednom pentestu po restartu dostával stejné SMS jako OTP (one time password), což asi nebude to pravé ořechové.

Pokud skriptujete, tak nejspíš používáte Get-Random. Tak ho prostě používejte. A hlavně tam nedávejte parametr -SetSeed. Zkuste si to. Normálně pusťte několik oken PowerShellu a dejte si Get-Random 100 například. Dostanete pokaždé jiné náhodné číslo. Tak jste to asi chtěli :-)

Parametr -SetSeed vám naopak zajistí, že dostanete pokaždé úplně stejnou sérii náhodných čísel. Zkuste si to. Do každého okna PowerShellu na každém počítači na světě kdykoliv zadáte například Get-Random 100 -SetSeed 999 tak dostanete 62. Proč a na co to je?

No někdy potřebujete testovat skripty pokaždé se stejnou sadou náhodných čísel. Jednou to otestujete na nějakém vzorku a když to předěláte, tak by možná bylo dobré to zkusit na stejném. K tomu je SetSeed. Prostě nějak inicializuje ten pseudonáhodný generátor. On má v sobě nějakou náhodnou řadu, pokaždé stejnou. A pokud se inicializuje stejným číslem, tak to bude všude stejná řada.

Jestli chcete náhodnost, tak ho nechte, ať se inicializuje sám podle "hodin".

Pokud vyvíjete pomocí netfx třídy (class) System.Random, tak to máte to stejné. Cmdlet Get-Random používá tu stejnou třídu. Takže constructor Random(999) vám nastaví stejné semeno a volání Next(100) vám dá to stejné, tedy číslo 62. Můžete to zkusit rovnou z PowerShellu:

$rnd = New-Object Random 999
$rnd.Next(100)

Opakuji. Seed je tam na testy. Nikoliv na provoz.

Jak ten Get-Random a Random vlastně generují?

Podíval jsem na zdroják (http://referencesource.microsoft.com) a zjistil jsem, že pokud nepoužijete seed ručně, tak to tam použije samo aktuální Environment.TickCount.

Na základě Seed hodnoty (buď vámi zadané, nebo získané z TickCount) si vygeneruje padesátipětiprvkovou řadu, kterou potom používá. No fuj. Takže to moc bezpečné náhodné číslo není.

Uvědomte si, že jakmile budou mít dva počítače stejný TickCount, tak to bude dávat stejné výsledky. TickCount je počet 100ns intervalů od startu počítače, takže trefit se je asi poněkud nemožné, ale přece. Navíc ta hodnota jenom stabilně a pořád stejně rychle roste. Takže pokud to v nějakém okamžiku zachytíme, můžeme predikovat do budoucna. Počítač startuje také obvykle poměrně stejně rychle. Nahození služby tedy bude někde v nějakém intervalu.

Samozřejmě pro skriptování nejspíš v pohodě. Ale pro slušný vývoj?

Skutečný kryptograficky slušný (pseudo)náhodný generátor

Musíte na to používat systémovou knihovnu (crypto service provider), který je obalený třídou RNGCryptoServiceProvider. Ta obaluje cryptoAPI CSP knihovnu Microsoft Enhanced Cryptographic Provider v1.0. Tenhle poskytovatel používá standardní SP800-90 AES-256 counter mode (CTR_DRBG). Do náhodného čísla míchá (detaily zde, kapitola 5.3.2 SystemPrng) nejenom počet tiků, míchá tam i aktuální systémový čas, který bude různý po každém restartu. Míchá tam dále například čítač hardware přerušení, který neroste rovnoměrně. Přimíchává do toho i čítače spotřeby paměti a místa na disku, které občas také klesají apod. Pokud máte TPM, tak to cucá hardware entropii z TPM. Celkově je potřeba do náhody dát co nejvíc věcí, které jsou mimo schopnosti člověka to ovlivnit.

$cryptoRnd = New-Object System.Security.Cryptography.RNGCryptoServiceProvider
[byte[]] $numbers = New-Object byte[] 1
$cryptoRnd.GetBytes($numbers)
$cryptoRnd.Dispose()

Takhle je to správně, pokud už vyvíjíte něco opravdu cíleného na bezpečnost.

únor 01
Jak osvěžím detekci typu sítě a profilu ve Windows Firewall

Dneska jenom rychlovka - Windows Firewall závisí na detekci síťového připojení a podle toho si nastavuje profil a tedy sadu pravidel a chování.

Obvykle vás zajímá pouze rozlišení mezi Domain network a Public network. Někdy se to detekuje špatně. Je za to zodpovědná služba Network Location Awareness (NLA, česky viz moje překladová tabulka služeb). Jenže se startuje moc brzo (Automatic) a někdy ještě není úplně rozjetá síť, ale přitom máte zastrčené kabely.

Pokud byste teprve později kabelem (nebo WiFi) zakvedlali, tak se to předetekuje. Ale pokud na nic nesaháte, tak se nová detekce neprovádí. A Windows Firewall máte ve veřejném (public) profilu. Když to chcete nechat osvěžit a tu detekci aktualizovat, jednoduše restartněte NlaSvc službu.

Restart-Service NlaSvc -Force

Upozorňuju, že pokud na Windows 2008 a Windows 2008 R2, které je PDC vypnete IPv6, tak to bude navždy v Public profilu. Ona totiž NLA služba používá LDAP UDP ping na PDC a pokud je to zrovna samo PDC tak to samozřejmě posílá na loopback/localhost 127.0.0.1. A jak soudruzi v jůesej zapomněli otevřít port UDP 389 na téhle IPv4 adrese, tak tam prostě nejde pingnout. Na Windows 2012 už to poslouchá paušálně na 0.0.0.0 takže tam to není problém.

leden 21
Účty, které si už dlouho nezměnily heslo aneb pwdLastSet atribut

O heslech v Active Direcotry (AD DS) jsem už psal třeba tady a tady a tady. Ale dnes jsem dostal mailem otázku, jak zjistím všechny účty, které si nezměnily svoje výchozí heslo.

Takový skript bude o něco složitější, takže můžeme začít nejprve jednoduše. Zjistíme všechny uživatelské účty, které si už dlouho nezměnili heslo. Déle v mém skriptu znamená déle než třicet dnů:

dsquery * domainRoot -filter "(&(objectCategory=person)(objectClass=user)(!userAccountControl:1.2.840.113556.1.4.803:=2)(pwdLastSet<=$(([DateTime]::Now.AddDays(-30) - [DateTime]::Parse('1601-01-01')).Ticks))(pwdLastSet>=1))" -attr sAMAccountName,userPrincipalName

Používám k tomu PowerShell a v něm utilitu dsquery, protože ActiveDirectory module každý nemá. Používám standardní LDAP search string. Uvnitř začínám s filterm na objectCategory=person, protože tohle je na všech verzích schematu indexované a tím pádem to bude maximálně rychlé. Vyhledají se tím user a inetOrgPerson účty a také contact objekty, které ale nechceme. Dále tedy potřebujeme filter na objectClass=user, abychom vyhodili kontakty.

Následně tam mám filter na userAccountControl, který nesmí obsahovat bit 2 - tedy účet nesmí být zakázaný (disabled), technickými slovy mít příznak ACCOUNTDISABLE. V tomhle filtříku se používá bitový AND (bitwise and) vyhledávací MS OID modifikátor 1.2.840.113556.1.4.803.

A dále už k tomu nejdůležitějšímu - tedy pwdLastSet. Atribut pwdLastSet obvykle obsahuje datum poslední modifikace hesla. Píšu obvykle, protože to není vždy. Pokud zaškrtnete na účtu, že si uživatel musí změnit heslo při příštím přihlášení (user must change password at next logon), tak to ve skutečnosti pouze vynuluje pwdLastSet atribut. Pokud tohle zaškrtávátko někdy později vypnete, tak do pwdLastSet nastaví natvrdo aktuální datum.

Takže tomuhle atributu je potřeba věřit jenom tak nějak opatrně :-) Proto testuju, jestli je sice starší, než 30 dnů, ale současně musí být hodnota větší než 0. V LDAP filterech nemůžete používat ostrou nerovnost, takže nezbývá než porovnávat na větší rovno 1.

Co tímhle vyhledávacím filtrem tedy najdete? Účty, které si už opravdu dlouho nezměnily heslo. Ale nenajdete účty, kterým bylo manipulováno s příznakem user must change password at next logon.

Ale už i tohle by mohlo někomu stačit.

Lepší vyhledání všech nezměněných hesel pomocí replikačních metadat

Možná vám nestačí nedokonalý atribut pwdLastSet. Máme jinou metodu? Ano. Musíme se podívat na vnitřní replikační metadata (replication metadata) každého jednotlivého uživatele a zjistit, kdy se naposledy skutečně změnilo heslo v atributu unicodePwd. Bez téhle informace nemůže fungovat replikace, takže to je naprosto přesná a jistá hodnota. Akorát to bude trvat déle, protože replikační metadata (přesněji řečeno žádný computed/constructed atribute) nelze vyhledat rovnou pomocí LDAP search.

Musíme si načíst každý účet, z něho vyndat constructed atribut msDS-ReplAttributeMetaData a z něho to vyčíst. Upozorňuji, že to funguje až od DC řadičích verze Windows 2003. Na řadičích Windows 2000 tento atribut nebyl k dispozici.

function Get-UnchangedPasswords ([int] $sincePastDays) 
{
  $root = [ADSI] 'LDAP://RootDSE'
  $searcher = [ADSISearcher] ([ADSI] ('LDAP://{0}' -f $root.defaultNamingContext.Value))
  $searcher.Filter = '(&(objectCategory=person)(objectClass=user))'
  $searcher.SearchScope = 'subTree'

  [Collections.ArrayList] $nonChangedPasswords = @()

  $pastDate = [DateTime]::Now.AddDays(- $sincePastDays)

  foreach ($oneResult in $searcher.FindAll()) { 

    $user = [ADSI] $oneResult.Path
    $user.RefreshCache('replPropertyMetadata')
    $user.RefreshCache('msDS-ReplAttributeMetaData')
    $replBin = $user.Get('replPropertyMetadata')
    $replBinText = [BitConverter]::ToString($replBin)
    $replTxt = $user.Get('msDS-ReplAttributeMetaData')

    $unicodePwdReplMeta = $replTxt | % { [xml] $_ } | ? { $_.DS_REPL_ATTR_META_DATA.pszAttributeName -eq 'unicodePwd' } | select -Expand DS_REPL_ATTR_META_DATA
 
    $theDate = [DateTime]::Parse($unicodePwdReplMeta.ftimeLastOriginatingChange)
    if ($theDate -le $pastDate) {

      $nonChangedPwd = New-Object PSCustomObject
      Add-Member -Input $nonChangedPwd -MemberType NoteProperty -Name sam -Value $user.sAMAccountName.Value
      Add-Member -Input $nonChangedPwd -MemberType NoteProperty -Name upn -Value $user.userPrincipalName.Value
      Add-Member -Input $nonChangedPwd -MemberType NoteProperty -Name lastPwdChange -Value $theDate
      Add-Member -Input $nonChangedPwd -MemberType NoteProperty -Name isDisabled -Value ((([int] $user.userAccountControl.Value) -band 2) -eq 2)
      Add-Member -Input $nonChangedPwd -MemberType NoteProperty -Name created -Value $user.whenCreated.Value
      [void] $nonChangedPasswords.Add($nonChangedPwd)
    }
  }

  return $nonChangedPasswords
}

No a to je celá věda :-) Další třídění a filtrování už zvládnete sami.

leden 20
Last minute - Brno - Active Directory internals and troubleshooting

Příští týden mám v Brně kurz "Active Directory internals​ and troubleshooting" a je tam aktuálně last-minute sleva, tak neváhejte!

leden 15
Bezpečnostní auditování ve Windows - přihlašovací události

Dneska bych se rád pověnoval základům bezpečnostnímu auditování ve Windows a zvlášť demystifikaci událostí Logon (přihlášení) a Account Logon (přihlášení k účtu, ověření pověření). Oboje obsahuje slovo "logon", což je dost matoucí, protože oba dva druhy představují v podstatě něco úplně jiného.

Plno dalších detailů se můžete dozvědět i na mém školení GOC175 v GOPASu. Samozřejmě přijďte také na vélmi aktuální konferenci ShowIT, kde sice moc o událostech nebude, ale zase to bude událost sama pro sebe.

Události typu logon event se mají spíše jmenovat session event. Zatímco události account logon event bych spíše nazýval authentication event. A to už by pomalu mohlo být přehlednější.

Oba dva druhy mohou být důležité. Pro oba dva druhy můžete využít i Alerty, nebo Rules ve SCOM a sledovat různé bezpečnostní zajímavosti. Případně se to velmi hodí pro zkoumání situace po nějakém incidentu. Jenom je vždycky potřeba přesně rozumět tomu, na co oba dva druhy jsou.

Už jsem se o auditování dříve zmiňoval, zde a zde a zde jsou nějaké tři starší článečky, které ho využívají.

Nejprve k otázce Account Logon (přihlášení k účtu, ověření pověření) event událostí

Account logon vzniká na počítačích, které přímo ověřují uživatelský účet - například heslo (password), nebo čipovou kartu (smart card), nebo certifikát (certificate). Tedy ve většině případů na Active Directory Domain Controller (AD DS DC), kdy se jedná o doménový účet. Pokud se jedná o lokální účet, tak taková událost samozřejmě vznikne přímo na počítači, který ten účet lokálně ověřuje, ale toho nebude nejspíš tolik, takže o tom ani nebudeme už dál přemýšlet.

Takové ověření bude buď pod-kategorie Kerberos Authentication Service (přihlašovací služba protokolu Kerberos) při vydávání TGT tiketu. Nebo Credentials Validation (ověření pověření) v případě NTLM ověření heslem a Schannel ověření TLS client authentication certifikátem. Může to být i Kerberos Service Ticket Operations (operace lístku služby Kerberos), tam jde o vydávání TGS ticketu na základě předchozího TGT ticketu. Ale pořád se to loguje na DC v okamžiku "ověřování" uživatelských tajných přihlašovacích údajů (secret authentication information podle CSN/ISO/IEC 27002)

Uvnitř události se nachází například číselná hodnota důvodu, proč se ověřit identitu nepodařilo. Není to tam napsáno textem, ale čísla lze jednoduše překládat pomocí ERR programu. Tady je tabulečka s důležitými kódy chyb, význam by měl být obykle jasný rovnou ze systémové hodnoty:

Stavový kód Hodnota Význam
STATUS_WRONG_PASSWORD 0xC000006A  
STATUS_PASSWORD_RESTRICTION 0xC000006C snažíte se přihlásit prázdným heslem v případě, že na účtu toto heslo skutečně je prázdné, ale je zakázáno se s ním přihlásit
STATUS_LOGON_FAILURE 0xC000006D  
STATUS_ACCOUNT_RESTRICTION 0xC000006E  
STATUS_INVALID_LOGON_HOURS 0xC000006F  
STATUS_INVALID_WORKSTATION 0xC0000070  
STATUS_PASSWORD_EXPIRED 0xC0000071  
STATUS_ACCOUNT_DISABLED 0xC0000072  
STATUS_LOGON_NOT_GRANTED 0xC0000155  
STATUS_LOGON_TYPE_NOT_GRANTED 0xC000015B  
STATUS_ACCOUNT_EXPIRED 0xC0000193  
STATUS_PASSWORD_MUST_CHANGE 0xC0000224  
STATUS_ACCOUNT_LOCKED_OUT 0xC0000234  
KDC_ERR_NONE 0x0
KDC_ERR_NAME_EXP 0x1
KDC_ERR_SERVICE_EXP 0x2
KDC_ERR_BAD_PVNO 0x3
KDC_ERR_C_OLD_MAST_KVNO 0x4
KDC_ERR_S_OLD_MAST_KVNO 0x5
KDC_ERR_C_PRINCIPAL_UNKNOWN 0x6
KDC_ERR_S_PRINCIPAL_UNKNOWN 0x7
KDC_ERR_PRINCIPAL_NOT_UNIQUE 0x8
KDC_ERR_NULL_KEY 0x9
KDC_ERR_CANNOT_POSTDATE 0xA
KDC_ERR_NEVER_VALID 0xB
KDC_ERR_POLICY 0xC
KDC_ERR_BADOPTION 0xD Kerberos delegation (delegace, neboli double-hop) není povolena a přitom se o ni žádolo
KDC_ERR_ETYPE_NOTSUPP 0xE špatný typ šifrování (encryption type), jako jsou problémy s AES, nebo DES a RC4 apod.
KDC_ERR_SUMTYPE_NOSUPP 0xF
KDC_ERR_PADATA_TYPE_NOSUPP 0x10
KDC_ERR_TRTYPE_NO_SUPP 0x11
KDC_ERR_CLIENT_REVOKED 0x12 účet zakázán
KDC_ERR_SERVICE_REVOKED 0x13
KDC_ERR_KEY_EXPIRED 0x17 heslo vypršelo, tohle platí i v případě čipové karty
KDC_ERR_PREAUTH_FAILED 0x18 špatné heslo, nebo neplatný certifikát - tohle jsou v Kerberos události, které také způsobují například zamykání účtu. Pokud Kerberos pre-authentication vypnete, tak se vám například ani nebudou zamykat účty.
KDC_ERR_PREAUTH_REQUIRED 0x19 tohle není vůbec chyba. Znamená to, že Kerberos vyžaduje pro ověření preauthentication a zrovna tento požadavek byl bez "hesla". Takže se to musí zkusit ještě jednou. Takhle to dělá Vista/7/8/2008 a novější ve výchozím stavu.
KRB_AP_ERR_SKEW 0x25 rozhozené hodiny

U Account Logon event jde o okamžiky ověření. Když se například ráno přihlašujete do Windows, tak se na blízkém DC objeví právě jeden Kerberos Authentication Service event. A potom dalších pár hodin nic. Když se z počíteče nebo ze sítě "odhlašujete", tak se už nic neobjevuje. To je proto, že pro "odhlášení" se vůbec nekontaktuje DC a tím pádem není ani co logovat.

Události typu Logon (přihlášení a odhlášení) event

Tyto události se narozdíl od událostí typu Account Logon event objevují primárně ne na DC, ale právě na stanicích a serverech, tedy tam, kde uživatel konkrétně pracuje. Tedy má tam session. Zde jsou k dispozici i logoff eventy, protože počítače vědí přesně, kdy končí session - jak interaktivní přihlášení, RDP, nebo ověřené síťové spojení.

Samozřejmě se uživatelé objevují občas i na řadičích domény (DC), protože si odtud stahují Group Policy, nebo se dívají do AD LDAPu, ale to je teď druhořadé.

Berme to tak, že Logon eventy se vám budou objevovat na stanicích a serverech. Zde vznikají v okamžiku vzniku paměťové struktury access token (o access tokenech jsem psal už tady, tady v souvislosti s aktualizací členství ve skupinách a třeba i tady v souvislosti s UAC).

Vznikají v okamžiku, kdy vzniká session. To znamená v okamžiku interaktivního přihlášení (interactive), přihlášení na RDP (remote interactive), připojení na existující RDP (unlock), odemknutí zamknutého desktopu (unlock), spuštění služby (service) nebo naplánované úlohy a IIS apppool (batch). Dokonce vzniká i pokud session vzníká z cache bez ověření na řadiči domény (cached logon). Toto je tedy na daném počítači, kde pracujete.

Ale logon event vzniká i pro každé TCP spojení, na kterém jste se ověřili. Taková událost (network logon) vzniká na serveru, kde to TCP spojení končí. Na klientovi nevzniká nic. Díky tomu jste schopni sledovat, který uživatel se kdy připojil na který file server, SQL server, web server apod.

Typ session se uvádí v události v položce logon type (typ přihlášení):

Type Value
Interactive 2
Network 3
Batch 4
Service 5
Unlock 7
NetworkCleartext 8
NewCredentials 9
RemoteInteractive 10
CachedInteractive 11
CachedRemoteInteractive 12
CachedUnlock 13

Vzhledem k tomu, že každá jak lokální, tak i síťová session někdy skončí, tak o ní daný počítače, nebo server obvykle přesně ví (kromě případu tvrdého resetu). Můžete tedy logovat i logoff (odhlášení) událost. Dozvíte se tedy přesně, kdy se například síťové spojení ověřilo a kdy skončilo. To se dá párovat pomocí Logon ID (neboli logon session ID, neboli ID přihlášení).

Je zajímavé, že do logon kategorie patří i account lockout (uzamčení účtu). To se ale neaudituje na řadičích, které účet zamykají, ale audituje se to na počítačích, na kterých právě kvůli zámku nemohla vzniknout daná session. Takže to bude vždycky jenom failure audit. Na řadičích DC se v takovém případě audituje Account Management event (událost správa účtu).

Pro přehlednost obrázky

Podívejte se na následující obrázky. Na prvním vidíte interaktivní přihlášení (interactive logon). Nejprve se zalohuje account logon event na řadiči domény a v zápětí na stanici logon event.

Když pak jdete do sítě (network logon), zaloguje se nejprve na AD DC řadiči opět nejprve account logon, protože se musí vydat Kerberos TGS lístek, nebo se musíte NTLM ověřit heslem. A hned potom se zaaudituje logon event na cílovém serveru, kde končí dané TCP spojení.

Shrnutí

Díky událostem account logon se dozvíte odkud a kdy a kdo se na řadičích domény DC ověřoval. Díky logon událostem se dozvíte na konkrétních počítačích, kdy na ně skutečně daný uživatel přišel, tedy na obrazovku, nebo kdy se připojil ze sítě. Díky logon událostem zjistíte také, kdy se nakonec odhlásil.

leden 15
Konference ShowIT 2016 v Bratislavě se blíží

Nečekejte a rychle se přihlašte na ShowIT! Po zkušenostech z podzimního ​HackerFestu se může stát, že bude vyprodáno pár týdnů dopředu. A ono už to není moc týdnů! Startujeme 4 dny od pondělí 8.2. 2016

Pro zajímavost moje přednášky. Ale bude tam dalších 40 přednášek pro ajťáky:

  • Forensní analýza šifrování BitLocker a TPM
  • Bezpečnostní novinky Windows 10, Windows 2016 a Hyper-V
  • PKI certifikační politiky pro podnikové prostředí
  • ADFS deep-dive

A samozřejmě večerní party jako součást programu!

leden 15
Vtípek co zapadnul v mailboxu

Jéé, před nějakou dobou jsem zřejmě dostal mail s tímhle vtipem, ale čtu ho až teď:

Turista v cizí zemi po pár dnech už značně znaven prohlížením historických památek si řekne, že by se chtěl kouknout i někam jinam. Rozhlídne se po náměstí a do oka mu padne zverimex. Vleze dovnitř s tím, že se mrkne, jakou exotickou zvířenu chovají místní ... rybičky - klasika, papoušci - klasika, králíci - klasika, želvy - dneska už i v jeho zemi takřka klasika ... opice - no konečně něco zajímavého, v jeho zemi nevídaného. Prohlíží je zprava, zleva ... prostě klasické opice. V tu chvíli vejde do obchodu zákazník a rovnou k prodavači, že chce jednu C++ opici. Prodavač ani nemrkne, vyndá z klece jednu opici a řekne si za ni 10 000$. Turistovi div že nevypadnou oči z důlků - znovu si prohlíží opice, ale nic zajímavého na nich neodhalí. Proto jde k prodavači a zeptá se proč jsou ty opice tak drahé. A prodavač okamžitě začne vychvalovat, jaká je to super investice, že ty opice umí programovat v C++ - krásný čistý kód.

Turista prohlíží dál obchod a najde druhou klec s identicky vypadajícími opicemi, ale cenovkou 20 000$. A opět mu to nedá a přeptá se na ně prodavače. A prodavač na to, že je to ještě lepší investice, protože ty dražší umí samozřejmě víc jazyků: C#, Javu, php, ajax, power shell ...

Do třetice najde klec v rohu, kde sedí jedna jediná osamělá opice, na pohled naprosto identická s předchozíma, ale s cenovkou 80 000$. Turista se vyděsí a zase jde za prodavačem, v čem že umí programovat tahle .... Prodavač se rozpačitě podrbe na hlavě a řekne: "Víte, od té doby, co ji tady máme, tak jsem ji vlastně neviděl nic dělat, ani nic programovat. Ale všechny ostatní opice jí poslouchají a říkají jí Project Manager"

leden 14
Zážitky z pole - single server ADFS 2.0 migrace na ADFS 3.0 farmu

Myslím, že je občas dobré podělit se s prakticky ověřeným výsledkem, zvláště když se jedná o ještě pořád poměrně novou technologii. Takže úspěšně jsem zmigroval jednoserverový AD FS 2.0 (Windows Server 2008 R2) na dvouserverovou NLB farmu s AD FS 3.0 (Windows Server 2012 R2) bez WAP (Web Application Proxy neboli ADFS Proxy) pro ověřování Office365 pro 20 tisíc uživatelů. Cílem je minimální výpadek, který jste schopni dostat do řádu cca 1 minuty.

Tak snad to někomu pomůže.

Zákazník nemá WAP, takže nerozlišíme klienty z internetu a z vnitřní sítě, ale to je zrovna tady požadavek zákazníka. Nemůžeme tím pádem bohužel také udělat extranet lockout, ale to už je prostě život :-) Kdo neví o co všechno se jedná, může přijít na můj kurz o ADFS :-)

Průběh akce do okamžiku, kdy už to budete muset přehodit na novou farmu:

  • zjistit jaké DNS jméno (A, nebo móžná CNAME) používá stávající ADFS 2.0. Budeme přecházet na NLB s Kerberos ověřením, takže budeme muset přejít za každou cenu na jeden A záznam.
  • zjistit login a heslo servisního účtu stávajícího ADFS 2.0, protože použijeme stejný. Stejný použijeme, protože nová farma se bude muset chvilku připravovat a přitom se musí počítat se stejným jménem (a tím pádem SPN - service principal name), jako u staré farmy.
  • nainstalovat na nové servery NLB a rozchodit ho při režimu No afinity. K tomu je vhodné rovnou si tam dát IIS, i když byste ho pro AD FS 3.0 už dneska přímo nepotřebovali, ale bude se nám hodit zaprvé na zkoušení NLB, ale hlavně na různé HTTP redirect na přihlašovací stránky apod. Můžete taky rovnou implementovat nějaký sledovací skript, který potom už jenom jednoduše přehodíte vůči ADFS URL.
  • vygenerovat nový, nebo přenést původní TLS/SSL server authentication certifikát z AD FS 2.0. Chceme veřejný certifikát, protože nemáme v tomto případě WAP a tím pádem bude Office365 čučet přímo na náš nový AD FS 3.0 server (ano, pokud chcete používat Outlook, tak za určitých situací se přímo Office365 připojuje k vám na vaše ADFS - což by nebylo potřeba, pokud byste používali pouze webový přístup přes prohlížeč - obecně passive client).
  • nainstalovat nejprve první a potom do nové farmy přidat i druhý AD FS 3.0 server. Použijeme stejné jméno jako původní AD FS 2.0. Použil jsem scénář bez plného SQL serveru, jen za pomoci nezávislých WID (Windows Internal Database) databází. Ověřeno, že to v AD nic nezničilo. SPN na účtu služby to nepokazilo a do kontejneru CN=ADFS,CN=Microsoft,CN=Program Data,DC=x to jenom přidává další unikátní identifikátory token-signing a token-encryption certifikátů.
  • staré token-signing a token-decryption certifikáty (self-signed) z původního ADFS 2.0 nepřenášíme, necháme vygenerované nové self-signed.
  • na DNS záznam zatím nesaháme a tudíž původní ADFS 2.0 stále běží a přidání nové farmy zatím nehraje žádnou roli.
  • na nové farmě můžeme tedy poladit některé věci, jako je třeba prodloužení životnosti self-signed token certifikátů pomocí Set-AdfsProperties -CertificateDuration a Update-AdfsCertificate -Urgent. Rád si také zkracuji ADFS replikaci uvnitř farmy, aby to jelo rychleji pomocí Set-ADFSSyncProperties -PollDuration.
  • na novou farmu můžete v klidu překlikat Relying Party Trust pro Office365. Ani teď to ještě pořád není v provozu a pořád běží původní ADFS 2.0. Upozorňuji, že jsem v tomto okamžiku ještě vůbec nesahal do Office365. Takže máme sice novou ADFS 3.0 farmu, ale Office 365 o ní prozatím vůbec neví.
  • můžete začít testovat ověrování a forms authentication tak, že si na několika vybraných klientech nastavíte novou IP adresu nové farmy do HOSTS souboru. Offíce 365 o nás pořád ještě neví, takže se nedostanete zaručeně dále, než k tomu, aby vás vaše ADFS přesměrovalo do Office365, kam se ale už nedostanete, protože Office365 o naší farmě pořád ještě neví.
  • pokud to neověřuje, zkontrolujte, jestli vám jede Kerberos S4U - musíte servisní účet toho ADFS dát do skupiny Windows Authorization Access Group. A pokud máte v pravidlech nějaké další AD atributy, musí servisní účet ADFS být schopen je číst přímo z AD DS LDAPu samozřejmě.
  • to ale nevadí, celé ověřování (login), formuláře i jejich grafické úpravy a odhlášení (sign-out) uvidíte a ověříte že to funguje, cookie jsou v pořádku a že to NLB balancuje a že je možné ho zhodit apod. Můžete si klidně rovnou upravit onload.js a ostatní věcí prováděné pomocí Set-AdfsWebTheme a Set-AdfsWebConfig. Protože dneska s AD FS 3.0 už nebudete modifikovat přímo zdrojové aspx soubory, ale musíte to konfigurovat pomocí PowerShell, nebo právě přes JavaScript getElementId() apod.
  • do IIS, které máte na ADFS 3.0 nainstalováno ručně navíc (nemusí tam být vůbec), můžete přidat libovolné HTTP redirect. Například z HTTP na HTTPS, přidat si tam HSTS a samozřejmě takové to zrychlovací přihlašovací URI, abyste z prohlížeče nechodil na dvakrát přes Office365 (něco jako https://adfs.gopas.cz/adfs/ls?wsignin1.0&wtrealm=https://portal.gopas.cz).
  • ani jsem nečekal, že by nemělo fungovat, ale přesto jsem ověřil, že NLB jede jak v unicast mode, tak v multicast mode režimu.

Teď už jste nachystaní na přeskok. Víme, že nová ADFS farma funguje až do okamžiku, kdy to ověřeného uživatele přesměruje do Office365 a ten ho odmítne. Odmítne ho proto, že nově generované tokeny jsou digitálně podepsané novým self-signed certifikátem, o kterém Office 365 nic neví. V tomto okamžiku už musíte udělat definitivní přehození.

  • nemusíte měnit v DNS IP adrese (zbytečně dlouhé TTL), stačí přehodit IP adresu mezi starou a novou AD FS farmou, takže i ta vlastně zůstane původní.
  • to podstatné ale musíte změnit v Office365. Musíte zaktualizovat token-signing certifikát. Použijete Azure AD PowerShell module.
Import-Module MSOnline
Get-Credential
Connect-MSOLService
Get-MSOLFederationProperty
Set-MsolADFSContext -Computer localhost -LogFile
Update-MSOLFederatedDomain

  • poslední krok, který nezapomeňte, je buď úplně vypnout starou ADFS 2.0 farmu, nebo na ní minimálně vypnout právě aktualizaci token-signing certifikátů. Míváte to tam zaregistrováno jako naplánovanou úlohu (task scheduler), která se na staré farmě spouští o půlnoci, tak aby vám to certifikáty zase po pár hodinách samo nezkazilo, jako mě :-)

Ověřil jsem, že přepnutí trvalo cca minutu a od toho okamžiku to zase fungovalo, takže vyhrožování, že aktualizace certifikátu v Azure se může protáhnout se nenaplnilo. Samozřejmě kdo ví, jestli to tak je vždycky. Zbytek funkčnosti je samozřejmě vhodné ověřit pomocí Microsoft Remote Connectivity Analyzer. A fičíme.

leden 14
Mimo téma - skutečné ochutnávání vína v restauraci

Kamarád mi včera vyprávěl o svých zážitcích s ochutnávkou vína za několik set až tisíc v jakési hogofogo restauraci. A vzhledem k tomu, že s tím mám stejný zkušenosti a stejný traumata, tak tu je něco o tom, jak by to mělo vypadat ve slušném podniku:

...

Dokážu si představit, jak to vypadá, zažívám to stejně - ty si vybereš sám víno přičemž o tom víš prd a chyba tě bude stát majlant a začneš se rovnou bát že to budeš muset ochutnávat a budeš za kreténa, že to držíš jak debil a neumíš k tomu čuchnout. A vono se to přesně tak stane, páč číšník dojde s TVOJÍ lahví a otevře ti ji a nechá tě to nejprve ochutnat a ještě se tě jako zeptá, jestli je to ok pane. Jenže každýmu je jasný, že kdybys řekl, že to ok není, tak bys pak dostal do jídla hovno a do polívky chrchel.

Takže nasrat. Takhle to dělají jenom šmejdi. A ještě se baví, jak seš za hlupáka. Proto tuhle hru rovnou odmítám, protože takhle se to ochutnávání nehraje.

Takovýhle "ochutnávání" nemá vůbec žádnej smysl a je to určený jenom k tomu, aby si pingl mohl ustavit jakejsi nadřazenej postoj nad chudáka hosta. Protože von přece dělá v takovým hogofogo podniku a vypracoval se tím, že si umí zapamatovat větší objednávku než tři piva.

Skutečný ochutnávání ve slušným podniku vypadá nějak takto

Objednáte si jídlo u jednoho číšníka bez pití a za chviličku se za vámi zastaví "vinař", kterej se vás zeptá, co by ste si dali, případně vám nabídne, že rád něco doporučí. Vy řeknete buď přesně co chcete podle vinýho lístku, nebo si necháte nabídnout. Vinař buď odběhne do chlaďáku, nebo přijel už rovnou s chladícím vozíčkem, kde má SVOJE OTEVŘENÝ vzorky. Pokud váš výběr zrovna není otevřenej, otevře SI novou lahev.

Pokud máte zájem, nechá vás ochutnat jeden, nebo dva, nebo víc vzorků a vy se rozhodnete, co vám dneska nejvíc vyhovuje. Nabízí vám SVOJE otevřený, ty skutečný drahý vína, samozřejmě na ochutnání jen kapičky. Protože ten podnik není sockárna a vědí, že tu ochutnávací láhev mají stejně stokrát zaplacenou.

Tady jsou hlášky jako "vyhovuje pane", nebo "co takhle něco sladšího", nebo "případně máme ještě..." naprosto na místě. Ochutnáte a vyberete si. Odmítnete cokoliv. Nikdo na vás nečumí v napjatým očekávání jestli se zakuckáte. Protože se s tím počítá a do ničeho vás to nenutí, protože lahev je tak i tak otevřená. "Vinař" se vás taky zeptá, jestli máte v plánu posedět déle, nebo si toho dáte méně. Pokud řeknete, že vám určitě bude stačit jedna lahev a pomažete do hajan, tak vám třeba i doporučí něco sladšího, protože ví, že to líp chutná a při malým množství to nekazí chuť.

Jak si vyberete, odběhne do sklepa nebo chlaďáku a dovalí VAŠI ZAVŘENOU láhev, kterou před vámi otevře, vočuchá špunt, jestli v tom náhodou nezdechla krysa a rozleje vám. A už se samozřejmě neptá, jestli "je to v pořádku pane".

A pak se vo vás celej zbytek večera stará z pohledu pití, doporučuje kam případně pokračovat a v pozdních hodinách vás předává podomkovi k naložení na trakař.

Takhle to chodí s ochutnáváním ve skutečných restauracích. Pokud to probíhá tím prvním způsobem, tak mě to uráží a nemám žádnej důvod proč to "ochutnávání" prostě s kyselým ksichtem neodmítnout.

leden 13
Výpočet hash souboru pomocí SHA256, SHA-1 a MD5 v jazyce PowerShell

Už jsem tu jednou psal o tom, jak se v PowerShellu spočítá SHA-1 hash nějakého textu, ale dneska jsem zjistil, že tu nemám skriptík na počítání heše obsahu souboru. Navíc je SHA-1 už poněkud obstarožní. Což je zásadní nedostatek. Takový výpočet se hodí velmi často, na kontrolu například konzistence nějakých instalačních médií. Skript umí vypočítat SHA256, SHA512, SHA384, SHA-1 i MD5.

Tady to je:

function Compute-Hash ([string] $fileName, [string] $type) {

  $bytes = [IO.File]::ReadAllBytes($fileName)
  $provider = '{0}CryptoServiceProvider' -f $type
  $hasher = New-Object System.Security.Cryptography.$provider
  return [BitConverter]::ToString($hasher.ComputeHash($bytes))
}

Compute-Hash c:\public\win10.iso sha256
Compute-Hash c:\public\win10.iso sha1
Compute-Hash c:\public\win10.iso md5
leden 13
Shrnutí situací kde jsou k nalezení plná hesla, heše a kde je to naopak bezpečné

Včera jsem měl WUG v Hradci Králové na téma Co by skutečný hacker udělal vaší Active Directory. Následuje shrnutí případů, kdy se v paměti udržují plno-textová hesla nebo kdy naopak se nepřenáší. Všude možně jsou odkazy na další moje články na tato témata.

Plnotextová hesla v paměti počítač

Zde se myslí buď tam, kde jste ho zadali, nebo nechali uložit, nebo naopak tam, kam jste ho dobrovolně poslali. V podstatě vždycky když heslo někde zadáváte, tak je to podezřelé na jeho následující přítomnost v paměti v plné formě.

  • Ctrl-Alt-Del (článek)
  • RDP (článek)
  • runas
  • IIS HTTP basic authentication (článek, článek)
  • PowerShell PS remoting basic a CredSSP authentication
  • uložená hesla služeb (článek)
  • uložená hesla naplánovaných úloh (článek)
  • uložená hesla IIS apppool (článek)
  • různí agenti typu SCCM, SCOM, antivirové instalace, zálohování
  • PSEXEC pakliže zadáváte heslo v příkazové řádce (článek)

NTLM hash v paměti

NTLM hash v paměti je buď vždycky když je tam plnotextové heslo, nebo se z něho dá vždycky vypočítat, takže uveďme jen případ, kdy tam není heslo a přitom je tam ta NTLM hash.

  • přihlášení čipovou kartou (smart-card logon), neboli Kerberos PKINIT

V tomto případě je vhodné omezit útoky pass-the-hash tak, že úplně vypneme NTLM ověřování a převedeme Kerberos plně na AES šifrování, protože v takovém případě se nedá použít NTLM hash na generování Kerberos tiketů. Také je vhodné Kerberos tikety zkrátit na kratší platnost, než výchozích 10 hodin. Při použití čipových karet máte také pravidelně měnit heslo účtů, které ho nepotřebují znát a používají jen kartu. (článek)

Bezpečné komunikace, které heslo nepřenáší v plné formě

  • jakékoliv NTLM nebo Kerberos síťové ověření
  • Schannel TLS client certificate authentication (článek, článek, článek)
  • správa počítače přes MMC a podobné konzole
  • PowerShell PS remoting při Kerberos nebo NTLM ověření (článek, článek)
  • SCCM remote tools
  • Remote Assistance
  • RDP Restricted Admin (mstsc /restrictedAdmin) (článek, článek, článek)

I když se heslo nepřenáší, uvědomte si, že aplikační servery, jako je RDP, nebo IIS, nebo SQL může po vašem přístupu a pod vaším účtem spouštět kdoví jaký kód, aniž byste si toho všimnuli. Pokud se tam připojujete "bezpečně" přes Kerberos nebo NTLM, tak se takový kód nemůže dostat sám dál do sítě (pokud není povolena delegace, samozřejmě), ale i tak může pořád napáchat různé škody přímo na vzdáleném počítači.

leden 08
Ne každá fotka v Active Directory je fotkou

A není všechno kontakt, co se tak tváří :-) Mě totálně nepochopitelně. Nové ADFS 3.0 na Windows 2012 R2 si ukládá určité konfigurační údaje do Active Directory, do kontejneru CN=ADFS,CN=Microsoft,CN=Program Data,DC=x. Ukládá si to tam ve formě kontaktů (contact). Jako kdyby nemohli prostě rozšířit schéma o nějaký nový druh objektu a vlastní atributy.

Takže potom v těch contact objektech se používají atributy jako l, givenName a thumbnailPhoto. Prostě hnůj.

Co je nejzajímavější je atribut thumbnailPhoto. Normálně je to bajtová hodnota (octet string) obsahující fotku.

V případě AD FS 3.0 je to jenom přesně 32 byte a obsahuje to AES 256bit šifrovací klíč, kterým jsou zašifrovány privátní klíče (private key) self-signed certifikátů pro token-signing a token-encryption/token-decryption. Tyto certifikáty (tedy jenom pokud se jedná o self-signed certifikáty, které si generuje ADFS samo) i s privátními klíči jsou totiž uloženy v SQL databázi ADFS.

Je jedno, jestli se jedná o centrální SQL Server, nebo jenom WID (Windows Internal Database). AD FS si self-signed certifikáty ukládá přímo v databázi, takže nejsou vidět v normálním úložišti certifikátů. Má tam i soukromé klíče. Aby se ty soukromé klíče jen tak nepovalovaly v databázovém souboru na disku, jsou zašifrované symetrickým AES256 klíčem.

Předpokládá se, že máte farmu několika ADFS serverů. Všechny musí být schopny privátní klíče z databáze dostat. Databáze je buď jenom jedna v plnohodnotném SQL serveru, ale případě, že máte WID databázi, tak ta je na každém AD FS serveru samostatná a sekundární AD FS servery si stahují její "repliku" přes nezašifrované HTTP SOAP z primárního ADFS serveru (URL jako například toto http://primaryadfs.gopas.virtual/adfs/services/policystoretransfer.

Takže se to dělá tak, že ten AES klíč je uložen v AD, kde ho může číst jenom servisní účet té dané ADFS farmy (a samozřejmě členové skupiny Domain Admins).

Z bezpečnostního hlediska to není velká tragédie, i když celá bezpečnost tohoto klíče stojí pouze na AD LDAP oprávněních (permissions) a klíče se replikují i do RODC například. To ale moc nevadí, protože ten AES klíč sám o sobě není na nic. Citlivé jsou až jím zašifrované privátní klíče pro token-signing certifikát a k těm byste museli mít fyzický přístup na databázový server.

leden 07
Název souboru podle data a času v BAT a CMD příkazové řádce

Rovnou dneska ještě jedna libůstka nad to spouštění PowerShellu přes BAT (viz. tady a tady). Někdy byste chtěli v batch souboru vygenerovat unikátní jméno souboru pro logy, nebo nějaké dočasné soubory. Ideálně se použije datum a čas, případně náhodné číslo. Takto

Datum a čas do proměnné v příkazové řádce

Všude se uvádí, že se dá použít dynamické proměnné %DATE% a %TIME% ale jejich formát závisí na regionálním nastavení (locale). Takže to není moc spolehlivé, jak jsem si vždycky myslel a dneska kvůli tomu musel plno věcí předělávat. Dá se použít například starší metoda přes WMI a jeho příkazová utilita WMIC s tabulkou (třída, class) Win32_LocalTime. Akorát je to dost zdlouhavé psaní. Na druhé straně to nevyžaduje PowerShell.

FOR /F "skip=2 tokens=2-7 delims=," %%i IN ('WMIC Path Win32_LocalTime GET Year^,Month^,Day^,Hour^,Minute^,Second /Format:CSV') DO (

  REM The leading zeros pad the numbers from the left
  SET day=0%%i
  SET hour=0%%j
  SET minute=0%%k
  SET month=0%%l
  SET second=0%%m
  SET year=%%n
)

REM Using the special notation in order to take only the last two digits from the padded values
SET datetime=%year%-%month:~-2%-%day:~-2%T%hour:~-2%-%minute:~-2%-%second:~-2%

ECHO DateTime sortable from WMIC: %datetime%

Jenže dneska máte PowerShell nejspíš úplně všude. A stejně ten BAT/CMD používáte jenom na startování nějakého jiného, obsažnějšího PowerShell scriptu. Tak proč to rovnou nevyužít?

REM Must specify the "usebackq" switch in order to be able to use single-quotes inside the powershell command
REM ExecutionPolicy parameter is not necessary here, because the execution policy does not affect -Command argument
FOR /F "usebackq tokens=1 delims= " %%i IN (`powershell -Command "(get-date).ToString('s').Replace(':','-')"`) DO (SET datetime=%%i)
ECHO DateTime sortable PowerShell: %datetime%

Pokud byste chtěli náhodné číslo do proměnné, tak třeba takto:

FOR /F "usebackq tokens=1 delims= " %%i IN (`powershell -Command "'{0:X8}' -f (Get-Random -Maximum 4GB -Minimum 0)"`) DO (SET random=%%i)
ECHO Random number on 8 hex digits: %random%

A pokud byste chtěli rovnou unikátní dočasný soubor v TEMPu, tak třeba takto:

FOR /F "usebackq tokens=1 delims= " %%i IN (`powershell -Command "[IO.Path]::GetTempFileName()"`) DO (SET tempfile=%%i)
ECHO Unique TEMP file name: %tempfile%

 

1 - 14Next
>
 

 Rychlovky lepší než tvítr

 
31.1.2016 9:53
jeden z mých posledních článků vyšel i na technetu: http://blogs.technet.com/b/technetczsk/archive/2016/01/28/bezpecnostni-auditovani-ve-windows-prihlasovaci-udalosti.aspx
26.1.2016 16:19
právě jsem objevil hack jako prase. z toho bude Security Bulletin. Nechte se překvapit!
14.1.2016 10:17
Office365 neboli Azure nedovoluje mezeru v hesle
12.1.2016 23:09
Novy kfc hogofogo grander - malo masa, tuha houska, a moc palivosti aby byl dojem najezeni
21.12.2015 18:35
Top kniha 2 - Zdenek Svarak...
21.12.2015 18:35
Top kniha v nabidce - Denicek bulimicky. ?? Bliju. Zase bliju. Dneska jenom bliju.
15.12.2015 15:40
hmmm, právě mi dorazil mail s nabídkou členství v "international association or professional women". Tak to beru! :-)
10.12.2015 23:23
Tri dny zpatky jsem se dival na vrchni prchni. A dneska jsem se v Kolkovne pral borce v bile kosili na jidlo a von to nebyl cisnik :-)
9.12.2015 11:18
Altair přišel s výhodnou nabídkou napsat pro IIS automatizaci certifikátů zadarmo z LetsEncrypt.org. Tak tomu se nedá odolat :-) Jdeme na to!
2.12.2015 8:16
indove - jsou uplne ztraceni, ale presto nadseni a zacinaji se ucit C# a PowerShell. Tady u nas by clovek na jejich mentalni urovni delal kopace a byl by spokojeny, ale oni jdou do toho!
27.11.2015 9:01
26.11.2015 18:36
veeeelmi dobre buchty na WUG Bratislava
21.11.2015 16:10
budu mít 4 free přednášky v příštích 3 týdnech - https://www.sevecek.com/Lists/Calendar/calendar.aspx
20.11.2015 8:19
tak jsem se rozsiril uz i na facebook: https://www.facebook.com/ondrej.sevecek.official
20.11.2015 8:19
vcera vysel Windows Server 2016 TP 4!
11.11.2015 8:51
paranoik :-) http://www.jenpromuze.cz/video/22081-tenhle-chlapik-ma-opravdu-epicke-heslo-na-svuj-telefon
11.11.2015 7:20
no konecne pridali do meho oblibeneho WinHEXu schopnost interpretovat VHD
9.11.2015 18:44
Nemuzu si pomoct, ale mekDonda ma ted uplne navykovej Maestro burgr a statkarske hranolky.
9.11.2015 12:53
expirace operacniho systemu? BSOD 0xC0000605: A component of the operating system has expired :-(
25.10.2015 7:43
Igam Ogam nejnesnesitelnejsi pohadka na svete
10.10.2015 10:34
Tak to je terno. AVG antivirus dela uz i zrychlovani PC a zarucene optimalizuje registry i pamet. Poslete mi 50 kopii, prosim!
8.10.2015 17:03
https://www.youtube.com/watch?v=mpg5CnagE9k
6.10.2015 18:16
Jeste jednou televize. 18-24 minuta: http://www.ceskatelevize.cz/porady/10659215431-online/315281381881003/
30.9.2015 13:04
sevecek plka v televizi, minuta 18:00: http://www.ceskatelevize.cz/ivysilani/10101491767-studio-ct24/215411058320929
18.9.2015 8:30
"...že peníze potřebuje hned a poslala odkaz na web, kde jsou převody nejrychlejší": http://finance.idnes.cz/nova-forma-phishingu-0r7-/viteze.aspx?c=A150917_064006_viteze_sov