Some thoughts about attribution in the XZ backdoor, having just wasted so many hours digging into the details.

The email addresses used for a couple of years at least by the parties involved have absolutely *zero* trace in any kind data breach or database beyond Github/Gitlab, and maybe Tukaani and Debian and a few mailing lists.

Normally when I see this, the assumption is that we're dealing with a single-use or single-purpose email address that was created either for fraud or b/c someone is super paranoid about privacy.

The people in the latter camp who do this tend to have other tells that give them away, or at least *some* trace or home base in the online world. Especially if we're talking on the order of years using that address.

Either way, very few people do opsec well, and for every year you're operating under the same name, nick, number, email, etc you dramatically increase the risk of screwing up that opsec. And almost everyone does, eventually.

To see this complete lack of presence in breached databases once or twice in the course of an investigation is rare, but to find it multiple times suggests we're dealing with an operation that was set up carefully from the beginning. And that almost certainly means a group project (state-sponsored).

Sometimes you get gems from LinkedIn:

From Chris Wysopal:
https://www.linkedin.com/in/wysopal/

"It would be interesting to run this analysis across all open source committers. I'm keen to understand if we can root out other backdoors by detecting signals like these learned from the XZ backdoor incident."

THIS!

@briankrebs Single purpose email addresses are pretty common in the Open Source scene. That is: people who maintain linux packages, not crypto bros with a github account.

@publictorsten @briankrebs

I bet if you account for the name+purpose trick you could get a long way though. And remember, we're not looking for yes/no detection here, we're accumulating signals.

@mhoye @briankrebs while accumulating, keep in mind: in this special community not only someone is super paranoid about privacy. Everybody is. It's a necessity.

If they are my age, they have Usenet experience.

@publictorsten Maybe. But you probably also can connect other aspects of how that account is used or with what in some way. Or there will be multiple accounts that match some kind of naming convention, provider, etc. over the years.
@briankrebs Just a hint: use every other aspect, not single purpose email addresses.
@publictorsten Also, finding privacy-minded people using single-purpose emails is not a bad thing; it just helps reduce the size of the haystack for closer examination. I bet some very interesting patterns would emerge.
@briankrebs I really like them. My email provider even gives me temporary addresses, that are routinely deleted after three months.
@briankrebs @publictorsten There are whole services dedicated to making it easier to use single-purpose emails. I use them pretty often myself for a variety of stuff. Especially among the type of folks who do open source I suspect that may not be as strong a signal as you might think.
@Chronotope @briankrebs strong correlation with people who use mutt :-)
@Chronotope @publictorsten Only one way to find out. I hope there are multiple grad school teams working on this right now.
@briankrebs @Chronotope because you don't like grad schoolers? :-)
@briankrebs @Chronotope I know some studies made about Wikipedia admins. It's a rough ride, and nobody gets it right.
@Chronotope @briankrebs @publictorsten just bear in mind that "single use" and "single purpose" are rather different things.
@Chronotope @briankrebs @publictorsten This is increasingly common with the rollout of built-in single purpose email services like the Firefox Relay Mask. Also, you'd need to do some regexing bc a lot of people use variants of their emails, e.g., first.last@email, f.irstlast@email, and firstlast+thiswebsiteonly@email all go to the same place. I agree that this proposal also has a privacy ick factor to it, but I like the idea of finding heuristics. Maybe we should make a list of all the bullies 🙃
@briankrebs Can absolutely guarantee this is what the major intelligence agencies are doing today. If it was state-sponsored, as it appears, I would also expect certain elements of the identity creation process to be programmatic. There is also a strong likelihood that linguistic analysis would find inconsistencies with the regional variations and potential repetition of identifiable phrases across profiles.

@briankrebs I’d be very interested in taking a look at any of the text attributed to the TA to see if any clues were incidentally left over the years. Writing style is an often overlooked element of opsec and one that’s difficult to mask consistently, especially if more than one human is behind the screen name.

Minimally, an assessment of their English proficiency and use of slang would at least crudely indicate the geographic orgin

@briankrebs single purpose email are becoming more common if not squarely defacto behavior with the ease of use that password managers brings so timing should also be put on the scale with other factors. An old single use email when password managers weren't so commun might be slightly more indicative.

Overall, I'm fearful it's going down the witch hunt path when more energy should be put to actually strengthening the whole oss trust problem...

@waps I feel calling it a witch hunt rn is a) a loaded term and b) a disservice to a ridiculous number of people who are very curious how far this goes, and I think rightfully so. If we don't start asking these questions now, we will not learn much from this episode.
@briankrebs absolutely agree. It is not a witch hunt in the case of xz and it is a logical step to introspect industry wide with whatever indicators we currently have. What I meant was that I see a line that could be cross by some less meticulous individual pointing fingers at some edges case past contributions based on flimsy indicators without actually looking at the code/binaries first.
@waps Yep. Such an effort calls for a rigorous approach, which is why I suggested academics, because they have the time, the drive and the rigor, and if not we can check their work (ideally). I assume the 3-letter agencies are already doing this, but I would not expect them to share the results.
@briankrebs That’s assuming the three letter agencies can’t find all the other cases of this just by asking around their own internal offensive capability teams…. I strongly doubt this is the only instance of this attack underway right now, and I for one would not bet against it being an NSA program… @waps
@bigiain @briankrebs this reply from @bontchev makes a lot of sense on the attribution front https://infosec.exchange/@bontchev/112197387774851300
I only slightly disagree with the analysis on the premise that with the backdoor access limited by a private key, NSA's legal team might have sign off on such an operation as they could later authorize on a case by case by limiting the private key usage and ensuring the target was legal. I highly dislike such magical thinking that they could keep the genie(the key) in the bottle but history makes it in the realm of plausible as they have repeatedly seek to break crypto with lawful key escrow crap.
VessOnSecurity (@[email protected])

@briankrebs So, clearly a state actor. But which one? - Russia? No. They generally don't give a shit if they are discovered ("whatcha gonna do, nuke us?") and this backdoor was carefully tailored so that even if discovered, nobody else could use it. - China? Unlikely. They are a bit more careful than the Russians but this whole modus operandi doesn't fit their style, especially the sophistication of the backdoor. - The USA? I don't think so. They certainly could have made the backdoor - but attacking the whole world, including US computers? The NSA's legal department wouldn't have permitted this. - The UK? Not impossible and they are big on plausible deniability. Hmmm... - Israel? They certainly have the sophistication (especially in collaboration with the USA) and are ruthless enough to attack the world. Plus, the time zone of the commits matches them too; not just Eastern Europe. But they are kinda busy with other stuff right now. Still, I'd put them in the "possible" category; this op predates their current activities. - North Korea, Iran, etc.? No way, this kind of sophistication is way above their head.

Infosec Exchange
Hans-Christoph Steiner (@[email protected])

Three years ago, #FDroid had a similar kind of attempt as the #xz #backdoor. A new contributor submitted a merge request to improve the search, which was oft requested but the maintainers hadn't found time to work on. There was also pressure from other random accounts to merge it. In the end, it became clear that it added a #SQLinjection #vuln. In this case, we managed to catch it before it was merged. Since similar tactics were used, I think its relevant now https://gitlab.com/fdroid/fdroidclient/-/merge_requests/889

Librem Social
Royce Williams (@[email protected])

Indeed. One practical, broad ecosystem shift on the technical side should be to bring more focus to the test / blob / binary-releases / autotools / m4 sides of the house. The attackers were ensconced there for a reason - notoriously non-reproducible, complex, organically interdependent ... and largely ignored. Reducing complexity, and increasing legibility / reproducibility, will take time - but will have multiple benefits. On the non-technical side, the perennial problem of supporting maintainership persists. IMO, there's public good here that should have corresponding pooled support - but I'm unclear what's logistically (and politically) feasible to move that forward. And underpinning all of it is mapping the dependency map - to inform decisions about which components to prioritize. Edit: and to make it explicit, it should be very clear that all of the above is *exactly* what the *adversary* did, and is doing - with the opposite goals. Edit 2: And flip it for threat hunting! (h/t: @tinker): https://infosec.exchange/@tinker/112196489323834766 #xz

Infosec Exchange

@briankrebs You mean that people should start auditing open source code?

From the fanatics who stand around and do nothing but screaming that "OSS is more secure than closed source" all day, i thought they already were doing that... </sarcasm>

@briankrebs If XZ is done by a state actor, seems there'd be a high probability there'd be lots more similar attempts.
Brian Krebs on LinkedIn: Some thoughts about attribution in the XZ backdoor, having just wasted so… | 82 comments

Some thoughts about attribution in the XZ backdoor, having just wasted so many hours digging into the details. The email addresses used for a couple of years… | 82 comments on LinkedIn