Live data from Hacker News

Glassworm is back: A new wave of invisible Unicode attacks hits repositories

aikido.dev

11–20 of 201 posts

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#13
post #4
post #2

Why didn't some make av rule to find stuff like this, they are just plain text files

Yeah it would have been nice to end with "and here's a five-line shell script to check if your project is likely affected". But to their credit, they do have an open-source tool [1], I'm just not willing to install a big blob of JavaScript to look for vulns in my other big blobs of JavaScript [1] https://github.com/AikidoSec/safe-chain

Something like this should work, assuming your encoding is Unicode (normally UTF-8), which grep would interpret:

  grep -P '[\x{200B}\x{200C}\x{200D}\x{FEFF}]' code.ts
See https://stackoverflow.com/q/78129129/223424

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#15
post #8

IMO while the bar is high to say "it's the responsibility of the repository operator itself to guard against a certain class of attack" - I think this qualifies. The same way GitHub provides Secret Scanning [0], it should alert upon spans of zero-width characters that are not used in a linguistically standard way (don't need an LLM for this, just n-tuples). Sure, third-party services like the OP can provide bots that…

Regardless of the thorny question of whether it's Github's responsibility, it sure would be a good thing for them to do ASAP.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#16
post #7

The `eval` alone should be enough of a red flag

No it’s not.

OWASP disagrees: See https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Securi..., listing `eval()` first in its small list of examples of "JavaScript functions that are dangerous and should only be used where necessary or unavoidable". I'm unaware of any such uses, myself. I can't think of any scenario where I couldn't get what I wanted by using some combination of `vm`, the `Function` constructor, and a safe wrapper around `JSON.parse()` to do anything I might have considered doing unsafely with `eval()`. Yes, `eval()` is a blatant red flag and definitely should be avoided.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#17
It baffles me that any maintainer would merge code like the one highlighted in the issue, without knowing what it does. That’s regardless of being or not being able to see the “invisible” characters. There’s a transforming function here and an eval() call.

The mere fact that a software maintainer would merge code without knowing what it does says more about the terrible state of software.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#18

Back in time I was on hacking forums where lot of script kiddies used to make malicious code. I am wondering how that they've LLM, are people using them for making new kind of malicious codes more sophisticated than before?

In this case LLMs were obviously used to dress the code up as more legitimate, adding more human or project relevant noise. It's social engineering, but you leave the tedious bits to an LLM. The sophisticated part is the obscurity in the whole process, not the code.

Re: Glassworm is back: A new wave of invisible Unicode attacks hits repositories

#19
Looks like the repo owner force-pushed a bad commit to replace an existing one. But then, why not forge it to maintain the existing timestamp + author, e.g. via `git commit --amend -C df8c18`?

Innocuous PR (but do note the line about "pedronauck pushed a commit that referenced this pull request last week"): https://github.com/pedronauck/reworm/pull/28

Original commit: https://github.com/pedronauck/reworm/commit/df8c18

Amended commit: https://github.com/pedronauck/reworm/commit/d50cd8

Either way, pretty clear sign that the owner's creds (and possibly an entire machine) are compromised.

Post reply on HN