Live data from Hacker News

XZ Backdoor: Times, damned times, and scams

rheaeve.substack.com

181–190 of 193 posts

Re: XZ Backdoor: Times, damned times, and scams

#181
post #45
post #8

Earlier quoted context omitted.

They probably have/will, though we are unlikely to find out what they get unless they manage to arrest/charge/try him. Jia Tan probably used a vpn though - we know that they did for accessing IRC (source: https://boehs.org/node/everything-i-know-about-the-xz-backdo... )

Most (but not all ) VPN providers keep logs and payment info that are subpoenable. You could use something like Mulvad with Lightning Network payments, but I am not sure that even that is fully anonymous. The Witopia VPN that he used for IRC [1] is US based: https://www.personalvpn.com/contact-us/ and they don't mention neither LN payments nor not keeping logs. 1. "~jiatan@185.128.24.163" https://boehs.org/node/every…

If he used a well known vpn, he probably used a fake id and stolen credit card to pay it.

Re: XZ Backdoor: Times, damned times, and scams

#182
post #63
post #54

Earlier quoted context omitted.

Not sure why you’re downvoted. When you think of state actors, Israel comes very high (stuxnet etc), as well as the usual US/Russia/China/NK groups. Unit 8200 in the IDF especially have a very notable reputation. That’s not to say other counties don’t have capabilities (and this doesn’t look like you need the resources of a group like say the NSA or GCHQ for this particular attack - indeed it could just be a single l…

If the only think I knew was UTC+2 (and I don't even think I know that, I'm really cautious with assumptions about what mistakes that kind of people plausibly make), Israel would be very high on the list. But FWIW, 25Dec is a Catholic holiday, and even though it's mentioned on Wikipedia page about Israel holidays, I'm not sure how official that is. I mean, it doesn't seems to be, like, a real Israeli holiday.

December 25 and and Jan 1 are regular work days in Israel, with the legal option that someone can't be refused to take those days off, but have it deducted from their accrued vacation time (there are other days that one can't be refused to take off, but if no available vacation days, have to be offered leave without pay for those days).

i.e. most Israelis work those days.

Re: XZ Backdoor: Times, damned times, and scams

#183

Earlier quoted context omitted.

Postal mail has non-zero metadata, e.g. origin can be traced at least to departure postal code.

There's... actually very little that stops you from sending mail from a non-local postal code. I've occasionally sent packages postmarked as being from one zipcode from another; as long as it's in the same region, much of the postal processing doesn't care so much. There's also remailers and forwarders.

How do you do that? Walk up to the postal counter, ask them to postmark it, then ask for it back, drive to another post office and slip it in their outgoing pile?

Re: XZ Backdoor: Times, damned times, and scams

#184
post #26
post #18

Earlier quoted context omitted.

> A bit random, but has there been speculation on why this seemed to only target rpm/deb packaging? I don't think much speculation is needed. RPM and deb catches every Enterprise Linux distribution, to the best of my knowledge. rpm catches Red Hat and all derivatives like CentOS, Alma Linux etc, as well as SuSE, Amazon Linux, and even Microsoft's Mariner Linux (now renamed Azure Linux). deb catches Debian and Ubuntu.…

Sure, but why go to the effort to exclude others? Did they think it would help avoid detection on systems that they didn't care to backdoor?

I don't think it was specific effort to exclude others, they took efforts to ensure it happened at packaging time, to reduce chances of detection. So eg other xz devs didn't notice it when compiling it, and so on.

Re: XZ Backdoor: Times, damned times, and scams

#185

If you don't have your BIOS clock set to UTC and your OS is expecting it to be, you can get strange behavior like this. If they were switching between Windows and Linux, that could explain some of the offsets.

You can fix that in Windows: https://wiki.archlinux.org/title/System_time#UTC_in_Microsof...>

Re: XZ Backdoor: Times, damned times, and scams

#186

Earlier quoted context omitted.

> Never, ever install bleeding-edge software in production, for any reason. But for any X which is mainstream today someone was always the first of X. And even then being the second or third is still cutting edge. For a certain kind of company it makes sense to play this way, but if it were everyone then we'd have a tragedy.

That's why you run X in your sandbox/QA/testing/whatever-you-call-it environment, safe from the prying eyes of the public internet and the private data of users. Once it's all good there, and the community has come to a consensus about it being safe and ready-for-release, that's when you can put it wherever you want. 99.9% of releases for packages like this are boring bugfixes and stuff, not earth-shattering new feat…

[deleted]

Re: XZ Backdoor: Times, damned times, and scams

#187
post #63

Earlier quoted context omitted.

If the only think I knew was UTC+2 (and I don't even think I know that, I'm really cautious with assumptions about what mistakes that kind of people plausibly make), Israel would be very high on the list. But FWIW, 25Dec is a Catholic holiday, and even though it's mentioned on Wikipedia page about Israel holidays, I'm not sure how official that is. I mean, it doesn't seems to be, like, a real Israeli holiday.

I think no commits on December 25 is not enough to go by. He's been active for about 2 years, so that's what, 1-2 Christmases? I assume he doesn't commit literally every day. So it could be a coincidence that he didn't on those particular 1-2 days. Also, in many Orthodox Christian majority countries including those in UTC+2 they don't celebrate on 12/25. But doesn't Israel also not follow a typical work week? Eg. No…

It's not just that there's only two Christmases. It's that Christmas fell on Sunday in 2022 and Monday in 2023, and the article already established the attacker mainly worked Tuesday-Friday. The note about the attacker never working on New Year has the same problem (New Year's Eve/Day always lines up with Christmas Eve/Day, so would not have hit the Thu-Fri window either).

Re: XZ Backdoor: Times, damned times, and scams

#188
post #161
post #92

Earlier quoted context omitted.

From my point of view, from what we know today, it is bigger than Stuxnet because: Stuxnet : aimed to delay one nuclear facility that was still being built SSH pre-auth RCE : root access to most servers on the planet, impacting everyone from hobbyist self-hosters (that's me) to large businesses (of every type imaginable) to probably even some of the security agencies around the world. With SSH's track record, a lot o…

> SSH pre-auth RCE: root access to most servers on the planet, impacting everyone from hobbyist self-hosters (that's me) to large businesses (of every type imaginable) to probably even some of the security agencies around the world. No, absolutely not; that didn't actually happen. Most servers on the planet that are running x86_64 Linux are probably not running a rolling-release distro based on .deb or .rpm. Rolling-…

> that didn't actually happen

See modulating factors at the bottom. In this case, it didn't because it was caught before making it into a stable release, but only due to sheer luck. The story is still so much bigger than Stuxnet to me because its aim was an actually tangible impact on millions of people's lives

> Now this could have been bigger than Stuxnet, if the backdoor had remained secret for -- and I think I'm being generous here -- another year or so.

Agreed on that! (To be clear, I still think it's already bigger, not because of the impact it concretely had but because I perceive it to having been very close; but I can understand this/your point of view very well)

Re: XZ Backdoor: Times, damned times, and scams

#189
post #178

Maybe a consideration: this isn't necessarily a nation state. It could literally just be one or more individuals trying to set up some sort of crypto heist. At this point we need some sort of new adage to the effect of "never attribute to nation states what can be attributed to crypto"

The attackers would have to know the distributions used by the company they are targeting, that connections are open to the internet, that the company won't change their setup over the course of several years. Everything you are saying is so far out of the realm of possibility that it makes me wonder if you follow this stuff at all. If you had 2+ years of spare time, and these type of skills, the attacker would be fa…

> If you had 2+ years of spare time, and these type of skills, the attacker would be far better off just trying to get a job inside the organization they are targeting.

Who says they don't? :-)

Re: XZ Backdoor: Times, damned times, and scams

#190
post #45

Earlier quoted context omitted.

Most (but not all ) VPN providers keep logs and payment info that are subpoenable. You could use something like Mulvad with Lightning Network payments, but I am not sure that even that is fully anonymous. The Witopia VPN that he used for IRC [1] is US based: https://www.personalvpn.com/contact-us/ and they don't mention neither LN payments nor not keeping logs. 1. "~jiatan@185.128.24.163" https://boehs.org/node/every…

If he used a well known vpn, he probably used a fake id and stolen credit card to pay it.

But well-known VPNs mostly keep IP logs - I know from experience; in my company the FBI found a DDoSer this way.
Post reply on HN