Vlákno názorů k článku Nepoučili jsme se, za většinou útoků stojí uživateli běžně používaná hesla od Danny - V roce 2022 vubec provozovat SSH s PasswordAuthentication......
-
DannyStříbrný podporovatelV roce 2022 vubec provozovat SSH s PasswordAuthentication... proc? To ma byt prvni vec, co kazdy proste vypne.
-
Narážím na to často, lidi mají obří a (IMHO) iracionální odpor k používání klíčů. Některým vadí odlišná logistika – že distribuce práv je oproti heslu obráceně, tj. nepřiděluji někomu heslo ale naopak od nich žádám veřejný klíč. Jiným vadí nutnost si nosit něco s sebou, místo hesla v hlavě... přestože se většinou přihlašují nanejvýš ze 2-3 strojů.
-
Jiným vadí nutnost si nosit něco s sebou, místo hesla v hlavě... přestože se většinou přihlašují nanejvýš ze 2-3 strojů.
Ono je dost znepokojivé i to, kolik lidí nevidí problém v tom, že se přihlašují - a to i samotným heslem - z cizího počítače. Já třeba používám openpgp token, který má zásadní výhodu, že tam po mně nezůstane nic, co by šlo použít k opětovnému přihlášení, ale i tak bych si to zatraceně rozmyslel.
-
u ssh klíče nelze vynutit použití hesla a je tedy možné, že útočník spuštěním kódu na počítači oběti automaticky získává přístup kamkoliv bez potřebné znalosti čehokoliv, protože klíč je nechráněn.
Často se hesla pro ssh používají v kombinaci s použití ssh jump hostu a třeba MS AD v podobě auth backendu, kde si někdo nedal práci, aby tam doplnil podporu pro ssh klíče.
Uživatelé na Windows dost výrazně s klíči bojují, putty má svůj vlastní formát, bezpečné uchování je složité, AD jejich bezpečnou distribuci nepodporuje a použití domény a kerberosu s ssh je zase něco čeho se admini prostě bojují a nepoužívají to.
Neobhajuji tyhle postoje, pouze přeposílám argumenty securiťáků, s kterými se setkávám při realizacích.
-
Filip JirsákStříbrný podporovatelTy argumenty jsou dost zvláštní (chápu, že nejsou vaše). Když může útočník spustit kód na počítači oběti, může získat i heslo. Nemyslím si, že by uživatelé Windows s klíči bojovali – prostě používají Putty a vědí, jak z něj získat klíč, stejně jako uživatelé OpenSSH vědí, jak získat klíč z OpenSSH. A mimochodem v posledních verzích Windows 10 už je systémové OpenSSH bez problémů použitelné, s Windows Terminálem (který je standardně bohužel až ve Windows 11) už bude mít i použitelný terminál, takže spousta uživatelů Windows pravděpodobně přestane mít potřebu používat Putty.
-
Filip JirsákStříbrný podporovatel
No to i s tím terminálem. Ale v posledních letech se Microsoft docela snaží a najednou jde spousta věcí, které byly dříve nemyslitelné. Třeba celé WSL.
-
Když může útočník spustit kód na počítači oběti, může získat i heslo.
Ten argument pochopil tak, že pokud má útočník kontrolu nad počítačem, ze kterého se přihlašuji přes SSH (s klíčem v souboru), získá ten klíč, a tím pádem přístup na všechny stroje, kam se autentizuji daným klíčem, což jsou typicky všechny, kam mám přístup. Při autentizaci heslem získá přístup tam, kam se autentizuji daným heslem, které odposlechl, což je - nebo by aspoň měl být - jen ten jeden cílový stroj. Hesla mají samozřejmě spoustu jiných nevýhod, ale tohle trochu smysl má, i když bych to bral spíš jako argument pro to, abych měl ten tajný klíč k SSH v nějakém hardwarovém tokenu, kde ho útočník bude moci zneužít jen po tu omezenou dobu, kdy ho tam budu mít připojený.
-
Filip JirsákStříbrný podporovatel
Při autentizaci heslem získá přístup tam, kam se autentizuji daným heslem, které odposlechl, což je - nebo by aspoň měl být - jen ten jeden cílový stroj.
Ano, ale pokud může útočník na mém počítači spouštět kód, může postupně získat všechna hesla.Je v tom rozdíl, útočníkovi sběr bude trvat déle, někam se třeba vůbec nepřihlásím a útočník mezi tím náhodou o přístup k mému počítači přijde.
Nicméně stav, kdy útočník může na mém zařízení spouštět libovolný kód a získal hesla k některým dalším zařízením já nepovažuju za něco, s čím bych se měl smířit. A to, že se na některá zařízení nedostal, nepovažuju za nic, čím bych se měl utěšovat.
Takže pokud bych se bál prozrazení nechráněného klíče a chtěl zvýšit bezpečnost, budu to řešit hardwarovým tokenem, přesně jak píšete.
Argument, že na serveru nelze politikou vynutit zaheslovaný klíč nebo klíč na hardwarovém tokenu, neobstojí. Politikou na serveru sice lze vynutit, aby heslo mělo třicet znaků a obsahovalo i egyptské hieroglyfy, ale už žádná politika nezajistí, že to heslo nebudu mít lokálně uložené v textovém souboru password.txt v domovském adresáři (nebo-li stejně nezabezpečeně, jako klíč bez hesla).
-
tak spouštět kód v tvém počítači může každá webová stránka, že? Přečíst nějaký soubor přes řadu zranitelností zase není takový extrémní scifi.
Skeny na lokálně uložená hesla se dělají běžně a má je řada korporátů nasazena, dokonce i onedrive podporuje skenování proti uložení hesla na sdílený disk.
Korporáty mají takový svůj masochismus, že uživatelům nedůvěřují a nechtějí nic, kde uživatel může pravidla nabourat.
Spousta github účtů byla napadena díky nezaheslovanému privátnímu klíči. Řešením je mít ssh klíč na klíčence a rozdávat zaměstnancům připravenou klíčenku.
-
Filip JirsákStříbrný podporovatel
tak spouštět kód v tvém počítači může každá webová stránka, že?
Bylo tím samozřejmě myšleno „libovolný kód“.Přečíst nějaký soubor přes řadu zranitelností zase není takový extrémní scifi.
Je to dost velké sci-fi. Z té údajné „řady“ zranitelností dokážete jmenovat alespoň jednu, která by to umožnila dnes na počítači se záplatovaným softwarem?Skeny na lokálně uložená hesla se dělají běžně a má je řada korporátů nasazena, dokonce i onedrive podporuje skenování proti uložení hesla na sdílený disk.
Za prvé, takový skener musí znát heslo v nějakém dost nebezpečném tvaru, nejspíš v otevřeném textu. Za druhé, musí o tom heslu vůbec něco vědět (pokud je to heslo do systému, o kterém neví, má smůlu). Za třetí, jak těžké asi bude takový scan ošálit? Rozdělit heslo mezerou? Nový řádkem?Spousta github účtů byla napadena díky nezaheslovanému privátnímu klíči.
To by mne zajímalo, co znamená „spousta“. A také jak se útočník k tomu souboru s privátním klíčem dostal. Jestli třeba ten privátní klíč ke GitHubu nebyl z celého toho úniku to nejméně zajímavé. -
Je to dost velké sci-fi. Z té údajné „řady“ zranitelností dokážete jmenovat alespoň jednu, která by to umožnila dnes na počítači se záplatovaným softwarem?
To jako chceš, abych ti vyjmenoval 0-day zranitelnosti? :)
Dva měsíce zpátky a CVE-2022-34718. Nebo teď aktuálně mám na stole CVE-2022-37969, aktivně zneužívána v kombinaci s dalšími. Opět cíl je ukradení dat, dnes letí krypto peněženky.
A co před rokem log4shell, zranitelnost, která dovolovala ukrást z disku jakýkoliv přístupný soubor danou službou.
Musí znát heslo? Uhf, nemusí. Např. MS DLP.
Tvrdíš, že ukradení privátního klíče není problém a zlehčuješ to? Těžko ti dám čísla, ze zpětné analýzy se ty cesty těžko detekují, ale mít nechránění privátní klíč je prostě problém, heslo také nemáš v texťáku na disku a netvrdíš, že to je bezpečné. Private key exposure a unauthorized Commit jsou zranitelnosti, které se řeší dlouhé roky.
-
Filip JirsákStříbrný podporovatel
To jako chceš, abych ti vyjmenoval 0-day zranitelnosti? :)
Ne, chtěl jsem 0-day zranitelnosti, které jsou aktuální (tj. zneužitelné v aktuální verzi softwaru) a mohou vést k přečtení souboru. Dva měsíce zpátky ani před rokem nejsou aktuální, dávno na to jsou záplaty.Netvrdím, že to není žádný problém. Ale v IT se primárně počítá s tím, že útočník nemůže číst data z lokálního počítače (a dalších zařízení, kam má přístup). Protože kdyby mohl, má tam daleko zajímavější data, než nějaké privátní klíče. Mohl by číst interní dokumenty, zdrojové kódy, data zákazníků, osobní údaje.
Takže zrovna u privátního klíče je ta možnost dalšího zabezpečení snadná, ale to neznamená, že největší úsilí se musí věnovat tomu, aby útočník lokální data číst nemohl. Proto se 0-day zranitelnosti umožňující číst soubory nebo spouštět kód považují za tak závažné, drží se v tajnosti a je snaha je co nejdříve po zveřejnění zazáplatovat.
Jinak heslo v texťáku na disku považuju za bezpečné a dříve jsem to tak používal (když ještě správci hesel neposkytovali integraci do prohlížečů). A správce hesel teď používám především kvůli ochraně proti phishingu a kvůli synchronizaci a zálohování hesel. To, že ta hesla nejsou uložená v čitelné formě na disku je jen příjemný bonus.
-
To je dost ultimátní postoj, těžko ti ukážu neopravenou zranitelnost. K čemu ti to vůbec bude?
Předpokládáš, že už se nová zranitelnost neobjeví? Ty minulé nám dávají nahlédnout do těch budoucích, stejně tak nás varují před tím, co mohlo v té době utéct.
Předpokládáš, že útočník objektivně vždy hodnotí daný průnik a vybírá si nejziskovější variantu? Tak dnes útoky nefungují, jede se daleko více plošným náletem přes automatizované skripty, daleko více hraje roli něčí objednávka či snaha dosáhnout nepřímých zisků (např. šíření malwaru přes kompromitaci zdrojových kódů, pak útočník neřeší, že na zařízení jsou i jiná data, udělá jednu věc, někdy pak ten přístup prodá někomu jinému, ale častěji chce zůstat co nejméně odhalen).
-
Filip JirsákStříbrný podporovatel
To je dost ultimátní postoj, těžko ti ukážu neopravenou zranitelnost.
No právě. Protože když se objeví, je velmi rychle opravena. Takže těch možností, které může útočník zneužít, je vlastně velmi málo. Pokud je software na počítači aktualizován. Ale pokud není aktualizován, je potřeba v první řadě začít aktualizovat, to je z hlediska bezpečnosti to nejdůležitější.Tak dnes útoky nefungují, jede se daleko více plošným náletem přes automatizované skripty, daleko více hraje roli něčí objednávka či snaha dosáhnout nepřímých zisků
To nějak rozporuje mé tvrzení? Mám si to vykládat tak, že mám hlavně zabezpečit heslem můj klíč, ale jestli se útočník dostane k interním dokumentům, datům nebo zdrojákům, to je nepodstatné? Já to tedy vidím jinak a myslím si, že z mého lokálního počítače by útočník získal přístup ke spoustě zajímavějších věcí, než je privátní klíč pro SSH.Jiné to asi bude u nějakého freelancera, který nemá přístup k žádným dokumentům a jenom přes SSH spravuje různá zařízení v jiných firmách. U něj asi SSH klíč může být opravdu to nejcennější, co na svém počítači má.
Na druhou stranu, pokud už útočník může v počítači spouštět libovolný kód, může docela dobře útočit i na ten klíč s heslem – např. vás obelstít, abyste heslo nenapsal do správného programu, ale do jím podvrženého falešného programu.
-
Já se přiznám, že to na vlastním serveru pořád používám. Mám zakázané přímé přihlášení na roota, takže útočník by musel uhodnout uživatele, přes kterého se přihlašuji, a dvě opravdu silná hesla, aby systém přes ssh ovládl. V kombinaci s tím, že mám nastavený fail2ban na 3 pokusy, mi to přijde dostatečné.
-
Riziko takového přístup není v tom, že je teoreticky těžké heslo uhádnout, ale v zanedbání a lehkovážnosti, jednou se přihlásíš odjinud, jednou heslo omylem nakopíruješ někam jinám, jednou budeš spěchat, protože server bude třeba přetížený a necháš se nachytat. Pokud heslo zadáš někam jinám, dozvíš se to až pozdě, naopak použití klíče tě varuje okamžitě a nedojde ke kompromitaci. Stačí jedna chyba, jedno zaváhání.
Použití pki, 2fa či tokenu dává jistotu, že postup nelze snadno obejít ani pro tebe a vždy ho dodržíš. V tom je ta síla bezpečnosti a nikoliv v tom, jestli heslo lze odposlechnout, uhádnout nebo hrubou silou zjistit.
-
Vždycky je asi dobré mít pro všechny případy někde schovaný i klasický klíč v souboru.
Já tedy používám pro ssh openpgp, ne FIDO2, hlavně proto, že openpgp používám i jinak. S FIDO2 je to asi jednodušší na konfiguraci (aspoň na straně klienta), ale funguje to až od nějaké relativně nedávné verze openssh a taky nejde tajný klíč sdílet, takže když chci mít dva tokeny (jako zálohu nebo proto, že občas používám desktop i notebook současně), musel bych na všech serverech povolit dva různé klíče.
