Begin april 2022 brak het nieuws uit dat verschillende gebruikers van het GitHub-platform van Microsoft hadden geleden ongeoorloofde toegang naar hun eigen broncode.

GitHib heeft nu zijn incidentrapport bijgewerkt om te zeggen dat het is "in het proces van het verzenden van de laatste verwachte meldingen naar GitHub.com-klanten die de Heroku- of Travis-CI OAuth-app-integraties hadden geautoriseerd in hun GitHub-accounts."

Het goede nieuws is dat GitHub zelf niet is geschonden, dus dit is geen reden tot algemene bezorgdheid voor elke GitHub-gebruiker.

Het slechte nieuws is dat dit soort indirecte inbreuken moeilijk te voorspellen zijn.

GitHub, als je het nog nooit hebt gebruikt, is een cloudgebaseerd broncodecontrolesysteem, vooral bekend vanwege het hosten van de openbare opslagplaatsen van veel open source-softwareprojecten.

Broncodecontrolesystemen zorgen er niet alleen voor dat de nieuwste versie van uw software beschikbaar is om te downloaden, maar houden ook een continue geschiedenis bij van alle recente wijzigingen en waarom ze zijn aangebracht (en, indien nodig, waarom ze later werden afgewezen).

Broncontrolesystemen bieden doorgaans ook historische lijsten van officiële releases, tools voor het ondersteunen en onderhouden van verschillende releaseversies naast elkaar, en online forums voor het rapporteren van bugs en het voorstellen van wijzigingen.

Je hebt vast wel eens van de term jargon gehoord pull verzoek, wat verwijst naar een voorgestelde wijziging waarvoor een bijdrager een mogelijke code-update levert, samen met een rechtvaardiging daarvoor. Voor de suggestie is het natuurlijk in wezen een push-verzoek, met als doel nieuwe code in het systeem te injecteren; indien goedgekeurd door het projectteam, krijgt de code getrokken, of samengevoegd, in de codebase en wordt een officieel onderdeel van het project.

Broncodebeheer geeft softwareprojecten een formeel overzicht van wijzigingen, wat het opsporen van nieuwe bugs veel gemakkelijker maakt omdat elke wijziging afzonderlijk kan worden herzien en opnieuw getest.

Het maakt het ook gemakkelijker voor ontwikkelaars over de hele wereld om efficiënt samen te werken zonder elkaars voorgestelde updates per ongeluk te vertrappen.

Voorbeelden van populaire open source-projecten die op GitHub worden gehost, zijn de cryptografische bibliotheek OpenSSL, Microsoft's eigen scripttaal PowerShell, en privacygerichte alternatieve browser Dapper.

Maar niet alle GitHub-projecten zijn openbare, open source codebronnen.

Veel organisaties gebruiken cloudgebaseerde tools zoals GitHub om propriëtaire, closed-source projecten te hosten waarvan ze niet willen dat ze openbaar worden.

Veel startups willen bijvoorbeeld niet dat potentiële concurrenten weten dat ze aan project X werken, of zelfs maar dat ze in veld Y experimenteren.

Gevestigde softwarebedrijven hebben mogelijk bestaande producten met algoritmen en ander intellectueel eigendom waarvan ze niet willen dat concurrenten ze gemakkelijk kunnen klonen.

Wat ging er mis?

Uit eerste onderzoek bleek dat de geschonden organisaties een van twee dingen gemeen hadden: ze waren gebruikers van een van beide Heroku or Travis CI, voorbeelden van zogenaamde continue integratie (CI) systemen.

Tegenwoordig hebben veel softwareontwikkelingsteams wat vaak wordt aangeduid als een behendig of DevOps nadering.

Coders komen niet zo nu en dan samen om hun collectieve updates te combineren tot een volledige testversie.

In plaats daarvan gebruiken ze een geautomatiseerd systeem dat regelmatig en regelmatig alle recente wijzigingen oppikt, vervolgens het systeem automatisch opnieuw opbouwt en opnieuw test, misschien zelfs meerdere keren per dag.

Het idee is dat hoe eerder elke voorgestelde wijziging wordt uitgeprobeerd, hoe eerder gemakkelijk waarneembare defecten worden gevonden.

Dit betekent op zijn beurt dat nieuw geïntroduceerde bugs snel kunnen worden onderzocht, voordat andere delen van het project verstrikt raken in die nieuwe code, zodat er met minder wijzigingen rekening hoeft te worden gehouden bij het uitzoeken wat er mis is gegaan.

Sterker nog, codewijzigingen die het bouwproces zelf verbreken, worden meteen zichtbaar, zodat het project zelden zo vastloopt dat het helemaal niet meer opnieuw kan worden opgebouwd, laat staan ​​opnieuw getest.

Zoals je je kunt voorstellen, hebben geautomatiseerde CI-systemen geen echte ontwikkelaar die bij de hand is om een ​​wachtwoord in te voeren en een 2FA-code in te voeren telkens wanneer ze zich willen aanmelden bij het broncodecontrolesysteem om de allernieuwste versie van het project te klonen ...

...dus moeten ze worden geleverd met een zgn authenticatie token die ze in hun netwerkverkeer kunnen injecteren om hun toegangsrechten te bewijzen.

Deze authenticatietokens fungeren over het algemeen als een soort "subwachtwoord" op middellange termijn waarmee geautomatiseerde softwaretools een vooraf bepaalde reeks acties kunnen uitvoeren, bijvoorbeeld door downloadtoegang te verlenen tot alle code en het uploaden van bugrapporten mogelijk te maken, maar niet toestaan ​​dat codewijzigingen worden goedgekeurd.

Zelfs als je geen programmeur bent, heb je zelf een dergelijk systeem gebruikt als je ooit een toolkit van een derde partij hebt geautoriseerd om te communiceren met je socialemedia-accounts.

Als u bijvoorbeeld een Hootsuite-gebruiker bent, heeft u waarschijnlijk uw eigen wachtwoorden en 2FA-codes gebruikt om toegangstokens te genereren, zodat het Hootsuite-systeem namens u in uw sociale media-accounts kan rondneuzen.

Misschien heb je de app, of een soortgelijke app, het recht gegeven om te kijken naar alles wat op je sociale media-accounts komt, en zelfs om tweets te verzenden of Facebook-berichten in jouw naam te plaatsen.

Dus als een cybercrimineel toegang heeft gekregen tot de opgeslagen geheimen die worden gebruikt door een van uw vooraf geautoriseerde apps, of malware op uw computer of in uw netwerk heeft kunnen implanteren om uw netwerkverkeer te bespioneren en de authenticatietokens tijdens het transport op te sporen...

... die tokens kunnen door de aanvallers worden gebruikt om zich met je online account te bemoeien, of worden doorverkocht aan andere oplichters voor soortgelijke snode doeleinden.

Volgens GitHub, dat is wat er is gebeurd in dit broncodediefstalincident, waarbij de aanvallers:

• Verworven GitHub-verificatietokens geüpload naar Heroku of Travis-CI voor account X. (Hoe dit is gebeurd, wordt niet bekendgemaakt, vermoedelijk omdat GitHub niet zeker weet wat er anders is gebeurd voordat de inbraken begonnen.)
• Lijst van alle subaccounts met toegankelijke projecten door tokens uitgegeven door X.
• Kies interessant klinkende projecten in die lijsten.
• Opsomde interessant klinkende code-opslagplaatsen binnen die projecten.
• De code gekloond (dwz gestolen), waardoor een mogelijk schadelijk datalek ontstaat.

Met andere woorden, hoewel GitHub-accounts van de slachtoffers dat niet waren direct gecompromitteerd, die accounts waren indirect gecompromitteerd door de blootstelling van wat je zou kunnen noemen "subwachtwoorden" die de slachtoffers hadden gedelegeerd aan de geautomatiseerde tools Heroku of Travis-CI.

Dat is een beetje zoals een indringer die toegang krijgt tot uw kantoorgebouw, niet door het systeem te hacken dat ID-kaarten genereert en zelf een nieuwe pas te maken, maar door een actieve toegangskaart te stelen die al is uitgegeven aan een geautoriseerde medewerker.

Wat te doen?

Indirecte datalekken zoals deze zijn een vorm van supply chain-inbraak, waarbij u niet rechtstreeks wordt aangevallen, maar via een deel van uw operationele proces dat u aan iemand anders hebt toevertrouwd.

Tips om u te beschermen tegen dit soort ongelukken, of om snel te reageren als u toch wordt betrapt, zijn onder meer:

• Controleer regelmatig alle toegangsverificaties van derden die u hebt gemaakt, voor alle apps die zijn gekoppeld aan alle online services die u gebruikt. Mogelijk hebt u er meer dan u denkt, waaronder cloudservices zoals webmail, teleconferenties, webhosting, broncodebeheer, sociale media, DNS, contentbeheer en CRM. Social-mediasites zoals Twitter en Facebook bevatten dashboardpagina's waar u alle apps van derden kunt vermelden die u hebt goedgekeurd. Ga er niet vanuit dat alleen omdat u een app met toegang tot uw account hebt verwijderd, tegelijkertijd de toegangsrechten zijn ingetrokken.
• Zorg ervoor dat u weet hoe u authenticatietokens van derden kunt intrekken voor elke service die u gebruikt. OAuth, de authenticatiedienst die betrokken is bij dit incident, heeft advies over: hoe de toegang in te trekken?. De dashboardpagina's van sociale media die in Tip 1 worden genoemd, waar u kunt vermelden wie toegang heeft, bevatten over het algemeen een knop waarmee die toegang onmiddellijk wordt ingetrokken.
• Bereid je op het ergste voor. Weet wat u moet doen als er een cyberaanval plaatsvindt en met wie u contact moet opnemen, vooral als uw lokale wetgeving vereist dat u gegevensinbreuken openbaar maakt.

Onthoud dat het voorbereiden op een cyberaanval geen bekentenis is die u verwacht te mislukken.

Regelmatige en doelgerichte cyberbeveiligingspraktijken kunnen u inderdaad helpen uw veerkracht te verbeteren door hiaten in uw beleid en procedures aan het licht te brengen en door toegangsrechten te onthullen die u van plan was in te trekken, maar nooit deed.

Als u niet de ervaring of de tijd heeft om zelf voortdurend te reageren op bedreigingen, overweeg dan om samen te werken met een dienst als Sophos Managed Threat Response. Wij helpen u de activiteiten uit te voeren die u moeilijk bij kunt houden vanwege alle andere dagelijkse eisen die IT op uw bord dumpt.

Niet genoeg tijd of personeel? Meer informatie over Sophos Managed Threat Response:
Sophos MTR – Door experts geleide respons  ▶
24/7 jacht op bedreigingen, detectie en reactie  ▶