Stealthy Linux backdoor malware spotted after three years of minding your business

Chinese security outfit Qihoo 360 Netlab on Wednesday said it has identified Linux backdoor malware that has remained undetected for a number of years. The firm said its bot monitoring system spotted on March 25 a suspicious ELF program that interacted with four command-and-control (C2) domains over the TCP HTTPS port 443 even …

[David 132]

Disguising it as Systemd is cunning

How many admins, upon seeing a process (apparently) related to systemd sending data out on a well-known port, would assume it was malware?

I suspect that in many cases, the response would instead be a shrug and a resigned muttering of "so systemd has now extended its tentacles over TLS too? *sigh*"

[Anonymous Coward]

Re: Disguising it as Systemd is cunning

I suspect that many admins don't dig enough to shrug. Many just rely on their malware scanners to tell them there's a problem.

Also, given the sophistication, the dormancy, the targeting of China, and the Ukraine destination, I wonder if this was an NSA or Five Eyes operation.

[JakeMS]

Re: Disguising it as Systemd is cunning

To be fair. you really should have an active and carefully configured IDS like Tripwire (or similar), with both its binaries and databases on read-only media to prevent DB/binary tampering.

Thus, if any binaries suddenly change on the system, you can easily detect it.

[Anonymous Coward]

Re: Disguising it as Systemd is cunning

The read-only medium for tripwire does not help you much if you can't trust that the (potentially compromised) system will actually execute the real tripwire ...

A simple bash alias could redirect your call to tripwire to a program that simply repeats the last report (or makes other arbitrary changes to the output).

Setting up a system like tripwire effectively would mean powering down the VM, mounting the disk in a different OS and then inspecting it from there.

Of course the question remains how you'd verify that a given change was legitimate or malicious.

Any OS update will legitimately change more binaries on the system than you'll want to manually verify and if you just waive them all in tripwire then that's the perfect time to persist malware to the disk.

Tripwires (physical or virtual) only work when the attacker does not expect or find them. Otherwise it's not a lot of work to simply step over or bypass them.

[DuncanLarge]

Re: Disguising it as Systemd is cunning

> A simple bash alias could redirect your call to tripwire

In that case always use the full path fr such binaries

[steelpillow]

Re: Disguising it as Systemd is cunning

A reason to move to Devuan, then

[Zolko]

Re: Disguising it as Systemd is cunning

"A reason to move to Devuan"

or MX-Linux. it's also Debian based, and also systemd free, but much more userfriendly, similar to Mint. Defaults to KDE/Plasma. I was not able to use Devuan because of the old kernel and lack of non-free drivers, but MX Linux was a breeze to setup, I recommend.

[sev.monster]

Re: Disguising it as Systemd is cunning

Alpine Linux represent!

[Anonymous Coward]

Re: Disguising it as Systemd is cunning

I've seen malware that came in through the Exchange bugs in March that hid itself in the System32 directory with the name hosts.dll.

Again, in that location, with that name, it sounds legitimate, at first glance.

[Myself]

The lack of detection is the scandal here.

So what happens to files submitted to VT, then? I thought they were made available for AV researchers to study.

This had been submitted several times over the years. Did nobody find it suspicious? Or, were they told to keep it off their detection lists?

[Anonymous Coward]

@Myself - Re: The lack of detection is the scandal here.

Look for the Chinese security outfit being banned from North America and Europe on the grounds of cooperating with Chinese government and/or military. Where have I seen this before ? Oh yes, Kaspersky.

[claimed]

What backdoor?

If its not an exploit, how is it getting executed? Details please

:)

[Doctor Syntax]

Re: What backdoor?

The linked article has the details. It installls the appropriate config files for systemd to start it up like any other service.

[bombastic bob]

Re: What backdoor?

so those of us who refuse to install Linux with systemd on it have dodged a bullet, then?

[Robert Carnegie]

Re: What backdoor?

You will have to install the malware yourself with cron :-)

[sev.monster]

Re: What backdoor?

The way I look at it, the malware isn't the only bullet dodged...

[claimed]

Re: What backdoor?

So firstly my request was for El Reg to provide the details, they tend to summarise the technical information brilliantly.

Secondly, the linked blog - which I think is what you're referring to - only describes how RJ achieves persistence once its running.

So, if you can run code on a machine, you can often compromise it - yep, pretty well known. My question is, how does it get to execute if its not an exploit, so how does it create those files?

I think the answer is that it doesn't? It's therefore a payload that has to be used in conjunction with a runtime exploit?

An interesting payload, sure, but not sure it warrants the systemd bashing as if you're already running as root then it doesn't matter if the machine has systemd anyway, you're trashed.

[Anonymous Coward]

Re: Pretty stupid port number

?

It doesn't listen on 443, it communicates with the command and control on 443. So would not affect any services on the system.

So you would see a process communicating with a remote server on 443, with an outbound port being random.

[bombastic bob]

Re: Pretty stupid port number

it communicates with the command and control on 443. So would not affect any services on the system.

Until you get that "Hey I.T. why is the web server only listening to http requests? i thought you had it set up for https?" call...

[Unoriginal Handle]

Re: Pretty stupid port number

You wouldn't. The C2C server is listening on port 443, but *not* using SSL/TLS to encrypt services.

The backdoored machine may be running a web server but it's talking *outbound*. Destination port = 443, source port on the victim something completely different.

[sreynolds]

What a supsirse.

I thought that systemd was the malware, but now I realize that this was just something on the all encompasising systemd roadmap. Q2019 - become pre-eminint linux malware hosting platform.

[oiseau]

Re: What a surprise.

...become pre-eminent linux malware hosting platform.

Indeed ...

systemd is nothing but a developer endorsed registry-class virus set up inside Linux distributions.

From a post here at ElReg, May 2017:

"Systemd also has its dirty fingers into other parts of the system. As a replacement for sysvinit is is supposed to be an init system, but because its scope goes far beyond the initialization phase (and it doesn't let you take the good without the bad) it has become a dependency for many userspace programs that should never have any reason to interact with the init system at all, making it harder to use those programs on a non-systemd system."

It is the ideal vector for all sorts of nastry stuff.

This new discovery is just a trial run.

The next one or the one after that will probably not be noticed.

Want a safe system where you can audit everything properly?

Get rid of this systemd crap ASAP.

O.

[DuncanLarge]

Re: What a supsirse.

Yesterday I tried to reboot my system and systemd decided to take 3 mins to do so. First of all it was waiting on a job for 1:30, well I thought ok systemd, wait then kill it, then once the 1:30 timer was over it added another 1:30 to it.

I knwo what caused the issue, a filesystem that wouldnt unmount, due to a kernel bug that I triggered when I was testing something but I remember the days when if the system was told to reboot, it rebooted.

[DS999]

Yet another reason why systemd sucks

Having a kitchen sink process that has reason to be sending/receiving all sorts of network traffic makes it perfect for disguising illegitimate traffic. If it was broken up into a bunch of small programs that each did only one thing, it is easy for a log analyzer to know what they are "supposed" to be doing and notice when they start doing something extra. No one will ever notice systemd doing something extra, because it is designed to do everything.

[bombastic bob]

Re: Yet another reason why systemd sucks

No one will ever notice systemd doing something extra, because it is designed to do everything.

THAT deserves to be written in BOLD TYPE

similarly, how Windows servers are set up, when everything runs as 'rundll' - digging further IS possible, but you have to jump through a few hoops with the system monitor.

and yeah, I.T. people have SO much extra time to use extra steps to root around looking for stuff...

[Anonymous Coward]

Re: Yet another reason why systemd sucks

I don't see how a systemd file is any different to an initrc file in that respect, though. Both bundle hundreds of services that noone is going to look through.

[sev.monster]

Re: Yet another reason why systemd sucks

systemd unit files are just configurations that tell how systemd should run a script or binary. Traditional rc scripts are actual scripts that often handle both the configuration and the functionality. Understanding rc scripts only require understanding traditional Bourne shell, while understanding systemd requires more intricate knowledge to even begin to know what the fuck is going on. I still can't read unit files and I have no desire to learn until I am forced against my will to administrate a systemd-powered server.

Anyway...

You're telling me you don't read your service scripts? I do.

And if you for some reason have "hundreds" of services running under systemd or whatever else, in my opinion, you're doing something wrong...

[Version 1.0]

Who wrote it?

If the Chinese are releasing the details then it was almost certainly written elsewhere, could this be a no such agency access application?

[Julz]

Re: Who wrote it?

Indeed. I would suspect our Israeli friends as they have been messing around with Linux for years in their spat with our Iranian friends.

[sreynolds]

Re: Who wrote it?

Last time I checked it was a German ruse - oh wait, are we talking about the malware additions that made systemd more reliable and useful here?

[sitta_europea]

I'm always suspicious of anything that calls itself systemd.

[Pigeon]

ditto

I use Devuan, but for a while was alerted when systemd-ish files appeared during package installation. Luckily they are the dried exoskeletons of systemd integration. This article has boosted my wavering resolve to stay away.

[TimMaher]

Alex Turing?

Really?

Some people have all the luck.

[FuzzyTheBear]

All the explanations ..

Well .. ok .. so it's possible and found.. but where is it ? They do not say or tell if they found anything in modern day linux distros .. or even how this can be installed on a machine or present in a linux distribution .. how is it propagating ? It leaves too many questions to be truly helpfull.

[vincent himpe]

wait

As linux users (and especially the admins of servers) , aren't you supposed to read and understand the entire sourcecode to your running install ? Isn't that why we have open source in the first place ? So you can inspect it before running.

[Henry Wertz 1]

systemd is the devil

"As linux users (and especially the admins of servers) , aren't you supposed to read and understand the entire sourcecode to your running install ? Isn't that why we have open source in the first place ? So you can inspect it before running."

Yes, and this is a reason why systemd is the devil. Replace readable and understandable scripts with poorly-documented opaque binary blobs* that tentacle their way through the system, subsuming more and more system functionality.

*Obviously systemd does have source code, but compared to just having shell scripts booting the system it's still pretty opaque.

[DJ]

Isn't the that the point

of open source code?

Yes, it's complicated code and no one person understands it all, but what does this say about open source code for something as prominent as Linux?

[Anonymous Coward]

Re: Isn't the that the point

READ the systemd source code!!!

And risk having it take over what's left of my mind?

NO F***** way.

[sreynolds]

Re: Isn't the that the point

Meh the source isn't that bad. Sometime you have to look and wonder WTF was He thinking. Like some mounting shit that means you need to have certain mounts in a certain place. That plays really well with embedded systems.

[ghp]

Here's wondering if they'll ever detect the trojan inside pulseaudio.

[Anonymous Coward]

Whining about systemd...

It doesn't matter if you're using systemd or something else, something is running loads of processes on the system.

However this thing gets installed is unclear, it could easily adapt to different names, and using soundsalike system process names for malware pieces is hardly new.

[nijam]

Oh, this is so tempting, can I refrain? No, evidently not:

> to make the malicious code less likely to be noticed...

... by disguising it as a different piece of malicious code.

[mmather]

So how can you detect whether your Linux system is infected or not?

Interesting article, but I am more interested in how to detect and remove malware/viruses in Linux?

[Paul Crawford]

Re: So how can you detect whether your Linux system is infected or not?

First get rid of systemd

Then you can worry about any other malware...