[HN Gopher] RotaJakiro: A long live secret backdoor with 0 VT de...
___________________________________________________________________
RotaJakiro: A long live secret backdoor with 0 VT detection
Author : FridayoLeary
Score : 369 points
Date : 2021-04-29 14:50 UTC (8 hours ago)
(HTM) web link (blog.netlab.360.com)
(TXT) w3m dump (blog.netlab.360.com)
| _hyn3 wrote:
| 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.
| VWWHFSfQ wrote:
| This 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_enterp...
|
| [1] https://www.redhat.com/sysadmin/security-monitoring-
| tripwire
| dbrgn wrote:
| rkhunter and samhain are two other similar tools. Both are
| available in the regular Debian repositories.
| tyingq wrote:
| Probably 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.
| _hyn3 wrote:
| That's pretty much what I said.. ;)
| tyingq wrote:
| Your comment was much shorter when I hit reply :)
| [deleted]
| fullstop wrote:
| Other malware has hidden itself as init, mysqld, php-fpm, etc.
| This is really nothing new.
| acdha wrote:
| This 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 wrote:
| Right. It wouldn't be all that difficult to look at the
| process list and use heuristics to select a relevant
| process name.
| tyingq wrote:
| You could set argv[0] too: $ perl -e
| '$0="/usr/sbin/httpd";fork or sleep 1000';ps
| acdha wrote:
| Good point - I was thinking about persistence but I saw
| the argv trick in the wild in the early 2000s when
| someone hit a PHP script in one of our undergrad's home
| directory and dropped something fun onto the system.
|
| I think I used lsof back then but it's been a while.
| nousermane wrote:
| $ readlink /proc/`pgrep /usr/sbin/httpd`/exe
| /usr/bin/perl
| rofrol wrote:
| What does it do?
| dcow wrote:
| The name of the program as it was invoked is stored in
| `argv[0]`. The perl script overwrites the value before
| continuing on.
| swills wrote:
| For me, it looks like:
|
| 17630 27 S 0:00.00 /usr/sbin/httpd (perl)
|
| which stands out like a sore thumb, IMHO.
| fullstop wrote:
| That's what I see on FreeBSD.
|
| ps, top, and htop all show /usr/sbin/httpd on Ubuntu.
| [deleted]
| modshatereality wrote:
| True, 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.
| tomxor wrote:
| It'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.
| jjgreen wrote:
| Also oddly redundant, most daemons end in a "d" to denote
| daemon, so that name is a bit like the toe-curling "RAID
| array".
| twarge wrote:
| also, "web blog"
| _joel wrote:
| Reminds me of PAT Testing
| dbrgn wrote:
| This is called the "RAS Syndrome" (where "RAS" stands for
| "redundant acronym syndrome"):
| https://en.wikipedia.org/wiki/RAS_syndrome
| UI_at_80x24 wrote:
| As 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 wrote:
| That is just to highlight the redundancy!
| tuukkah wrote:
| This. If I saw a *d-daemon in the process list, I would feel
| I must research the origin of the name.
| swiley wrote:
| Glad to know I'm unaffected since all my machines run openrc
| and herd.
| CrazyPyroLinux wrote:
| 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.
| deelowe wrote:
| Pretty sure they are referring to herd and shepherd: https:
| //www.gnu.org/software/shepherd/manual/html_node/herd-...
| nitrogen wrote:
| Maybe "herd" is an actual tool, separate from Hurd? Or "and
| herd" here is equivalent to "et al?" Impossible to search
| for though.
| m463 wrote:
| 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
| jjgreen wrote:
| _et armenta_ ?
| egberts1 wrote:
| This is why Linux firewall is terrible at blocking systemd's
| access to a network port.
|
| 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).
| chrisbrandow wrote:
| It's not clear to a non-systems person, me specifically, whether
| this is something that was added to Linux code base itself, or as
| a virus-like file that was added and has spread.
| dathinab wrote:
| The article didn't say anything of it being added to any code
| base, so no.
|
| 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).
| williesleg wrote:
| # rm -rf / send me bitcoin and I'll get your files back
| duxup wrote:
| This isn't my area of expertise but ... where did they find this?
|
| >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?
| Mathnerd314 wrote:
| BotMon is a "DDoS botnet C2 command tracking system". So I
| guess they're doing some kind of traffic analysis.
| https://ddosmon.net/faq doesn't say much.
|
| "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...
| hiccuphippo wrote:
| The website this was posted in seems to be a company offering
| network monitoring tools. So they probably saw it in one of
| their customer's systems.
| marcodiego wrote:
| So, it doesn't makes use of any 0day or exploit to enter the
| system. Has to be deliberately run. Makes me think of
| https://www.gnu.org/fun/jokes/evilmalware.en.html
| jacob019 wrote:
| The infection vector is not clear, this is the payload.
| spookthesunset wrote:
| Running something is as easy as hijacking one of those "copy
| and paste this line into your command prompt to install this
| package" things you see on many open source sites. The command
| always curls some bigger script down and executes it. Often
| times it even has you sudo to root.
|
| While it would be prudent to examine the script rather than
| just blindly execute it... I imagine most don't (myself
| included).
| amenod wrote:
| Or just copying a command with a hidden `<span>` in the
| middle, then pasting it into a terminal which allows
| multiline pastes (which most terminals do).
| michaelpb wrote:
| 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 doesn't
| truly help in terms of security or side-effects as it can
| still run scripts, so although ultimately the issue is still
| running binaries not vetted by your distro's maintainers)
| staticassertion wrote:
| > 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.
|
| 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.
| f1refly wrote:
| Actually it's not hard at all. All you need is a half-
| working build system and tar installed. You just create
| an additional build target and you're fine.
| staticassertion wrote:
| If you maintain the repository yourself now your setup
| instruction involves adding a custom apt repo, and then
| the installation. You also now have to handle multiple
| package managers, etc. A simple bootstrap script is
| pretty much as easy as it gets.
| fiddlerwoaroof wrote:
| 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.
| TacticalCoder wrote:
| 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're the
| "lucky" one to get served malware by the server on that
| one curl call.
|
| This is completely different.
| fiddlerwoaroof wrote:
| 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
| kevincox wrote:
| White side effects does Nix have when you install a
| package? IIUC it just updates the programs that are
| symlinked into various locations (like a directory in
| your $PATH).
| fiddlerwoaroof wrote:
| If you're installing from a binary cache, that's true,
| but a nix expression is just a build specification: it
| can run any program available to build and install a
| package. The "normal" way this works is you install the
| software to $out and $out gets copied into the nix store,
| but a malicious nix package can bypass this (and,
| assuming you're not using nix's sandboxing mechanisms, do
| arbitrary things to your computer).
| kevincox wrote:
| Building without a sandbox is really pushing the
| definition of "just installing a package". Also the
| sandbox is enabled by default on at lest NixOS.
|
| 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.
| fiddlerwoaroof wrote:
| We aren't really talking about installing packages from
| official distributions, right? We're talking about things
| like installing an interesting tool from GitHub using the
| ability of nix to download an build master.tar.gz. In
| most of these cases, there's always going to be some
| amount of reliance on the assumption that the developer
| of the software is trustworthy.
|
| 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.
| matheusmoreira wrote:
| > unless you're the sort of person who reads configure
| scripts and makefiles
|
| 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.
| fiddlerwoaroof wrote:
| But, we're talking about installing software from non-
| distribution sources. E.g. the Minecraft Launcher ships
| as a .deb that you install: there's no benefit security-
| wise for that over curl ... | sh
|
| 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.
| marcodiego wrote:
| 3 features browsers should not have: - access
| clipboard - mess with scrolling -
| overlapping controls.
| acdha wrote:
| Also you have to do that every time you run it (or pin
| hashes) -- the codecov uploader was fine for a long time
| before that changed.
| habibur wrote:
| Which doesn't sound worse than installing non-app-store
| applications on any other platform, my take.
| salawat wrote:
| You say that like doing so is a negative thing. How do you
| think executable code gets on a system in the first place?
|
| 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.
| musingsole wrote:
| > 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.
| salawat wrote:
| It's telling that you got grayed out that fast for what I
| don't think is an uncommon programming life lesson to try
| to instill.
|
| 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.
| dijit wrote:
| "Trust" is something you can give, though, as long as
| it's not to the whole world.
|
| 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.
| acdha wrote:
| > App stores changed none of that in terms of fundamental
| activity one needs to do.
|
| 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.
| IncRnd wrote:
| > So, it doesn't makes use of any 0day or exploit to enter the
| system.
|
| Why do you believe that to be the case?
| detaro wrote:
| How do you know an exploit wasn't used to deploy it?
| chmod775 wrote:
| This is pretty noisy as backdoors go. I wouldn't call this
| stealthy.
|
| 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.
| hdjfmtnrn wrote:
| On Windows, using the equivalent of LD_PRELOAD makes all the
| antiviruses go crazy.
|
| 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.
| chmod775 wrote:
| > On Windows, using the equivalent of LD_PRELOAD makes all
| the antiviruses go crazy.
|
| 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.
| hdjfmtnrn wrote:
| > There is no such thing on modern-day Windows.
|
| 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.
| ProAm wrote:
| You can hide in plain sight and still be hiding.
| kbenson wrote:
| It depends on what you consider stealth. This is the equivalent
| of someone social engineering their way into a building by
| looking like an employee. Are they using stealth? By the
| definition of the word, I think so.
|
| > 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.
| squarefoot wrote:
| The malware contains some hardcoded domains:
|
| 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 )
| lgats wrote:
| https://domain.glass/status.sublineover.net -registered
| 2015-12-09 -cisco umbrella ranked intermittently since 2020-07
|
| 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
| cyberpunk wrote:
| This is pretty cool, but I keep waiting until someone finds a
| horribly malicious version of bash that hides processes,
| directories and so on unless you have a specific env var set.. It
| could even detect when you do a update and just copy itself back
| over the new version, since almost all updates are being applied
| under a shell somewhere (may need a malicious python also then..)
| spookthesunset wrote:
| Back in my younger days... I've had boxes hacked through bugs
| in bind or sendmail. The hacker would cover their tracks with
| replacements of "ps", "ls" and such that attempted to cover
| their tracks. Good times.
| cyberpunk wrote:
| Back in my younger days I wrote a few such patches. Not a lot
| of people use tripwire anymore!
| tux3 wrote:
| The old tripwire makes less sense in a world of
| cloudwalking cattle. Ephemeral containers and VMs
| everywhere. Machines go up, they go down.
| cyberpunk wrote:
| Some of my containers run for weeks between deploys, I'd
| like to know what changes in 'em just as much as thay
| oldskool iaas db server marketing uses ;)
| jcrawfordor wrote:
| Replacing coreutils used to be a semi-common persistence
| strategy on Linux, you either swapped out the actual tools or
| a common library with one that had a hook to start up your
| RAT or whatever other malicious payload. It had the advantage
| of almost certainly getting it started very quickly after
| boot without necessarily leaving anything in an "obvious"
| place (e.g. cron, profile scripts, etc). I haven't seen this
| in a while, I would guess the increasing use of
| antivirus/rootkit detection (these things would be pretty
| easy to signature) and auditing package managers are both
| factors.
|
| 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!
| adventureadmin wrote:
| I don't think anyone bothers to backdoor a shell in that way.
| Why not just target libc via LD? That tricks bash, sh, python,
| etc; but you can use setuid to check for the existence of
| malware that is evading through LD_PRELOAD.
| SavantIdiot wrote:
| Dumb question but how does an ELF file end up in the Kernel? I
| thought everything was source-only?
| gvb wrote:
| The user (perhaps running as root) was tricked into installed
| it. It has nothing to do with the kernel installation.
|
| 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.
| jozvolskyef wrote:
| This is completely off topic but I love the Caesar cipher
| implementation in your bio. What does HAL stand for?
| thebigspacefuck wrote:
| IBM is HAL
| cronix wrote:
| Specifically, each letter in H-A-L is one less than I-B-M
| overtomanu wrote:
| this caesar cipher implementation doesnt replace z with a.
| incomplete??
| [deleted]
| gvb wrote:
| Yes, but it is unnecessary for the specific application.
| It also doesn't "encode" '@' which was more awkward. :-)
| lainga wrote:
| 2001:ASO's villain is named HAL
|
| execute the cipher on it and see :)
| Cyph0n wrote:
| The full name of the movie is "2001: A Space Odyssey".
| It's based on a novel by the great Arthur C. Clarke.
| kingsuper20 wrote:
| Based on a short story.
| dllthomas wrote:
| "Based on" is a little imprecise. IIRC, the two were
| developed simultaneously and cooperatively, until Kubrick
| deviated at the end in some ways that made Clarke mad.
| jozvolskyef wrote:
| That's a shame. The book's ending is one of the most
| memorable things I ever read.
| Cyph0n wrote:
| Huh, didn't know that! Thanks for sharing.
| Igelau wrote:
| IBM
| dathinab wrote:
| The kernel repository, i.e. where the kernel code comes from is
| source-only and didn't had anything todo with that ;-).
|
| 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).
| mossity wrote:
| This wasn't in the kernel, this was just a piece of malware
| targeting Linux systems
| Phurist wrote:
| I did not really understand it from the article but... how can
| one verify the existence of this on their own system and if
| needed, purge it ?
| fguerraz wrote:
| They give some md5, so you could check if any of your binaries
| gives any of these hashes
| gvb wrote:
| ls -l $HOME/.gvfsd/.profile/gvfsd-helper /bin/systemd/systemd-
| daemon /usr/lib/systemd/systemd-daemon
|
| 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
|
| https://linux-audit.com/determine-file-and-related-package/
| afturkrull wrote:
| How does RotaJakiro deploy on a not already compromised system.
| Without the enduser downloading and running an execututable? will
| it run on non-systemd systems? Or non-gnome desktops?
|
| "How did RotaJakiro spread, and what was its purpose?"
|
| There's no evidence it has spread, apart from being uploaded to
| the VirusTotal anti-malware engine?
| 101001001001 wrote:
| Why can't Linux keep track of parent-child relationships and
| visualize them when you look at running processes? You could
| instantly identify this virus. And why can't Linux apps have a
| universal and straightforward install directory?
| inetknght wrote:
| > _Why can't Linux keep track of parent-child relationships and
| visualize them when you look at running processes?_
|
| 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`.
| 101001001001 wrote:
| It doesn't. See below
| inetknght wrote:
| It does. You're mistaking _reparenting_ with another
| concept: the concept of an absolute parent PID.
|
| 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.
| [deleted]
| detaro wrote:
| What do you mean by "parent-child relationships"?
| lysium wrote:
| Do you mean pstree?
| cgh wrote:
| Assuming you are talking about parent/child processes, use the
| --forest option in ps for an ascii art process tree.
| souprock wrote:
| I implemented the --forest option in ps.
|
| 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.
| philsnow wrote:
| > The proper fix is to keep some PID values allocated. Do
| not free a PID value until all the children of it have
| died.
|
| 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.
| souprock wrote:
| For an actual fork bomb, nothing ends up in the PID
| graveyard. No process ever dies. The fork bomb by itself
| is a problem, even without a PID graveyard. Process
| limits are required to stop a fork bomb.
|
| For other situations, just keep the direct parents. Worst
| case, that doubles the PID usage.
| 101001001001 wrote:
| So I was right?
| temp667 wrote:
| I know you are not supposed to blanket block foreign IP's, but I
| often do that and it seems to knock down a fair bit of crap. Also
| saves you from inadvertently messing up GPDR.
|
| Where does this stuff C2 back to / come from?
| ficklepickle wrote:
| 176.107.176.16
|
| DeltaHost - VPS, VDS, dedicated servers in Ukraine &
| Netherlands
| ramshanker wrote:
| Cat : So my guess is the point where the virus author slipped is
| not making the traffic to port 443 look like genuine HTTPS. The
| moment a firewall notices 443 and NOT HTTPS it is tell-telle sign
| of something.
|
| Mouse: OK. see you next time.
| numpad0 wrote:
| PSA: when communicating known malicious FQDN/URLs in good cause,
| either add [.] before TLD or use hxxps URL scheme(e.g.
| example[.]com or hxxps://example.com).
|
| Modern websites/browsers recognize these and disable autolinking.
| pmoriarty wrote:
| What's "VT" and "C2" ?
| [deleted]
| ramshanker wrote:
| C2 is "Command and Control" server I guess. VT no idea.
|
| EDIT: Someone else commented below. VT is number of scans on
| Virus Total website.
| IChooseY0u wrote:
| VirusTotal?
| luto wrote:
| VT = virustotal.com, a popular site to check unknown binaries.
|
| C2 = command & control, a server which tells the malware what
| to do.
| detaro wrote:
| VirusTotal, online virus scanner and file sample collection
|
| Command & Control - server coordinating a botnet
| de6u99er wrote:
| Now a script would be great helping check if the backdoor is
| present on a system or not.
| vaylian wrote:
| Sure. Just use this one: http://totally-legit-
| website.com/downloads/linux-systemd-roo...
| jessaustin wrote:
| Should one use the "curl <url> | sh" idiom to install this
| tool?
| cblconfederate wrote:
| but only as root in a production machine
| ValueNull wrote:
| Add some sudos in there for good measure.
| DelaneyM wrote:
| The obvious question not answered (but asked) in the article is:
| "Who put it there and why?"
|
| Surely this should be easily knowable?
| temp667 wrote:
| It's not actually shipping with Linux - someone installed a
| virus. That's really it.
| detaro wrote:
| How would that be easy? If I put a random file on your computer
| X years ago while trying to cover my tracks, how would you tell
| when and how I did it?
| laburn wrote:
| Attribution of malware can be difficult and the lack of details
| like who was targeted and missing plugins don't leave enough
| information to guess who might have been interested in
| developing this.
| jokoon wrote:
| Well this might be answered by asking who got it, what is their
| business, etc.
|
| 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.
| TheMagicHorsey wrote:
| It's not quite clear to me, but is this Malware part of any of
| the popular Linux distributions, or was it part of an infection
| on that particular machine through some installation after the
| fact?
| speeder wrote:
| For those wondering why "RotaJakiro" the name, Jakiro is a
| reference to a Dota2 character, that is a dragon with 2 heads,
| thus why the double-behaviour got the name "Jakiro"
| FirstLvR wrote:
| so thats why the name was bothering me, thanks for the
| reference
| [deleted]
| hollerith wrote:
| Did Fedora's selinux policy stop this?
| angry_octet wrote:
| They already have local exec before they install this, and it's
| a user land persistence kit, so no.
| fguerraz wrote:
| Pardon me if it's a stupid question, but a backdoor to what? I
| don't really understand what it's about. In my mind a backdoor is
| hidden feature built into another _useful_ piece of software.
|
| 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?
| cyberpunk wrote:
| This is what you drop on a system after it's compromised for
| use later, it's a RAT.
|
| 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.
| fguerraz wrote:
| Got it thanks!
| 55555 wrote:
| it's a virus. lol. there are many ways to get them onto
| systems. file download site, typosquatted apt/pip package
| names, buying/hacking a download mirror website, 0-day browser
| exploits, etc.
| fguerraz wrote:
| err, no it's not a virus, it seems it has no ability to
| reproduce on its own.
| x86_64Ubuntu wrote:
| I'm loving the differences between the word "virus" in the
| computer and biology sense.
| danparsonson wrote:
| I think the comparison is quite apt actually - a software
| virus requires a host (system) to reproduce, just as a
| meat-space virus does.
| meowface wrote:
| 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 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.
|
| [1] https://en.wikipedia.org/wiki/Samy_(computer_worm)
| meowface wrote:
| The term "backdoor" kind of has two commonly used but somewhat
| different meanings: an embedded backdoor and an access
| backdoor. (Or perhaps "application backdoor" vs. "system
| backdoor".)
|
| 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.
___________________________________________________________________
(page generated 2021-04-29 23:00 UTC)