Názory k článku
Služba šifrovaného open source protokolu pro chat Matrix byla napadena

Presne z tohoto duvodu nemam v oblibe 3rd party software a pisu si co muzu sam. At uz se podivame na phpMyAdmin, fckEditor/CKEditor, nebo ruzne opensource CMS - vse je jenom sama bezpecnostni dira.

Security by obscurity... What could possibly go wrong?

Chcete mi tvrdit, ze spravne navrzeny a 100% auditovany kod je mene bezpecny, nez neauditovatelny slepenec od mnoha lidi, ktery prodelal nekolika revoluci podle momentalni nalady ve spolecnosti vyvojaru?

Stejne jako lidi neduveruji closed-source produktum, tak dnes nelze duverovat ani open-source vecem a nejlepsi je vse poustet v izolovanem kontejneru. Clovek nikdy nevi, kdy natrefi na bug, broken-by-design produkt, zadni vratka nebo umyslne skodlivou vec.

Super, když píšeš ten skvěle navržený a auditovaný soft... to je samozřejmě jiná. To je cajk.

Jen jestli není jednodušší nic nepsat a nechat zauditovat něco existujícího. Výsledek stejný, práce zlomková.

A můžu se zeptat, jak dlouho vám trvalo naprogramovat si překladač? A jaký operační systém jste si naprogramoval? A jaký procesor jste si vyvinul? A jak jste si vyráběl chipset motherboardu?

Je směšné se domnívat, že bude spolehlivé napsat si vlastní kód nějaké aplikace, když ji buildujete cizím kompilátorem v cizím OS a na hardware, o jehož přesné struktuře a chování nejspíš nemáte ani tušení.

Pokud chcete spolehlivý a neprůstřelný počítač, budete muset vzít do ruky páječku a začít tak někde u relé, možná ještě TTL/CMOS chipů... Všechno nad tím je nedůvěryhodné už na úrovni HW. A to by mě fakt zajímalo, jak to napíšete bez chyb a jak dlouho se budete mordovat s něčím tak samozřejmým, jako je síťový stack...

>Stejne jako lidi neduveruji closed-source produktum, tak dnes nelze duverovat ani open-source vecem a nejlepsi je vse poustet v izolovanem kontejneru. Clovek nikdy nevi, kdy natrefi na bug, broken-by-design produkt, zadni vratka nebo umyslne skodlivou vec.

A pak to pustí na closed-source procesoru, nad kterým běží neauditovaný slepenec mikrokódu. Juch.

P.S. kontejnerizaci používáte vlastní?

Nojo, to je řešení. Každý si napíšeme vlastní řešení na chat... Jen to asi bude mít maličký problém: nikdo si s nikým nepopovídá.

V tomto případě zjevně selhalo zabezpečení na více úrovních.

Proc by si nepopovidali? Staci kdyz se domluvej na protokolu...

Oficiální zpráva https://matrix.org/blog/2019/04/11/security-incident/

to tam mám od začátku, viz. druhý link

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ášť.

CI/CD trubka je normalni, na produkci by mela byt pouze responsible za deployment/reverse existujiciho artefaktu. Artefakt se stavi pouze jednou na urovni DEVu a cestuje si skrz prostredi skrz trubky az do produkce...