On 2024-04-01 16:03, Rich wrote:
> Carlos E.R. <robin_listas@es.invalid> wrote:
>> On 2024-03-31 23:37, Richard Kettlewell wrote:
>>> Incredibly good luck that it was spotted before it was too widely
>>> deployed. Or bad luck if you were the originator l-)
>>
>> I saw a post (es.comp.os.linux.redes) of someone in which the sshd
>> had weird peaks of high cpu (40%)
>
> The individual who discovered the backdoor was doing some kind of
> performance testing of PostgreSQL. Because of that they were
> monitoring their system's processe's usage and noticed unusual CPU
> usage from sshd. When they started digging into why sshd was spiking
> CPU usage (because it was messing with their PostgreSQL performance
> monitoring) they discovered the sshd backdoor.

No, I mean that it has been seen in the wild.

When the thread I mentioned appeared, we knew nothing of the
vulnerability, it was March 21st.

--
Cheers, Carlos.

On 3/31/24 16:46, D wrote:
>>
>
> I'm one hundred percent sure state level actors

I'm 100% sure that usenet users without recognizable names that can be
tracked to real people and shout out irrelevant conspiracy theories need
mental health internvention and can't be taken seriously.

Reuvain

On 3/31/24 09:59, Lew Pitcher wrote:
> On Sun, 31 Mar 2024 11:29:08 +0200, D wrote:
>
>> On Sun, 31 Mar 2024, Computer Nerd Kev wrote:
>>
>>> Computer Nerd Kev <not@telling.you.invalid> wrote:
>>>> MarioCCCP <NoliMihiFrangereMentulam@libero.it> wrote:
>>>>>
>>>>> any hints to patch the vulnerability, or will it be
>>>>> addressed soon and be released as security updates ?
>>>>
>>>> The code was targeting Debian, and only reached the Testing version
>>>> of Debian
>>>
>>> And RHEL, and of course all the distros based on those (or at least
>>> those using Systemd).
>>>
>>>
>>
>> How is this exploited? Does it require login/pw?
>
> An "infected" system just needs an SSH server exposed to the internet
> to be exploited. The "bad actor" uses a pre-built key to initiate
> contact and contact doesn't go any further than key validation.
>
> However, the key validation of a bad-actor key causes SSHd to extract
> a payload from the key, and pass that payload to a system(3) call.
>
> So, while the "bad actor" initiator never officially "logs on" to
> the system (no userid, etc), they are afforded sshd privilege-level
> access to the system to run commands.
>
> HTH

Thanks for the rundown Lew.

Reuvain

On 02/04/24 03:34, Carlos E.R. wrote:
> On 2024-04-01 16:03, Rich wrote:
>> Carlos E.R. <robin_listas@es.invalid> wrote:
>>> On 2024-03-31 23:37, Richard Kettlewell wrote:
>>>> Incredibly good luck that it was spotted before it was
>>>> too widely
>>>> deployed. Or bad luck if you were the originator l-)
>>>
>>> I saw a post (es.comp.os.linux.redes) of someone in which
>>> the sshd
>>> had weird peaks of high cpu (40%)
>>
>> The individual who discovered the backdoor was doing some
>> kind of
>> performance testing of PostgreSQL.  Because of that they were
>> monitoring their system's processe's usage and noticed
>> unusual CPU
>> usage from sshd.  When they started digging into why sshd
>> was spiking
>> CPU usage (because it was messing with their PostgreSQL
>> performance
>> monitoring) they discovered the sshd backdoor.
>
> No, I mean that it has been seen in the wild.
>
> When the thread I mentioned appeared, we knew nothing of the
> vulnerability, it was March 21st.
>
apart from all tech details, had the chap that put this
backdoor in the systems been detained yet ?

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

MarioCCCP <NoliMihiFrangereMentulam@libero.it> wrote:
> apart from all tech details, had the chap that put this
> backdoor in the systems been detained yet ?

Last reports have been that no one knows who is behind the Jia Tan name
in real life.

So if that info is not "being withheld" then it is reasonable to
presume that no one has been detained yet.

And, if the attack, given its patience and sophistication, is as some
surmise, the work of state actors in the employ of their government
(i.e. NSA, CIA, Russia, China, North Korea, etc.) then it is unlikely
that anyone will ever be detained nor will anyone be named.

On 06/04/2024 15:40, Rich wrote:
> MarioCCCP <NoliMihiFrangereMentulam@libero.it> wrote:
>> apart from all tech details, had the chap that put this
>> backdoor in the systems been detained yet ?
>
> Last reports have been that no one knows who is behind the Jia Tan name
> in real life.
>
Oh I think someone does..

> So if that info is not "being withheld" then it is reasonable to
> presume that no one has been detained yet.
>
> And, if the attack, given its patience and sophistication, is as some
> surmise, the work of state actors in the employ of their government
> (i.e. NSA, CIA, Russia, China, North Korea, etc.) then it is unlikely
> that anyone will ever be detained nor will anyone be named.

It is at least comforting that if it were, they must not already have
such access, or they would not have bothered.

--
“It is hard to imagine a more stupid decision or more dangerous way of
making decisions than by putting those decisions in the hands of people
who pay no price for being wrong.”

Thomas Sowell

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 06/04/2024 15:40, Rich wrote:
>>
>> And, if the attack, given its patience and sophistication, is as some
>> surmise, the work of state actors in the employ of their government
>> (i.e. NSA, CIA, Russia, China, North Korea, etc.) then it is unlikely
>> that anyone will ever be detained nor will anyone be named.
>
> It is at least comforting that if it were, they must not already have
> such access, or they would not have bothered.

I don't follow that. Hackers, especially state funded hackers with
unlimited resources, will always want more options for getting into
systems. That way when one vulnerability is discovered or doesn't
apply to a particular usage case, another can be selected straight
away.

It's identical to arms development. Nobody ever stops working on
this stuff unless the money gets cut off.

What this does show is that social engineering techniques are
being used very successfully, which means it's quite likely that
similar attacks _are_ going on against other software projects.
Some probably from the same office, if not the same person, as
"Jia Tan".

--
__ __
#_ < |\| |< _#

On 2024-04-01 10:44, Marco Moock wrote:
> On 31.03.2024 um 14:25 Uhr Grant Taylor wrote:
>
>> N.B. there is a big difference in saying that *BSD / Slackware /
>> Gentoo (OpenRC) aren't effected by the topic at hand because they
>> aren't using systemd and saying that they are obviously more secure
>> because they aren't vulnerable to the topic at hand.
>
> They are not affected because the author of the backdoor maybe intended
> to only affect sshd linked to xz or simply forgot that there are
> systems that won't be affected by the back door.
> Linux distributions with systemd are now the vast majority, so maybe
> the author didn't care about some Gentoo or slackware machines.

Maybe they have certain machines in mind for attacking, and they know
what they run

And maybe another actor is working on attacking those others. They do
not want/need a single vulnerability for attacking everything. Less
surface for detection.

> If he liked, he could affect them too because they most likely have
> liblzma installed for other purposes. Although, sshd could be affected,
> but various other packages could be if the author intended to do that.
>

--
Cheers, Carlos.

In article <eplaekx4iu.ln2@Telcontar.valinor>, robin_listas@es.invalid
(Carlos E.R.) wrote:
> On 2024-04-01 10:44, Marco Moock wrote:
> > Linux distributions with systemd are now the vast majority, so
> > maybe the author didn't care about some Gentoo or slackware machines.
>
> Maybe they have certain machines in mind for attacking, and they
> know what they run

The build script part of the attack activated when building .deb or .rpm
packages. If it had not been detected, it would have got into Debian
stable, and then into the vast array of derivatives, notably Ubuntu. It
would also have got into RHEL. That doesn't have direct downstreams any
more, but Rocky, Alma and Oracle follow its example in taking updated
packages, and Amazon Linux takes a fair bit of notice.

The combination of these targets would have compromised a large fraction
of the world's cloud servers. The problem for an intelligence agency
would have been finding the most interesting data, not in getting it.

John

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 06/04/2024 15:40, Rich wrote:
>> MarioCCCP <NoliMihiFrangereMentulam@libero.it> wrote:
>>> apart from all tech details, had the chap that put this
>>> backdoor in the systems been detained yet ?
>>
>> Last reports have been that no one knows who is behind the Jia Tan name
>> in real life.
>>
> Oh I think someone does..

Well, obviously, the individual(s) behind the Jia Tan name know their
own name(s).

If they were, as has been surmised, for pay state actors, then their
bosses also know their names (and also may know what they were up to).

But so far we've not been made privy to those details, so if anyone
outside the ones behind the nick and/or their bosses (if they are
employed by one of the world's governments) know the names, such
details having been revealed to the greater world.

>> So if that info is not "being withheld" then it is reasonable to
>> presume that no one has been detained yet.
>>
>> And, if the attack, given its patience and sophistication, is as some
>> surmise, the work of state actors in the employ of their government
>> (i.e. NSA, CIA, Russia, China, North Korea, etc.) then it is unlikely
>> that anyone will ever be detained nor will anyone be named.
>
> It is at least comforting that if it were, they must not already have
> such access, or they would not have bothered.

There is that. Other than a govt. sponsored entity wanting to insert
plural back doors so that should one be found, they still have another
to utilize. And in this case the backdoor was caught before it was
deployed.

On the other hand, a compression library did also give a good cover for
hiding the actual package. The actual backdoor was hiding inside
purported "broken test archives" for testing the error handling paths
of the compression library. The test data had been "broken" in a
reversible way so that the autoconf changes could "unbreak" the xz
archives and actually extract the payloads.

Other libraries that are not parsers for binary data formats will not
normally have binary test data blobs for their unit tests in their
tests section, so any back door code has fewer hidden 'caves' into
which to hide itself. Note, I'm not saying this means non-crompression
libraries are /safe/ from an attack like this. All I'm saying is there
are fewer hidden corners to stuff things when there are no binary blobs
as part of the build/test process. So the process of hiding the
payload from view becomes much more difficult.