Symbiote Linux malware spotted – and infections are 'very hard to detect'

Intezer security researcher Joakim Kennedy and the BlackBerry Threat Research and Intelligence Team have analyzed an unusual piece of Linux malware they say is unlike most seen before - it isn't a standalone executable file. Dubbed Symbiote, the badware instead hijacks the environment variable (LD_PRELOAD) the dynamic linker …

[Flocke Kroes]

Detection is trivial

Create a process with one of the hidden names and look for it with ps. If you do not find it, you are infected.

[Frumious Bandersnatch]

Re: Detection is trivial

Even simpler: `touch apache2start; ls apache2start && echo ok`

[Anonymous Coward]

Re: Detection is trivial

.and if you do find it, you still may be.

[Anonymous Coward]

The research doesn't mention how the initial infection occurs

Too bad, it's the only part that I'm interested in. Especially since you can't detect it easily.

[Mike 137]

Re: The research doesn't mention how the initial infection occurs

As usual. Initial infection vector seems to be the least interesting thing to almost all these hot shot researchers, but it's probably the most important issue, as the population of initial vectors is almost certainly vastly smaller than the population of malware itself, so it would in principle be an easier problem to address.

[Anonymous Coward]

Re: The research doesn't mention how the initial infection occurs

They also didn't mention if LD_PRELOAD could be patched in order to block this. Or, for that matter, if it's already been patched and this only affects unpatched systems.

[Steve Graham]

Re: The research doesn't mention how the initial infection occurs

Yes, I read both the report and the Mitre one referenced in it and came up empty.

I actually use LD_PRELOAD in GUI sessions to disable client side decorations in Gnome applications (a bit of UI idiocy). I'd like to know how the malware sets it in a process, but the researchers aren't telling.

[bombastic bob]

Re: The research doesn't mention how the initial infection occurs

the descriptions in the article makes me think it starts out as a compromised process running as root. If true it can muck with the environment during the login process. To truly hide a process you need root access, otherwise you can look at /proc to get the correct info., i.e. /proc/*/cmdline for process ID '*'

[sitta_europea]

Remote mount?

[MrDamage]

Only if you don't check the couch before sitting down.

[Anonymous Coward]

Maybe…. But remote mounts are usually noexec.

[Anonymous Coward]

Attacks LD_PRELOAD

There's always a case for static linked binaries when looking for this kind of trouble.

[DS999]

Re: Attacks LD_PRELOAD

That's what I was going to suggest, though I wonder since Linux has such a strong bias towards dynamic linking if it might be possible to force even a statically linked binary to load a dynamic object.

[Flocke Kroes]

Re: Attacks LD_PRELOAD

Simple answer: Static linking creates a different type of file that the dynamic linker does not understand:

Create hello_world.c and compile it with: "gcc -o hello_world hello_world.c" then run: "file hello_world" and you get output like:

hello_world: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=8ff789376a00beebceecf9d11428eed4fd02622b, for GNU/Linux 3.2.0, not stripped

Now compile it again with: "gcc -o static_world -static hello_world.c" and run "file static_world":

static_world: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=93e4e42fed15a9819b3df716d95c8f60e4bdc796, for GNU/Linux 3.2.0, not stripped

Note that hello_world has an interpreter (the dynamic linker) but static world does not. hello_world can be executed via its interpreter: "/lib64/ld-linux-x86-64.so.2 ./hello_world" and it runs fine. Try "/lib64/ld-linux-x86-64.so.2 ./static_world". I got a Segmentation fault - the dynamic linker (which is the thing that uses LD_PRELOAD) does not understand static executables at all and promptly dies of confusion.

It goes deeper: even if the dynamic linker did not crash and did load the libraries from LD_PRELOAD for a static executable, the dynamic libraries would have their constructors executed but would not be able to redirect calls inside the static executable. Static calls know where the required functions are and go straight there. Dynamic calls read a function pointer variable that initially point to a function in the dynamic linker. The dynamic linker looks up the name in the loaded shared libraries (and loads more if the name is not found) then updates the function pointer to point at the shared library function then calls it.

That is a lot of complexity but hello world is about 16kB and static_world is 780kB (using puts, it would be worse with printf). If every executable is static you are going to use a lot of memory and really thrash the caches.

Complicated answer: Some functionality is implemented by dynamic libraries unless you pay close attention. The obvious example is the name service switch in the C library. If you did not do anything clever, user data is stored in /etc/password in a simple human readable file. You could store it in a database and the C library would provide functions that hide the difference to programs by loading a different shared library.

[Anonymous Coward]

Re: Attacks LD_PRELOAD

I don’t think static binaries disable ld_preload (you have to use a format other than ELF)

May be wrong, of course…

[sreynolds]

But if we know t he DNS addresses we can kill it?

Sorry how does the DNS request work? Does it ask for a particular record that isn't cached and has to go to the actual DNS servers? I mean you know the SOA so you know where the DNS is going so why is this such a hard thing to take down?

I mean there is no way a bank would allow a server to go do recursive look up, or would it?

[david 12]

As the OpenVPN people explained to me when I objected to their use of environment variables to load executables: you have to be an authorized user to change environment variables, so it doesn't matter.

[Brewster's Angle Grinder]

In what sense? I can set the environment variables in a call to execve(2). If that's for a setuid executable then I've given a higher priority executable an environment I control.

The linker protects against that for its variables and for certain other variables. But if you're using variables the linker doesn't know about, it's a risk.

[Anonymous Coward]

I think this is mostly a program hiding itself after infection. Obviously you are already compromised if things are fiddling with your env variables.

I thought you could only preload executable files on disk, so I am not sure where the fileless part of this comes in…

Also preload is 1970s attack vector.

[Dwarf]

I wonder what happens if you change the LD_PRELOAD env variable back to empty or something sane on an infected machine ?

[the.spike]

It never ceases to amaze me how clever some of these virus writing chaps are..