7 ms·
It's systemd-daemon. The authors knew that systemd was so huge and opaque that it'd go unnoticed. It even has its own systemd unit file. It doesn't even do "no
by _hyn3 5y ago
It's systemd-daemon. The authors knew that systemd was so huge and opaque that it'd go unnoticed. It even has its own systemd unit file.
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.
- tyingq 5y agoProbably a good choice running as "systemd-whatever". People have lost track of all the systemd pieces as it's grown in scope, so it doesn't look immediately suspicious.
- fullstop 5y agoOther malware has hidden itself as init, mysqld, php-fpm, etc. This is really nothing new.
- deleted 5y ago[deleted]
- acdha 5y agoThis technique is really effective when the attacker does a little bit of homework on the system: if it’s a web server, a lot of people (even security analysts) will miss that the 147 httpd process are 146 /usr/sbin/httpd and one /usr/local/sbin/httpd — or they’ll assume that was where someone installed a custom build.
- fullstop 5y agoRight. It wouldn't be all that difficult to look at the process list and use heuristics to select a relevant process name.
- tyingq 5y agoYou could set argv[0] too: $ perl -e '$0="/usr/sbin/httpd";fork or sleep 1000';ps
- modshatereality 5y agoTrue, though systemd-* naming scheme provides a substantial amount of brush for mal-binaries/configs to use as persistent cover. Every system could be different, but distros are lazy it seems.
- jjgreen 5y agoAlso oddly redundant, most daemons end in a "d" to denote daemon, so that name is a bit like the toe-curling "RAID array".
- tuukkah 5y agoThis. If I saw a *d-daemon in the process list, I would feel I must research the origin of the name.
- _joel 5y agoReminds me of PAT Testing
- dbrgn 5y agoThis is called the "RAS Syndrome" (where "RAS" stands for "redundant acronym syndrome"): https://en.wikipedia.org/wiki/RAS_syndrome https://en.wikipedia.org/wiki/RAS_syndrome
- UI_at_80x24 5y agoAs the President of the AAPoOAA[0] I'd like to point out that this is the #1 article in our charter. [0] American Association of over Abused Acronyms </joke>
- PixelOfDeath 5y agoThat is just to highlight the redundancy!
- twarge 5y agoalso, "web blog"
- swiley 5y agoGlad to know I'm unaffected since all my machines run openrc and herd.
- CrazyPyroLinux 5y agoI'm skeptical since you spelled it "herd" (or maybe auto-correct strikes again.) But yeah, keeping your system free from the systemd cancer has always been a good idea.
- nitrogen 5y agoMaybe "herd" is an actual tool, separate from Hurd? Or "and herd" here is equivalent to "et al?" Impossible to search for though.
- jjgreen 5y agoet armenta ?
- m463 5y agoHurd/Hird you mean :) 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 https://en.wikipedia.org/wiki/GNU_Hurd#Name_and_logo https://en.wikipedia.org/wiki/GNU_Hurd#Name_and_logo
- brendyn 5y agoWhat deelowe said. Shepherd's cli tool is herd. For example you can run sudo herd status. In practice it means they are running GNU Guix
- deelowe 5y agoPretty sure they are referring to herd and shepherd: https://www.gnu.org/software/shepherd/manual/html_node/herd-and-shepherd.html https://www.gnu.org/software/shepherd/manual/html_node/herd-...
- VWWHFSfQ 5y agoThis kind of thing is trivially detected with basic system integrity tools [0][1] but I think a lot of those kinds of sysadmin tools have gone out of vogue at this point. [0] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-using-aide https://access.redhat.com/documentation/en-us/red_hat_enterp... [1] https://www.redhat.com/sysadmin/security-monitoring-tripwire https://www.redhat.com/sysadmin/security-monitoring-tripwire
- dbrgn 5y agorkhunter and samhain are two other similar tools. Both are available in the regular Debian repositories.
- jinnko 5y agorkhunter is nothing but a false sense of security. The detection mechanisms are crude and trivially bypassed. Have a read of the code for yourself.
- dbrgn 5y agoYes, it's very simplistic. It does not claim otherwise. 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).
- tomxor 5y agoIt's also piggybacking on dbus and gvfsd esque names for non root persistence. 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.
- donmcronald 5y agoI don’t hate SystemD and even prefer writing unit files over init scripts, but it really has usurped the whole system. It’s even usurped fstab on Debian 10 / Ubuntu 20.04 and it’s awful. 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?
- passerby1 5y agoWhat options are available to avoid this from happening?
- donmcronald 5y agoI don’t know. Set a root password so you can at least get into the emergency / recovery console.
- _hyn3 5y agoThat doesn't work so well via remote ssh. :(
- asasaasasa 5y agoTwo options available : 1) don't use systemD. 2) don't lose a data disk.