4 ms·
This whole thing has been consuming me over the whole weekend. The mechanisms are interesting and a collection of great obfuscations, the social engineering is
by bilekas 3y ago
This whole thing has been consuming me over the whole weekend. The mechanisms are interesting and a collection of great obfuscations, the social engineering is a story that’s shamefully all too familiar for open source maintainers.
I find most interesting how they chose their attack vector of using BAD test data, it makes the rest of the steps incredibly easier when you have a good archive, manipulate it in a structured method (this should show on a graph of the binary pattern btw for future reference) then use it for a fuzzy bad data test. It’s great.
The rest of the techniques are banal enough except the most brilliant move seems to be that they could add “patches” or even whole new back doors using the same pattern on a different test file. Without being noticed.
Really really interesting, GitHub shouldn’t have hidden and removed the repo though. It’s not helpful at all to work through this whole drama.
Edit: I don’t mean to say this is banal in any way, but once the payload was decided and achieved through a super clever idea, the rest was just great obfuscation.
- mondrian 3y agoA main culprit seems to be the addition of binary files to the repo, to be used as test inputs. Especially if these files are “binary garbage” to prove a test fails. Seems like an obvious place to hide malicious stuff.
- bilekas 3y agoIt is an obvious place for sure, but it also would have been picked up if the builds where a bit more transperant. That batch build script should have been questioned before approval.
- j16sdiz 3y agoBy whom? The attacker have assumed the maintainer role. Nobody is reviewing.
- NarcissistDev 3y agoThere’s a severe and dangerous lack of paranoia in this dev space. If I was letting someone maintain my codebase, I would 1 Billion percent be reviewing everything… if there was a binary added, I’d be building it myself and comparing the checksums. Trust absolutely no-one. If you can give a close friend or a loved one a loan of money and it is so easy for them to never pay you back, it should be a reminder that devs you’ve never met are even more likely to scam you.
- waihtis 3y agopretty unhealthy attitude to live by tbh. almost better being burned by a malicious payload once every 10 years than live in perpetual fear of being constantly scammed
- daymanstep 3y agoI think that depends on the context. If you're maintaining one of the most widely used packages that is directly linked to by libsystemd and is included by pretty much every Linux distro as part of the base system? Then maybe some measure of paranoia is justified. I think the OpenBSD developers are right to be as paranoid as they are. Anyone who is maintaining a security critical system should be on guard against these kinds of attacks.
- waihtis 3y agoOh absolutely true for things like OpenBSD and such
- NarcissistDev 3y agoThing is, sec should be taken seriously across the board. I love what OpenBSD devs did - they seen an entire community of naive coders who didn’t give much of a crap about security and started something. I have used OpenBSD for 10 years and thoroughly recommend it to anyone to give you a good slap around the face for how shit is done right.
- withinboredom 3y agoIt’s got me suspicious of build-time dependency we have in an open source tool, where the dependency goes out of its way to prefer xz and we even discovered that it installs xz on the host machine if it isn’t already installed — as a convenience. Kinda weird because it didn’t do that for any other dependencies. These long-games are kinda scary and until whatever “evil” is actually done you have no idea what is actually malicious or just weird.
- ToneWashed 3y ago> It’s got me suspicious of build-time dependency we have in an open source tool, where the dependency goes out of its way to prefer xz and we even discovered that it installs xz on the host machine if it isn’t already installed — as a convenience. Kinda weird because it didn’t do that for any other dependencies. Have you considered reaching out to the maintainers of that project and (politely) asking them to explain? In lieu of recent events I don't think anyone would blame you, in fact you might even suggest they explain such an oddly specific side effect in a README or such.
- withinboredom 3y ago> Have you considered reaching out to the maintainers of that project and (politely) asking them to explain? That's kind of a catch-22, right? They'd explain with a seemingly good answer if they did it for actual reasons. They'll still explain with a seemingly good answer if they did it for nefarious reasons. I don't have a good answer to this except to monitor this dependency and its changes.
- wholinator2 3y agoIs it possible that it was added by a bad actor, and that most of the individuals in contact will not have signed off on it? I mean, this whole thing started by an interested party digging deeper than anyone else had, you could trigger that for someone else. At the very least, what do you have to lose? If the best they can do is look like they're fine, then every possible side effect is to root up a frighteningly well hidden inflator
- throw156754228 3y agoThey removed the repo so only the attackers had access to the code and know how.
- andybak 3y agoNo. They obviously didn't do that so you're just being sarcastic but not actually making any point of your own in addition to that.
- throw156754228 3y agoIntended levity, gee you sound miserable. Try some exercise in the mornings?
- deleted 3y ago[deleted]
- andybak 3y agoRead the room... This ain't Reddit.
- throw156754228 3y agoWell this very reply you made is very much like something I would see on Reddit.
- byteknight 3y agoThe door is that way, kind sir.
- throw156754228 3y ago[flagged]