Comment by aftbit

1 day ago

Has anyone from the AUR team (such as that is) published a retrospective yet? This was some impressively fast firefighting but in all honesty, it seems like some changes are needed, either in AUR policies or in the wrappers.

I should be able to set a minimum package age just like I can with pnpm.

Orphaned packages should not be adoptable by just anyone. Maybe there should even be a global rate limit on this as a sign of attack.

Someone or something should vuln-scan these packages as they're published, as a number of companies do for NPM now. That would likely have found these pretty quickly.

Most of these are not changes to be made by the AUR maintainers, but rather by packaging helpers and 3rd parties.

9 comments

aftbit

Reply
whateverboat  1 day ago

Better would be to namespace AUR packages. That way, ownership is not lost and we don't need orphaning at all.

  • no-name-here  19 hours ago

    Are you suggesting like <package-name>.packaged-by.joe-Schmoe ? And then if Joe Schmoe abandons it, people should instead switch to <package-name>.packaged-by.Abe-Lincoln etc?

    • whateverboat  10 hours ago

      I mean we can talk about the actual naming scheme but essentially yes.

      It is also an explicit signal of someone different taking over the ownership.

embedding-shape  1 day ago

> Orphaned packages should not be adoptable by just anyone. Maybe there should even be a global rate limit on this as a sign of attack.

Why not? I agree some limits should be added, but also shouldn't be too limited, then lots of things that could be properly maintained, won't. Maybe limit adoption to one package a month or something, to users registered since some date. But no one has automatic (& unreviewed) updates applied to their locally installed AUR packages (that'd be utterly bananas) so the attack vector is already pretty small here.

cookiengineer  20 hours ago

> Someone or something should vuln-scan these packages as they're published, as a number of companies do for NPM now. That would likely have found these pretty quickly.

No. It wouldn't have. That's the whole point of the miasma worm, because it changes too fast in its signatures and helper methods. The encrypted malware implant uses a changing AES-128-GCM key that's used to decrypt the payload, and that key is per-where-it-is-uploaded on GitHub. The code itself is dynamically renamed in its methods, re-used shuffled offsets for encrypted symbols, among other things. It's a mutating malware and the worst enemy from tools that rely on signatures.

Ironically, APT28/29 is somewhat relying on Microsoft being too slow to auto block users and repositories on GitHub that are the C2 infrastructure. Think about that for a second what this implies for your cyber strategy.

By the time you're able to scan signatures or "strings" you're already playing a cat and mouse game with a fully automated botnet, which you will never win. The only other ones I've observed during the last week that seem to be able to track this malware implant's changes were socket.dev. ALL other supply chain tools didn't even know about Miasma and re-invented it as a new campaign. They didn't have the skilled enough people nor toolchain to reverse the malware payload quickly enough to be able to keep up every 24h when they push out a new adapter for another ecosystem.

By fully automated I mean they're already using the credentials they stole less than 48 hours ago from a different package ecosystem, because the email addresses and names etc keep appearing from people who likely didn't even understand the impact of this self-spreading worm.

And having an IOC that checks for, let's say, any package that depends on bun won't help either because the malware will just use external means to re-download it. See the second PyPi campaign, where they just changed the dropper to use compressed WHL files and the setup.pth files that are auto-executed to download the dropper. They changed this after the PyPi maintainers flagged the first wave of malware droppers from the RedHat campaign.

As long as the package managers in those ecosystems aren't fully rewritten from scratch to accomodate for chroots, sandboxes, network and domain logs that are _only allowlistable per entry_ this won't change, and will stay being a feasible malware deployment strategy for supply chain attacks.

Repo for Mitigation Tool (I'm human so I play catch 21 with an LLM powered botnet) [1] ... Tech details in the blog post [2]

Also this is a problem across all package managers. Composer is also affected. Rubygems is also affected. NPM is also affected. PyPi is also affected. Go is also affected.

Nobody is talking about this, and I think this should be more openly discussed how much negligence and external trust we put in package managers in general. This really needs to change.

[1] https://github.com/cookiengineer/antimiasma

[2] https://cookie.engineer/weblog/articles/malware-insights-mia...

  • aftbit  10 hours ago

    With this _actual_ attack, it would have been trivial to detect. The signature was:

    1. Orphaned package adopted

    2. Has post-install hook added

    3. Which uses npm or bun

    Yes, you're right - detecting this could have led to a more sophisticated attack. Security is always a cat and mouse game. The purpose isn't to stop every attack - it's to raise the costs for attackers and the visibility for defenders.

    Any attacker who wants to attack 1000s of packages is going to necessarily leave some signatures, unless they're extremely careful. If they change one thing but not another, you can tie them both together.

    Think of this like email anti-spam. It hasn't gotten rid of spam, but it has made it much more expensive to operate.

    Combine this with a minimum package age to give the scanners time to run and humans time to inspect, and the ecosystem as a whole gets much more secure.