Een hacker aan de hand van ‘Pl0xP’ heeft een groot aantal GitHub-repository’s gekloond en de namen van de gekloonde repository’s lichtjes gewijzigd, in een typosquatting-poging om legitieme projecten na te bootsen – en daarmee mogelijk alle software te infecteren die de code importeerde, zeiden software-experts vandaag.
Het wijdverbreide klonen resulteerde in meer dan 35,000 invoegingen van een kwaadaardige URL in verschillende codeopslagplaatsen, hoewel het exacte aantal getroffen softwareprojecten waarschijnlijk veel kleiner is, zei software-ingenieur Stephen Lacy in een Twitter-bericht in de vroege ochtend. De aanval, een variant van afhankelijkheid verwarring, zou problemen kunnen hebben veroorzaakt voor ontwikkelaars die de nep-GitHub-opslagplaatsen gebruikten zonder adequate verificatie van de softwarebron, zei hij.
Volgens Lacy voert de kwaadaardige code, indien geïmporteerd, code uit op het systeem. “Deze aanval zal de GEHELE ENV van het script, de applicatie, de laptop (elektronenapps) naar de server van de aanvaller sturen! ENV's omvatten: Beveiligingssleutels; AWS-toegangssleutels; Cryptosleutels … veel meer.”
“ENV’s” zijn omgevingsvariabelen die worden gebruikt om informatie op te slaan waarnaar ontwikkelaars in hun workflows willen verwijzen.
De software-ingenieur ontdekte de schadelijke functionaliteit toen hij een softwarebibliotheek controleerde die hij overwoog in zijn eigen project op te nemen, zei Lacy.
"Ik ontdekte de exploit toen ik een project aan het beoordelen was dat ik via een Google-zoekopdracht had gevonden", hij tweeted. “Dit is de reden waarom we geen willekeurige pakketten van internet installeren!”
Klonen (of 'forken') is geen nieuwe kwaadaardige techniek, maar wel een lastige.
“Slechte actoren zijn in het verleden al bekend geweest omdat ze gekloonde/gevorkte populaire repository’s met kwaadaardige code creëerden”, zegt Mor Weinberg, software-ingenieur van Aqua Security. “Dit kan behoorlijk moeilijk te herkennen zijn, omdat gekloonde repositories code-commits met gebruikersnamen en e-mailadressen van de oorspronkelijke auteurs kunnen behouden, waardoor de misleidende indruk wordt gewekt dat nieuwere commits ook door de oorspronkelijke projectauteurs zijn gemaakt. Open source code commits ondertekend met GPG-sleutels van authentieke projectauteurs zijn een manier om de authenticiteit van code te verifiëren.”
"Dit... leek op iemand die een 'nep'-website opzette of een phishing-e-mail verzond", voegt Mark Lambert, vice-president producten bij ArmorCode, toe. “Dit gaat mensen betrappen die niet opletten.”
Een aanval of legitiem onderzoek?
Deze massale forking in GitHub was misschien geen echte aanval. Iemand die beweerde kennis van de kwestie te hebben, positioneerde de wijdverbreide typosquatting als een legitieme onderzoeksinspanning.
“Dit is louter een bug-bounty-inspanning. geen kwaad gedaan. Rapport zal worden vrijgegeven,” een Twitter-gebruiker genaamd “pl0x_plox_chiken_p0x” tweette op 3 augustus.
Hoewel een slecht doordacht onderzoeksproject de aanval zou kunnen verklaren, lijkt het creëren van duizenden codewijzigingen voor onderzoek irrationeel riskant. Bovendien had de Twitter-gebruiker het account pas de afgelopen drie dagen geregistreerd; een korte accountlevensduur is vaak een kenmerk van frauduleuze online persona's.
De bewering dat de aanval deel uitmaakt van een bugbounty “wacht om bewezen te worden, omdat de activiteit de kenmerken heeft van een activiteit met kwade bedoelingen”, vertelt Jossef Harush, hoofd supply chain security engineering bij softwarebeveiligingsbedrijf Checkmarx, aan Dark. Lezing.
Hoe het ook zij, Michael Skelton, senior director security operations bij bug-bounty-platform Bugcrowd, merkt op dat in ieder geval de oorspronkelijke codeopslagplaatsen onaangetast bleven.
“Hoewel het onduidelijk is wat de aard van de bug-bounty-vinding van Pl0xP zou zijn (aangezien social engineering buiten het bereik valt van bijna alle bug-bounty-programma's), lijkt het erop dat ze een aantal repositories hebben gekloond en hun wijzigingen in die klonen hebben aangebracht alleen – in geen enkel geval heeft deze verandering zijn weg gevonden naar de oorspronkelijke opslagplaatsen die waren gekloond”, zegt hij. "Het klonen van een repository is een standaardactie die geen invloed heeft op de oorspronkelijke repository, tenzij de eigenaar een wijziging terugvoegt (aangevraagd via een pull-verzoek), wat hier niet is gedaan."
Schadelijke softwareafhankelijkheden zijn er in overvloed
GitHub heeft schijnbaar de commits van kwaadaardige code opgeschoond, en vanaf de middag van 3 augustus leverde een zoekopdracht naar de ingebedde slechte URL nul resultaten op. Toch is de aanval niet de eerste keer dat open source-projecten met aanvallers te maken krijgen. Het aantal aanvallen op de softwaretoeleveringsketen in 650 met 2021% gestegen, voornamelijk veroorzaakt door afhankelijkheidsverwarrende aanvallen, waarbij de aanvaller een vrijwel identiek genoemde versie van een open source codeblok gebruikt in de hoop dat ontwikkelaars de naam van een gewenste bibliotheek of component verkeerd typen, of het kleine verschil in de nomenclatuur niet opmerken.
Het plaatsen van opslagplaatsen met kwaadaardige, verkeerd benoemde projecten vereist dat de aanvaller wat basiswerk doet. In juli onthulde softwarebeveiligingsbedrijf Checkmarx een manier om valse ontwikkelaarsaccounts op GitHub te maken, compleet met een actieve geschiedenis van code-commits om hun geloofwaardigheid te vergroten. De techniek, samen met de nieuwste aanval, onderstreept dat beheerders stappen moeten ondernemen om alleen ondertekende code-commits te accepteren, zegt Harush. Ontwikkelaars moeten “oppassen voor pull-verzoeken en bijdragen met verdachte niet-geverifieerde commits, [en moeten] de inhoud van de bijdragen beoordelen in vergelijking met de disclaimer in het commit-bericht en bijdragen die bestaande afhankelijkheden toevoegen of wijzigen aan gelijksoortige afhankelijkheden als onderdeel van de bijdrage”, voegt hij eraan toe.
Vertrouw niet, verifieer
Om te voorkomen dat hun projecten worden vergiftigd, moeten beheerders en ontwikkelaars alleen die bijdragers vertrouwen die bij hen bekend zijn en een uitgebreide en verifieerbare commitgeschiedenis hebben. Ze moeten ook de beschikbare tools – zoals digitale handtekeningen en meervoudige authenticatie – gebruiken om hun accounts te beveiligen, zegt Harush.
"Net zoals je snoep van vreemden niet moet vertrouwen, moet je ook geen code van vreemden vertrouwen", zegt hij. “Gebruikers kunnen worden misleid bij het evalueren van het kandidaat-project en denken dat ze legitiem zijn, [dus] gebruiken ze het in hun lokale ontwikkelingscomputers, bouwen omgevingen, productieomgevingen en bouwen zelfs software, [totdat ze uiteindelijk iets kwaadaardigs uitvoeren] op de [ systemen].”
In het advies van Checkmarx van juli over het vervalsen van identiteitsinformatie en het vastleggen van informatie in de git opdrachtregelprogramma onderstreepte het bedrijf de risico's voor softwareprojecten wanneer kwaadwillende committers zich vermommen als bekende bijdragers. Dit “zorgt ervoor dat het project er betrouwbaar uitziet”, aldus de firma. “Wat deze commit-spoofing nog alarmerender maakt, is het feit dat de gebruiker die wordt vervalst, niet op de hoogte wordt gesteld en niet weet dat zijn of haar naam wordt gebruikt.”
GitHub heeft al digitale handtekeningen toegevoegd voor code-commits om de identiteit van de bijdrager te verifiëren, maar projectbeheerders moeten de ‘waakzame modus’ inschakelen, een functie van GitHub die details weergeeft van de verificatiestatus van elke commit en hun bijdrager, aldus Checkmarx.
Op zijn minst zouden ontwikkelaars en projectbeheerders zo nu en dan hun commit log moeten bekijken en hun andere beheerders moeten vragen om GPG-ondertekende commits in te schakelen, zegt Harush. “Als je gewend raakt aan het hebben van een ondertekend commit-logboek, zul je er baat bij hebben om aandacht te besteden aan niet-geverifieerde bijdragen.”
GitHub was niet onmiddellijk bereikbaar voor commentaar.
