The Bad guys never give up.

kc1di

Well-Known Member
Joined
May 14, 2021
Messages
3,423
Reaction score
3,882
Credits
24,815


A great line from the end of the article:

VoidLink still indicates defenders should apply vigilance when working with Linux machines.

This malware looks like you need to have already found a way to exploit the machine.
 
The is why I'm glad I use a Linux distro with 100% HDD / SSD isolation.

No HDD / SSD to write to can't gain no control.
Every session cleared with a reboot.

If I were to go to those lengths, I'd revisit this distro:


It's a great distro for accomplishing that same goal. Basically, your stuff runs in a VM. I've used it in the past. It might not make sense immediately, but it eventually makes good sense.

I used to use that on a laptop that I took with me. I wanted it to be secure if I lost it or if it was stolen. If folks are into a secure OS, that'd be one of the first ones I'd think of. But it's all VMs, so I don't usually recommend it when new users are asking for a secure distro. You, as an experienced user, would be just fine. There's a learning curve, but it is not too steep for someone who already uses Linux.
 
This is a worrisome one. But no machines have been found infected yet.
Thanks for the link to the article. It appears that the malware is server oriented, and in particular targeting specific cloud servers. That doesn't mean ordinary home users aren't potentially caught up in it, for example, if they are users and linked to those cloud servers.

The article mentions that the malware is not in the wild yet, writing: "no indication that VoidLink is actively targeting machines, there’s no immediate action required by defenders". There's probably not much that individual users can do at the moment apart from their normal security measures. Users differ in relation to the levels of security which they need to be met so it's an individual matter each needs to assess for themselves.

In relation to running one's system totally in RAM or in a virtual machine, in the case of accessing the internet, it doesn't mean that these working systems are beyond attack from malware generally. Rather, apart from any security measures inherent in those systems, the ultimate safety valve for them is that they can be discarded and an identical clean new version run in the face of any issues. There's both a benefit and a cost to running systems in that way. For this particular malware VoidLink though, there doesn't appear to be a current problem for ordinary individual home user systems.
 
Last edited:
Did I miss in the article how this malware infects machines?

This...

This malware looks like you need to have already found a way to exploit the machine.

Use strong defensive tools, and keep your software updated. Be aware of where your software comes from and only give it the permissions it needs.

For example, use SSH keys instead of passwords. That's a simple step that's rather important. Use fail2ban, of course. Then, don't forget the software you're running on the server. If you're running something like a web server, keep all of those applications up to date.

This sort of stuff isn't too hard to do. It can be mostly automated. It's a bit more complicated if you're using a testing environment and a production environment. You're never meant to make any changes on production first. So, you need an understood process for dealing with major incidents and pressing definable risks.

(Written from that point of view, as this is mainly aimed at stuff in the cloud.)
 
The is why I'm glad I use a Linux distro with 100% HDD / SSD isolation.
Don't forget PC firmware. Sadly all the UEFI/tpm bugaboo has not resulted in PC firmware being protected by default, or even having sufficient options (PBA, spi lock) to secure automated flashing. Ironically, a tool like fwupd will even mark a write-protected firmware as vulnerable. That aside, a distro like easyos will not feature the daemon by default, which is a bonus.

This sort of stuff isn't too hard to do. It can be mostly automated.
The automation got much better, as did the availability of up-to-date cloud based Linux templates for virtual hosts. Still, I'd still call it too advanced for the average Linux user who sets about to use a cloud VPS or something.

For example, fail2ban runs as root and has also been exploited in the past (e.g. CVE-2023-30258, scale 9.8). Being knowledgeable enough to deploy it safely (e.g. on a cloud host, automatically setting up IP sets of malicious actors) IMHO automatically makes you an advanced admin. Also, if you run something like a public ssh-server only, it will be probed all the time regardless. It will likely be more resource efficient to let the system's kernel automatically limit connection attempts (e.g. ufw limit ssh/tcp). There is no golden recipe, most certainly you'd have to get into the details depending on use-case of the system.

the ultimate safety valve for them is that they can be discarded and an identical clean new version run in the face of any issues.
I agree. Probably the most overlooked topic in this regard, being able to keep data safe and redeploy in a fresh instance. Aside from discussed malware, more automation mean more points to break. How much data can you afford to loose and how much downtime is tolerable, are questions to ask.
 
, it will be probed all the time regardless.

From my experience, this is true with pretty much everything that's public-facing. The current reported number is that just more than half of all traffic is bots, and that most of those bots are malicious. Those numbers are a bit lower than they used to report, so I'm not sure what to think of that.

Where applicable, I'd also highly recommend a WAF. If you're doing co-lo stuff, make sure you have access to your section of the networking gear, including the firewall. You know, cover the basics.

Also, some software seems to attract bots like honey attracts flies. Anything with WordPress is going to get hammered on. To that end, I have a WordPress site with 100% uptime. (To be fair, that's with a CDN, but it's still 99.9% without it.)
 


Follow Linux.org

Staff online


Top