Het lek van de broncode van Twitter op GitHub is een potentiële cybernachtmerrie

Twitter's broncodelek op GitHub een potentiële cybernachtmerrie

Een deel van de bedrijfseigen broncode van Twitter was al bijna drie maanden openbaar beschikbaar op Github, volgens informatie verkregen uit een DMCA-verwijderingsverzoek ingediend op 24 maart.

GitHub is 's werelds grootste code-hostingplatform. Het is eigendom van Microsoft en bedient meer dan 100 miljoen ontwikkelaars en bevat bijna 400 opslagplaatsen in alles.

Op 24 maart honoreerde GitHub het verzoek van een Twitter-medewerker om "gepatenteerde broncode voor Twitter's platform en interne tools" te verwijderen. De code was gepubliceerd in een opslagplaats genaamd "PublicSpace," door een persoon met de gebruikersnaam "FreeSpeechEnthousiast.” De naam is een duidelijke verwijzing naar die van Elon Musk casus belli voor het overnemen van Twitter in oktober (een filosofie die is geweest ongelijk uitgevoerd sinds maanden).

De gelekte code zat in vier mappen. Hoewel ze vanaf 24 maart ontoegankelijk zijn, lijken sommige mapnamen - zoals "auth" en "aws-dal-reg-svc" - een hint te geven over wat ze bevatten.

Een schermopname van de Twitter-broncode in GitHub

Bron: TorrentFreak

Volgens Ars Technica is FreeSpeechEnthusiast op 3 januari bij Github gekomen en heeft het diezelfde dag alle gelekte code gecommit. Dat betekent dat de code in totaal bijna drie maanden volledig toegankelijk was voor het publiek.

Hoe Enterprise-broncodelekken gebeuren

Grote softwarebedrijven zijn gebouwd op miljoenen regels code en zo nu en dan kan er om de een of andere reden een deel ervan uitlekken.

"Slechte acteurs spelen natuurlijk een grote rol", zegt Dwayne McDaniel, pleitbezorger van ontwikkelaars voor GitGuardian. “We zagen het vorig jaar in zaken als Samsung en Uber waarbij de Lapsus$-groep. '

Hackers maken echter niet altijd deel uit van het verhaal. In het geval van Twitter wijst indirect bewijs op een ontevreden werknemer. En "een groot deel ervan komt ook van code die onbedoeld terechtkomt waar hij niet thuishoort, zoals we zagen bij Toyota, waar een onderaannemer een kopie van een privécodebase openbaar maakte", voegt hij eraan toe. "De complexiteit van het werken met git en CI/CD in combinatie met een steeds groeiend aantal repo's om mee om te gaan voor moderne applicaties, betekent dat code op privé-repo's per ongeluk openbaar kan worden."

Het probleem van broncodelekken voor ondernemingen

Voor Twitter en soortgelijke bedrijven kunnen broncodelekken een veel groter probleem zijn voor cyberbeveiliging dan inbreuk op auteursrechten. Zodra een private repository openbaar wordt, kan er allerlei schade ontstaan.

"Het is belangrijk om te onthouden dat bronrepository's vaak meer bevatten dan alleen de code", zegt Tim Mackey, hoofdbeveiligingsstrateeg van het Synopsys Cybersecurity Research Center. "Je vindt er testcases, mogelijk voorbeeldgegevens en details over hoe de software moet worden geconfigureerd."

Er kan ook gevoelige persoonlijke informatie en authenticatie-informatie in de code verborgen zijn. Bijvoorbeeld: "voor sommige applicaties die nooit bedoeld zijn om naar klanten te worden verzonden, kan de standaardconfiguratie in de broncoderepository gewoon de actieve configuratie zijn", zegt Mackey. Hackers kunnen gestolen authenticatie- en configuratiegegevens gebruiken om grotere en betere aanvallen uit te voeren op het slachtoffer van een lek.

Daarom "moeten bedrijven een veiligere strategie voor het beheer van geheimen aannemen, waarbij ze de opslag van geheimen combineren met de detectie van geheimen", zegt McDaniel van GitGuardian. "Organisaties moeten ook hun huidige situatie van het lekken van geheime informatie controleren om te weten welke systemen risico lopen als er een codelek optreedt en waar prioriteit moet worden gegeven."

Maar in gevallen waarin het lek van binnenuit komt, zoals bij Twitter, is nog meer voorzichtigheid geboden. Het vereist grondige dreigingsmodellering en analyse van het broncodebeheer van een onderneming, zegt Mackey.

"Dit is belangrijk, want als iemand een broncodelek kan veroorzaken, kan hij ook de broncode wijzigen", zegt hij. “Als je geen multifactor-authenticatie gebruikt voor toegang, beperkte toegang afdwingt tot alleen goedgekeurde gebruikers, toegangsrechten afdwingt en toegangsbewaking uitvoert, dan heb je misschien geen volledig beeld van hoe iemand misbruik zou kunnen maken van de veronderstellingen die je ontwikkelingsteams hebben gemaakt toen ze hun broncode-opslagplaats beveiligd.”

Tijdstempel:

Meer van Donkere lezing