Packages downloaded thousands of times targeted people working on sensitive projects:
Highly invasive malware targeting software developers is once again circulating in Trojanized code libraries, with the latest ones downloaded thousands of times in the last eight months, researchers said Wednesday.
Since January, eight separate developer tools have contained hidden payloads with various nefarious capabilities, security firm Checkmarx reported. The most recent one was released last month under the name "pyobfgood." Like the seven packages that preceded it, pyobfgood posed as a legitimate obfuscation tool that developers could use to deter reverse engineering and tampering with their code. Once executed, it installed a payload, giving the attacker almost complete control of the developer's machine. [...]
All eight tools used the string "pyobf" as the first five characters in an attempt to mimic genuine obfuscator tools such as pyobf2 and pyobfuscator. The other seven packages were:
- Pyobftoexe
- Pyobfusfile
- Pyobfexecute
- Pyobfpremium
- Pyobflight
- Pyobfadvance
- Pyobfuse
While Checkmarx focused primarily on pyobfgood, the company provided a release timeline for all eight of them.
Pyobfgood installed bot functionality that worked with a Discord server identified with the string:
MTE2NTc2MDM5MjY5NDM1NDA2MA.GRSNK7.OHxJIpJoZxopWpFS3zy5v2g7k2vyiufQ183Lo
There was no indication of anything amiss on the infected computer. Behind the scenes, however, the malicious payload was not only intruding into some of the developer's most private moments, but silently mocking the developer in source code comments at the same time. Checkmarx explained:
The Discord bot includes a specific command to control the computer's camera. It achieves this by discreetly downloading a zip file from a remote server, extracting its contents, and running an application called WebCamImageSave.exe. This allows the bot to secretly capture a photo using the webcam. The resulting image is then sent back to the Discord channel, without leaving any evidence of its presence after deleting the downloaded files.
Among these malicious functions, the bot's malicious humor emerges through messages that ridicule the imminent destruction of the compromised machine. "Your computer is going to start burning, good luck. :)" and "Your computer is going to die now, good luck getting it back :)"
But hey, at least there is a smiley at the end of these messages.
These messages not only highlight the malicious intent but also the audacity of the attackers.
(Score: 4, Insightful) by looorg on Wednesday November 15, @02:51PM (5 children)
Must be some kind of development irony, installs tool for obfuscation and gets malware. Didn't they read the source code or was it so obfuscated they couldn't read it? Of cause they didn't read it. Lets not be silly here. Trust is everything ...
So what was it using the webcam photo for? The Lolz?
(Score: 5, Insightful) by VanessaE on Wednesday November 15, @03:15PM
Yeah as far as I'm concerned, any developer who uses such tools deserves to have their asses handed to them, as do the people who make those tools. If you're so desperate to hide your source code, then Python is not for you. Pick a regular compiled language, only distribute the binaries, and use a license that's fit for the purpose.
(Score: 3, Insightful) by JoeMerchant on Wednesday November 15, @03:51PM (2 children)
I was going to say: couldn't happen to a more deserving bunch of folks... security through obscurity using lazy tools gets what it deserves?
Last time I ran into obscured code was a Chinese driver for their video capture card. First I asked for the source code so we could compile it on our systems. They happily obliged and sent us the obscured stuff. I wrote back: "Thanks, but we really need the non-obscured source code if we are even going to consider buying thousands of your cards and incorporate them in our products." Took a little longer, but they sent the non-obscured code eventually. Better still, the non-obscured code didn't have any (obvious) Trojans in it.
🌻 [google.com]
(Score: 4, Insightful) by pTamok on Wednesday November 15, @04:26PM (1 child)
This is where reproducible builds are important, too.
I'm very uncomfortable with pulling in code in this way - web-browsers pulling in (obfuscated) javascript from 'who knows where' strikes me as an 'accident' waiting to happen in pretty much the same way. People rely on browser sandboxing rather a lot.
The thing about using distributions and package managers with reproducible builds is that you can demonstrate that you are using the same software as 'everyone else' (it's difficult to target individuals), and a result of the larger user-base, you are likely to get faster discovery of problems.
Some people argue that minifying code reduces resource usage, but we get to the argument that programmers can program less efficiently faster than Moore's 'law' can provide more CPU power. If you need>/i> minification, something is wrong. Minification is not obfuscation, but it sure seems like it at times.
The interesting question is how you can offer reusable code in this way without the obvious downsides. People use the feature because it is useful to them. How can we assure that code libraries are safe enough to use?
(Score: 4, Interesting) by JoeMerchant on Wednesday November 15, @05:05PM
>How can we assure that code libraries are safe enough to use?
First (worst) way: write them yourself.
Next (most unrealistic) way: thoroughly review the source of them, yourself.
Most common way: trust others to do one of the above for you.
Lately: we're starting to collect system software bills of materials SSBOMs. From those we plan to monitor the vulnerability reports on the components and then, apparently make some kind of judgement calls about what we do next with respect to each and every vulnerability that is reported about any software component in our systems.
I call the SSBOM approach: too much work, too late in the cycle. An interesting aspect of it is: systems in which we have "rolled our own" everything will never have a vulnerability report to analyze - which dramatically lowers the TCO of rolling your own, while simultaneously likely decreasing the quality of the code you are actually running. It's getting back to that first, worst option above.
🌻 [google.com]
(Score: 3, Insightful) by Tork on Wednesday November 15, @06:56PM
This is exactly why I don't buy the 'million eyeballs' philosophy of Open Source.. at least in the context of the way it was evangelized on the green site. I've seen people there describe OSS as 'nearly bug free' and 'secure'. There was a lax-ness to it that, frankly, bothered me. At least with Windows I just plain didn't trust it, so I did shit like prioritize security updates, off-line backups, good practices with regards to software downloading, etc. I really really really really don't believe the source code of any OSS app is being scrutinized.
I need to clarify, though, that I don't mean OSS is bad, nor do I mean it's worse than proprietary software. I'm saying it's not functionally different enough to trust it and we need to quit giving people that impression.
🏳️🌈 Proud Ally 🏳️🌈
(Score: 4, Insightful) by ikanreed on Wednesday November 15, @03:14PM
A fairly benign hot take, but code obfuscation is both security-through-obscurity and directly hostile to the ideals of open source. I'm not surprised the people using it have lax security standards to target.
(Score: 2) by RamiK on Wednesday November 15, @05:22PM (8 children)
I just took a look at the GPL [gnu.org] and it seems to me there's nothing preventing companies from replying to compliance requests by disassembling / de-compiling binaries into something that compiles and sending that... Am I missing something?
compiling...
(Score: 2) by HiThere on Wednesday November 15, @06:13PM
No, you aren't missing much. IIUC there's no legal requirement. But your reputation may suffer. (It would if I were evaluating it.)
OTOH, you do need to specify the entire tool-chain needed to produce the working code.
P.S.: I believe that technically it's a license violation, but that that would be quite difficult to prove. And I can't find the exact lines that make me believe that. (Perhaps they've been dropped since the GPL v1.)
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 3, Informative) by krishnoid on Wednesday November 15, @06:53PM (2 children)
They define "source code" as a particular term:
So if you have to provide the "source code", unless an AI or the like is what's preferentially "making modifications" to it, the obfuscated or decompiled form wouldn't fly. Of course, if you're talking about a legal license, it's what you can argue in court, not what's "true".
(Score: 3, Interesting) by Freeman on Wednesday November 15, @07:08PM
Considering some code I've seen, there might not be much to obfuscate in the first place.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 2) by PiMuNu on Thursday November 16, @10:22AM
> unless an AI or the like is what's preferentially "making modifications" to it
Presumably at which point you need to also provide the AI.
(Score: 4, Insightful) by DannyB on Wednesday November 15, @08:57PM
If a commercial company does not intend to comply with the GPL, then they should not use GPL licensed code in their product.
It's interesting how understanding all this is well settled. Then after another generation or two, all the same questions come up again about how to subvert the GPL.
Life is short. It's even shorter if you are stupid.
(Score: 3, Interesting) by stormreaver on Wednesday November 15, @09:06PM (2 children)
The GPL says, "The source code for a work means the preferred form of the work for making modifications to it." So companies that send decompiled or disassembled code are most likely in violation.
(Score: 2) by RamiK on Thursday November 16, @10:17AM (1 child)
But that's assuming work is being done on the code. What if they too got it in obfuscated form? That is, the developer has the distributor middle-man so that:
1. The developer only supplies binaries to a distributor which is basically just a front-man so they don't ask for the code.
2. The distributor replies to code requests by sending in compiled code and says "we don't do any work on the code - at most, we look at the binary from a debugger - so that's what we're sending in.
3. The edge user is left with de-compiled code while the developer and the distribute have complied with the license requirements.
I believe medical equipment manufacturers are currently doing something fairly similar.
compiling...
(Score: 2) by stormreaver on Thursday November 16, @03:36PM
Then that probably changes things a bit.