Microsoft Warns of 'Stealthy DDoS Malware' Targeting Linux Devices (zdnet.com) 76
"In the last six months, we observed a 254% increase in activity from a Linux trojan called XorDdos," writes the Microsoft 365 Defender Research Team. It's a trojan combining denial-of-service functionality with XOR-based encryption for communication.
Microsoft calls it part of "the trend of malware increasingly targeting Linux-based operating systems, which are commonly deployed on cloud infrastructures and Internet of Things devices." And ZDNet describes the trojan "one of the most active Linux-based malware families of 2021, according to Crowdstrike." XorDdos conducts automated password-guessing attacks across thousands of Linux servers to find matching admin credentials used on Secure Shell (SSH) servers... Once credentials are gained, the botnet uses root privileges to install itself on a Linux device and uses XOR-based encryption to communicate with the attacker's command and control infrastructure.
While DDoS attacks are a serious threat to system availability and are growing in size each year, Microsoft is worried about other capabilities of these botnets. "We found that devices first infected with XorDdos were later infected with additional malware such as the Tsunami backdoor, which further deploys the XMRig coin miner," Microsoft notes... Microsoft didn't see XorDdos directly installing and distributing the Tsunami backdoor, but its researchers think XorDdos is used as a vector for follow-on malicious activities...
XorDdoS can perform multiple DDoS attack techniques, including SYN flood attacks, DNS attacks, and ACK flood attacks.
Microsoft's team warns that the trojan's evasion capabilities "include obfuscating the malware's activities, evading rule-based detection mechanisms and hash-based malicious file lookup, as well as using anti-forensic techniques to break process tree-based analysis.
"We observed in recent campaigns that XorDdos hides malicious activities from analysis by overwriting sensitive files with a null byte. It also includes various persistence mechanisms to support different Linux distributions."
Microsoft calls it part of "the trend of malware increasingly targeting Linux-based operating systems, which are commonly deployed on cloud infrastructures and Internet of Things devices." And ZDNet describes the trojan "one of the most active Linux-based malware families of 2021, according to Crowdstrike." XorDdos conducts automated password-guessing attacks across thousands of Linux servers to find matching admin credentials used on Secure Shell (SSH) servers... Once credentials are gained, the botnet uses root privileges to install itself on a Linux device and uses XOR-based encryption to communicate with the attacker's command and control infrastructure.
While DDoS attacks are a serious threat to system availability and are growing in size each year, Microsoft is worried about other capabilities of these botnets. "We found that devices first infected with XorDdos were later infected with additional malware such as the Tsunami backdoor, which further deploys the XMRig coin miner," Microsoft notes... Microsoft didn't see XorDdos directly installing and distributing the Tsunami backdoor, but its researchers think XorDdos is used as a vector for follow-on malicious activities...
XorDdoS can perform multiple DDoS attack techniques, including SYN flood attacks, DNS attacks, and ACK flood attacks.
Microsoft's team warns that the trojan's evasion capabilities "include obfuscating the malware's activities, evading rule-based detection mechanisms and hash-based malicious file lookup, as well as using anti-forensic techniques to break process tree-based analysis.
"We observed in recent campaigns that XorDdos hides malicious activities from analysis by overwriting sensitive files with a null byte. It also includes various persistence mechanisms to support different Linux distributions."
Re: (Score:3)
This is actually what happens when people don't use sufficient protection.
You shouldn't today expose anything directly to the internet you don't have to, even if it is encrypted. Every popular device supports multiple VPN strategies, usually including IPSEC. iOS 5.1 and later and Android since approximately forever both include IPSEC support, for example.
Re: (Score:2)
WireGuard is also a good vpn option for remote access administration-- easy to set up and clients pretty universally available.
Re: Password guessing for the win (Score:3)
Re: (Score:2)
But VPN still connects you to the internet, it's only an extra hub between you and the rest, it's not a firewall or something like that.
A hub doesn't do VPN. A hub just connects signals together. If it's "smart" it might collect some statistics, or let you disable traffic on some ports.
You don't need any additional hardware, you can do the VPN on the device itself, and still increase security. The point is to require more credentials to connect, preferably in the form of a certificate.
You could also improve security without even adding a VPN, by simply using ssh better. For example, you could enable 2FA with ssh by requiring both cert and p
Re: Password guessing for the win (Score:2)
Re: (Score:2)
It really depends. That VPN increases system complexity and may extend the attack surface. Sure, everything exposed to the internet needs to be hardened somewhat and needs good log-in credentials, but that is it. The attack from the article is possible because many people have horribly bad root passwords. I recommend googling "low intensity zombies" some time.
Re: (Score:3)
SSH has supported only allowing root with public key authentication for many many years now. Password guessing is way too common to allow root access with a password.
Re: Password guessing for the win (Score:2)
This is what happens when you hire Windows "admins".
Re: (Score:2)
Re: (Score:1)
Microsoft embraced the Subsystem For Linux (basically, can run Linux software) - not a surprise. This is a Trojan requiring human stupidity to open it. Probably will beat COVID by 20-30x. I have zero faith in the Trump era and I'm not even liberal.
Why it just block root login? (Score:4, Interesting)
Re:Why it just block root login? (Score:5, Insightful)
Re:Why it just block root login? (Score:5, Insightful)
Re: (Score:3)
Original poster is right. Use strong key and passphrase and disable password authentication. Sure you can use a sudo access, but if the person breaks in as that user, how does that help you? Granted, the name might not be known but if you've posted anywhere it might be easy to guess as well if someone was determined.
Even better, is to limit via firewall the list of IPs that can connect to SSH even with a valid key and passphrase. At that point, root would seem to be just as safe. Then ban anything trying t
Re:Why it just block root login? (Score:4, Insightful)
1) You can't enforce strong passphrase at the ssh server level for private keys.
1a) A private key is private to a given user.
1b) The user only sends its public key to the server admins in order to be able to login.
1c) Public keys have no passphrase.
1d) In order to be really private, the user himself must create his private key with no help at all from the ssh server or ssh server admins. Otherwise, it's not a private key.
1e) A user can easily create his private key with no passphrase at all, simply type enter twice when using ssh-keygen locally on the user computer to create your private key.
2) Just a side note for parent, GP and GGP as well, most if not all Linux Distros I have installed lately don't allow root password login by default.
Re: (Score:2)
There are quite a few ways you can change how SSH functions in the config file. You can lock things down enough to where only specific devices with specific ip addresses can connect to your ssh.
You can also add a passphrase on top of the keys. The attacker would have to take over a white-listed device and then guess the password. At this point, if you setup no root login, they will have to then find another exploit to get root access.
Not saying it is not possible, but that's a whole lot more work then just
Re: (Score:2)
A private key with no password at all is at least an order of magnitude more secure than allowing passwords for root login.
Re: (Score:2)
To your second point you are correct, however it is worth noting that sshd still defaults to allow login as root by default and it needs to be disabled in the config file.
Why this is still a thing in 2022 I don't know. But thank your distributions for their diligence in the wake of silly defaults.
Re: (Score:2)
That can be a good option. In other cases, not even that. They can use su - and the root password after logging in as themselves.
Re: (Score:2)
Re: (Score:2)
What I'm saying is that if you don't set up sudo, they must guess a user name, guess a password, then in order to get where they want to be, they must then guess yet another password and they must do so actually logged in where they will (should) be more closely monitored and cannot distribute the attack to make it less obvious.
If you really want to ruin the bad guy's day, ban all use of passwords for logging in to the server.
Re: (Score:2)
Re: (Score:2)
You still have the option to log in using public key.
Re: (Score:1)
No one *needs* remote root. Ever. That's just not a thing.
Re: (Score:2)
I regularly use ssh keys with no passphrase at all for the backup server to pull backups from servers as root with rsync.
Proxmox virtual Environment server does exactly the same so cluster members can communicate between them and many other software does exactly the same, it isn't uncommon at all.
You should be using a read-only backup user (Score:2)
You have an application that needs read access. You're giving it root access.
> it isn't uncommon at all
2.6 million people admitted they smoke meth. So doing meth is even more common. That doesn't make it a good idea.
To clarify, the company dies (Score:2)
To clarify, the way you have it set up right now, when a bad guy with ransomware gets access to the backup server, they can wipe out BOTH the backups and the production servers. The entire company is gone, overnight.
Contrast with using a proper backup account, which has read-only access. Getting control of the backup servers would allow the bad guys to delete the backups, but not damage production.
I prefer to avoid situations that involve complete and absolute destruction of the company.
Re: (Score:2)
It seems a lot of people don't seem to understand my statement either. And you're 100% correct. Which was my point as well.
Thanks. :D
Re: (Score:1)
Wrong, plenty of advanced use cases. Gaining access via "regular" user who has sudo is just as bad anyway, and besides once on box as regular user there is enough damage that can be done to take over machine for nefarious purposes that don't even need root.
If you let someone log in you've lost anyway, root or not
Re: (Score:2)
How tf are you going to use any VPS service ever then?
Re: (Score:2)
If you need remote login functionality in the first place, that is, and can't just disable sshd, there is a configuration option to disable root logins, and it seems to me that would probably be enough to stop this particular threat, if it is trying to access your machine that way. I discovered this option for myself by serendipity one day a number of years ago now. Why it does not seem to be the typical out of box configuration setting for sshd in all distros is beyond me.
If IoT devices are vulnerable, how may users know what IoT is, much less what OS is used and how to configure it?
And how many manufacturers obfuscate how to access configuration settings so to limit tech support calls/returns?
Re: (Score:2)
Unless you disable the root account itself, not allowing remote root-logins does not make you more secure. It makes you less secure, because suddenly you either need sudo (a low-security option at the best of times) or local root login, which is not much better. I have no idea why this myth that you should not use remote root logins persists and I have yet to hear any reasonable explanation for it.
Re: (Score:3)
The only argument against allowing direct root SSH access is that forcing people to log in as themselves and then become root can help with auditing, assuming you log whoever invokes root access (and log it to a different machine.)
Re: (Score:2)
The only argument against allowing direct root SSH access is that forcing people to log in as themselves and then become root can help with auditing, assuming you log whoever invokes root access (and log it to a different machine.)
Indeed. In an environment where you want to be able to audit root users, that is a possible approach. Does not work too well though.
Re: (Score:2)
People still use password auth for SSH?? (Score:2)
Nobody should be using password authentication for SSH. We've had public-key auth since the beginning; use that, along with a strong passphrase on your private key.
Also, "Xor-based encryption"? Uh... no. XORing against a fixed string is at most obfuscation, not encryption.
Re: People still use password auth for SSH?? (Score:2)
Re: (Score:2)
"Xor-based encryption" doesn't imply the use of a fixed string. It could refer to any PRNG, even a legit stream cipher.
I don't know anything about the malware and I don't RTFA.
Re: (Score:2)
TFA indicated XORing with a fixed string. Next time RTFA.
Re: (Score:2)
And why not? There are people that can use passwords competently. There is absolutely no reason for them to not use password authentication for ssh. Incidentally, passphrases on private keys do not help a lot, one of the reasons I do not use them. All they do is require a attacker that has compromised your system to wait for you to do one log-in and then they have that "good" passphrase as well.
Re: (Score:2)
Yes, I agree the password auth is OK if people can't change their own passwords to something weak and they have to use randomly-generated long passwords generated from a secure random number generator. In practice, nobody does that.
Your keyboard-sniffing attack against an SSH key passphrase is equally effective against password auth; public-key auth does not protect against that particular attack. However, the malware's attack isn't this kind of attack. It's a brute-force password-guessing attack which
Re: (Score:2)
Yes, I agree the password auth is OK if people can't change their own passwords to something weak and they have to use randomly-generated long passwords generated from a secure random number generator. In practice, nobody does that.
Actually, this is done in practice, but only if people know what they are doing and high security is a requirement. Since people that know what they are doing are rare in the IT space, I can understand that you have never seen this though. I have. I do it myself. Also, a physically secure environment (give the expected attacker model) makes this a lot easier because you can write down passwords. (A not physically secure environments allows things like cameras pointed on keyboards and is a whole different ga
Re: (Score:2)
Nobody should be using password authentication for SSH.
Many organizations use RADIUS-based password authentication for SSH access on the grounds that it is far easier to administer than public key authentication when you have large numbers of users accessing the target system from different locations, and users joining and leaving the organization all the time.
Oh Micro$oft.. (Score:1)
People who live in glass houses and all that.
Re:Oh Micro$oft.. (Score:5, Informative)
Encourage the use of Microsoft Edge -- vailable on Linux
That quote from the article makes me very supicious about this article. It is very lite on platforms or architecture, all it seems to say is "Linux is bad mkay"
I cannot help but wonder if this is limited to Azure or WSL. Who even runs Defender on their Linux System when better options exist ?
Re: (Score:2)
Who even runs Defender on their Linux System when better options exist ?
But do they? The reality is these days AV vendors have shat in the bed so long without cleaning it up that it's not a given that "better options exist".
But really the reality is that Linux isn't some magical perfect thing and sadly yes "Linux bad mkay" is a good way of describing the fact that now in 2022 sshd still defaults to permitting password based logins as root even at a time when large parts of the Linux world are trending towards disabling the root account entirely.
SSH password authentication (Score:2)
'nuff said.
Re: (Score:2)
No. You completely missed the problem. SSH password authentication works fine. As any password authentication, it is only secure with a good password that gets used nowhere else. The problem here is people using bad passwords on their root accounts.
Re: (Score:2)
I did not miss anything: disable SSH password login and the problem you describe goes away.
Re: (Score:2)
I did not miss anything: disable SSH password login and the problem you describe goes away.
You never said "disable" in your original post you walking example of dementia.
Re: (Score:1)
'nuff said.
Not really. I worked at a high profile Government agency and none of my Solaris/Irix/Linux machines were ever penetrated. Windows machines were regularly penetrated. Then they wanted to go to paid monitoring with HP tools. Pointy haired boss types. So in 2019 a pen team finally managed to breach a Linux system. The way they did it was to compromise the Windows domain first, which they did in about 20 minutes from an office off premises and in another state. The only connection via internet. They kept on goi
find matching admin credentials...on SSH servers (Score:2)
Huh!, "allow root access" (Score:2)
Re: (Score:2)
It's a supercomputer-class high performance parallel file system (meaning something designed to run on hardware that costs multiple millions per rack, that starts at around 10-20GBps throughput). But the ESS (extreme scale storage) software suite that drives those banks of SSDs compares to a network filesystem in much the way an entire aircraft compares to a turbofan engine.
Besides high performance storage (the fastest single-threaded sequential IO I've ever seen... i
Re: (Score:2)
I've worked plenty with AIX, but not GPFS. Help me out - GPFS requires enabled password login for root? M$ has identified a brute-force password attack against systems which still allow password authentication for SSH. Surely, GPFS doesn't prevent the implementation of SSH keys, does it?
I'm genuinely asking. Let me reiterate - I've only barely even heard of GPFS.
Re: (Score:2)
Maybe it's terminology... GP said "root ssh login," which I see as covering both password and public key authentication.
A caveat... 100% ESS n
Re: (Score:2)
I do. I happen to be a security expert. There is no sane reason to not allow ssh root login and instead compromise system security by using sudo. (I do not use sudo.) It is one of the many irrational myths in the IT security space that you should not allow direct root login. Of course you need to use either a good password or certificate-based login, but that is it.
Re: (Score:2)
Re: (Score:2)
I completely disagree. Certificates have the problem that they are typically in place, i.e. directly usable by an attacker that compromises the account with the certificate. Passwords can be kept offline and even can be put in sealed envelopes, distributed over several users, etc., and are only present on the computer on actual access.
Re: (Score:2)
That's the wrong question. The question is who wouldn't disable it. Even now SSH remote logins as root is enabled by default unless disabled via the sshd config.
It's the dumbest example of something that should be opt in in the open source community but somehow still isn't.
Disable password logins except for local network (Score:1)
It's convenient to allow password-based logins from the local network but not from anywhere else. Not that you need to use passwords locally very often, but it's still a handy thing to have available when you do have a user for it when setting up new equipment and the like.
Use the Match Address function in sshd_config to do this.
I wrote up exact instructions here but Slashdot's Security Service (I never knew it had one, something to do with Cloudflare according to the page that came up) blocked me from pos
Re: (Score:2)
Absolutely not needed. Just use reasonable passwords.
Re: (Score:1)
I disagree.
A "hack resistant" twenty-character password made up of random letters and numbers isn't a reasonable thing to retype every time you set up a device and get to the point that you need log into the fileserver to copy a configuration file.
Disabling remote passwords while allowing them on the local network avoids that headache.
Re: (Score:2)
Your math is borked. This is an ssh-login and the only thing an attacker can do is trial-logins. You are secure against that at significantly shorter and less complex passwords. This attack is possible because the machines attacked use pathetic passwords.
XOR based encryption? WTF? (Score:2)
Do they mean a stream cipher?
Re: (Score:1)
Re: (Score:2)
AES and Blowfish do not "give off" signatures at all. They cannot, just like all other block ciphers. That is a direct consequence from input block size being the same as output block size. All that can happen with block ciphers is that patterns from the plaintext leak through. Are you talking about headers or the like? Vigenère encryption (which I gather is this "alternative") leaks patterns from the input like crazy though.
Re: (Score:1)
WireGuard works well for this (Score:2)
I used to use OpenVPN for remote connections on TCP port 443. I thought it was clever since it looked like HTTPS traffic and would not be blocked by some random hotel's network connection when I traveled. However, I quickly learned that there are many bots that attempt to connect to TCP port 443. My OpenVPN server was cons
Re: (Score:2)
Exposing root in any fashion to the internet is probably the worst thing you can do. End of line.
If you must expose root, relying on password authentication is probably the worst thing you can do. End of line.
It's just like exposing, say, WIndows 7 Server to the internet. I give it ten, fifteen seconds tops before someone pwns it. There are plenty of actors doing nothing but nmap'ing everything they can see in IPv4 space.
...says the MS engineers that developed the trojan (Score:1)
Do ya think?