How a Rust Supply-Chain Attack Infected Cloud CI Pipelines with Go Malware (sentinelone.com) 45
Sentinel Labs provides malware/threat intelligence analysis for the enterprise cybersecurity platform SentinelOne.
Thursday they reported on "a supply-chain attack against the Rust development community that we refer to as 'CrateDepression'." On May 10th, 2022, the Rust Security Response Working Group released an advisory announcing the discovery of a malicious crate hosted on the Rust dependency community repository. The malicious dependency checks for environment variables that suggest a singular interest in GitLab Continuous Integration (CI) pipelines.
Infected CI pipelines are served a second-stage payload. We have identified these payloads as Go binaries built on the red-teaming framework, Mythic. Given the nature of the victims targeted, this attack would serve as an enabler for subsequent supply-chain attacks at a larger-scale relative to the development pipelines infected. We suspect that the campaign includes the impersonation of a known Rust developer to poison the well with source code that relies on the typosquatted malicious dependency and sets off the infection chain.... In an attempt to fool rust developers, the malicious crate typosquats against the well known rust_decimal package used for fractional financial calculations....
The malicious package was initially spotted by an avid observer and reported to the legitimate rust_decimal github account.... Both [Linux and macOs] variants serve as an all-purpose backdoor, rife with functionality for an attacker to hijack an infected host, persist, log keystrokes, inject further stages, screencapture, or simply remotely administer in a variety of ways....
Software supply-chain attacks have gone from a rare occurrence to a highly desirable approach for attackers to 'fish with dynamite' in an attempt to infect entire user populations at once. In the case of CrateDepression, the targeting interest in cloud software build environments suggests that the attackers could attempt to leverage these infections for larger scale supply-chain attacks.
Thursday they reported on "a supply-chain attack against the Rust development community that we refer to as 'CrateDepression'." On May 10th, 2022, the Rust Security Response Working Group released an advisory announcing the discovery of a malicious crate hosted on the Rust dependency community repository. The malicious dependency checks for environment variables that suggest a singular interest in GitLab Continuous Integration (CI) pipelines.
Infected CI pipelines are served a second-stage payload. We have identified these payloads as Go binaries built on the red-teaming framework, Mythic. Given the nature of the victims targeted, this attack would serve as an enabler for subsequent supply-chain attacks at a larger-scale relative to the development pipelines infected. We suspect that the campaign includes the impersonation of a known Rust developer to poison the well with source code that relies on the typosquatted malicious dependency and sets off the infection chain.... In an attempt to fool rust developers, the malicious crate typosquats against the well known rust_decimal package used for fractional financial calculations....
The malicious package was initially spotted by an avid observer and reported to the legitimate rust_decimal github account.... Both [Linux and macOs] variants serve as an all-purpose backdoor, rife with functionality for an attacker to hijack an infected host, persist, log keystrokes, inject further stages, screencapture, or simply remotely administer in a variety of ways....
Software supply-chain attacks have gone from a rare occurrence to a highly desirable approach for attackers to 'fish with dynamite' in an attempt to infect entire user populations at once. In the case of CrateDepression, the targeting interest in cloud software build environments suggests that the attackers could attempt to leverage these infections for larger scale supply-chain attacks.
Re: (Score:2)
Re: (Score:2)
Rust wishes it were as cool as Zig, with its painless "compile anywhere" toolchain!
Indeed. There is so much that Zig got right that Rust got wrong and it's not even taking the language into consideration.
Re: (Score:2)
Re: (Score:3)
Take a fresh linux box. Install Rust and try to compile hello world.
Install Zig and try to compile hello world.
Compare notes and compile times.
Observe the build system.
Rust - read the documentation on the build system. Try to do something slightly more complicated than hello world.
Zig - write the build rules in zig.
Compare notes and effort expended.
Parameterized code
Rust - Read the steaming pile that is the configuration predicate in Rust. Try to use it.
Zig - write compile time executed zig, in zig to preco
Re: god I hate rust (Score:2)
If you're new to rust, yeah, it will be more complicated. But what you get in return for your efforts is a guarantee of having fewer bugs, in addition to having a more expressive syntax.
Re: (Score:2)
Re: (Score:2)
Kyosuke said it before me. What does a bad build system have to do with offering fewer bugs?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Does "compile anywhere" mean "compile on any machine" or "compile for any machine"
Since it's self-hosting, doesn't it mean the same thing? If it can "compile for any machine", it can compile itself for any machine and you can then run the resulting binary to compile on that machine.
and would that help against supply-chain attacks?
Well, Zig currently doesn't handle anything similar to Crates.io or NPM, so there's nothing to prevent here yet.
Re: (Score:2)
And making its way into the kernel. Going to be interesting to see how this plays out on platforms with limited resources that can’t build rust. The dependency and amount of resources needed to build rust is staggering.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
It's not there yet, but neither are Rust modules in Linux, so I'm not sure why anyone would worry about those.
We should worry about being dragged down a suboptimal path when other more sensible options have arisen and more will arise over the same time period. The opportunity to send the whole industry down a wasteful and damaging path is there and it has happened before : OO, SQL, DOM+Javascript etc. We are stuck with that crap and people think it's good because it's commonplace. It isn't.
Re: (Score:2)
Re: (Score:2)
The obvious solution for rust warriors is to rewrite everything in rust. Will that work?
Holy shit, is that why those rust fuckers are all zealots?
Re: (Score:2)
The obvious solution for rust warriors is to rewrite everything in rust. Will that work?
Holy shit, is that why those rust fuckers are all zealots?
When you can't compile your LaTeX_rust_edition document because the borrow checker disagrees with your split infinitives, you will understand what evil is.
Re: That's wishful thinking (Score:2)
You will be assimilated.
Re: (Score:2)
Indeed. I do not think I will allow any Rust in my kernels anytime soon. That community is just borked.
Re: god I hate rust (Score:2)
Resistance is futile.
Re: (Score:2)
Re: (Score:2)
As I understand it the initial use of Rust will be x86_64 only drivers, so Rust itself will not be a major hardship in that stage. I hope it dies there, or at least stays there.
Re: (Score:2)
As I understand it the initial use of Rust will be x86_64 only drivers, so Rust itself will not be a major hardship in that stage. I hope it dies there, or at least stays there.
So to write a cross-architecture driver, I must use C?
It seems like a Rust driver would be dead in the water if I had to write another one in C for the other platforms.
Re: (Score:2)
Same here. After all, Rust basically advertises itself as a tool for incompetents. These people create far more problems than only ones with security.
Re: god I hate rust (Score:2)
No, rust advertises itself as a tool for human programmers. Incompetents are the ones who think they're incapable of writing buggy, insecure code. It's like C programmers that complain about Rust because they say it requires planning, and then at the same time say it's easy to write bug free code in C, because all you have to do is plan correctly. THAT is incompetence.
And interestingly, Rust doesn't require you to plan that way. You can reactor willy nilly without having to worry about whether you've left a
Re: (Score:2)
You can't do that with C
Technically you can just build against libgc and be done with it. Poof, dangling pointers gone.
Re: (Score:2)
Just like a Rust moron to focus on a single problem in a single other language and ignore everything else. Pretty much confirms my point.
Re: (Score:2)
What was attacked here is the "crates" packaging system, which is used by the majority of user space Rust programs, but not by the Linux kernel.
Re: (Score:2)
What was attacked here is the "crates" packaging system, which is used by the majority of user space Rust programs, but not by the Linux kernel.
Isn't crates written in Rust, which promises to force you to write secure code?
Re: (Score:2)
It promises memory-safe code and memory safety is not the issue here. It is impossible to have a general purpose language and guarantee that it cannot be used to do bad things.
The question of whether CI and build systems can be made more resilient should definitely be asked. Putting secrets in environment variables may be too large of an attack surface. But those issues apply to any programming language.
Re: (Score:2)
You can do CI safely as long as you don't do it on the public internet and let anyone mess with it. It seems like that was the issue here.
Re: (Score:2)
Re: (Score:1)
Both are Turing complete, so yes. Your point? C++ is even worse than C or Rust. So there.
Re: (Score:1)
Children and artists can write C++. If you can't, you're incompetent.
Re: (Score:2)
Re: (Score:2)
Children and artists can write C++. If you can't, you're incompetent.
Can children and artists understand some arbitrary code from some arbitrary C++ project? No? I thought so.
C++ is just not a suitable language for an open source project managed according to the "bazaar", as opposed to the "cathedral" paradigm, due to the sheer complexity of its full manifestation. Use C++ in any part of Linux, and be assured that the "thousand eyes" which can and will look at the code of that part will be reduced to tens. And this defeats one of the central points of Linux, IMHO.
Plus, it's
Re: (Score:2)
Re: Worthless Language (Score:2)
/facepalm
The Evil Analingist is back with his programming advice, and it's as shitty as ever.
C++ is better than C. Unlike C, you're not forced to use unsafe features by default.
Just remember that when you forgot when you used an LPCTSTR when the API asked for a LPCWSTR. Oh wait, you don't know what those are? Guess you should go back to art school.
Hahahaha (Score:2)
"But but but... memory safety!!!!"
Yeah.