Vlákno názorů ke zprávičce GitHub rychle vyměnil hostitelský RSA klíč pro SSH, který byl omylem zveřejněn od Uncaught ReferenceError: - Výměna klíče samozřejmě přímo nezabrání MitM útoku, ten...

Než budete někoho obviňovat z toho, že něčemu nerozumí, zkuste si přečíst aspoň to, co je ve zprávičce odkázané. A pak přemýšlejte o tom, jestli v záležitostech týkajících se GitHubu budu věřit spíš anonymovy v diskusi nebo prohlášení GitHubu. Jinak by se vás třeba také někdo mohl ptát, jestli rozumíte tomu, co jsou logy.

Ve zprávičce je o privátním klíči uvedeno, že byl odhalen ve veřejném úložišti, což je poměrně přesný překlad originální formulace "exposed in a public repository". Čemu na tom přesně nerozumíte, že Vás to donutilo k tak nesmyslné reakci?

A ještě Vám zcela zdarma dám další lekci logického uvažování: z toho, že firma nemá informace o zneužití klíče k útokům, se rozhodně nedá odvozovat, že ke zneužití klíče k útokům nedošlo (nebo nedojde)!

Nevím, čemu přesně nerozumíte, že vás to vede k domněnce, že má reakce byla nesmyslná. Možná by pomohlo, kdybyste zkusil konkrétně napsat, co na mé reakci je nepravdivé. Já trvám na tom, že nebezpečí je stejné, jako když se někdo připojuje ke GitHub repository poprvé např. z nového zařízení a neověří si klíč GitHubu.

V prohlášení GitHubu se nepíše, že nemají informace o zneužití klíče k útokům. Píše se tam, že nemají důvod nevěřit, že klíče nebyly zneužity. Například pokud by někdo měl logy zaznamenávající přístupy ke git repository, a z logů zjistí že nikdo nepovolaný si data z repository nestáhl, je to docela dobrý důvod věřit tomu, že nikdo nepovolaný k datům v repository přístup nezískal. No a co myslíte – může mít GitHub log přístupů k repository hostovaným na GitHubu?

Kdyby tam ty logy byly a bylo jednoznacne prokazatelne, ze si to nikdo nestihl stahnout, tak by to uvedli takhle explicitne. Takze stav z prohlaseni je jasny - sami netusi.

Vse ostatni jsou jenom vase domnenky - a v pripade bezpecnosti se pristup jaky predvadite opravdu nevyplaci. To by pak ten klic menit nemuseli prece, ne?

Verim vice jejich spravcum, kteri nekonali na zaklade domnenek, ale podle pravidel bezpecnosti.

Ne, to nejsou moje domněnky, já jsem citoval to prohlášení. To vaše jsou domněnky – že sami netuší.

v pripade bezpecnosti se pristup jaky predvadite opravdu nevyplaci
Můj přístup je „nejsme si 100% jisti, že klíč neunikl, takže ho raději preventivně vyměníme“. Takhle postupoval i GitHub. Co přesně se na tomhle přístupu nevyplácí?

Verim vice jejich spravcum, kteri nekonali na zaklade domnenek, ale podle pravidel bezpecnosti.
Tak to jsme dva, co věříme správcům GitHubu, a věříme, že udělali, co bylo potřeba, aby byla zachována bezpečnost. Akorát teda nechápu, proč polemizujete se mnou a ne s třemi tečkami a Někým, kteří tvrdí (na základě svých domněnek), že nebezpečí je daleko větší, než tvrdí GitHub, a GitHub podle nich situaci podcenil.

A vy vite jestli ty logy byli na append only storage a ze je nekdo nevymazal? A vy vite ze tam vubec nejake logy byli? Nebylo by to poprve co se v korporatech neloguje protoze to stoji prachy. A nebylo by to poprve kdyby v korporatu byl takovy bordel ze tohle je jenom spicka ledovce. Naopak jejich snaha o bagatelizaci problemu ukazuje ze security moc neresi.

Nevím, ale nemám žádný důvod jim nevěřit. A nikdo tu žádný důvod, proč. jim nevěřit, neuvedl – všechno jsou to jen ničím nepodložené domněnky. Žádnou snahu o bagatelizaci nevidím – když zjistili problém, klíč hned preventivně vyměnili. Kdyby problém bagatelizovali, tak klíč nevymění.

Proc jim neverit? Ztrata reputace? Ztrata zakazniku? Vy opravdu zijete v socialni bubkine a verite ze vsich mluvi pravdu?

Ano, kdyby si vymýšleli, ztratili by reputaci i zákazníky. Nevěřím že všichni mluví pravdu. Posuzuji to třeba podle dřívějšího chování. Takže třeba anonymům, kteří píšou nesmysly v diskusích, nevěřím; naproti tomu GitHubu, který vždy o bezpečnostních problémech transparentně informoval, věřím.

no tady je ale problem, ze ten klic vubec leakl a to dokonce do GitHub repositare. Uz toto je dost fishy, ze nekdo (ten kdo to do repa vrazil) ten klic mel k dispozici. To byva (mel by byt) hodne omezeny pocet lidi, takze bud fakt chvilkove selhani jednotlivce nebo se jim to na interni infrastrukture vali kdovi kde :/

To je trošku hraběcí rada, nemyslíte? Kdybychom uměli (v IT obecně) zařídit, aby privátní klíče a hesla neunikaly, odpadla by tím spousta problémů. Jenže ono to zařídit nejde a prostě se občas stane chyba. K tomu klíči může mít přístup nízký počet uživatelů a stejně mohl uniknout. Vzhledem k tomu, že se tak stalo poprvé a zjistili to během chvilky, vypadá to spíš na chvilkové selhání než na systémový problém. Vzhledem k tomu, že ten klíč musí být stejný na všech počítačích, které pro GitHub zajišťují SSH spojení pro git, není jeho zabezpečení zrovna jednoduché.

Já vidím problém spíš v tom, že se pro SSH pořád primárně používá soubor known_hosts a ne DNS záznam SSHFP. Protože tím pádem je ten klíč neodvolatelný – v těch milionech known_hosts ho nevyměníte jinak, než že se dotyčný připojí k serveru, ten mu pošle nový klíč a uživatel odsouhlasí jeho výměnu.

Navíc předpokládám, že běžné implementace SSH klientů, když už použijí SSHFP záznam, ho používají jenom pro naplnění known_hosts při prvním přístupu k danému serveru. Tj. že to není tak, že by v known_hosts byl záznam „pro toto jméno důvěřují výhradně klíčům z DNS“.

Slibuju, že tohle je můj poslední příspěvek, protože jestli to nepochopíte, máte nejspíš nějaký mentální blok, který Vám znemožňuje pochopit o co ve skutečnosti jde, a nemá tedy cenu se dál snažit. Pro Vaše vlastní dobro prosím věnujte maximální možné úsilí pochopení této situace: Může mít GitHub log přístupů k repository, které provozuje útočník s ukradeným privátním RSA klíčem (SSH host key), a na které si nějakým švindlem přesměroval uživatele, pro které následně funguje jako proxy pro přístup na skutečný GitHub, až na to že má přístup k jejich odšifrované komunikaci (klasický man-in-the-middle-attack)? A může tedy GitHub zodpovědně prohlásit, že se to neděje? Uvědomte si, že v tomto případě by GitHub viděl u sebe nějaké přístupy, které vypadají úplně jako kdyby tam přistupoval ten správný uživatel - až to, že mu celou jeho komunikaci se servery GitHubu (která by normálně byla zašifrovaná end-to-end) někdo může klidně odposlouchávat (nebo dokonce i pozměňovat).

Někdo: Aha, vy jste vůbec nepochopil, o co v této situaci jde. Nejde o žádné repository útočníka. Jde o repository GitHubu, které je hostované na GitHubu jako veřejné repository, a ve kterém byl krátce dostupný RSA klíč pro SSH. To je to jediné známé místo, odkud případně útočník mohl získat RSA klíč.

O tomhle repository může mít GitHub 100% přehled, pokud loguje všechny operace, přes které by mohl někdo získat. Nebo o něm také může mít přehled jenom z 99,999 %, protože třeba některé operace nejsou logované – a zároveň GitHub ví, jak nepravděpodobné je, že by k takové operaci došlo. Takže by pak nemohl napsat „100 % víme, že k úniku klíče nedošlo“, ale mohl by napsat jen „jsme přesvědčeni o tom, že k žádnému úniku nedošlo“.

Věřím, že váš slib dodržíte, a tohle byl opravdu váš poslední příspěvek. Protože když jste doteď nepochopil, že jde o to, jestli ten RSA klíč někdo získal nebo nezískal, nemáte čím do této diskuse přispět.

Následující odstavec už není určen vám, protože ho stejně nepochopíte. Ale pokud by někdo nevěděl, jak by mohl mít GitHub o něco méně než 100% znalost o tom, zda někdo ke klíči přístup měl. Mohlo by to být třeba takhle. Přístup přes k repository na GitHubu je možný dvěma způsoby – přes HTTPS a přes SSH. U HTTPS je běžné, že webový server loguje do access logu všechny cesty, ke kterým někdo přistupoval. Kontrolou takového logu lze tedy ověřit, že přes HTTPS nikdo k souboru přístup neměl – ani přes HTTPS neklonoval/fet­choval repository, ani nestahoval přímo ten soubor, ani nepoužil API, kterým by získal přístup k souboru. Druhá možnost je klonování přes SSH. U SSH se obvykle loguje připojení uživatele k serveru, ale už se nelogují všechny operace, které uživatel skrze SSH kanál provádí – protože je to prostě jen šifrovaný kanál, kterým mohou proudit data mnoha různých protokolů. Třeba gitu. GitHub má určitě nějaké custom řešení, ale není důvod myslet si, že je tam logování řešené nějak zásadně jinak. Takže GitHub nemusí mít informaci tom, zda si v inkriminovanou dobu někdo příslušné repository nenaklonoval/ne­fetchnul přes SSH. Ale ví, že se nikdo nemohl přes HTTPS dozvědět, že tam ten zajímavý soubor je. Takže pokud by někdo zrovna v té době naklonoval repository přes SSH, byla by to jen shoda okolností, ne útok s cílem získat ten klíč. Zároveň GitHub ví, jak často se SSH používá, ví, jak často se používá dané repository – takže dokáže docela dobře odhadnout, jaká je pravděpodobnost, že si někdo náhodou naklonoval to repository přes SSH v době, kdy v něm byl ten klíč. No a na základě téhle pravděpodobnosti mohou říct, že nemají žádný důvod myslet si, že klíč unikl. Ale nemají jistotu, protože někde v té hodnotě pravděpodobnosti tam za těma nulama ta jednička je – takže ten klíč preventivně vyměnili.

Předchozí odstavec jsou jenom moje spekulace. Ale kdybyste provozovali vlastní Git server s přístupem přes HTTPS a SSH na běžně dostupných technologiích, budete mít přesně ty informace, které jsem výše popsal.

Ja jsem tu zpravicku asi cetl nepozorne, ale nikde jsem tam nevidel informaci jak dlouho byl privatni klic verejne dostupny.

GitHub přesný čas nezveřejnil, pokud vím. Uvádějí „briefly“.

Je docela možné, že to zachytila jejich služba Secret Scanning, takže já bych to tipoval, že to bylo v řádu jednotek minut.

ten klíč je venku (ověřeno ze dvou zdrojů), okamžitá reakce Githubu tomu nasvědčuje.

"než že se dotyčný připojí k serveru, ten mu pošle nový klíč a uživatel odsouhlasí jeho výměnu." Uhf, tak to ale přece neprobíhá, ne? Uživatel je důrazně varován, že mohlo dojít k útok na ssh spojení, žádná výměna mu není nabidnuta logicky.

A ano, problém je to opravdu vážný, již se množí po světě útoky a první kousek zaznamenán i v cz.

Probíhá to tak, jak je v klientovi naprogramováno. Popis výměny klíče pro OpenSSH je popsán třeba v odkazovaném vyjádření GitHubu.

Když si vymýšlíte, je potřeba si vymýšlet něco, co je aspoň trochu uvěřitelné.