Linux maintainers were infected for 2 years by SSH-dwelling backdoor (Ars Technica)

[Posted May 15, 2024 by corbet]

Ars Technica looks at a a recent report on the Ebury root kit, with a focus on the 2011 compromise of kernel.org, which may have been more extensive than believed at the time.

In 2014, ESET researchers said the 2011 attack likely infected kernel.org servers with a second piece of malware they called Ebury. The malware, the firm said, came in the form of a malicious code library that, when installed, created a backdoor in OpenSSH that provided the attackers with a remote root shell on infected hosts with no valid password required. In a little less than 22 months, starting in August 2011, Ebury spread to 25,000 servers. Besides the four belonging to the Linux Kernel Organization, the infection also touched one or more servers inside hosting facilities and an unnamed domain registrar and web hosting provider.

Linux maintainers were infected for 2 years by SSH-dwelling backdoor(ars technica)

Posted May 16, 2024 3:15 UTC (Thu) by Baughn (subscriber, #124425) [Link] (2 responses)

And now we're 100% positive, of course, that there's no remaining implants and nothing made its way into the kernel.

-kidding, of course. It would take a lot of hubris to be positive of that.

"Implants"

Posted May 16, 2024 3:20 UTC (Thu) by corbet (editor, #1) [Link] (1 responses)

It's actually pretty easy to be sure that nothing was put into the kernel; modifications to the Git repositories would have set off alarms across the net. It seems pretty clear that the people who compromised that machine had no idea of what they had.

"Implants"

Posted May 16, 2024 11:40 UTC (Thu) by yoshi314 (guest, #36190) [Link]

yeah, git has strict(er) integrity validation.

i still recall when there was a cvs mirror of bitkeeper repo and someone injected faulty commits into that one (but the BK repo was unaffected). still, i would assume that someone with ill intent and in-depth knowledge of git might have attempted to sneak something in as well.

Linux maintainers were infected for 2 years by SSH-dwelling backdoor(ars technica)

Posted May 16, 2024 8:04 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (3 responses)

I don't pretend to understand how kernel.org is operated, but I found this sentence a bit surprising:

> Maintainers reneged on a promise to provide an autopsy of the hack, a decision that has limited the public’s understanding of the incident.

It is easy to sit on the sidelines and judge the people who are actually making the hard calls... but when you combine this with the external report's lack of detail (How do they know anything about kernel.org in particular? What is the "data" that they claim to have, how does it pertain to kernel.org, and how do they know that it is authentic?), the whole situation is rather frustrating from an external perspective.

I would like to believe that this is being discussed in one of those closed security mailing lists, and all of the people who need to know these things already do know, but this hack happened in 2011, or possibly as early as 2009 if you believe this new report. The obvious implication is that either 1) somebody is deeply embarrassed by the hack and is continuing to embargo it for purely PR reasons or 2) there is some security problem that still has not been fixed (or maybe can't be fixed), and so we can't talk about it openly. I *sincerely* hope this is a case of some (3) that I haven't thought of, because this is over a decade old, and both (1) and (2) are absolutely terrible for a security incident of such antiquity.

Linux maintainers were infected for 2 years by SSH-dwelling backdoor(ars technica)

Posted May 16, 2024 10:05 UTC (Thu) by ianmcc (subscriber, #88379) [Link] (2 responses)

Or (4) there is a National Security Letter or some other mechanism that prevents disclosure?

Linux maintainers were infected for 2 years by SSH-dwelling backdoor(ars technica)

Posted May 16, 2024 12:31 UTC (Thu) by smoogen (subscriber, #97) [Link] (1 responses)

It doesn't have to be a National Security Letter. Many criminal prosecutions can put seals on releasing information which can have no end date and limit what can be said (including that there is such a seal).

Linux maintainers were infected for 2 years by SSH-dwelling backdoor(ars technica)

Posted May 16, 2024 12:47 UTC (Thu) by mricon (subscriber, #59252) [Link]

This is pretty much all there is to it, not some kind of shadowy "circle of silence." For many years this was an active FBI investigation and then, for another many years, it was an active court case. We were asked to direct any requests for comments to the LF legal department for this reason.

NB: I started at LF several months after the incident -- I do not know any details about it that aren't public knowledge.

Linux maintainers were infected for 2 years by SSH-dwelling backdoor(ars technica)

Posted May 16, 2024 9:35 UTC (Thu) by Sesse (subscriber, #53779) [Link]

Random fact: The malware is called Ebury because I was the first one who wrote anything about it in public, and I was visiting London the weekend that this hit; I lived in Tophams Hotel in Ebury Street, and the name was as good as any. (We found out about it since we started getting bounces indicating that root@ had sent out spam on one of our servers. That's _not_ a normal thing for root to be doing.)

I don't remember anything of the hotel, but I do remember sitting on the floor a lot, using Hex-Rays to figure out what the heck was going on with sshd.

Linux maintainers were infected for 2 years by SSH-dwelling backdoor(ars technica)

Posted May 16, 2024 12:39 UTC (Thu) by butlerm (subscriber, #13312) [Link]

C isn't exactly the most reliable language to build a trusted computing base, Undefined behavior plus optimizer means it is only a matter of time before any late model C compiler formats your hard drive.

PCI DSS and SCO OpenServer

Posted May 16, 2024 23:32 UTC (Thu) by sub2LWN (subscriber, #134200) [Link] (1 responses)

The paper's suggested remediation of payment skimmers is for sites to redirect users to 3rd party payment processors and perform the transaction there. I wonder if that would lead to sites being less conscious of PCI DSS requirements (no need to bother with all the security hubbub: that's up to [Stripe], just set the redirects and forget about it.) Especially for sites which might be held to no other operational standards.

"Besides Linux, Ebury was also installed on approximately 400 FreeBSD servers, about a dozen OpenBSD and SunOS servers, and at least one Mac. Ebury operators also gained access to an SCO OpenServer 5 system, but never deployed Ebury on that machine." Considering the variety of exploited systems, was that SCO system inherently repellent? :-)

PCI DSS and SCO OpenServer

Posted May 17, 2024 8:44 UTC (Fri) by kleptog (subscriber, #1183) [Link]

> The paper's suggested remediation of payment skimmers is for sites to redirect users to 3rd party payment processors and perform the transaction there. I wonder if that would lead to sites being less conscious of PCI DSS requirements (no need to bother with all the security hubbub: that's up to [Stripe], just set the redirects and forget about it.) Especially for sites which might be held to no other operational standards.

Isn't that kind of where we are? At least here in NL where people do not use credit cards on a regular basis because we have other payment methods that do not require a CC. Since the most common payment method (iDEAL) requires redirecting to another site anyway, you may as well redirect to a payment processor that support all sorts of payment methods, including CC. Even CC payments will redirect to another site anyway for the 2FA.

It's only on international sites that I see building CC processing into the site because they simply don't accept anything else. And then of course you need to worry about PCI-DSS requirements. From my point of view managing a small site, I think it's great that I can accept payments (even direct debits) without having to worry about any kind of PCI-DSS requirements.