En hacker som gikk etter håndtaket «Pl0xP» klonet et stort antall GitHub-depoter og endret litt på de klonede depotnavnene, i et feilsøkende forsøk på å etterligne legitime prosjekter – og dermed potensielt infisere programvare som importerte koden, sa programvareeksperter i dag.
Den utbredte kloningen resulterte i mer enn 35,000 XNUMX innsettinger av en ondsinnet URL i forskjellige kodelagre, selv om det nøyaktige antallet berørte programvareprosjekter sannsynligvis er mye mindre, uttalte programvareingeniør Stephen Lacy i et tidlig morgeninnlegg på Twitter. Angrepet, en variant av avhengighetsforvirring, kunne ha forårsaket problemer for utviklere som bruker de falske GitHub-depotene uten tilstrekkelig verifisering av programvarekilden, sa han.
Hvis den importeres, kjører den skadelige koden kode på systemet, ifølge Lacy. "Dette angrepet vil sende HELE ENV av skriptet, applikasjonen, bærbar PC (elektronapper), til angriperens server! ENV-er inkluderer: Sikkerhetsnøkler; AWS tilgangsnøkler; Kryptonøkler ... mye mer."
"ENV-er" er miljøvariabler som brukes til å lagre informasjon som utviklere ønsker å referere til i arbeidsflytene sine.
Programvareingeniøren fant den skadelige funksjonaliteten da han reviderte et programvarebibliotek som han vurderte å inkludere i sitt eget prosjekt, sa Lacy.
"Jeg oppdaget utnyttelsen da jeg gjennomgikk et prosjekt jeg fant ved et Google-søk," han twitret. "Dette er grunnen til at vi ikke installerer tilfeldige pakker fra internett!"
Kloning - eller "gaffel" - er ikke en ny ondsinnet teknikk, men det er en vanskelig en.
"Dårlige skuespillere har allerede vært kjent i fortiden for å lage klonede/forklede populære depoter med ondsinnet kode," sier Mor Weinberg, Aqua Security-programvareingeniør. "Dette kan bli ganske vanskelig å få øye på, ettersom klonede arkiver kan beholde kodebekreftelser med brukernavn og e-postadresser til de opprinnelige forfatterne, og gir et misvisende inntrykk av at nyere commits også ble gjort av de originale prosjektforfatterne. Åpen kildekode-forpliktelser signert med GPG-nøkler til autentiske prosjektforfattere er en måte å verifisere ektheten til koden på."
"Dette … var beslektet med at noen stilte opp et "falsk" nettsted eller sendte en phishing-e-post, legger Mark Lambert, visepresident for produkter i ArmorCode til. "Dette kommer til å fange folk som ikke tar hensyn."
Et angrep eller legitim forskning?
Denne massegaffelen i GitHub var kanskje ikke et reelt angrep. En person som hevdet å ha kunnskap om problemstillingen posisjonerte den utbredte skrivefeilen som en legitim forskningsinnsats.
"Dette er bare en bug-bounty-innsats. Ingen skade gjort. Rapport vil bli utgitt," a Twitter-bruker ved navn «pl0x_plox_chiken_p0x» twitret 3. august.
Mens et dårlig gjennomtenkt forskningsprosjekt kan forklare angrepet, virker det irrasjonelt risikabelt å lage tusenvis av kodeendringer for forskning. Dessuten hadde Twitter-brukeren bare registrert kontoen i løpet av de tre foregående dagene - kort levetid på kontoen er ofte et kjennetegn på falske personas på nettet.
Påstanden om at angrepet er en del av en bug-bounty "venter på å bli bevist, siden aktiviteten har egenskapene til en med ondsinnet hensikt," sier Jossef Harush, leder for forsyningskjedesikkerhetsingeniør hos programvaresikkerhetsfirmaet Checkmarx, til Dark Lesning.
Uansett, Michael Skelton, seniordirektør for sikkerhetsoperasjoner ved bug-bounty-plattformen Bugcrowd, bemerker at i det minste de originale kodelagrene forble upåvirket.
"Selv om det er uklart hva innholdet i Pl0xPs bug-bounty-funn vil være (ettersom sosial engineering er utenfor rekkevidden for nesten alle bug-bounty-programmer), ser det ut som om de klonet en rekke depoter og gjorde endringer i disse klonene bare - i ingen tilfeller kom denne endringen inn i de opprinnelige depotene som hadde blitt klonet, sier han. "Kloning av et depot er en standard handling som ikke påvirker det opprinnelige depotet med mindre eieren slår tilbake en endring (forespurt gjennom en pull-forespørsel), som ikke ble gjort her."
Avhengighet av skadelig programvare florerer
GitHub ryddet tilsynelatende opp i de ondsinnede kodebekreftelsene, og fra og med ettermiddagen 3. august ga et søk etter den innebygde dårlige nettadressen null resultater. Likevel er angrepet neppe første gang åpen kildekode-prosjekter har måttet forholde seg til angripere. Antall angrep mot programvareforsyningskjeden hoppet 650 % i 2021, hovedsakelig drevet av avhengighetsforvirringsangrep, der angriperen bruker en nesten identisk navngitt versjon av en åpen kildekodeblokk i håp om at utviklere skriver feil navnet på et ønsket bibliotek eller en ønsket komponent, eller ikke legger merke til den lille forskjellen i nomenklatur.
Seeding repositories med ondsinnede, feil navngitte prosjekter krever at angriperen gjør noe grunnarbeid. I juli avslørte programvaresikkerhetsfirmaet Checkmarx en måte å opprette falske utviklerkontoer på GitHub, komplett med en aktiv historie med kodebekreftelser for å øke deres troverdighet. Teknikken, sammen med det siste angrepet, understreker at vedlikeholdere må ta skritt for kun å akseptere signerte kodebekreftelser, sier Harush. Utviklere må "vokt seg for pull-forespørsler og bidrag som har mistenkelige ubekreftede forpliktelser, [og må] gjennomgå ... innholdet i bidragene sammenlignet med ansvarsfraskrivelsen i forpliktelsesmeldingen og bidrag som legger til eller modifiserer eksisterende avhengigheter til lignende navngitte avhengigheter som en del av bidrag, legger han til.
Ikke stol, bekreft
For å unngå at prosjektene deres blir forgiftet, bør vedlikeholdere og utviklere bare stole på de bidragsyterne som er kjent for dem og som har en omfattende og verifiserbar forpliktelseshistorikk. De bør også bruke de tilgjengelige verktøyene – som digitale signaturer og multifaktorautentisering – for å sikre kontoene sine, sier Harush.
"Som du ikke bør stole på godteri fra fremmede - ikke stol på kode fra fremmede," sier han. "Brukere kan bli lurt når de evaluerer kandidatprosjektet og tror de er legitime, [så] de bruker det i sine lokale utviklingsdatamaskiner, byggemiljøer, produksjonsmiljøer og til og med bygge programvare, [inntil de til slutt utfører noe ondsinnet] på kundenes [ systemer].”
I Checkmarxs juli-rådgivning om forfalskning av identitetsinformasjon og forpliktelsesinformasjon i git kommandolinjeverktøy, understreket selskapet risikoen for programvareprosjekter når ondsinnede formidlere forkle seg som kjente bidragsytere. Dette "får prosjektet til å se pålitelig ut," opplyste firmaet. "Det som gjør denne forfalskningen enda mer alarmerende er det faktum at brukeren som blir forfalsket ikke blir varslet og ikke vet at navnet deres blir brukt."
GitHub har allerede lagt til digitale signaturer for kodeforpliktelser for å verifisere identiteten til bidragsyteren, men prosjektvedlikeholdere bør aktivere "våken modus", en funksjon i GitHub som viser detaljer om bekreftelsesstatusen til hver forpliktelse og deres bidragsyter, uttalte Checkmarx.
I det minste bør utviklere og prosjektvedlikeholdere av og til gjennomgå forpliktelsesloggen sin og be sine andre vedlikeholdere om å aktivere GPG-signerte forpliktelser, sier Harush. "Å bli vant til å ha en signert forpliktelseslogg vil hjelpe deg å ta hensyn til ubekreftede bidrag."
GitHub kunne ikke umiddelbart nås for kommentar.
