I hope you know that there was a reason I wrote that challenge.

Your solution failed because you installed the rootkit that was aliased via the lsof command in the .bashrc.

Additionally, lsof like so many other tools rely on procfs, which allows processes to rewrite their own process names (comm) and arguments (cmdline).

Even if the malware of the article would run only in userspace (as non-root and "only a wheel user"), you certainly would have executed it.

My point being that you also forgot to check any processes against environment variables like LD_PRELOAD that the malware uses before executing any command (meaning even syntax programs like "if" as a program can be hijacked).

Again, this is a conceptual problem because there is a lot of programs in $PATH that can be executed by the same user, meaning only a kernel hook or ebpf module can audit/grant access to these kind of things to prevent that.

There is no trusted execution in Linux because of so many things down the line. Glibc, the $PATH mess, aliases, .local overrides etc.

Here's a .deb version; only running debsums once per package name. Errors will go to stderr:

    sudo lsof | grep -o '/[^ ]*\.so[^ ]*' | awk '!seen[$0]++' | while read -r path; do
        if p=$(dpkg -S "$path");then
            cut -f1 -d: <<<"$p"
        fi
    done | awk '!seen[$0]++' | xargs -n1 debsums -s

Didn't check the code, but lsof seems a good approach.

How does that work with the various namespaces? From root namespace you should see everything. But in a mount namespace you could bind mount under a different name. How would that confuse things? With a SELinux module even root cannot do everything. If /proc is mounted privately does it change anything?

Not sure, just starting to think. Linux has become incredibly complex since the old days...

Edit: orc routinely loads executable sections not belonging to any package.

Seems like you assumed none of your tools got backdoored. I'd start bootstrapping from busybox.

I think it's less about targeting KDE or GNOME specifically, but instead hitting linux desktop, and those using those systems.

as a target demographic, the folks using linux on the desktop are almost certainly more technical than most, and are likely developers, engineers, admins, or otherwise STEM types. probably high overlap with domains like SRE and security.

also probably, as a whole, better paid, and more likely to have cryptocurrency.

Please learn the difference of persistence and privilege escalation versus "hiding a binary".

They are certainly not trying to hide, and it has nothing to do with the initial exploit surface. You are mixing up things because you seem to be not aware how multi stage exploits work.

The article also mentioned that tomcat was targeted, but it didn't mention whether it was a zero day or a known vulnerability (like log4j vulnerabilities, for example).

- The initial access stage of that malware was a Tomcat exploit

- The privilege escalation stage was done via both userland + kernelmod, whereas userland's method was using glibc, hijacking any open() call of any process that is executed later. If you enter your sudo password any time for anything after that in any bash shell, it's escalated successfully and can install the kernel mod (that's what the .bashrc and profile entries were for).

- The persistence stage was done with a kernel mod that can now pretty much do whatever it wants.

Edit: After looking a little bit further, the initial access exploit was very likely CVE-2024-52316 [1], which is a Tomcat bug specific for that Jakarta Authentication system, given the described georegional malware campaign targets.

[1] https://nvd.nist.gov/vuln/detail/CVE-2024-52316

I totally agree with your statements.

I already replied somewhat in a sibling comment [1] in regards to the conceptual problem the article/malware focusses on.

In addition to that I think that it's a bad design choice relying so much on coreutils, binutils, and glibc behavior. A lot of those tools were written in a time when you trusted the system 100%, when there wasn't even an internet or downloadable programs yet.

In reality, it's unfeasible to have a user and group for each ELF binary/program that runs on your machine. Just managing file system access to all shared objects that each binary requires is a nightmare. AppArmor and other tools often go the "as good as possible" route here, but a lack of thorough profiling of binaries is usually the culprit why they can be exploited even in non-standard infrastructure systems.

The only way forward in my opinion is behavioral and network profiling (and the correlation between those) via eBPF/XDP. This way you can at least get the data to test against in those scenarios, whereas with AppArmor it's forensics that happened too late - long after you've been pwned, and you realized after hours of debugging that a rule was XOR ing another one with an unexpected side effect.

All these things that we are talking about are maintenance burden for the maintainers of the upstream distro, that in part have hundreds of "soft forks" of upstream software laying around that changes their behavior to reduce those attack surfaces. Even just little things like removing the SUID flag from packaged binaries becomes a huge burden to the maintainers, which in my opinion, should not even exist as a problem anymore.

Access to important (IAM related) things, like a keepassXC database file or the ssh keys somewhere in /home, should not be accessible to outside processes other than those that require it. The reality is though, discord can get pwned via HTML XSS messages and can just read it, and you wouldn't even know about it.

We need a better sandboxing system that by default denies access to anything on the filesystem, and requires mandatory rules/profiles what is able to be accessed. And that, hopefully, without more maintenance burden. This also implies that we have to get rid of all that $PATH related bullshit, and /usr/local and .local shenanigans have to be completely removed to get to a state where we can also call it a rootless base system.

POSIX as a reference to build your distro against isn't enough. Distros like Alpine focus on memory offsets and making exploitation of C-based software harder, but are useless once you realize everything is running as root anyways because they stop at "if you get pwned, you gotta reboot the container", so they're useless as a Desktop environment.

The issue I have with all these things is that there's this survivor's bias of Linux Desktop users that are not aware of how unsecure their system actually is. That's part of the reason why the late malware campaign trends of large APTs (APT3/APT28/APT29 etc) were so successful in targeting developer environments. They simply don't know that an "lsof" can be anything, and not the program they wanted to execute in the first place.

[1] https://news.ycombinator.com/item?id=42212391

I think most people will be served with a simple IDS that checks the entrypoints (ssh etc.), a software update routine and hardening of world accessible services to mitigate any potential damage.

Anything else is probably going to be immeasurable security theatre.

It doesn't target KDE, it's just the developer of backdoor runs KDE, so a running process named kde looks innocent on his machine. Similar reason for .Xl1 folder: if rootkit hid .X11 folder, it would break xorg on the developer's machine. And some server distros allow to install with KDE interface.

I think you have figured out where I am getting at.

As long as processes can rewrite their own cmdline and process names, you have a conceptual problem that you can only solve with kernel hooks (or eBPF modules).

The persistence techniques in the article were easy to follow, but all that alias mess, path mess, and glibc dependent mess makes everything that you execute untrustable.

The cli commands that were posted in the sibling comments all rely on procfs and the faked names :) so they won't actually detect it if a process rewrote its cmdline or has an in memory .so file that was changed and loaded from somewhere else (e.g. via LD_PRELOAD).

LD_PRELOAD is quite easy to detect, though nobody seems to be aware of its effects. And that is a 10 years known vulnerability and part of every standard audit by now. None of the posted answers even check for the environment files in procfs.

We're not talking about a bug in glibc here, because it is intended and documented behavior. If it was a bug, it would be much much worse.

edit: I wanted to add that the POSIX and Linux way of doing things would require a specific user for each program in order to be successful. But this is a prime example of what can go wrong when a user (and its groups) is used for multiple things. Any process that is running as the same (non-root) user can modify those procfs files. And I think that's a HUGE problem.

what is this

    /var/*/*maps 

?

Yes, if it's not running Tomcat.

(Personal opinion: You should never run Tomcat, history of really unsecure development practices)

I thought SQL injection but actually Tomcat ? Might be just an old unpatched server allowing PUTs

Unless I misread they don't state exactly how the attack escalates privileges to install the driver. Could there be two versions of the attack with varying levels of severity?

Any tools or resources you'd recommend for this?

A backdoor is a literal door that the building was designed with. Whatever purpose it served, criminals could sometimes use it to gain covert access.

>The article says they don’t know how the attacker gets access to install this back door in the first place.

It doesn't really matter, because it's orthogonal. Malware like this can be installed on a system through any exploit that provides sufficient access.

So there's two parts to defending against it: 1) finding and fixing any vulnerability that allows the installation of malware like this, and 2) since #1 is a never-ending task, knowing about this malware so you can look specifically for it and delete it when you find it.

Agree with OP, wikipedia is also wrong. A backdoor is something intentional. That definition fits any exploitable bug.

Sophisticated would be fileless with persistence through flashing of some firmware code, but those aren't gonna be uploaded randomly on virustotal lmao

I was under the impression that persistent, but SILENT access was China's goal. Dropping files in home and /tmp/ seems like the total opposite of that and any competent sysadmin would detect these anomalies manually real quick with a simple "ls -a", even possibly by accident.