Hacker News Reader

Comment by 0xDEAFBEAD | Hacker News Reader

I notice that the getsymbol tool on Github has 214 stars, and no banner to indicate that the tool is malicious. There is a recently filed issue with a link to the Google blog post, but that's it.

If anyone from Github is reading this -- I strongly suggest adding a banner or modal dialogue to warn users about the backdoor in this tool, and any other software with a known backdoor (e.g. forks of the project)

View on HN

This also serves as a reminder that code hosted on github might be malicious and we shouldn't blindly trust those just because the author seems to have similar interests.. I've done that multiple times :(

That's true, but in this case the code might be fine and the executables they provide on GitHub bogus. It's tricky to keep in mind that GitHub is not a trusted build source.

And the GitHub Actions… oh man… Insert some tool in your build that comes from another random repository, that uploads an artifact to S3 or similar… GitHub’s architecture entirely is the iMessage of source code.

Could you please expand on your iMessage comparison? I don't understand what you're referencing.

I don’t know if I 100% follow or agree with the comparison of iMessage and GitHub actions. But iMessage has had a number of interesting security vulnerabilities over the years in image parsing and deserialization. One example:

https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...

Or a story from today:

https://news.ycombinator.com/item?id=37425007

So perhaps the similarity between iMessage and GutHub actions is there are a lot of things that could go wrong. In iMessage it’s a pile of memory unsafe code that was not originally designed to withstand attack. In GutHub actions there is a lot of trust in their parties that could potentially be exploited.

And yet Android had multiple high and critical CVE's reported in the last few days with little coverage:

https://source.android.com/docs/security/bulletin/2023-09-01

«А у вас негров линчуют»

This isn't an Android vs Apple article.

Its not an iOS / iMessage article either but it was brought up here and is the point if this current thread.

Coverage is proportional to the number of users :)

Where do CVEs tend to show up app-wise in Android? Is it also messaging or some other system service? With iOS its almost always either iMessage, WebKit, and iCloud Calendar

The normal thing is to have integration test PRs and other CI actions (which may require access tokens to APIs, inherently or due to naive design) be defined by the incoming branch, creating a vector for an attacker to get access to privileged resources.

For certain parts of integration and testing jobs that are operating on untrusted code, it'd therefore be desired to not allow incoming PRs to change certain parts of the CI configuration (not only including .github/workflows, which can be protected using branch protection rules, but the testing framework).

It's possible to achieve this by splitting up your workflows and using workflow_run but it's non-obvious and finicky enough that I very rarely see it done.

GitHub could make this easier and propose better patterns than they do in their attempt to address the problem[0], which I think could use a 2023 follow-up.

[0]: https://securitylab.github.com/research/github-actions-preve...

---

In this context, an iMessage message <> a GitHub PR, I guess.

> Could you please expand on your iMessage comparison? I don't understand what you're referencing.

https://arstechnica.com/gadgets/2023/09/apple-patches-clickl...

iMessage itself is a dumpster fire that time and again has been proven to be an attack vector.

A lot of useful features are missing from actions/checkout@v3, so people have to either program actions manually, or use ones made by other GitHub users. Actions are build steps, such as opening a firewall before building, preparing a directory, or caching Maven artifacts.

It would be very easy to add a backdoor to one of those build steps.

The comparison with iMessage is that it’s unsafe by design, at the architecture level, because you’re relying on live code made by anonymous people. One day, attack vectors will be found every second day.

It strikes me as the classic NPM disease. Do we really need a reusable action for disabling a firewall, uploading files, etc.? I mean if it comes from GitHub that's fine, but for anything else I would rather verify the solution and copy the code. It works like a low-tech lock file, except changes are always visible inline in Git history, so less chance of lazy programmers missing changes.

I almost laughed when GitHub suggested me an Action for Makefile based projects. The entire build process in my case consists of "make package"...

> if it comes from GitHub that's fine

No it isn't.

It's become normalized but it isn't fine. Whoever thought it was a good idea to download massive amounts of unaudited code at build time to then run it behind your defensive lines should have thought about that a bit longer. CI/CD is great. GitHub/GitLab are great. But combining the two has substantial risks. More so for languages that have broken package management and namespace issues.

You are of course right. I was thinking more in terms of "how do we save clueless developers (and their users) from themselves". They will probably find more ways to shoot themselves in the foot, but any percentage of prevented vulnerabilities is a positive result. Kind of like people trust Google/Apple with their phones.

I think it's safe to say that you can just about give up on that. The IT landscape is a horrific mess and it doesn't look like there is any change in direction on the horizon that will help to rectify that.

If you trust Google or Apple with your phone then I'm fine with that, it's your phone, your life. But I've found that trusting companies to have their incentives aligned with your own or with what's good for the world in general is a structural mistake that will find you disappointed each and every time given a long enough engagement. You can't trust that which you don't own and can't verify.

As a startup delivering executables to customers, I decently trust most programs running in the company: Gimp, Libreoffice, Docker, IntelliJ… There are only 4 major things that download unchecked stuff and run them:

- IntelliJ plugins,

- Maven,

- NPM,

- GitHub Actions.

Jetbrains says it carefully reviews the source code of all versions of all plugins, and Maven has a somewhat decent dependency tree that you can restrict to major actors (Spring-Apache-Google).

Maybe the key to trust would be to have larger pieces of code (such as Spring) with quite a lot of process to check-in code, rather than a thousand NPM packages. The parcellization of OSS didn’t do good for trust.

Yes. Remember that not only security researchers but also developers in general are extra juicy targets because of e.g. their AWS credentials that sometimes aren't kept as secure as they need to be. Heck, even if you're doing proper SSO with 2FA the tokens can be stolen and data proxied/exfiltrated.

At best they can be used for coin mining (running up a huge bill), at worst for stealing private customer data (and then selling/ransomwaring it).

> e.g. their AWS credentials that sometimes aren't kept as secure as they need to be

There is some irony in there.

We have pretty high bars for what we allow in terms of outside dependencies, but that doesn’t mean they do. It’s basically a crap shoot if you choose to do open source at all.

And that includes libraries that you blindly pull down from package managers

The source code itself looks relatively clean; there's autoupdate functionality but it looks like it's gated behind a confirmatory dialog box.

It's much more likely that the binary releases and/or autoupdate binaries are backdoored. If someone compiles their own version, and then clicks to accept the autoupdate, they could be infected. The binary is 15+MB in size, which is far more than enough to hide a small backdoor.

It's the auto-update functionality from a now-suspect URL. The repo has since been taken down, but here's the suspect file:

https://github.com/dbgsymbol/getsymbol/blob/cb4bdedc1a85c308...

Drat, archive.org didn't snag it. Do you happen to have a copy? https://web.archive.org/web/20230000000000*/https://github.c...

check https://github.com/bb33bb/getsymbol and https://github.com/clayne/win-getsymbol, two up to date forks -- and my comment above https://news.ycombinator.com/item?id=37425311

Found these two forks which are still accessible (and are supposedly up to date with the upstream repo (linked in the comment above) which is not accessible anymore):

https://github.com/bb33bb/getsymbol

https://github.com/clayne/win-getsymbol

here is the same link as in the comment above from one of the forks:

https://github.com/bb33bb/getsymbol/blob/main/GetSymbol/CMai...

the code fetches from `UPDATE_CHECK_URL`, which is hardcoded as:

https://dbgsymbol.com/version

which as of the time of this posting, returns:

"GetSymbol 2.0.3|https://dbgsymbol.com/downloads/2.0.3/GetSymbol.exe"

the GetSymbol.exe file (which is downloadable right now) being presumably the infected file being discussed..!

wow! all mirror repos (I found 5) have since been disabled :-)

you can still see cached bits of the code via github search -> https://github.com/search?q=path%3AGetSymbol%2FCMainDlg.cpp+...

and a tiny bit of the repo's main page in google's cache: http://webcache.googleusercontent.com/search?q=cache%3Ahttps...

and the user's github profile, again from google's cache: https://webcache.googleusercontent.com/search?q=cache:JXXyoV...

the dbgsymbol.com links above still work, obviously.

Github just erasing a repo and forks from existence is scarier than any potential malware that could have been included there. Not the first time they have done this - usually based on copyright accusations, but the reason does not matter - if you must use ShitHub, at least mirror your projects elsewhere folks.

Yeah that’s what I’m referring to. IIRC it requires clicking/confirming a dialog to actually run the “update”, although I didn’t look that carefully before it got taken down.

There were also some binary DLLs in the repo (in the x64 directory) which get loaded/executed on first launch and then deleted. I didn’t reverse-engineer to see if there was anything malicious inside of them, but it seemed pretty fishy to me.

>I notice that the getsymbol tool on Github has 214 stars ...

Analysis of which accounts starred it prior to publicity is probably a worthwhile endeavor. If there's any commonality with other obscure projects, that may be an indicator those accounts could be puppets.

Unfortunately that opens up a whole new can of worms. There are already sites that guess how fake amazon reviews are, maybe we need something similar for github.

I hope an analysis like you proposed could yield some insights to patterns or maybe even enough data to do some machine learning on.

But how do I trust the tool that guesses how compromised a repo is?

You post it to HN and claim that it's safe. If you aren't proven wrong in the next 2 hours, it probably is.

It looks like it just got taken offline

Yep. Page Not Found now.

I just had a look at it like 30 minutes ago and it was still there then.

Here are archives of what it looked like

http://web.archive.org/web/20230907185609/https://github.com...

http://web.archive.org/web/20230907193333/https://github.com...

http://web.archive.org/web/20230907193402/https://github.com...

I think it's better to give an obvious warning and archive it. As a reminder to people.

I reported the repository as malware, guess we'll see what happens with it

> Our review of the account named in your report has concluded. We have determined that one or more violations of GitHub’s Terms of Service have occurred and have taken appropriate action in response.

I'm really curious where the 0-day is in the code of the project honestly

The 0-day is in a popular software package. The GitHub repo apparently contains a backdoor ability to execute code from the attacker. If I had to guess, this would be the software update functionality here: https://github.com/dbgsymbol/getsymbol/blob/cb4bdedc1a85c308...

That's just malware. There's no 0-day here.

That’s what Google is calling it, so I’m inclined to believe them.

"In addition to targeting researchers with 0-day exploits, the threat actors also developed a standalone Windows tool that has the stated goal of 'download debugging symbols from Microsoft, Google, Mozilla and Citrix symbol servers for reverse engineers.'

The attackers used a 0-day but getsymbol is not one.

Yep, that’s what I said.

No it isn’t what you said at all. You said Google was calling malware a zero day and you believe them, but they aren’t doing this.

This is what I said:

> The 0-day is in a popular software package.

(I have no idea what this is.)

> The GitHub repo apparently contains a backdoor ability to execute code from the attacker.

(This is what Google says and I think it’s the autoupdater.)

Is this different than what you feel?

Seems to be some dll:s included. Maybe there?

"But the tool also has the ability to download and execute arbitrary code from an attacker-controlled domain."

Sounds like most software nowadays to be honest. The blog author does not really point out why this code would be more malicious than "normal" or how the code author is known to be Korean.

This "UpdateCheckThread" code looks pretty funky, [0]. It downloads some stuff from a URL, writes a file to disk, and creates a process to run it.

0: https://github.com/dbgsymbol/getsymbol/blob/cb4bdedc1a85c308...

If the code is wrapped in

   if (updateDlg.DoModal() == IDOK) { … }

then doesn’t that mean it only runs that code if the user clicks “OK” on the update dialog?

(Edit: I think I understand now. It’s not the code, it’s the update URL that’s the problem, because it’s controlled by NK. So if you run this and blindly click “OK”, then it will download an executable that will infect your PC.)

(Edit 2: Or the issue is not in the source at all, but is in the prebuilt binary.)

It could be that the code is fine but the URL is compromised?

Does github have that on any repos? If so, I’ve never stumbled across it.

> If anyone from Github is reading this -- I strongly suggest adding a banner or modal dialogue to warn users about the backdoor in this tool, and any other software with a known backdoor (e.g. forks of the project)

I'd also strongly suggest they add a way to flag projects in a way that is appropriate.

What's the point of the warning? Wouldn't Github just removing the offending repo?

Unfortunately, looks like it did.

...which while admirable from one perspective, also effectively destroys the evidence.

I prefer the warning instead.

It also normalizes removing repositories for other reasons.

Content providers have an obligation and responsibility to remove content for a variety of reasons. It's already normalised, as it should be.

It looks like its no longer on Github. Does anyone have the source code mirror? I would love to get a peek on it.

there is an open issue that warns about this

Reply on news.ycombinator.com