Slashdot Mirror
New Mayhem Malware Targets Linux and UNIX-Like Servers
Bismillah writes: Russian security researchers have spotted a new malware named Mayhem that has spread to 1,400 or so Linux and FreeBSD servers around the world, and continues to look for new machines to infect. And, it doesn't need root to operate. "The malware can have different functionality depending on the type of plug-in downloaded to it by the botmaster in control, and stashed away in a hidden file system on the compromised server. Some of the plug-ins provide brute force cracking of password functionality, while others crawl web pages to scrape information. According to the researchers, Mayhem appears to be the continuation of the Fort Disco brute-force password cracking attack campaign that began in May 2013."
The code snippets have too many colors which in my opinion make them hard to read. What do you think?
For those who don't read articles, this appears to happen if you don't auto-update your software and are running php. Not to many details on what versions of software they are using, but it may be a time for a sudo apt-get upgrade.
or
And for each of those, they present some example contents that could be used to verify it is part of this infection.
It's difficult to rate-limit login attempts from a botnet. The attack pattern I see on my server is one IP making three login attempts, then another IP making three login attempts, and so on. I do rate limit (via temporary IP blocking) attempts from one IP, but it doesn't help much. Of course, they're all doing password-based login attempts and I disable password-based SSH logins for all Internet-connected machines...
I am TheRaven on Soylent News
If the attacker gains access to any kind of database of password hashes, he can just compute thousands of attempts per second.
Likewise, log-in rate limiting is problematic. Windows does stupid shit like lock the local console if you set up rate-limit log-in...when logging in through the Microsoft log-in manager. That's retarded. A person is sitting at that console, and can't enter passwords fast enough; it should NEVER BE LOCKED. By contrast, any network log-in (RDP, FTP, ssh, etc.) should lock for 60 seconds after 20 failed attempts in 60 seconds, not counting console log-ins.
This does pose an additional small problem: if your system is compromised by malware, a no-local-login-locking policy will allow infinite, concurrent, constant log-ins. If you rate limit it to 20 per 60 seconds, the malware can prevent local users from logging in. If the malware has a local user's access but has locked out the administrator, the admin can't log in and remove the malware; you now need to power cycle what may be a production server.
You can get around this somewhat by attaching the log-in rate limit to the terminal. That means you need rules that decide context (network, local); then, for some contexts (local), account per terminal (tty1, tty2, pts/0, etc.).
Nobody's done that yet.
Support my political activism on Patreon.
I was going to release an RFC several years back that detailed malware communications protocols, but it was out-of-scope for an RFC and I figured it would be bad when people started using it. Plus IETF might not take that as an April 1 RFC.
I had suggested that the malware be modular, and that it have a communications protocol using PKI, and an evolutionary module loading framework. It would take code for modules shipped across the network and try to compile them locally for various systems, then ship the binaries around. It would also divide when it got a new module: a kill module would just kill the weak strain. The proposal included detecting remote OS and shipping the correct primary executable code, as well as support code for cross-infection.
The whole thing was a big argument for why we need a non-executable stack and strict rules preventing in-memory transitions between non-executable and executable pages. Data written in memory should never become code. Of course, people want to use JIT compilers, so...
Modern malware still bores me.
Support my political activism on Patreon.
If you never travel outside your country, why not block all networks from outside? Back in my AT&T days I blocked all of south america, europe, and asia for our servers because nobody from those locations had any reason to even contact our advertising data collection systems. There is no reason to keep your servers wide open for the world.
Do not look at laser with remaining good eye.
Most of what we see in the wild is caused by improperly written PHP scripts which don't validate their input and then use crud like fopen_url. That provides the crackers the METHOD to put files on the server and execute them. SuExec gives web visitors PERMISSION to ad and modify files.
Unfortunately, the folks at Plesk didn't read the first paragraph of the SuExec documentation before deploying it by default, so hundreds of thousands of DIY web servers are running with SuExec. (SuExec means allow visitors to modify files, but don't allow other clients hosted on the same shared server to do so).
What the Plesk and DirectAdmin folks should have read, from the Apache SuExec page:
-----
Used properly, this feature can reduce considerably the security risks involved with allowing users to develop and run
private CGI or SSI programs. However, if suEXEC is improperly configured, it can cause any number of problems and
possibly create new holes in your computer's security. If you aren't familiar with managing setuid root programs and the
security issues they present, we highly recommend that you not consider using suEXEC.
-----
That last sentence bears repeatings. "If you aren't familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC." Plesk, and DirectAdmin - your customers are not familiar with managing setuid programs and the security issue, so they should not even CONSIDER running suexec, much less have that foisted on them as the default.
So lock the account?
Seems clever. DoS successfull.
Notabene: All through the 90s and some years later, you could lock customers of Deutsche Telekom out of their Internet access until midnight, if you knew their telephone number.
Internet login was derived from the phone number, accounts were locked after 10 failed passwords until midnight.
There's a very simple and very easy solution for it: One password attempt every 2 seconds. 2 seconds is pretty much what an average human needs to type his password (of course, he needs to be allowed to type while he waits). Of course that limitation begins with the first login attempt. There is exactly zero reason to allow three attempts within a split second and then disallow for a minute or so if your potential attacker is a script. Quite the opposite, two login attempts within a second should automatically lead to a ban, no matter whether one of the passwords was correct, because that pretty much PROVES that it's an automated script trying to log in.
Hence my login procedure still listens after you entered your credentials. If you try again before getting an answer (something NO human being, and no sensible script either, would do), you pretty much proved you're an attacker and you don't get in. From the same or a different IP address doesn't matter, because, again, NOBODY "honest" would come from two places at once. It may lead to a DoS, of course, when someone tries to hack account A from various sources while the genuine user of account A tries to log in, but the game "confidentiality vs availability" can be played ad infinitum.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
"A lack of anti virus, and missing auto update features leave machines vulnerable"
It astounds me the lengths the article writers go too while avoiding the attack vector:
The admin must:
1. allow a method to upload files
2. allow php files to be up loaded
3. Allow execution of these uploaded scripts
4. Allow system / exec calls (disabled by default since forever ago)
5. Allow the user to write their own crontab
At that point, you might as well just install the infection through yum or apt.
Seriously, there's a reason that the article numbers are less than 1% of the size of the average windows server infection..
So, all I need to do to block off legitimate access is fire off a single connection (per user I want to block) every 30 seconds...
I could have a daemon doing that without noticably slowing down my regular internet traffic on my home DSL.
Hey, if you want to nitpick, I can reassure you that nearly no infections in the past years on Windows machines were due to a faulty kernel. It was some GDI problem, or a driver issue, something about Internet Explorer or Silverlight... and for a while the big thing was attacking systems by abusing bugs in common third party products like Flash or Acrobat Reader.
By your definition, I dare say that Windows ain't much easier to hijack than Linux.
The sad point is that both systems are not really airtight. Maybe waterproof by now, but I wouldn't use either on my space suit, so to speak. I even have to say that the biggest blunder recently has been in a piece of OSS, I bet heartbleed needs no explanation.
Sadly, the main reason why Windows gets all the attention from malware is plain and simple profit. It's more profitable to target Windows machines. Not only are Windows machines far more numerous than Linux boxes, the average Windows box also has the inferior "admin" with less information about security who is more likely to fall for the Dancing Pigs. That's the main reason for malware being more of a Windows phenomenon than one on Linux.
Profit.
The current big thing is holding your stuff for ransom. I.e. going through your files, encrypting them with a 4096 bit key and wanting money from you in exchange for the private key belonging to it (something, btw, that needs no elevated privileges at all, i.e. would work like a charm in Linux, too, provided you can execute a program from user file space, which you easily can in the average home user Windows because you need at least Windows Professional to set Local file permissions... Well, security costs extra with MS...).
How many Linux users would pay? And how many would show the extortionist a digital four with their fingers and restore the recent backup (because, unlike most Windows users, they have one)?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
I use fail2ban and RSA keys as my primary login mechanism... but I also use the RFC 6238 TOTP tokens (Google Authenticator code available from git, or just fetch it from EPEL if on RedHat or a downstream distro like CentOS. For an app, one can use RedHat's FreeOTP, Google's app, Amazon's, or a slew of others.)
This isn't 100%, but two factor authentication should be the minimum standard for Internet communication these days.
After that, what may or may not help is the push to run everything in containers (think domains in Solaris, or WPARs in AIX.) Docker seems to have a lot of enterprise support, and it is relatively new, and that would put another layer of security in place.
This isn't to say malware can misbehave in a container. In fact, malware running in the user context on Windows can do a lot of mayhem. However, containers provide better defense in depth, same with SELinux.
This virus doesn't attack Linux at all. It attacks PHP web applications. They could run on Linux or any other OS. The brute forcing is what the botnet does once it has a foothold on the machine in question, and has nothing to do with the attack vector.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Surely you must be joking. There have been Explorer bugs that went unpatched for six months. No operating system is immune and security flaws arising from bugs in code are an inevitable accompaniment to having code in the first place, especially complex code with lots of moving parts (some of them infrequently tested/visited), but Microsoft has historically been Macrosquishy when it comes to security and patches. LOTS of holes, and many of them (in the historical past) have taken a truly absurd amount of time to be patched, resulting in truly monumental penetration of trojans and viruses via superrating wounds like Outlook. I still get an average of one email message a day that makes it through my filters purporting to be from a correctly named friend or a relative and encouraging me to click on a misspelled link. You think those messages are arising from successful data-scraping via Linux malware or Apple malware or FreeBSD malware?
Perhaps, driven by the need to actually compete with Apple and Linux (including Android) instead of resting on their monopolistic laurels, they have cleaned up their act somewhat over the last few releases of Windows, but on average over the last 10 or 15 years, certainly since the widespread adoption of apt and yum to auto-maintain Linux, the mean lifetime of a security hole in a Linux based system all the way out to user desktops has been around 24 hours -- a few hours to patch it and push it to the master distro servers, mirror it, and pull it with the next update. Microsoft hasn't even been able to acknowledge that a bug exists on that kind of time frame, let alone find the problem in the code, fix it, test it, and push it.
If they are doing better now, good for them! However, look at the relative penetration of malware even today. Linux malware has a very hard time getting any sort of traction. Apple malware has a very hard time getting any sort of traction. Windows? It's all too easy to whine that it gets penetrated all the time because it is so popular and ubiquitous, except that nowadays it is neither.
rgb
Even when the experts all agree, they may well be mistaken. --- Bertrand Russell.
its PHP that's the problem not linux so i guess it could also affect other systems such as Windows
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
No need to block entire countries - just allow SSH access to those systems that need it.
Now, if you want to talk about blocking access to your web or mail server from anyone in East Elbonia, then you can implement a package like Country Block, or use a service like this one, depending on your firewall.
The lesson from this? Restrict access to important services via a whitelist, block access to public services with a deny list.
How come Slashdot never gets Slashdotted?
Start your security process by not using port 22 for ssh, and instead using some random, legal 5-digit port number. Then block IPs from anyone doing a port scan. Also, setup port-knocking prior to any authorized user even starting to login using ssh. Of course certificates should only be used, not passwords for authorization. That should go a long way to keep the bad guys out.
Also bots tend to have the same user-agent strings, which tend to be obscure in and amongst themselves. These obscure, identifying user-agents can also be blocked, once identified.
To read and actually make sense of machine logs, the free ELK Stack rocks! Here's a guide to setup your own machine, for the purpose of reading logs in a very user-friendly way.
You can't be ahead of the curve, if you're stuck in a loop.
That is why I did the insert after it got the date/time of last login. So if you get a slew of login attempts in the time frame it just kicks them off.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Well, I cut down from ~50 SSH login attempts per minute some days to basically ... looks up the logs ... four such attempts last month.
What I found: No matter how secure your lock is, when you have one, big, red, secure, lock on your stuff, which people know is active, people will try to pick it. On the other hand, when there is not one, big red, secure lock, but thousands of identical looking little, grey, secure locks, and the attacker would first have to try every one of them to see which is even active, then 99.999% of the script kiddies don't bother long enough to even find the lock.
So I moved my SSH stuff to another port. Doesn't help against any "real" attacker, and doesn't really add any security, but it DOES cut down on the noise in the logs.