A hacker going by the handle “Pl0xP” cloned a large number of GitHub repositories and slightly changed the cloned repository names, in a typosquatting effort to impersonate legitimate projects — thus potentially infecting any software that imported the code, software experts said today.
Den udbredte kloning resulterede i mere end 35,000 indsættelser af en ondsindet URL i forskellige kodelagre, selvom det nøjagtige antal af berørte softwareprojekter sandsynligvis er meget mindre, udtalte softwareingeniør Stephen Lacy i et tidligt morgenindlæg på Twitter. Angrebet, en variant af afhængighedsforvirring, kunne have forårsaget problemer for udviklere, der bruger de falske GitHub-lagre uden tilstrækkelig verifikation af softwarekilden, sagde han.
If imported, the malicious code executes code on the system, according to Lacy. “This attack will send the ENTIRE ENV of the script, application, laptop (electron apps), to the attacker’s server! ENVs include: Security keys; AWS access keys; Crypto keys … much more.”
“ENVs” are environment variables, used to store information that developers want to reference in their workflows.
Softwareingeniøren fandt den ondsindede funktionalitet, da han reviderede et softwarebibliotek, som han overvejede at inkorporere i sit eget projekt, sagde Lacy.
“I discovered the exploit as I was reviewing a project I found off a Google search,” han tweeted. “This is why we don’t install random packages off the internet!”
Cloning — or “forking” — is not a new malicious technique, but it’s a tricky one.
“Bad actors have already been known in the past for creating cloned/forked popular repositories with malicious code,” says Mor Weinberg, Aqua Security software engineer. “This can become quite difficult to spot, as cloned repositories may retain code commits with usernames and email addresses of the original authors, giving off a misleading impression that newer commits were made by the original project authors as well. Open source code commits signed with GPG keys of authentic project authors are one way of verifying the authenticity of code.”
“This … was akin to someone standing up a ‘fake’ website or sending a phishing email,” adds Mark Lambert, vice president of products at ArmorCode. “This is going to catch people that are not paying attention.”
Et angreb eller legitim forskning?
Denne masseforgrening i GitHub var måske ikke et rigtigt angreb. En person, der hævdede at have kendskab til problemet, placerede den udbredte typosquatting som en legitim forskningsindsats.
“This is a mere bug-bounty effort. no harm done. Report will be released,” a Twitter user named “pl0x_plox_chiken_p0x” tweeted on Aug. 3.
Mens et dårligt gennemtænkt forskningsprojekt kunne forklare angrebet, virker det irrationelt risikabelt at skabe tusindvis af kodeændringer til forskning. Desuden havde Twitter-brugeren kun registreret kontoen i de foregående tre dage - korte kontolevetider er ofte et kendetegn for svigagtige online-personas.
The claim of the attack being part of a bug bounty “is waiting to be proven, as the activity is having the characteristics of one with a malicious intent,” Jossef Harush, head of supply chain security engineering at software security firm Checkmarx, tells Dark Reading.
Under alle omstændigheder bemærker Michael Skelton, seniordirektør for sikkerhedsoperationer hos bug-bounty-platformen Bugcrowd, at i det mindste de originale kodelagre forblev upåvirket.
“While it’s unclear what the nature of Pl0xP’s bug-bounty finding would be (as social engineering is out of scope for nearly all bug-bounty programs), it does look like they cloned a number of repositories, and made their changes in those clones only — in no cases did this change make its way into the original repositories that had been cloned,” he says. “Cloning a repository is a standard action that doesn’t impact the original repository unless the owner merges a change back (requested through a pull request), which wasn’t done here.”
Afhængigheder af skadelig software er mange
GitHub ryddede tilsyneladende op i de ondsindede kode-commits, og fra om eftermiddagen den 3. august viste en søgning efter den indlejrede dårlige URL nul resultater. Alligevel er angrebet næppe første gang, at open source-projekter har haft at gøre med angribere. Antallet af angreb mod softwareforsyningskæden sprang 650 % i 2021, hovedsageligt drevet af afhængighedsforvirringsangreb, hvor angriberen bruger en næsten identisk navngivet version af en åben kildekodeblok i håb om, at udviklere fejltaster navnet på et ønsket bibliotek eller en ønsket komponent eller ikke lægger mærke til den lille forskel i nomenklaturen.
Såning af repositories med ondsindede, forkert navngivne projekter kræver, at angriberen gør noget grundarbejde. I juli afslørede softwaresikkerhedsfirmaet Checkmarx en måde at oprette falske udviklerkonti på GitHub, komplet med en aktiv historik over kodeforpligtelser to increase their credibility. The technique, along with the latest attack, underscores that maintainers need to take steps to only accept signed code commits, Harush says. Developers need to “beware of pull requests and contributions having suspicious unverified commits, [and need to] review … the content of the contributions compared to the disclaimer in the commit message and contributions adding or modifying existing dependencies to similar named dependencies as part of the contribution,” he adds.
Stol ikke på, bekræft
For at undgå, at deres projekter bliver forgiftet, bør vedligeholdere og udviklere kun stole på de bidragydere, som er kendt af dem og har en omfattende og verificerbar forpligtelseshistorik. De bør også bruge de tilgængelige værktøjer - såsom digitale signaturer og multifaktorautentificering - for at sikre deres konti, siger Harush.
“As you should not trust candy from strangers — don’t trust code from strangers,” he says. “Users may be tricked when evaluating the candidate project and think they are legitimate, [so] they use it in their local development computers, build environments, production environments, and even build software, [until finally executing something malicious] on customers’ [systems].”
In Checkmarx’s July advisory on spoofing identity information and commit information in the git command-line utility, the company underscored the risks to software projects when malicious committers disguise themselves as known contributors. This “makes the project look trustworthy,” oplyste firmaet. “What makes this commit-spoofing even more alarming is the fact that the user being spoofed isn’t notified and won’t know that their name is being used.”
GitHub has already added digital signatures for code commits to verify the identity of the contributor, but project maintainers should enable “vigilant mode,” a feature of GitHub that displays details of the verification status of every commit and their contributor, Checkmarx stated.
At the very least, developers and project maintainers should occasionally review their commit log and ask their other maintainers to enable GPG-signed commits, Harush says. “Getting used to having a signed commit log will benefit you to pay attention to unverified contributions.”
GitHub kunne ikke umiddelbart nås for en kommentar.
