RotaJakiro: A long live secret backdoor with 0 VT detection
blog.netlab.360.com
blog.netlab.360.com
It doesn't even do "normal" rootkit level of hiding that rootkit detectors might notice; it just hides in plain site as an innocent root process, right out in the open.
$ perl -e '$0="/usr/sbin/httpd";fork or sleep 1000';ps17630 27 S 0:00.00 /usr/sbin/httpd (perl)
which stands out like a sore thumb, IMHO.
ps, top, and htop all show /usr/sbin/httpd on Ubuntu.
It's not completely reliable but most people wouldn't look that deep anyway.
I think I used lsof back then but it’s been a while.
$ readlink /proc/`pgrep /usr/sbin/httpd`/exe
/usr/bin/perl[0] American Association of over Abused Acronyms </joke>
In December 1991 the primary architect of the Hurd described the name as a mutually recursive acronym:
It's time [to] explain the meaning of "Hurd". "Hurd" stands for "Hird of Unix-Replacing Daemons". And, then, "Hird" stands for "Hurd of Interfaces Representing Depth". We have here, to my knowledge, the first software to be named by a pair of mutually recursive acronyms.
- Thomas (then Michael) Bushnell
[0] https://access.redhat.com/documentation/en-us/red_hat_enterp...
[1] https://www.redhat.com/sysadmin/security-monitoring-tripwire
However, it did manage to detect a rootkit on one of my system once (many years ago, when I used to phpMyAdmin, which had some kind of RCE). So it's better than nothing, and it would probably have detected the backdoor from the article (which does not even attempt to hide itself).
They are common but small compared to systemd. there are lots of commonly installed deamons, most people can't keep track of all of their names through all revisions. Even if you did it's still going to be hard to spot with legitimate looking names like this.
If you lose a disk on a modern system, SystemD will refuse to boot. Instead, it’ll try to drop to an emergency console, BUT there’s no root password on those systems because they use sudo. So it just runs in a loop and you’re SOL.
Losing a data disk shouldn’t prevent my system from booting. WTF?
news.thaprior.net blog.eduelects.com cdn.mirror-codes.net status.sublineover.net
Just out of curiosity I did a simple search and found no mention of any of those domains, except for status.sublineover.net which is being reported here:
https://raw.githubusercontent.com/shargon/Fwhibbit/master/To...
Which is stored on a 4 years old project by what seems to be a ethical hackers group:
https://github.com/shargon/Fwhibbit
(possibly related to: https://fwhibbit.es )
https://domain.glass/news.thaprior.net -registered 2015-12-09 -intermittent cisco umbrella ranking since 2021-01-31
https://domain.glass/cdn.mirror-codes.net -registered 2015-12-10
https://domain.glass/blog.eduelects.com -registered 2015-12-09
All domains registered with Web4Africa (Pty) Ltd, hosting provided by Deltahost PTR, Kiev, Ukraine
It places a whole bunch of files in various locations, is running as a separate process, and doesn't do https properly.
It's surprising really - when LD_PRELOAD'ing your malware into an existing process is way stealthier. Preferably one that nobody will bat an eyelash at for making TCP connections.
The best ones will probably hide in (places such as) your initial ramdisk, be invisible when the system is running, and copy themselves into the new ramdisk whenever you generate a new one.
Anyways. This isn't 'stealthy'. Not at all. It's hardly the bare minimum.
One way around this if you insist is tricking another app into loading you, instead of you forcing your way in, this looks more legit.
But the best way to stay undetected is to behave as a regular innocent program and not use any tricks at all. These days, when computers have hundreds of processes running, nobody is going to notice another one.
For network communications there are ways of delegating this to other apps, so that you don't trigger the firewall. For example you can write something in the Chrome user profile directory which will make Chrome fetch data for you on the next start.
There is no such thing on modern-day Windows.
There used to be AppInit DLLs, but that 'feature' was broken to a degree that no legitimate application would have used it anyways and it likely wasn't a malware author's first choice either.
Further, by the time you place a backdoor such as this, you would have neutralized any antivirus software. This used to be done by 'patching' them and turning their update process into something that did essentially nothing after any download. No idea what the state of the art is here for either.
This is a backdoor after all, not a vector. As a backdoor you mostly care about humans noticing you messed with their system. You have defeated and subverted the machine and now need to keep the meat ignorant. So you want to avoid having random suspiciously named files lying around or weird extraneous processes showing up. Even the most technologically illiterate users know to watch for weird processes.
There are a number of ways. For example shell extensions. Even Chrome, which took great care to not load them missed a few, which I used to get my DLL running inside Chrome without the antivirus complaining. This was some years ago, don't know if they fixed this (and is not really a bug, is by design, sort of).
> you would have neutralized any antivirus software.
That is extremely difficult and fragile. Much better to just not trigger it in the first way by behaving like a "normal" app. The user is also much more likely to notice a non-updating antivirus than some random process.
> Anyways. This isn't 'stealthy'. Not at all. It's hardly the bare minimum.
It's using techniques to encourage people and systems overlook it when it's noticed. I think that qualifies.
While it would be prudent to examine the script rather than just blindly execute it... I imagine most don’t (myself included).
- access clipboard
- mess with scrolling
- overlapping controls.Either an Admin builds from source, an Admin installs a binary from a source they deem trustworthy, or you YOLO, download something sketchy to an older system and watch what your Network Analyzer/reverse engineering stack spits out.
App stores changed none of that in terms of fundamental activity one needs to do. They just lull users into a false sense of security because "someone else did it". I've run into too many devs who salivated over the idea of embedding cryptominers in game clones to believe it isn't done on a semi-regular basis.
Reminds me of early days in my career when my mentor and I were discussing user issues with a library we maintained. I didn't realize it at the time, but he was messing with me by suggesting we add some hooks to report usage statistics back to us and use that to improve things.
I was young and naive so excuse that I got really excited at the genius of the idea. If not for his wry smile, I would have happily run off and implemented just that.
What people run on their machine is no one's business but theirs. Undisclosed/non-consensual information leakage is unethical, and immoral. Period. I'm also not entirely on the status-quo of "accept the EULA or F off" form of disclosure or consent facilitation either. If someone reaches out, by all means, get the detailed info you need, but don't pull it. Let them push it. Other folk's machines don't become yours by virtue of executing some version of a computation you wrote once, no matter how badly Microsoft, IBM, Intel, and the FAANG's wish that were the case.
Note, this would be considered anti-thetical to most corporate or for-profit interests in the computing space; so don't be surprised if you get blowback or static for it.
This just isn’t true: app stores vary but they added some key changes — developers have a reputation to worry about, stores restrict what APIs you can call, and it provides a single place to force updates or pull malware. That’s not perfect, of course, but it’s better than just installing whatever you find online — Facebook et al. wouldn’t be upset with Apple if it wasn’t working.
Do you trust the Debian project? I mean, there’s reasons to trust them but if you don’t, then don’t run Debian.
If you do: the package repositories carry their chain of trust, since they’re signed by Debian maintainers- not the application developers themselves.
That’s a large distinction.
App stores didn’t give us trust; they have developers direct access to users and, crucially, the ability to charge for software- which was not a consideration for package managers before.
And Apple for the most part has been trying to carry the “burden” of ensuring trust, at a high cost.
They're fine for security and super convenient. I get why it's so popular - packaging and publishing debs is often going to be a lot more work, and now you're in the world of either maintaining a package repo or having to deal with an official one.
Creating a baseline .deb file takes at most 10 minutes if you know what you're doing. To know what you're doing, you need to spend ~2 hours once.
It's not rocket science (finding the documentation is tbh). :)
In this case, explicitly telling "this is my repository and this is the public key. gnupg the key, add this repository line, and get the packages" provides an end to end verified package pipeline. No .sh scripts to compromise.
If you keep your private keys on a network detached place and only plug your keys while signing stuff, things are pretty secure out of the box.
https://src.fedoraproject.org/rpms/5minute/blob/rawhide/f/5m...
Signing of packages is used to protect from malware.
Even something like nix runs all sorts of arbitrary side effects when installing packages: the main benefit isn’t preventing the side-effects but the various sandboxing tricks it uses.
I do admit that this sandbox is likely more for purity than security. Nonetheless while there may be exploits it is quite different than executing an installer or packages that have after-install scripts.
Also, I mainly use nix on Mac, where the sandbox is disabled by default and doesn’t work as well as the Linux sandbox, by all accounts.
I always read these files before building from source. Is this really so rare? Why wouldn't people read the scripts they're about to run?
> the various scripts inside Debian packages and RPMs
It's reasonable to assume package repository maintainers have ensured their packages are not malicious.
And, I doubt most people have the time or ability to read all the scripts that come with large software packages and ensure that they’re safe. For better or worse, executing code downloaded from the internet without verifying it manually is the norm these days.
You apt-get signed packages coming from official mirrors (at least I do). Most of the Debian packages, by very far, are also fully deterministic and reproducible. If someone serves a backdoored package, that's probably incredibly noisy, leaving lots of traces everywhere and evidence can be gathered.
When you curl, there's no way to know if you're the "lucky" one to get served malware by the server on that one curl call.
This is completely different.
PPAs and debs downloaded from a GitHub release page have all the same problems as curl | sh
# rpm -q --scripts bash
postinstall scriptlet (using <lua>):
nl = '\n'
sh = '/bin/sh'..nl
bash = '/bin/bash'..nl
f = io.open('/etc/shells', 'a+')
if f then
local shells = nl..f:read('*all')..nl
if not shells:find(nl..sh) then f:write(sh) end
if not shells:find(nl..bash) then f:write(bash) end
f:close()
end
postuninstall scriptlet (using <lua>):
-- Run it only if we are uninstalling
if arg[2] == "0"
then
t={}
for line in io.lines("/etc/shells")
do
if line ~= "/bin/bash" and line ~= "/bin/sh"
then
table.insert(t,line)
end
end
f = io.open("/etc/shells", "w+")
for n,line in pairs(t)
do
f:write(line.."\n")
end
f:close()
end
rpm -ip https://mojang.com/Minecraft-launcher.rpm
The checksums don’t really matter here: if I can compromise the package, I can also compromise the checksums.
Except then it's not the same idiom. Piping curl to a shell is not the same thing as downloading and running an installer, even if that installer happens to be a shell script. Part of the main problem is that the installation steps are ephemeral. It's nearly impossible to confirm that what was run when you installed it is what you see when you check the installation URL now, where now may be a week, a month or a year later.
> Which has all the same problems as curl | sh
No, I just god through outlining some of the ways it specifically is different in the prior comment. At a minimum, you know what launcher was installed, and what URL it's set to check, and what version it is in case there's a bug in the launcher. It shares some problems with piping an online script to a shell, but not all of them. You may think the ways in which they differ don't matter, but that's an opinion, and I hold a different one. They are different in real ways though.
It most certainly is not. Grabbing random code from some site is not the same as installing a package from a known repository which has been tested and inspected by a maintainer. Of course the latter isn't perfect, but it is way more assurance than the none whatsoever of a random script from an unknown source.
Why do you believe that to be the case?
>On March 25, 2021, 360 NETLAB's BotMon system flagged a suspiciousELF file (MD5=64f6cfe44ba08b0babdd3904233c4857) with 0 VT detection, the sample communicates with 4 domains on TCP 443 (HTTPS), but the traffic is not of TLS/SSL. A close look at the sample revealed it to be a backdoor targeting Linux X64 systems, a family that has been around for at least 3 years.
They saw it communicating over the network? But ... where was it? On their linux system? Someone else's? Any idea how it got there?
"0 VT detection" means that no virus scan on VirusTotal detected it.
The ZDNet article is a little more informative with regard to the terms: https://www.zdnet.com/article/rotajakiro-a-linux-backdoor-th...
Modern websites/browsers recognize these and disable autolinking.
It's just another "backdoor" which had been installed by a hacker or malware. (Backdoor doesn't mean it's build into existing systems, it means it gives you access to a system through a unintended path. Most backdoors are installed by hackers or other malware to allow the attacker to again gain access at a later point. Most viruses bundle a backdoor, but it totally can be a separate thing).
Is this "just a backdoor"? Like, its sole purpose is to give remote access / exfiltrate information? If so, how does it end up on systems? What is the vector?
It gets there via some kind of compromise, either an insecure application, some drive-by exploit for some missing patch, owning a sysadmin and pushing it out via ansible/salt/etc.
Meatspace viruses are like computer worms, though computer viruses and computer worms aren't like meatspace worms; for that and a laundry list of other reasons, "malware" has superseded a lot of those terms among the infosec community.
A compuyter virus self propagates with human intervention. A worm self propagates without human intervention.
I think the biological item that most closely resembles a work would be a parasite that is self-mobile. E.g. a botfly.
Various computer virus' in the past propagated through floppy drives and infected floppies, but you were safe as long you didn't initiate the action that caused the infection (use the floppy in your computer). Also, you can get a virus by visiting a website, which is also initiated by the uninfected.
Worms used infected host resources to actively seek out and infect other hosts without any initiating action by those other hosts.
In this way, meatspace viruses are NOT like computer worms. They don't cause their hosts to seek out people to infect. Infection is either coincidental or requires some allowance by the candidate (close contact, use of shared resources, etc).
I still think a worm is a decent analogy, though. For example, the first thing a worm will often do is scan the local network and try to infect each "living host" it finds in its vicinity. In some sense it can be seen as having some kind of willpower or intention, but it's a little more like a blind, unthinking process of trying to constantly fire itself in all directions, not unlike how a virus is unthinkingly regularly emitting itself into the air around it to infect those in its vicinity.
The first meaning is what you describe: something malicious stealthily implanted into an otherwise-legitimate or thought-to-be-legitimate application or appliance.
The other meaning covers any method of secret access persistence on a compromised system (generally a host, like a server). This could be something like a bash script that launches a reverse shell when you login, a malicious kernel module that extracts and executes arbitrary C code if a specific pattern is detected in network traffic, or just about anything imaginable. And you could also achieve it with the former definition.
I think among the infosec community, it's indeed more common for "backdoor" to refer to the former and a general term like "persistence" / "persistence mechanism" (though that can potentially refer to anything malicious that persists), or sub-categories like "foothold", to refer to the latter. "Backdoor" for the latter wouldn't be a misuse, though.
There's also a possible looser third definition, where lazy / fearmongering anti-virus companies sometimes like to label almost any kind of malware a "backdoor" or "backdoor trojan", perhaps because that carries more frightening implications for end users than a term like "virus" or "malware". It somewhat overlaps with the second definition, but I think it's rare a technical person would use it that way; it's less rare that a technical person might use the second definition.
If one or more of those files is found, you likely are infected - they probably are not "real" system files.
If you find one, do a system audit
Yeah, I had a corner case where I wanted to use ISC DHCP client (due to Juniper DHCP server at my ISP) where I wanted to block all network access to systemd.
Alas, no can do. So i’ve since moved over to Denuvan distro where SysV unit can still be used while having Debian APT repo.
This is a plus for OpenBSD which can firewall by-PID (PID 1, systemd).
The file name is chosen by the attackers to look like a legit executable - systemd-daemon if installed as root, $HOME/.gvfsd/.profile/gvfsd-helper if installed without root privileges. That way victims who are looking at file names won't be alarmed because they look like an expected file e.g. hiding in the forest of legit "systemd-*" files.
execute the cipher on it and see :)
The kernel any OS including linux runs is not source only at all, it's compiled, maybe by the user from source or by a redistributor which then passes it in compiled form to your system.
Furthermore this malware seem to not mess with the kernel, but pretend to be a normal system service.
ELF means Executable and Linkable Format, it's the executable format which Linux binaries use (and not just them). E.g. a shared library (Linux version of DLL) is in elf format. A variation of ELF is also used by UEFI but that doesn't seem to matter in this article.
So basically someone or something hacked their system and installed this malware or they where tricked into installing it themself.
The fact that the involved files where named in ways which totally could be normal parts of the system didn't help (but is also common, so I wouldn't say it made it harder).
EDIT: Someone else commented below. VT is number of scans on Virus Total website.
C2 = command & control, a server which tells the malware what to do.
Command & Control - server coordinating a botnet
Where does this stuff C2 back to / come from?
DeltaHost - VPS, VDS, dedicated servers in Ukraine & Netherlands
find / -type f -exec md5sum {} + | grep '^64f6cfe44ba08b0babdd3904233c4857'
Any feedback about using this method?
Surely this should be easily knowable?
In general good malwares either try to make money or have some kind of geopolitical goal (industrial spying etc).
Information is power, but generally, a good hacker would know how to obfuscate the reasons why he is putting malware.
Actually, last time I saw it the cracker (really a script) had replaced a couple of libraries with 32 bit versions on a 64 bit machine, which lead to most of the coreutils no longer working. Very subtle. 64-bit machines were becoming common by that point but maybe not so much on Linux servers, but still it was a clear sign of low effort!
Mouse: OK. see you next time.
It can't fully work. The kernel forgets parent-child relationships when processes die. Every orphan is adopted by init, and the kernel doesn't bother to remember the original parent. I've always hated this.
Anybody want to fix it?
The simple fix, kind of bad, is to simply remember the number and report it. The trouble here is that the number might get recycled. Adding a boolean to indicate "my original parent died" would help.
The proper fix is to keep some PID values allocated. Do not free a PID value until all the children of it have died. This would mean that every living process without a living original parent would have a ghost parent that gets reported to ps.
Sadly, for compatibility reasons, the getppid() call would need to report the adoptive parent. The fix for this is to add a new system call that reports both the original parent PID and a flag to indicate adoption.
Any fork bomb at all will exhaust the pid graveyard, wouldn't it? You could change pid_t to 64 bits but then the pid graveyard would take a lot of memory in the kernel.
For other situations, just keep the direct parents. Worst case, that doubles the PID usage.
Linux does keep track of parent-child process relationships. Linux, however, is just a kernel. It's not your operating system and it's definitely not your GUI.
I suggest you look at something like `htop`.
The concept of an absolute parent PID is nonsensical. Having an absolute parent PID would reduce the maximum number of processes effectively infinitely by creating a linked list of parent IDs even if the original parent process is gone.
Imagine if PID 2 is a parent process. It spawns a child. The child spawns a child. That child spawns a child... all the way down to the maximum number of PIDs... the final child is PID n. Then, all of the intermediate processes exit.
The final child process with the maximum PID wants to look at its parent process... but it's gone. Now, what do you want the kernel to do?
Should the kernel tell you about that PID n-1? What if another process has been created and has inherited PID n-1? Does your check now think that the process's parent is still alive? Your check is incorrect and will lead to very aggrevating bugs. Should the kernel prevent PID n-1 from being reused? Congrats you've basically just reinvented zombie processes.
No. The solution is to just reparent PID n onto PID 1 and tell you that process is the parent now. Then you, as a developer, have to actually deal with an aspect of computer science: lifetime management of your objects processes. And the kernel is therefore more efficient for the vast majority of processes who don't need or care about their parent.