Ľahký úvod do security 3.: Autentifikácia do systému

Pre upresnenie dnes sa nebudem venovať lokálnej stanici ale prihlasovaniu Klient / Server.

Bežné je prihlásenie užívateľov do systému v doméne či cez VPN. Obe varianty pracujú na princípe klient server a to nasledovným spôsobom:
dopyt "Hi, Its Me"(klient) ---> (server) /
/ request "pls authentificate" (server) ---> (klient) autentifikuje sa /
/ (odošle Username. password) ---> request accept (server) /
/ odošle username a access a akceptuje prihlásenie (server) ---> klient je prihlásený
(Ide o "jednoduché" zhrnutie)

No ako je to z bezpečnosťou? Nuž vždy musí ísť o kryptovanú (šifrovanú) komunikáciu.
Kryptografické prostriedky sú motorom celej bezpečnosti. Hash funkcie ako sha1, autentifikačné kódy HMAC, ako aj protokol SSL musia byť použité správne a implementátor schémy im musí rozumieť.
Napríklad SSL nie je autentifikátor užívateľa, hoci môže autentifikovať užívateľa pomocou cerifikátu X.509, ktorý patrí k technológii PKI a tá nie je veľmi mobilná. SSL teda zabezpečí len dôvernosť pre autentifikátory a data.
Momentálne sa na autentifikáciu užívateľov primárne používajú heslá, preto ich treba obzvlášť chrániť, hlavne ak užívateľ je nedisciplinovaný a musí si pamätať niekoľko hesiel na viaceré systémy. Odhalenie hesla vedie ku kompromitácii celého užívateľa a teda servery by nemali prezentovať heslo užívateľovi. Nevyhnutnosť je preposlať heslo kryptovane (HASH, SSL). Optimálne je heslo posielané s klienta serveru jediný raz a spätné nadviazanie kryptovaného spojenia na základe jednorazového generovaného ID.
Optimálne je nastavenie "silného" hesla. Čo napríklad pri konte MARTIN môže byť v tvare maRt!n48 kde číslo nie je žiadne z dátumu a podobne.
Bohužiaľ väčšina ľudí použije heslo martin123 (alebo martinxyz kde xyz su po sebe iduce číslice). Ďaľším jasne daným špecifikom by malo byť 3x a dosť. Kde nejde o trest smrti ale o uzamknutie konta alebo povedzme zamietnutie daľších pokusov na 15 minút až hodinu.
Pred citlivými operáciami, ako je napríklad zmena hesla, by mal server vyžadovať reautentifikáciu. Keďže pri kompromitácií konta by útočník zmenil údaje a mohol by konto používať a majiteľ by sa k nemu nedostal. Optimálne je zaslať email na adresu sekundárneho mailu (súkromná schránka) ktorá nie je public alebo nie je vydedukovateľná z tvaru užívateľského mena (napr.: meno.priezvisko@firma.sk).
Používať a chrániť autentifikátory, ktoré nahrádzajú heslo v komunikácií klientom/server. Sú to cilivé dáta, ktorých prezradenie môže viesť k neoprávnenému prístupu. Oproti heslám majú výhodu že sú flexibilné (jednorázové). Pri každom kontakte môže byť odovzdavý iný autentifikátor platný pre užívateľa. Heslá sú väčšinou menené len vtedy ak je užívateľ "prinútený". Netreba zabúdať, že heslo je teoreticky kompromitované pri prvom použití. Optimálne je meniť heslá raz za 30 dní, pri dôležitých kontách (admin) každých 7 dní.
Spoľahlivé nasadenie ktoré má zabrániť kompromitácií nesmie byť ľahko odhaliteľné. Zlým príkladom autentifikácie môže byť autentifikátor pozostávajúci z ID čísla a email adresy v cookie. Autentifikátory často obsahujú identifikátory session a to nestačí, dôležité je aby boli náhodné.
Autentifikátor by mal pozostávať: ID užívateľa, doplňujúce údaje a dodatkové (readonly) údaje. Meno užívateľa je jasné, doplňujúca by mala byť informácia povedzme o IP alebo MAC adrese (pri VPN je odporúčané uzamknúť konto na MAC adresu). A dodatkový údaj, ktorý by bol iba na čítanie je nejaký HASH-ovaný údaj, dodatkové informácie, mali by byť jednoznačne oddelené. Napríklad reťazec usernameaccess, môže byť interpretovaný ako user / nameaccess a nie ako je bežné username / access. Ako oddelovač sa najčastejšie používa ampersand &. Pretože sa predpokladá, že kľúč nie je záškodníkovi známy, nemôže ani pozmeniť obsah autentifikátora.
Ak je na uloženie autentifikátora použíté cookie, je nevyhnutné, aby mal cookie zapnutý príznak secure. Ďalšou možnosťou kam umiestniť autentifikátor je URL. Mnohé servery to tak robia hoci HTTP v. 1.1 to nedoporučuje. Webový prehliadač totiž uloží aktuálnu hodnotu URL (aj s autentifikátorom) do HTTP hlavičky s názvom referer a takúto požiadavku pošle na nový, kliknutý server. Vkladanie Referer položky do HTTP hlavičky je štandardné správanie sa prehliadača a nedá sa vypnúť. Vlastnosť sa často používa v XSS (cross site scripting útokoch). Ďalej odporúčam nepoužívať súborové cookie. Server má možnosť určiť či prehliadač bude držať cookie v pamäti, alebo ho uloží na disk do súboru.
Ukladanie do súboru umožňuje dve hlavné možnosti na zneužitie. Niektoré, "správne" napísané vyhľadávacie programy pri vhodnom dopyte zobrazia obsah súboru s cookie, a tým k získaniu autentifikátorov. Druhá nepríjemnosť spočíva vo verejných prístupových bodoch. V tom prípade, ktokoľvek, kto príde k pc má možnosť prečítať súbor cookies.
Odporúčané je nastaviť timeout autentifikátora ako jeho súčasť (kryptovaný časový údaj). Po uplynutí doby životnosti server, ktorý by prijal ukradnutý autentifikátor, zistiť falzifikát a odmietnuť autorizovať odosielateľa. Ako som uviedol vyššie odporúčam viazať VPN na MAC adresu. Tým sa znižuje možnosť na replay útok keďže by útok musel prebehnúť z toho istého PC alebo musí útočník poznať danú MAC adresu (MAC spoof). Určite neodporúčam viazať na IP keďže môže ísť o IP proxy alebo nemusí mať pevnú IP. Na druhej strane však užívateľ musí použiť to isté PC.

No po dlhsom case som zas pripravoval (a dokoncievam) clanok o security. Vzhladom k casu ktory mi uteka tak som hladal do prednasky nejake zaujimave video (no lenivost ma naucila hladat bocne cesticky) a kedze som potreboval este VM Ware appliance na Back Track tak som snoril a nuchal:-)
Vysledok je nizsie. Len pre neinformovanych pred akym kolvek prevedenych technik je dobre poznat aspon zaklady zakonov tu je predvedeny takzvany eticky hacking, alebo inak povedana bezna security prax pri testovani prelomitelnosti ochran.

To je zatial vsetko a tu su linky:
Offensive Security dema
Offensive Security predviedli za pomoci BT (BackTrack) v ramci etickeho hackingu vzdialene prevzatie PC. Pekne:-)
Security blogy
Ethical Hacker Comunity pokial by to niekoho zaujimalo.

Mimochodom nieco podobne je aj v AT kde je firma X-Soft a ta riesi testy a projekty na security ;)