5 ms·

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 fr

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?

ronsor 6y ago
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.
- mehrdadn 6y ago
  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.
- katbyte 6y ago
  I presume it would be opt in, would make for a handy github action tbh
  - mehrdadn 6y ago
    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.
ThePadawan 6y ago
The relevant code was (allegedly) not part of source control, but inserted during the build process.
- mehrdadn 6y ago
  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?
  - ThePadawan 6y ago
    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).
    - mehrdadn 6y ago
      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!
  - eternalny1 6y ago
    SolarWinds themselves it claiming it. https://www.solarwinds.com/securityadvisory/faq 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?"
woodruffw 6y ago
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/administering-a-repository/about-secret-scanning https://docs.github.com/en/free-pro-team@latest/github/admin...
colek42 6y ago
I wrote about some mitigation steps here https://boxboat.com/2020/12/14/safeguarding-the-world-from-the-solarwinds-hack-and-future-supply-chain-attacks/ https://boxboat.com/2020/12/14/safeguarding-the-world-from-t...

ronsor 6y ago

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.

mehrdadn 6y ago
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.
katbyte 6y ago
I presume it would be opt in, would make for a handy github action tbh
- mehrdadn 6y ago
  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.

ThePadawan 6y ago

The relevant code was (allegedly) not part of source control, but inserted during the build process.

mehrdadn 6y ago
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?
- ThePadawan 6y ago
  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).
  - mehrdadn 6y ago
    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!
- eternalny1 6y ago
  SolarWinds themselves it claiming it. https://www.solarwinds.com/securityadvisory/faq 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?"

woodruffw 6y ago

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/administering-a-repository/about-secret-scanning https://docs.github.com/en/free-pro-team@latest/github/admin...

colek42 6y ago

I wrote about some mitigation steps here https://boxboat.com/2020/12/14/safeguarding-the-world-from-the-solarwinds-hack-and-future-supply-chain-attacks/ https://boxboat.com/2020/12/14/safeguarding-the-world-from-t...