Een nieuwe dag, weer een database-inbreuk op basis van toegangstokens.

Deze keer is het slachtoffer (en in sommige opzichten natuurlijk ook de boosdoener) van Microsoft GitHub bedrijf.

GitHub beweert dat het zag de breuk snel, de dag erna, maar toen was het kwaad al geschied:

Op 6 december 2022 zijn repositories van onze atom, desktop, en andere verouderde GitHub-organisaties werden gekloond door een gecompromitteerde Personal Access Token (PAT) gekoppeld aan een computeraccount. Eenmaal ontdekt op 7 december 2022, heeft ons team de gecompromitteerde inloggegevens onmiddellijk ingetrokken en is het begonnen met het onderzoeken van de mogelijke gevolgen voor klanten en interne systemen.

Simpel gezegd: iemand gebruikte een vooraf gegenereerde toegangscode verkregen van wie-weet-waar om de inhoud van verschillende broncode-repository's die toebehoorden aan GitHub zelf te lekken.

We vermoeden dat GitHub zijn eigen code op GitHub bewaart (het zou een soort motie van wantrouwen zijn als dat niet het geval was!), maar het was niet het onderliggende GitHub-netwerk of de opslaginfrastructuur die werd geschonden, alleen enkele van GitHub's eigen projecten die daar waren opgeslagen.

Strandhoofden en zijwaartse beweging

Zie deze inbreuk als een oplichter die het wachtwoord van uw e-mailarchief van Outlook in handen krijgt en de berichten van de afgelopen maand downloadt.

Tegen de tijd dat u het opmerkte, zou uw eigen e-mail al verdwenen zijn, maar noch Outlook zelf, noch de accounts van andere gebruikers zouden rechtstreeks zijn getroffen.

Let echter op ons zorgvuldige gebruik van het woord "rechtstreeks" in de vorige zin, omdat het compromitteren van één account op een systeem kan leiden tot domino-effecten op andere gebruikers, of zelfs op het systeem als geheel.

Uw zakelijke e-mailaccount bevat bijvoorbeeld vrijwel zeker correspondentie van en naar uw collega's, uw IT-afdeling en andere bedrijven.

In die e-mails hebt u mogelijk vertrouwelijke informatie onthuld over accountnamen, systeemdetails, bedrijfsplannen, inloggegevens en meer.

Het gebruik van aanvalsintelligentie van het ene deel van een systeem om zich in andere delen van hetzelfde of andere systemen te wurmen, staat in het jargon bekend als laterale beweging, waar cybercriminelen eerst vaststellen wat je een "strandhoofd van compromissen" zou kunnen noemen, en vervolgens proberen hun toegang van daaruit uit te breiden.

Wat staat er trouwens in je repositories?

In het geval van gestolen broncodedatabases, of ze nu op GitHub of elders zijn opgeslagen, bestaat altijd het risico dat een privérepository toegangsreferenties voor andere systemen bevat, of dat cybercriminelen toegang krijgen tot certificaten voor codeondertekening die worden gebruikt bij het daadwerkelijk bouwen van de databases. software voor openbare vrijgave.

Dit soort gegevenslekken kan zelfs een probleem vormen voor openbare opslagplaatsen, inclusief open-source broncodeprojecten die niet geheim zijn en door iedereen kunnen worden gedownload.

Open source-gegevenslekken kunnen optreden wanneer ontwikkelaars per ongeluk privébestanden van hun ontwikkelingsnetwerk bundelen in het openbare codepakket dat ze uiteindelijk uploaden zodat iedereen er toegang toe heeft.

Dit soort fout kan leiden tot het zeer openbare (en zeer openbaar doorzoekbare) lek van privéconfiguratiebestanden, privéserver toegangssleutels, persoonlijk toegangstokens en wachtwoorden, en zelfs volledig directory bomen die gewoon op het verkeerde moment op de verkeerde plaats waren.

Ten goede of ten kwade, het heeft GitHub bijna twee maanden gekost om erachter te komen hoeveel spullen hun aanvallers in dit geval te pakken hebben gekregen, maar de antwoorden zijn nu bekend en het lijkt erop:

• De boeven hebben code-ondertekeningscertificaten voor de GitHub Desktop- en Atom-producten in handen gekregen. Dit betekent in theorie dat ze malafide software kunnen publiceren met een officieel Github-keurmerk erop. Merk op dat je niet al een bestaande gebruiker van een van deze specifieke producten hoeft te zijn om voor de gek gehouden te worden - de criminelen kunnen GitHub's imprimatur geven aan bijna elke gewenste software.
• De gestolen ondertekeningscertificaten waren versleuteld en de boeven hadden blijkbaar de wachtwoorden niet te pakken. Dit betekent in de praktijk dat hoewel de boeven de certificaten hebben, ze deze pas kunnen gebruiken als ze die wachtwoorden kraken.

De verzachtende factoren

Dat klinkt als redelijk goed nieuws na een slechte start, en wat het nieuws nog beter maakt, is:

• Slechts drie van de certificaten waren op de dag van diefstal nog niet verlopen. U kunt een verlopen certificaat niet gebruiken om nieuwe code te ondertekenen, zelfs niet als u het wachtwoord hebt om het certificaat te decoderen.
• Eén gestolen certificaat is in de tussentijd verlopen, op 2023-01-04. Dat certificaat was voor het ondertekenen van Windows-programma's.
• Een tweede gestolen certificaat verloopt morgen, 2023-02-01. Dat is ook een ondertekeningscertificaat voor Windows-software.
• Het laatste certificaat verloopt pas in 2027. Deze is voor het ondertekenen van Apple-apps, dus GitHub zegt van wel "samenwerken met Apple om te controleren of er nieuwe apps zijn ondertekend." Houd er rekening mee dat de boeven nog steeds eerst het certificaatwachtwoord moeten kraken.
• Alle betrokken certificaten worden ingetrokken op 2023-02-02. Ingetrokken certificaten worden toegevoegd aan een speciale checklist die besturingssystemen (samen met apps zoals browsers) kunnen gebruiken om inhoud te blokkeren die wordt gegarandeerd door certificaten die niet langer vertrouwd mogen worden.
• Volgens GitHub zijn er geen ongeoorloofde wijzigingen aangebracht in een van de repositories die zijn uitgeloogd. Het lijkt erop dat dit een 'alleen-lezen'-compromis was, waarbij de aanvallers wel konden kijken, maar niet konden aanraken.

Wat te doen?

Het goede nieuws is dat als u geen GitHub Desktop- of Atom-gebruiker bent, u niets hoeft te doen.

Als je GitHub-bureaublad, moet u vóór morgen upgraden om ervoor te zorgen dat u alle exemplaren van de app hebt vervangen die waren ondertekend met een certificaat dat op het punt staat als slecht te worden gemarkeerd.

Als u nog steeds gebruikt Atoom (die werd stopgezet in juni 2022 en zijn leven beëindigde als een officieel GitHub-softwareproject op 2022-12-15), zult u enigszins merkwaardig genoeg moeten downgrade naar een iets oudere versie die niet was ondertekend met een inmiddels gestolen certificaat.

Aangezien Atom het einde van zijn officiële levensduur al heeft bereikt en geen beveiligingsupdates meer zal krijgen, moet u het waarschijnlijk toch vervangen. (De zeer populaire Visual Studio Code, die ook van Microsoft is, lijkt de belangrijkste reden te zijn dat Atom in de eerste plaats werd stopgezet.)

Als je zelf ontwikkelaar of softwarebeheerder bent...

… waarom zou u dit niet gebruiken als een stimulans om te gaan kijken:

• Wie heeft toegang tot welke delen van ons ontwikkelingsnetwerk? Zijn er, vooral voor legacy- of end-of-life-projecten, legacy-gebruikers die nog resterende toegang hebben die ze niet meer nodig hebben?
• Hoe zorgvuldig wordt de toegang tot onze coderepository vergrendeld? Zijn er gebruikers met wachtwoorden of toegangstokens die gemakkelijk kunnen worden gestolen of misbruikt als hun eigen computers worden aangetast?
• Heeft iemand bestanden geüpload die er niet zouden moeten zijn? Windows kan zelfs ervaren gebruikers misleiden door de extensies aan het einde van bestandsnamen te onderdrukken, zodat u niet altijd zeker weet welk bestand welk is. Linux- en Unix-systemen, inclusief macOS, verbergen automatisch alle bestanden en mappen die beginnen met een punt (punt) voor weergave (maar niet voor gebruik!)

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. Toegang hier.
• Bron: https://nakedsecurity.sophos.com/2023/01/31/github-code-signing-certificates-stolen-but-will-be-revoked-this-week/