> Specifically, it hides files and directories beginning with the names “auwd” and “vmware_helper” from directory listings and hides ports 52695 and 52699, where communications to attacker-controlled servers occur.
Do people out there really “allow any” ports on their firewalls? Or are those ports for control inside the firewall only?
Outgoing, which I believe this would be, is generally far less restrictive than incoming.
I'm playing around with IP address level detecting and blocking using incoming ports as indicators. I'm going to set aside some time to think more about restrictions on outgoing ports as a result of this and your comment.
Do some logging of frequently used remote ports over a couple of weeks and create a baseline set of allowed ports, block everything else and see what breaks.
I already use the limited Feodo Tracker[0] lists to flag in my firewall logs whether any device on the network has attempted to contact a known C&C IP address.
First things first, found I've got a bunch of devices doing "internet check" pings to Google's DNS servers once per second! I feel dirty that that's been going on so long.
Devices reconfigured to NOT do that at all.
Now that's cleared, the log won't be quite so cluttered.
Edited to add: Also redirected a whole load of regular NTP queries to remain internal.
There's sweet FA traffic that should be going out to the 'net when everyone's asleep. But make sure these rules can be switched on and off in case of emergencies.
I had to take my daughter to emergency late one night a few months ago (didn't end up being anything worthy of a story), but got home at 2:30am. My garage door opener gets smart-home-switched-off at 1:00am-ish. At 2:30am, just wanting to go to bed after the stress of an emergnecy room, waiting for that thing to boot up felt like 15 minutes.
And CloudFlare will be extremely happy to let them hide there. They don't care about malware abusing their workers infra.
But also "Only allow HTTPS out to FAANG" - ok, so now you're allowing encrypted connections to 2 largest cloud providers. At that point what's the benefit at all?
It’s widely known and talked about in the infosec community - getting CF to do anything about malicious content on their services is an absolute nightmare.
I do understand they don’t want to set any bad precedents internally, but their abuse reporting is abysmal.
Is it needed? Most hosting companies and CDNs are difficult to get to remove malicious content, this is pretty well known. I don't know why we'd require some form of irrefutable evidence to believe Cloudflare isn't the same.
It's kinda hard to point to someone saying how big the problem is, because most posts are just "sigh, here's yet another example, anyway...". I wouldn't go as far as saying they're doing this as an intended strategy, but it's definitely a case of it being hard for CloudFlare to care about an issue when they're in business of selling protection from that issue.
Thank you for providing links instead of giving me a “just believe me, bro” type of response. I’m about to take a look at them.
As a side note, I’m actually amused that I got downvoted for simply asking for evidence. I think it’s a pretty reasonable to ask folks to substantiate serious allegations made against a company like Cloudflare (a company, I might add, I’m not even a fan of for my own personal/philosophical reasons). I find this behavior very cult-like, but anyway, I digress…
I've used Google App Script for C&C in a demo before. It's HTTPS traffic going to a Google IP and the domain is script.google.com - what looks more legit than that?
Hiding your C&C behind clownflare is basically the default mode for a lot of actors.
CF are terribly slow to respond to abuse, their ranges are allowlisted everywhere, and it’s not terribly hard to hide your backend infrastructure (origin) even from cloudflare itself.
Sure you have to deal with the eventual takedown of your domain, by CF or more likely the domain registrar, but it’s trivial to work around that (backup domains, frequently rotating them, etc).
What’s funny is how Namecheap are now absolutely god tier at doing takedowns on malicious domains - they used to have a very poor reputation and now will process a takedown (provided evidence) within the hour usually.
> Or are those ports for control inside the firewall only?
It seems so. This traffic likely will not even traverse a firewall -- the article lists the IP addresses used with port 52699, which are all RFC1918 space (172.16.0.0/12).
oh yes, it does. Good catch. False-Flagging your actions as commercially motivated doesn’t strike me as a hard to construct alibi, either. Certainly not beyond the scope of sophisticated, state aligned actors, except maybe the north-Koreans, that guardians of peace Spiel was entertaining tho.
This awakens memories of GCHQ attacks on Belgian(?) telecom providers; they really are inherent gold mines for dragnet surveillance, stealing database, offensive cyberattacks and probably lots more. There’s a reason Huawei is subsidized for offering cheap 5g infrastructure to international clients, it’s a real nice thing to have backdoors to. Not saying the west is much better in this regard, Cisco has been more than compliant in similar shenanigans just to name one.
“Using weird protocols” for C&C is old hat for hackers tbh. Well over a decade ago after reading an RFC I switched all my backdoors to use SCTP - a protocol many of my peers had never fucking heard of - and found it evaded a shit tonne of IDS/firewall products.
2 years and they don't know how it starts? Well, I bet we can assume at first it was People. It is probably still largely people, but 2 years of possible persistent C2... I would think by now it's possibly using many other areas of ingress without any people involved.
>people will disable SELinux the moment their distro boots first time, because that thing is just massive pain to use Linux with.
I think you mean secure boot: the only distros that even try to enable SELinux are Fedora and Red Hat, and on those distros SELinux gets in the way only very rarely. (Source: I am a user of Fedora and Red Hat.)
I always thought that admins of Linux installs other than Fedora and Red Hat installs rarely bothered with selinux and that it is definitely not enabled on an initial install.
I thought selinux was available as a package on non-RH distros, but install it and enabling was very painful unless you are an selinux expert, so almost no one on those distros does.
I've been a fedora user and Red hat user since 2010, and worked at Red hat for a few years, though not on RHEL.
I think they did mean selinux. You are absolutely right that nowadays it just works for the most part. The big exception is for people deploying applications that don't have selinux config shipped by Red hat. Those people have to configure things properly, and rarely do people bother. If you do things like change the default ports for services, that can also get you in selinux trouble.
How does this “stealthy Linux rootkit” get onto the system in the first place. Without opening a malicious email attachment or clicking on a malicious weblink.
Those methods would work. Could also be included in pirate content in a torrent or similar (this was a significant vector for windows malware in the 2010s). Some instances could also have been manually placed. Or the creator could have bought the services if a bonnet, installing the seeds on machines already backdoored and open. There are a fair few ways to get new rootkits out there, a number of them difficult to trace back to the true source.
EDIT: from the article:
The researchers have so far been unable
to determine precisely how Krasue gets
installed. Possible infection vectors
include through vulnerability
exploitation, credential-stealing or
-guessing attacks, or by unwittingly
being installed as trojan stashed in an
installation file or update
masquerading as legitimate software
Today most (by volume) Linux attacks are against IoT devices that run Linux and SSH with weak/no auth.
Behind that are attacks on Linux web servers where exploits in the web application (e.g. WordPress) or the web framework (e.g. Rails) are the attack vector.
Seems to me this is probably a later stage thing. Somebody got initial access to a company's systems via such a mechanism to some individual's system. A few more cycles of recon, exploitation, and pivoting later, they may be in a position to install something like this on some actually important server. Use it to maintain access to the things they really want, then delete evidence of the previous steps to cover their tracks.
Now that it's at least 2 years after the initial intrusion, it could be pretty tough to determine how that happened and what path the attacker took.
The malicious weblink can be an advertisement, or a legit webpage that got compromised/XSS'd, or a formerly legit webpage whose domain has expired. (AFAIK this is pretty common)
The email attachment may come from your friend/business partner which themselves got infected and the malware is now attaching itself to their legit emails. (AFAIK not very common)
Probably not, depending on configuration. You can do very clever things with secure boot on Linux to have all kernel modules signed, etc, but if the attacker has ring0 code execution anyway that can be evaded without a huge amount of effort.
Binary replacement (replacing top, ps, netstat, etc with patched versions) is the oldest trick.
Syscall hooking kernel root kits largely only vary in how exactly they hook the syscalls - there’s a few methods, but the underlying principle is the same.
And then you have userland hooks which usually use LD_PRELOAD to intercept system calls/libc calls to get the job done.
Honestly most of the time a full blown root kit is overkill, just name your binary something innocuous and have it not do anything too fucking obvious and nobody will notice.
Itd be obvious if you really look, but i once discovered in Perl you can make your command look however you want when you run `ps`. I was able to make a process appear to be a kernel process (one with `[]`). It was pretty hard to discover unless you were very familiar with what every kernel process did. Ive discovered other fun ways of hiding things too, such as creating `...` as a directory. The first time i encountered that, it took me a whole day to find that dir.
> Syscall hooking kernel root kits largely only vary in how exactly they hook the syscalls
I don't understand how this survives major kernel upgrades. I have problems keeping out-of-tree modules working, intentionally. Do rootkits ship with fancy DKMS these days? Do the authors test with upcoming versions of major distros and push an upgrade to support the new release?
Most authors of kernel rootkits target a subset of versions and then give up or are stuck maintaining a codebase that is a mess of ifdefs for different versions.
At one of my old jobs we had a kernel rootkit we used on occasional red team exercises that ended up having forks for 2.6, a couple of forks for 3.x, and a couple more forks for 4.x - maintenance of that was an absolute nightmare and frankly, not worth the effort in the long run, so it was not maintained into 5.x and replaced with a few much simpler userland backdoors.
That’s why you will see malware such as the one in the article shipping with stuff cobbled together from several different rootkit projects to try obtain some semblance of compatibility.
In a Darknet Diaries episode from a while back, I recall a three letter agency person saying something along the lines of "oh, haha they are running desktop Linux, those guys never run anti-virus software, this will be easy..."
Can anyone give me any more depth on this? Is a typical desktop Linux distro install more likely to be susceptible to attack by a nation-state level actor?
Anti-virus software is utterly worthless in detecting previously-unknown rootkits. Not a factor.
The typical attack vector for any system would be compromising the inbound software. This is really easy to do when people are downloading and installing random programs from websites. This used to be less common, but popular cutting edge tools have popularized it recently "distro packaging is too slow, etc, curl|bash to install"
On linux, most base software comes from the distro repositories. The question there is how hard it would be to compromise these systems (including one of the mirrors). This includes ancillary packaging systems (pip, cpan, gems, conda, etc)
> Anti-virus software is utterly worthless in detecting previously-unknown rootkits.
Maybe the "this will be easy" part was that without AV software, there was a greater chance that they could just spin up Metasploit, and wouldn't even have to use one their stockpiled zero-days?
Why worry about stockpiled zero-days even for non-linux systems when they can just force MS or Apple to hand over data or inject whatever they want into an OS "update".
If I'm beginning to recall the story correctly, it's that your suggested route would involve more time, paperwork, and this particular op might not be important enough to get the big guns authorized by the higher-ups. Hence, "oh, this will be (relatively) easy..."
But AV (EPP) could detect a binary which was passed through a traditional vector, like phishing or gaining access to a "trusted" email account and attaching a compromised PDF, as a random example.
Just a reminder that I was originally talking about desktop Linux, and all of the additionally installed attack surface which that entails.
It would seem to me that it does not matter how "technical" a user is, they are still human, and some of the time anyone could fall for a well formed phishing attack. We all get tired, overworked, or click too fast, etc.
Not running AV on a desktop OS and relying on one's own superhuman technical ability seems like the exact type of hubris that would be ripe for attack.
It is very likely that a modern AV (I should have been saying EPP) will pick up your average re-encoded payload, or Metasploit fun time. Certainly they will pickup most known vulnerabilities. Endpoint Protection (EPP) orgs use the same CVE DBs that adversaries use.
Security is an onion, perfect is the enemy of good, etc...
Why make it easier for the adversaries? While annoying, running EPP on your desktop OS is not exactly neuroscience.
Ideally, it's furnished by the OS provider so that there are fewer parties to trust. I hate to say it, but Microsoft is now teaching by example. MS has factually one of the best-in-class Endpoint Protection agents on the market.
If resources allowed, all other desktop OS providers should follow suit, otherwise they are just shirking responsibility.
You have asked the most important question. I should have asked it as well.
Would love other input as I’m not an Ubuntu daily driver anymore.
It turns out 22.04 has ClamAV “provided and supported,” but not installed by default. So it should easily install manually. That’s what I would go with first, as it’s officially supported. An OS vendor supporting a specific AV vendor is a really big deal imho.
If that is not satisfactory by some metric, and this is just my personal and dated opinion… I used to like Eset.
I was naive before, but next time I install desktop Ubuntu, I will install ClamAV immediately.
- a 0day, which would require the AV to have a PDF parser better than the standard document viewer, and the ability to sense that this PDF is "weird" -- I would expect AV companies to publish ads "our AV has detected a 0day in XXX"
- a vulnerability was recently discovered in a PDF viewer, and the AV company can push their definitions earlier than the standard "package the fixed version - send to debian-security - let users upgrade" route. This would shorten the attack window by a few hours. Again, I would expect AV companies to boast "we were X hours earlier than the official fix".
Which one is the case? Or is there another option?
Actually, this whole "buggy PDF parser" thing should be solved by application sandboxing -- there is no need that document viewer needs any other access to my system. Unfortunately, Linux is lagging behind. There are some AppArmor experiments with not so great UX, and then there is QubesOS, which is difficult to use. The average Linux desktop is AFAIK almost unsandboxed.
I only ran Ubuntu as a desktop daily driver for a year or so, and I'm a muggle, so my understanding is limited. But, is there any real-world data on how often desktop Linux users run the equivalent of:
versus the more automated update systems MacOS or Windows ?
I am genuinely curious which ecosystem is more likely to be up to date. In my limited experience, I ran into issues updating on Ubuntu, and have not on MacOS and Windows. It seems like MacOS does it best as most applications come via the App Store, and on Windows that's in the future leaving most apps to take care of their own updates. However, Windows makes up for that a little bit with excellent, and auto-updated EPP, so that's something at least.
In your view, which desktop OS is most likely to be up to date for OS and apps?
I think Ubuntu has some kind of notifier in "tray". For me, I am subscribed to debian-security mailing list and update when something that is running on systems that I manage seems to be affected.
> versus the more automated update systems MacOS or Windows
I'm not sure -- it is better with Microsoft Store, but other apps solve updates on their own, with various success. I have little experience with Windows and no with mac OS, so I cannot comment.
The point is that it offers absolutely no defense against an APT -- who can simply include a binary that won't match any known exploit pattern.
It is not a meaningful technical barrier. It's the equivalent of storing a big table of mean things people said in a chat and suggesting this could prevent a capable person from insulting someone. Any moderately competent person can think of a way to communicate without using previously blocked phrases with minimal effort.
The AV databases are known - it is trivial to test against them to ensure a binary won't match.
AV is a crude tool, good only for blocking the most basic of efforts. It has no utility against a nation state.
Most of the currently used AV software contains heuristic/ML components that are able to gather and analyze various indicators of compromise. Without something like that running, you're basically tied to manual review of systems running at the moment. Making malware for such scenarios is basically making a Base64-encoded script in the language of your choice and then exploiting something(either the user or some software) to get it to execute.
I know, because I've been writing small malware toys and it got blasted by both Bitdefender and ESET.
> Most of the currently used AV software contains heuristic/ML components that are able to gather and analyze various indicators of compromise
Ransomware runs just fine on corporate computers with the latest and greatest "antivirus" software.
I really lost hope some 10 years ago, when i saw that i have to manually remove malware from memory sticks, because macaffe was clueless.
After more than a year they released an update that will detect and remove the malware (it was a virus speading through autorun.inf with exe names which did not have any sense like jhghjjj.exe)
I can't speak to that particular attack vector today, but it's interesting that McAfee isn't even on this Gartner chart, and that Microsoft is now a leader. Things have really changed in that space.
Corporate Ransomware attacks typically use 0-days and social engineering to achieve goals. No system is perfect, but a system in place is better than not having anything in place.
Things have changed in the last 10 years. Long gone are the days of only using signature databases.
> On linux, most base software comes from the distro repositories. The question there is how hard it would be to compromise these systems (including one of the mirrors). This includes ancillary packaging systems (pip, cpan, gems, conda, etc)
IMO if you're worried about the NSA, I assume they have access to root certificates and your package manager that uses TLS would be vulnerable. Wouldn't have to compromise any system or mirror to do so.
> your package manager that uses TLS would be vulnerable
most distro package managers (dpkg, rpm, etc.) tend to use gpg which shouldn't suffer from those issues (but they could obviously still have some sort of other backdoor for gpg).
Still, I feel like distro packages are really secured compared to stuff you install via pip/npm/... as I don't believe they do anything beyond protecting downloads with TLS.
This seems like an extremely important point, which applies not just to desktop Linux (my OP,) but especially server Linux.
Since I am very much a Linux & infosec muggle, please indulge me with these possibly dumb questions:
What are the mitigations for the lack of provenance in pip/npm?
Does properly configured SELinux do enough? Or is the fact that many of these packages use 80/443 negate that? Or is the fact that a pip/npm package could be comprised after install, during update the main problem?
I always think of that left-pad NPM drama, could that single dev have comprised thousands of systems by changing his update to something much more nefarious, instead of just deleting the package?
Well, it depends on what you consider "properly configured". But I'd say most systems used by developers aren't secured against these attacks. This mostly boils down to (like discussed elsewhere in this thread) that the developer runs his tools as his user, thus malicious software can modify his .bashrc and using that hijack a later sudo invocation to gain full access.
The thing that "protects" you is package locking, where unless you explicitly update your packages, you'll stay on an uncomprimised version (this broke with leftpad, as every available version was deleted). Locking has the downside that you don't get security updates for your software, which might be even more harmful tho.
I don't know what EPP provides (I doubt it'll help you in this case), but AFAIK least ClamAV only matches against known signatures (almost exclusively windows malware), so it can't detect newly created malware.
To protect a system, the only really reasonable approach is to not run code/binaries you don't trust. Once malicious software capable of writing files in ~, it's too late (those new sandboxing solutions are also not really solving this, as their interfaces to access files suck, so everyone continues to use the posix api with full access).
The only "Linux system" that can be considered secure in that regard is Android, as you don't have software that tries to execute "random" stuff in ~ and Apps tend to get away with using SQLite (not exposed to the user) over complex filesystem structures. Obv. you used to be able to access ~ rw, so malware could still upload/encrypt your Data, but most Users only have Pictures there (as other data was only stored in app-only storage [/data/data/<id>/] that couldn't be accessed by anyone else). Now you don't even have access to that, so malware is even more limited (but obv. legitimate software also suffered from that, for example WhatsApp used to store it's data there in ~/WhatsApp/ so you could simply access media sent/received on chat but now its far more hidden).
> IMO if you're worried about the NSA, I assume they have access to root certificates and your package manager that uses TLS would be vulnerable. Wouldn't have to compromise any system or mirror to do so.
Debian-derived systems use GPG signing so that wouldn't be enough, there's no central authority in the first place. There are hundreds of Debian developers, and most likely they could find one with poor opsec (or straight-up send a National Security Letter), but they would pretty much be burning that specific individual.
(Do distro package managers use Certificate Transparency? That would be the hope on the TLS-based side)
TLS isn’t a major pet of the security of say APT, the key which signs the Release/Pacakges files is, and the process that provides the checksums to those files, and if you’ve compromised the developer it’s over anyway.
With an NSA able to generate a root cert as you say, I’d trust an apt package from a known provider way before the curl|bash stuff or YetAnotherPackageManagerBecause13ArentEnough that people prefer today.
Now that I have had a chance to recall this story a bit more, I should not have mentioned the nation state actor aspect, it was distracting.
I believe the point was that they wouldn't have to do the paperwork, and wait to run it up the chain for the big guns.
Also, maybe the big guns would not be authorized for this particular op. I think what they were getting at was that there was probably no need for all that as there was no end point protection agent.
And, now I am inferring, that on desktop Linux, with all of the additionally installed attack surface combined with how often people actually run apt update && apt uprgade && apt dist-upgrade... "it was going to be (relatively) easy."
This mental model is oversimplified enough to be misleading, throwing up your hands too easily. See eg the Snowden revelations and pervasive passive eavesdropping, and the spectrum of increasingly risky/costly operations icreasingly valuable spoils that can't be had with easier methods. Rogue TLS certs are risky to use because the CA gets burned in the transparency logs.
The default settings of many Linux distros don't enable major security features. For example, on Arch Linux, microcode updates must be configured separately and most users likely skipped that step.
Also, X11 has really poor separation between processes. Any desktop application running in Xorg can keylog all user inputs.
It is possible to build a secure Linux installation but it requires a lot of careful OS knowledge and the discipline to only use a small set of software with established provenance. And probably disabling Javascript.
One big example is home folder access. Linux has a variety of file access control systems (the most prominent are Linux file permissions and SELinux). However, typically any application you run will be run under your own user and have access to your home folder.
In macOS/Windows, there are runtime permissions these days which allow you to control which folders can be given to which application.
Linux needs to mainstream a solution like this. One of the most popular way Linux users can handle this today is by associating a user with a application and granting various permissions to that user. However this is a far cry from safe by default, and it requires deep system knowledge.
Once you own the home folder you can drop aliases for anything you want in the bashrc with almost no one noticing. At that moment point you are essentially done in almost all cases even in the absence of a local root exploit which Linux continues to be rife with. You will eventually catch a sudo password (using a trivial sudo wrapper alias) and all the ssh keys and jump host or password manager config.
Moreover, even if the user manages to deny you root access through excellent hygiene, that just means you can't include this machine in your botnet. You still have full view of the home folder! Upload to a data broker, get $.
I guess it would make sense to make bashrc, zshrc, whatever immutable to all but root. Never really considered that before. Allowing them to be edited is like allowing you to install or edit binaries anywhere in your $PATH.
There are many more files that will need this protection:
- autorun and keyboard shortcuts of your window manager -- one can hook an evil command to Ctrl+C
- ~/.mozilla -- you can add arbitrary javascript to your profile or extensions
- any application which does not expect to have its config externally tampered with and this may result in various errors including RCE
- ~/work/FooProject/Makefile, configuration of your IDE (which contains list of commands that shall be executed to compile)
etc.
An explicit allowlist would be a better option, IMHO perfectly manageable - with a popup window "the app wants to access <file>, allow once | allow permanently | deny".
Of course - the point is not to get the home folder owned.
There is no reason why Evince/Okular or mpv (to name a few apps which handle files with complex formats from untrusted sources) should have the right to access anything beside their ~/.config/<application_name> and the file they are currently viewing/playing, or maybe read-only ~/Music. If you want to do a "Save as", you will do this through a OS-controlled file dialog, or save it to /tmp and copy it.
This can be achieved with AppArmor, with a caveat that in X, applications can steal each other's windows, but unfortunately this is not the default and easy configuration on most distros.
> In macOS/Windows, there are runtime permissions these days which allow you to control which folders can be given to which application.
I know about this feature on macOS, but how do you configure this on windows?
I’ve seen the protected folders feature or something like that. But that’s not “which app can access which folder”. Rather, “only this list of apps can access this list of folders”.
I think there is also bubblewrap which flatpak uses, which can limit access to folders, and also XDG desktop portal which allows GUI applications to access files that are not available to them. Not sure if these are widely used though, iirc a lot of flatpak packages just have "normal" permission. Also, these are not very helpful for CLI applications.
> Maybe the "this will be easy" part was that without AV software, there was a greater chance that they could just spin up Metasploit, and wouldn't even have to use one their stockpiled zero-days?
There’s a lot more footguns for attackers on modern windows than other operating systems. Most can be bypassed (EDR, AV, AMSI, ETW, UAC, controlled folders, App Control, block at first site etc), but it definitely raises the bar if your end goal is very low likelihoods of detection.
Put differently: the gauntlet you have to run on Windows (and to a lesser extent macOS I imagine) is much longer
Hum... Did Microsoft ever isolate their development infrastructure from the one that was compromised by Solar Winds? They never even tried to claim they did something about it.
Anyway, half of those acronyms have more vulnerabilities than Windows on a normal computer.
In order for AV to work, it has to have the highest level of permissions on the system, high enough to analyze all actions and potentially deny or alert on them.
I don't trust that an AV vendor can _add_ security to a system with a _new_ and obscure binary looking over the kernels shoulder. I don't think the properties of the universe allow for this to ever be true.
This is why.. shudder.. Microsoft appears to be the leader in AV (EPP). I also don't want an extra party involved, so ideally, the OS provider should also provide the EPP.
I do see how other OSes address this problem differently, such as everything going through a package manager.
But, see my question here regarding how often some is going to run apt update && apt upgrade && apt dist-upgrade, vs. the more automated update systems on MacOS and Windows.
The Linux desktop technology stack lags behind Windows and macOS when it comes to security. The causes are both technical (see this comment [1] for an overview) and non-technical, often stemming from a fragmented development model where there are no clearly defined security boundaries. For example:
- There is no real concept of base system because distros are usually a patchwork of software from diverse sources. This means stuff like proper secure boot is not really feasible on any distro (although AFAIK the systemd/Fedora people are working on it with signed UKIs and immutable OS images).
- Some features that could live in userland for improved security are instead implemented in the kernel, while both Windows and macOS generally keep moving exploitable features like font rendering to userland.
- Distros often disable or disregard security features such as SELinux or mitigations like CFI.
Here [2] is a more detailed article examining the lack of security of Linux desktops in case you're interested.
Malware requires propagation vectors. Computers don't work by magic, instead when thinking about security you should think about your threat model. What are you protecting and from whom, and what is the attack surface you are exposing which would allow them to get prize?
On Linux, the attack surface may not be non-existent, but by default it is smaller than some other operating systems. Any halfway competent Linux sysadmin can configure iptables or some other firewall to block all network traffic except what is specifically permitted. Even when something is exposed, it usually only allows access to specific user accounts (including system service accounts.) Once access is granted to an account, you are then constrained by discretionary access controls (DAC) (i.e. POSIX users + groups + file permission modes), and, for the paranoid, by mandatory access control (MAC) (eg AppArmor or SELinux) as well.
As others have said, such access could theoretically allow bootstrapping to greater privilege escalation, especially if you only have DAC and no MAC, but in practice it's harder than it sounds.
I have seen plenty of publicly-exposed Linux VMs compromized over the years. They were always compromized via one of two methods: the admin user explicitly enabled password authentication to ssh instead of adhering to keypairs (which we enforce by default); or, they opened up a vulnerable service such as a database to the public internet. It was never via some virus.
You hear people saying dumb stuff like, oh no one uses Linux and that's why there are no viruses. To that, I say our Linux server farms have a vast amount of highly valuable compute power and research data. If it were possible to infect these machines with a virus, any halfway competent nation state, ransomware group or bitcoin mining conglomerate would very much consider it a worthwhile investment to develop such a virus.
I've been using Linux desktop for 15 years. No viruses so far.
But if I just talked about my personal machines, would anyone listen? I've had a lot more opportunity to see what it looks like when a VM is compromized, compared to a desktop, because my desktop has never been compromized.
Question to HN, is chkrootkit still useful to use at all? I remember using that tool decades ago thinking it gave me some semblance of peace of mind, but I’ve also kind of assumed that sophisticated malware would likely be able to evade it.
Probably not. It's probably similar to windows AVs saying they can catch empire or meterpretor. They can, but it's also not too hard to change the signature away from default
I wonder if using Qubes-OS will solve some of these security problems.
The architecture is pretty good, and I’m surprised it has not been already adopted by OS vendors. But on the other hand, there is huge amount of code installed, and with far fewer eyes on it.
Another option is ChromeOS, but that’s tied to google. Also, I’m not sure if it can replace Linux desktop (there is option of installing Linux).
A third option is a minimax Debian. The software that the user needs will mostly be installed in VMs.
128 comments
[ 2.9 ms ] story [ 190 ms ] threadDo people out there really “allow any” ports on their firewalls? Or are those ports for control inside the firewall only?
I'm playing around with IP address level detecting and blocking using incoming ports as indicators. I'm going to set aside some time to think more about restrictions on outgoing ports as a result of this and your comment.
Do some logging of frequently used remote ports over a couple of weeks and create a baseline set of allowed ports, block everything else and see what breaks.
I already use the limited Feodo Tracker[0] lists to flag in my firewall logs whether any device on the network has attempted to contact a known C&C IP address.
Thanks for push.
[0]:https://feodotracker.abuse.ch
Devices reconfigured to NOT do that at all.
Now that's cleared, the log won't be quite so cluttered.
Edited to add: Also redirected a whole load of regular NTP queries to remain internal.
There's sweet FA traffic that should be going out to the 'net when everyone's asleep. But make sure these rules can be switched on and off in case of emergencies.
I had to take my daughter to emergency late one night a few months ago (didn't end up being anything worthy of a story), but got home at 2:30am. My garage door opener gets smart-home-switched-off at 1:00am-ish. At 2:30am, just wanting to go to bed after the stress of an emergnecy room, waiting for that thing to boot up felt like 15 minutes.
But also "Only allow HTTPS out to FAANG" - ok, so now you're allowing encrypted connections to 2 largest cloud providers. At that point what's the benefit at all?
This is a serious allegation to make. Do you happen to have some supporting evidence?
I do understand they don’t want to set any bad precedents internally, but their abuse reporting is abysmal.
It's kinda hard to point to someone saying how big the problem is, because most posts are just "sigh, here's yet another example, anyway...". I wouldn't go as far as saying they're doing this as an intended strategy, but it's definitely a case of it being hard for CloudFlare to care about an issue when they're in business of selling protection from that issue.
As a side note, I’m actually amused that I got downvoted for simply asking for evidence. I think it’s a pretty reasonable to ask folks to substantiate serious allegations made against a company like Cloudflare (a company, I might add, I’m not even a fan of for my own personal/philosophical reasons). I find this behavior very cult-like, but anyway, I digress…
CF are terribly slow to respond to abuse, their ranges are allowlisted everywhere, and it’s not terribly hard to hide your backend infrastructure (origin) even from cloudflare itself.
Sure you have to deal with the eventual takedown of your domain, by CF or more likely the domain registrar, but it’s trivial to work around that (backup domains, frequently rotating them, etc).
What’s funny is how Namecheap are now absolutely god tier at doing takedowns on malicious domains - they used to have a very poor reputation and now will process a takedown (provided evidence) within the hour usually.
A good solution is to block all outgoing traffic on production servers.
It seems so. This traffic likely will not even traverse a firewall -- the article lists the IP addresses used with port 52699, which are all RFC1918 space (172.16.0.0/12).
This awakens memories of GCHQ attacks on Belgian(?) telecom providers; they really are inherent gold mines for dragnet surveillance, stealing database, offensive cyberattacks and probably lots more. There’s a reason Huawei is subsidized for offering cheap 5g infrastructure to international clients, it’s a real nice thing to have backdoors to. Not saying the west is much better in this regard, Cisco has been more than compliant in similar shenanigans just to name one.
I think you mean secure boot: the only distros that even try to enable SELinux are Fedora and Red Hat, and on those distros SELinux gets in the way only very rarely. (Source: I am a user of Fedora and Red Hat.)
I thought selinux was available as a package on non-RH distros, but install it and enabling was very painful unless you are an selinux expert, so almost no one on those distros does.
Are you sure you don't mean AppArmor?
I think they did mean selinux. You are absolutely right that nowadays it just works for the most part. The big exception is for people deploying applications that don't have selinux config shipped by Red hat. Those people have to configure things properly, and rarely do people bother. If you do things like change the default ports for services, that can also get you in selinux trouble.
EDIT: from the article:
Behind that are attacks on Linux web servers where exploits in the web application (e.g. WordPress) or the web framework (e.g. Rails) are the attack vector.
Now that it's at least 2 years after the initial intrusion, it could be pretty tough to determine how that happened and what path the attacker took.
The email attachment may come from your friend/business partner which themselves got infected and the malware is now attaching itself to their legit emails. (AFAIK not very common)
Binary replacement (replacing top, ps, netstat, etc with patched versions) is the oldest trick.
Syscall hooking kernel root kits largely only vary in how exactly they hook the syscalls - there’s a few methods, but the underlying principle is the same.
And then you have userland hooks which usually use LD_PRELOAD to intercept system calls/libc calls to get the job done.
Honestly most of the time a full blown root kit is overkill, just name your binary something innocuous and have it not do anything too fucking obvious and nobody will notice.
https://www.man7.org/linux/man-pages/man2/prctl.2.html
> PR_SET_NAME
> Set the name of the calling thread
I don't understand how this survives major kernel upgrades. I have problems keeping out-of-tree modules working, intentionally. Do rootkits ship with fancy DKMS these days? Do the authors test with upcoming versions of major distros and push an upgrade to support the new release?
At one of my old jobs we had a kernel rootkit we used on occasional red team exercises that ended up having forks for 2.6, a couple of forks for 3.x, and a couple more forks for 4.x - maintenance of that was an absolute nightmare and frankly, not worth the effort in the long run, so it was not maintained into 5.x and replaced with a few much simpler userland backdoors.
That’s why you will see malware such as the one in the article shipping with stuff cobbled together from several different rootkit projects to try obtain some semblance of compatibility.
Can anyone give me any more depth on this? Is a typical desktop Linux distro install more likely to be susceptible to attack by a nation-state level actor?
The typical attack vector for any system would be compromising the inbound software. This is really easy to do when people are downloading and installing random programs from websites. This used to be less common, but popular cutting edge tools have popularized it recently "distro packaging is too slow, etc, curl|bash to install"
On linux, most base software comes from the distro repositories. The question there is how hard it would be to compromise these systems (including one of the mirrors). This includes ancillary packaging systems (pip, cpan, gems, conda, etc)
Maybe the "this will be easy" part was that without AV software, there was a greater chance that they could just spin up Metasploit, and wouldn't even have to use one their stockpiled zero-days?
The difficulty level is "recompile with small changes and test that it doesn't match" not "develop a new attack vector"
It really is stupid and pointless against an attacker with even a bare minimum of competence (able to run a software build vs downloading binaries)
Just a reminder that I was originally talking about desktop Linux, and all of the additionally installed attack surface which that entails.
It would seem to me that it does not matter how "technical" a user is, they are still human, and some of the time anyone could fall for a well formed phishing attack. We all get tired, overworked, or click too fast, etc.
Not running AV on a desktop OS and relying on one's own superhuman technical ability seems like the exact type of hubris that would be ripe for attack.
See another user's comment: https://news.ycombinator.com/item?id=38594247
Security is an onion, perfect is the enemy of good, etc...
Why make it easier for the adversaries? While annoying, running EPP on your desktop OS is not exactly neuroscience.
Ideally, it's furnished by the OS provider so that there are fewer parties to trust. I hate to say it, but Microsoft is now teaching by example. MS has factually one of the best-in-class Endpoint Protection agents on the market.
If resources allowed, all other desktop OS providers should follow suit, otherwise they are just shirking responsibility.
Would love other input as I’m not an Ubuntu daily driver anymore.
It turns out 22.04 has ClamAV “provided and supported,” but not installed by default. So it should easily install manually. That’s what I would go with first, as it’s officially supported. An OS vendor supporting a specific AV vendor is a really big deal imho.
If that is not satisfactory by some metric, and this is just my personal and dated opinion… I used to like Eset.
I was naive before, but next time I install desktop Ubuntu, I will install ClamAV immediately.
This means either:
- a 0day, which would require the AV to have a PDF parser better than the standard document viewer, and the ability to sense that this PDF is "weird" -- I would expect AV companies to publish ads "our AV has detected a 0day in XXX"
- a vulnerability was recently discovered in a PDF viewer, and the AV company can push their definitions earlier than the standard "package the fixed version - send to debian-security - let users upgrade" route. This would shorten the attack window by a few hours. Again, I would expect AV companies to boast "we were X hours earlier than the official fix".
Which one is the case? Or is there another option?
Actually, this whole "buggy PDF parser" thing should be solved by application sandboxing -- there is no need that document viewer needs any other access to my system. Unfortunately, Linux is lagging behind. There are some AppArmor experiments with not so great UX, and then there is QubesOS, which is difficult to use. The average Linux desktop is AFAIK almost unsandboxed.
I am now at the limits of my understanding...
I only ran Ubuntu as a desktop daily driver for a year or so, and I'm a muggle, so my understanding is limited. But, is there any real-world data on how often desktop Linux users run the equivalent of:
versus the more automated update systems MacOS or Windows ?I am genuinely curious which ecosystem is more likely to be up to date. In my limited experience, I ran into issues updating on Ubuntu, and have not on MacOS and Windows. It seems like MacOS does it best as most applications come via the App Store, and on Windows that's in the future leaving most apps to take care of their own updates. However, Windows makes up for that a little bit with excellent, and auto-updated EPP, so that's something at least.
In your view, which desktop OS is most likely to be up to date for OS and apps?
> versus the more automated update systems MacOS or Windows
I'm not sure -- it is better with Microsoft Store, but other apps solve updates on their own, with various success. I have little experience with Windows and no with mac OS, so I cannot comment.
It is not a meaningful technical barrier. It's the equivalent of storing a big table of mean things people said in a chat and suggesting this could prevent a capable person from insulting someone. Any moderately competent person can think of a way to communicate without using previously blocked phrases with minimal effort.
The AV databases are known - it is trivial to test against them to ensure a binary won't match.
AV is a crude tool, good only for blocking the most basic of efforts. It has no utility against a nation state.
Are you referring specific'ly to a limitation ClamAV?
I know, because I've been writing small malware toys and it got blasted by both Bitdefender and ESET.
Ransomware runs just fine on corporate computers with the latest and greatest "antivirus" software.
I really lost hope some 10 years ago, when i saw that i have to manually remove malware from memory sticks, because macaffe was clueless. After more than a year they released an update that will detect and remove the malware (it was a virus speading through autorun.inf with exe names which did not have any sense like jhghjjj.exe)
https://www.cybereason.com/blog/cybereason-named-a-leader-in...
Things have changed in the last 10 years. Long gone are the days of only using signature databases.
https://attackevals.mitre-engenuity.org/results/enterprise?v...
IMO if you're worried about the NSA, I assume they have access to root certificates and your package manager that uses TLS would be vulnerable. Wouldn't have to compromise any system or mirror to do so.
Still, I feel like distro packages are really secured compared to stuff you install via pip/npm/... as I don't believe they do anything beyond protecting downloads with TLS.
Since I am very much a Linux & infosec muggle, please indulge me with these possibly dumb questions:
What are the mitigations for the lack of provenance in pip/npm?
Does properly configured SELinux do enough? Or is the fact that many of these packages use 80/443 negate that? Or is the fact that a pip/npm package could be comprised after install, during update the main problem?
I always think of that left-pad NPM drama, could that single dev have comprised thousands of systems by changing his update to something much more nefarious, instead of just deleting the package?
Again, sorry if these are dumb questions.
The thing that "protects" you is package locking, where unless you explicitly update your packages, you'll stay on an uncomprimised version (this broke with leftpad, as every available version was deleted). Locking has the downside that you don't get security updates for your software, which might be even more harmful tho.
Say it was Ubuntu Desktop… would installing the supported EPP, ClamAV help in some regard? It would, right? Should this be a Tell HN type thing?
Maybe ClamAV being installed by default, like UFW, is the real (partial) solution?
To protect a system, the only really reasonable approach is to not run code/binaries you don't trust. Once malicious software capable of writing files in ~, it's too late (those new sandboxing solutions are also not really solving this, as their interfaces to access files suck, so everyone continues to use the posix api with full access).
The only "Linux system" that can be considered secure in that regard is Android, as you don't have software that tries to execute "random" stuff in ~ and Apps tend to get away with using SQLite (not exposed to the user) over complex filesystem structures. Obv. you used to be able to access ~ rw, so malware could still upload/encrypt your Data, but most Users only have Pictures there (as other data was only stored in app-only storage [/data/data/<id>/] that couldn't be accessed by anyone else). Now you don't even have access to that, so malware is even more limited (but obv. legitimate software also suffered from that, for example WhatsApp used to store it's data there in ~/WhatsApp/ so you could simply access media sent/received on chat but now its far more hidden).
Debian-derived systems use GPG signing so that wouldn't be enough, there's no central authority in the first place. There are hundreds of Debian developers, and most likely they could find one with poor opsec (or straight-up send a National Security Letter), but they would pretty much be burning that specific individual.
(Do distro package managers use Certificate Transparency? That would be the hope on the TLS-based side)
With an NSA able to generate a root cert as you say, I’d trust an apt package from a known provider way before the curl|bash stuff or YetAnotherPackageManagerBecause13ArentEnough that people prefer today.
I believe the point was that they wouldn't have to do the paperwork, and wait to run it up the chain for the big guns.
Also, maybe the big guns would not be authorized for this particular op. I think what they were getting at was that there was probably no need for all that as there was no end point protection agent.
And, now I am inferring, that on desktop Linux, with all of the additionally installed attack surface combined with how often people actually run apt update && apt uprgade && apt dist-upgrade... "it was going to be (relatively) easy."
Also, X11 has really poor separation between processes. Any desktop application running in Xorg can keylog all user inputs.
It is possible to build a secure Linux installation but it requires a lot of careful OS knowledge and the discipline to only use a small set of software with established provenance. And probably disabling Javascript.
In macOS/Windows, there are runtime permissions these days which allow you to control which folders can be given to which application.
Linux needs to mainstream a solution like this. One of the most popular way Linux users can handle this today is by associating a user with a application and granting various permissions to that user. However this is a far cry from safe by default, and it requires deep system knowledge.
- autorun and keyboard shortcuts of your window manager -- one can hook an evil command to Ctrl+C
- ~/.mozilla -- you can add arbitrary javascript to your profile or extensions
- any application which does not expect to have its config externally tampered with and this may result in various errors including RCE
- ~/work/FooProject/Makefile, configuration of your IDE (which contains list of commands that shall be executed to compile)
etc.
An explicit allowlist would be a better option, IMHO perfectly manageable - with a popup window "the app wants to access <file>, allow once | allow permanently | deny".
There is no reason why Evince/Okular or mpv (to name a few apps which handle files with complex formats from untrusted sources) should have the right to access anything beside their ~/.config/<application_name> and the file they are currently viewing/playing, or maybe read-only ~/Music. If you want to do a "Save as", you will do this through a OS-controlled file dialog, or save it to /tmp and copy it.
This can be achieved with AppArmor, with a caveat that in X, applications can steal each other's windows, but unfortunately this is not the default and easy configuration on most distros.
I know about this feature on macOS, but how do you configure this on windows?
I’ve seen the protected folders feature or something like that. But that’s not “which app can access which folder”. Rather, “only this list of apps can access this list of folders”.
> Maybe the "this will be easy" part was that without AV software, there was a greater chance that they could just spin up Metasploit, and wouldn't even have to use one their stockpiled zero-days?
Put differently: the gauntlet you have to run on Windows (and to a lesser extent macOS I imagine) is much longer
Anyway, half of those acronyms have more vulnerabilities than Windows on a normal computer.
I don't trust that an AV vendor can _add_ security to a system with a _new_ and obscure binary looking over the kernels shoulder. I don't think the properties of the universe allow for this to ever be true.
I do see how other OSes address this problem differently, such as everything going through a package manager.
But, see my question here regarding how often some is going to run apt update && apt upgrade && apt dist-upgrade, vs. the more automated update systems on MacOS and Windows.
https://news.ycombinator.com/item?id=38596966
- There is no real concept of base system because distros are usually a patchwork of software from diverse sources. This means stuff like proper secure boot is not really feasible on any distro (although AFAIK the systemd/Fedora people are working on it with signed UKIs and immutable OS images).
- Some features that could live in userland for improved security are instead implemented in the kernel, while both Windows and macOS generally keep moving exploitable features like font rendering to userland.
- Distros often disable or disregard security features such as SELinux or mitigations like CFI.
Here [2] is a more detailed article examining the lack of security of Linux desktops in case you're interested.
[1] https://news.ycombinator.com/item?id=37502088
[2] https://madaidans-insecurities.github.io/linux.html
On Linux, the attack surface may not be non-existent, but by default it is smaller than some other operating systems. Any halfway competent Linux sysadmin can configure iptables or some other firewall to block all network traffic except what is specifically permitted. Even when something is exposed, it usually only allows access to specific user accounts (including system service accounts.) Once access is granted to an account, you are then constrained by discretionary access controls (DAC) (i.e. POSIX users + groups + file permission modes), and, for the paranoid, by mandatory access control (MAC) (eg AppArmor or SELinux) as well.
As others have said, such access could theoretically allow bootstrapping to greater privilege escalation, especially if you only have DAC and no MAC, but in practice it's harder than it sounds.
I have seen plenty of publicly-exposed Linux VMs compromized over the years. They were always compromized via one of two methods: the admin user explicitly enabled password authentication to ssh instead of adhering to keypairs (which we enforce by default); or, they opened up a vulnerable service such as a database to the public internet. It was never via some virus.
You hear people saying dumb stuff like, oh no one uses Linux and that's why there are no viruses. To that, I say our Linux server farms have a vast amount of highly valuable compute power and research data. If it were possible to infect these machines with a virus, any halfway competent nation state, ransomware group or bitcoin mining conglomerate would very much consider it a worthwhile investment to develop such a virus.
I've been using Linux desktop for 15 years. No viruses so far.
But if I just talked about my personal machines, would anyone listen? I've had a lot more opportunity to see what it looks like when a VM is compromized, compared to a desktop, because my desktop has never been compromized.
Additionally, a lot of Linix users run most attack vectors (like browsers or email clients) inside a sandbox using Snap or FlatPak).
None of these things make it impossible to get through to the system, but they are additional barriers that an attacker needs to deal with.
The architecture is pretty good, and I’m surprised it has not been already adopted by OS vendors. But on the other hand, there is huge amount of code installed, and with far fewer eyes on it.
Another option is ChromeOS, but that’s tied to google. Also, I’m not sure if it can replace Linux desktop (there is option of installing Linux).
A third option is a minimax Debian. The software that the user needs will mostly be installed in VMs.