Quoting marc (marc...@welz.org.za): > > > > > >> https://www.theregister.com/2021/04/29/stealthy_linux_backdoor_malware_spotted/ > > >> > > > ..how it works: > > > https://blog.netlab.360.com/stealth_rotajakiro_backdoor_en/ > > > > > > This backdoor is targetting systemd and gvfs. > > So the below words aren't directed at anybody in particular: > > It is easy to gloat > > And it is true that this particular bit of malware tries to blend in > amongst the many cryptic helper processes that both systemd-based > distributions and gnome desktops launch. A simpler system, where > there are fewer processes provides fewer hiding places. > > So simple is good, and it is even better to know what each user > process in "ps ax" does, and investigate if the listing looks > different... > > However, it also needs to be said that there are rootkits which > patch ps and ls to hide their executables. Even scarier ones > patch the kernel or even hard disk controller firmware...
May I interject, here? It's irrational to talk about rootkits as if they were a security threat (and my apologies in advance if, as seems likely, you're fully aware of the difference; in these discussions, there will always be other readers who don't. By definition, a rootkit is a set of coverup tools installed by an intruder _after stealing root via other means entirely). The point is that focussing on what bad guys do after they broken into your system and cracked the root account is largely a waste of time: After they have completely broken security, they can do anything at all, and what particular thing they choose do isn't very interesting -- or relevant to system administration. What _is_ interesting and relevant is how the bad guys got in and how they escalated privilege to root. And those questions are the ones relevant to system administration. > And as has been pointed out: We don't know how this malware gets > installed in the first place. Something which has gotten fashionable > very recently is the "supply-chain attack", where the bad guys don't > break into your system directly, but into the systems which > build the software you run... > > ... and in the case of devuan the attack risk is a bit larger > than for some other distributions, in that it is effectively > two distributions - debian plus the local changes. In a way > this doubles the risk... so it seems best to stay humble and > careful. Quite correct (though I could cavil about 'double') -- but with a significan number of competent system administrators testing and running Devuan, it would take a really bold would-be master criminal to do all the work and vetting to become a Debian or Devuan package maintainer, and his/her glory days would probably be short and the remainder of his/her days haunted by fear of very annoyed Linux people. But you're _actually_ talking about bad guys compromising the binary-package build infrastructure. Which, well, good luck. Even the most striking attacks against distro infrastructure to date, the ones against certain Debian Project and Gentoo Project in 2003, came nowhere near compromising the package collections. And that was not a freak accident. Distros are strongly motivated to be actually competent about their supply-chain infrastructure security, and so far have consistently been. Here is Wichert Ackerman's comprehensive write-up about details of the 2003 debian.org compromise, for details: https://web.archive.org/web/20070324011514/http://www.wiggy.net/debian/developer-securing/ > Put simply if you build packages for a distribution, you are likely > to be a more attractive target than a normal user. Note that neither Debian Project nor Devuan Project (nor Gentoo, nor...) accepts developer packages built on outside private hosts. > And then the other heuristic: I think it is best to either run sshd or > ssh on particular machine, not both. Er, anyone who compromises a user account from remote via an sshd can then immediately install an ssh client. Also, anyone who (somehow) remotely compromises an ssh client and thereby gains user-level shell access can immediately run an sshd bound to a high-numbered port (but IMO that would be silly, as the intruder could do easier and more useful things to create harm). Either way, there's no impediment to 'hopping along from one compromised system to another'. Calling either of those pieces of software a security risk in itself, whether present singly or together, strikes me as a failure of perspective, but that would be a much longer discussion than I wish to have here. Realistically, when we're talking about ssh-mediated compromise of system security, we're basically talking about stolen and reused security tokens (passwords or ssh keys). Like as happened in 2002 at my then-employer: http://linuxmafia.com/faq/Security/breakin-without-remote-vulnerability.html If you were to speculate that my employer was VA Linux Systems and that the embarassing theft of a token happened when a VA sysadmin ssh'd out to shells.sourceforge.net (a shared public host that he didn't know someone had rooted), and then ssh'd or scp'd back into the sensitive corporate network, I would say "Hmm, no comment.' -- Cheers, Grammarian's bar joke #16: A run-on sentence walks into a Rick Moen bar it starts flirting. With a cute little sentence fragment. r...@linuxmafia.com McQ! (4x80) _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng