Vlákno názorů ke zprávičce Služba šifrovaného open source protokolu pro chat Matrix byla napadena od Jan Hrach - Hacker jim (až po činu, nebyl to tedy...

Hacker jim (až po činu, nebyl to tedy white hat) nahlásil zneužité díry jako issues, bohužel je po chvíli smazali. Ale stihl to stáhnout Web Archive. Ve zkratce: první entrypoint byla tato díra v Jenkinsu, na kterou byla tou dobou již dlouho dostupná oprava. Díra spočívala v tom, že Jenkins při přechodu na verzi 2.0 změnil povolený formát uživatelských jmen. Pokud se přihlásí nějaký uživatel se starým jménem, vyrobí mu to nové a jeho konfiguraci přesune. Bohužel vlivem logické chyby, pokud se zadá uživatelské jméno "..", přesune se globální konfigurace serveru. A Jenkins bez konfigurace nastartuje v režimu s vypnutými security checky.

To by ještě nebylo tak hrozné, holt by jim vyhackovali continuous integration. Jenže jejich admini používali SSH agent (forwarding) (upřímně nechápu koho vůbec napadlo takovou věc do SSH implementovat). No a pak stačilo počkat si na naSSHčkování admina, nastavit si publikovaný soket agenta a použít to pro přihlášení se všude jinde.

Zde jsou ty původní issues. S některými příliš nesouhlasím (např. 2FA by podle mě jen zkomplikovala postup, neboť by si nestačilo ukrást ssh agenta, ale bylo by nutno deploynout patchnutou binárku ssh/jeho konfiguraci (např. ssh -S))

https://web.archive.org/web/20190412143908/https://github.com/matrix-org/matrix.org/issues/357
https://web.archive.org/web/20190412143913/https://github.com/matrix-org/matrix.org/issues/358
https://web.archive.org/web/20190412143918/https://github.com/matrix-org/matrix.org/issues/359
https://web.archive.org/web/20190412143922/https://github.com/matrix-org/matrix.org/issues/360
https://web.archive.org/web/20190412143927/https://github.com/matrix-org/matrix.org/issues/361
https://web.archive.org/web/20190412143931/https://github.com/matrix-org/matrix.org/issues/362
https://web.archive.org/web/20190412143936/https://github.com/matrix-org/matrix.org/issues/363
https://web.archive.org/web/20190412143941/https://github.com/matrix-org/matrix.org/issues/364
https://web.archive.org/web/20190412143946/https://github.com/matrix-org/matrix.org/issues/365

> Jenže jejich admini používali SSH agent (forwarding) (upřímně nechápu koho vůbec napadlo takovou věc do SSH implementovat).

Agent forwarding má několik skvělých a nenahraditelných funkcí, zejména pokud používá člověk SSH pro přístup na vzdálenou pracovní stanici, což je něco trochu jiného než obyčejný jumphost, kde je bezpečnější použít ssh -J. Alternativou by bylo kopírovat si na takovou vzdálenou stanici privátní SSH klíč, což by nejspíš bylo ještě horší.

Co já nechápu, je proč není přepínač -c pro ssh-add výchozí volbou a zejména proč se mezi vývojáři a adminy tolik oblíbený macOS musí ručné ohýbat, aby v něm ssh-add -c fungovalo.

> Alternativou by bylo kopírovat si na takovou vzdálenou stanici privátní SSH klíč, což by nejspíš bylo ještě horší.

Já tohle vždycky řešil tak, že jsem si na té vzdálené stanici vygeneroval nový klíč speciálně pro tuto stanici a na stroji kam se potřebovala připojovat jsem ho přidal do authorized_keys.

-c zobrazuje jenom fingerprint, nebo i odpovídající hostname (když ho máš v known_hosts)?

Na dopadech útoku tohoto typu asi nic nemění, jestli by šlo o speciální klíč, nebo běžný klíč uživatele. Tedy pokud bylo zneužití agenta použito proti serverům, které se přes příslušný server právě spravovaly.

> -c zobrazuje jenom fingerprint, nebo i odpovídající hostname (když ho máš v known_hosts)?

Nezobrazuje nic, jen otisk klíče, o který se jedná. Domnívám se, že informace o tom, kdo si žádá privátní klíč, se do agenta vůbec nepřenáší; nehledě na to, že přenést ji tam tak, aby se nedala útočníkem podvrhnout, je zřejmě netriviální úkol.

> Tedy pokud bylo zneužití agenta použito proti serverům, které se přes příslušný server právě spravovaly.

Já to právě pochopil tak, že tady šlo o nějaký relativně nevýznamný server, a v něm byl nasshčkovaný admin s agentem (ale nikam dál se nepřipojoval).

> Domnívám se, že informace o tom, kdo si žádá privátní klíč, se do agenta vůbec nepřenáší

Aha, já bych čekal, že to bude dělat ověření fingerprintu protistrany stejně jako když se připojuju přímo.

řešením přece může být obyčejný tcp tunel na cílový ssh server a přihlášení ze své stanice a to přesně dělá proxyJump (zmíněný přepínač -J).

Ano, to je řešení některých případů, pro které lidé nesprávně používají přesměrování agenta. Pak jsou ale případy, kdy je přesměrování agenta ideálním řešením. Třeba když spravujete cluster serverů na druhé straně oceánu, což v době IaaS řešení typu Amazon není vůbec nereálné. Latence bude aspoň 200 ms, přenosová rychlost nic moc. V takovém případě je ideální mít administrační stanici součástí clusteru a správu provádět přímo z té stanice, namísto zdlouhavého tunelování SSH provozu pro každý nód zvlášť.