Autentizace ke sdíleným složkám využívajícím SMB protokol

Využití autentizačních mechanismů pro přístup ke sdíleným složkám závisí na podporované verzi SMB protokolu a podporovaných mechanismech operačního systému. Jedná se o pokračování článku na téma Sdílení souborů v sítích Windows.

Přehled autentizačních metod pro přístup k úložištím využívajícím SMB protokol

Volba možných technologií sdílení dat v prostředí sítí Windows je velice úzce spojena s přihlašováním a použitými přihlašovacími mechanismy. Pokud se volí technologie sdílení, přesněji použitá verze sdílení, je nutné zvážit i jaké technologie přihlašování budou použité. Některé z těchto technologií již dnes nejsou dostatečně bezpečné, některé z nich jsou přímo kriticky slabé. Zde uvedená tabulka ukazuje, které systémy podporovaly jaké metody přihlášení. Aby se poukázalo na slabiny těchto mechanismů, je uveden celý vývoj včetně dávné historie. Je potřeba si uvědomit, že mechanismy staré již téměř půl století v dnešní době nemohou obstát a jsou pro útočníky spolehlivou cestou do systému.

Zhodnocení podpodovaných metod vůči jednotlivým verzím protokolů

Jak je vidět, že některé metody jsou relativně staré a začalo se od nich naštěstí odcházet. Zpravidla byly příčinou bezpečnostní problémy a vývoj v oblasti kryptografie. Dále budou popisovány jednotlivé algoritmy, jejich vlastní vývoj a vlastnosti. Algoritmy jako je SAML, Microsoft Account, Microsoft Hello budou v tomto článku cíleně opomíjeny, protože je nelze přímo použít pro přístup ke sdíleným složkám. Zpravidla se používají pro další služby a řízení přístupu je řešeno zprostředkovaně pomocí mechanismů NTLMv2 nebo Kerberos. Obecně tedy lze na základě dostupných informací tvrdit o podpoře autentizačních mechanismů přibližně následující.

Mechanismus LANMAN

Jednou z nejstarších metod pro autentizaci uživatelů v síti je LANMAN. Tato metoda použila šifrovací algoritmus DES, který v té době patřil mezi nejlepší algoritmy. Bohužel zároveň se tím vytvořila jedna z velkých slabin, kterou algoritmus má. Na příkladu tohoto algoritmu je nutné rozlišovat mezi kryptografickým mechanismem LMHash a autentizační metodou LANMAN. Vlastní autentizační metoda prošla dlouhým vývojem a od Windows NT 4.0 již není doporučovaná. Jednotlivé verze byly:

Autentizace:
Negotiate (Client –> Server): Send U=Username
Challenge (Server –> Client): Send C=Challenge
Authenticate (Client –> Server): Send Encrypted DES(Key=LMhash, C)

Mezi největší slabiny autentizačního schématu:

• Příliš krátká challenge.
• Chybí sůl (např. uživatelská challenge), zajišťující odlišení hesel mezi jednotlivými uživateli.
• Nemá ochranu proti relay útoku.
• Nemá ochranu proti replay útoku, částečnou ochranu vytváří pouze challenge poskytnutá serverem.
• Chybí obousměrná autentizace (mutual authentication).
• Nemá ochranu proti MITM útoku.
• Nepodporuje MFA.

Vlastní funkce LMhash, která je v autentizační metodě použitá, má následující problémy:

• Uživatelské heslo je klíčem pro DES algoritmus. Protože DES má 56b nikoliv 64b heslo, je uživatelský vstup vždy 7B/56b namísto 8B nebo 14B/112b namísto 16B. Osmý byte hesla pro DES je vždy prázdný (0x00).
• Heslo delší než 14 znaků není možné, algoritmus ho nepodporuje.
• Heslo může obsahovat některé speciální znaky, čísla, mezeru a velká písmena. Malá písmena se převádí na velká. To znamená 26 znaků (A-Z), 10 číslic (0-9) a 10 speciálních znaků. Celkem je tedy možné dosáhnout maximálně 78b entropie vstupu pro 14 znakové heslo. To odpovídá přibližně 10 znakovému heslu bez uvedených omezení rozsahu vstupu.
• Na heslo kratší než 8 znaků je možné zaútočit a spočítat původní vstup, nebo je hesla rozdělit na dvojice 8B výstupů a hodnoty hesla spočítat.
• Pro hesla o délce 8 a více znaků je možné použít duhové tabulky (Rainbow table). Je možné je použít i pro kratší hesla.
• Algoritmus není jednosměrný a dovoluje tak spočítat i původní heslo uživatele.

Mechanismus NTLMv1

Algoritmus NTLMv1 (původně pouze NTLM) byl určen jako náhrada původního a slabého algoritmu LANMAN pro autentizaci. Ten měl mnoho chyb a snahou bylo nahradit algoritmus DES spolu s reverzibilním šifrováním jednosměrnou hash funkcí a odstranit největší neduhy tohoto způsobu přihlašování. Z tohoto důvodu byl vyvinut algoritmus NTLM, který bohužel přebíral většinu neduhů z původního mechanismu. Výrazným kladem bylo rozšíření hesla, bohužel stále nebyla ochrana proti některým typům útoků. Výsledek hash funkce je 128b výstup, který se prodloužením o 5 nulových Bajtů stává 168b blokem. Ten je možné rozdělit na 3x56b, tedy velikost odpovídající klíčovému materiálu pro DES. Vlastní autentizační algoritmus se chová téměř stejně a má stejné chyby jako algoritmus LANMAN.

Negotiate (Client –> Server): Send U=Username
Challenge (Server –> Client): Send CS=Challenge (8B Server challenge)
K1 || 0x00 || K2 || 0x00 || K3 || 0x00, 0x00, 0x00 = NTLM-Hash
RC = DES(K1,SC) || DES(K2,SC) || DES(K3,SC)
Authenticate (Client –> Server): Send RC

Vlastní jádro autentizačního mechanismu NTLMhash má zápis:
NTLMhash=MD4(UTF-16-LE(password))

Mezi největší slabiny autentizačního schématu:

• Příliš krátká challenge.
• Chybí sůl (např. uživatelská challenge), zajišťující odlišení hesel mezi jednotlivými uživateli.
• Nemá ochranu proti relay útoku.
• Nemá ochranu proti replay útoku, částečnou ochranu vytváří pouze challenge poskytnutá serverem (PtH - pass the hash).
• Chybí obousměrná autentizace (mutual authentication).
• Nemá ochranu proti MITM útoku.
• Nepodporuje MFA.

Mechanismus NTLMv2

Až teprve NTLMv2 vyřešil část problémů s původními mechanismy. Bohužel se objevil v době, kdy přišly na scénu útoky na MD5. Zatím sice nedošlo k prolomení HMAC funkce založené na MD5, na druhou stranu bylo jasné, že tento postup je jenom jakási znouzecnost. Přesto je dodnes uvedený mechanismus jedním ze základních autentizačních schémat a pokud není k dispozici jiná metoda autentizace, tak i postup jediný.

Mezi největší slabiny autentizačního schématu:

• Příliš krátká challenge.
• Nemá ochranu proti relay útoku.
• Nemá ochranu proti replay útoku, částečnou ochranu vytváří pouze challenge poskytnutá serverem (PtH - pass the hash)
• Chybí obousměrná autentizace (mutual authentication).
• Nemá ochranu proti MITM útoku.
• Nedostatečná podpora MFA
  

Negotiate (Client –> Server): Send U=Username
Challenge (Server –> Client): Send CS=Challenge (8B Server challenge)
CC = 8-byte client challenge, random
CT = (version, time, CC, domain name)
NTLMv2hash = HMAC-MD5(NTLMhash, User Name||Domain Name)
LMv2 = HMAC-MD5(NTLMv2hash, SC, CC)
NTv2 = HMAC-MD5(NTLMv2hash, SC, CT)
RC = LMv2 || CC || NTv2 || CT
Authenticate (Client –> Server): Send RC

Vlastní jádro autentizačního mechanismu se opět opírá o původní algoritmus NTLMhash, který je upraven pomocí další vrstvy ochrany. Ta je řešená díky HMAC-MD5 a pro zajištění vztahu mezi heslem a uživatelským účtem dochází k navázání na uvedené informace. Objevuje se tu i jednoduchá forma ochrany před replay attack za pomoci časové značky.
NTLMv2hash=HMAC-MD5(NTLMhash, user name||domain name)
Rozepsaný zápis potom jako:
NTLMv2hash=MD5(MD4(UTF-16-LE(password)) ⊕ 0x5c5c..5c,
                  MD5(MD4(UTF-16-LE(password)) ⊕ 0x3636..36,username||domain name))

Příchod Active Directory a mechanismus Kerberos

Historie protokolu Kerberos se začala psát v roce 1983 jako interní projekt pro ověřování v rámci MIT. První tři verze byly použity pouze interně. Následně v rámci projektu Athena [7] vznikla verze 4. Tu napsali Steve Miller a Clifford Neuman, uvolnili ji 24.ledna 1989. Kvůli exportním omezením nebylo možné použít algoritmus DES a proto byly v zahraničí vytvořeny další verze. U jedné z nich byl autorem Eric Young a byla vytvořena v Austrálii, druhá byla vytvořena ve Švédsku (KTH-KRB). V roce 2006 byl oznámen konec podpory algoritmu DES a tím došlo k ukončení podpory Kerberos v4. V roce 1993 vyšel Kerberos v5, jehož autoři byl opět Clifford Neman a spolu s ním John Kohl. Jeho rozšíření v roce 2005 odstranilo podporu algoritmu DES, RC4-HMAC-EXP a dalších zranitelných algoritmů, na druhou stranu přidalo podporu pro algoritmus AES. V současnosti vývoj zastřešuje konsorcium Kerberos [8] a MIT Kerberos konsorcium [9].
Kerberos byl zcela nový přístup k problému autentizace do systému, který byl použit poprvé v Active Directory systému Windows 2000. Přesněji, Microsoft ho zde poprvé použil. Jedná se prakticky o implementaci Kerberos 5 s některými omezeními, které jsou dané podporovanými kryptografickými algoritmy. Mimo vysvětlení jak tento protokol pracuje je důležité i upřesnění, jak přesně protokol Kerberos v prostředí Microsoft Windows využívá určitá nastavení a specifické sady kryptografických protokolů. Základní popis je vcelku jednoduchý. V rámci ověření se uživatel identifikuje autentizační službě (AS – Authentication Server). Protože uživatel i autentizační služba znají přihlašovací údaje, server vytvoří klíč služby (token) pro (TGS – Ticket Granting Server), šifrovaný za pomocí tajného klíče klienta (heslo nebo údaj odvozený od hesla). Na základě tohoto klíče uživatel může dešifrovat důležité údaje, které mu umožní komunikovat s TGS. Ten následně přidělí tiket pro autentizaci mezi klientem a serverem a poskytuje informace důležité pro spolupráci. Pro představu jak tento protokol pracuje je vhodné si projít jednotlivé kroky komunikace, zdrojové soubory síťové komunikace je možné stáhnout na webu Wireshark, sekce Kerberos [10].

Komunikace mezi jednotlivými účastníky probíhá po portu UDP/88 a TCP/88. Mezi největší slabiny autentizačního schématu patří:

• Slabé, dnes nedoporučované algoritmy pro zajištění integrity zprávy - CRC32, MD5, SHA1.
• Slabé, dnes nedoporučované algoritmy pro zajištění důvěrnosti zprávy - DES, 3DES, RC2, RC4.
• Exportni verze algoritmů s cíleně oslabenými mechanismy (40b heslo, oříznuté výstupy hash funkcí).
• Možnost zneužití hashí hesel:
  • PtH - pass the hash
  • Oth - Overpass the hash
  • PtT - Pass the Ticket
  • PtC - Pass the Cache)
• Chybí obousměrná autentizace (mutual authentication).
• Nemá ochranu proti MITM útoku.
• Nedostatečná podpora MFA.

Důležité informace:

• AS - Authentication Service je služba, která je součástí KDC. V případě Active Directory se zpravidla jedná o DC (Domain Controller). Jedná se o první hlavu Kerbera.
• TGS - Ticket Granting Service je služba, používaná pro přidělování tiketu. Prakticky druhá hlavu Kerbera.
• AP - Application Server nebo jenom server, nabízí službu požadovanou uživatelem. Jde o třetí Kerberovu hlavu.
• KDC - Key Distribution Center, obsahuje AS a TGS.
• PAC - Privilege Attribute Certificate ke struktura používané v téměř každém tiketu a je podepsaná pomocí KDC klíče.
• TGT - Ticket Granting Ticket je tiket, kterým se prokazuje na KDC pro získání informací od TGS. TGT je šifrováno pomocí KDC klíče.

• Uživatelský klíč (K_C, Key_Client) - je v případě Active Directory odvozen od NTLM hashe nebo se jedná přímo o NTLM hash.
• TGS klíč (K_TGS, Key_{Ticket Grantig Service}) - také KDC nebo krbtgt key (účet krbtgt), v případě Active Directory je odvozen od NTLM hashe účtu (uživatele nebo služby).
• AP klíč (K_AP, Key_{APplication server}) - klíč služby, účtu služby nebo stroje, je odvozen od NTLM hashe nebo se jedná přímo o NTLM hash.
• KTS klíč / klíč relace (K_TS, Key_{Ticket Session}) - je náhodně generován TGS a označuje se jako Session Key.
• KSS klíč / klíč relace služby (K_SS, Key_{Service Session}) - je generována na základě časové značky. Ve většině dokumentů se označuje jako K_CS nebo Service Session Key

Rozpis vyměňovaných zpráv:

V případě, pokud je použito defaultní nastavení, tj. není nastavena politika šifrování komunikace, používá se algoritmus RC4-HMAC, jinak také RC4-HMAC-MD5. Ono to není zcela pravda, na začátku se používaly algoritmy DES. U Kerberos komunikace to lze poznat například v programu Wireshark při analýze komunikace dle hodnoty etype 23, v případě exportu do textového tvaru zpravidla dle úvodního řetězce „23/0x17h“. Poznámka na okraj, DES používal hodnoty etype "1/0x01h" a "3/0x03h". Za této podmínky dochází k použití NTLMhash uživatelského hesla jako klíče pro šifrování. To zároveň znamená problém, a to hlavně díky útokům na RC4, kterou je dnes možné zlomit v intervalu okolo 12sec. Dále, protože se zde nepoužívá se žádný generátor hesel, solí nebo nonce, proces ověření díky tomu probíhá extrémně nešťastným způsobem s možností získat uživatelská hesla.

Pokud je nastavena politika šifrování, ale nejsou splněny další podmínky (tedy není functional Forest Level alespoň na úrovni Active Directory version 2012 a uživatelé nejsou v odpovídající user security group „Protected Users“), dochází sice k šifrování pomocí algoritmu AES, ale stále se používá jako heslo NTLMhash. V těchto případech je použit identifikátor ticketu „17/0x11h“ nebo „18/0x12h“, ale není možné bez další analýzy odlišit kvalitu a nepředvídatelnost klíčového materiálu.

Pokud je nastavena politika šifrování a jsou splněny podmínky (functional Forest Level alespoň na úrovni Active Directory version 2012 a uživatelé jsou v security group „Protected Users“), dochází k šifrování pomocí algoritmu AES a klíčový materiál se odvozuje od NTLMhash a dalších informací. Pro generování se používá funkce KDF (PBKDF2 dle RFC 3962, section 4), která dovoluje vytvořit pseudonáhodný a nepředvídatelný klíčový materiál pro šifrování tokenu. Tím je zajištěna vyšší bezpečnost ochrany. Tyto tokeny mohou mít hodnoty „17/0x11h“, „18/0x12h“, „19/0x13h“ nebo „20/0x14h“. V rámci derivace klíčového materiálu se jako passphrase používá stále NTLMhash, který dovoluje pomocí PBKDF2 odvodit dočasný klíč. Jako hash funkce se na starších systémech používá zpravidla HMAC-SHA1, na novějších pak HMAC-SHA2. Počet iterací algoritmu je nastaven na 32768 iterací, tuto hodnotu je naštěstí možné změnit (zvětšit). Hodnota keylenght se liší dle použití AES-128 (128b) a AES-256 (256b).

tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
key = DK(tkey, "kerberos")

Poslední možností, která je v současnosti k dispozici je nastavení politiky šifrování a splnění rozšířených podmínek (functional Forest Level alespoň na úrovni Active Directory version 2019, uživatelé jsou v security group „Protected Users“ a je zvolena KDF2 funkce pro generování náhodného klíčového materiálu). V tomto případě dochází k šifrování pomocí algoritmu AES a klíčový materiál se odvozuje od NTLMhash a dalších informací, kdy se pro generování používá funkce KDF2 [6]. Ta dovoluje vytvořit pseudonáhodný a nepředvídatelný klíčový materiál pro šifrování tokenu novějším přístupem, založeným na standardech IEEE Std 1363-2000, ANSI X9.42 (KDF1) a ISO 18033-2 (KDF2). Tyto tokeny mohou mít hodnoty pro šifrovací sady „17/0x11h“, „18/0x12h“, „19/0x13h“ nebo „20/0x14h“. Derivace klíčového materiálu stále využívá hodnotu NTLMhash, který dovoluje pomocí KDF2 odvodit dočasný klíč. Jako hash funkce se používá HMAC-SHA2. Počet iterací algoritmu je nastaven na 32768 iterací, tuto hodnotu je stejně jako v předchozím případě možné změnit. Hodnota keylenght se liší dle použití AES-128 (128b) a AES-256 (256b).

Povolení KDF2:
Set-AdfsProperties -KdfV2Support enable

Popis funkce KDF2:
KDF2=hash(input||I2OSP(1,4))||.….||hash(input||I2OSP(k,4))
kde
k=[l/délka výstupu hash funkce]

Popis funkce I2OSP
I2OSP je Integer to Octet String Conversion Primitive (Victor Shoup, I2OSP[6]). V tomto případě dochází k výběru 4B hodnoty ze vstupního textu (l=4), které se považují za číslo a následně je s nimi nakládáno jako s číslem. KDF2 vytváří sérii hodnot rozšiřující vstup.

Přehled existujících a podporovaných kryptografických algoritmů v Active Directory, protokol Kerberos. Podpora označená Ano^V (s výhradou) znamená označení algoritmu za zastaralý a nevyhovující, zpravidla je nutné ho zapnout manuálně. Dostupnost takového protokolu je pouze pro účely kompatibility. Postup změny nastavení je velice dobře popsán např. na webu Samuraj [11].

Poznámka: Ano^V (s výhradou) znamená označení mechanismu jako výběhového a může být nutné ho samostatně povolit.

Konfigurace krb5.conf v prostředí Linux

V případě kerberos klienta v sítích, kde je AD kontroler ještě není na Windows 2019, ale je odpovídajícím způsobem nastaven, je možné použít konfiguraci podporující alespoň oslabenou implementaci využívající AES. Soubor krb5.conf pak může obsahovat:

[libdefaults]
default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
allow_weak_crypto = false

Pokud je AD kontroler na Windows 2019+ a je odpovídajícím způsobem nastaven, je možné použít konfiguraci využívající AES ve všech podobách. Soubor krb5.conf pak může obsahovat:

[libdefaults]
default_tkt_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
default_tgs_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
permitted_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
allow_weak_crypto = false

A konečně, pokud v síti neexistují starší systémy než Windows 11 a Windows 2019, systém má odpovídajícím způsobem nastavené politiky bezpečnosti, je patrně nejrozumějším řešením nastavit systém pro použití dostatečně odolných implementací šifrovacích sad založených nad AES. Soubor krb5.conf pak může obsahovat:

[libdefaults]
default_tkt_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128
default_tgs_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128
permitted_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128
allow_weak_crypto = false

Soubor krb5.conf obsahuje defaultně šifrovací sady:
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4

Závěr

V současnosti nemá smysl používat staré autentizační mechanismy jako je LANMAN a NTLMv1. Tyto mechanismy nejsou schopné zaručit ochranu a zároveň představují výraznou komplikaci pro snahy o zabezpečení systémů. V případě využití uvedených mechanismů pro přístup ke sdíleným složkám pak uvedené mechanismy jsou schopné zajistit ověření uživatelů pouze na desítky let starých protokolech.
Aktuální mechanismy jako je Kerberos a NTLMv2 (v případech kdy není možné použít Kerberos) je možné v případě správného nastavení využívat pro přístup k souborům. Přestože systémy dnes nabízí další formy ověřování jako je Hello, SAML nebo Microsoft Account, ty není možné použít pro lokální ověření na síti. Vždy zprostředkovaně využívají již uvedené mechanismy.

Autor článku:

Jan Dušátko

Jan Dušátko se počítačům a počítačové bezpečnosti věnuje již skoro čtvrt století. V oblasti kryptografie spolupracoval s předními odborníky např. s Vlastimilem Klímou, či Tomášem Rosou. V tuto chvíli pracuje jako bezpečnostní konzultant, jeho hlavní náplní jsou témata související s kryptografií, bezpečností, e-mailovou komunikací a linuxovými systémy.