OrBit: New Undetected Linux Threat Uses Unique Hijack of Execution Flow(intezer.com)
intezer.com
OrBit: New Undetected Linux Threat Uses Unique Hijack of Execution Flow
https://www.intezer.com/blog/incident-response/orbit-new-undetected-linux-threat/
27 comments
This is the same company that wasn't aware that LD_PRELOAD has been in use since the 90's in their last post. Here is that unique method of hijacking execution flow using /etc/ld.so.preload, 20 years ago: https://seclists.org/incidents/2002/Jan/86. None of this is unique or novel, including replacing the loader. LD_PRELOAD rootkits have severe drawbacks (which are not an issue for eBPF rootkits).
It’s weird how there’s been a massive uptick in security “threat researchers” blogging about hello world style malware in the past few years. On the plus side, malware reverse engineering is a tough job that traditionally didn’t pay that well, so hopefully they’re doing better now with the rise of all these startups doing blog posts about LD_PRELOAD.
There’s a wide gap between the majority of infosec bloggers and the top echelon of experts. I don’t see a problem with that, personally, and it’s not much different than the distribution of expertise in most other software domains. Surely the more the merrier, since at least some of those new entrants will grow into experts.
Also, there’s a reason the “hello world” malware posts are popular - the techniques they’re describing might have been known for years, but they’re practical and they work. Often their longevity is only due to their unfixable nature in exploiting a design flaw. So they’re useful not only from a practical standpoint but also an academic one of demonstrating a class of attack so pernicious that it can only be eliminated with a ground up redesign.
Also, there’s a reason the “hello world” malware posts are popular - the techniques they’re describing might have been known for years, but they’re practical and they work. Often their longevity is only due to their unfixable nature in exploiting a design flaw. So they’re useful not only from a practical standpoint but also an academic one of demonstrating a class of attack so pernicious that it can only be eliminated with a ground up redesign.
To me all of the sec research still seems like some kind of secret wisdom bound only to the best hackers out there, am I wrong here?
That's just the culture of defcon/blackhat/"if you get any certs you're dumb".
If you can program, you can learn almost any concept in security with self study and a handful of good books. Marketing posts, such as these, often aren't very useful but sure look neat with all the basic blocks...
If you can program, you can learn almost any concept in security with self study and a handful of good books. Marketing posts, such as these, often aren't very useful but sure look neat with all the basic blocks...
It seems to me hard sometimes to know what all of the 'state-of-the-art' and historic techniques are; in practice there'll likely be far too many to enumerate on a variety of platforms. But I do wonder if there are good lists or compilations anywhere that would include these.
That is the purpose of resources like MITRE's ATT&CK. Here is the ATT&CK page on the technique which is portrayed to be novel in this post: https://attack.mitre.org/techniques/T1574/006/
That was my first thought as well similar thing. They are right that it isn't being detected but malware detection for Linux has always been lagging.
How is this thing supposed to get installed on a Linux machine?
Fileless malware whose sole focus is root escalation.
Primary infection path seems to require root access at the very least, breaking out of SELinux/AppArmor as well if the infection vector is passed through an exploit. This post doesn't seem to say where the infection is coming from, I'm guessing the people who analyzed it haven't found a propagation method yet.
Perhaps it's installed through infected packages? Sabotaged repositories? Privilege escalation by `alias`ing `sudo`?
Perhaps it's installed through infected packages? Sabotaged repositories? Privilege escalation by `alias`ing `sudo`?
Would love to see these researchers comment on whether their new favourite exploit can bypass selinux or other MAC systems. I know a lot of lazy admins don't bother but if selinux will protect you, wouldn't you want to know?
[deleted]
Avoid using Glibc or patch-out LD_PRELOAD unless you need it. I don't mean as a response to this one threat but in general it seems to be the go to hooking mechanism. With this measure and signed kernel module loading enforcement with secureboot you can make it more hostile for untargeted malware to succeed in persisting or installing a rootkit.
Yeah, I would love a list of “downsides” if one were to compile-out the LD_PRELOAD.
As far as I can gather, one cannot do GDB without recompiling with --gdb option if LD_PRELOAD were disabled at compile-time.
As far as I can gather, one cannot do GDB without recompiling with --gdb option if LD_PRELOAD were disabled at compile-time.
LD_PRELOAD is also useful for working around hard-coded file paths inside of closed source (often commercial) software. This is how we make some closed source software work on NixOS, where we need a way to redirect file IO to corresponding paths in the NixOS file system (when those paths aren't the same as on typical distros).
That use of LD_PRELOAD by Nix is NOT a downside.
But it is not a good workaround for Nix thus making Nix a poor candidate for a reasonably secured production servers.
But it is not a good workaround for Nix thus making Nix a poor candidate for a reasonably secured production servers.
There are several others mentioned so it shouldn't be a default but none of those use cases apply to normal users otr prod servers.
yeah, the following positive usages of LD_PRELOAD is enough to cobble together and hijack a system, from userland.
https://github.com/gaul/awesome-ld-preload
https://github.com/gaul/awesome-ld-preload
Enjoyable article.
I am fairly confident that this rootkit would be detected by rkhunter, but possibly only when the adversary is logged into the machine, as the malware hides the pids and network ports associated with their ssh connection.
I am fairly confident that this rootkit would be detected by rkhunter, but possibly only when the adversary is logged into the machine, as the malware hides the pids and network ports associated with their ssh connection.
Fun fact: essentially all of the described exploits are entirely dependent on dynamic linking, which is something no sane modern OS should support. Thanks Drepper!
Wait you honestly think modern operating systems shouldn't support dynamic linking? Go ldd every program on your system and let me know how that goes.
Nice read, I wonder how this was detected though.
Did it trigger any alarms on the infected machine? Was a firewall or specialized traffic inspection involved?
[deleted]