Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > default
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 :-)

prosinec 11
Tak nám pomalu končí SHA-1, tentokrát už úplně

Podle následujících dvou referencí: http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx, http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx se mění Microsoft požadavky na členské kořenové CA v MS root certificate program.

Jsou tam nějaké výrokové podivnosti a nejasnosti, takže zde je to mými slovy tak, jak jsem to pochopil:

  1. něco se začne dít už 1.ledna 2016, pro SSL až od 1.ledna 2017
  2. stávající root CA zůstávají na programu a tedy důvěryhodné, pokud si změní politiku (policy) vydávání Server Authentication a Code Signing certifikátů a budou je dobrovolně vydávat podepsané SHA2
  3. upozorňuju, že je jedno, jestli jejich vlastní root CA certifikát zůstane podepsán SHA1, nebo třeba MD5. Jedná se o jeden jediný certifikát, který tedy není z pravděpodobnostního hlediska příliš rizikový a nepodléhá aní choosen-prefix ani jiným pre-computation útokům. Rizikovost svého vlastního certifikátu si hlídají root CA samy a případně by ho z programu odhlásily
  4. nově přidávané root CA certifikáty už budou muset být SHA-2, aby je root program přijal

Pořád nevím následující - v článku se vyjadřují že "Windows will stop accepting SHA-1 SSL certificates". Tohle by mě zajímalo. Znamená to snad, že natvrdo přestanou (technicky) brát koncové certifikáty podepsané SHA-1 jako platné (píše se tam, že i certifikáty vydané před datem 2017)? To by ovšem znamenalo, že to bude natvrdo nakódováno buď přímo do CSP/CNG knihoven, nebo třeba do Schannel, nebo možná jen do IE apod. Z jedné věty se dokonce zdá, že tahle blokace bude platit i pro certifikáty podřízených autorit (subordinate CA).

Uvidíme. V každém případě by to znamenalo, že dokonce i vaše vlastní vnitřní CA budou muset přestat vydávat SHA1 koncové certifikáty a budou muset začít vydávat SHA-256 a silnější. Jakmile zjistím, doplním.

Jen pro doplnění, nějaké moje starší články na tato témata zde, tady, tu, a ještě i tady.

prosinec 04
Strašlivě pomalé Hyper-V

Potřebuju radu.

Veliký problém s Hyper-V výkonem VHDX souborů. Situace je následující. Hyper-V host se dvěma CPU sockety, má to 2 NUMA node. NUMA spanning je vypnut. Storage je iSCSI. Disk, na kterém jsou VHDX soubory není clustrovaný. Jak železo, tak i virtuální stroj (jedinný běžící) je Windows Server 2012 R2 se všemi aktualizacemi z Windows Update. Ve virtuálce se to chová stejně, i když je tam jenom čistá instalace stejného OS. Hyper-V integration components (IC) uvnitř VM jsou nejnovější možné. Virtuální stroj nemá žádné NIC. Nemá zapnutu dynamickou paměť. VHDX je sice dynamicky rostoucí, ale nezvětšuje se a byl překopírován na čistý disk, takže bez fragmentace, což říká i Get-VHD.

Železo jede velice svižně. Virtuální počítač je velice pomalý. Když se podívám na disk response time (disk latency) na železe, je vidět, že do těch VHDX souborů se zapisuje s cca 1-3ms. Když se podívám přes Resource Monitor na to stejné uvnitř virtuálního počítače, vidím disk latency cca 100ms a mnohem více.

Formát je 64kB jak disku s VHDX, tak i uvnitř virtuálního počítače. VHDX 4kB fyzický sektor, 512B logický směrem do virtuálky.

Někdo nějaké nápady?

prosinec 02
Panebože, já se z toho PowerShellu snad zblázním

Tak v tomhle případě jsem samozřejmě chtěl říct něco úplně jiného, než "zblázním". Kreténi. Bože. Co to zase je za peklo.

Tak dneska k podivnému přetypování hashtable.Keys.

Následující kód je snad jasný. Všechny tři druhy polí jsou IEnumerable. Jak normální pole, tak ArrayList, tak i KeyCollection. Takže to jde přetypovat do ArrayList naprosto v pořádku. PowerShell ty prvky prostě přeskládá. Od toho je to skriptovací jazyk. Používám to tak už roky:

[Collections.ArrayList] $alist = @('ondrej' , 'kamil' , 'jitka' )
$array = @('ondrej' , 'kamil' , 'jitka' )
$hash = @{ 0 = 'ondrej' ; 11 = 'kamil' ; 20 = 'jitka' }


[Collections.ArrayList] $arrayList = $alist
write-host $arrayList.GetType().Name
write-host $arrayList.Count

[Collections.ArrayList] $arrayList = $array
write-host $arrayList.GetType().Name
write-host $arrayList.Count

[Collections.ArrayList] $arrayList = $hash.Keys
write-host $arrayList.GetType().Name
write-host $arrayList.Count

Přetypování proběhne v klidu, výsledek má 3 položky v ArrayListu. Všechno ok.

A teď to stejné, ale do parametru funkce:

function Paneboze ([Collections.ArrayList] $arrayList)
{
  write-host $arrayList.Count
}

Paneboze $hash.Keys
Paneboze $alist
Paneboze $array

Výsledek? Pole a ArrayList se do toho vstupního parametru přetypovaly (přeskládaly) úplně normálně. Stejně jako předtím. Narozdíl od hashtable.Keys. To se tam nepřetypovalo. To se celé zabalilo jako do prvního prvku toho ArrayList.

Kreténi! Ještě že mi Willi dal tu pálku k narozeninám. Až se vrátím domů, někde ji rozmlátím.

listopad 28
Vtip od Milana Bortela

Vtip od Milana Bortela. Takže já tady nejsem ten rasista :-)

Liška, vlk a medvěd jsou nezaměstnaní a tak jdou na pracák. Po týdnu se zase potkají a říkají si jak na tom jsou:

Liška: "no já už zas nedělám. Dostala jsem hlídat slepice, no a je snad jasné, že za týden jich pár chybělo..."

Vlk: "joo, to já taky ne. Měl jsem hlídat ovce. Znáte to. No a dvě pak chyběly, tak už nedělám."

Na to ovšem medvěd: "to já jsem v pohodě. Dělám v ekodvoře. Železo nežeru a cigány nikdo nepočítá"

listopad 26
Můj vlastní security bulletin (už dlouho zapomenutý)

Teď je zrovna taková pastva bezpečnostních záplat, že mě napadlo podívat se, jestli jsem se tu pochlubil, že i já jsem objevil jednu díru. Už je to hoooodně dávno. Ale každá sebechvála se počítá :-) A navíc jsem třeba jediný čech, který kdy něco takového nahlásil???

Můj security bulletin je tady: Microsoft Security Bulletin Summary for April 2004 (CAN-2003-0806) - winlogon vulnerability

O co šlo? Jednoduše remote code execution přes buffer overflow v procesu winlogon. To je přihlašovací proces, který si od vás vyzvedne přihlašovací údaje a spustí vám userinit.exe a potažmo tedy průzkumníka Windows (windows explorer). No a oni si kopírovali jeden buffer, konkrétně obsah homeDrive attributu z Active Directory, u kterého počítali, že má jenom dva znaky. A on jich může mít libovolný počet. A přitom nekontrolovali délku toho bufferu. Takže cokoliv jste dali do toho atributu v Active Directory, přepsalo stack v jedné funkci v procesu winlogon.

Našel jsem to tak, že jsem blbě použil nějaké atributy a proměnné a padal mi winlogon, tak jsem to trošku disassembloval a našel tohle.

No nic kritického, ale security bulletin z toho byl :-)

Zajímavá je na tom ta zkušenost s domluvou na Microsoftu. Od prvního kontaktu to trvalo tak alespoň půl roku, než na to vydali opravu. Tak samozřejmě, chce to otestovat a nací mi na to ty potvory dali rating jenom moderate :-) A to bylo nepřetržite debilních dotazů od nějakého inda ve stylu "a už na to máte exploit?", "nechcete s tím náhodou vyjít ven dříve?", ale hlavně pořád chtěli popisovat jak to funguje a co je špatně. Asi desetkrát jsem jim to popisoval v podstatě znovu a dokolečka totéž. Prostě zdržovačka

listopad 19
Jak rychlý je BitLocker na Windows 8.1

Zrovna jsem si upgrádnul na notebooku 7200 otáčkový disk na SSD a přeinstaloval se na tenhle nový disk. Mimochodem, parádní fíčura, koupíte si místo DVD jenom SATA rámeček na harddisk a do toho dáte SSDčko. DVD mě bylo na prd a takhle mám víc kapacity a ještě neuvěřitelně rychlý provoz. A to všechno na šet let starém notebooku. A zase to pár let vydrží. Aspoň bych rád.

A tak jsem taky musel znovu zapnout BitLocker šifrování. Při té příležitosti jsem změřil rychlost. Studený boot plus spuštění Outlooku, OneNote, Salamander a Visual Studio a Skype.

Bez BitLocker šifrování 24 sekund.

Při BitLocker šifrování oddílu s operačním systémem 26 sekund.

Paráda.

Jo a mám multiboot do dvou operačních systémů, každý na svém vlastním oddílu zašifrovaném pomocí BitLocker. Takže jen pro informaci a potvrzení - není problém, aby TPM používaly oba dva operační systémy a startovalo to "bez zadávání".

listopad 14
Nekomentované poznámky k SharePoint User Profile Service (UPS)

Tohle ani nečtěte. Jen jsou věci, které si nepamatuju a tak si je sem rád přihodím, abych se na ně mohl zpětně někdy podívat. Tak pardon, že s tím otravuju :-)

"User Information List" = DB table "AllUsers"

_layouts/15/userdisp.aspx?Force=true&ID=9
_layouts/15/people.aspx?MembershipGroupId=0
_layouts/15/useredit.aspx?ID=9

Set-SPUser -SyncFromAd

job "User Profile to SharePoint Quick Synchronization"


$webApp = Get-SPWebApplication https://intranet.gopas.cz
$webApp.UseClaimsAuthentication = $false # $true
$webApp.Update()


(New-SPClaimsPrincipal -Identity 'gps\kamil' -IdentityType 1).ToEncodedString()
# 1 = WindowsSamAccountName (may not exist) i:0#.w|gps\kamil
# 2 = WindowsSecurityGroupName (must exist) c:0+.w|s-1-5-21-3554988821-2548339769-934835410-1497
# 3 = WindowsSecurityGroupSID (may not exist)
# 4 = FormsUser
# 5 = FormsRole 
# 6 = EncodedClaim


$site.RootWeb.Lists | ? { $_.Title -eq 'User Information List' }
# or the same
$site.RootWeb.SiteUserInfoList

$site.RootWeb.SiteUsers | select UserLogin,ID,DisplayName,SystemUserKey,SID,IsSiteAdmin


$webApp.MigrateUsers()
$webApp.ProvisionGlobally()


Move-SPUser -Identity 'gps\helena' -NewAlias 'newDomain\helena'

 

listopad 13
Chyba jako prase

Aktualizujtééééé. KB2992611. Jak jsem už vpravo v rychlovkách psal včera, vyšla úplně extrémně důležitá aktualizace (CVE tady) na TLS (a SSL samozřejmě, i když SSL je roky přešlá mrtvola) knihovnu SChannel, která je ve všech Windows a používá se úplně na všechny TLS komunikace.

Zaslouží si to pozornost, protože:

  • je to remote code execution. To znamená, že vzdáleně nacpete do počítače kód. MS to nezveřejnil přesně, takže se neví ještě, jak moc kódu se tam dá dostat, ale hackeři jsou schopní vždycky něco vymyslet, aby to nemuselo být moc.
  • je to chyba v serverové části toho TLS protokolu, takže to bude napadat všechny možné servery. TLS se používá na IIS samozřejmě. Ale o hodně hůře také v RDP, Exchange (SMTPS), na Active Directory řadičích domény (ADDS DC - domain controller) pro LDAPS. Dále tuto knihovnu samozřemě využívá i TMG a ISA server. Dneska ADFS a Hyper-V replication. Také VPN v podání SSTP, a IKEv2 a i IPSec pokud se ověřujete pomocí AuthIP, takže i DirectAccess například. Je jedno, jestli to je IPHTTPS, nebo Teredo. Stejně je uvnitř AuthIP a TLS ověření.
  • je to TLS, které se ustavuje vždycky jako první, ještě dříve, než se vůbec někdo pokouší ověřovat. Takže to půjde nejspíš využít anonymně.
  • nemá to žádné workarounds ani mitigation factors. Z toho plyne, že proti tomu nefunguje ani ověřování client TLS certificate. Plyne z toho, že neexistují žádné "best practices", ani jiné Windows zabudované ochrany, které by to zmírnily, nebo úplně zastavily. I kdyby se muselo třeba čekat na nějakého klienta, až se připojí, nebo kdyby útočník musel být MITM (man-in-the-middle), tak by to tam bylo uvedeno, protože to výrazně omezuje prostor k útoku. A uvedeno to tam není!
  • je to problém v DLL knihovně, kterou si všechny ty systémy nahrávají do paměti. Nejde tedy o nějakou konkrétní Windows službu, ale o všechny služby, které tuto knihovnu používají. V tom, co jsem vyjmenoval v podstatě není ani jedna služba, která by na počítači neběžela pod účtem SYSTEM. Útočník tedy spustí kód, který je pánem daného počítače.

Vadí vám, že útok poběží pod účtem počítače? Ano. Uživatel SYSTEM je členem skupiny Administrators a může tedy dělat lokálně cokoliv. Stačí třeba, když do autorun klíče přihodí něco, co si spustíte až se přilásíte. Nebo si sám sobě vykrade hesla z IIS, naplánovaných úloh a služeb.

Samozřejmě, do sítě chodí už jen pod účtem počítače (POCITAC$), což je člen skupiny Users na ostatních strojích. Jenže vzhledem k počtu služeb, které jsou dostupné přes TLS takhle půjde napadnout velká část sítě. A pokud někdo napadne byť jen jediné DC, má celý forest v ruce a nemusí nic dalšího řešit. I když vám přepadnou Exchange, tak jste v pekle. Exchange server může obvykle vytvářet a modifikovat většinu účtů v Active Directory.

A tak to je. Psycho.

Pro úplnost - někdo si to plete s chybou v OleAut32 (MS tady). Což je ale něco jiného a ovlivňuje to "jen" klienta IE.

A teď jedna otázka - nedala to tam v devadesátých letech NSA?

listopad 07
Rychlovka - jak nastavit Protect object from accidental deletion pro uživatele a skupiny

Jak jste si jistě všimli od Windows 2008 R2 v jeho Active Directory Users and Computers konzoli (neboli Uživatelé a počítače služby Active Directory) je možné chránit objekty proti náhodnému smazání. Jedná se o zaškrtávátko ve vlastnostech uživatelského účtu nazvané Protect object from accidental deletion.

Tohle je automaticky zapínáno na organizačních jednotkách (organization unit) při jejich vytváření přes GUI. Pokud to děláte skriptem, tak se to nenastaví.

Na uživatelích a skupinách a jiných objektech to nastaveno ve výchozím stavu není. Nehledě na to, že to možná chcete nastavit na více objektů později.

Pomocí skriptu PowerShell to jde úplně snadno:

DSQUERY * 'OU=people,DC=gopas,DC=virtual' -filter '(|(objectClass=user)(objectClass=group)(objectClass=organizationalUnit))' | % { 

  DSACLS ($_.Trim().Trim('"').Trim()) /D Everyone:SDDTDC
}

Předchozí skript pozapíná zákazy mazání na uživatelích (user), skupinách (group) i organizačních jednotkách (organizationalUnit).

Upravit si nejspíš dokážete, pokud ne, dejte vědět :-)

Proč to nejde jednoduše zdědit?

Zděděná oprávnění jsou slabší, než nezděděná explicitní oprávnění z nižší úrovně hierarchie. Takže i zděděné zakazovací (deny) oprávnění je možné přebít nezděděným povolením. Ta klasická hláška, že deny je vždycky silnější je kec. Deny není vždycky silnější ani na NTFS ani nidke jinde. Všude je možné zděděné deny přerazit pomocí explicitní nezděděné povolovací položky allow.

No a ony objekty v Active Directory (ADDS) mají mnoho explicitních nezděděných položek oprávnění (permissions). Dostávají je při svém vzniku z default security descriptor, který je pro jejich typ definován ve schematu. To obsahuje například full control pro Domain Admins, nebo pro Account Operators.

Takže pro Domain Admins a Account Operators je potřeba udělat právě skriptem explicitní deny položky na každém objektu samostatně.

listopad 04
Nástroj a principy forenzní analýzy v okamžiku rychlé reakce - analýza prchavého stavu

To je hodně divný název, že? Tak to je můj překlad anglických termínů jako je forensic analysis, first response a first responder a volatile state.

Prchavý stav a první odpověď

O co jde? Na nějakých zařízeních (v našem případě postavených na Windows), byl nahlášen nějaký bezpečnostní incident (IS incident). Podle normy ISO/IEC 27035 by se to mělo spíše jmenovat událost (IS event), protože to nahlásil pracovník (tedy BFU) a hodnocení na incident může přijít teprve později, až to kvalifikovaně vyhodnotíme.

V takovém okamžiku nastupuje forenzní pracovník skupiny rychlého nasazení (forensis expert of first response). Norma ISO/IEC 27035 to nazývá ISIRT (information security incident response team).

Nebo možná jen kvalifikovaný systémový správce (system administrator), který má za úkol následující úplně prvotní věci:

  • zajistit místo události (suspected crime scene) tak, aby nedošlo poškození jeho důkazní kvality. To znamená zejména zabránit dalšímu kontaktu nekvalifikovaných osob nejen s výpočetním prostředím, ale také s jeho blízkým fyzickým prostředím. To jsou například stoly a věci na nich položené a v zásuvkách uložené, kabeláž i elektrická silová. Prostě ideálně celá kancelář.
  • vyhodnotit rozsah události a případně zajistit i vzdálenější místa, která s událostí souvisí. Pod tím bych si představoval například serverovnu, pokud je podezření, že událost ovlinila i vzdálená data.
  • všechno vyfotit, nejprve z dálky přehledně, potom z větší blízkosti. Pořád ještě ale bez těsných detailů zařízení. Ideálně to také točit na kameru. Kamerku na hlavu si pořídíte za pár korun.
  • a potom se zastavit a zamyslet se

Zamyslet se nad tím, jak moc chce zasahovat do místa činu (crime scene). Nejjednodušší, a bez přemýšlení, je možné prostě všechny počítače korektně vypnout. To znamená slušný, vyžádaný shutdown. Samozřejmě pokud to jde. Minimální zásah samozřejmě vylučuje nějaké zkoušení prolomit zamknutou obrazovku apod.

Prostě vidím, jestli počítač žije a můžu kliknout "vypnout". Pokud nemůžu, protože je třeba zhasnutá obrazovka, lehce zamyšuju bez klikání, třeba se rozsvítí. Pokud na mě vyskočí zamknutá plocha, nebo přihlašovací obrazovka, možná je tam čudlík shutdown. Pokud to vyžaduje přihlásit, požádám majitele počítače, aby se přihlásil. Pokud já jsem policie a on je podezřelý a neudělá mi tu radost, nebudu tam něco zkoušet zadávat a prostě to zkusím vypnout čudlíkem na bedně. Pokud ani to nejde, tak holt natvrdo vytrhnout z napájení.

Následuje detailní zaprotokolování důkazů (tomu se budu věnovat někdy příště). A buď rovnou na místě vytvoření bitových kopií úložišť, nebo odvoz do labu.

Jenže tímto přicházíte o paměťový stav (volatile state) toho počítače. Přijdete o seznam běžících procesů, o obsah jejích pamětí (ne všechno je ve stránkovacím souboru a ten se možná také smaže při vypínání). Mnoho konfigurací také nemusí být trvalých (persistent), jako jsou routey, nahozená TCP a VPN spojení, IPv6 tunely, seznam DNS a NetBIOS překladů apod.

Podle 27035 článku 8.2.1.3 (Incident information update) má člen ISIRT tedy zvážit a případně provést toto: "After the initial discovery of the incident, all volatile data should be collected before the affected IT system, service and/or network is shut down, for a complete information security forensics investigation. Information to be collected includes contents of memory, cache and registers, and detail of any activities running, and the following."

Bez zásahu do scény to nepůjde

K předchozímu odstavci norma připomíná, že "Two or more persons should be present when information security forensics duplication is performed, to assert and certify that all activities have been carried out in accordance with relevant legislation and regulation."

Což je důležité. Pokud chcete z počítače odnést jeho volatile data, musíte do něho nějak více zasáhnout a něco k němu připojit.

Pokud se rozhodnete k tomuto kroku, je důležité si uvědomit, že se zvětšuje prostor pro problémy, které můžete mít s takovými důkazy u soudu, pokud by k němu došlo. Protistrana bude chtít, aby soud vaše důkazy nepřipustil. To samozřejmě bude chtít vždycky, ale když budete do místa činu zasahovat, budete to muset umět soudu vysvětlit.

Podstatné je dokázat, že jste svým zásahem nevnesli do scény falešné důkazy, které by žalovanou stranu neprávem inkriminovaly. Celou situaci výrazně vylepší také to, že tento zásah do místa činu prováděla nezaujatá třetí strana - možná nějaký cizí specialista.

I v případě ohledání místa činu po vraždě tam forensní tým vnáši věci, které tam předtím nebyly. Ale snaží se minimalizovat škody. Mají ochranné obleky, aby z nich moc nepadaly chlupy. Mají rukavice, takže když už nějaké otisky pomatlají, tak alespoň nezanechají svoje. Jestli chcete naložit tlouštíkovo tělo na nosítka, uděláte mu nejspíš nějaké otlaky.

Taky si uvědomte, že na místě činu už nejspíš předtím docela dlouho působili uživatelé, ještě než si sami uvědomili, že se možná něco děje.

Nástroje pro sběr volatile forensic data

Na internetu se dá stáhnout hromada různých nástrojů. Polovina z nich vypadá, jako že se jedná o samotné hekovače, screenshoty jako z keygenu. Druhá polovina funguje jenom na některých typech systémů. Další polovina vyžaduje instalaci Oracle databáze. Osmdesát procent z nich není ani digitálně podepsáno. Devadesát procent z nich nesbírá to všechno, co bych si já představoval. A u sto procent z nich nevíte vůbec, co dělají a jak fungují.

To se vám u mého forensního PowerShell nástroje nestane. Máte celý jeho zdroják. Který je digitálně podepsaný a obsahuje log SHA1, MD5 heší všech svých součástí. Pokud máte PowerShell 3.0 a novější, počítá i SHA256 heše. Používá jenom PowerShell, WMI a zabudované Windows nástroje. Navíc používá tři utilitky přímo od firmy Microsoft, také digitálně podepsané a 100% zdokumentované. Běží všude, kde máte alespoň PowerShell 2.0. Což je dneska už skoro všude.

Pokud budou pochybnosti o jeho chování, umím vysvětlit každé písmeno jeho kódu.

Program vygeneruje sadu textových a CSV souborů, ve kterých jsou výstupy rozličných WMI tabulek a výstupy Windows programů, jako je třeba netsh. Program ze systému pouze čte. Zapisuje pouze do svého výstupního adresáře.

Pokud si o to řeknete, provede pomocí procdump programu (od Microsoftu, staženo ze SysInternals) dump paměti všech procesů. Výstupy také uloží do svého výstupního adresáře. Umí také spustit autorunsc a posbírat i jeho textový výstup - to ale není už moc prchavý stav. Autoruns se dá zjistit kompletně i z offline imidže.

Nakonec celý obsah výstupu znovu přepočítá na SHA1, MD5 a případně SHA256. Soudci chtějí vždycky slyšet, že jste všechno hešovali, protože tak se to má dělat. Jenom si neuvědomují, že to není ochrana proti záměrné změně.

Pokud se chcete pojistit proti záměrné změně, můžete si zadat také heslo, které znáte jenom vy. Program vám všechen inventář podepíše HMAC-SHA256. Takže jenom vy, pokud budete znát heslo, si můžete ověřit pravost těch signatur.

Jediná modifikace

Skript umí, na požádání, také změnit jedno nastavení v registru (ClearPageFileAtShutdown). To říká, jestli se bude při vypínání mazat pagefile. Smazat ho ideálně nechcete, protože může obsahovat zajímavé informace o obsahu pamětí různých procesů.

Skript to udělá jenom když ho o to požádáte. Navíc v každém případě dopředu zaudituje předchozí stav té registrové hodnoty.

Jak takový software do počítače přinesete a jak potom odnesete výsledky?

Nastává otázka, jak tenhle nástroj do důkazního počítače (evidence computer) dostat. Jak už jsem říkal, všechny programy, nebo hardware na fyzický dump RAM paměti, tam budete muset nějak dostat. Pokud je tam tedy vůbec dostávat chcete. I když ty programy spustíte z příkazové řádky ručně, zanecháte něco navíc v systému. I když tam budete přistupovat vzdáleně přes síť tam něco zanecháte.

Pokud už budu vnášet například USB flash do scény, měl bych dodržovat následující:

  • médium zakoupené pouze pro tento případ, u kterého známe přesně jeho dlouhodobé uložení, pokud bylo ve skladu
  • čistě naformátované medium, přejeté ideálně sdelete tak, aby nemohlo obsahovat žádné nežádoucí a falešné důkazy
    • k tomu mám v nástroji rovnou baťáček sdelete-free-space.bat
  • kopie mého nástroje, která je digitálně podepsaná a ohešovaná
  • do papírového protokolu zapíšete čas příchodu na místo a čas začátku sběru prchavých dat
    • hodiny počítače se mohou lišit, možná i záměrně
  • na všechno si seženete svědka, který to bude celou dobu sledovat s vámi
  • ideálně to točíte na kameru a fotíte jako zběsilí
  • zastrčíte do volného USB portu, určitě nic jiného nevytahujete
  • spustíte volatile-forensics.bat. Nezapomenete ho spustit s právy administrátora, pokud to jde. Pokud nejde, zase až tak se moc neděje. Nepůjde zjistit seznam SMB spojení a nepojedou dumpy paměti.
  • může se stát, že ani tento volatile-forensics.bat nepůjde spustit, protože PowerShell execution policy to blokuje na úrovni group policy. Schválně jsem skript udělal tak, že můžete jeho obsah komplet na Ctrl-A, Ctrl-C, right-click překopírovat (copy/paste) do spuštěného okna PowerShellu
    • pokud script spouštíte tímto způsobem (copy/paste), ujistěte se, že aktuální adresář v příkazovém řádku PowerShellu je nastaven opět na tu USB flashku
  • zaznamenejte si do papírového protokolu všechny odpovědi na otázky, které vám skript kladl
  • výstupní soubory se objeví v Out podadresáři aktuálního adresáře. Tedy ideálně opět na USB klíčence. Bez zásahu do harddisku důkazního počítače.
  • jakmile program skončí, zeptá se vás na heslo pro HMAC-SHA256, které si zapamatujte. Svědek ho znát nemusí, spíše by ani neměl.
  • až program úplně skončí, dejte vypnout důkazní stroj (evidence machine) a nechte všechno tak jak je. Včetně vaší flash USB klíčenky.
  • až se všechno vypne, zaprotokolujte a posbírejte všechny počítače a související věci jako důkazy. Včetně vaší forensní USB pen klíčenky. To je teď taky důkaz.

O USB disk takto vlastně přicházíte. Budete ho muset nechat jako součást důkazů. Budete ho také muset předat protistraně, která má právo vidět všechny důkazy a udělat si na ně svoje vlastní posudky. Takže i z vaší klíčenky budete normálně dělat sektorový imidž (sector-by-sector image, bitwise image). A pracovat budete teprve s tímto imidžem.

Všechno je k dispozici zde ve formě ZIP a také ve formě jednotlivých souborů.

říjen 24
Výkonová charakteristika Group Policy

Já rád dělám hodně Group Policy Objectů (GPO). Každý obsahuje jen maličko nastavení. Jmenují se přesně podle toho, co dělají. Viz. přiložený obrázek - v tomto pokusu jich bylo 63, z toho některé mají zapnuté Enforce. V mnoha z nich je jen jedna hodnota. Na několika z nich je dokonce WMI filter. V některých používám Group Policy Preferences. Prostě klasický mix všehochuti.

Ano, jsou to jenom testovací GPO. Normálně jich udělám tak čtyřikrát tolik :-) Navíc já nevypínám tu druhou část - většina těch objeků má nastavení v Computer Configuration, ale přitom má "zapnutou" i část User Configuration. Uživatelská část je ale prázdná. Ano, mohl bych ji vypnout, abych systému přímo naznačil, že se do uživatelské části nemá vůbec dívat. Ale pro pokus jsem to neudělal.

Už jsem několikrát slyšel, že to je tragicky špatně a jsem "prase". Nejsem. To je asi tak špatně, jako že mě se líbí černá auta a někomu se líbí červená.

Podívejme se, jaký to má dopad na různé výkony.

Velikost SYSVOL

Sysvol žere ve skutečných datech 168 kB. Na disku to ale spotřebovává 788 kB, protože je to hodně souborů a každý se musí zarovnat na celý cluster. Souborů a adresářů je to 699.

Zjevně je to malinký objem, ale hrozba číhá v počtu souborů a adresářů. Jejich stahování na stanice je velice závislé na RTT (round-trip-time) mezi klientem a DC. Takže strach o výkon je zde jistě oprávněný. Otázka je, jestli je opodstatněný.

Testování GPUPDATE

Předně si uveďme, jak to budu testovat. Pro DC i stanici jsem si nastavil jen jedno CPU, abych jednodušeji zachytil jejich spotřebu. Oba dva mají dosta RAM paměti na to, aby se jim tam všechno v pohodě vešlo. Síť má RTT sub-milisecond, takže blesk. To nevadí, změříme počet a přepočítáme to.

Podstatné je, že na stanici spouštím jenom gpupdate bez parametrů. Nepoužívám parametr /force. Parametr force je na řešení potíží a vyvolá kompletní novou reaplikaci všech objektů. To se ale za normálních podmínek neděje. Klienti si stahují každý GPO jen jednou. Pokud se jeho obsah nezměnil od poslední aplikace, už to znovu neaplikují.

Klienti poznávají novinky podle verze GPO v LDAP a v SYSVOL. To je info, které normálně vidíte v GPMC konzoli na záložce Details.

Takže pomocí gpupdate bez parametrů simuluji to, co dělají všechny počítače v síti každých cca 2 hodiny.

Klient je Windows 8, Windows 2008 R2 a Windows 2003 bez GP preferences klienta. Řadič domény DC byl Windows 2012 R2. Každé CPU jádro bylo Intel Core i5 750 2.67 GHz.

Spotřeba CPU na stanici a DC

Změřil jsem CPU na stanici. Vylétlo to na chviličku na 100%, což se dalo čekat, mám jenom jeden procesor. Celá akce trvala cca 5 sekund. Normálně to samozřejmě běží na pozadí a uživatel o tom vůbec neví. Tady máte obrázek, samozřejmě jsem to měřil vícekrát na všech třech klientských operačních systémech.

Na Windows 2003 bez preferencí to dalo ve špičce 50% CPU a trvalo to jenom 3 sekundy.

Na řadiči domény to vzalo ve špičce dokonce jenom 5% CPU. Je to moc?

Řekněme, že ta špička 5 % je po dobu 1 sekundy. Kolik bych musel mít stanic, aby to udělalo trvalých 5% jednoho CPU na DC? Každý klient si aktualizuje politiku každé dvě hodiny. Rozloží se to řekněme rovnoměrně.

Trvale by znamenalo 3600 gpupdate během hodiny. Za hodinu se aktualizuje polovina stanic. Takže cca 7200 stanic by vytížilo jedno jádro CPU jednoho DC na 5% trvale. Začíná mi to rvát žíly.

Síťové charakteristiky

Obrázek zachycuje projev na síti v průběhu gpupdate.

Maximální hodnota byla 122 kB/s, takže cca 1 Mbps. Průměrně bych to odhadl na 800 kbps. Tentokrát bez výraznější špičky, po celou dobu aplikace, oněch 5 sekund.

Jak to vypadá s celou zátěží síťovky jednoho DC? Trvalý stah 800 kbps by během hodiny udělalo 720 stanic, to je tedy 1440 stanic v síti při dvouhodinovém gpupdate. Abyste dali tomu jednomu DCčku trvale alespoň 10 Mbps, museli byste mít 18 000 stanic.

Projev delšího RTT na pomalých pobočkových linkách

Co když je klient připojen přes pomalou (velká latency, tedy dlouhý RTT) linku z nějaké pobočky a nemá tam DC? Na síti to bude znamenat delší prodlevy mezi jednotlivými pakety. Tím se prodlouží čas aplikace. Ale úměrně tomu klesne špičková zátěž CPU a spotřeba linky v šířce pásma (bandwidth).

Závěr?

Abyste jedno jedinné DC zatěžovali při těchto mých 63 GPO objektech trvale na 5% jedinného jádra CPU a dávali mu trvale 4 Mbps, museli byste mít 7200 stanic.

Kamón.

1 - 14Next
>
 

 Rychlovky lepší než tvítr

 
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!
12.11.2014 10:16
pekelná chyba: https://technet.microsoft.com/library/security/ms14-066
5.11.2014 19:59
tohle moc lidí nezná - průzkumník - nějaký soubor nebo složka - shift+pravé tlačítko - Copy as path
1.11.2014 14:06
Jankova dnesni hlaska - a co to jako bude za slavu, ze si musim vzit tyhle hezci teplaky?
30.10.2014 20:18
Po pekelne hejtickem dnu na pivu s Pepou Dvorakem. Teda bavi se s zenskejma a ne se mnou :-)
27.10.2014 7:43
Ctyri sojky u vrsovickeho nadrazi!
25.10.2014 9:56
zajimalo by me, proc ma Java zapotrebi vsude otravovat s tim podivnym Ask toolbarem?
23.10.2014 17:30
Bratr mel pravdu, plisnove syry maji projimave ucinky
17.10.2014 18:19
CHFI: Computer Hacking Forensic Investigator!!!
17.10.2014 12:59
zdá se, že na jakémkoliv telefonu jde zjistit IMEI zavoláním na *#06# to je zajímavé.
17.10.2014 12:56
dnešní fyzikální okénko: http://palkovsky.blog.idnes.cz/c/196273/Rychlosti-se-nescitaji.html
14.10.2014 22:01
tak soft restart na Windows 10 server asi nefunguje - nebo to chce nejakou hw podporu?
13.10.2014 18:58
Prave jsem dostal na googlu kapcu "debil".