Live data from Hacker News

RotaJakiro: A long live secret backdoor with 0 VT detection

blog.netlab.360.com

151–160 of 183 posts

Re: RotaJakiro: A long live secret backdoor with 0 VT detection

#151

Earlier quoted context omitted.

I'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.

Maybe "herd" is an actual tool, separate from Hurd? Or "and herd" here is equivalent to "et al?" Impossible to search for though.

Hurd/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

Re: RotaJakiro: A long live secret backdoor with 0 VT detection

#152
post #111
post #103

Earlier quoted context omitted.

You could set argv[0] too: $ perl -e '$0="/usr/sbin/httpd";fork or sleep 1000';ps

For me, it looks like: 17630 27 S 0:00.00 /usr/sbin/httpd (perl) which stands out like a sore thumb, IMHO.

*BSD, I suppose, but the idea is that the binary itself would be named httpd. Like "cp /usr/bin/perl ./httpd" first.

Re: RotaJakiro: A long live secret backdoor with 0 VT detection

#153

Earlier quoted context omitted.

curl'ing is not the same at all as running, say, a Debian apt-get install. 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…

In this context we’re not talking about .debs from an official repository PPAs and debs downloaded from a GitHub release page have all the same problems as curl | sh

Even if you aren't running official debs or RPMs, you're still quite a bit above running a build script off the web. A deb or RPM will include a manifest with checksums, which you can at a minimum use to confirm whether some post-isntall script or process changes an included file (such as removing or cleaning a malicious script that was included). In the case of RPM (at least, I'm not implying debs don't do this, just that I'm not as familiar with them) you can actually query any pre/post install scripts that were shipped with it as well:

    # rpm -q --scripts bash
    postinstall scriptlet (using ):
    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 ):
    -- 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
Even a downloaded package that's not signed is far more auditable after the fact than executing arbitrary commands from a remote source.

Re: RotaJakiro: A long live secret backdoor with 0 VT detection

#154

Earlier quoted context omitted.

I know I'm not at all the first to say this, but those "curl into sh" installers are just such terrible ideas in general, and typically inconvenient and brittle as well. I hate the idea of any arbitrary, unknown side-effects happening to my system. Providing an archive `.deb`, `.rpm`, etc is at least more convenient and predictable so it can be installed like a normal package by your package manager (although it does…

As you mention, curl into sh is just as safe as any other software installation mechanism, unless you’re the sort of person who reads configure scripts and makefiles and the various scripts inside Debian packages and RPMs. 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.

> curl into sh is just as safe as any other software installation mechanism

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.

Re: RotaJakiro: A long live secret backdoor with 0 VT detection

#155

Earlier quoted context omitted.

I think the comparison is quite apt actually - a software virus requires a host (system) to reproduce, just as a meat-space virus does.

I think the computer term for the thing that most resembles how a meatspace virus behaves and propagates is "worm". Most worms can probably be classified as viruses, but most viruses nowadays (thankfully) aren't worms. (It can also generally refer to anything that's malicious and recursively self-propagating, like Samy's infamous Myspace XSS worm [1].) Meatspace viruses are like computer worms, though computer viruse…

> I think the computer term for the thing that most resembles how a meatspace virus behaves and propagates is "worm".

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).

Re: RotaJakiro: A long live secret backdoor with 0 VT detection

#156
post #7

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.

I 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?

Re: RotaJakiro: A long live secret backdoor with 0 VT detection

#157

Earlier quoted context omitted.

In this context we’re not talking about .debs from an official repository PPAs and debs downloaded from a GitHub release page have all the same problems as curl | sh

Even if you aren't running official debs or RPMs, you're still quite a bit above running a build script off the web. A deb or RPM will include a manifest with checksums, which you can at a minimum use to confirm whether some post-isntall script or process changes an included file (such as removing or cleaning a malicious script that was included). In the case of RPM (at least, I'm not implying debs don't do this, jus…

I can also pipe the script into a file and read it: it’s much easier to vet a simple shell script than an rpm or whatever anyways. But, my point just is that the vast majority are going to trust the package they downloaded to be safe: most people installing Minecraft on Linux from a .rpm they downloaded from Mojang aren’t going to audit the RPM, they’re just going to install it, maybe even with (it’s been a while since I’ve used RPMs, so my syntax is probably off here):

    rpm -ip https://mojang.com/Minecraft-launcher.rpm
Which has all the same problems as curl | sh

The checksums don’t really matter here: if I can compromise the package, I can also compromise the checksums.

Re: RotaJakiro: A long live secret backdoor with 0 VT detection

#158
post #7

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.

I 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. L…

What options are available to avoid this from happening?

Re: RotaJakiro: A long live secret backdoor with 0 VT detection

#159

Earlier quoted context omitted.

Even if you aren't running official debs or RPMs, you're still quite a bit above running a build script off the web. A deb or RPM will include a manifest with checksums, which you can at a minimum use to confirm whether some post-isntall script or process changes an included file (such as removing or cleaning a malicious script that was included). In the case of RPM (at least, I'm not implying debs don't do this, jus…

I can also pipe the script into a file and read it: it’s much easier to vet a simple shell script than an rpm or whatever anyways. But, my point just is that the vast majority are going to trust the package they downloaded to be safe: most people installing Minecraft on Linux from a .rpm they downloaded from Mojang aren’t going to audit the RPM, they’re just going to install it, maybe even with (it’s been a while sin…

> I can also pipe the script into a file and read it

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.

Re: RotaJakiro: A long live secret backdoor with 0 VT detection

#160

Earlier quoted context omitted.

I 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. L…

What options are available to avoid this from happening?

I don’t know. Set a root password so you can at least get into the emergency / recovery console.
Post reply on HN