Hacker News new | ask | show | jobs
by mehrdadn 2051 days ago
Any GitHub/GitLab/etc. employees here? I think you might be able to help mitigate some of these kinds of attacks:

> To have some minimal form of obfuscation from prying eyes, the strings in the backdoor are compressed and encoded in Base64, or their hashes are used instead.

There needs to be a quick tool that flags strings that appear to represent binary data before a merge, maybe even decoding them when possible and providing hints of what they might represent, especially inside source-code files. These shouldn't be common in checked code. And we should figure out a way to whitelist them in the repo that's both safe and convenient (I'm not sure how).

Is this a feature code-hosting sites like GitHub can add?

4 comments

The relevant code was (allegedly) not part of source control, but inserted during the build process.
Hmm, interesting. I'm confused if that's how I should read this. You might be right. I assume you're referring to this paragraph?

> Evidence suggests that as early as October 2019, these attackers have been testing their ability to insert code by adding empty classes. Therefore, insertion of malicious code into the SolarWinds.Orion.Core.BusinessLayer.dll likely occurred at an early stage, before the final stages of the software build, which would include digitally signing the compiled code.

They talk about adding classes at an early stage... I assumed that meant modifying the source code in some fashion. Sounds like you took it to mean they inserted binary (MSIL?) code during the build? Or are you referring to a different paragraph that indicates this wasn't part of source control?

SolarWinds themselves it claiming it.

https://www.solarwinds.com/securityadvisory/faq

> Our initial investigations point to an issue in the Orion software build system in which the vulnerability was insert which, if present and activated, could potentially allow an attacker to compromise the server on which the Orion Platform products run.

Under "With these processes in place how was your code compromised?"

If the compromise was inserted during the build process, then one countermeasure could have been reproducible builds. Reproducible builds require the source code, but they can verify whether or not the build matches the claimed source code. That would work even after it was signed.
Thanks!
I was also thinking of manipulating source code. Let's say there are multiple stages:

1. Source code as available on development machines and version control

2. Source code as available on build machines

3. .dll generated by build machines

I would assume (based on the article's language that you quoted) that manipulation happened on (2), not (1) or (3).

Oh interesting. So that would mean it would depend on a compromised build machine. Yeah, that would make sense, and I guess you couldn't prevent it like this in that case. Thanks!
If it was standard to compare a dependency graph of the program architecture pre and post build, then you would catch these sorts of things right away. Supply chain attacks are not new and I imagine at least some companies have a process like this in place already.
What do you mean by "dependency graph" here?

Seems to me like this malware might as well have been added to the calling assembly.

That's just going to cause annoying false positives, and it's not that difficult to get around such detection.

I'll bet the only result would be confused developers.

I can imagine it failing or succeeding depending on how intrusive the UX is. It's worth trying out I think, especially in an opt-in fashion. They can improve it gradually and people can leave it disabled if they don't like it.
I presume it would be opt in, would make for a handy github action tbh
Note that it shouldn't be an "action" on GitHub Actions, since those are specified in the repo itself, and can hence be removed in the same commit. It needs to be an external thing.
I'm not a GitHub employee, but this is probably something that could be (either today or with some changes) via secret scanning[1].

[1]: https://docs.github.com/en/free-pro-team@latest/github/admin...