Symbiote: A New, Nearly-Impossible-to-Detect Linux Threat (blackberry.com) 43
Ars Technica reports:
Researchers have unearthed a discovery that doesn't occur all that often in the realm of malware: a mature, never-before-seen Linux backdoor that uses novel evasion techniques to conceal its presence on infected servers, in some cases even with a forensic investigation.
On Thursday, researchers and the BlackBerry Threat Research & Intelligence Team said that the previously undetected backdoor combines high levels of access with the ability to scrub any sign of infection from the file system, system processes, and network traffic. Dubbed Symbiote, it targets financial institutions in Brazil and was first detected in November.
Researchers for Intezer and BlackBerry wrote:
"What makes Symbiote different from other Linux malware that we usually come across, is that it needs to infect other running processes to inflict damage on infected machines. Instead of being a standalone executable file that is run to infect a machine, it is a shared object (SO) library that is loaded into all running processes using LD_PRELOAD (T1574.006), and parasitically infects the machine. Once it has infected all the running processes, it provides the threat actor with rootkit functionality, the ability to harvest credentials, and remote access capability...."
So far, there's no evidence of infections in the wild, only malware samples found online. It's unlikely this malware is widely active at the moment, but with stealth this robust, how can we be sure?
"When hooked functions are called, the malware first dynamically loads libc and calls the original function..." according to Blackberry's blog post. "If the calling application is trying to access a file or folder under /proc, the malware scrubs the output from process names that are on its list.... If the calling application is not trying to access something under /proc, the malware instead scrubs the result from a file list....
"Symbiote also has functionality to hide network activity on the infected machine."
On Thursday, researchers and the BlackBerry Threat Research & Intelligence Team said that the previously undetected backdoor combines high levels of access with the ability to scrub any sign of infection from the file system, system processes, and network traffic. Dubbed Symbiote, it targets financial institutions in Brazil and was first detected in November.
Researchers for Intezer and BlackBerry wrote:
"What makes Symbiote different from other Linux malware that we usually come across, is that it needs to infect other running processes to inflict damage on infected machines. Instead of being a standalone executable file that is run to infect a machine, it is a shared object (SO) library that is loaded into all running processes using LD_PRELOAD (T1574.006), and parasitically infects the machine. Once it has infected all the running processes, it provides the threat actor with rootkit functionality, the ability to harvest credentials, and remote access capability...."
So far, there's no evidence of infections in the wild, only malware samples found online. It's unlikely this malware is widely active at the moment, but with stealth this robust, how can we be sure?
"When hooked functions are called, the malware first dynamically loads libc and calls the original function..." according to Blackberry's blog post. "If the calling application is trying to access a file or folder under /proc, the malware scrubs the output from process names that are on its list.... If the calling application is not trying to access something under /proc, the malware instead scrubs the result from a file list....
"Symbiote also has functionality to hide network activity on the infected machine."
Linux, what a joke. (Score:4, Funny)
We all TOLD YOU this would happen. This is what happens when you use a UNIX wannabe cobbled together by weekend hobbyists, instead of using an industrial strength OS like Windows or OSX that is rigorously crafted by professional coders.
Re: (Score:3, Funny)
Were you cobbled together on a weekend too, or was your mom a professional?
Re: (Score:2)
No wonder my parents named me "Cobble". And my sister "Broken Rubber".
And that shared object is stealthy how...? (Score:5, Interesting)
Sounds way less "stealthy" than those "trust zone" or UEFI based viruses that exploit CPU's/BIOS's malware-helping features.
Re: And that shared object is stealthy how...? (Score:2)
Iâ(TM)m not even mad, thatâ(TM)s dedication to SEO
Re: (Score:2)
I turned that lengthy post every which-way, but I still don't see the swastika.
What's the secret?
Re:And that shared object is stealthy how...? (Score:5, Insightful)
Wish I had mod points, you'd get them all.
I always see this on these, "OMG LInux malware" news items. Some article gets posted about some new malware variant which targets Linux-based servers/OS's and then, buried somewhere deep in the article, you finally see a part of the story which seemingly never makes the headline: for the malware to be effective some epic stupidity has to occur (root login, port 22 open, or, in this case, certain config variables set where they can easily be spotted even before compilation). I should do some investigation and see just who sponsored the article...
Re: (Score:3)
Re: And that shared object is stealthy how...? (Score:2)
Depends on just how sophisticated it really is. In theory, when you're running in ring 0 space, you have the power to manipulate all outputs. Though theoretically you may not even need that, see the Ken Thompson hack.
This isn't a Linux specific thing. Though it is harder to pull this off in windows because most windows systems will be using code signing.
Re:And that shared object is stealthy how...? (Score:5, Interesting)
^THIS!
Furthermore, LD_PRELOAD mischief is not exactly new. It's why (at least once upon a time) a number of the admin tools were always static linked and kept in /sbin.
It's also part of the reason Alt-SysReq on the console can be used to get a dump of running processes direct from the kernel.
Failing all of that, booting a rescue disk (or RO image) can be used to examine the system free of the PRELOAD.
Re: (Score:3)
Indeed. You know, like a competent forensic investigation would do.
Re: And that shared object is stealthy how...? (Score:3)
The first step is knowing whether something has actually gone wrong. If you don't, then there never will be an investigation.
Re: (Score:2)
Yes, so? That is why you have sensors placed.
Re: (Score:2)
Re: (Score:2)
That is related. I would consider a malicious PRELOAD to be a horked library problem.
Re: (Score:2)
Re: (Score:2)
Well, the attack will be glaringly obvious when you look at a forensic image.
Re: (Score:2)
Historically, executables in /bin and /sbin were statically linked -- for just this security reason. And he destroyed that.
Whew! We can trust the reporting ... (Score:3)
In the author picture at the bottom of the Arstechnica article (TFAA), the guy is, literally, wearing a white hat. #SledgehammerSymbolism :-)
Re: (Score:2)
Oh yeah, cowboys are the best.
It's not a cowboy hat ... I'd have let that slide.
It has to get root first... (Score:4, Interesting)
Yes, this thing is new and improved... but it still has to get root access in order to hook at the kernel level. It also has to get past AppArmor or SELinux which would stop such an item cold, even if it did manage to get UID 0. With the logs generated, admins would know something is up, when something like Apache starts spewing into syslog about a bunch of attempts to hook in at the kernel level.
If it gets root, that is bad... but we have had decades of rootkits, and Linux is pretty good at handling privilege escalation attacks.
However, this attack, in combination with a rowhammer attack, or something on the CPU level (Spectre/Meltdown) can be devastating, because it could easily be injected by a number of means, even a webpage. So, it is a great attack for keeping gained territory, and having a bastion for future attacks... or just quietly inserting a shim which auto-decrypts files, so ransomware can quietly encrypt files without the user knowing for a few months (which will ensure backups are unusable), then at a certain date, drop the keys and present the demand for cash.
This isn’t new (Score:4, Interesting)
Stuff like this has been around for decades. I remember dealing with a kit like this on Solaris decades ago. Not only did that bugger scrub itself from process listings etc. but it also replaced some of the static binaries in /sbin.
So why is a kit like this news? Seems kinda run of the mill to me.
Re: (Score:2)
Where are the mod points when you need them?
What, LD_PRELOAD again? This technique goes back many decades. Its one of the oldest black-hat tricks in the book, and its so easy to do. But its what happens afterward hooking a service that is so important. There is no lack of rootkits out there that play these games so this article is very anti-climatic to the older geeks out there that have been around the block a time or two.
Wake me when it starts injecting trampolines in the dynamic portions of the kernel
Re: (Score:2)
Stuff like this has been around for decades. I remember dealing with a kit like this on Solaris decades ago. Not only did that bugger scrub itself from process listings etc. but it also replaced some of the static binaries in /sbin.
So why is a kit like this news? Seems kinda run of the mill to me.
Indeed. The real story here is that "forensic investigators" seem to be incompetent today.
Somebody is about to explain (Score:1)
How is it delivered? (Score:4, Interesting)
Sneakernet and USB? You have received an e-card from a total stranger for no apparent reason? You got it from a toilet seat while surfing warez.com?
This may be an evasive piece of malware, but I'm pretty sure that this is a standard expectation from malware these days. As good as this software may be at obfuscating its presence I suspect tripwire will detect it readily enough (if the local SysAdmin has any security awareness whatsoever). Hooking into something like lib.c should ring alarm bells all over the place.
If deployment software such as Puppet or Chef are in use, file hashes won't match and shared libraries will be overwritten with (presumably known-good, clean, static) versions - probably very quickly, and once more, there will be a flashing neon sign blinking out "Problem here".
It'd be nice to know the propagation mechanism. If it were floating around in public code repositories, it would be a lot more widespread than it is, so I don't think I need to worry about apt-upgrade or yum update just yet. Most of the end-users I've ever dealt with think UNIX are for guarding harems. Inside job? Best way to hide exploits, have someone on the inside making sure they stay hidden.
Re: (Score:2)
I'd be much more impressed by your post if it didn't refer to a package manager (yum) that was replaced by dnf seven years ago. If you're going to pontificate about Linux, you'd better keep yourself up-to-date.
Re: (Score:1)
Re: (Score:2)
Who contributed the code? (Score:3)
Re: (Score:2)
The code was probably manually installed. A sysadmin (or higher) probably manually redacted the logs after initial installation from USB drive. After that, it was just a matter of maintaining the exploit, updating it with tools from the modern malware tool set, custom tailored to the security of the carefully-managed victim set.
Just guessing - but zero "in the wild" instances is sort of telling . . .
Looks like there are amateurs at work (Score:4, Insightful)
A _competent_ forensic analysis does of course look at all shared libraries on the system and looks at which ones get loaded. Yes, if you load it into _everything_ you can prevent tools already on the system form seeing it. But what abysmally incompetent "forensic" investigator does it like that? What you do is look at an image from outside. There you will find the LD_PRELOAD setting and see the dynamic library. And if you really need to run something in the system itself (obviously on a copy, never the life system) you will use something that comes with its own libraries or, better, is statically compiled. Also, do this with your own kernel and make sure the kernel is not compromised.
As to network activity, of course you look for that _outside_ of the machine using a network tap. Do I have to tell these people the very basics???
This really is a story about what incompetents call themselves "forensic investigators" these days, not about a particular insidious malware.
Re:Looks like there are amateurs at work (Score:5, Interesting)
For this to be worth a shit, it needs to be set as root (Linux dynamic linker will not LD_PRELOAD for an escalated process) and it needs to be done for each and every process spawned by your init. Contained as any user-account is pointless.
Otherwise, it's rather trivial to detect.
I'm less interested in abuse of LD_PRELOAD, as I am having a discussion about how the fuck the environment variable was set to begin with, and by pid 1.
I mean, if you can arbitrarily execute code that early in the boot process, who the fuck cares what trickery you do to hide yourself? Your shit is fucking pwned, period.
Anyway, the forensics guys aren't incompetent. They're just focusing on an already-infected machine, and how to find out that it is.
I spent some time and earned some e-fame in my reverse engineering exploits, and these guys seem competent in that domain, which is a domain that a fraction of a hundredth of a percent of the human population is skilled in.
Re: (Score:2)
I should clarify: _These_ forensics guys (if there are even any in the team that wrote this) are incompetent.
Re: (Score:2)
Re: (Score:2)
What you do is look at an image from outside. There you will find the LD_PRELOAD setting and see the dynamic library. And if you really need to run something in the system itself (obviously on a copy, never the life system) you will use something that comes with its own libraries or, better, is statically compiled. Also, do this with your own kernel and make sure the kernel is not compromised.
Your analysis method assumes three things:
1. You have the ability to access the cleartext of the code in question directly.
2. The code in memory on the target device is not under suspicion.
3. Any potential threat / "unauthorized" code will show up on disk.
Number one can fail with most modern devices. A.K.A. Anything with hardware based DRM. (Video game consoles, media players, phones, PCs with a TPM chip and SecureBoot.) These tend to have exploitable entry points that affect the "secure" sections
A few questions (Score:2)
1. Were financial institutions using host intrusion detection systems?
2. Were these machines leaving critical directories open to writes by other users?
3. Were mandatory access controls enabled?
4. How did the payload get onto the infected machine?
5. Were these companies using hardened kernels?
6. Were the systems up to the standards you'd expect of such institutions?
If these questions indicate that poor choices were made, then the real vulnerability would have been those choices.