Počítačová bezpečnost 8. Uživatelé a oprávnění Obsah: unixové systémy: uživatelé, hesla, oprávnění, speciální oprávnění Microsoft Windows: uživatelé, MIC, UAC SMB, Doména Windows, Active Directory LM hash, NT hash © Milan Keršláger http://www.pslib.cz/ke/slajdy 1. 12. 2016 http://creativecommons.org/licenses/by-nc-nd/3.0/

Unixové systémy

Uživatelé jádro OS pracuje s UID (celé číslo, dnes 32bitů) správce (administrátor) → root (UID=0) není jádrem OS omezován může se změnit na libovolného uživatele využíváno při přihlašování (uvítací program jako root) běžný uživatel → UID!=0 může zasahovat jen do vlastních souborů, procesů využívá se systém oprávnění NEmůže se změnit na jiného uživatele UID se ve výpisech se překládá na jméno podle /etc/passwd (lepší srozumitelnost)

Definice uživatelů uloženo v souboru /etc/passwd jednoduchá databáze (chyba → zbytek se nepoužívá) 1 řádek = 1 uživatel, položky odděleny znakem „:“ login:passwd:UID:GID:FullName:HomeDir:shell využívá se při překladu UID → jméno uživatele (ls -l) založení uživatele prosté přidání dalšího řádku lze i editorem nástroje (GUI, useradd, userdel) používáme kvůli zamykání (editační konflikt)

/etc/passwd na prvním řádku je typicky root root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt mail:x:8:12:mail:/var/spool/mail:/sbin/nologin ... huzva:x:500:500:René Hužva:/home/huzva:/bin/bash na prvním řádku je typicky root dále jsou tzv. systémové účty se speciálním využitím některé mají GUID=0, takže je to „malý root“ tři tečky naznačují řádky, které byly v ukázce smazány

Uložení hesel používá se hashovací funkce při krádeži hashe nelze zjistit původní heslo hashovací funkce jsou jednosměrné lze využít útok hrubou silou zkoušíme všechna možná hesla a počítáme hash výsledek je stejný, jako uložený tvar → heslo nalezeno jednodušší je slovníkový útok zkoušíme zakódovat a porovnat omezený počet hesel nejjednodušší jsou duhové tabulky rainbow table → předpočítané hashe pro různá hesla obranou je kryptografická sůl

Skrytá hesla (shadow passwords) heslo zakódováno jednosměrnou funkcí původně crypt(), později md5, sha1, sha2 kryptografická sůl (1 heslo = více zakódovaných tvarů) i tak lze použít útok hrubou silou bereme všechny kombinace hesel (využití slovníku) zakódujeme a porovnáme s uloženým tvarem dnes tzv. „rainbow table“ → otázka vteřin (md5, sha1) ukrytí hesel do souboru /etc/shadow může číst jen root, běžný uživatel ne nevadí, protože před přihlášením oprávnění root běžný uživatel si zakódované tvary nepřečte

Kryptografická sůl ochrana uloženého hesla znemožňuje použití duhových tabulek sůl je náhodné číslo při uložení hesla je sůl použita pro výpočet hashe typicky 16, 24, 32, 64 bitů, ale i delší při ověření: buď zkusíme všechny možné soli může být náročné na výpočetní výkon, prodleva při ověření nebo je sůl uložena společně s hashem hesla nevadí to, protože stále nelze použít duhové tabulky

/etc/shadow opět jednoduchá databáze login:passwd:další:údaje:... další údaje upřesňují vlastnosti hesla poslední změna hesla, platnost hesla, účtu, povinná změna, zákaz změny hesla uživatelem, ... soubor může číst jen uživatel root zašifrovaná hesla chráněna před zcizením nelze použít útok hrubou silou změna hesla uživatelem → SUID (speciální oprávnění) root:6$630fCdtG$:14632:0:99999:7::: huzva:465sWTI1pX/:14251:0:99999:7:::

Autentizace uživatele uživatele vítá proces s právy správce uživatel sdělí svoje jméno + heslo podle soli se vypočte hash porovná se s uloženým hashem je-li v pořádku, proces změní své oprávnění změna ze správce na uživatele možná je změna zpět již není možná další procesy jsou potomci tohoto procesu oprávnění se dědí, změna jen přes SUID, SGID

Tradiční unixová oprávnění velmi jednoduchá v době vzniku Unixu málo výkonné počítače (1969) jde o rychlost souborového systému (FS – filesystem) žádná dědičnost, vše na konkrétní adresář, soubor ke čtení ze souboru jsou nutná metadata metadata jsou v i-node, který obsahuje i oprávnění využijeme data, která stejně musíme načíst → efektivní „svatá trojice“ – jednotně pro soubory i adresáře 3 druhy: čtení, zápis, spuštění (Read, Write, eXecute) 3 cíle: vlastník, skupina, ostatní

Význam oprávnění Soubor Adresář Read (čtení) Write (zápis) eXecute (spuštění) čtení (zobrazení) obsahu souboru výpis obsahu adresáře (příkaz ls) změna obsahu adresáře (vytvoření, smazání a přejmenování položek) zápis do souboru (změna obsahu) vstup do adresáře (musí být i ve všech nadřízených) spuštění (provedení) binárka, skript

Uplatňování oprávnění řízení přístupu podle modelu DAC uživatel má definováno UID a GID (těch i více) objekty oprávnění pro vlastníka, skupinu a ostatní uplatňují se jen nejkonkrétnější oprávnění jsem-li majitel → práva pro vlastníka patřím do skupiny, ale nejsem majitel → pro skupinu nejsem ani vlastník, ani skupina → práva pro ostatní POZOR: (!!!) žádný (!!!) průnik ani sjednocení atp.

Zobrazování oprávnění pro objekty (soubor, adresář) zobrazuji: tři trojice oprávnění (Read, Write, eXecute) vlastník, skupina, ostatní rwx rwx rwx ve výpisu musí být k objektu vypsán: vlastník skupina

ls -l typ objektu počet odkazů -rw-rw-r-- 1 huzva www 801512 led 22 2009 seznam.txt tři trojice oprávnění název skupina čas poslední změny obsahu vlastník délka Typ vypsaného objektu: - → obyčejný soubor d → adresář (directory) b → blokové zařízení (block) c → znakové zařízení (char) p → roura (pipe) s → soket Počet odkazů je počet jmen (v adresářích), které odkazují na daný objekt. Souvisí s pevnými odkazy („hardlink“). U adresářů se započítává odkaz z vnitřku samotného adresáře (tj. dvě tečky „..“) a další případně obsažené podadresáře.

Příklad výstupu $ ls -ld /dev/ttyS0 /dev/sda web.tgz vyuka brw-r----- 1 root disk 8, 0 bře 19 06:28 /dev/sda crw-rw---- 1 root uucp 4, 64 bře 19 06:28 /dev/ttyS0 drwxrwxr-x 4 rene www 4096 pro 18 07:18 vyuka -rw-r--r-- 1 rene rene 550258 lis 7 2008 web.tgz $ stat ucitele.txt File: `ucitele.txt' Size: 2280 Blocks: 16   IO Block: 4096 regular file Device: fd00h/64768d Inode: 9132416 Links: 1 Access: (0644/-rw-r--r--) Uid: (500/huzva) Gid: (500/huzva) Access: 2009-10-01 09:17:19.000000000 +0200 Modify: 2008-08-29 08:31:50.000000000 +0200 Change: 2008-08-29 08:31:57.000000000 +0200

ACL – Access List rozšíření tradičních unixových oprávnění i na složitější situace stačí tradiční + speciální oprávnění pomocí ACL může mít objekt (soubor/adresář) další klasická oprávnění pro další uživatele i skupiny využívá tradiční trojici oprávnění (rwx) definováno normou POSIX implementace v Linuxu (výhodné pro Sambu) existuje dlouho, ale problémy – vyřešeno 2005 současné distribuce mají ACL implicitně zapnuto ACL se dá selektivně aktivovat pro jednotlivé FS

Speciální oprávnění tradiční součást unixových systémů mění standardní chování systému (s oprávněním) standardně se oprávnění u procesů dědí (z rodiče na potomka) SUID bit program běží s právy vlastníka binárky SGID bit program běží s právy skupiny vlastnící binárku sticky bit umožňuje mazat a modifikovat jen vlastní soubory pro adresář /tmp → všichni do něj mají právo zápisu

Využití SUID bitu nutné pro změna hesla soubor /etc/shadow běžný uživatel nepřečte program (passwd) na změnu hesla je SUID root /usr/bin/passwd získá po spuštění oprávnění roota program se SUID musí být jednoduchý, bezpečný musí dovolit změnu hesla jen aktuálnímu uživateli při chybě by uživatel mohl např. měnit cizí hesla (nebo změnit cokoliv v celém systému) $ ls -l /etc/shadow /usr/bin/passwd -r--------. 1 root root 1753 26. bře 23.16 /etc/shadow -rwsr-xr-x. 1 root root 25464 28. led 17.12 /usr/bin/passwd

Další využití SUID bitu su, sudo, SuperSU (Android) pro změnu uživatele, provedení privileg. příkazu ping, mtr vyžaduje raw socket, dnes již pomocí capabilities pro mtr obvykle nenastaveno (kvůli bezpečnosti) správce systému to může risknout: chmod +s /usr/sbin/mtr X Server (dnes již bez SUID → Rootless X) kvůli přímému přístupu k hardware (graf. karta) již nepotřebuje díky KMS (kartu řídí jádro)

SELinux doplňující zabezpečení pro Linux implementuje MAC (Mandatory Access Control) přesněji RBAC → Role-based Access Control na souborech jsou rozšířené atributy definované role pro různé skupiny programů → i proces běžící jako root může být omezen vytvořila NSA v USA (Národní úřad pro bezpečnost) používá Fedora a klony RHEL (CentOS), Android (!) 3 režimy: disabled, permissive (jen hlášení, bez omezení), enabled největší chyba je SELinux po instalaci zakázat :-(

Co umí SELinux typicky různá omezení omezení zápisu na disk na spustitelném souboru atribut webový server, FTP server, přepravce el. pošty, ... na adresářích atributy → striktní omezení zápisu síťový démon SSHD potřebuje být root → změna na uživatele root ale může „všechno“, což je velmi nebezpečné osekáme možnosti démona jen na změnu ID (po autentizaci) hooky jsou rozmístěny v jádře systému na „strategických“ místech je odskok do SELinuxu

AppArmor doplňující zabezpečení pro Linux implementuje MAC (jako SELinux) nevyužívá rozšířené atributy řídí se podle cesty ke spouštěné binárce vytvořila firma Novell používáno v SLES, openSUSE, Ubuntu jednodušší správa není tak komplexní, jako SELinux

Systémy Microsoft Windows

Uživatelé lokálně autentizovaní uživatelé definováni v tom kterém příslušném počítači rozlišeni dlouhým číslem (SID → Security Identifier) heslo → LM hash, NTLM heslo lze přepsat → start z CD (Linux → chntpw) síťoví uživatelé definováni na serveru stanice je může akceptovat (důvěřovat serveru) je-li v Doméně Windows nebo v Active directory tj. lokálně uživatel neexistuje, ale může se přihlásit je mu vytvořen profil, převezme se SID ze serveru

Oprávnění ve Windows posuzuje se SID, oprávnění zapsána v ACL některá SID jsou speciální: lokální uživatelé: Administrator, guest, System user, ... skupiny Administrators, PowerUsers, PrintOperators, ... oprávnění v NTFS klasický DAC systém s vlastníkem (jako Unix) dnes navíc ještě MIC (tokeny, UAC) síťová oprávnění čtení, zápis, čtení+zápis (z Windows pro DOS) uplatňují se při přístupu skrze síť

Speciální SID

Oprávnění v NTFS „zjednodušená“ a „skutečná oprávnění“ tj. dva dialogy pro nastavení oprávnění zjednodušená obsahují několik skutečných běžně se používají pouze ta zjednodušená viz http://www.pslib.cz/ke/files/PravaWin.pdf

Problém Administrátora ve Win ještě ve Windows XP všichni jako Administrator problém: uživatel může snadno poškodit systém nový problém: Internet přináší do počítače bez možnosti důkladné kontroly nedůvěryhodná data → malware se snadno šíří skrz e-mail, www jenže aplikace (včetně Microsoft Office) potřebovaly ke své funkci Administrátorské oprávnění například zápis konfigurace do globálních registrů nebo do adresáře, kde je nainstalován program Microsoft se ani nepokusil zajistit, aby uživatelé pracovali jako běžný uživatel Unix: odjakživa je účet správce jen pro správu systému (pozn)

MIC Mandatory Integrity Control uvedeno ve Windows Vista (2007), Server 2008 dodatečné zabezpečení a separace procesů opatření v rámci jednoho uživatele (!!!) tím je možné být „Administrátor“, ale zároveň jím nebýt proces uživatele má „bezpečnostní token“ funguje jen na procesy zahrnuté do UAC tedy nikoliv na služby (services), síťové služby apod. systém při přístupu k objektu, který je krytý bezpečnostním atributem zjišťuje, zda proces má díky tokenu oprávnění operaci provést (čtení, zápis) → MAC problém interakce procesů stejného uživatele

Bezpečnostní token token je přidělen běžícímu procesu přiděluje ho logon proces prvnímu procesu uživatelova sezení po po úspěšné autentizaci uživatele (něco jako tikety u Kerberosu) další procesy ho dědí správce oken, panel, Skype, programy spuštěné z menu nebo pomocí Průzkumníka, příkazy v CMD.exe, ... obsahuje ID uživatele, GID, seznam oprávnění obsah tokenu nelze za běhu procesu měnit služba AIC umí přidělit novému procesu token s vyšším oprávněním

Integrity Level (IL) čtyři „bezpečnostní úrovně“ pro MIC Low (SID: S-1-16-4096) Protected mode pro Internet Explorer Medium (SID: S-1-16-8192) běžný uživatel (User group) High (SID: S-1-16-12288) na základě členství ve skupině Administrators System (SID: S-1-16-16384)

Člen skupiny Administrators je v podstatě Administrátor, jenže... :-) prvnímu procesu jsou přiděleny dva tokeny: administrátorský obyčejný (jako člen skupiny „Users“) při práci uživatele je aktivní ten druhý, obyčejný program si může vyžádat elevaci oprávnění: pomocí XML manifestu (součást EXE souboru) pro privilegovanou operaci je nutné spustit nový proces (helper) uživatel ručně pomocí „Run as Administrator“ program může svoje oprávnění snížit „Protected mode“ pro Internet Explorer 7+

UAC User Account Control česky „Řízení uživatelských účtů“ když (nový) proces potřebuje vyšší oprávnění zobrazí se okno s žádostí o potvrzení od uživatele kvůli zamezení spoofingu okolní plocha potemní tzv. „Secure desktop mode“ při vyšším UAC je nutné stisknout CTRL+ALT+DEL nebo i vložit heslo správce, přestože jsem správce tuto kombinaci nelze běžnou aplikací odchytit (jedině modifikací jádra, podvrženým ovladačem) převzato ze systému DOS → CTRL+ALT+DEL → restart PC mohla by to být jakákoliv jiná kombinace kláves

Vypnutí UAC nevyřadí MIC z činnosti tj. i člen Administrators je stále „běžný uživatel“ požadavek na elevaci ale nespustí UAC tím pádem nebude požadavek na elevaci proveden vyřadí však z činnosti přemapování zápisů tj. „File and Registry Virtualization“: HKLM „Program Files“ → %AppData% Poznámka: mám dojem, že po zakázání UAC mají procesy v systému menší překážky

UIPI User Interface Privilege Isolation UAC má „různá oprávnění“ u stejného uživatele s tím jádro OS nepočítá procesty stejného uživatele se mohou ovlivňovat s UAC je nežádoucí, aby proces s nižší Integrity level (IL) mohl ovlivnit proces s vyšším IL pro řešení útoku „shatter attack“ omezuje zasílání zpráv (se spustitelným kódem) bohužel funguje dobře jen pro low IL neřeší tedy všechny možné shatter attacky (!!!)

Run as Administrator spuštění procesu s privilegovaným tokenem kontextové menu (klik pravým tlačítkem myši) vyskočí UAC jsem-li členem Administrators → jen potvrzení (OK) jsem-li běžný uživatel → UAC žádá heslo správce při vyšším nastavení UAC: nutno stisknout CTRL+ALT+DEL, příp. i heslo správce proces pak běží skutečně s Administrátorským oprávněním (jinak běží s běžnými, viz dříve) viz výstup příkazu whoami v CMD.exe

Tichá elevace oprávnění ve Windows 7 (a novějších) pro programy v %system32% musí být navíc elektronicky podepsány Microsoftem je-li uživatel členem skupiny Administrators tedy má i „administrátorský“ token v takovém případě nevyskočí UAC tichá elevace je snahou o omezení počtu výzev UAC protože uživatel si „nacvičí prostě souhlasit“ ...a text v potvrzovacím okně prostě nečte zneužíváno pro „sideload“ jiného kódu je velmi obtížné ošetřit všechny možné scénáře

Protokol SMB SMB je zkratka pro Server Message Block původně protokol LAN Manager IBM a Microsoft, původně NetBIOS, dnes TCP/IP SMB zprávy se „vozí“ uvnitř nějakého síťového protokolu NetBIOS pro adresaci MAC adresy (funguje bez nastavování) IP adresy se musí přidělit, ale stejně je dnes každý potřebuje 1992: Andrew Tridgell → projekt Samba odhalil totožnost mezi DEC Pathworks a LAN Manager poskytované služby (pomocí RPC) sdílení souborů → UNC tisk na vzdálené tiskárny autentizace uživatelů (Doména Windows, Active Directory)

UNC Uniform Naming Convention označení umístění síťového zdroje pro sítě Microsoft Windows sdílený adresář, soubor, tiskárna \\Počítač\SdílenýAdresář\Upřesnění Počítač je jméno počítače (platné v síti Microsoft) sdílený adresář je název sdíleného prostředku upřesnění může být cesta (novější implementace) kořen připojeného disku lze umístit do podadresáře

Jména počítačů broadcast stanice vysílá broadcastem do sítě své jméno ostatní naslouchají a doplňují si svůj seznam stanice hlasují → master browser (ví „všechno“) WINS server server udržuje databázi jmen stanic opuštěno ve prospěch DNS řešení DNS příklon k řešení podle Internetu tj. převod jméno → IP adresa propojení s DHCP → stanice získá IP a zanese jméno do DNS

Mapování uživatelů winbind démon poskytující ve Windows mapování UID → jméno uživatele (a zpět) je nutné při sdílení souborů s oprávněními databáze uživatelů je na vzdáleném stroji sdělení jména uživatele (podle SID) při výpisu adresáře ugidd obdoba pro unixové systémy

Příklad (přístup ze sítě)

Počítače samostatné nejsou nijak vázané na ostatní počítače v síti takto fungovaly až do Windows 98 v doméně Windows počítač má na serveru vlastní účet vzniká „vstupem do domény“ (na heslo správce domény) při startu se počítač „přihlásí“ větší vztah důvěry mezi počítačem a serverem počítač uznává uživatele definované na serveru tzv. „doménový uživatel“

Doména Windows plochá centrální databáze uloženi uživatelé, skupiny, počítače uživatel: jméno, heslo, členství ve skupinách databáze uložena na PDC (Primary Domain Controller) usnadnění správy uživatel nemusí existovat na všech počítačích v doméně uživatel má jeden účet a jedno heslo v celé síti stěhující se profil domácí adresář se při přihlášení kopíruje na stanici při odhlášení se kopíruje zase zpět na server bohužel je to poměrně pomalá operace

Active Directory AD je nástupcem Domény Windows proprietální implementace LDAP + Kerberos Kerberos dává autentizační tokeny na omezenou dobu stromová databáze uživatelé, skupiny, tiskárny → objekty v AD kontext objektu → je v nějakém podstromu AD na kontext může být definován „malý administrátor“ větší škálovatelnost pro větší sítě jednodušší vztahy mezi stromy implementace AD serveru → Samba 4 je teprve ve vývoji, v roce 2012 pre-release

Autentizace v SMB NTLM (NT LAN Manager) autentizace pomocí jména a hesla řeší problém odposlechnutí autentizačních údajů je proto nutná kryptografická ochrana na serveru uložen hash, klient posílá také hash (MD5) NTLMv1 → DES, NTLNv2 → MD5, NTLMv2 Session → MS-CHAP z odposlechnutého hashe není možné získat původní heslo problém → šifrovaný tvar je vždy stejný (např. MD5) komunikaci lze odposlechnou a zašifrovaný tvar použít → toto je tzv. replay attack řeší se pomocí challenge-response (tj. NTLMv2)

Challenge-reponse metoda výzva → odpověď klient pošle serveru žádost o autentizaci server nabídne náhodné číslo klient použije na heslo hash a pak ono náhodné číslo výsledek je přenesen na server (odpověď klienta) server má na disku uložen hash hesla na hash stejná operace s náhodným číslem porovnání výsledku s odpovědí klienta je nepravděpodobné, že příště zvoleno stejné číslo nelze proto využít replay-attack, protože komunikace je závislá na vybrané náhodné hodnotě

LM hash původní způsob uložení hesla pro uložení hesel používáno do Windows NT později používáno kvůli zpětné kompatibilitě ve Windows Vista implicitně vypnuto → NT hash (NTLM) pro uložení hesla se nepoužívá kryptografická sůl pro autentizaci lze využít i ukradený hash → replay attack uložení hesla heslo je převedeno na velká písmena heslo je doplněno nulami na délku 14 bajtů heslo je rozděleno na dvě poloviny (po 7 bajtech) poloviny zvlášť zašifrovány pomocí DES

NTLM nástupce za LM hash autentizační protokol → challenge-response NTLMv1 NTLMv2 od Windows NT 4.0 SP4 NTLM2 session napadnutelné pomocí duhových tabulek