SSH je velmi rozšířeným protokolem nejen pro dálkovou správu unixových serverů, ale také pro přenos souborů, přesměrování portů a další úkony. V poslední době ale přibylo oznámení nejrůznějších bezpečnostních chyb, které ohrožují šifrovací algoritmy a hrozí únikem dat. Svůj podíl na tom mají i tajné služby, jejichž aktivita v tomto odvětví donutila uživatele klást si otázku: Je tohle vlastně ještě bezpečné?
Historický základ
Kořeny SSH sahají až do roku 1995, kdy na Helsinki University of Technology vyvinul Tatu Ylönen první implementaci nového protokolu, který měl za úkol zabránit odposlechu hesel na univerzitní síti. Autor se později rozhodl svůj software prodávat, a proto po čtyřech letech kód uzavřel a změnil jeho licenci. V tu chvíli se poslední otevřené verze chopili vývojáři projektu OpenBSD, kteří pokračovali ve vývoji otevřené verze. V tu chvíli začalo také masivní šíření software na mnoho různých platforem včetně linuxových a unixových operačních systémů.
V roce 2008 už mělo OpenSSH na internetu více než 80% podíl. V současné době je aktuální verze 6.8 a další je už ve fázi testování. SSH nahrazuje starší protokoly jako telnet, rlogin, rsh, rcp a ftp. Předpokládám, že jste o nich slyšeli a doufám, že žádný z nich už nepoužíváte,
řekl ve své přednášce na konferenci CryptoFest Jakub Jelen ze společnosti Red Hat a spolku vpsFree.cz. SSH umožňuje autentizaci bez hesla, ověření protistrany pomocí otisku klíčů, přesměrování portu nebo třeba přenos X11 sezení bezpečným kanálem. Zásadní také je, že SSH dnes není závislé na konkrétním hashovacím algoritmu, algoritmu výměny klíče nebo šifře.
V průběhu let byla část algoritmů označena za problémovou – například byla používaná šifra Blowfish, 3DES, RC4, IDEA nebo tehdy patentovaná RSA. Nebyly dobré, ale tehdy to bylo to nejlepší, co bylo k dispozici.
OpenSSH už pohřbilo řadu protokolů
Existují dvě verze protokolu označované jako SSH1 a SSH2. Původní protokol SSH1 je dnes považován za zastaralý a nebezpečný, což plyne také z toho, že byl vymyšlen v roce 1995 jedním člověkem. Když vymýšlíte něco na zelené louce, je nepravděpodobné, že to bude napoprvé správně.
Proto se v průběhu let objevilo několik různých zranitelností – nedostatečně kontrolovaná integrita dat, modifikace posledního bloku šifry IDEA a možnost MitM útoku. Dnes se s ním naštěstí člověk už nepotká, většina serverů a klientů je má zakázané. Problém je jen ve vestavěných systémech, které jej ještě někdy používají.
Od roku 2006 existuje SSH2, které je zpětně nekompatibilní, ale významně vylepšuje bezpečnost. Z dokumentů, které vynesl Snowden, je zřejmé, že NSA dokáže dekódovat ‚některá SSH spojení‘. Bohužel není zřejmé, co přesně a za jakých okolností je možné odposlouchávat.
Opět to ale důvod zabývat se celou bezpečností SSH, jak z pohledu algoritmů, tak jejich implementace v OpenSSH.
Známé vektory útoků
Pro bezpečnost SSH je zásadní bezpečnost výměny šifrovacích klíčů metodou Diffie-Hellman. Ta umožňuje předat protistraně informaci tak, že informace samotná zabezpečeným kanálem vůbec neputuje. Putují jen dílčí informace, které jsou ale bez znalosti nepřenášené části bezcenné. Pokud by v budoucnu někdo získal od jedné strany privátní klíč, stejně by nebyl schopen celou komunikaci dešifrovat. Ta je totiž zabezpečena jednorázovým symetrickým klíčem, který nelze vyčíst ani po dešifrování začátku komunikace.
Princip Diffie-Hellman: Alice a Bob si vymění barvy už smíchané, výsledkem je hnědá, která ale v komunikaci nefigurovala a je velmi obtížné ji odvodit.
Velmi známým útokem je takzvaný Logjam, který neútočí přímo na SSH, ale právě na výměnu klíčů pomocí Diffie-Hellman. Ta se netýká jen SSH, ale obecně TLS – potenciálně ohroženy jsou tedy i další protokoly jako HTTPS nebo VPN. Algoritmus výměny totiž předpokládá, že se na vstupu používají dostatečně velká prvočísla, která se navíc příliš často neopakují. Praxe je ale bohužel jiná. Ukázalo se, že na celém internetu se používá jen několik málo prvočísel a většina použitých čísel má velmi malou délku.
Přibližně v 90 % případů se používá asi jen pět prvočísel, která jsou navíc poměrně malá (512 bitů). Pří útoku Logjam je možné přimět server používat právě tato malá prvočísla – takzvaný downgrade attack. Servery tuto možnost stále obsahují kvůli zpětné kompatibilitě.
Většina běžně používaných aplikací navíc používá stále stejný seznam předgenerovaných čísel, který je k dispozici už od devadesátých let. Konkrétně v OpenSSH je připraveno třicet prvočísel, která mají délku 1024 bitů, a pak také další s větší délkou.
Problém totiž spočívá v pravděpodobnostních testech, které dovolují ověřit, zda je vygenerovaná hodnota prvočíslem. Tyto testy jsou velmi náročné a pro uživatele by bylo velmi nepraktické generovat si tímto způsobem vlastní sadu prvočísel.
Běžná faktorizace prvočísel je velmi náročný úkol, ale pokud bereme v potaz jen velmi malé množství prvočísel, můžeme provést jejich předzpracování. Pro 512 bitů to na milionu procesorových jader trvá přibližně týden. Samotné dešifrování spojení pak proběhne do jedné minuty. Je docela možné, že NSA takový výkon k dispozici má.
Současná verze OpenSSH odebrala prvočísla s délkou 1024 bitů, takže už není možné se se serverem dohodnout na jejich použití. Pomůže také samozřejmě zakázání starších protokolů a slabších šifrovacích algoritmů. Při délce 1024 bitů se nám doba předzpracování na milionu jader protáhne na 35 milionů let,
dodává Jelen.
Jakub Jelen, CryptoFest 2015
Bezpečnost SSH závisí také na dalších komponentách systému, jako je například Bash nebo standardní knihovna C. Na ně byly před časem předvedeny útoky jako ShellShock ze září 2014, POODLE z října 2014 a GHOST z ledna 2015. Pomocí nich je možné spouštět příkazy přes proměnné prostředí nebo dešifrovat zasílané zprávy. Naštěstí bylo možné tyto chyby poměrně rychle opravit, záleží však na správcích serverů a uživatelích, zda záplatují.
Kromě technických chyb jsou tu ale i problémy s lidským faktorem, který tu s námi je a vždy bude. Nejzajímavější jsou chyby vznikající mezi počítačem a židlí.
Zmíněna byla například úprava SSH v Debianu, která poškozovala generátor klíčů, takže bylo možné vygenerovat jen asi 100 000 různých klíčů. Další problémy souvisí s tím, že uživatelé rádi ukládají své domovské adresáře na GitHub včetně souborů s privátními klíči. Stačilo tak použít vyhledávání a získali jste stovky privátních klíčů.
Jak se bránit?
Bránit je možné se ve třech různých oblastech: auditem kódu, úpravou programu v závislosti na současných trendech a implementací. V roce 2002 zavedlo OpenSSH privilege separation a sandboxing což jsou bezpečnostní postupy schopné zabránit předautentizačním útokům.
Zneužívá se toho, že SSH server běží s právy roota, takže je ho možné teoreticky napadnout a získat v systému nejvyšší práva. Po zavedení zmíněných úprav už uživatel po síti komunikuje s neprivilegovaným procesem v sandboxu, který pak s SSHd komunikuje přes definované API. Vše ostatní má zakázáno, takže prakticky není možné jej zneužít k připojení do systému bez autentizace. Proces běží v prázdném chrootu, je obvykle přísně omezen limity a ještě často chráněn SELinuxem.
Z uživatelského hlediska je možné použít například fail2ban, který automaticky blokuje IP adresy, ze kterých přichází příliš mnoho požadavků na přihlášení. Na můj server se denně pokusí někdo připojit přibližně třistakrát.
Dále je možné službu zcela utajit a zavřít pomocí firewallu. Poté je možné se autorizovat pomocí port knockingu či jednoho podepsaného UDP paketu, který pak otevře přednastaveným IP adresám patřičný přístupový port – využít je možné například program Fwknop. Má klienty pro všechny možné platformy včetně mobilních, takže si do mobilu nahrajete klíč a poté si můžete otevírat porty na serveru.
Výhodou je, že útočník vůbec nevidí otevřený port SSH a není schopen na něj ani začít útočit.
Důležité také je, aby uživatelé poctivě kontrolovali otisky veřejných klíčů u prvních spojení s novými servery. Eliminujeme tím riziko man-in-the-middle útoku, kdy by se útočník mohl vydávat za cizí server. Výhodou je, že klíč je nutné kontrolovat jen jednou, poté si jej klient zapamatuje a sám provádí další ověřování.
Podle Jakuba Jelena je SSH stále bezpečné, ale bezpečnost závisí na konkrétní implementaci. Největší slabina je stále v útoku hrubou silou. Dejte si pozor zejména na hesla. I když používáte přihlašování klíčem, pokud explicitně nezakážete přihlašování heslem, je stále možné hesla hádat a přes slabá se do systému přihlásit,
uzavřel svou přednášku.
ČLÁNKY DO MAILU