Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > default
květen 03
Nakládání s platebními kartami na portále alza.cz a CSOB

Abychom tu pořád neřešili jenom Office365, tak se pro změnu podívejme na ne zrovna košér nakládání s informacemi o platebních kartách na portále alza.cz, nebo možná na platebnibrana.csob.cz? Dneska jsem zůstal poněkud koukat na to, jak se mi z ničehož nic sama zaplatila objednávka, aniž jsem musel něco vůbec potvrzovat.

Nejprve bych rád uvedl, že alza.cz mám fakt rád. Jsou maximum rychlí, mají maximum výdejních míst otevřených i o víkendu, minulý týden jsem zíral na dokonalost AlzaBox, maximum ochota při reklamacích, žádné problémy s vracením zboží. Prostě něco, co se tady nevidí, cca o jedno století napřed.

Z technického pohledu mají pěkně udělané TLS šifrované HTTPS připojení, mají TLS 1.2, zelený certifikát (EV), všechno dovedeno k dokonalosti. Akorát s těmi kartami to teď už trošku přetáhli.

O co šlo? Nedávno jsem platil něco kartou. Bylo to poprvé, co se platilo viditelně přímo přes alza.cz. Po letech přeskakování mezi platebními portály se (ale jen na první pohled) stali už sami skutečným platebním portálem. To by znamenalo, že zadáváte číslo karty, expiraci i CVV přímo do jejich webové stránky. Dříve to fungovalo stejně jako na jiných webech, kde vás obchodník (třeba České dráhy, nebo dříve Alza) přesměruje na cizí platební portál/bránu (něco jako gbwebpay, paysec, gopay, nebo 3dsecure.csas.cz) a po zaplacení vás to zase vrátí zpátky k obchodníkovi.

U platebních portálů jsem měl vždycky lepší pocit, že si neukládají údaje o mojí platební kartě. Sice to občas nabízejí na zaškrtávátko, ale ve výchozím stavu není nikdy zapnuto, já si ty stránky obvykle poměrně podrobně prohlížím.

Proč nechci, aby si platební portál pamatoval moji kartu?

Řeknete si, že je to přece všechno bezpečné, když adresa je celá zelená a komunikace je zabezpečená. Komunikace ano. V okamžiku transakce. Ale každá online služba má vždycky riziko útoku. Jaká je záruka, že tu platební bránu někdo nenapadne a údaje karet tím nezíská? Klidně za pár měsíců nebo let? Když si nic nepamatuje, není co ukrást.

Už jednou se mi stalo, že si někdo na moji kartu koupil letenku do mexika za 110 000,- Kč. Naštěstí mi to banka (RB velká pochvala :-)) vrátila. Ale byly to nervy.

Nová Alza platební brána? Jen na oko

Alza se nově stala sama platební bránou. Alespoň to tak na první pohled vypadá, protože platební formulář máte přímo v okně s adresou alza.cz. Nikam vás viditelně nepřesměrovávají a rovnou zadáváte údaje karty do jejich vlastní webové stránky. S tím já problém nemám, komunikaci mají perfektně zabezpečenou:

Dokonce nahoře píšou Bezpečná online platba :-) Dobře si prohlédněte formulář. O ukládání údajů karty ani zmínka. Ani zmínka o tom, že se ve skutečnosti jedná o formulář z adresy https://platebnibrana.csob.cz. Tento fakt však dokáže odhalit jen oko zkušeného uživatele F12 Developer Toolbar v IE :-) Fakt je, že data karty byla ve skutečnosti odeslána POST na csob.cz a nikoliv do alza.cz.

Moje karta má zapnutu technologii 3dsecure, což má být druhý faktor ověření platby. Znamená to, že musím platby potvrzovat přímo na portále své banky pomocí SMS na zaregistrované číslo mobilního telefonu. Vím že zahraniční weby většinou 3dsecure nevyžadují, ale tam také neplatím touto kartou. K podivným platbám mám samozřejmě blesk peněženku.

I v případě Alzy jsem byl přesměrován na 3dsecure stránku RB banky a pocit bezpečí byl dokonán:

Následně mě to vrátilo do webové stránky alza.cz, kde jsem si přečetl informaci o doručení zboží a už jsem si moc nevšímal velkého zeleného obdélníku s hrozivou informací...

Další platba už byla překvapivě snadná

Dnes jsem se vypravil zaplatit nějakou další blbinu za cca 400,- Kč. Kliknu na platbu a překvapí mě, že vidím předvybrané číslo své platební karty:

Sice překvapen, nepřikládal jsem tomu přílišnou váhu, protože číslo karty samotné jsem považoval za nepodstatnou informaci. Číslo karty necháváte kudy chodíte. Mám tam přece 3dsecure SMS.

Ale ouha. Ono to šlo až moc jednoduše:

Bez ptaní, bez CVV, bez SMS, bez problémů a hladce. A sakra. Já jsem přece nikdy nikde neautorizoval uložení údajů karty!!!

Jak je to možné?

První podezření samozřejmě padlo přímo na Alza. Platíte na pohled kompletně přes jejich webovou stránku. Šel jsem se tedy podívat do svého Nastavení účtu a v sekci Platební karty pro nákupy byla moje karta. Žádné údaje nejsou přímo vidět, ale to nic neznamená.

Odpověď na přímý dotaz zněla takto:

Čísla karet u nás nejsou nikde ukládána.
Pokud Jste u nás platil kartou, tak je možné kliknou na zapamatovat kartu. Pokud máte povolený recuring (opakování plateb), tak je pak platba již automatická. Musel jste tedy zadat " zapamatovat kartu " 

Což není pravda, protože jsem nikde nic nepotvrzoval.

Ale po menším průzkumu věřím tvrzení, že čísla karet nejsou u nich zaznamenávána. Formulář s údaji karty jsem ve skutečnosti odesílal do ČSOB, takže Alza si skutečně číslo karty asi pamatovat nemusí.

Pokud zkusíte v té stejné sekci Platební karty pro nákupy přidat další kartu (tentokrát to děláte na vlastní žádost), opět ve skutečnosti zadáváte údaje karty pomocí POST požadavku přímo na https://platebnibrana.csob.cz.

No a v tom je celé kouzlo. Alza je jako z obliga. Údajně si nic nepamatují. Myjí si ruce, protože všechny údaje si pamatuje ČSOB platební portál.

To ale není pravda. Musí si pamatovat nějaký identifikátor, který páruje moji uloženou kartu do ČSOB. Takže rozdíl mezi tím, jestli si pamatují přímo kartu, nebo stačí do platebnibrana.csob.cz poslat nějakou kůkinu je podle mě nulový.

Rekurentní platby a 3dsecure

Takže jsem volal do své RB banky, aby mi řekli, jak je možné, že to po mě nechtělo 3dsecure a co znamenají ty údajné recuring (opakované) platby.

Na infolince paní přesně věděla, že to byla platba od alza.cz. O ČSOB platebním portálu ani slovo.

Na dotaz, proč to nechtělo 3dsecure byla odpověď, že jsme už jednou u toho obchodníka zaplatil a on si "kartu zapamatoval", takže 3dsecure už podruhé není potřeba.

Na otázku, jak je možné, že se to považuje za opakovanou platbu, když jsem platil úplně jiné zboží, za jinou cenu, byla odpověď, že když si obchodník pamatuje kartu, tak to proběhne samo.

Na otázku, jestli je možné tyto opakované platby nějak vypnout, byla odpověď že ne. Pouze je možné úplně vypnout veškeré elektronické platby :-)

Celkové shrnutí

Alza nabízí platby kartou sice přes platebnibrana.csob.cz, ale zobrazuje to na své webové stránce pod svým URI. Platební portál si bez diskuze zapamatuje údaje karty pro opakované použití bez 3dsecure. Alza si zapamatuje něco, čím vyvolá kdykoliv přes platebnibrana.csob.cz jakoukoliv platbu.

Tohle jednání se mi nelíbí

Zaprvé se údaje karty uloží i bez explicitního vyžádání, prostě při platbě.

Zadruhé se uloží u třetí společnosti platebnibrana.csob.cz a nikoliv na webu, u kterého se to tváří, že to zadáváte.

Zatřetí, kde je jistota, že při požadavku na odstranění karty přes webové rozhraní alza.cz dojde ke smazání údajů karty na platebnibrana.csob.cz?

Začtvrté, co se asi stane, až alza.cz někdo napadne a bude mít v ruce všechny ty identifikátory karet do platebnibrana.csob.cz?

Co se stane, až někdo napadne platebnibrana.csob.cz a ukradne údaje karet, které se tam automaticky ukládají?

Co se asi stane, až někdo uhádne někomu heslo k alza.cz účtu, ve kterém je uložen identifikátor karty? Až dosud nebylo přece podstatné mít moc silné heslo. To že se někdo podívá na moje starší objednávky nejsou trable. Trable začínají, až si může bez autorizace objednat na alza.cz zboží a jít si ho vyzvednout do AlzaBox v kapuci.

To budu zase já čekat s nervem, jestli mi ty peníze vrátí?

Takhle ne, děcka!

květen 02
Kolosální chyba Office365 není vlastně až tak kolosální

Dneska jsem dostal info o tomhle článku dokonce několikrát: http://www.root.cz/clanky/postrehy-z-bezpecnosti-kolosalni-chyba-microsoftu. Na první pohled se to zdá být jasně princpiální úder na bezpečnost služby Office365. Ale není.

Mě samozřejmě nemůže nikdo obvinit, že bych tady chtěl propagovat Office365 z bezpečnostního pohledu. Systém "dejme všechna firemní data do ruky neomezenému počtu indů" mě osobně nevyhovuje. Ale v tomhle případě o to nejde.

Na první pohled to vypadá, že to je díra, která ovlivnila "všechny" společnosti, a z toho má plynout ona kolosálnost. Ale ta tam ve skutečnosti není. Bezpečnostní díry se vyskytují všude a vždy. Tenhle incident je potřeba brát z pohledu každého konkrétního zákazníka. Z pohledu hackera je to samozřejmě paráda, dostat se díky jedné díře k datům více společností. Ale ne z pohledu samotné firmy, která má v Office365 data. Každé jedné firmě může být jedno, že hacker ukradne data i ostatním firmám.

Pro jednoho každého zákazníka to nepřináší větší rizika, než mít svoje data přístupná ve své síti, při stejném zabezpečení vzdáleného přístupu.

Pokud to řekneme zobecněně, tak tady byla využita chyba v technologii ověřování uživatelských účtů. Šlo o přístup z internetu na data společnosti a ověřování mělo chybu. Jednalo se o jedno-faktorové ověření heslem. Technologie ověřování byla pouze jedna (SAML). Stačila tudíž jediná díra k tomu, aby se účtočník dostal na data.

Stejná rizika by měla firma, kdyby měla data u sebe doma a umožňovala k nim přístup s jedno-faktorovým ověřením z internetu přes jedinou ověřovací technologii. Ne?

Proto se taky dělají vícevrstvé ochrany a multi-faktorové autentizace. Například nejprve VPN a teprve potom web, ještě třeba přes reverzní HTTPS proxy. Nebo nejprve RD gateway (opět třeba přes HTTPS proxy) a teprve potom RDP. Protože každá tahle technologie ověřuje uživatele jinak, minimalizuje se tím prostor pro útok. Aby se to povedlo, chyba by musela být ve více technologiích současně.

Pokud navíc tyto vrstvy vyžadují multi-faktorovou autentizaci, opět je o polovinu menší pravděpodobnost incidentu.

duben 25
Expirace účtu a platnost Kerberos tiketů

Mám tu za poslední dobu několik článečků, které se týkají zneplatnění účtů, dočasného členství ve skupinách a vůbec změny a aktualizace členství ve skupinách a zrovna se vynořila zajímavá otázka ohledně zneplatnění účtu. Tak tady je odpověď.

O co jde? Na účtu v Active Directory si můžete nastavit jeho expiraci - tabulka Account, políčko Account expires dole. Datum a čas, který nastavíte v GUI je sice k půlnoci, ale tahle hodnota se uloží do atributu accountExpires a tam by se případně dala nastavit expirace k jakémukoliv času přesněji.

Co když si uživatel vyžádá Kerberos ticket ještě krátkou dobu před expirací účtu? Bude platit celou standardní dobu (ve výchozím stavu 10 hodin), tzn. ještě přes okamžik expirace účtu? Nebo bude platit jen přesně do konce platnosti účtu?

A odpověď je.....

Že platnost ticketů je maximálně přesně do okamžiku vypršení. Takže ticket (jak TGT, tak i TGS z něho odvozené) bude platit maximálně tak dlouho, jako platí daný účet.

Howgh. Ověřeno právě na DFL/FFL 2003.

Znovu upozorňuji, že stejně jako v případě zákazu účtu, tak ani ukončení ticketů nemusí znamenat ukončení práce, viz. článečky nahoře v odkazech.

duben 23
Windows 2016 a expirující doménové skupiny které jsou tu už od Windows 2003

Na letošní konferenci ShowIT 2016 jsem ukazoval novinku ve Windows 2016 a znovu to budu ukazovat na nemilosrdně se blížím TechEdu. A protože je už vyprodáno, tak to berte pro některé jako malou ochutnávečku a pro ostatní jako možnost přečíst si něco, co neuslyšíte :-)

Je to taková malinká příjemná novinečka ve Windows 2016 Active Directory, která může mít velký dosah a přitom tam je ve své podstatě už od Windows 2003, akorát se o tom až do teď skoro nevědělo (tedy pokud jste nebyli na mém GOC171).

Vo co gou? Dočasné členství v AD skupinách, lépe řečeno přímé dočasné členství, neboli nejpřesněji expirující linky. Členství ve skupinách můžete přidělovat jen na omezený čas.

Prostě při forest functional level 2016 (FFL 2016) můžete začít používat tzv. optional feature (podobně jako je AD recycle bin) nazvanou Privileged Access Management Feature (zapíná se opět pomocí Enable-AdOptionalFeature).

Znamená to, že AD umí nastavit na link-cích expiraci a umí tedy po nějaké době dané linky smazat z databáze. Potřebujete k tomu FFL 2016, protože je to obecná nová funkce celé databáze, tedy forestu. Členství ve skupinách funguje tak, že skupiny (group) pomocí svého link atributu member odkazují na svoje členy. Nově se na ty linky dá nastavit expirace (hodnota TTL - time to live), takže je AD po nějaké době odstraní.

Něco podobného šlo už od forest functional level 2003 od kdy je možné nastavit TTL pro objekty (object). Tedy nikoliv linky. Takže AD umí už dlouho automaticky expirující objekty, nově umí i linky. Nazývalo se to dynamické objekty (dynamic object), dnes přibyly dynamické linky (dynamic link).

Rychle dva cmdlety pro zadávání dočasného členství ve skupinách - detaily už si každý dogůgluje (klíčová slova - privileged access management PAM, dynamic groups, dynamic links etc.):

Enable-AdOptionalFeature -Identity 'Privileged Access Management Feature' -Scope ForestOrConfigurationSet -Target gopas.virtual
Add-ADGroupMember -MemberTimeToLive

Pro geeky používající LDP:

LDAP_SERVER_LINK_TTL_OID 1.2.840.113556.1.4.2309

Dočasné členství ve skupinách postaru (FFL 2003 až 2012)

Už za použití těch původních dynamických objektů (dynamic object) šlo zařídit dočasné členství ve skupinách už při FFL 2003. Museli jste ale vytvořit dočasnou mezi-skupinu, kterou AD časem odstranilo a tak jste vlastně vypadli i ze skupiny skutečné. Viz. následující obrázek:

Skutečná skupina je nahoře. Skutečný účet (nebo další skupina) je dole. Mezi tím je dočasná skupina s omezenou životností TTL. Šipky zachycují linked atribut member. Jakmile AD tu meziskupinu odstraní, účet najednou už není členem té horní skutečné skupiny.

Pokud jste tohle chtěli používat na FFL 2003, tak jste museli vytvořit pokaždé novou expirující dočasnou skupinu (s novým SIDem), vložit do ní toho spodního člena a tuto dočasnou skupinu vložit do vámi požadované horní skupiny.

Mám k tomu demonstrační skript, tak kdyby to něhoko zajímalo - natvrdo tomu novému objektu skupiny nastavíte atribut objectClass na dynamicObject. Divné co? A potom už jenom nastavíte jeho atribut entryTTL na hodnotu expirace v minutách. Nepohodlné a navíc to spotřebovává SIDy.

$ou = [ADSI] 'LDAP://OU=Company,DC=gopas,DC=virtual'
$user = [ADSI] 'LDAP://CN=Kamil,OU=People,OU=Company,DC=gopas,DC=virtual'
[int] $ttl = 20

$baseGroup = $ou.Create('group', 'CN=IS Access')
$baseGroup.Put('sAMAccountName', 'IS Access')
$baseGroup.SetInfo()

$expiringGroup = $ou.Create('group', "CN=IS Access Expiring in $ttl minutes")
$expiringGroup.PutEx(2, 'objectClass', @('dynamicObject', 'group'))
$expiringGroup.Put('entryTTL', ($ttl * 60))
$expiringGroup.Put('sAMAccountName', "IS Access Expiring in $ttl minutes")
$expiringGroup.SetInfo()

$baseGroup.Add($expiringGroup.Path)
$expiringGroup.Add($user.Path)

Poznámka: na CN=Directory Services,CN=Windows NT,CN=Services,CN=Configuration je atribut ms-DS-Other-Settings s hodnotou DynamicObjectMinTTLSeconds který určuje minimální hodnotu TTL, kterou bude AD uplatňovat. Pokud na entryTTL nastavíte hodnotu menší (což jde), tak se prostě objet smaže až později, nejméně po té minimální hodnotě TTL. Menší hodnota než 5 minut jde sice nastavit, ale kratší životnost to nebude mít nikdy. Což nejspíš ani nepotřebujete.

Hlavní výhoda nové metody Privileged Access Management (PAM) ve Windows 2016

Hlavní výhoda PAM feature ve Windows 2016 je ale jinde. Jde o aktualizaci členství ve skupinách (viz. nějaké moje starší články). Problém je s Kerberos TGT a TGS tickety. Tickety mají platnost ve výchozím stavu až 10 hodin. Takže členství ve skupinách se po tuto dobu nebude měnit zaručeně. Bez ohledu na to, jestli už vlastně neexistuje. Samozřejmě jde platnost TGT a TGS tiketů omezit pomocí group policy, ale to třeba někdo nechce, zvyšuje to zátěž apod.

Jakmile máte ale PAM, tak se změní chování KDC (Kerberos Key Distribution Center, neboli Kerberos Domain Controller). Jestli jste členem nějaké skupiny jen dočasně, tak vám prostě KDC vydá kratší TGT nebo TGS, které platí jen do konce zbytku vašeho členství (to nejkratší, které máte). Takže nejpozději jakmile členství vyprší, současně už přestanou platit vaše TGT a TGS tikety a musíte si vydat nové, což znamená, že se znovu zkontroluje členství  ve skupinách.

Pěkné ne?

Poznámka: proč tady zmiňuji TGT i TGS je proto, že TGT obsahuje pouze global skupiny z vaší domény a universal skupiny z celého forestu, zatímco TGS potom obsahuje ještě i domain local skupiny z resource domény (trusting domain, outgoing trust).

duben 20
Podivná volba Enable Certificate Privacy při exportování certifikátu ve Windows 10

Guru Altair se mě zeptal, co znamená volba Enable certificate privacy, kterou byste našli ve Windows 10 v okamžiku, kdy se snažíte exportovat certifikát i s privátním klíčem do PFX souboru (PKCS#12). Dřív to tam nebylo. A protože jsem chtěl Koňovi udělat radost, tak jsem to taky dnes zjistil.

Následují obrázky z certificate export průvodce, nová volba Enable certificate privacy je vidět na druhém z nich:

První tabulka se vůbec nezměnila. Na poslední tabulce už ve Windows 8 a Windows 2012 přibyla volba Group or user names (aka group protected pfx), kdy nemusíte zadávat heslo a přitom se k tomu souboru dostanou členové vyjmenovaných skupin - vyžaduje to domain functional level (DFL 2012) a rozjetý KDS (key distribution service) atd. Ale to už tam bylo, to teď řešit nebudeme, jenom jsem si sem musel hodit link na starší článek :-)

Takže vo co gou?

PFX soubory jsou od jakživa zašifrované, aby se soukromý klíč (private key) jenom tak někde nepovaloval. Pokud vyexportuju PFX ještě na Windows 8.1, tak je celý komplet zašifrovaný. Pokud se do tohoto staršího exportu podívate nějakým hex editorem, tak uvidíte velmi entropickou břečku od začátku až do konce. Není vidět ani obsah certifikátu.

Můžete na to zkusit spustit certutil a on bude chtít okamžitě heslo, aniž by cokoliv dokázal zobrazit:

certutil -v konikuvprivat.pfx

Což je zajímavé, protože obsah certifikátů se obecně považuje za totálně veřejný a žádné systémy mu nepřikládají žádnou zvláštní ochranu, jako že by se to snažili nějak chránit proti kopírování nebo rozlézání po síti. Jediné co je potřeba chránit obvykle je privátní klíč.

A mě tohle kompletní zašifrování od jakživa docela vadilo, protože jste se bez hesla nemohli podívat, co to je za certifikát, i když jste ho nechtěli rovnou importovat.

Nové chování exportu ve Windows 10

Jak jsem zjistil, chování exportu ve Windows 10 se změnilo následovně. Pokud tu volbu Enable certificate privacy necháte vypnutou (výchozí stav), tak se nově nešifruje celý obsah pfx souboru, ale pouze soukromý klíč. Takže při použití hex editoru uvidíte textové části certifikátu normálně čitelně a certutil nevyžaduje heslo na to, aby zobrazil pěkně obsah certifikátu uvnitř pfx souboru.

Takže pohodlné vylepšení.

Aby to nebylo někomu líto, pokud si chce přecejenom chránit i obsah certifikátu, tak není problém. Od toho je tam ta volba Enable certificate privacy. Pokud ji zapnete, zašifruje se celý pfx soubor včetně veřejné části certifikátu. A je to tedy stejné, jako když jste exportovali pfx z Windows 8.1 a starších.

Kompatibilita

Obě formy exportu, jak nová forma bez certificate privacy, tak i stará forma při zapnutém certificate privacy se dá v pohodě naimportovat i do Windows 7, jak jsem ověřil.

Tolik keců kvůli takové blbosti ...

... ale snad bude mít Koník radost :-)

duben 19
Hesla pro RDP WebApp v paměti stanice i na Windows 10

Toho jste si předpokládám všimli. Připojíte se poprvé na první RDP RemoteApp a zadáváte heslo (pokud nemáte třeba RDP SSO jako tady). Buď přímo do RDP klienta mstsc, nebo přes webový prohlížeč do RD Web sajtny.

To už samo o sobě indikuje, že se v případě RDP jedná vždycky (kromě případu RestrictedAdmin režimu) o basic authentication. Myslím tím prostě tu nejjednodušší možnou autentizaci, kdy posíláte do vzdáleného serveru plné textové heslo. Žádné drama, pokud s tím počítáte.

Ovšem v případě RemoteApp jste si mohli všimnout, že při připojování na každou další vzdálenou aplikaci už heslo nemusíte znovu zadávat. Dokonce ho nemusíte zadávat ani podruhé, pokud se přihlásíte nejprve do RD Web rozhraní.

Není to divné? Jak dokáže RD Web rozhraní předat heslo z prohlížeče do mstsc klientského prográmku? Jak je možné, že při spuštění další aplikace, dokonce potom, co jste předchozí aplikaci úplně uzavřeli, dokonce potom co vás někdo na RD session host serveru totálně odhlásil (logoff)?

Tak pokud byste se takto zeptali, tak byste taky vcelku rychle našli důvod. V task manageru k tomu objevíte mrchu zvanou wksprt.exe. Jméno je prT vy vtipálci. A úplně na prd to není. Například, pokud byste podnikali analýzu nějakého bezpečnostního incidentu pomocí mého volatile forensics kitu, nebo jste prostě jenom parchanti, kteří chtějí někomu ukrást heslo.

On si ten wksprt program vaše heslo pamatuje v paměti. Neomezeně dlouho. A dává ho na požádání mstsc klientovi. Stačí udělat dump paměti, třeba pomocí procdump ze sysinternals, nebo přímo pomocí funkce BitColdKit-FindString z mého BitColdKitu.

Windows 8 a Windows 2012 a novější se na jedné straně srandovně snaží nepamatovat si vaše plnotextové heslo po interaktivním přihlášení v lsass (pokud nemáte právě zapnuté to RDP SSO aka credentials delegation), ale potom si ho prostě pamatuje wksprt a nikomu to nevadí.

Takže znovu opakuju. Pokud vám vaše stanice nepatří, tak cokoliv na ní děláte není vaše.

duben 08
Zakázat účet v AD neznamená, že to odpojí uživatele

Zrovna tu řeším jeden problém s přístupem do Exchange mailboxu uživatelů, jejichž účty byly zakázány v Active Directory. Zdá se, že pokud účet v AD zakážete, tak se ještě velmi dlouho dostane do svého mailboxu přes ActiveSync a kratší dobu i přes OWA - viz ofiko článeček tady a tady. Jak si v článcích přečtete, je to způsobeno různě rozjetými spojeními, která není jednoduché ukončit. Články k tomu doporučují postup, co máte udělat, aby se doba zkrátila na minimum.

Překvapilo vás to?

Překvapit vás to nemělo

Tohle je normální. U všech aplikací. U všech systémů. Například i ISO 27002 na to pamatuje a nutí vás, abyste si přesně zdokumentovali u všech služeb, jak se zbavíte uživatele potom, co ho tam už nechcete. Nikdo nikdy neřekl, že se všechno hned odpojí samo, když zakážete účet v AD.

Důvody a příklady

Základní fakta. Pokud zakážete účet v Active Directory (disable), tak AD LDAP, Kerberos a NTLM a Schannel nadále odmítá tento účet ověřovat. To je naprosto v pořádku.

Jenže kdy probíhá ověřování? Ověřování probíhá obvykle vždy jen na začátku "session". Pod pojmem "session" se myslí buď Ctrl-Alt-Del lokální přihlášení na obrazovku nebo přes RDP, nebo pokud se ustavuje TCP spojení do nějaké vzdálené služby. Potom už nejspíš nikdy, dokud se "neohlásíte". Odhlásit chápu jako ukončení TCP spojení, nebo totální logoff z obrazovky (ne jen odpojení RDP session).

Příklad je místní přihlášení nebo přihlášení na RDP. Pokud se někam připojíte na RDP nebe přihlásíte lokálně, tak vám v paměti vznikne access token (už jsem o tom tady několikrát psal třeba tady a tady). S tímto access tokenem můžete na daném počítači provozovat procesy jak dlouho chcete, bez ohledu na to, jestli vám někdo zakázal účet. Dokonce pokud máte přímo na tom stejném RDP serveru například sdílený adresář, nebo SQL server, tak ho můžete používat až do aleluja, i když to je "jakoby" přes síť. K žádnému dalšímu ověřování nedochází.

Do sítě se už asi moc nedostanete, protože by to znamenalo nahodit nové TCP spojení a to by se muselo znovu ověřit? Jenže co když máte TCP spojení už navázána. Například máte ve wordu otevřený nějaký soubor ze sdíleného adresáře? Nebo máte spuštěného nějakého GUI SQL klienta a ten je připojený ke své databázi? Protože je TCP spojení navázáno od doby, kdy jste se ještě mohli ověřit, vydrží vám to opět až do smrti.

Stejný příklad je VPN. Zakážete účet, takže se člověk už znovu nepřipojí. Ale co když si tu VPN nahodil už dříve a má ji prostě pořád vytočenou? Žádné další ověřování obvykle neprobíhá.

Webový prohlížeč do nějaké webové aplikace je další příklad. Prohlížeče obvykle zavírají TCP spojení při nečinnosti cca 1 minuta. Web server IIS například kešuje access tokeny (pro Basic ověření) ještě 15 minut po tom, co vám zmizelo TCP spojení. Aby se ušetřila rychlost přihlašování a nemuselo se kvůli tomu chodit na DC. Dobrá, to skoro vypadá, že v prohlížečích to moc dlouho nevydrží.

Omyl, pokud vám ta webová aplikace do pohlížeče podstrčí nějaký "keep-alive" skript, který tu stránku jednou za 30 sekund třeba refreshuje, nebo alespoň nějakou její část, TCP spojení vám v pohodě vydrží, aniž byste si to vlastně uvědomovali.

Kerberos je další krásný příklad, dokonce s přístupem do sítě při vzniku TCP spojení. Ve výchozím stavu vám Kerberos vydává tikety na platnost 10 hodin. Jakmile máte TGT tiket, tak se po celou dobu jeho platnosti nekontroluje stav vašeho účtu. Takže scénář - přihlásím se a vydám si TGT, následně mě admin zakáže účet, ale já můžu ještě dalších 10 hodin chodit po síti kamkoliv. A to platí i pro totálně nově vznikající TCP spojení a dokonce nové generování TGS tiketů. O tom jsem tu taky už psal.

Co máte tedy dělat?

Musíte si zdokumentovat všechny "služby", které uživatelé mohou používat, tak jak vás k tomu vede ISO norma. Službou se rozumí počítač, mobil, RDP, VPN, WiFi, Exchange mailboxy, cokoliv. U každé služby si musíte také zdokumentovat, jak její uživatele "ukončíte", pokud je to potřeba.

Takže jaký je rozdíl mezi tím, jestli po zákazu účtu může člověk ještě hodně hodin stahovat poštu. Oproti tomu, že mu účet zakážete a on je ještě několik týdnů připojený na váš RDP terminal server a normálně si vykrádá data zákazníků z informačního systému?

Rozdíl je jenom v tom, že u toho OWA je to poněkud nečekané, že zavřete prohlížeč a přitom se tam znovu dostanete. Na druhé straně mám zkušenost, že i na ten Kerberos lidé obvykle zírají vcelku dost překvapeně.

Takže dojděte na můj kurz ISO 27001 a 27002 a třeba se dozvíte i další věci :-)

duben 06
Konzole certifikátů místního počítače a matematický vtip

To je až neuvěřitelný, jakou může člověkovi udělat radost objev, o kterém by 99,999% lidí řeklo, že to se ten člověk musel snad zbláznit.

Konzole pro správu certifikátů

Od jakživa si můžete spouštět konzoli pro správu uživatelských certifikátů pomocí certmgr.msc (certificates - current user). Jenže to neumožňuje spravovat certifikáty počítače, které jsou přecejenom běžnější problém. Pokud jste chtěli spravovat certifikáty počítače (certificates - local computer), tak jste si tu konzoli Certificates museli přidat ručně do mmc konzole. Zbytečná otrava.

Dneska jsem objevil zázrak. Pánové přidali od Windows 8 a Windows 2012 rovnou konzoli certlm.msc, která je rovnou chycená na certifikáty lokálního počítače.

No luxus.

Pro ty co to nepochopili, je tady ještě jedna pěkná ukázka potěšení, které může něco způsobovat určité specializované skupině exotů

Matematickej vtip

Přijdou tři matematici do hospody, sednou si ke stolu a hospodský se ptá prvního - dáte si všichni pivo? První na to "nevím". Tak se hospodský zeptá druhého, jestli si všichni dají pivo. Druhý na to "nevím". Tak se zeptá třetího a ten na to "ano dáme".

PS: musel jsem čumět, že moje manželka to pochopila okamžitě a ještě se jí to navíc i líbilo. O tom certlm.msc jsem jí to neříkal, ale tam bych už byl poněkud skeptičtější :-) 

březen 29
Optimální řešení certifikátů pro RDP session farmu

Tak po mnoha laborováních a řešení problémů s certifikáty na několika RDP (Remote Desktop neboli Terminal Services) nasazeních Windows 2012/R2 jsem dospěl k tomuto optimálnímu řešení problému SSL/TLS certifikátů. Takže jestli se chcete stát RDP statkářem, (po americku farmářem) tak si to přečtěte, protože snad předejdete zbytečným problémům.

Problém certifikátů na Remote Desktop session host farmě

Obvykle máte AD doménu na nějakém vnitřním DNS jméně - jako já mám například testovací prostředí gopas.virtual:

Ve výchozím stavu jsou tedy jména všech RD session host serverů, stejně jako RD connection broker serverů vnitřní (něco jako RDBROKER1.gopas.virtual). Obykle ale potřebujeme také přístup z internetu a "podivných" zařízení, která nespravujeme centrálně, jako jsou mobily a tablety apod. případně od ne-doménových zákazníků páč dneska má každej kulak klaud.

Certifikát potřebujete jen pro RD web, RD gateway a RD connection broker. RD session hosti přežijí uživatelský přístup jen se svým výchozím, automaticky generovaným self-signed certifikátem, protože přístup na ně se ověřuje z RD connection broker. Ale taky ne vždycky (/admin přístup například).

Pro RD web a RD gateway logicky zvolíte ne-doménové veřejné jméno, například něco jako rd.gopas.cz, aby to bylo dostupné z internetu. Toto jméno si prostě zadáte do vnitřního i veřejného DNS ručně (podstatná informace o split-dns například i zde). Pro tyto stroje si také koupíte certifikát od veřejné autority a je to.

Jenže co s těmi ostatními mašinami. RD connection broker automaticky používá svoje vnitřní doménové jméno, dokud ho nepřepnete do high-available konfigurace. Jenže to každý nechce. High-available configuration vyžaduje SQL server a pokud ten nemáte taky vysoce dostupný, tak to nedává smysl (takže nějaký hustý Always On apod.). Přitom i s jedním RDP connection brokerem můžete mít krásně rozloženou zátěž mezi více RD session hostů.

Veřejné certifikační autority (certification authority - CA) vám certifikát pro vnitřní jména nevydají, nejpozději od ledna 2015. Ty byste si museli vydávat sami z vnitřní AD CS autority. Jenže to každý nechce řešit, podobně jako SQL always on pro high-available connection broker. Vaší vnitřní CA naopak nevěří zákazníci, nevěří tomu podivná zařízení apod.

Dobře, můžeme to tedy také rozjet na nějakých DNS aliasech, jenže to zase při vnitřním přístupu nebo KDS ztrácíme Kerberos ověření a vůbec jsou problémy se single-sign-on (SSO).

Elegantní řešení pomocí změny primárního DNS suffixu na serverech

Nejspíš o tom nevíte, ale počítače se ve skutečnostni mohou jmenovat úplně jinak, než se jmenuje jejich vnitřní Active Directory doména. Prostě jim změníte primary DNS suffix. Říká se tomu disjoint AD namespace.

A je to. Koupíte si rovnou jedinný certifikát od veřejné certifikační autority a použijete ho na všech serverech. Bude mít buď jméno s hvězdičkou (wildcard certificate), tedy *.gopas.cz. Hvězdičkové certifikáty jsou ale obvykle poněkud dražší, než certifikáty s několika jmény (subject alternative name, SAN). Takže můžete mít také certifikát s více jmény všech vašich serverů.

A jestli se později rozhodnete zavést high-available configuration pro RD connection broker, není problém, prostě přidáte to další jméno do nového certifikátu.

Takto jede i Kerberos, SSO a všechno je prostě na veřejných jménech, která jsou vlastně ale také vnitřní :-)

Nevýhody

Tak samozřejmě nic není zadarmo.

Máte malinký problém s dynamickou DNS registrací. Buď máte ve vnitřním DNS přímo celou tu veřejnou zónu - to ale zakrývá veřejné záznamy. Nebo si musíte pro každý server udělat ručně separátní zónu a záznam tam udělat ručně - A záznamy pro jméno zóny nelze dynamicky aktualizovat. Nebo uděláte ten DNS suffix na nějaké jiné veřejné doméně, která vám nebude nic zakrývat a přitom dostanete v pohodě certifikát od veřejné CA. Ještě existuje možnost veřejné domény třetího řádu (third-level domain), například servery.gopas.cz. Takže by se servery jmenovaly rdhost1.servery.gopas.cz. To veřejné autority umí vydávat, ale neplatí pro to wildcard certifikáty vyšší úrovně.

Potom samozřejmě může být problém s nějakými aplikacemi, které takovou konfiguraci nechápou. Ale z mé zkušenosti to je ok.

To jsou ale malinké problémy ve srovnání s tím, jak moc problémů je jinak s certifikáty.

březen 08
Zase další PowerShell kreténina

Ach jo. Prostě v PowerShellu nemůže nic jít jenom tak. Aneb jak nadefinovat uint32 konstantu:

0xC0000005
# result -1073741819, signed int (Int32 exactly)

[uint32]0xC0000005
# result exception: Cannot convert value "-1073741819" to type "System.UInt32". Error: "Value was either too large or too small for a UInt32."

0xC0000005L
# using the L suffix makes it 64bit signed!! int (Int64 actually)

# The solution
[System.Convert]::ToUInt32('0xC0000005', 16)

Nazdraví!

únor 05
Rizika spouštění PowerShell skriptů a jak je (ne)omezit plus úvahy o možnostech black-listingu

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

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

Jaké máte tedy možnosti?

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

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

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

nebo česky

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

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

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

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

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

nebo česky

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

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

powershell -ExecutionPolicy Bypass -File "mujskript.ps1"

Parametr -Command, -EncodedCommand a copy-paste metoda

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

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

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

Cesta přes RDP RemoteApp

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

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

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

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

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

nebo česky

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

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

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

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

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

 neboli česky

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

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

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

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

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

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

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

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

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

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

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

nebo česky

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

Auditování a sledování procesů

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

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

Závěr

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Restart-Service NlaSvc -Force

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  [Collections.ArrayList] $nonChangedPasswords = @()

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

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

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

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

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

  return $nonChangedPasswords
}

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

1 - 14Next
>
 

 Rychlovky lepší než tvítr

 
29.4.2016 7:53
No konecne to je aspon dobra zprava: StartCom launches new StartAPI and StartPKI service
15.4.2016 11:41
Konecne bez hanby nahrada za Mamia pizzu - pizza pappi!
15.4.2016 8:15
IDOS mě právě našel spojení z Mendláku na Křížkovského autobusem 44 :-)
8.4.2016 18:46
Jimi finch mi píše: Fuck me tonight :-) spam nekdy i pobavi
11.3.2016 10:18
aktuální vývoj mého bezpečnostního objevu: "We have been able to reproduce your report and are planning to release a fix for it in June."
8.3.2016 20:43
chrome a firefox přestaly věřit SHA-1 certifikátům intermediate autorit. Tzn. už nejen koncovým certifikátům.
8.3.2016 18:34
SAP problém pomalého NTLM/Kerberos ověřování a přístupu z jednoho forestu do druhého přes forest trust, celkem čtyři domény, 30 000 uživatelů, 150 DC, 70 site. Vyřešeno za 2 hodiny pomocí offline práce v Network Monitor a ETL souboru. Jsem pořád dobrej. Podotýkám že zdarma po školení.
21.2.2016 9:58
VasekB mi poslal tuhle PowerShell parádičku: https://blogs.technet.microsoft.com/heyscriptingguy/2016/02/18/powertip-count-backwards-in-array/
10.2.2016 14:49
... ted přišel event z 13:51 :-)

10.2.2016 14:46
závěr přednášky na SCOM - nechytalo to události - a teď se dívám, že mám error "Event Log provider is 51 minutes behind in processing". Tak proto.
31.1.2016 9:53
jeden z mých posledních článků vyšel i na technetu: http://blogs.technet.com/b/technetczsk/archive/2016/01/28/bezpecnostni-auditovani-ve-windows-prihlasovaci-udalosti.aspx
26.1.2016 16:19
právě jsem objevil hack jako prase. z toho bude Security Bulletin. Nechte se překvapit!
14.1.2016 10:17
Office365 neboli Azure nedovoluje mezeru v hesle
12.1.2016 23:09
Novy kfc hogofogo grander - malo masa, tuha houska, a moc palivosti aby byl dojem najezeni
21.12.2015 18:35
Top kniha 2 - Zdenek Svarak...
21.12.2015 18:35
Top kniha v nabidce - Denicek bulimicky. ?? Bliju. Zase bliju. Dneska jenom bliju.
15.12.2015 15:40
hmmm, právě mi dorazil mail s nabídkou členství v "international association or professional women". Tak to beru! :-)
10.12.2015 23:23
Tri dny zpatky jsem se dival na vrchni prchni. A dneska jsem se v Kolkovne pral borce v bile kosili na jidlo a von to nebyl cisnik :-)
9.12.2015 11:18
Altair přišel s výhodnou nabídkou napsat pro IIS automatizaci certifikátů zadarmo z LetsEncrypt.org. Tak tomu se nedá odolat :-) Jdeme na to!
2.12.2015 8:16
indove - jsou uplne ztraceni, ale presto nadseni a zacinaji se ucit C# a PowerShell. Tady u nas by clovek na jejich mentalni urovni delal kopace a byl by spokojeny, ale oni jdou do toho!
27.11.2015 9:01
26.11.2015 18:36
veeeelmi dobre buchty na WUG Bratislava
21.11.2015 16:10
budu mít 4 free přednášky v příštích 3 týdnech - https://www.sevecek.com/Lists/Calendar/calendar.aspx
20.11.2015 8:19
tak jsem se rozsiril uz i na facebook: https://www.facebook.com/ondrej.sevecek.official
20.11.2015 8:19
vcera vysel Windows Server 2016 TP 4!