Výměna klíče samozřejmě přímo nezabrání MitM útoku, ten kdo má ten klíč, může se začít vydávat za github servery a klient to nepozná dokud si sám nenačte nový klíč do know_hosts.
K úspěšnému útoku je ještě potřeba na sebe přesměrovat provoz. Kdoví kolik lidí používá DNSSEC nebo VPN, když pracují z veřejných wifi a commitují do githubu.
Pokud se útočníkovy podaří podvrhnout svůj server, udělá fake git server, tak mu git push rád doručí celý repositář vč. historie. Stačí, když útočník bude nabízet k ověření pouze RSA, klient to příjme jako dostatečné. Stejně tak pokud klient zároveň má ECDSA nebo ed25519, rozdíl nepozná a bude fungovat bez problémů nadále, nebude mít potřebu cokoliv měnit a kdykoliv v budoucnu může narazit na podvržený server, kterému pošle omylem data.
Github tohle hodně zlehčuje, což je pochopitelné k akcionářům a ostatním firmám, ale problém je to daleko vážnější než sám prezentuje. Ne všichni čtou jeho blog a ne všichni umí udělat změnu. Spousty vývojářů ani nepoužívají terminál a commitují rovnou z IDE, ten si know_hosts spravuje na pozadí.
Myslím, že to zveličujete. Ti, kdo nečtou blog, narazí při prvním pokusu komunikovat s GitHubem přes SSH, tj. při prvním fetchi či pushi. V tom okamžiku bude muset uživatel podepsat vlastní krví, že zkontroloval klíč a souhlasí s jeho výměnou. Útočník by tedy měl šanci jedině tehdy, kdyby byl první, ke komu se uživatel připojí. Ano, jisté riziko tam je, ale nepovažuju ho za příliš velké. Vzhledem k tomu, že málokdo kontroluje klíč při prvním přihlášení, je to riziko zhruba stejně velké, jako pokaždé, když se někdo připojuje ke GitHubu z nového zařízení.
To všechno ale platí jen za předpokladu, že se ten tajný klíč do nepovolaných rukou nedostal. U takhle důležitého klíče bych si na to spoléhat určitě nedovolil. Takže na jednu stranu oceňuji rychlou reakci a otevřený popis situace místo toho, aby se snažili předstírat, že se nic nestalo, na druhou stranu si IMHO mohli odpustit tu formulaci o abundance of caution
, protože to je nemístná bagatelizace problému.
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.
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/fetchoval 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/nefetchnul 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.
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.
Zrovna u GitHubu vam DNSSEC v nicem nepomuze, kdyz zona github.com
jaksi neni podepsana :D
Domain Name: github.com Tech Organization: GitHub, Inc. Name Server: dns4.p08.nsone.net Name Server: dns1.p08.nsone.net Name Server: dns3.p08.nsone.net Name Server: ns-1707.awsdns-21.co.uk Name Server: ns-421.awsdns-52.com Name Server: dns2.p08.nsone.net Name Server: ns-520.awsdns-01.net Name Server: ns-1283.awsdns-32.org DNSSEC: unsigned
Trochu zvláštní způsob, jak udělat reklamu nedávno představené službě GitHubu Secret Scanning…
Priklad se zalohou je stejne pitomy jako navod ze si muzes koupit novy prazdny disk a koukej, nebude tam ten commit.
Zmena historie tedy mozna je, "beznymi" prikazy:
https://stackoverflow.com/questions/3293531/how-to-permanently-remove-few-commits-from-remote-branch
Ano, příklad je adekvátní otázce.
V repository gitu také mohou být objekty, které nejsou odnikud referencované, ale ještě nebyly smazané. Přes běžný fetch se k nim nedostanete, ale třeba správce serveru se k nim dostat může. V tomto konkrétním případě je to jedno, protože správce serveru i majitel repository je GitHub. Ale obecně když se řeší problém, že se do Gitu dostalo něco, co tam být nemá, je potřeba řešit, zda stačí problematickou věc odstranit z historie Gitu, nebo zda k ní někdo může mít přístup, i když ve viditelné historii objekt už není.
Zde je jeden priklad pro vsechny:
historie:
https://github.com/twitter/the-algorithm/issues/121#issuecomment-1493034938
Drzeny je v ramci sve historie zatim - protoze existuje diff mezi dvouma "initial commitama":
https://github.com/twitter/the-algorithm/commit/ec83d01dcaebf369444d75ed04b3625a0a645eb9
Fork je prece plnohodnotna kopie, nemuze se odkazovat primo na objekt v cizim repozitari jen tak - http link by vedl na jiny user/repo v ceste, ne tenhle.
A pak mame includnute repa, ale ty se odkazuji na urcitou tamni verzi a neni nikdy mozne zarucit, ze ten vzdaleny zdroj nezmizne ze sveta, ta vazba je mekka a nelze ji zarucit vyjma specificke pripady (kdy treba v ramci githubu se podrzi temne kopie).
vždycky můžeš přegenerovat celé repo. Tady do několika minut klíč z repa zmizel, nejspíš použili force update, ale na konkrétní http adrese byl dostupný asi ještě 2h, to byl nejspíš případ toho, kdy jim chvilku trvalo si uvědomit, že musí přegenerovat všechny objekty v gitu a nestačí odstranit reference.