Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > default
květen 24
Aktuální hitovka - kontrola ukradené emailové adresy

​V poslední době je žhavým hitem možnost nechat si na webu zkontrolovat, jestli se vaše emailová adresa nenachází v nějaké databázi ukradených přihlašovacích údajů. Údajně.

Moje technologie zachází dokonce ještě dál a umí zkontrolovat zda někdo neukradl dokonce číslo vaší kreditní ​karty.

Zkuste zde: https://www.sevecek.com/UkradeneKarty/byla-vase-karta-ukradena.htm

květen 19
Poděkování a prezentace z konference GOPAS TechEd 2016

Děkuji všem co byli na mých přednáškách na TechEd a doufám, že se jim to líbilo a hlavně, že je to bavilo! Příští rok se těším opět na shledanou na konferenci, která už bude mít patnácté narozeniny! Už teď připravujeme například i nový formát přednášek.

Moje letošní prezentace ke stažení zde.​

V kalendáři mám přidány kurzy a WUG přednášku na červen a červenec.

květen 17
BitLockerem AES CBC vs. XTS-AES z dnešní přednášky o novinkách ve Windows 10

Nojo. Jak jsem se už zmiňoval, jsem chaotik. Dneska jsem předváděl, co znamená, když se na sektory disku zašifrovaného BitLocker používá jen prosté CBC. Pokud znáte dešifrovací klíč (tedy FVEK), můžete se podívat, že jste schopni dešifrovat téměř celý libovolný sektor i bez ohledu na to, jestli znáte jeho pozici na disku, nebo ne.

Každý sektor se šifruje nezávisle na ostatních sektorech. Inicializačním vektorem (IV) je pouze číslo sektoru vzhledem k oddílu.

Tím se myslí, že neznáte inicializační vektor (IV) pro AES CBC. Při dešifrování se vám nepodaří dešifrovat správně jen prvních 16 bytes (tedy velikost AES bloku). Zbytek sektoru uvidíte v pořádku. Viz. následující obrázek z mého ukázkového prográmku. Je v něm sektor plný ASCII znaků 16-255. Jen prvních šestnáct znaků je chaos.

Proč mi to nefungovalo na přednášce? Protože jsem blázen. Sektory jsou sice dlouhé 0x200, ale taky člověk musí začít na pozici tímto dělitelné. V obou případech jsem si prostě vzal 512 bajtů od poloviny jednoho do poloviny druhého sektoru. No prostě únava materiálu :-(

BitLocker Diffuser a XTS-AES

Proč to vadí? Proč nestačí jenom CBC? Vždyť jsem znal FVEK. Když znáte dešifrovací klíč, tak je přece jasné, že ty sektory dešifrujete.

Ale v případě offline sector-switch útoku ten FVEK neznáte. Nejste schopni nic sami dešifrovat. Ale přehodit dva zašifrované sektory (tedy nečitelné) můžete vždycky. Až se bude disk později normálně dešifrovat - uživatel si prostě počítač spustí - sektory se dešifrují korektně, kromě svých prvních 16 bajtů.

Dalo by se to tedy využít k tomu, že nahradíte, offline a bez znalosti klíče, některé systémové soubory, nebo konfiguraci v registrech. Samozřejmě byste museli vědět (offline bez dešifrování), které sektory máte vyměnit. Ale ono je v systému hodně míst, která mají poměrně pevnou pozici na disku.

Proto byl dříve v BitLocker proprietární Diffuser. A od Windows 10 je k dispozici standardní XTS-AES. A je dokonce výchozí. S jedním z těchto dvou algoritmů už sektory závisí na své pozici vzhledem k ostatním sektorům a nelze je tedy přehodit.

květen 17
Názorná ukázka proč není dobré šifrovat BitLocker jenom v režimu "used space only"

Tak zrovna jsem narazil na pěknou ukázečku nebezpečnosti used-space-only. To je možnost, jak nastavit BitLocker. BitLocker může šifrovat buď celý oddíl a tím pádem všechny jeho sektory, i "prázdné". Dokonce ani jinak nelze šifrovat například VHD soubory, a to ani v případě že jsou pevné velikosti (tedy ne dynamicky rostoucí). Navíc je to výzhozí volba.

Podívejte se na obrázek. Je na něm kousíček obsahu VHD souboru, který je zašifrován BitLockerem v režimu used space only. Dal jsem do něho veliký soubor s ASCII znaky od 16 po 255. A ouha. Sice je velká část disku zašifrována a nic vidět není, našel jsem tam ale i nějaké sektory, které obsahují části souboru viditelně nezašifrované.

Proč? No asi se to tam zapsalo dříve, než se šifrovalo a soubor byl průběžně nějak realokován po disku. Nebo kdo ví :-) NSA nikdy nespí :-) 

květen 17
Řešení prvního problému z přednášky o novinkách ve Windows 10

Ukazoval jsem virtuální čipovou kartu na TPM čipu, do které se vydá přihlašovací certifikát a přitom to má hardware atestation.

Atestation znamená, že je zaručeno, že se ten certifikát vytvoří na TPM ​a nikoliv jenom nějak na software. Nelze tedy vydat větší počet certifikátů.

Atestation se zajistí tím, že do CA zadáte "id" jednotlivých vaších TPM čipů a je to. Píšu ID, aby to bylo přehlednější. Ve skutečnosti se tam zadává thumbprint (otisk) zabudovaného TPM certifikátu, který má každé TPM uvnitř.

No dobře. Ale teď k tomu problému. Jsem blb. Ještě jsem kvůli tomu instaloval TeamViewer. Ty virtuální čipové karty nefungují z RDP sešny. Stačilo se zastavit venku na vzduchu a hned mi došlo, jakj jsem zmatkář.

květen 16
Rozřešení problému z přednášky o PKI

Jak jsem říkal na dnešní přednášce na ​konferenci GOPAS TechEd, nemám rád nevyřešené problémy. Ukazoval jsem přihlašování klientským certifikátem na web server a ono to nejelo.

Do háje.

Jako vždy na hodinové přednášce to zkazí dojem a není čas to řešit. Tak jsem se rozhodl to aspoň trošku odčinit, a sice to vzalo tak hodinu, ale nakonec jsem to rozlousknul. Napsal jsem to rovnou anglicky (kritika na adresu mé "angličtiny" je zbytečná, rovnou se přiznávám :-) . Třeba se to bude někomu hodit.

květen 13
PowerShell a pole vs. ArrayList vs. HashTable vs. SortedList

Dělám teď nějaké operace citlivé na rychlost přes mnoho objektů a můžu tedy poskytnout nějaký pohled na to, jak je to v PowerShellu s těmito čtyřmy typy "kolekcí". Budu se bavit primárně o chování PowerShell 2.0 protože to je dneska ještě mnohde mainstream a musí s ním všechno fungovat.

Pole

Pole je peklo. Pokud do něho přidáváte položku (například pomocí operátoru +=) tak se vytvoří nové pole, to staré se do něho zkopíruje a přidá se nový prvek. To se změnilo do PowerShell 3.0, kde už je pole kolekce a má i metodu Add() a Clear().

Ale není to zase až tak strašlivé, protože jako parametr funkce se pole předává odkazem. Tedy pokud se ovšem nemusí konvertovat jeho prvky na jiný typ. To se potom celé zkopíruje a prvky nakonvertují. Příklad by byl například parametr funkce [object[]] a do něho vložené pole typu [string[]]. Tady se nemusí konvertovat, takže jenom odkaz. Naopak kdyby parametr funkce měl typ [string[]] a přitom byste do něho rvali [object[]], tak by se to muselo zkonvertovat po jednom a tedy zkopírovat.

Samozřejmě, pokud ho vracíte z funkce jako návratovou hodnotu, tak se jeho prvky přeskládají do nového pole typu [object[]] a to bez ohledu na jeho původní typ. Prostě výsledkem funkce je vždy buď [object[]] nebo jeden konkrétní objekt - klasická demence PowerShellu.

Rozhodně nebrat

ArrayList

Je lepší a já ho rád používám. Má ale jednu podstatnou nevýhodu. I tady, pokud ho totiž vracíte z funkce jako návratovou hodnotu, tak ten list PowerShell celý projede kus po kusus a přeskládá všechny prvky do pole [object[]]. Jak u blbých na dvorku.

Můžete tomu pomoci operátorem čárka (něco jako return ,$list) ale to zase potom ten výstup funkce nelze přímo pajpnout do dalšího příkazu - pajpne to tam celý ten list, tedy v podstatě jeden objekt.

HashTable a SortedList

Potřeboval jsem rychle vyhledávat duplicity. K tomu jsem si potřeboval vytvořit index řetězcových hodnot. Vyzkoušel jsem to nejprve na random 200 000 řetězců. A překvapivě!

HashTable je v tomhle dokonce cca 10 krát rychlejší než SortedList jak v případě vkládání klíčovaných hodnot, tak i v případě jejich vybírání (indexer).

Navíc pokud vracíte HashTable jako návratovou hodnotu funkce, tak vám to nekonvertuje její typ a prostě to vrátí ten odkaz.

Tak tohle je miláček. HashTable.

květen 05
Implementace MD4 a NT hash pomocí C#

Jenom taková malá ​zmínečka, kdyby někdo chtěl, zrovna jsem si v C# naimplementoval MD4 algoritmus podle RFC 1320. Ne že by to byl nějaký světoborný algoritmus, ale ony se pomocí toho počítají NT hash. Tedy to, jak jsou v Active Directory uložena hesla. Zdroják zde.

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. Nevaruje mě o tom ani mi neumožní tuto "výhodu" rovnou odmítnout. 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.

1 - 14Next
>
 

 Rychlovky lepší než tvítr

 
kontrola kradené karty 24.5.2016 0:00
zkontrolujte si, zda se vaše karta nenachází v databázi kradených karet: https://www.sevecek.com/UkradeneKarty/byla-vase-karta-ukradena.htm
 
seznamy "kradených" mailů 23.5.2016 22:44
všude jsou seznamy kradených mailů. a důkaz? není to metoda, jak ukrást mail? škoda, že tam obvykle nemají "ověřit, zda bylo ukradeno heslo (kreditka)" :-)
 
windows 2008 R2 convenience update rollup 20.5.2016 13:34
a naopak tohle se nezdá špatné: https://support.microsoft.com/en-us/kb/3125574
 
indickej rychlokód? 19.5.2016 10:27
přislo mailem od známého. Tak to je opravdu chyba jak sviňa https://support.microsoft.com/en-us/kb/3053711 Něco jako "if -like *user" then while (true).
 
teched problem s TPM virtualni cipovou kartou 17.5.2016 16:41
Tak jeden problém z přednášky vyřešen - TPM virtuální čipová karta - ono to nefunguje z RDP sešny. Na to jsem tam přece instaloval TeamViewer a pak jsem na to zapomněl. Jsem vůl.
 
(More Announcements...)