Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Thursday August 04, @01:51PM   Printer-friendly
from the attack-of-the-clones dept.

Arthur T Knackerbracket has processed the following story:

Thousands of GitHub repositories were forked (copied) with their clones altered to include malware, a software engineer discovered today.

While cloning open source repositories is a common development practice and even encouraged among developers, this case involves threat actors creating copies of legitimate projects but tainting these with malicious code to target unsuspecting developers with their malicious clones.

GitHub has purged most of the malicious repositories after receiving the engineer's report.

Today, software developer Stephen Lacy left everyone baffled when he claimed having discovered a "widespread malware attack" on GitHub affecting some 35,000 software repositories.

Contrary to what the original tweet seems to suggest, however, "35,000 projects" on GitHub have not been affected or compromised in any manner.

Rather, the thousands of backdoored projects are copies (forks or clones) of legitimate projects purportedly made by threat actors to push malware.

Official projects like crypto, golang, python, js, bash, docker, k8s, remain unaffected. But, that is not to say, the finding is unimportant, as explained in the following sections.

While reviewing an open source project Lacy had "found off a google search," the engineer noticed the following URL in the code that he shared on Twitter:

hxxp://ovz1.j19544519.pr46m.vps.myjino[.]ru

BleepingComputer, like many, observed that when searching GitHub for this URL, there were 35,000+ search results showing files containing the malicious URL. Therefore, the figure represents the number of suspicious files rather than infected repositories:

We further discovered, out of the 35,788 code results, more than 13,000 search results were from a single repository called 'redhat-operator-ecosystem.'

[...] As a best practice, remember to consume software from the official project repos and watch out for potential typosquats or repository forks/clones that may appear identical to the original project but hide malware.

This can become more difficult to spot as cloned repositories may continue to retain code commits with usernames and email addresses of the original authors, giving off a misleading impression that even newer commits were made by the original project authors. Open source code commits signed with GPG keys of authentic project authors are one way of verifying the authenticity of code.


Original Submission

 
This discussion was created by janrinok (52) for logged-in users only. Log in and try again!
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Insightful) by Rosco P. Coltrane on Thursday August 04, @02:34PM (1 child)

    by Rosco P. Coltrane (4757) on Thursday August 04, @02:34PM (#1264919)

    I stick to the root projects, even if they don't have some improvements that a fork may provide.

    Case in point: the super-useful PySerial module for Python has many clones designed to do this-or-that, or solve this-or-that problem. Whenever I find the solution to a PySerial problem in one of the forks, I prefer to stick to the original PySerial module and overload it with my own code based on the modifications offered by the fork - or even plain onboard the modification from the fork locally, after review, but I won't install forked module itself: I don't know who made it, I don't know if they won't join a cult and be asked to load their fork full of malware in 6 months... while I have a reasonable expectation that a module like PySerial is such a biggie that it's unlikely to be subverted.

    Starting Score:    1  point
    Moderation   +2  
       Insightful=2, Total=2
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 1) by Dichzor on Thursday August 04, @04:44PM

    by Dichzor (4816) on Thursday August 04, @04:44PM (#1264931)

    It's indeed a problem, both Python and javascript ecosystems have this weakness.

    What you do is a sane mitigation, it does reduce the risk here.

    I haven't got a clue as how to solve the problem with people uploading malicious packages.

    More authentication or validation is not the answer and never was, neither is cutting the hand they clicked "upload" with (regrettably, it also needs authentication).

    Cryptography... not really, spooks can and will get magical certs...

    Actually testing the code for side effects and input of length upto N on the spot... opens door for obfuscated multipackage runtime encoded (pick at least one) scripts that synthesise a shellcode etc... also not feasible for a 1 megaline function that takes 65535 parameters...

    oooh i know! Someone should start a cult that tracks down and inhumes people who submit malicious typo packages!

    But who will finance such a thing?! lol