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