Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > default
červen 15
Verzovní peklo na Windows 10 Technical Preview build 10074

Tak to je psycho. Při spuštění ver v příkazové řáce, nebo winver do okénka to hlásí nově verzi 10.0 build 10074, stejně jako WMI tabulka Win32_OperatingSystem a její hodnota Version.

Zatímco v registrech v klíči

HKLM\Software\Microsoft\Windows NT\CurrentVersion
CurrentVersion = REG_SZ = 6.3
CurrentBuild = REG_SZ = 10074

V předchozím buildu byla všude verze 6.4. Zřetelně se borci zaměřují na produkci mendejů, aby nemuseli nic dělat a místo toho filosofují nad kravinou, jakou verzi mají zvolit. Když už jsme u filosofie, tak tvrdím, že ta jednoduchá volba čísla 10 bude znamenat nekonečné problémy s miliónem programů. Představte si, že někdo bude třídit verze jako řetězce - ono to je totiž jako řetězec uloženo prakticky všude. Například v těch registrech a nebo v WMI class Win32_OperatingSystem. Je to proto, že v tom čísle bývá ještě build a to samozřejmě nejde dát do čísla (jako třeba tady).

Takže nastane to, co jsem si užil například s WMI a Hyper-V na Windows 2012 R2. Trvalo mi několik dnů, než jsem portnul svou implementaci z root/virtualization na root/virtualization/v2. V podstatě jenom proto, že přejmenovali půlku tabulek a jejich property. Žádnou novou extra funkcionalitu to nedostalo. Jenom to celé přejmenovali a přečíslovali hodnoty.

Takže zřejmě filosofické rozhodnutí bylo toto: "borci, nemůžem tomu dát jenom číslo 6.4. To by těm lidem všechno fungovalo a každej by pak tvrdil, že to je starej systém. Tak tomu dejte verzi 10 a každej se z toho opíchá. Vždycky můžem tvrdit, že to je jejich blbost, že už tisíc let třídí řetězce. Jo a vyřiďte borcům z Azure Active Directory Sync Tool aby si zase dali bacha, minule to porovnávali dokonce v regionálních zobrazeních".

Takže to je naprostý chaos. Jako nezlobte se na mě soudruzi, ale číslo verze je jedna z nejkritičtějších hodnot pro libovolnou aplikaci co se dá použít a na čem záleží skoro cokoliv.

Zkuste sami:

'6.3.9600' -gt '10.0.10074'
červen 15
Posun bezpečnosti IE 11 - s červnovou aktualizací dostáváte HSTS (HTTPS Strict Transport Security)

Tak nám MS přidal do Internet Explorer 11 lahůdku zvanou HSTS - tedy HTTPS Strict Transport Security. Stáhněte si kumulativní aktualizaci tady, nebo úplně přímo soubory aktualizace z Update Catalog. A přečtěte si, co to znamená a co to naopak neznamená.

Problém s SSL/TLS strip útokem

Obyčejné HTTPS, jen se serverovým certifikátem, je od jakživa náchylné na MITM útok. Protože klient nemá svůj vlastní certifikát, který by server vyžadoval, může se udělat HTTPS strip., neboli SSL strip, neboli TLS strip. V podstatě bezpečnost závisí na tom, jestli klient chce šifrované HTTPS, nebo je mu to jedno.

Pokud je to klientovi jedno, může se jednat o to nejsilnější TLS 1.2 spolu s PFS, a přitom se to dá krásně odposlouchávat. Proč?

Normální lidé píšou do prohlížeče jenom "www" adresu a nedávají do ní explicitně HTTPS prefix. Většina odkazů po webu a ve vyhledávačích vede také jen na čisté nezašifrované HTTP. Sám web server samozřejmě může poslat klientovi redirect (301/302). Jenže pokud klient nezačne rovnou na HTTPS, tak mu to MITM zakryje. Viz. obrázky.

Mělo by na nich být vidět HTTP redirect a samozřejmě absolutní odkazy (href), pokud jsou takto uvedeny ve zdrojovém HTML. Tohle je normální obsah paketů od web serveru.

Jenže v takovém případě MITM vidí klientův první požadavek na nezašifrovaném HTTP. Přepošle to na web server, klidně rovnou v šifrovaném HTTPS. Útočník se nemá proč bránit šifrovanému HTTPS mezi sebou a webovým serverem. Jenže cokoliv přijde od web serveru po šifrovaném HTTPS, z toho útočník prostě písmenko S odstraní a přepošle ke klientovi.

Klient se tak ani nedozví, že by měl/mohl vlastně šifrovat. Viz. další obrázek:

Snaha o udržení HTTPS

Řešením je snaha uživatele začít každé spojení rovnou na HTTPS. Útočník MITM potom nemá šanci do transakce vstoupit, protože není schopen podvrhnout platný certifikát skutečného serveru. MITM může samozřejmě zkusit vytvořit certifikát podvodný, ale ten (doufejme) na klientovi nebude platit a uživatel (doufejme) neodklikne varování o jeho nekvalitě :-)

V tomto se uživateli právě snaží prohlížeč pomoci sám. Pokud se stáhne webová stránka s HTTP hlavičkou Strict-Transport-Security, tak prohlížeč ví, že by měl už od příště chodit rovnou na HTTPS a nezkoušet to přes nezašifrované HTTP tak, jak si uživatel, nebo nějaký odkaz původně přeje. Prohlížeč si tuhle informaci nakešuje a příště už chodí rovnou na HTTPS.

Hlavičku (header) Strict-Transport-Security musí do HTTP odpovědí (response) přidávat rovnou web server, samozřejmě. Nakreslil jsem to na následujícím obrázku. Podstatná je také keš na klientovi, bez ní by to příště nefungovalo.

Preload list od gůglu

Od příště. To je přesně kámen úrazu. Pokud by v cestě byl MITM útoční už od prvního uživatelova přístupu přes nezašifrované HTTP, je samozřejmě schopen tyto hlavičky vymazat. Vytlumil by je tak stejně, jako udržuje klienta na nezašifrovaném HTTP a zakrývá mu HTTPS přístup.

Od toho má gůgl preload list. Webové sajty, které vědí, že samy implementují Strict-Transport-Security se tam rády zaregistrují. Zdá se, že je to zdarma. Samozřejmě je to zdarma, protože je to podobně jako 8.8.8.8 velmi vítaná metoda, jak sbírat marketingová data.

No ale znamená to, že prohlížeč ví o HTST stránkách dopředu rovnou ještě dříve, než se na ně vůbec pokusíte poprvé přistoupit. A tím se vás snaží o trošku více chránit. Doufejme, že se ten preload list stahuje do IEčka čas od času s nějakou aktualizací a ne až v okamžiku, kdy do té sajty přistupujete. To by nebyla moc ochrana proti MITM, že? Navíc by to dávalo gůglu ještě lepší marketingové info.

V textu support článku je prozatím napsáno že "Microsoft plans to update the preload list on a quarterly basis and deliver it in the corresponding Internet Explorer cumulative update". Tak otázka je, jak ty plány dopadnou :-)

Není to definitivní bezpečnost

Takže jak jistě vidíte sami, nejedná se o definitivní bezpečnost. Pro vnitřní web servery si samozřejmě můžete implementovat ověřováním TLS klientským certifikátem (něco o tom například zde, nebo tady), které je zajištěné bez ohledu na kvalitu prohlížeče.

Nicméně tohle HSTS je jistě příjemný posun.

červen 11
Jak moc nebezpečné je ukládat hesla přímo ve skriptu

Nedávno jsem tu psal o tom, jak uložit heslo přímo do PowerShell skriptu, aby se to neptalo pokaždé okénkem. Vznikla vcelku hojná odezva ohledně bezpečnosti samotného principu, jestli je vhodné to heslo ve skriptu uložit, a nebo jestli to nemít někde jinde "bezpečněji".

Proč to možná vadí

Mít heslo přímo ve skriptu zavání dvěma problémy:

  1. může ho někdo na tom počítači vidět přímo ve zdrojáku toho skriptu. Dostat se ke zdrojáku může buď lokálně po CTRL-ALT-DEL a RDP přihlášení, nebo přes síť, pokud je adresář se skriptem nasdílený
  2. pokud na to zapomenete a skript si někam překopírujete "jako do zálohy", tak si budete heslo ve skriptu nechtěně roznášet.

Problém číslo jedna nepovažuji za problém. Pokud adresář se skriptem správně zabezpečíte, není důvod obávat se, že se do něho dostane někdo nepovolaný. Logicky tedy adresář nastavte tak, aby se k němu dostali jen členové lokální skupiny Administrators. A případně další účty, které to potřebují, samozřejmě.

Dostatečně bezpečné řešení problému s náhodným přenosem souboru

Problém druhý, tedy neopatrnou manipulaci se souborem, která by heslo rozšířila na více míst, se dá vyřešit velice jednoduše. Prostě si udělejte v registrech klíč a hodnotu, do které to heslo natvrdo vložíte a ve skriptu ho přečtete. Registry nikam nekopírujete, takže skript bude úplně čistý.

Registrový klíč opět zabezpečíte tak, aby se do něho dostala jen skupina lokálních Administrators a případné další potřebné účty.

Diskuze bezpečnosti tohoto řešení

A je tohle tedy bezpečné? Jasně že je. Jestliže se do těch registrů dostane jen skupina Administrators, tak není nikdo jiný, kdo by si to jinak přečetl. Samozřejmě byste mohli využít nějaké jiné sofistikované řešení, jako je DPAPI, nebo LSA Secrets. Ale to jsou technologie, ze kterých to heslo stejně člen skupiny Administrators dostane bez jakýchkoliv problémů - viz. můj článek o vykrádání hesel naplánovaných úloh a služeb. Ty tohle přesně používají a přitom, jestli jste členem skupiny Adminitrators, heslo z nich taky dostanete.

 

květen 26
Cloud nerovná se Office365, asi tak stejně jako Seznam nerovná se internet

I u nás na TechEdu v keynote, ale i jinde, jsem se konečně dozvěděl následující z úst/pera významných osob pracujících v MS. Tak jak to tvrdím už dlouho. Znělo to nějak takto:

  • ... náš Office 365 jako jedna z ukázek public cloud hostované služby ...
  • ... náš Azure jako jedna z ukázek hostování VM v public cloud ...
  • ... vyrábíme také nějaká referenční hardware zařízení, jako třeba Surface a Xbox ...
  • ... nové Windows 2016 budou ještě více podporovat vaše veřejná a privátní cloud řešení ...
  • ... Windows 10 budou mít možnost instalovat Win32 aplikace z Windows Store ...

Tak si k tomu přidejte nadpis tohoto článku a uvědomte si, že i MS ví, že jeho služby jsou pouze "refereční" a že i pro MS je stejně důležité, aby partneři prodávali služby a podporuje je v tom. Podstatný je prodej služeb a je jedno, jestli to jsou služby placené MS přímo, nebo nepřímo. Cloud neznamená Office365. Cloud znamená veřejný hosting služeb postavený na MS technologiích, provozovaný kýmkoliv.

Nikdo neříká, že si musíte maily dát do Office365 a nechat si na ně čumět každýho pátýho, totálně anonymního, Inda.

květen 25
Jak v PowerShell vytvořit Credentials, aby se to neptalo

Klasický problém skriptařů a automatizačníků. Množství PowerShell cmdletů potřebuje parametr Credentials. Jenže ten parametr bere jenom login a potom to zobrazí okénko pro zadání hesla. To je samozřejmě pro automatizaci na nic. Nešlo by to zadat rovnou do toho skriptu? Jasně, stačí vytvořit objekt PSCredential ručně:

$installAccount = New-Object System.Management.Automation.PSCredential 'gps\sp-admin', (ConvertTo-SecureString 'Pa$$w0rd' -AsPlainText -Force)

... a je to :-)

květen 19
Moje prezentace z konference #TechEdDevCon 2015

Parádní publikum! Díky všem!

Moje prezentace z letošní konference TechEd DevCon 2015 jsou k dispozici zde.​

Poznámka k mé přednášce o RDP: na přednášce mi nejelo Kerberos ověření z internetu přes RD Gateway (RDG, Remote Desktop Gateway). Až potom jsem si uvědomil, že jsem zapomněl do toho ​.RDP souboru vložit hodnotu rdgiskdcproxy:i:1. Prostě se to nesmí zapomenout na klientovi povolit. 

Ale slibuju, že na ten SSO z internetu přes RDP Proxy napíšu v brzku článeček.

květen 11
OT - proč lidi nechápou statistiku a korelaci

Dneska OT (off-topic). Minulý čtvrtek jsem si do vlaku koupil dva politicko-společenské časopisy a zdá se, že x autorů nepochopilo, na co je statistika. Hlavně jim nedochází, že nemohou vyvozovat na nějakou závislost dvou jevů čistě z toho, že to oboje dává vysoká procenta :-)

Klasický příklad na ne-korelaci

Mějme dvě tvrzení. Asi jsou pravdivá, nevím. Ale to není důležité.

  • Švýcaři se dožívají v průměru nejvyššího věku
  • Švýcaři konzumují nejvíce čokolády na světě

Plno lidem z toho automaticky plyne výsledek, že se dožívají tak vysokého věku, protože ce cpou čokoládou. Ale to je jenom to, co ti lidi chtějí, aby plynulo.

A to je právě ten omyl. Proč by muselo? Nemůže to být tak, že žerou tolik čokolády právě proto, že se dožívají tak vysokého věku a chtějí si trošku zpříjemnit dlouhý pobyt v domově důchodců? A není to tak, že i když žerou tolik nezdravé čokolády, tak to věčné odhánění much požírajících kravnice na pastvinách jim procvičuje krevní oběh?

Jak snad už pochopíte, ani jedno.

Ze dvou statistik na dvou nějakých jevech se nedá usuzovat ani to kravské lejno. Obecně řečeno, nejprve musíme mít nějaké jiné důkazy pro závislost těch dvou jevů a teprve potom můžeme použít statistiku k posouzení jejich vzájemné míry. Ale nemůžu jenom ze statistiky vyvozovat ten vztah. Tomu se říká implikace, jak by řekl pan Studnička!

Trošku opačný business přístup

Co třeba toto - prodávám čokoládu. Je pro mě výhodnější ji prodávat do Švýcarska? Jasně. Delší věk, větší žrouti => větší prodeje. Může mi být úplně jedno, jestli to spolu souvisí, nebo nesouvisí. Když ty dvě hodnoty vynásobím, tak mám lepší zisk.

Tady ale neřeším závislost těch dvou charakteristik. Tady prostě násobím zisky z jednoho i druhého výroku samostatně. Ale už nemůžu čekat, že v jiné zemi, kde se taky dožívají tak vysokého věku, budou taky žrát čokoládu jak zběsilí (i kdyby ten věk mohl záviset jen na jednom faktoru).

A odpověď na otázku z nadpisu?

...

Pozdější úprava: Ještě jeden pohled na věc

Co když máme stejné statistiky pro různé země, kde si tyto dva výroky "odpovídají" nebo jak bych to nazval. Tzn. méně čokolády vs. kratší život, více čokolády vs. delší život. Můžeme z toho vyvodit, že konzumace čokolády prodlužuje život?

Opět nemůžeme. Vždycky to může být přece důsledek jednoho, nebo druhého a stejně tak to může být ve všech případech důsledek něčeho třetího.

Jediné co jsem ochoten uznat je, že v tomto případě je nějaká "důsledkovost" už alespoň trošku vidět. Ale pořád nevíme co je příčina a co je důsledek.

květen 04
Všem firmám trvá nekonečně dlouho, než zjistí ztrátu dat

Nedávno mě upozornili na tento článek: http://businessworld.cz/bezpecnost/trem-ctvrtinam-firem-trva-radove-hodiny-nebo-dny-nez-zjisti-kradez-dat-12245

Tak jsem si to přečetl a podle mě je to celé nesmysl. Krádež dat nelze zjistit. Na rozdíl od pevných věcí, jako jsou papírové peníze, kusy zlata, nebo spodní prádlo. Když si někdo zkopíruje vaše data, tak to nemáte jak poznat. Alespoň ne do okamžiku, než se tato data objeví viditelně někde, kde si jich všimneme. A i tak se dá jen velice těžko usuzovat, že to jsou "naše data".

Samozřejmě existují k tomu různé metody, například vodoznačky. Zabývá se tím celá věda zvaná steganography, která se taky zabývá tím, jak to v datech odhalit a případně se toho zbavit (poznámka, přijďte na kurz CHFI do GOPASu).

I v případě pevných věcí si nemůžete být nikdy jisti, že krádež odhalíte nějak "proaktivně". Kontra příklad je bankovní sejf. Můžete mít nejprve třeba jen detekci na dveřích, jestli je někdo neotevřel. Banditi se prokopou přes zeď. Tak tam dáte detekci do zdi. Banditi odpojí elektřinu. A zase to pozná až nějaký chudák, co si přišel vybrat svoje úspory. Neexistuje absolutní ochrana. Vždycky se najde protiútok. Viz. dokonce nedávný případ v Británii, který jsem úplně náhodou objevil až po napsání tohohle přízpěvku. Dobře, tak tam měl sedět borec a čumět na kameru, jestli se vevnitř neválí otevřené sejfy. Bandita nasadí předehranou smyčku na kameru. To jsme viděli v různých akčňácích milionkrát. A tak pořád dokola.

Takže se zamysleme, co asi tak může někdo detekovat a co ne?

Antimalware může detekovat binární signaturu celosvětově známého, profláknutého, viru. Neexistuje, že by mohl být úspěšný vůbec v detekci ručně provedeného útoku. Důkaz jsem předvedl na podzim na konferenci HackerFest a na jaře na ShowIT.

Intrusion detection system (IDS) může opět detekovat nějaké známé signatury síťových útoků. Pokud útočník ví, co takový systém detekuje, jistě si najde cestu, jak to udělat, aby se detekci vyhnul. Na důkazní přednášce na letošní HackerFest se pracuje :-)

Snad jediná věc, u které jsem ochoten uznat, že lze detekovat velmi rychle a spolehlivě je DoS útok. Služba přestane fungovat a uživatelé se ozvou. Myslím, že každý má zkušenost, že uživatelé jsou ty nelepší detektory libovolného výpadku :-)

A dojděte na teched, už je pomalu vyprodáno!

duben 29
RestrictedAdmin režim RDP připojení a jak to vlastně funguje

Jistě si vzpomínáte na množství mých článků ohledně Kerberos a Kerberos delegation a v poslední době například o vykrádání hesel z paměti počítače. V dnešním přízpěvku to všechno zúročíte.

Také se jedná o vaši povinnou přípravu na konferenci TechEd, kde budu mít související přednášky! Všichni přihlásit! Pokud to nepochopíte, můžete naopak dorazit na můj kurz Kerberos Troubleshooting do GOPASu a já už to do vás dostanu.

RDP připojení a kradení hesel

Jak jsem už psal několikrát, RDP ověřování je ve své podstatě jednoduchá basic authentication. Podobně jako HTTP basic authentication, nebo LDAP simple bind. Ano, komunikační kanál je šifrovaný, optimálně pomocí TLS (SSL). Ale uvnitř něho se vždy přenáší heslo v plné formě. Na straně RDP serveru (terminal server) ho přijme tamní LSASS proces a uloží si ho v operační paměti.

Poznámka: LSASS je local security authority sub system, tedy proces, který "ověřuje uživatele", vytváří access tokeny, uchovává LSA secrets tajná data (jako je třeba heslo počítače do domény v klíči $MACHINE.ACC, nebo hesla ke službám apod.). Taky o tom hojně pojednávám ve svém MVA kurzu.

Pro uživatele samozřejmě vytvoří na základě tohoto hesla access token. podle Kerberos, nebo při nejhorším NTLM ověření v Active Directory. Je to úplně stejné, jako byste se přihlašovali interaktivně lokálně na počítači pomocí ctrl-alt-del, jenom má váš monitor trošku delší kabel.

Znamená to, že po dobu běhu vaší terminal RDP session je plnotextové heslo v paměti. Je tam potřeba, abyste mohli chodit z RDP serveru neomezeně po síti. Pokud je v paměti, je možné ho ukrást. Nebo ho zneužije automaticky i při UAC. Útočník potřebuje práva lokálního člena Administrators, nebo minimálně uživatelské právo Debug programs. Jak se stát lokálním adminem jsme si už ukazovali tisíckrát, dokonce na všech možných konferencích, jako je TechEd, ShowIt nebo HackerFest.

Pokud byste plain-text heslo na RDP nedostali, chovalo by se to celé podobně, jako v případě PowerShell remoting pomocí Enter-PSSession, nebo Invoke-Command s Kerberos ověřením. Nešlo by se tedy dostat na žádné další síťové služby. Museli byste dodatečně zadávat hesla. Naopak PowerShell remoting s CredSSP ověřením je přesně opačný, je to taky "basic" authentication a transportuje to do vzdáleného počítače opět heslo, stejně jako právě RDP.

Rizika vzdálené správy stanic

Jak jste mohli vidět, není dobrý nápad připojovat se na stanice, nebo obecně libovolné nezabezpečené stroje, se silným heslem. Bezpečná metoda je pouze vzdálené připojení při bezpečném Kerberos ověření. Takové spojení do vzdáleného počítače netransportuje nic, co by se tam dalo vychytat.

Znamená to tedy používat buď MMC konzole, PowerShell, nebo PowerShell remoting s Kerberos ověřením (a nikoliv CredSSP, to je taky basic authentication), WMI, LDAP, SQL konzoli a podobně.

Naopak RDP a PowerShell remoting s CredSSP ověřením je nebezpečný. Což je škoda, protože RDP je velmi pohodlné a každý ho rád používá. Ještě poznámečka k oblíbenému TeamViewer, to je samozřejmě to stejné, ještě podstatně horší, protože si tím otevíráte díru do sítě kdoví odkud z internetu - stačí spustit a tradá.

Windows 8 a Windows 2012 přicházejí s restricted admin (restrictedadmin) režimem vzdálené plochy

Proto Windows 8 a Windows 2012 dorazily s novinkou. Noví klienti (mstsc) nemusí do vzdálené plochy posílat plné heslo. Prostě si vygenerují TGS ticket pro TERMSRV SPN a tradá. Na vzdáleném počítači potom není heslo v paměti. Ve skutečnosti tam v paměti není nic. Takže není co vykrást. Samozřejmě taky ale není co použít na přístup do sítě. Ale to u stanic nejspíš vůbec nevadí!

Stačí spustit mstsc s přepínačem restrictedadmin. Bohužel to nejde napsat až později do adresního řádku, ale to není taková tragédie.

mstsc /restrictedadmin

Následuje pár obrázků:

Na posledním obrázku už vidíte pokus o přístup do sítě na nějaký admin share, nebo třeba pomocí WMI vypsat seznam procesů ze vzdáleného počítače. Budete obecně dostávat access denied, protože do sítě chodíte anonymně (anonymous logon).

Text v obrázku říkající "your windows logon credentials will be used to connect" je shodný s textem, který se vám tam zobrazuje, pokud máte zapnuto RDP SSO (single-sign-on, neboli Credentials Delegation). Na pohled to nelze rozlišit, musíte prostě vědět, jak jste program spustili.

Požadavky?

K tomu, abyste se na vzdálený počítač dostali, musíte na něm být členem skupiny Administrators. Nestačí mít jen obecně přístup na RDP (remote desktop users). Pokud máte RDP přístup, ale přitom nejste členem skupiny Administrators, tak dostanete tuto hlášku: Account restrictions are preventing this user from signing in. For example: blank passwords aren't allowed, sign-in times are limited, or a policy has been enforced.

Proč?

To ale není všem dnům konec

Pokud se ale do sítě pokusíte dostat, někam se ve skutečnosti dostanete. Není to divné? Docela mě to překvapilo:

To přece není možné. Když jsem se někam nedostal, ale zato jinam ano? Ona tam je úplně ultra mega fíčura. Po připojení vám LSASS na RDP serveru vytvoří access token. Samozřejmě podle obsahu vašeho TGS ticketu. Takže na serveru jste lokálně jako vy sami, máte správné doménové skupiny apod.

Ale k tomuto access tokenu vám LSASS vloží do paměti síťové heslo účtu počítače. Péklo. Takže po síti chodíte jako ten počítač. V mých obrázcích se počítače jmenuje GPS-DATA1, takže všude chodíte pod účtem GPS-DATA1$.

Důkaz je v klist výpisu:

To je taky důvod, proč tenhle režim nemohou využívat obyčejní uživatelé. Znamenalo by to pro ně získat nelegálné účet počítače a to samozřejmě nechceme.

Důvod pro tuhle últra specialitu je pravděpodobně ten, aby se GUI programy, které si na vzdálené ploše spouštíte, mohli alespoň trošku podívat do sítě, speciálně do Active Directory. Ony, narozdíl od síťových služeb, nejsou moc přizpůsobené se vyhýbat síťovým čtením.

Pro zajímavost, tohle se dá vypnout v HKLM\System\CurrentControlSet\Control\LSA, DisableRestrictedAdminOutboundCreds = DWORD = 1 a budete totálně odříznuti. To ale není žádná ochrana, protože by samozřejmě stačilo spustit si cokoliv pod účtem SYSTEM, nebo Network Service.

A tak to je.

duben 27
Odpověď - jak je to vlastně s hesly v Internet Exploreru

Redakce našeho populárně naučného časopisu dostala následující dotaz:

"Existuje na IIS web s Windows Authentication. Přihlásím se na něj přes internet doménovým jménem/heslem. Když tam vlezu druhý den ze stejného prohlížeče (comp nevypínám), vesele mě to příhlásí, aniž by to znovu chtělo heslo. To mě teda dost překvapilo."

Odpověď poněkud rozveďme, ať tomu dáme trošku rámec.

Ověřovací metody v Internet Exploreru

Do webových aplikací je možno zaslat heslo jednou z následujících metod:

  • HTTP basic authentication - čístotextové heslo, bez nějakých zašifrování. Samozřejmě je možno ho chránít pomocí TLS (to jak tomu někdo říká SSL), ale principiálně se přenáší plné heslo. Na IIS web serveru se nejspíš ověřuje vůči doménovým účtům, i když by to mohla vyvolat i webová aplikace samotná a používat svoje vlastní aplikační účty z nějaké databáze.
  • Windows authentication - heslo cestuje v nějaké "zašifrované formě". Jedná se o dva protokoly, buď NTLM (obecně řečeno - ono to má tři verze), nebo Kerberos. V případě NTLM opravdu cestuje heslo v "zahešované" formě (MD4 heslo v HMAC-MD5). V případě Kerberos cestuje pouze TGS tiket, který s heslem uživatele nemá nic společného.
  • Forms-based (cookie-based) authentication - prostě aplikační webová stránka, která po vás chce zadat login a heslo. Heslo cestuje obvykle v plné formě, podobně jako při HTTP basic ověření, ale viděl jsem i weby, které ho o něco lépe chránily (proti TLS strip a vůbec HTTPS inspection). Potom, co si vás webová aplikace ověří, vám web server vydá nejspíš nějakou HTTP cookie. Samozřejmě nemusí, to už je na něm, jak si vás bude pamatovat (například i jen podle IP adresy).

HTTP basic authentication a Windows authentication je součástí HTTP hlaviček. Forms-based authentication se posílá nejspíš jako součást těla POST požadavku, někdy (velmi nevhodně) v podobě GET parametrů.

V případě HTTP basic authentication a Windows authentication na vás může prohlížeč vyskočit s normálním okénkem, kam přihlašovací údaje zadáte. V případě forms-based se jedná o formulář na HTML stránce.

Automatická, uložená, nebo zadaná hesla

Do přihlašovací stránky (forms-based), nebo do přihlašovacího okénka může uživatel něco zadat. Prohlížeč obvykle nabízí možnost tyto informace uložit pro další použití automaticky. Pokud jsou k dispozici Kerberos nebo NTLM přihlašovací údaje uživatele operačního systému (zadané při ctrl-alt-del), prohlížeč je může automaticky použít k odeslání.

Ano, pokud uživatel jednou zadá basic nebo Windows authentication údaje, tyto zůstávají v paměti procesu prohlížeče až do jeho finálního ukončení, bez ohledu na to, jestli jste vybrali "uložit" nebo ne. Pod pojmem proces myslím stejný Windows process. Což zahrnuje také nově otevřené taby (ctrl-t), nově otevřená okna (ctrl-n). Prohlížeč takové údaje nezapomene ani po nějaké době nečinnosti, ani pokud přejdete na úplně jiné stránky. Důvodem je nejspíš jednoduchost jejich funkce a nezávislost na nějakých "oknech" a konkrétních "tcp spojeních". Prohlížeč prostě nemá možnost, jak jednoznačně poznat, že uživatel už práci s danou stránkou "ukončil". A standard mu žádné konkrétní doporučení nedává. Kromě faktu, že nesmí posílat ty údaje do jiných host header webů.

Trvanlivost forms-based přihlašovacích údajů si naopak řídí kompletně webová aplikace a prohlížeč o nich nemá v podstatě ani ponětí. Prohlížeč pouze udržuje v paměti cookies, nebo libovolnou jinou formu identifikace, kterou si webová aplikace vymyslela. Tady se aplikace může sama rozhodnout, kdy přestane dané cookie přijímat, kdy je zruší a jestli nabídne uživateli nějakou možnost explicitního odhlášení.

Obě metody jsou samozřejmě náchylné na cross-site scripting a vůbec brouzdání cizích osob po historii. V případě forms-based authentication se obvykle limituje životnost cookies. V případě HTTP authentication jako je basic, nebo Windows authentication se doporučuje uživatelům zavírat pořádně okna prohlížeče. Vzhledem k obvyklému intranetovému SSO to je ale i tak zbytečné.

Ještě k SSO a výchozím přihlašovacím údajům systému

Obecně se prohlížeč pro intranetové weby bude snažit použít výchozí přihlašovací údaje uživatele z operační systému (Kerberos nebo NTLM zadané při ctrl-alt-del) automaticky, aby tak dosáhl SSO (single-sign-on). SSO je maximálně žádoucí, protože to snižuje opakované zadávání přihlašovacích údajů - ochrana proti odpozorování, keyloggerům atd - tak jak si žádá například i ISO/IEC 27001/27002.

Pokud se ovšem jedná o automatické zasílání SSO přihlašovacích údajů, uvědomme si, že neexistuje možnost odhlášení (logoff). Kdykoliv okno prohlížeče zavřete, nebo i kdybyste dali libovolně aplikaci vědět, že již nechcete pracovat, při příštím otevření stránky se stejně automaticky použijí výchozí přihlašovací údaje systému.

Hesla ukládaná ručně "v prohlížeči"

Pěkný referenční článeček zde.

Internet Explorer (IE) ukládá hesla z formulářů buď jako tzv. "autocomplete passwords" až do verze IE 9. Hesla z formulářů ukládá do uživatelových registrů v plné formě, jen lehce chráněné. Umístění je:

HKCU\Software\Microsoft\Internet Explorer\IntelliForms\Storage2

kde se objevují REG_BINARY hodnoty. Je to tu ale jaksi "zašifrováno" pomocí URL (jeho SHA-1 hash) webové přihlašovací stránky. To znamená, že pokud nevíte, jaké URL to bylo, heslo z toho nedostanete. Naopak, pokud byste věděli URL, heslo se dešifruje v plné formě. Existují na to samozřejmě různé krekry. Ukládání hesel z formulářů se dá vypnout pomocí registrové hodnoty DisablePasswordCaching:

HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings
DisablePasswordCaching = REG_DWORD = 1

Od verze IE 10 se ukládají hesla do Windows credentials manager, stejně jako hesla pro HTTP authentication viz. dále.

Hesla pro HTTP basic a Windows authentication ověřování se ukládají do tzv. credentials manageru, neboli Windows vault. To je to, co najdete od Windows Vista v Control Panel v panelu User Accounts vlevo, kde se dá kliknout buď Manage your network passwords, nebo Manager your credentials. Zde se to rozděluje na dvě části. Hesla systému Windows a od IE 10 i hesla webová. Hesla systému Windows - tedy hesla pro intranetový Kerberos, NTLM, nebo i Basic ověření - se dají prohlížet i na starších systémech a serverech viz. můj dřívější článek.

Credentials manager si ukládá tajná data na disku v profilovém adresáři uživatele:

%appdata%\Microsoft\Credentials

Opět je možné je odtud samozřejmě dostat. Údaje jsou zde chráněné pomocí DPAPI (Data Protection API) a jsou principiálně šifrované uživatelovým přihlašovacím heslem. To je samozřejmě trošku složitější, protože takhle by se uživatelům nemohlo resetovat heslo, ale to je už jiná pohádka. Pro nás je podstatné, že je odtud dostane libovolný program běžící jen pod účtem uživatele. A to i v případě, že bylo uživateli správcem vyresetováno heslo.

A to jsou důvody, proč není moc bezpečné nechat lidi ukládat hesla na počítačích. Pokud chcete vypnout Credentials manager, můžete tak učinit pomocí Group Policy nebo Local Security Policy:

Computer configuration
    Windows Settings
        Security Settings
            Local Policies
                Security Options
                    Network access: Do not allow storage of passwords
                    and credentials for network authentication

Neukládat, zavírat!

duben 16
Dnešní online přenos z WUG na téma PowerShell pro pokročilé

Dneska mám premiéru. Poprvé se pokusím svoji přednášku pro WUG (PowerShell pro pokročilé) přenášet online pomocí livemeetingu. Kdo máte zájem, můžete se zkusti připojit, začíná to od 17:00, ale asi tam musíte být dříve. Nevím ještě. Nevím v jaké to bude kvalitě, jak to bude fungovat a nevím, jak moc budu schopen to ovládat, tak buďte prosím trpěliví.

Nevím který link je ten správný, zkuste jeden z nich:

https://www.livemeeting.com/cc/mvp/meet/TH887C 

https://www.livemeeting.com/cc/mvp/join?id=TH887C&role=attend&pw=sevecek

Položka do kalendáře je tady: ​https://www.livemeeting.com/cc/mvp/meetingICS?id=TH887C&role=attend&pw=sevecek&i=i.ics

​Tak zkusíme a uvidíme! Těším se!

PS: Těším se na setkání na TechEd 2015!

duben 15
Dobře alza!

Pěkně. Dneska jsem zavítal zase jednou na alza.cz a ​už je to všechno v cajku, jak má být! Dokonce se vytáhli se zeleným certifikátem.

Takže výtka z mého staršího článku už není pravdou. Pochvala.

A dívám se, že se toho nebojí a mají rovnou hustě 256bitový certifikát.

Taky se můžete podívat sem, mají test za A. A to ten test nezohledňuje PFS preferenci (ECDH algoritmy). Ode mě by za tohle dostali AAA.

Mají i Strict-Transport-Security (HSTS) a mají ho dobře udělané, protože to vracejí i ve všech HTTPS odpovědích, což jsem už párktár viděl, že ne každý dělá (překvapivě). Zkoušel jsem se tam dostat přes čisté HTTP a nelze. Vždycky dostanete 301 permanent redirect. Teď už jenom aby to IE začal podporovat. Jsou dokonce už i předloudnutí.

Tak sice už jen škoda, že mě tím zmizel příklad chybného webu, tedy kromě mého :-)

​PS: Těším se na setkání na TechEd 2015!

únor 17
Můj první MVA kurz

Můj první MVA (Microsoft Virtual Academy) kurz byl vydán právě před několika hodinami.​ Jedná se o Bezpečnost Windows pro pokročilé. Děkuji tímto Tomáši Kantůrkovi z Microsoftu, protože připravit to do provozu musela být pěkná dřina.

Další budou doufám v brzu následovat!

http://www.microsoftvirtualacademy.com/training-courses/bezpecnost-windows-pro-pokrocile-identity

únor 17
Moje slajdy z konference ShowIT 2015

Tak tohle byla naprosto luxusní konference! Parádní prostředí, katering, projekce!

Všechny moje slajdy jsou tady: https://www.sevecek.com/presentations/showit2015

1 - 14Next
>
 

 Rychlovky lepší než tvítr

 
2.7.2015 22:32
skype for windows desktop je volitelná Windows 8.1 aktualizace. Tak to je maso.
2.7.2015 19:05
http://www.bbc.com/news/technology-33347866
2.7.2015 18:45
Plovarna v Edenu je plna cigosu. Az na to, ze to neni plovarna...
2.7.2015 12:48
jupi, Windows Server 2016 (build 10074) ma znovu DCPROMO pro unattended instalaci. Starsi build to nemel, tak me to trosku rozesmutnilo.
27.6.2015 20:49
Reacher je dneska zase sama perla :-)
15.6.2015 17:09
panebože. Tak to nejde. Oni opravdu udělali verzi Windows 10 jako: 10.0. Takže polovina programů nepojede, protože bude třídit verze podle abecedy. To je nápad hodný idiota.
14.6.2015 12:23
Za vcerejsek build HyperV "clusteru", a migrace 2x DC, 2x CA, 2x NPS a 2x DHCP z 2008 zelez na 2012r2 virtualky. Jsem vcelku rychlej.
10.6.2015 19:32
Nasemu otci nefunguje Microsoft, manzelce nejede internet (rozumnej Seznam) a dozvidam se ze komusi zavedli na chalupu google :-)
20.5.2015 8:08

Jůlin překladový slovník: ďáďa - Honzík, mamn - maminka, tata - fotr, papn - papat, kakn - kakat. Ukazuje se, že je to celkem dostatečná slovní zásoba.

18.5.2015 15:55

dneska super publikum na #TechEdDevCon! dekuju!

 

18.5.2015 7:20
Dneska zas slunce a TechEd, nemuze byt nic lepsiho!
17.5.2015 22:06

panebože, ten nový build Windows Server 2016 neobsahuje nabídku Start? Ježiš!

 

17.5.2015 18:35
Slunko a sestiletel chlapecek na ulici zpiva ceskou hymnu. Kraasa
14.5.2015 10:56
Konference TechEd 2015 je narvaná k prasknutí! To bude něco! Už se nemůžu dočkat.
29.4.2015 6:07
MS planuje tarif pro duchodce. Azure Geront Plan. VM jenom s jednim CPU 300MHz, guest OS WinXP a Office365 ve skinu Outlook 97.
28.4.2015 16:22
diky VasekB za seznam :-) http://en.wikipedia.org/wiki/List_of_fictional_Microsoft_companies
17.4.2015 11:49
hustěéé, nějaký spammer dokázal prorazit moji "ochranu" s číslem 2 při komentování u mě na webu.
17.4.2015 7:37
Ostravaka nemusim ale dnesni song o treninku u ruzicky - se smeju jeste ted
16.4.2015 7:45
TechEd 2015 se nezadržitelně blíží. Už jenom měsíc do mé milované jarní konference. Nevím proč, ale ta atmosféra je prostě úžasná! https://www.teched.cz
9.4.2015 17:21
Certifikační zkoušky MCP vyžadují po několika letech recertifikaci. Odteď nemusíte jít znovu na zkoušku, stačí projí (jen) několik (mnoho) MVA kurzů.
8.4.2015 11:47
příští týden mám WUG Bratislava - PowerShell pro pokročilé. Tak doražte! http://www.wug.sk/?name=events&e=179
7.4.2015 20:57
teamviewer? neexistuje čistá verze "client". všechno si to automaticky zapíná vzdálený přístup, který nelze vypnout. tomu říkám bezpečnost.
4.4.2015 15:06
Kostkovy cukr - nejvhodnejsi bomboniera pro tchyni
1.4.2015 16:25
Congratulations 2015 Microsoft MVP!
28.3.2015 19:22
No proc? Vsichni turci, kosovci, makedoci atd z Nemecka a Rakouska maji pres velikonoce dovcu, tak jedou domu.