Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > default
leden 23
Blesk peněženka

Nudím se v nemocnici, tak jsem si koupil v trafice Blesk peněženku a zkoumám to (web mají na www.bleskpenezenka.cz). Jedná se o platební kartu, kterou si koupíte za 150,- Kč v trafice. Dostanete MasterCard, normálně s číslem a CVV vzadu, platí mi do 10/17. Zdá se že je i bezkontaktní (idioti). Potom už to jenom dobíjíte přes Sazka terminály, přes internet z jiné platební karty (který musí mít 3D Secure), nebo převodem z účtu.

Na co to je? Někdo díky tomu může mít totálně anonymní platby, jako třeba když se rozvádíte a potřebujete vypadat jako socka. To já nepotřebuju. Jde mi o to, abych nemusel všude zadávat svoji kreditku. Minule mi z ní někdo vyndal 110 000,- na letenku do Peru :-) Prostě teda něco jako paypal.

Mají webový portál, kam se přihlásíte a vidíte platby do karty a kartou.

Podstatná omezení:

  • horní limit na jedno dobití přes internet je 1500,-
  • horní limit na jedno dobití obecně je 10 000,- (takže asi přes Sazku a převodem) za den, to musím ještě vyzkoušet
  • převod z banky se přičte až za 3 dny
  • jednotlivá platba může být max 10 000,- Kč
  • zdá se, že i maximální zůstatek na kartě je jenom 10 000,- Kč
  • dá se to údajně zvýšit až na 50 000,- ale musíte telefonem nahlásit, jak se jmenujete. I když teď se zrovna dívám na webu na limity a je tam rovnou 50 000,-. Tak uvidíme.
  • placení je zadarmo, ale dobití (a to i převodem z banky) je za 25,- což znamená, že dobíjet to z karty přes internet je drahé

Zážitky:

  • v pohodě jsem zaplatil na americkém webu 50 USD při zadání čísla a CVV bez nutnosti potvrdit to SMSkou
  • klesly mi peníze pod 300,- a přišla mi zadarmo SMS o tom, že tam mám málo peněz
  • myslel jsem, že ta karta má taky sama 3D Secure, ale zaplatil jsem právě na českém webu, kde to normálně moje kreditní karta vyžaduje, ale tahle to nechtěla
  • historii obou plateb vidím okamžitě na webu, pěkné
  • do jejich webu se přihlašujete jenom heslem, ale nedá se od tam nic odeslat, takže jenom přehled plateb. pěkné.

Tak uvidíme, jak se to bude dále vyvíjet. V podstatě bych to viděl jako dobrou kartu na neznámé weby, kde se zadávají údaje do toho webu a ne do nějakého rozumného platebního portálu.

leden 20
Jak vytvořit ručně shadow copy (stínovou kopii svazku)

Když vám nejede zálohování, nebo prostě jen tak kvůli kdoví čemu :-) není špatné si vytvořit ručně shadow copy (stínovou kopii svazku) nějakého diskového oddílu. Potřebujete k tomu jenom nástroj diskshadow a případně PowerShell a příkazovou řádku, pokud nemáte diskshadow na stanicích.

Když už to píšu u sebe na bezpečnostním blogu, tak upozorňuju, že shadow copy máte nejspíš na všech stanicích, kde je ve výchozím stavu zapnuta funkce system restore, neboli system protection. Operační systém vám sám od sebe dělá shadow copy před každou instalací programů i aktualizací. Dá se to potom použít k průzkumu různě napadených počítačů, protože útočníci si obvykle neuvědomují a i když smažou nějaké staré soubory, nebo logy, možná je ještě najdete v nějaké shadow copy.

Jak vylistovat všechny kopie svazku

Můžete to udělat buď pomocí diskshadow, nebo pomocí PowerShell:

diskshadow
  list shadows all


gwmi Win32_ShadowCopy | 
  select *,
         @{ n = 'DriveLetter' ; e = { (gwmi -Query ('SELECT * FROM Win32_Volume WHERE DeviceId = "{0}"' -f $_.VolumeName.Replace('\', '\\'))).DriveLetter } }

gwmi Win32_ShadowStorage | 
  select *, 
         @{ n = 'DriveLetter' ; e = { ([wmi] $_.Volume).DriveLetter } },
         @{ n = 'DiffVolumeLetter' ; e = { ([wmi] $_.DiffVolume).DriveLetter } }

V tabulce Win32_ShadowCopy je seznam všech kopií, které jsou k dispozici na všech vašich oddílech. V tabulce Win32_ShadowStorage jsou konfigurace úložišť shadow copy rozdílových kopií pro každý oddíl, který to má vůbec nějak definováno - tedy na který disk se to ukládá (obvykle na ten stejný oddíl do složky System Volume Information) a maximální omezení na velikost, pokud nějaké existuje.

Jak si stínovou kopii svazku vytvořit

Opět ji vytvoříte buď pomocí diskshadow, nebo přes WMI a PowerShell:

diskshadow
  set context persistent
  begin backup
  add volume c:
  end backup


([wmiclass] 'Win32_ShadowCopy').Create('C:\', 'ClientAccessible')

A to hlavní, jak se k ní vůbec dostat?

Je úplně jedno, jestli je client accessible, nebo není. Jestli je to produkt shadow copies for shared folders, nebo je to výsledek system protection (system restore). Pokud znáte její device object ID (deviceObjectId), tedy něco ve formátu \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy38, tak se k jejímu obsahu dostanete.

Můžete zkusit několik cest:

diskshadow
  list shadows all
  expose {guidguid-guid-guid-guid-guidguidguid} R:\


mklink /D c:\mojekopie "\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy38\"

U té druhé metody s mkdir a directory junction (parameter /J), nebo symbolic link (parametr /D), nesmíte zapomenout na konci na zpětné lomítko (backslash). Pokud to tam nedáte, sice se to namapuje, ale dostanete při přístupu chybovou hlášku "is not accessible, the parameter is incorrect".

Mazání shadow copy na závěr

Samozřejmě jdou smazat přes diskpart, nebo také přes WMI, kde použijete metodu .Delete().

leden 20
Kombilace C# vloženého uvnitř PowerShell a změna dočasného adresáře

Jenom zajímavůstka pro PowerShellisty. Do skriptu v PowerShell jde vložit (ne)přímo kus kódu v jazyce C# (csharp, c-sharp, cs). PowerShell ho potom umí spustit. Používá se to například, pokud chcete využívat PInvoke metodu na volání Win32 API, což jinak přímo z PowerShell nejde. Já to mám například ve svém keyloggeru, a zrovna se tím chystám přidat nějakou funkcionalitu do forensní analýzy.

Právě kvůli tomu volatile forensics scriptu jsem ale zkoumal, jak to dělá.

Kompilace pomocí Add-Type a temp adresáře

Kód napsaný v jazyce C# se do PowerShellu vloží pomocí herestring. Příklad následuje. Je to prostě jen jednoduchá třídička (class) s konstantou a její okamžité použití:

$cs = @'

namespace Sevecek.PowerShell { 

  public class Constants { 
     
    public const int OneValue = 5;
  }
}

'@

Add-Type -TypeDefinition $cs

[Sevecek.PowerShell.Constants]::OneValue

Jenže ten C# se musí zkompilovat. Kompiluje se pomocí cs.exe kompilátoru, který máte vždycky nainstalovaný spolu s .NET framework. PowerShell potřebuje .NET framework, takže tam ten kompilátor je úplně vždycky.

Použil jsem process monitor (procmon) k tomu, abych zjistil, kam to zapisuje. Jakmile zavoláte Add-Type, celý obsah toho herestring se vyextrahuje a uloží do soubouru v tempu - konkrétně v té cestě, která je v proměnné %tmp%, neboli pro PowerShell tedy $env:tmp. Existuje ještě jedna úplně stejná proměnná %temp%, tedy $env:temp, ale ta se v tomto okamžiku nepoužije. PowerShell to ukládá opravdu do dočasného adresáře, který je v proměnné $env:tmp. Vyzkoušeno pro všechny verze PowerShellu 2, 3 i 4.

Vytvoří to tam několik souborů, kód je v souboru .cs a příkazová řádka pro cs.exe kompilátor je v souboru .cmdline. Příkazové řádky pro C# compiller jsou zde:

# PowerShell version 2 CS/C# compiller command line
# used by Add-Type -TypeDefinition.
# The temporary files goe into the path specified by 
# the $env:TMP (%TMP%) environment variable:
#
# /t:library /utf8output /R:"System.dll" /R:"C:\Windows\assembly\GAC_MSIL\System.Management.Automation\1.0.0.0__31bf3856ad364e35\System.Management.Automation.dll" /out:"qbrwvho.dll" /D:DEBUG /debug+ /optimize- /warnaserror  "qbrwvho.0.cs"

# PowerShell version 4 CS/C# compiller command line
# used by Add-Type -TypeDefinition
# The temporary files goe into the path specified by 
# the $env:TMP (%TMP%) environment variable:
#
# /t:library /utf8output /R:"System.dll" /R:"C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Management.Automation\v4.0_3.0.0.0__31bf3856ad364e35\System.Management.Automation.dll" /R:"System.Core.dll" /out:"sxbfvua.dll" /D:DEBUG /debug+ /optimize- /warnaserror  "sxbfvua.0.cs"

Změna dočasného adresáře pro kompilaci

Za normálních okolností asi nebudete chtít měnit adresář, do kterého se budou dočasné kompilační soubory ukládat. Jde to do dočasného adresáře tmp, u kterého se očekává, že prostě plní tuto funkci. V mém případě to ale není dobře, protože potřebuji kompilaci provádět do vyhrazeného adresáře ve svém forensním balíčku, abych minimalizoval zanášení změn do zkoumaného systému.

Jak tedy změníte dočasný adresář pro kompilace vloženého C# kódu? Jednoduše. Stačí nastavit jinou cestu do proměnné $evn:tmp.

$env:tmp = 'C:\MyTempCompilationTarget'

 

leden 19
Process memory dump a historie příkazů cmd a PowerShell

Dneska jsem narazil na zajímavý problém. Udělal jsem si memory dump příkazových řádek z procesů cmd a powershell pomocí programu procdump (ofiko program od Microsoftu ke stažení zde). Jak jistě pravidelně sami používáte, tyto programy si pamatují historii (command history) příkazů, které jste zadávali. Můžete se na ně vracet buď pomocí šipek nahoru a dolů, nebo si je dokonce zobrazit přes klávesu F7.

Používám procdump ve svém forensním nástroji na sběr informací z počítačů, pokud je podezření na nějaký incident. No a co když tam někdo nechal běžet příkazovou řádku, nebo právě PowerShell. Nepůjde z toho memory dumpu vyndat seznam těch použitých příkazů?

Nečekal jsem, že by to bylo nějak blízko u sebe, nebo přehledně, ale ono to v těch procesech nebylo vůbec. Přitom ještě nedávno jsem to tam našel. Jak to?

Stačilo si uvědomit, že dneska jak cmd, tak i PowerShell, spouští ještě další proces conhost.exe na to, aby hovořili s uživatelem. Moc nerozumím proč, ale dělá to už od Windows 7. Ale to není ani podstatné. Důležité je to, že historie příkazů je v tom conhost procesu, a nikoliv v cmd.exe, nebo v powershell.exe.

Takže stačí použít další utilitku strings, tedy něco jako

procdump -ma -o <conhostPID> conhost.dmp
strings conhost.dmp > conhost.txt

A ty příkazy už v tom najdete. Samozřejmě nejsou tam moc pěkně pohromadě, ale na to, abyste zjistili, nebo si potvrdili, co tam kdo zadával, to úplně stačí.

leden 09
Pentest - Ukázkový kód modifikace obsahu webového požadavku pro Fiddler

Právě pracuju na jednom penetračním testování webové aplikace a zase jako vždycky, když se k něčemu vracím po pár měsících, tak si už nic nepamatuju, a všechno hledám. Tak tohle berte jenom jako můj vlastní semplík, abych to příště měl po ruce.

Jedná se o ukázku kódu do Fiddler pravidla (rule), který modifikuje jméno souboru uploadovaného z formuláře, který používá enctype="multipart/form-data". Navíc to obarví tu položku na červeno a ztlustí ji (bold). Na zbytek už máte Fiddler ScriptEditor, a jeho inteli sense, ale s něčím musím vždycky začít.

if (oSession.HostnameIs("test.gopas.cz") && oSession.uriContains("/default.aspx") && oSession.HTTPMethodIs("POST")) {

  oSession["ui-color"] = "red";
  var oBody = System.Text.Encoding.UTF8.GetString(oSession.RequestBody);
           
  if (oBody.Contains("Content-Disposition: form-data; name=\"fileUpload\";")) {
       
    oSession["ui-bold"] = "true";
    oBody = System.Text.RegularExpressions.Regex.Replace(oBody, "(Content-Disposition: form-data; name=\"fileUpload\"; filename=\")(.+?)(\")", "$1test.pdf$3");
    oSession.utilSetRequestBody(oBody);
  }
}

 

Tak dobrou. Mimochodem, tenhle pentest opět ukázal, že mnozí vývojáři webových aplikací o bezpečnosti ještě neslyšeli. A to i když dodávají aplikaci pro banku.

leden 08
Odpověď - jak zablokovat přístup na internet některým uživatelům, nebo počítačům

Dneska ještě jedna odpověď - jak zablokovat přístup na internet z nějakých počítačů, centrálně přes GPO (Group Policy Object)?

Odpověď

Nejspíš docela jednoduše pomocí Windows Firewall. Windows Firewall se dá nastavit přes Group Policy. V editoru je to v části:

Computer configuration
  Policies
    Windows settings
      Security settings
        Windows firewal with advanced security

Česky to je tady:

Konfiugrace počítače
  zásady
    nastavení systému Windows
      nastavení zabezpečení
        brána Windows Firewall s pokročilým zabezpečením

Umí udělat blokovací Outbound pravidlo. Tam si zadáte třeba rozsah IP adres. Pokud bych měl třeba vnitřní síť 192.168.1.x, tak bych tam dal dva blokované rozsahy 0.0.0.0-192.168.0.255 a druhý nad tím privátním 192.168.2.0-223.255.255.255.

Nesmíte to přehnat moc nahoru, musíte skončit na 223. Protože nad tím je multicast, který potřebujete i ve vnitřní síti - možná. Jediná věc je, že tohle se nastavuje per počítač - tedy přes GPO, ale je to v počítačové části toho Group Policy Object.

To znamená, že se to bude vstahovat na konkrétní počítače a nikoliv na nějaké konkrétní uživatele. Pokud lidi mají svůj počítač, tak to je ok. Pokud se ale nějaký uživatel přesouvá, tak toho nedosáhnete.

Ještě odkazy na předchozí článečky o Windows Firewall - problémy s jeho GPO pravidly, pokud se používají výchozí předdefinovaná a obecně o jeho smysluplnosti.

leden 08
Odpověď - jak je to s virtuálními čipovými kartami na Windows 7

Právě dorazil zajímavý dotaz a vzhledem k tomu, že to může mít složitější vysvětlení, dávám to rovnou sem:

Dotaz

Obdržel jsem zajímavý dotaz a protože nevím odpověď, obracím se na největšího mně známého odborníka. Zákazník by rád využil virtuální smart karty, ale nechce přejít na Win8, rád by zůstal u Win7. V těch nativně tahle funkcionalita není, ale možná existují nějaká řešení třetích stran se stejnou funkcionalitou. Věděl bys o něčem respektive doporučil bys nějaké řešení pro tenhle scénář?

Moje odpověď

Nejprve rychle - ne, nevím o ničem pro Windows 7. Microsoft měl nějakou interní utilitku na simulaci čipové karty do souboru na testování Base Smart Card Crypto Provideru, tu jsem nějak "pokoutně" dostal, ale je to opravdu jen testovací a ne úplně to funguje. Navíc to ukládá klíče do souboru, což není bezpečné vůbec.

O jiném software nevím, podle mě to nikdo nestačil ani vyvinout, než vyšly Windows 8. Nehledě na to, že na to není trh, aby to někdo vyvíjel.

Ale lepší odpověď, možná z ní vyplyne, že to není ani tak moc výhodné a není na škodu si prostě koupit za 1000,- CZK karty fyzické, které dávají mnohem více muziky (porovnejte s cenou počítače). Kolik by asi takový software stál v porovnání s jednou kartou?

Úvod do virtuálních čipových karet

Ano, od Windows 8 je za pomoci TPM čipu na motherboard (základní desce) počítače k dispozici funkce zvaná virtual smart card. Znamená to, že si člověk může ukládat privátní klíče k certifikátům, v principu, do základní desky a nemusí být na disku počítače.

Windows umožňují teď tedy ukládat privátní klíče na třech místech:

  • na disku v profilu - normálně jsou totiž jednoduše v souborech, v profilu uživatele. Je to cesta %AppData%\Microsoft\Crypto\RSA v případě CSP poskytovatele, nebo v %AppData%\Microsoft\Crypto\Keys v případě CNG poskytovatele. Chráněno je to zde přihlašovacím heslem uživatele. Chráněno znamená zašifrováno. Pomocí DPAPI atd. Bez znalosti hesla uživatele to tedy nikdo nedostane.
  • do TPM module na základní desce. Tady to může být dále chráněno TPM PINem. Jedná se o uložení do samostatného hardware, mimo operační systém počítače.
  • do separátní fyzické čipové karty (smart card), kterou připojíte přes USB reader, nebo ve formě přímo USB tokenu.

Výhody hardware úložiště

Psal jsem o tom například zde. Nejen že to ukládá privátní klíče mimo operační systém, ale ty privátní klíče nejdou ani exportovat. Veškeré kryptografické operace provádí nikoliv Windows operační systém, ale přímo čip na čipové kartě, nebo právě TPM čip.

Tím pádem, když si uživatel stáhne do počítače nějaký exploit, tak mu to ty privátní klíče nemůže přímo ukrást z disku.

Rozdíly čipové karty a TPM virtual smart card

No v podstatě je to stejné, krom několika omezení, která TPMko má. Ano, můžete se obojím přihlašovat do Windows (pomocí Kerberos PKINIT) a samozřejmě na VPN a DirectAccess a RDP apod.

Výhody TPM:

  • oproti tokenu, nebo čipové kartě to nemusíte tahat sebou
  • nemusíte si to separátně koupit za pár korun, zatímco můžete zaplatit hodně peněz za corporate grade notebook, který má TPM :-)

Nevýhody TPM virtuální čipové karty:

  • nelze to vytáhnout, takže se na to neuplatňuje automatické zamykání počítače při vytažení
  • nemůžete v tom mít RFID anténu, takže si s tím dveře neotevřete
  • mezi více počítači je to nepřenosné - mnohdy potřebujete mít svoje přihlašovací údaje na kartě, abyste se mohli hlásit na víc strojích
  • zadáváte jen kraťoučký PIN, stejně jako u čipové karty - jenže když to kolega odpozoruje (právě, protože je tak krátký) - přijde k vašemu počítači a přihlásí se stejně
    • používat dlouhý PIN pomalu postrádá krásu čipových karet - to už můžete mít skoro heslo, ne?
  • není to multifactor autentizace, protože vám stačí pamatovat si PIN. Neznamená to, že musíte něco mít. Sice ano, musíte mít svůj počítač, ale ten musíte mít i s čipovou kartou, že?

Závěrem

Je to pěkné, pokud máte na počítači TPM a máte Windows 8 a nechce se vám kupovat kartu, tak pojďme do toho, je to pohodlné vylepšení bezpečnosti. Super.

Ale pokud už řešíte PKI a chcete opravdovou bezpečnost, potřebujete čipové karty (smart card). 

leden 06
Povolení Kerberos delegace (double hop) pro PowerShell remoting

V poslední době se člověkům dost zvyšuje používání PowerShell příkazové řádky na správu více serverů. Speciálně s Hyper-V cluster a podobně. A člověk rád používá remoting, tedy Invoke-Command a podobně. A začíná bojovat s problémem přístupu na ještě vzdálenější servery - tedy double hop (neboli delegation).

Už jsem tu před nějakou dobou psal o tom, jak (ne)povolovat delegaci pro PowerShell remoting a jeho příkazy jako je Invoke-Command nebo Enter-PSSession. Článek byl o tom, že musíte použít pouze volbu Trust this computer for delegation to any service. Teď jsem to vyzkoušel na Windows 2012 a jede to i s druhou volbou Trust this computer for delegation to specified services only with Any authentication protocol.

Ani jedna volba není ideální, ale podívejme se tedy na obě možnosti pořádně.

PowerShell remoting a problém s double-hop (neboli delegation)

Scénář je tento Client8 ---> Srv2k12r2 ---> Data1. Na klientovi máte puštěný PowerShell. Na prostředním serveru Srv2k12r2 chcete spouštět příkazy. Spouštíte nějaký příkaz pomocí Invoke-Command, nebo třeba Enter-PSSession.

K tomu musíte být samozřejmě členem skupiny Administrators na tom vzdáleném počítači, bez toho byste se tam ani nedostali (tohle povolit by bylo ještě stokrát složitější). To je ok.

Jenže ten příkaz, který poběží na vzdáleném počítači chce jít ještě na nějaký další počítač. Děláte tedy tak zvaný double-hop, neboli delegation (Kerberos delegation).

Pokud to nemáte nějak povoleno, tak Invoke-Command neuspěje stejně, jako v prvním případě na obrázku. Tedy chyba jako:

Access is denied (error 0x5, 0xC0000005)
Permission denied, UnauthorizedAccessException, Anonymous logon

To stejné byste zažili, kdybyste dělali kompletní Enter-PSSession.

Ve druhém případě se to už povedlo, což by mělo dokumentovat okamžik, kdy už máte tu delegaci (delegation, double hop) povolenu.

Jak povolit delegation a dokázat potom udělat double hop?

Máte v zásadě dvě základní možnosti:

  • použijete CredSSP ověřování. To ale budete muset zadávat login a heslo při připojování a ještě to budete muset povolovat v politice.
  • použijete jednu ze dvou možných Kerberos delegation. Jak už jsem psal dříve, původně fungovala jenom jedna metoda Kerberos delegace, na Windows 2012 už fungují dvě ze tří. Asi to soudruzi vylepšili.
    • funguje - Trust this computer for delegation to any service
    • nefunguje - Trust this computer for delegation to specified services only with Kerberos only
    • funguje od Windows 2012 - Trust this computer for delegation to specified services only with Any authentication protocol

Povolení double hop PowerShell remoting pomocí Trust this computer for delegation to any service

Tahle metoda povolí delegaci úplně kamkoliv. Kdokoliv se dokáže připojit přes WinRM na ten server vzdáleně, se potom dostane už úplně kamkoliv jinam. Současně povolujete také libovolným službám na tom serveru, aby po příchodu nějakého libovolného ověřeného uživatele pokračovaly kamkoliv dále.

To je hrozně nebezpečné. Ale funguje to už od domain functional level 2000. Nastavíte prostě delegaci pro prostřední server takto:

Obrázek: volba Trust this computer for delegation to any service, v češtině Důvěřovat tomuto počítači pro delegování libovolné službě (pouze protokol Kerberos).

Dále musíte ještě přidat ten účet prostředního serveru do skupiny WAAG (Windows Authorization Access Group). Tahle skupina totož umí číst atribut tokenGroupsGlobalAndUniversal. Obvykle to sice není potřeba, protože skupina Authenticated Users je by default členem skupiny Pre-Windows 2000 compatible access, ale pro jistotu tím nic nezkazíte:

A musíte ten prostřední server (v mém případě Srv2k12r2) restartovat! LSASS má různé keše, které je potřeba vyhodit. Nepomůže ani chvilku počkat, ani restartovat jen nějakou službu. Otočte to celé. Samozřejmě možná něco někdy pojede i bez restartu, ale už jsem na tom strávil hodně bezesných nocí.

Na klientovi se musíte odhlásit! Aby se vám vyčistila klientská keš Kerberos tiketů. Opět by mohlo pomoci klist purge, ale není to úplně na jistotu.

Poněkud omezenější a bezpečnější Kerberos delegation za pomoci Trust this computer for delegation to specified services only with Any authentication protocol

Druhá možnost delegace je na jedné straně více omezená. Na druhé straně je tedy také komplikovanější, pokud chcete povolit více double hop služeb na vzdálených serverech. Na třetí straně tím dáváte možnost prostřednímu serveru (a tedy jeho libovolným službám běžícím jako SYSTEM, Network Service, nebo pod virtuální servisní identitou - virtual service identity) dělat si delegaci, aniž by se k nim vůbec musel někdo připojovat. Takže za jistých podmínek dokonce nebezpečnější.

Podle obrázků to povolíte podobně, jenom musíte vyjmenovat seznam služeb, do kterých může prostřední server delegovat:

Obrázek: volba Trust this computer for delegation to specified services only, Any authentication protocol. V češtině Důvěřovat tomuto počítači pro delegování pouze určeným službám - Používající libovolný protokol pro ověření.

Závěr

Ani CredSSP, ani Kerberos delegation není v podstatě jednoduchá na zapnutí a navíc to vyvolává bezpečnostní pochybnosti. Já to nerad používám. Vždycky se to dá obejít nějak jinak.

Jak jsme dneska zjistili, například to koliduje s nastavením delegace pro Hyper-V live migration.

leden 06
Testovací ASP a ASP.NET webové aplikace z přednášek

Když dělám nějaké přednášky, například na TechEdu, HackerFestu, WUGu, na svých kurzech, nebo teď zrovna velice aktuálně na ShowIT v únoru Bratislavě, tak to mnohdy předvádím na IIS webových aplikacích. Mám nějaké napsané v ASP a v ASP.NET. Vzhledem k tomu, že je po nich občas sháňka, jsou všechny ke stažení zde.

Tohle je přetisk startovacího HTML souboru, který používám jako rozcestník:

 

Sample ASP and ASPX applications

Select one of the following sample applications:

Application Description
Classic ASP
username.asp Displays basic information about authenticated and impersonated user under whose identity the application is running
delegation.asp Demonstrates CIFS, SQL and LDAP delegation with various Kerberos delegations and the protocol transition
names-get.asp Demonstrates how the HTTP GET method handles and transports form parameters from a client browser to the server
names-post.asp Shows how the HTTP POST method handles and transports form parameters from a client browser to the server
server-variables.asp Shows what and how IIS server variables are populated for a simple request
ASP.NET
username.aspx Process and impersonated user name, logged-on user account and other appdomain specs
code-impersonation.aspx Impersonate the authenticated user in code. Can run in both the Integrated or Classic pipelines
server-variables.aspx List of all server variables available with actual values
resource-access.aspx Local and remote resource access under the current credentials

Security samples

Select one of the following sample applications:

Application Description
ASP.NET
add-local-admin.aspx Adds specified user into local Administrators group
add-domain-admin-SAM.aspx Adds specified user into domain Domain Admins group over SAM (SMB) interface.
Requires cifs SPN.
add-domain-admin-LDAP.aspx Adds specified user into domain Domain Admins group over LDAP interface.
Requires ldap SPN.
start-process.aspx Starts process under AppPool identity regardless of ASP.NET impersonation
start-process-as-user.aspx Starts process under ASP.NET impersonated identity
start-process-with-output.aspx Starts process under ASP.NET impersonated identity and shows the program output

 

leden 05
Čtení LSA secrets pomocí PowerShell skriptu

Už jsem tu psal o tom, že počítače si ukládají různá hesla v plné formě. Dneska se pověnujme detailněji heslům uloženým ve formě LSA secrets. To je poměrně stará technologie na zašifrované ukládání tajných informací v registrech počítače v klíči:

HKLM\SECURITY\Policy\Secrets

Systém (tedy systémový proces lsass.exe - neboli Local Security Authority sub system) si sem ukládá například hesla služeb (Windows service), pokud běží pod nějakým konkrétním uživatelským účtem. To by bylo v podklíčích začínajících prefixem _SC_. Také se zde ukládá a je k dispozici heslo počítače do domény. To je tady v podklíči $MACHINE.ACC viz. můj starší článeček. Tedy pokud je počítač členem domény. Pokud byl někdy použit autologon (automatic logon), je tam navždycky taky DefaultPassword.

Do toho klíče se normálně nedostanete. Pokud se tam chcete podívat v regeditu, klikněte si pravým tlačítkem a v kontextovém menu Permissions si prostě přidejte oprávnění, například pro skupinu Administrators.

Troška historie

Je zde také lokální master heslo pro DPAPI (klíč DPAPI_SYSTEM) o kterém jsem se mírně zmiňoval v předcházejícím článku. Tady se jedná pouze o lokální DPAPI, což nebylo přímo to, co jsem tam řešil s tím Key Distribution Service. Ale všechno souvisí se vším :-) DPAPI je novější metoda, jak se šifrují tajné informace v registrech, na disku a v databázích a všude možně jinde. A jeho bezpečnost samozřejmě stojí na tomto master key.

Historicky by se to dalo porovna asi takto - LSA secret od jakživa, DPAPI na Windows 2000 a novějších a potom Key Distribution Service (KDS) od Windows 2012.

Dneska o LSA secrets

Pokud si tedy systém pomocí LSA secret ukládá nějakou kritickou informaci, speciálně to heslo do domény, nebo heslo služeb (service password), je to zašifrované v podklíčích toho Secrets klíče. Pojem "zašifrované" znamená, že se to šifruje ještě nějakým jiným systémovým klíčem (syskey). Ten je samozřejmě taky někde v registrech (pokud ho nezadáváte při startu právě přes syskey), takže zase ne žádná super věda.

Jsou tam vždycky ještě dva další podklíče, CurrVal a OldVal a k nim ještě dvě časová razítka v klíči CupdTime, OupdTime repsektive. V CurrVal je aktuální hodnota toho hesla. V OldVal je předchozí hodnota toho tajemství. Časová razítka jsou ve formátu FILETIME a odpovídají jejich změnám. Předchozí hodnoty hesel jsou pro systém velmi důležité. Třeba Kerberos tikety mají nějakou určitou platnost a protože mohou být zašifrovány ještě tím starým heslem, musí být možnost je i nadále dešifrovat. Mimochodem použití starších hesel má zajímavé vlastnosti.

To je samozřejmě zajímavé i pro hackery, kteří se vám chtějí dostat k heslům. Sice asi ne automaticky, ale když se člověk podívá na dvě hesla a vidí, že se tam jenom mění koncovka, už se z toho dá něco zjistit.

V tom předchozím článku o vybírání hesel služeb jsem používal program Cain & Abel, ale to je zbytečné. Hlavně je to "zlý" program a navíc mi prozatím nefunguje na Windows 2012 R2.

Tak jsem si to naprogramoval v PowerShellu. Nejde vůbec, ale vůbec, o žádné hekování. Pokud si ten skript spustíte pod účtem skupiny Administrators, není důvod proč by to bylo něco nelegálního. Ono je tam totiž úplně normální Win32 API v knihovně ADVAPI32.DLL, normálně zdokumentované, na čtení těch hodnot z registrů.

Používají se Win32 funkce jako LsaOpenPolicy a LsaRetrievePrivateData. Byla to jen pekelná dřina rozchodit všechny ty definice pinvoke. Hlavně jsem chtěl dokázat, že to jde přes PowerShell. Takže opět žádný antivirus ani nemrkne jak jsem se snažil ukázat už na konferenci HackerFest.

Je to strašné množství kódu, takže jsem to neupravoval pro samotné zveřejnění. Je to prostě součást mých knihoven ADLAB (lib-common, lib-modifyActions a lib-utils). Pokud by to někdo chtěl vyzkoušet, tak samozřejmě může následovně. Stačí stáhnout ty tři soubory. Pokud si nestáhnete lib-modifyactions.ps1, tak budete mít jistotu, že vám to na systému nic nezmění. Veškeré měnící funkce jsou právě umístěné pouze v tom lib-modifyActions.ps1, abyste si je nemuseli stahovat pro jistotu.

Jenže bez jisté modifikace registrů z toho nepřečtete hesla služeb. Přečtete heslo počítače do domény, to ano ($machine.acc). A DefaultPassword taky. Prozatím se mi nepodařilo zjistit jak to udělat, abych nemusel ručně duplikovat tu registrovou hodnotu. Ony totiž LSA secrets, které začínají _SC_ jsou tak zvané machine secret, které může údajně číst pouze "operating system". Netuším, co znamená pojem operating system, ale nepodařilo se mi to překonat ani pomocí privileges, ani ničím jiným. Takže v tom článku borci prostě okopírují ta data a pak to přečtou. Tak to dělám taky. Akorát já to dělám tak, aby to fungovalo, narozdíl od nich (pinvoke RegQueryValueEx a RegSetValueEx :-)

Ale je to nepodporované a obával bych se, že vám to může poškodit LSA databázi, takže jen pro testovací účely a nikoliv v produkci.

Takže pouze BEZPEČNÉ čtení všeho co jde, BEZ MODIFIKACÍ. Nepřečtete ale hesla služeb (service passwords):

lib-common.ps1
lib-utils.ps1
Get-LsaSecrets

Pokud chcete číst hesla služeb, musíte nechat ten skript kopírovat klíče s těmi LSA private data object, takže POUZE do TESTOVACÍHO PROSTŘEDÍ, určitě NEZKOUŠET v PRODUKCI (nebo třeba offline pro forensic analýzu):

lib-common.ps1
lib-utils.ps1
lib-modifyActions.ps1
Get-LsaSecrets -Name $null -returnAsByteArray $false -forceMachineSecretsDecryptionByKeyCopyOperation $true

Výsledkem je prostě list jednotlivých LSA secrets. Pokud se něco nepodaří přečíst, prostě dostanete jenom datum a čas jeho změn, ten jde přečíst vždycky.

leden 03
Co mají společného Group Managed Service Accounts s DNSSEC a PFX, aneb centrální čipová karta

Windows 2012 a Windows 8 přišly s technologiemi jako jsou group managed service accounts (gMSA), dotažený DNSSEC (neboli secure DNS), soubory certifikátů se soukromým klíčem (private key), tedy PKCS #12 PFX soubory šifrované pro celou uživatelskou skupinu (neboli group protected PFX files), nebo třeba BitLocker šifrování pro sdílené diskové oddíly na failover clusteru (neboli BitLocker protected failover cluster volumes).

Jsou to všechno úplně jiné bezpečnostní technologie. Mají ale jednu společnou vlastnost, pro kterou bylo potřeba nejprve dodat podporu do Active Directory (AD DS). Všechny tyto technologie pracují na více počítačích a to i současně. Všechny používají nějaký tajný šifrovací klíč (secret key), který musí být na všech těch počítačích k dispozici.

Podívejme se na zrychleně jednotlivé typy a jejich klíče. Potom nás bude zajímat jak se to sakra sdílí. Zjednodušeně řečeno, někde se povalují klíče. Musíme zajistit, aby jen určitá skupina počítačů (nebo uživatelů) byla schopna si je přečíst, neboli použít. Nikdo jiný to nesmí být schopen udělat. A současně nechceme, aby se ty klíče přímo ukládaly v AD (jasné, ne? PFX je prostě jenom soubor).

Účty typu group managed service account (msDS-GroupManagedServiceAccount)

Tohle jsou v podstatě normální uživatelské účty, které ovšem nejsou obvyklého typu (class) user a mají určité výhody. Zvláště automatickou změnu hesla. Od Windows 2012 je můžete použít pro běh služeb (service), naplánovaných úloh (scheduled task), nebo IIS fondů aplikací (app pool). Účty se vytváří v Active Directory LDAPu pouze pomocí PowerShell příkazu New-AdServiceAccount. Nějaké informace můžete dostat zde, ale není to až tak úplně do detailu, jak mě osobně zajímalo.

V případě group managed service account (group MSA, uživatelské objekty typu msDS-GroupManagedServiceAccount) se jedná prostě o heslo (password) toho účtu. Tedy symetrický klíč v podstatě (symmetric key). Na každém serveru, kde má být daný skupinový účet spravované služby použit, musí být jeho heslo známo v plné formě (plain text, clear text). O tom, že účty služeb, naplánovaných úloh a IIS app poolů mají hesla uložena v plné formě jsem tu už psal (další věci zde a zde). V případě těchto účtů tomu není jinak. Mají jen dvě výhody.

Zaprvé se jim heslo mění samo - mění se to zvláštním způsobem, pobavíme se o tom později - pravidelně jednou za třicet dnů. Pokud tedy nezměníte frekvenci změny parametrem ManagedPasswordIntervalInDays (AD attribute msDS-ManagedPasswordInterval). Zadruhé pro ně LSA na serverech nedělá v případě Kerberos ověření kontrolu zvanou PAC validation (k tématu PAC a jeho kontroly jen okrajově zde a zde a tady).

Znamená to tedy, že všechny počítače (proto group MSA), na kterých je takový účet zadán pro běh nějaké služby, musí být to heslo k dispozici. Daný počítač si ho musí od někud stáhnout. Stáhne si ho rovnou z Active Directory databáze. Seznam počítačů, které si mohou heslo účtu přečíst, se konfiguruje pomocí parametru PrincipalsAllowedToRetrieveManagedPassword (ADDS attribute msDS-GroupMSAMembership).

Je to normální účet uživatele/počítače, takže se samozřejmě v AD ukládá jeho normální hash (nt-hash MD4, digest hash MD5, aes hash SHA-1 apod.). Ale navíc se v atributu msDS-ManagedPassword pamatuje přímo jeho heslo v plné formě. Je to sice constructed (computed) atribut, ale o tom až za chviličku. Počítače, které to mají dovolené, si to heslo prostě odtud načtou v plné formě. A to je právě ta divnost, že?

Už teď dopředu můžeme říct, že atribut msDS-ManagedPassword je opravdu jen constructed (computed) atribut. To znamená že v databázi NTDS.DIT ve skutečnosti není přímo uložen. Pokud se podíváte na gMSA pomocí repadmin /showobjmeta, dozvíte se, že jediné, co je tam ve skutečnosti uloženo je atribut msDS-ManagedPasswordId. Hodnota tohoto atributu není nijak pořádně chráněna, atribut není confidential, ani na něm nejsou žádná speciální oprávnění. Prostě se normálně replikuje i do RODC, a kdokoliv kdo to má dovoleno, si ho může přečíst. Z něho se zjišťuje heslo toho účtu.

Poznámka: jen pro úplnost, je zajímavé, že se to dokonce tváří spíše jako počítačový účet - je to odvozeno od třídy (class) computer, atribut sAMAccountType obsahuje hodnotu 805306369 = MACHINE_ACCOUNT, primární skupinu (primaryGroupId) má Domain Computers a i atribut userAccountControl obsahuje bit 0x1000 = 4096 = WORKSTATION_TRUST_ACCOUNT.

Technologie secure DNS, neboli DNSSEC

V případě DNSSEC jde o zone master key signing key (KSK) - tedy klíč, kterým se v podstatě podepisují (digital signature) záznamy v DNS zóně (zone). Sice nepřímo, prostředníctvím dalších klíčů - zone signing key (ZSK) - ale přesto bezpečnost stojí na onom master klíči. Jedná se o RSA, nebo o ECDSA soukromý klíč (private key).

Podpisový klíč je uložen opět v Active Directory, opět v plné formě, samozřejmě. Je to obsah objektu typu dnsZone a jeho atributu msDNS-SigningKeys. Tohle je v příslušné DNS application partition, například v DomainDnsZones, nebo v celo-forestové ForestDnsZones. K tomu je tam ještě jeden atribut msDNS-SigningKeyDescriptors. Oba atributy jsou normálně nezabezpečené, normálně replikované i do RODC a nemají žádná speciálnější oprávnění.

Není to nebezpečné? Všimněte si také, že tyto klíče, podle uložení záznamů zóny (zone records), musí být schopen dostat libovolný DNS server na libovolném DC z celého forestu.

Ochrana privátního klíče v souboru PFX pro uživatelskou skupinu (group protected PFX)

Pokud máte Windows 8, nebo Windows 2012 a novější, pokud exportujete certifikát i se soukromým klíčem (private key) do formátu PKCS12, tedy do souboru PFX (někdy i P12), musíte ho tam nějak zašifrovat. Buď prostě zadáte heslo, jako kdykoliv dříve. Nebo jen vyberete, že ho má být schopna dešifrovat nějaká Active Directory skupina. A je to. Bez zadávání hesla. A přitom je to šifrováno nějakým symetrickým klíčem.

A tenhle soubor se vám bude povalovat kdekoliv na libovolném počítači v celém forestu. A zase to musí být bezpečně chráněno jen pro danou AD skupinu. Musíme počítat také s tím, že se její členství bude občas měnit.

V tomto případě je také důvod, aby ty klíče nebyly přímo uloženy v AD. Takových PFX souborů může existovat tisíce, nebo milióny a proč bychom tím zahmyzovali obsah LDAPu? Navíc kdo by řešil, jestli jsou ty klíče ještě potřeba, nebo zda už ten PKCS 12 soubor vůbec neexistuje?

Ve skutečnosti je seznam autorizovaných skupin (descriptor) i ten dešifrovací symetrický klíč uložen přímo v tom PFX souboru.

BitLocker a oddíly sdílených úložišt na failover cluster

Opět velice podobně. Máte několik členů klastru (failover cluster). Všechny tyhle počítače (node) mají připojen nějaký společný "disk". Všechny do něho umí samy nekontrolovaně zapisovat (cluster shared volume). Když to chcete mít zašifrované pomocí BitLocker Drive Encryption (BDE, FVE), všechny node musí mít na to klíč. Symetrický (symmetric key) AES klíč. Jak to budou sdílet?

Přímo na zašifrovaném oddílu je jeho dešifrovací klíč spolu s popisovačem (descriptor), který říká, že pouze účet failover clusteru může klíč používat.

Rekapitulace požadavků

Všechny ty služby mají svoje tajné informace u sebe při ruce. Uloženy podle vlastní logiky. Některé v LDAPu, některé v souboru, BitLocker to má v metadatech zašifrovaného oddílu. Někdo jiný by to mohl mít v registrech. Nebo napsané na papírku. Prostě každý si uloží svoje tajné klíče.

K tomu tam je vždycky ještě nějaký popisovač (descriptor), který určuje skupiny, nebo uživatelské účty, které ta tajná data mohou dostat, neboli používat.

Musíme zajistit, aby tajná data nešla jen tak přečíst. A nesmíme dovolit, aby někdo změnil ten popisovač - descriptor.

Řešení v podobě centrálního klíčového serveru na Windows 2012

Windows 2012 přichází s novou službou (Windows service) nazvanou Microsoft Key Distribution Service (kdssvc), která je realizována jako kdssvc.dll do lsass.exe procesu. Služba se instaluje jako součást AD DS (Active Directory Domain Services) role. Je to RPC služba (B9785960-524F-11DF-8B6D-83DCDED72085), která se startuje Manual (Triggered), tedy zapne se sama až si o to libovolný klient požádá přes port TCP 135 (RPC endpoint mapper). Dokonce k tomu existují i dvě výchozí výjimky ve Windows Firewall.

Nijak to nezávisí na domain functional level (DFL), ani forest functional level (FFL) - některé další věci, které nejsou závislé na funkční úrovni jsou třeba zde.

Tahle služba realizuje nové Group Data Protection API (DPAPI-NG, neboli CNG DPAPI). To je novější rozšíření a obdoba DPAPI, což procuje jen lokálně (tohle používá třeba SharePoint k ochraně passphrase). Dokumentace se dá najít v Open Protocol Specifications. Jmenuje se to také CNG DPAPI, protože je to postavené nad novým Cryptography Next Generation API. Není moc programů, které by CNG používaly, ale ono to není ve skutečnosti potřeba, rozhodně ne kvůli group MSA.

Funguje to velice jednoduše. Služba Microsoft Key Distribution Service běží jen na Windows 2012 a novějších DC. Služba má přímo v Active Directory, v Configuration oddíle (partition) uložen svůj root master key (někdy taky KDS root key). Nachází se to tady:

CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=
    CN=Master Root Keys

Je tam jeden, nebo více, objektů typu msKds-ProvRootKey, které mají svoje tajná data v atributech msKds-KDFParam, msKds-SecretAgreementParam a msKds-RootKeyData. Je to v Configuration oddíle, takže je to replikováno na všechna DC v celém forestu. Tyto tři citlivé atributy jsou ve schematu označeny pomocí searchFlags jako CONFIDENTIAL a RODC_FILTERED. Znamená to, že se nereplikují do RODC. Jejich hodnotu může také číst pouze uživatel, který na ně má oprávnění zápisu - to je ta vlastnost confidential. Taková oprávnění má pouze SYSTEM, Domain Admins z forest root domain a Enterprise Admins. Tudíž je to vcelku dobře chráněno.

Pokud tam ještě žádný takový root master key není vytvořen, je potřeba ho založit ručně (nebo se založí sám), pomocí Add-KdsRootKey. V podstatě potřebujete jen jedne takový root key. Ale můžete jich mít více. Každý root key má jiné parametry, jako jestli to je RSA, nebo ECDSA klíč, případně se může lišit svou bitovou délkou.

Je zajímavé, že kvůli gMSA si ten PowerShell musíte zavolat sami ručně, zatímco ochránit PFX, nebo DNSSEC zónu a BitLocker jde samo od sebe. Klíč tam vznikne prostě sám od sebe.

Jestli tam klíč už máte se můžete buď normálně podívat, například přes ADSI Edit, nebo byste měli vidět následující událost v KdsSvc logu na jednom z vašich Windows 2012 a novějších DC:

Log: Application and Service Logs/Microsoft/Windows/KdsSvc/Operational
Event Id: 4004 
Event Type: Information
Event Source: KdsSvc
Message: Group Key Distribution Service created the first root master key in AD. The key ID is ...

Služba Key Distribution Service je přístupná přes RPC (například lsass named pipe). Spolu s původním DPAPI to nabízí služby jako protect key a protect secret a unprotect key a unprotect secret. Sama služba dělá ve skutečnosti jenom generování konkrétních skupinových klíčů (generates group key) ze svého root master key. Ale precizní detaily si můžete přečíst v normě. To pro nás není až tak podstatné.

V podstatě a technicky velmi zjednodušeně to funguje takto:

  • chci ochránit nějaká tajná data (secret) tak, že se k tomu dostane jen nějaká konkrétní skupina (protect secret)
    1. vygeneruji si seznam skupin (SIDů, tedy security descriptor), které se k daným tajným datům mohou dostat, tohle se nazývá descriptor
      • třeba DNSSEC tam dává skupinu Domain Controllers (RID 516), pokud se jedná o zónu v DomainDnsZones, nebo SID Enteprise Domain Controllers (S-1-5-9)
      • failover cluster tam dává svůj klastrový virtuální účet (virtual cluster account)
      • group managed service account tam dává vcelku překvapivě taky skupinu Domain Controllers
    2. descriptor si zašlu na službu Key Distribution Service, která mi to digitálně podepíše svým soukromým klíčem (private key)
    3. vezmu podepsaný descriptor a nechám si veřejným klíčem (public key) služby KDS zašifrovat svoje tajná data
    4. tahle zašifrovaná tajná data si ani já sám nepřečtu. Uložím si to ale dohromady s tím descriptorem, který je digitálně podepsaný KDS službou
      • uložení je buď právě v AD LDAPu, nebo například v PFX souboru
  • když ta tajná data potřebuju na něco použít
    1. tak vezmu podepsaný descriptor, kterému KDSSVC služba sama věří, protože si ho sama podepsala
    2. a pošlu jí ta zašifrovaná tajná data spolu s tím podepsaným descriptorem (unprotect secret)
    3. a ono mi to vrátí ta tajná data v čisté formě. Tedy samozřejmě jen v případě, že ten kdo volá to KDS API, má ve svém access token správné skupiny (nebo přesněji řečeno SIDy)

Z toho by mělo být vidět, že tajná data si uchováváte sami, ale jediný, kdo vám je může zpřístupnit je služba Key Distribution Service. A ta služba k tomu kontroluje přístupová oprávnění a vaše členství ve skupinách na základě security descriptoru, který si mohla jen ona sama vygenerovat. Navíc se tajná data mohou povalovat úplně libovolně kdekoliv.

Všechny přenosy jsou samozřejmě normálně šifrované RPC šifrováním (tedy klíče získané z Kerberos, nebo NTLM ověření). Pokud je žadatelem o klíče rovnou operační systém řadiče domény (DC, domain controller), tak dokonce ani služba KdsSvc nemusí vůbec běžet.

Řekl bych, že by tedy už mělo být vidět, jak to funguje pro DNSSEC, failover cluster a PFX soubory, ne? Pořád ale zůstává hodně otázek ohledně group managed service account (gMSA). Jaktože ten jejich descriptor obsahuje Domain Controllers? A co tam dělá ten constructed (computed) atribut? A kdo mění heslo toho účtu? A jak? To si ale milé děti něcháme na příště, protože tohle už je opravdu hooodně dlouhé a navíc se musím jít věnovat dětem.

Ještě bych dodal, že pokud operace (un)protect key, nebo (un)protect secret, selže na nějakém počítači (tam, kde třeba pracujete s PFX souborem), tak to uvidíte v logu přímo na tomto počítači. Například:

Log: Application and Service Logs/Microsoft/Windows/Crypto-NCrypt/Operational
Event Id: 5
Event Type: Error
Event Source: Crypto-NCrypt
Message:
	Protect Key operation failed.
	Protector name: SID
	Recipient attributes: S-1-5-21-domain-516 (domain\Domain Controllers for DC=DomainDnsZones,...)
	Recipient attributes: S-1-5-9 (builtin\Enteprise Domain Controllers for DC=ForestDnsZones,...)
	Flags: 0x40
	Return code: 0x800706D9 = 1753 (EPT_S_NOT_REGISTERED: There are no more endpoints available from the endpoint mapper)

 

Log: Application and Service Logs/Microsoft/Windows/Crypto-NCrypt/Operational
Event Id: 7
Event Type: Error
Event Source: Crypto-NCrypt
Message:
	Protect Secret operation failed.
	Flags: 0x40
	Return code: 0x80090034

 

Log: Application and Service Logs/Microsoft/Windows/Crypto-NCrypt/Operational
Event Id: 6
Event Type: Error
Event Source: Crypto-NCrypt
Message:
	Unprotect Key operation failed.
	Protector name: SID
	Recipient type: Symmetric Key Encryption
	Flags: 0x0
	Return code: 0x800706D9 = 1753 (EPT_S_NOT_REGISTERED: There are no more endpoints available from the endpoint mapper)

 

Log: Application and Service Logs/Microsoft/Windows/Crypto-NCrypt/Operational
Event Id: 8
Event Type: Error
Event Source: Crypto-NCrypt
Message:
	Unprotect Secret operation failed.
	Flags: 0x0
	Return code: 0x8009002C (NTE_DECRYPTION_FAILURE: The specified data could not be decrypted)

A ještě jedna poslední otázečka. Pokud mám více DC a přitom nejsou všechny verze Windows 2012, jak to funguje? Ona služba netlogon a její funkce DC locator má na novějších systémech schopnost vyhledat jen řadiče domény určité důležité verze. Můžete to zkusit sami pomocí nltest: (DS_6 je Windows 2008 a novější, DS_8 je Windows 2012 a novější a DS_9 je Windows 2012 R2 a novější):

nltest /dsgetDC:gopas /ds_9

 

A všechno nej do nového roku!

prosinec 21
Propaganda a nic než propaganda

Teď jsem dostal od kamaráda odkaz na článek o tom, jak nesvětější Chrome vývojáři plánují, že zablokují nezašifrované HTTP, protože jeho vývojáři mají ten nejsprávnější přístup, ten program se považuje za úplně nejvíc nejbezpečnější a nejkrásnější na něm je, že umožňuje instalovat jenom software z google obchodu, protože když na tom vydělává gůgle, tak je to prostě nejbezpečnější. Každá žena by měla mít stále při sobě buď onoho nejbezpečnějšího vývojáře, nebo alespoň Chrome v kabelce.

Začal jsem si hned se svým oblíbeným Internet Explorerem připadat zranitelný. A nějak podivně mě rozbolela prdel. Dwejnééé! (kdo nečetl Mládí v hajzlu, tohle neřešte :-)

Podíval jsem se tedy na zoubek statistice. Jednoduše se to dá vyhledat v National Vulnerability Database. Vyhledal jsem si všechny nálezy v prohlížečích Internet Explorer, Chrome a Firefox od listopadu 2011 do listopadu 2014. Tedy poslední tři roky. Když se to udělá na každý z těch let zvlášť, jsou v tom velké rozdíly.

V tabulce je počet High problémů. Libovolná verze prohlížeče.

Prohlížeč Počet
Internet Explorer 356
Chrome 374
Firefox 282

A do háje. Von ten kroum zas tak ultra mega moc bezpečnej nejni. A díra v zadku se zase zacelila. Až se zdá, že vlastně ani nikdy nebolela :-)

prosinec 19
Přehled RID rozsahů jednotlivých DC z celého forestu

Dobrá, dobrá, tak i já jsem se snížil k použití toho podivného ActiveDirectory module pro PowerShell.

Dnes tu máme přehlednou tabulečku s aktuálními nejvyššími RID pool rozsahy všech DC z celého forestu. Je to hodnota zjištěna z jediného DC v každé doméně, na které se právě ten modul připojuje pomocí Active Directory Web Services (ADWS). Čte to hodnotu rIDAvailablePool, která je normálně replikovaná mezi všemi DC v dané doméně. Řadiče domény mají mnohdy ještě jeden RID rozsah ze kterého možná vydávají nové SIDy - rIDPreviousAllocationPool. Tohle není replikované, protože to ani není potřeba.

Skript se může hodit na představu, jaké SID koncovky, nebo lépe řečeno RID se budou objevovat na vašich DC v nějaké brzké budoucnosti. Také se z toho dá zjistit, jestli nemáte duplicitní RID pool. Proč? Třeba když děláte operaci seize pro RID FSMO, nebo restore nějakého domain controller, který je RID master FSMO. Viz. můj článek o obnově RID master.

Skript následuje:

Get-ADDomain | 
  Select -Expand DistinguishedName |
    % { Get-ADDomainController -Filter "DefaultPartition -eq '$_'" } |
      Select ComputerObjectDN, DefaultPartition, Domain |
% { 
  $ridSet = Get-ADObject "CN=RID Set,$($_.ComputerObjectDN)" -Property *
  $_ | Select *, @{ n = 'Low' ; e = { [int] ($ridSet.rIDAllocationPool % 4GB) } }, @{ n = 'High' ; e = { [int] ($ridSet.rIDAllocationPool / 4GB) } }
}

 

prosinec 18
Jak vypnout first sign-in animation na Windows 8 a Windows 8.1

Včera večer jsem na své WUG přednášce o Kerberos ověřování zmínil, že bych potřeboval vypínat takovou tu otravnou animaci, která se vám zobrazuje během prvního přihlášení na Windows 8 a Windows 8.1. Píše to něco jo, "hi, we are setting things up for you" a "check out the new way to use Windows" a podobné kraviny.

Tak jsem to tam řekl a urodilo se :-) Děkuji Petrovi Girgalovi. Poslal mi tenhle odkaz.

Píšou tam, že se to jmenuje first sign-in animation. V češtině je to zřejmě animace při prvním přihlášení. Píšou tam taky, že se to dá vypnout pomocí registrové hodnoty:

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System
EnableFirstLogonAnimation = REG_DWORD = 0

Z toho klíče je jasně vidět, že se jedná o Group Policy (GPO) hodnotu. Já osobně nerad hodnoty do těchto dvou klíčů dávám ručně:

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System
HKLM\Software\Policies

Do těchto klíčů nastavuje ty hodnoty Group Policy. Kdo ví, kdy to taky Group Policy smaže a naopak, kdy to bude kolidovat se kterým Group Policy nastavením. Takže jsem se rovnou vypravil do GPO editoru. A použil jsem filter nad Administrative Templates.

Vyhledávání a filtrování v Group Policy

Proč to píšu je právě upozornění na to, že v Group Policy Object editoru, nebo přesněji v jeho části Administrative Templates, se dá hledat, pokud jste to nevěděli.

Normálně kliknete pravým tlačítkem na Policies - Administrative Templates a vyberete Filter Options. Zaškrtnete Enable keyword filters a napíšete slovo, nebo slova, která chcete hledat. Umí to hledat v názvech (policy title), popiscích (help text, neboli explain), případně i v komentářích, pokud to používáte.

A potom už uvidíte jenom politiky, které to slovo obsahují.

Dal jsem do toho slovo "animation". Není úplně vždy jednoduché ty zásady najít, protože buď toho najdete strašně moc, nebo naopak nic, protože se to v GPO jmenuje jinak, než by člověk očekával. Samozřejmě pokud to máte česky, tak s nějakým kloudným výsledkem ani nepočítejte :-)

A výsledek je politika v tomhle umístění:

Computer Configuration
  Policies
    Administrative Templates
      System
        Logon
          Show first sign-in animation

V čestině je to tady:

Konfigurace počítače
  Zásady
    Šablony pro správu
      Systém
        Přihlášení
          Zobrazit animaci při prvním přihlášení

A to je tedy konec té otravy :-)

1 - 14Next
>
 

 Rychlovky lepší než tvítr

 
23.1.2015 19:24
aktualizoval jsem svuj volatile forensics script - ted to audituje i certifikáty, lépe to překládá SIDy přihlášených uživatelů a používá to svůj vlastní Temp. https://www.sevecek.com/files/volatileForensics. Sice to nejsou úplně prchavé informace, dají se samozřejmě zjistit později i z imidže, ale i tak není špatné to slíznout rovnou.
23.1.2015 13:12
dejte si do google obrázků "my new credit card". Ti lidi musí být úplní magoři :-)
22.1.2015 7:06
Tak znovu. Kde je NEuspornost normalni zarovky? Co vytopim zarovkama usetrim na topeni. Stoji zlomek a SVITI!
16.1.2015 8:48
Přednáška o Kerberos, už příští týden na WUG Bratislava v GOPASu od 17 hodin: http://www.wug.sk/?name=events&e=172
16.1.2015 8:44
plazi se slimaci a potkaj tretiho. ten ma vestu s trhavinou, v jedny ruce granat a v druhy odpalovaci zarizeni. ty dva na nej koukaj a povidaj: a ty ses kdo ? a on odpovi: ja sem muslimak
15.1.2015 13:57
zdroják všech mých PowerShell kódů, pokud vynechám občasné maličkosti, právě dosáhl 25112 řádků včetně poznámek. Nepočítám prázdné řádky.
13.1.2015 8:39
Tri volavky? v letu, paráda
12.1.2015 17:11
no nechápu proč je na myši nastaveno ve výchozím stavu "Allow this device to wake up computer". Obvykle to vypínám potom, co se mě natvrdo po cestě vybije noťas.
9.1.2015 11:16
To jsem nevěděl, že PowerShell validace paremetrů v klauzuli Param() platí pro tu proměnnou i nadále uvnitř dalšího kódu. (Get-Variable $vstup).attributes.
7.1.2015 18:32
dneska spam - že prý "splňte si předsevzetí začít pracovat efektivně už v lednu"? Jakože "jsem línej lempl, tak třeba mě někdo poradí, jak se toho zbavit"? :-) Ale rovnou jsem to smazal, tak nevím.
7.1.2015 15:21
CD se posouvaji do dalsi dimenze. Jidelnicek RailJet: dva parky plus rohlik = 153 CZK, jeden kynuty knedlik = 185 CZK
22.12.2014 8:25
"Dnes mají rodiče největší obavy z toho, co jejich syn stahuje z Internetu a co jejich dcera na Internet nahrává."
18.12.2014 14:42
No hned si valím nainstalovat tenhle kazič stability a výkonu. To stojí za to: http://www.zive.cz/bleskovky/viber-se-pustil-do-esetu-ten-mu-to-spocital-na-twitteru/sc-4-a-176542/default.aspx
2.12.2014 6:13
Windows 8.1 se nasilne restartnou po aktualizacich, kdyz to dlouho neudelate sami, jak jsem prave zazil :-) Ale zase potom pospousti vsechny predchozi program.
29.11.2014 11:48
Znamy po me chtel nastaveni sites v IE pres GPO. https://www.sevecek.com/Lists/Posts/Post.aspx?ID=411
28.11.2014 11:40
Ve stredu 17.12. budu mit WUG na tema Kerberos! https://www.sevecek.com/Lists/Calendar/DispForm.aspx?ID=54
27.11.2014 11:51
McDonald zrusil smazak???!!!
26.11.2014 18:07
Linux? Navic s ceskou klavesnici?
21.11.2014 19:34
Byl jsem v pondeli na Interstellar.Dost me desilo tech 170 minut,ale super!Nadherne cizi planety.A ten motiv rodice me vcelku vzal.
19.11.2014 8:40
Panebozeee, lsass.exe 1000 hardfaults/sec, 10GB commit. Co to jeee? Uz poslednich 5 minuuuut!
19.11.2014 6:47
Windows 8.1. pravým tlačítkem na taskbar - Properties, záložka Navigation, Replace CMD with PowerShell in the Win+X menu
18.11.2014 4:32
Odinstalace Gugle Chrome prave zrychlila pocitac cca 3x. Tolik ke kvalitam techhle nesmyslu.
13.11.2014 19:55
Windows Experience Index na Windows 8.1 - winsat prepop, gwmi win32_winsat
13.11.2014 19:18
na Windows 8.1 neni Windows Experience Index? Na Windows 8 ho jeste mam
12.11.2014 10:21
a to není žádná sranda - to je každý web server, RDPčko, TMG i DCčko přes LDAPS, nebo Exchange!