Linux Devices Are Under Attack By a Never-Before-Seen Worm 101
Previously unknown self-replicating malware has been infecting Linux devices worldwide, installing cryptomining malware using unusual concealment methods. The worm is a customized version of Mirai botnet malware, which takes control of Linux-based internet-connected devices to infect others. Mirai first emerged in 2016, delivering record-setting distributed denial-of-service attacks by compromising vulnerable devices. Once compromised, the worm self-replicates by scanning for and guessing credentials of additional vulnerable devices. While traditionally used for DDoS attacks, this latest variant focuses on covert cryptomining. ArsTechnica adds: On Wednesday, researchers from network security and reliability firm Akamai revealed that a previously unknown Mirai-based network they dubbed NoaBot has been targeting Linux devices since at least last January. Instead of targeting weak telnet passwords, the NoaBot targets weak passwords connecting SSH connections. Another twist: Rather than performing DDoSes, the new botnet installs cryptocurrency mining software, which allows the attackers to generate digital coins using victims' computing resources, electricity, and bandwidth. The cryptominer is a modified version of XMRig, another piece of open source malware. More recently, NoaBot has been used to also deliver P2PInfect, a separate worm researchers from Palo Alto Networks revealed last July.
Akamai has been monitoring NoaBot for the past 12 months in a honeypot that mimics real Linux devices to track various attacks circulating in the wild. To date, attacks have originated from 849 distinct IP addresses, almost all of which are likely hosting a device that's already infected. The following figure tracks the number of attacks delivered to the honeypot over the past year.
Akamai has been monitoring NoaBot for the past 12 months in a honeypot that mimics real Linux devices to track various attacks circulating in the wild. To date, attacks have originated from 849 distinct IP addresses, almost all of which are likely hosting a device that's already infected. The following figure tracks the number of attacks delivered to the honeypot over the past year.
Telnet... (Score:1)
Re: (Score:2)
Don't use passwords at all. Disable them in the sshd config and use keys instead.
Re:Telnet... (Score:4, Insightful)
You can also disable passwords for all external connections and still allow them for internal connections if you wish.
I would post the exact method but the Slashdot security blocker that I didn't know existed until right now says that I am not allowed to do that so you'll have to look it up on Google. Sorry about that, folks!
Hint: Look up the PasswordAuthentication and Match Address directives.
Now everyone logging in remotely (and the bad guys) need a key but local users can still use a password if they wish.
Re:Telnet... (Score:4, Insightful)
Re: Telnet... (Score:3)
Yep, I sure do miss the good old days when you could post code on this alleged site for nerds.
Re: (Score:2)
They can't keep the fucking ASCII swastikas out,
And they can't keep out iPhone spittle either.
Re: (Score:2)
Nonsense. Just stop using weak-ass passwords.
Re:Telnet... (Score:5, Funny)
what about SSH, since that is what this thing is using fucknuts
Why are you dragging me into this?
Re: (Score:1)
I know how you feel. It happens to me all the time.
Re: (Score:2)
Re: (Score:2)
There's a bit of a difference between a telnet service and a telnet client.
BTW, here's a quick way to install the latter on a Windows machine... /online /Enable-Feature /FeatureName:TelnetClient
dism
Or, if you prefer to use PowerShell...
Install-WindowsFeature -name "Telnet-Client"
Re: Telnet... (Score:1)
Install-WindowsFeature: The target of the specified cndlet cannot be a Windows client-based operating system.
Re: (Score:3)
It's your own fault if you have telnet access enabled...
This has nothing to do with Telnet, as ssh is the entry point. It's all about weak passwords.
Re: (Score:1)
> I am sure the Linux "community" will come up with no less than 12 variations on how to deal with this, and none of them will fully work right.
That's the Genetic Algorithm way to solve problems: create bunches of candidates, select the most successful ones (or least failures), randomly merge features together, rinse, repeat...
Eventually it'll probably be good enough.
Re:dont worry (Score:5, Insightful)
There is one way to deal with and it has already very well-documented for decades:
Don't use weak passwords.
You can take it a step farther and eliminate the use of passwords altogether or I don't know, keep port 22 behind a firewall unless you absolutely need it. But this isn't a Linux flaw at all.
Re: (Score:3)
Add random ports to the mix if you must accept external connections to mathematically reduce exposure.
Re: (Score:1)
Re: (Score:2)
Still part of a security strategy just like any obfuscation in general, you can't rely solely on it although obviously. Also with random ports, you get a lot less resource waste. I look at my logs.
Re: (Score:2)
Slows the skids down. Most of them don't know (or don't want to spend the time) fiddling with NMAP on every public IP address.
Re: (Score:2)
>"Add random ports to the mix if you must accept external connections to mathematically reduce exposure."
Might help a bit. But if you expose sshd to the internet, you *MUST* have some type of rate limiting to prevent brute-force attacks. You can do this even with just iptables. It can be done with just two lines (three lines if you want to log it too):
Re: (Score:2)
Great! Here is what I use, the problem I seem to see with what you use is that somebody could prevent you from logging into your own machine, there is no "by IP" in what you posted I suspect, not sure you prevent being flooded with logs either..
see srcip below. I also only accept connections from restricted ip:
SCAN_LOG_LIMIT=120/minute
CA_AND_OUR_NETWORKS="-m set --match-set CAnetworks src"
REDIR_PORT=66631
TARGET_PORT="22"
LIMIT="10/minute"
EXPIRES="600000" # this is in miliseconds
Re: (Score:2)
Kewl. Mine is just to show that it can be really simply. It does track the IP (that is "recent" flag, I believe). And yes, mine certainly does fill the logs (at least with no source IP filtering) if one chooses the 3 line version instead of omitting the middle-line rule. I can't take credit for the rules, since I stole them from somewhere :)
Re: (Score:2)
I remember writing this myself after looking at many others. I seem to remember that at the firewall level like I do, this was the optimal way to do it.
Cheers!
Re: (Score:2)
I thought you aren't supposed to use passwords at all and that passphrases are the new cool.
Re: (Score:2)
You're certainly not supposed to use passwords on SSH.
It's weird to have all that cryptographic capability and secure it with 12345.
Re: (Score:2)
You're certainly not supposed to use passwords on SSH. It's weird to have all that cryptographic capability and secure it with 12345.
That's the combination to my luggage.
Re: (Score:2)
Must be nice to have the extra security of a 5th digit. My combination is much less secure at 1234.
Re: (Score:2)
Correct horse staple battery.
Re: (Score:2)
The strength of a password is practically irrelevant if the attacker is just guessing and they only get a few tries to login. If the password was compromised elsewhere, then it doesn't matter if it is "poop" or "xXx_SOOPERP00P_XxX"
Re: (Score:2)
And if you don't use passwords, no person or program gets a chance to try to guess them.
Re: (Score:2)
>"There is one way to deal with and it has already very well-documented for decades: Don't use weak passwords."
Stronger passwords will *not* stop a brute-force attack on a machine allowing ssh in from the Internet. With fast speeds, lots of connections, and some time, something can be cracked. To prevent that, you need rate-limiting. This will deny the time needed and will likely protect even weak (but reasonable) passwords. I posted a simple example iptables script elsewhere on this article's comme
Found your problem... (Score:4, Funny)
...takes control of Linux-based internet-connected devices to...
Yup - found the stupid! - that's it right there^!
Re: (Score:2)
Re: (Score:3)
the tubes run faster if you warm them up a little bit
Re: (Score:1)
The acceptable shade of toast is actually controlled by DEI and ESG rules that are constantly changing. Hence the requirement to parse that information from the internet.
You don't want to get called a racist for eating the wrong shade of toast do you?
Finally (Score:4, Funny)
Finally we Linux users are starting to achieve parity with Windows users in the hotly-contested "malware target" market!
Re: (Score:2)
Re: (Score:2)
I thought most datacenter attacks use (Score:1)
...unseen malware. Otherwise, detectors would have caught them earlier. And it's not entirely "new", as the TFA points out it's based on the Mirai line.
Antivirus? (Score:2)
That's because of things like that that I think I would feel more safe if I had more options if anti-malware programs in my Linux machines.
Re: Antivirus? (Score:2)
Please, ignore "That's".
How to check if you're infected (Score:5, Informative)
Re: How to check if you're infected (Score:2)
Is this code for real? There are the words "pussy" and "mommy" in it
Re: How to check if you're infected (Score:5, Informative)
it seems like it is looking for magicPussy in crontab, /lib, and ps. And an ssh key for a server @mommy in your authorized_keys.
I think this script is legit.
Re: (Score:3)
Re: (Score:2)
Is this code for real? There are the words "pussy" and "mommy" in it
Well, it was written by a Linux user so...
(I kid, I kid)
If you're still using passwords with SSH (Score:3)
YOU'RE DOING IT WRONG! And I hate you for it, because you are part of the reason the logs are full of botnets making futile SSH password login attempts.
Re: (Score:1, Insightful)
Re: If you're still using passwords with SSH (Score:1)
Re: (Score:3)
run your sshd on a random high port then
Still gets attacked by brute force attempts.
Rate-limiting either connections or login attempts is required for any directly Internet accessible ssh server.
Re: If you're still using passwords with SSH (Score:1)
Re: (Score:2)
My logs say otherwise. I use a high port and it receives ssh brute force attempts.
Re: If you're still using passwords with SSH (Score:1)
Re: (Score:2)
..maybe it's a known port for some other service then
That would explain connection attempts, but not login attempts. But no, it's not a known port.
It's only in the past few years that this has been happening. Before that, using a high non-standard port stopped all or almost all ssh login attempts.
Re: (Score:3)
Nope. Using low-security passwords with SSH is a problem. With proper passwords, ssh-login with password is entirely fine. Stop spreading FUD.
Re: (Score:2)
Allowing ssh root login is not a bad practice at all. Not properly securing that login is.
Re: (Score:2)
I understand perfectly well what the situation is: A meaningless, faulty "security ritual", nothing else. If you secure it properly, there is absolutely nothing wrong with direct ssh to root. In fact, it is _more_ secure than going via user account. If you do not secure your logins properly, this intermediate step will not save you at all.
I am just wondering where this nonsense comes from. Probably a stupid attempt to emulate Windows "security".
Re: (Score:2)
Simple: User accounts are, in any sane set-up, less secured than root, simply because they are more exposed. For example because they are typically used frequently for work. The meaningless ritual of going via them lowers root security. This is so obvious I should not even have to explain it at all.
XMRig is malware? (Score:1)
Isn't that kind of like a "zero day" exploit? (Score:2)
Everybody wants to use "zero day" to describe every malware infection, even when it doesn't apply, because apparently calling it a "zero day" makes it seem more incredible or something.
But here, when it actually is a zero day, apparently they don't want to call it that!
Re: (Score:2)
This isn't a "zero day", or any other kind of an exploit.
It's just getting in with weak passwords.
Why is anyone using passwords on SSH? We stopped doing that a long time ago.
Re: (Score:2)
Previously unknown **self-replicating malware** has been infecting Linux devices worldwide
That's from the first line of the summary. I'd call that an exploit. And it was "previously unknown" making it a zero-day. It doesn't matter how stupid or simple the vulnerability is, just that there's an exploit and that it wasn't previously known.
Re: (Score:2)
There's no "previously unknown exploit" here. It's been known for many years that if you use a guessable password someone might guess it.
Re: (Score:2)
Was it known that these specific devices had weak passwords? Knowing about a class of weaknesses doesn't equate to being a "known vulnerability" for a specific device.
Re: (Score:2)
So you're referring to a password not chosen by a user? If that's what this is about, TFS didn't make it clear.
I didn't even consider IoT-type embedded devices. When I think SSH, I think of actual servers.
Well, if that's what's going on, it's still silly to call weak default passwords a "zero day".
Re: (Score:2)
Weak passwords logins into regular accounts are not even a software or system vulnerability, much less "zero day". These are a pure "user/sysadmin is an idiot" vulnerability.
Re: (Score:2)
For a zero-day to qualify as such, it doesn't have to attack a strong defense. It just has to be "previously unknown" and an exploit (malware).
Re: (Score:2)
A zero day has to be a software or system vulnerability. This is not. As to "previously unknown", this is not. Seriously.
This is in no way, form or shape a "zero day". Deal with it.
Re: (Score:2)
I'd say that a system that *allows* weak or default passwords, is a system vulnerability.
And I don't really care if it qualifies as "zero day"--the phrase doesn't actually mean anything anyway. And that's kind of the point.
marketing (Score:2)
These attacks need better marketing. I mean security researchers have been using catchy names and making logos for their big discoveries for a while, heartbleed comes to mind for me.
I'm dubbing this one Big Worm. It has a face and a crypto mining relevant slogan (Playing with my money is like playing with my emotions):
https://i.etsystatic.com/25705... [etsystatic.com]
And slashdot reacts like this (What up big perm!):
https://i.pinimg.com/originals... [pinimg.com]
You worm writers need to get with it.
https://i.pinimg.com/originals... [pinimg.com]
NOVICE. (Score:2)
Re: (Score:2)
If your password is something stupid like, "password", "god", or "sex", then definitely yes. This is not a software vulnerability. This is a weak password vulnerability.
Re: (Score:2)
If I had a list of 10,000 most used passwords, even if not all of them are obviously weak, it's a short enough list to manage a useful attack. For example, I could send out bots to try it on 10 million systems in a day and probably get a hit or two. I think the scale is sufficient to warrant some caution with leaving services like SSH open to password guessing.
My advice is when provisioning systems that part of that provisioning process include installation of SSH keys in the administrator accounts and do n
Re: (Score:2)
Don't you have to enable sshd? I haven't had a need to remotely log onto my computer, so assume things like sshd are not running.
Re: (Score:2)
Depends on the installer. A sane installer will ask you for passwords during the installation process and tell you that these accounts will be remotely reachable so you should select a good one. "SSH off" is not very common anymore as default, since many Linux systems run in VMs, where ssh is the only way to get in after installation.
AI? (Score:2)
Re: (Score:2)
Yes, but you'd probably get a lot of false positives and false negatives.
Re: (Score:2)
Not usefully. You need to have very high accuracy for anything like that to be useful. LLMs cannot do "very high accuracy".
SSH can require both a key and a password (Score:2)
Many large networks have been compromised after something has obtained user level access and used that users keys to hit other systems. SSH can be configured to require both a key and a password and so far the malware hasn't been able to break that combo yet. Note that is not the same as putting a password on the key.
Re: (Score:2)
This malware does not even crack reasonable passwords...
"weak passwords connecting SSH" (Score:2)
Nobody in their right mind has those, much less on an internet-connected system. Gross negligence at work. Anybody claiming to be a "victim" here did it to themselves and should be liable for all damage caused. They can then try to sue the criminals to get that money back...