GitHub roteert ssh-sleutel nadat private key per ongeluk openbaar verscheen

GitHub heeft zijn eigen privé-ssh-sleutel moeten vervangen, nadat het platform die per ongeluk in een openbare repository had gezet. Daardoor hebben veel gebruikers problemen met het correct verbinding leggen naar hun eigen repo's.

GitHub schrijft in een korte blogpost dat het de ssh-sleutel heeft vervangen. De sleutel, een RSA-key, werd gebruikt om versleutelde Git-verbindingen naar GitHub.com op te zetten. Door de key over te nemen, zou een aanvaller een verbinding met GitHub.com kunnen spoofen zodat gebruikers via Git bestanden zouden versturen richting een nepserver.

GitHub geeft weinig details over wat er precies is gebeurd. Het platform zegt dat de privésleutel 'een korte tijd' openbaar stond in een openbare GitHub-repo. Het is niet bekend welke repo dat was en hoe lang de sleutel daar zichtbaar was. GitHub zegt dat er 'geen reden is om aan te nemen dat de sleutel is misbruikt'. Inmiddels zou de sleutel zijn geroteerd. Het gaat alleen om de RSA ssh-sleutel. Ecdsa- of Ed25519-gebruikers hebben niet met de verandering te maken, omdat die sleutels niet openbaar stonden.

Gebruikers die een GitHub-repo hebben en die bijwerken via Git, moeten hun sleutels roteren en de fingerprint SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s toevoegen aan hun hostfiles. Omdat GitHubs sleutel is geroteerd, krijgen ssh-gebruikers automatisch een waarschuwing als ze een verbinding leggen waarin staat dat de sleutel is veranderd. GitHub heeft instructies online gezet waarin staat hoe de known_hosts-file kan worden aangepast.

Reacties (40)

Matthew Garret heeft hier een leuke blog over geschreven. Maar meer over het achterliggende probleem namelijk het TOFU model wat SSH gebruikt.

Blog is te vinden op https://mjg59.dreamwidth.org/65874.html

Wat Matthew niet meld is dat je ook een DNS record voor SSH fingerprints kan gebruiken: https://en.m.wikipedia.org/wiki/SSHFP_record

Ja, helaas is DNSSEC niet zo breed correct uitgerold als je zou hopen. Daarnaast kan de OpenSSH client zelf geen DNSSEC dus moet je lokale stub resolver er ondersteuning voor hebben (en moet je een trust aanleggen tussen je stub resolver en je vertrouwde validating recursor zodat je fatsoenlijk centraal cachet).

Ergens in deze keten gaat het vaak mis voor DNSSEC.
Dan werkt het op kantoor maar opeens niet meer in de trein ofzo.

Vergeet ook niet dat wij in Nederland erg verwend zijn met een brede deployment van DNSSEC. In de VS is dat helemaal niet hetzelfde, hoor.

.com % signed: 3.97
.nl % signed: 58.32

https://stats.dnssec-tools.org/#/?tld_tab=3

edit: stats erbij met link

[Reactie gewijzigd door gertvdijk op 27 maart 2023 11:44]

Vergeet ook niet dat wij in Nederland erg verwend zijn met een brede deployment van DNSSEC. In de VS is dat helemaal niet hetzelfde, hoor.

Ik heb juist precies de tegenovergestelde ervaring bij Namecheap. Zi ondersteunen DNSSEC niet voor een klein aantal TLD's, waaronder .nl-domeinen, maar de meeste worden wel ondersteund.

Volgens hun FAQ wordt dit niet ondersteund door de registrar, maar had het ook even bij de klantenservice nagevraagd omdat ik weet dat SIDN DNSSEC zeker wel ondersteund. Blijkt dat zij de ondersteuning voor DNSSEC bij SIDN gewoon nog niet af hebben.

NL is echt VER vooruit op de DNSSEC adoptie hoor. Kijk maar naar publieke stats.

.com % signed: 3.97
.nl % signed: 58.32

https://stats.dnssec-tools.org/#/?tld_tab=3

Namecheap is gewoon een random registrar. De naam zegt het al... cheap!

[Reactie gewijzigd door gertvdijk op 27 maart 2023 11:43]

Wat is er zo heilig aan TOFU? Waarom kan Github niet een klein beetje geld naar de SSH client ontwikkelaars gooien en overstappen op SSHFP?

Dit is wel een oeps van formaat waardoor je de halve wereld aan het werk zet

Wat gek dat er een "one-rules-them-all" opstelling wordt gebruikt.

[Reactie gewijzigd door RoestVrijStaal op 24 maart 2023 19:54]

Hoe zou je dit anders doen? Dit is de key waarmee mensen via ssh verbinding maken, dus die moet of over alles servers hetzelfde zijn of elke keer als je een verbinding maakt weer een andere key te zien krijgt.

Elke http server van Google heeft ook de master private key voor de ssl verbinding.

[Reactie gewijzigd door Dr. Horrible op 24 maart 2023 19:47]

Voor de duidelijkheid zodat we over het zelfde hebben:
De Private Key van GitHub, waarmee de Public Key gegenereerd wordt en die op zijn beurt gebruikt wordt door de gebruikers voor de communicatie, is gelekt.

Ik had verwacht dat GitHub op de achtergrond voor iedere ssh gebruiker ook een aparte keypair (private en dito public key) gebruikt.

Het is niet verboden om meerdere keypairs op je machine te hebben. Sterker nog het wordt zelfs aangeraden om per use case een aparte keypair te gebruiken. Mocht er dan een private key lekken, dan blijft dat gescoped tot die use case.

In de echte wereld kun je ook niet met je fietssleutel je huisdeur open doen.

Dus wat zou het probleem van een keypair per gebruiker moeten zijn?

[Reactie gewijzigd door RoestVrijStaal op 24 maart 2023 19:56]

Het probleem is dat de identificatie van de server gebeurd voordat er iets van authenticate gebeurd; je weet dus niet welke gebruiker er aanmeld als de connectie wordt opgezet.

Dit verhaal gaat over de "ssh host key". Dit valt het best te vergelijken met een ssl certificaat, en wordt gebruikt om te controleren of je de server kan vertrouwen. Je wilt namelijk geen password/ssh-key naar een ssh server sturen die je niet vertrouwd. Bekendste scenario wat een host key dient te voorkomen is een man-in-the middle.

Dit is dus iets anders dan een ssh keypair om ergens in te loggen als gebruiker, die je het liefst zo min mogelijk deelt.

In de echte wereld wilt ook niet iedereen door dezelfde deur naar hun huis toe, met elk een eigen sleutel.

Ik had verwacht dat GitHub op de achtergrond voor iedere ssh gebruiker ook een aparte keypair (private en dito public key) gebruikt.

De host key wordt al naar de client gestuurd (en door de client gevalideerd) voordat authenticatie plaatsvindt, dus hoe zie je dat voor je?

Iedere gebruiker heeft een eigen key pair, waarvan github alleen de public key weet. Zo weten zij wie jij bent als je iets pusht (of pullt) van hun servers.

Wat er gelekt is, is de server key, waarmee jij weet dat de server waarmee je praat echt van github is.

Je hebt toch ook niet voor elke random cliënt voor je website een apart SSL certificaat? Dat zou vergelijkbaar zijn hiermee. Een SSH host key wordt gebruikt om een encrypte verbinding naar de juiste server op te zetten (en zodat jij weet dat je met GitHub.com praat, en niet een mitm). Dit gaat niet over SSH keys die toegang geven tot repos oid.

SSH kent certificate authorities die wel toestaan om keys to roteren zonder de train of trust te verliezen. Certificate authorities werken twee kanten op: voor het identificeren van hosts en voor het identificeren van clients.

Echter heb je wel het probleem dat de standaard-SSH-implementaties bij trust-on-first-use niet aanbieden om de certificate authority te vertrouwen.

Voeg bijvoorbeeld

@cert-authority *.example.com ssh-rsa <CA public key>

toe aan je known hosts en alle example.com-host keys worden vertrouwd als ze door de opgegeven CA zijn ondertekend.

Misschien valt het nogal mee. Zoals al geschreven: "Het gaat alleen om de RSA ssh-sleutel. Ecdsa- of Ed25519-gebruikers hebben niet met de verandering te maken, omdat die sleutels niet openbaar stonden."

Het is dus alleen maar voor zij die (nog) de RSA sleutel gebruiken. Dat is van de hier genoemde 3 naar mijn weten de oudste. Nieuwe gebruikers wordt in de regel geadviseerd om Ed25519 te gebruiken, als dat aan alle kanten gebruikt kan worden natuurlijk.

Wel ironisch hoe er tegenwoordig volop wordt ingezet op secret scanning door GitHub, wat juist moet voorkomen dat private keys in je code belanden, maar het juist gebeurt bij GitHub.

Volgens mij voorkomt secret scanning op GitHub niet dat er secrets gecommit worden, maar waarschuwt het alleen. Zodat de key gerevoked kan worden voordat een kwaadwillende deze vindt.

Mogelijk dat GitHub zelf ook op deze manier achter de fout is gekomen, en daarom zo snel een nieuwe key heeft gemaakt.

Klopt, in dat geval krijg je een alert, maar er is ook iets als 'push protection', maar dit lijkt alleen voor Advanced Security, wat betaalt is: https://github.blog/2022-...github-advanced-security/. Maar mag toch aannemen dat GitHub wel z'n eigen tools gebruikt (het is immers gratis voor ze).

[Reactie gewijzigd door AnonymousWP op 24 maart 2023 19:47]

Maar mag toch aannemen dat GitHub wel z'n eigen tools gebruikt (het is immers gratis voor ze).

Je kan niet aannemen dat het gebruik van interne tools gratis is. Soms moet het gebruik van een bepaald budget worden afgeboekt, en interne kosten zijn vaak dan lastig.

Ik ken een bedrijf waarbij de interne ontwikkelaars een licentie moeten afsluiten om de huisstijl van het bedrijf waar ze werken in een applicatie te implementeren en dan maandelijks bijvoorbeeld €150 per seat moeten afdragen om daar gebruik van te maken. Het is een ander team die de huisstijl onderhoud, en die moet kennelijk ook winst maken.

[Reactie gewijzigd door Sebazzz op 24 maart 2023 20:07]

Nou. Weet je dus ook gelijk wat er niet gebruikt wordt bij de volgende greenfield applicatie.

Dit klinkt echt als kapitaalvernietiging.

Het lijkt me juist een zinnige manier van kostentoekenning.

Immers het maken van die huisstijl kost kapitaal, dus dat moet je verrekenen aan de gebruikers. Door zowel interne als externe gebruikers identiek te belasten, krijg je juist een heel goede kostenverdeling. Het uitbesteden van een huisstijl is dan ook bijv. makkelijker te verantwoorden op basis van kosten.

Immers het maken van die huisstijl kost kapitaal, dus dat moet je verrekenen aan de gebruikers.

Dat moet niet. Het kan. Zat bedrijven die dat niet doen.

Als je wil dat devs gewoon maar lekker zelf iets gaan knutselen moet je het vooral doen ja .

De huisstijl is ook je branding en valt onder marketing.

We hebben de context verder niet, dus het is lastig om er wat van te vinden, maar gezien de kosten die een normale licentie aanvraag binnen organisaties vaak al met zich meebrengt zal dit je bottomline absoluut niet verbeteren, maar juist heel hard er op inhakken.

Ik zou graag de beredenering horen waarom wel, want ik zie alleen maar kosten die niet opwegen tegen de winst.

Als je wil dat devs gewoon maar lekker zelf iets gaan knutselen moet je het vooral doen ja .

Je haalt een aantal zaken door elkaar:

• Financiering van branding.
• Gebruik van branding.

Het tweede hoeft niets te maken te hebben met het eerste. Zat bedrijven die standaard branding afdwingen zonder het intern door te berekenen, simpelweg omdat doorberekenen meer kost dan dat het oplevert.

[Reactie gewijzigd door The Zep Man op 25 maart 2023 09:42]

Nee ik haal niet dingen door elkaar:

Zat bedrijven die standaard branding afdwingen zonder het intern door te berekenen, simpelweg omdat doorberekenen meer kost dan dat het oplevert.

Dit was exact mijn punt.

Uiteraard kost het geld, maar dat belast je door aan de eindgebruiker. Misschien dat je het op papier wel registreert, maar je gaat niet je devs een licentie laten aanschaffen. De enorme berg rompslomp eromheen kost je meer dan het oplevert.

Stel de aanvraag, activering en goedkeuring voor 1 dev kost je daadwerkelijk 2 uur. Met een geautomatiseerd systeem kunnen ze gelijk aan de slag, maar heb je dat niet kan het je nog zo een dag kosten aan doorlooptijd, dat ben je dan gewoon kwijt. Zit je ook vaak nog met gecentraliseerde inkoop dus daar moet iemand ook nog wat aan vinden. Kost gigantisch veel tijd en je hebt nog niks kunnen doen.

Dus naast de bruto kosten heb je ook nog extra dervingskosten.

€150 voor de licentie, €200 aan uren (+€200 derving) en dan mogelijk nog €800 aan uren plus bijkomende derving)

Dus iets wat de ene bedrijfstak op jaarbasis misschien eens €1800 oplevert kost de andere tak toch snel het dubbele.

Onderling kosten aan afdelingen doorberekenen is gewoon een manier om de winst te drukken en dus minder belasting hoeven af te dragen.

Tja, iets over een lekkende kraan bij een loodgieter.

Do as I say not as I do

Vanochtend zag ik dat er allerlei interne websites leeg waren, die worden vanuit private github repositories gegeneerd. Duurde even voordat ik doorhad dat het aan github lag. Gelukkig heb ik wat scripts waarmee ik de host key op alle build virtual machines kon updaten, handmatig was het weer heel wat werk geweest.

En ik zou je deployment scripts aanpassen, dat ze de interne website niet updaten zodra het ophalen van info uit die private repo mislukt. Liever een website die een dag achter loopt kwa info dan geen website, toch?
Of iig dat de update scripts je een alert sturen als het mislukt

Liever geen website dan, de generatie datum staat helemaal onderaan de pagina, daar kijk ik normaal nooit na, oude data zitten bekijken is helemaal zonde van mijn tijd ;-)

Waarom moet ik mijn public key vervangen?
Ik heb niet mijn private key gelekt.

Update: Even het GitHub artikel gelezen. Het is alleen de oude key van GitHub die ik niet meer mag vertrouwen. Op basis van het artikel van GitHub hoef ik dus niet mijn key pair te vervangen. Heeft ook weinig zin want die sleutel staat sowieso publiek op de GitHub site.

Side note: Been there done that met test servers op zelfde ip/hostname op mijn homelab. Een goede reden om gegenereerde hostnames te gebruiken met een slimmer dns voor die use case.

[Reactie gewijzigd door nicenemo op 25 maart 2023 05:28]

Dus github is zo vaag dat je als klanten niets hebt om hun beweringen te kunnen controleren op redelijkheid. En daarbij verwacht github dat duizenden klanten niet alleen dat maar accepteren, maar ook de nadelen die ze hoe dan ook op de klant schuiven aan ongemak en extra werk. Dat klinkt niet heel professioneel of klantvriendelijk. Eerder opzettelijk onvriendelijk om er zelf zo min mogelijk nadeel aan te hebben.

Dat ze een nogal belangrijke sleutel per ongeluk publiek maken klinkt daarbij al niet als een redelijke bescherming hebben de ernst in tr zie om lekken te voorkomen. Daar nauwelijks uitleg over geven hoe je dat lekken dan per ongeluk overkomt en alle andere kennelijk zo vaag mogelijke beweringen over het ontdekken, hoe kort het zou zijn en dat er niets mee gebeurt zou zijn, wekt de indruk dat ze vooral weg hopen te komen dat ze ongeïnteresseerde klanten hebben die niet al te kritisch zijn wat github werkelijk aan beveiliging heeft dat je daar van afhankelijk bent.

[Reactie gewijzigd door kodak op 24 maart 2023 20:09]

ik was vanmorgen al super chagrijnig dat allerlei tools opeens niet meer werkte, super irritant, hah

Waarom heet dat roteren? Die term wordt in de blog niet gebruikt.

Key rotation is een heel gangbare term, maar wordt meestal gebruikt voor het periodiek vervangen van sleutels. Waar de term vandaan komt, weet ik niet, maar je favoriete zoekmachine kan vast wel wat plausibele etymologie voor je vinden.

Misschien nog uit het Enigma tijdperk?

Maar serieus is roteren geen goede term, want als het goed is komt de oude key nooit meer terug, terwijl je dat bij het roteren (uitgaande van een eindige cirkel, denk weer Enigma) wel hebt.

Inderdaad, die suggestie heeft het, zoals sommigen telkens maar één cijfer van hun wachtwoord veranderen. Dan ben je na 10 keer weer terug.