ESET Discovers 21 New Linux Malware Families (zdnet.com) 67
In a report published last week by cyber-security firm ESET, the company detailed 21 "new" Linux malware families. All operate in the same manner, as trojanized versions of the OpenSSH client. From a report: They are developed as second-stage tools to be deployed in more complex "botnet" schemes. Attackers would compromise a Linux system, usually a server, and then replace the legitimate OpenSSH installation with one of the trojanized versions.
Now that you know ... (Score:5, Interesting)
Is there anything about this that checking the digital signature of the OpenSSH files wouldn't work? That probably should be done at boot time and then periodically after that.
Re: (Score:2)
Bullshit. Digital signatures have no relation to normal signatures with regards to how difficult they are to fake. If done right, digital signatures are completely impossible to forge at this time. If done wrong (e.g. using MD5 or SHA1 as hash), they are still exceedingly hard to forge and only under special circumstances.
On most Linux distributions, that already happens. (Score:3, Insightful)
Or at least can happen, if you set it up.
On Linux, you usually have a package manager. Which keeps the checksums/signatures of every file it installed, so it can do its package managing job. It will complain, when you try to uninstall/reinstall the package, and things have changed behind its back. (Unless it’s a configuration/data file, of course.) /var/db/pkg and compare the info there to th
Want a regular check? Just use your package manager's helper tools in a cron script.
(On Gentoo, you could query
Re: (Score:2)
Also don't forget about tools like AIDE.
Re: (Score:1)
"Secure by default."
Re: (Score:2)
That would work. The classical approach to that is "tripwire". Also, just making sure your server is patched and you have good passwords does not let this malware in in the first place. From the article: "Unless Linux owners go out of their way to misconfigure their servers, for convenience's sake, they should be safe from most of these attacks."
Re: (Score:1, Informative)
To use any of this stuff you need to already be on the box and already be root. This ain't easy to do at all unless you have an idiot for a user that will run your dropper as root for you. Ain't nothing Linux can do about that.
Re: (Score:2)
No. Unlike OSes designed for morons like you, Linux does allow you to misconfigure everything as much as you like, because it assumes the system administrator actually knows his/her job.
How is it malware, if you compromise the server... (Score:4, Insightful)
How is it malware, if you have to compromise the server first??
If you manage to compromise a system, then you can just put anything in there. Duh.
Was this written by somebody from generation "i" again?
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
It is malware for the role of "backdoor". As such it does not server to do an initial system compromise, but serves to maintain system access after that. As it does really not have legitimate purposes besides that, it is "malware".
Re: (Score:2)
It's malware, but more commonly described as "a rootkit"...
Traditional malware gets itself executed by someone who isn't aware what they're executing, a rootkit is intentionally installed by someone who has already obtained privileged access.
Re:APK & hosts files to the rescue (again)... (Score:5, Informative)
1 botnet used IP address ONLY (unusual as ICANN sinkholes those fast & I've seen an 'uptick' in it lately - perhaps hosts IS making a 'dent' in 'badguys': For that - you need a firewall block rule OR wait out ICANN).
No, you can easily block individual addresses through the routing table.
ip route add prohibit N.N.N.N
This works with networks too, like:
ip route add prohibit 185.224.136.0/23
If you have all of the nasties in a file, you can do something like this at startup, in an rc.local file or similar:
xargs -r -n1 </etc/ipblocklist ip route add prohibit
Also, while I have you here, many modern distros default to prefer DNS over /etc/hosts and only use /etc/hosts as a fallback, in which case your /etc/hosts list will not have any effect unless /etc/nsswitch.conf is modified.
Example line in /etc/nsswitch.conf that will not work: /etc/nsswitch.conf that will work:
hosts: dns [!UNAVAIL=return] files
Example line in
hosts: files dns
Article Summary (Score:5, Insightful)
Unless Linux owners go out of their way to misconfigure their servers, for convenience's sake, they should be safe from most of these attacks.
Re: (Score:2)
And that is just it. Linux allows people to shoot themselves in the foot as much as they like. It even makes it easy. But unless you actually do it, you are pretty secure. And in addition, sometimes insecure configurations can have a legitimate purpose, hence they are allowed.
Re: (Score:2)
Go away impostor. You are not APK and you are pathetic.
Stupid (Score:2)
Re: (Score:3)
Could go the Windows route and deem certain files critical to the system (ie - only trusted publishers are allowed to update the OS files), but then you'd have to have a list of publishers (based on certs) allowed to update the system. I don't think it's an entirely bad idea.
Re:Stupid (Score:5, Informative)
Furthermore, you could require that the binaries are delivered in collections called "packages" and have the system require a valid signature and only recognize some signatures. Then you could have a distributed system for providing downloads of the signed packages. As long as the signature is valid, it doesn't matter what the source is.
Oh, wait, every major Linux distribution has done this since almost forever, probably before Windows installers were signed.
Re: (Score:3)
SLS was doing this in 1992, Slackware had a better system in 1993, and both Debian and RedHat came out with decent package managers that used PGP/gpg signatures in 1994.
Modern packaging systems do remember the hash of the files. A "rpm -Va" can easily point out changed binaries, and there are dedicated utilities like Tripwire and AIDE which do better.
Re: (Score:2)
Linux doesn't really support on boot hardware crypto does it? All my Linux admins always tell me to turn that stuff off before they install anything :(.
But your right - this whole virus scare is as silly as that whitepaper on how to exploit wsus - which was posted on slashdot as well - and step 1 was turn off ssl... (which by default is on).
Re: (Score:1)
Re: (Score:2)
There are good security researchers out there. These just only rarely get the spotlight because the morons (like the ones here) make everything sound sensational and the press just loves that. The story does not seem to have any content beyond "there are trojaned OpenSSH versions around". Nobody with an actual clue about security cares as that is not a surprise at all.
Instant water (Score:2)
Linux malware is a misnomer (Score:1)
This is another example of how Slashdot hires fifth grade senior editors. OpenSSH is not part of the Linux kernel, so that calling it Linux malware is a misnomer. OpenSSH was developed by a private company in Helsinki, Finland. Let's just say that it is a fork of an old version of their product, and that it runs in user space. It is bundled with GNU/Linux distributions, as well as with Microsoft Windows.
Re: (Score:2)
Ahem, OpenSSH is an OpenBSD project?
"widely used" (Score:2)
compared to the more widely used Windows
Actually Linux is more widely used overall, windows is only ahead of linux on desktops/laptops. Total worldwide instances of the linux kernel are likely to massively outnumber windows.