New Mayhem Malware Targets Linux and UNIX-Like Servers 168
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."
How does one detect these things (Score:1)
Too bad TFA doesn't mention this.
Re: (Score:2)
http://en.wikipedia.org/wiki/C... [wikipedia.org]
Re: (Score:2)
Only as a last resort. AV software mostly excels at bringing a system to it's knees and making itself impossible to remove.
What is needed is to close the hole that let it in.
Meanwhile, most of the products in that list actually scan for Windows virueses!
Re: (Score:2)
You should read again. Where did I say ineffective?
Re: (Score:1)
Not only that there is no mention of a vulnerability that cases a machine to get infected in the first place. There's nothing in there about how to prevent, or detect this.
Re: (Score:3, Informative)
or
And for each of those, they present some example contents that could be used to verify it is part of this infection.
Re: (Score:2)
Sometimes I wonder if Linux should have functionality similar to AIX's trustchk.
This command on AIX can make a list (signed with an OpenSSL key), then either warn when something runs that isn't on that list, or block it entirely. Functionality can be turned on to watch libraries as well, so if a library was changed, execution stops or a syslog entry is generated. In fact, it can be locked down so a reboot into another OS instance would be required to modify the trustchk settings.
If someone has static scri
Re: (Score:2)
Tripwire/AIDE is passive. It can tell me if a binary is changed, but won't actively block a dropped script.
SELinux is great for assigning roles and denying execution in directories. However, it doesn't sign executables, nor keep a manifest in place.
AppArmor is similar to SELinux.
All of these are quite useful, but what would be an addition which would stop this type of Trojan cold would be something that checks an executable to see if it is on a manifest, checks its signature, then allows/denies/logs acces
Re: (Score:1)
Too bad TFA doesn't mention this.
SHA256 hashes are provided for all the code analyzed.
Re: (Score:2)
Re: (Score:2)
Or even "why" they use "quotes" on things.
Re: (Score:2)
"bascially, tt looks like what needs to be done is the PHP runtime needs to be tightned up."
Boy, you could put that on the PHP developers headstones.
From virusbtn (Score:2)
What do the plug ins offer?
Too many colors in syntax highlighting (Score:3)
Re: (Score:1)
Re: (Score:2)
Constant distractions on the internet have made it hard to concentrate for me too. Learning to multitask helped a bit though.
Re: (Score:2)
I still prefer grey-on-black and full screen. Easy on the eyes and easy to concentrate.
Re: (Score:2)
angry fruit salad [wiktionary.org]
Re: (Score:1)
Its not the Colors it is just PHP.
Re: (Score:1)
strings are yellow
variables are white
functions are blue
reserved words are pink
the background is black
It's not that there are too many colors, it's just not my color scheme of choice.
Re: (Score:2)
It does seem overdone there.
Re: (Score:2)
Update yo software (Score:3)
Re: (Score:3)
So it's like Windows?
Re: (Score:2)
It's like any system where abusing a known system weakness leads to profit.
For reference, see politics and lobbying.
Re: (Score:2)
For those who don't read articles, this appears to happen if you don't auto-update your software
So it's like Windows?
In the sense that both are made by man and imperfect, yes. In the sense that patches come rapidly, no.
Re:Update yo software (Score:5, Insightful)
And for those of you who DO auto-update blindly and destroy your app or your server when a bad version comes out, well, at least you can smugly assert that you were "secure".
Re: (Score:2)
No, you weren't. If that happens to you, your backup policy sure as hell was lacking!
Re: (Score:2)
Re: (Score:2)
Updates are scheduled in if they are needed.
They are always needed. Sometimes eventually, sometimes quickly, and sometimes right fucking now. But you can never just be OK with old versions for long.
Re: (Score:2)
But how does it get there? (Score:1)
The article seems to go in depth to the operation, commands, and purpose of the various shared libraries and scripts run by this malware, but it seems to skip out on the point of how these servers get infected in the first place....... Or maybe I skipped it - I was just perusing.
PHP suexec, mostly. Thanks Plesk (Score:5, Informative)
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.
Re: (Score:1)
It provides a way to put files on the system... IF and ONLY IF the system is not using mandatory access controls.
These attacks don't work then. Files can only be written to directories with permissions... and those permissions don't (or should not) include "execute". Thus the libraries are non-executable. The binaries dropped become non-executable... And they cannot access files/directories that do not have permissions for access by the web server... and can't drop files into directories that are not permit
That's very tricky with newer SuExec and not trans (Score:2)
It's very, very tricky (impossible?) to set that up right with the newer suckurity checks in recent version of SuExec, especially now that SELinux has removed *_disable_trans. Previously you could do it with httpd_suexec_disable_trans. Now mostly people resort to running Apache as a permissive context - effectively castrating the mandatory access controls in order to run soemthing that castrates the discretionary access controls (standard permissions).
Also, before the new checks were added, SuExec could be
/usr/bin/host ? (Score:2)
So this only works if you have /usr/bin/host installed?
Still old-school (Score:4, Insightful)
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.
Attack Vector (Score:5, Insightful)
"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..
Re: (Score:2)
Or, to put it another way, you can't fix stupid.
rgb
Re: (Score:2)
Re: (Score:2, Insightful)
Seriously, there's a reason that the article numbers are less than 1% of the size of the average windows server infection..
There are clearly many more Windows servers on the Internet than there are Linux servers. After all, if Linux had anywhere near the deployment of Windows, then Linux would experience the same rate of infection, right?
Right?
Re: (Score:1)
Who's that clip clopping over my bridge?
Might want to wait until there's a teensy bit more malware before safely being able to safely deploy this broadside :)
Re: (Score:1)
Re: (Score:1)
Same can be said for all the Windows malware, most of which targets flaws that have been fixed for years.
Re: (Score:3, Informative)
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 o
Re: (Score:2)
Re: (Score:3)
Re: (Score:1)
"Toy OS..." ...that runs most of the modern web and nearly every mobile device in your home.
Fscking idiot.
lrn to *nix.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Wow, Linux still doesn't rate-limit login attempts by default? What is this, 1985?
*goes back to my VMS box*
Re:Derp (Score:5, Informative)
Re: (Score:1)
different login attempts to the same account from different IPs continuously doesn't seem at all suspicious?
Re: (Score:2)
If that account is "root", it's pretty much normal these days on the internet...
Re: (Score:2)
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,
Re: (Score:2)
I agree. Fully. Absolutely. Sadly, that little secret very obviously didn't get out yet to everyone. There's still plenty of machines, and I don't just mean some "hey, look at me, I am such a geek, I can install Linux" idiot's machine, that actually allow root logins.
Re: (Score:2, Insightful)
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.
Re:Derp (Score:5, Insightful)
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.
Re: (Score:1)
I know:
But other that typing an IP in and seeing which one it says (which I could automate), but I would think that info is already somewhere...I just don't know where.
Re: (Score:3)
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 [pfsense.org], or use a service like this one [countryipblocks.net], 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.
Re: (Score:2)
Whitelisting with mobile admins (Score:2)
Limit access to SSH to systems on the whitelist.
How would one go about whitelisting a restaurant if an admin gets an urgent call and needs to log in ASAP?
Re: (Score:2)
Or you could run a virtual firewall (running an Open VPN client to your main firewall) and admin station inside your laptop and tunnel from your workstation to your firewall.
There are a ton of ways to do this depending on the time and options you have access to.
Re: (Score:2)
For Europe at least, you can get RIPE IP blocks from their web site or through their RIPEstat Text Service [ripe.net]. I use it for one of my servers to get daily lists for one country, and feed it to ipset [netfilter.org]. Maybe others like ARIN etc. also publish lists? Or you can get GeoIP databases. Or you could try a (Perl) module like IP::Country [cpan.org]?
Re: (Score:2)
It might be that if one uses a VPN, and a limited number of IP addresses, maybe just block everything except for those ranges, and the VPN (preferably a less known, but reliable provider, maybe even a static IP on a linode box) would allow one access if one wasn't on that range.
Of course, the attacks I see coming are often compromised Windows boxes on DSL or cable modem IP ranges, so blocking Elbonia directly may not help much. The best bang for buck is maybe blocking the obvious hotspots, then rate limiti
Re: (Score:2)
We used to also block all of AOL's ip pools as well as many of the large UNI address pools.
Re: (Score:1)
I think nowadays that one can assume that 1400 random infections (for the botnet in question) on the net would include most countries. Even more so for the larger botnets which exist. So my suspicion is that this tactic has limited utility, possibly so limited that it is no longer worthwhile ("Damn, I forgot to turn off the geoblocking before my unexpected trip to Peru!").
Re: (Score:2)
We had lots of trouble with WordPress bot-logins from Russia and Ukraine, so I decided to block those ip-ranges.
Turns out one such block was also partly being used by customers in my own country. I received some vague mails about some things not working correctly. So I removed that ip-block, and sent back some vague replies that it was a firewall that was too strict.
There might be other blocks listed as from Russia and Ukraine, that are actually being used elsewhere.
Anyway, with the advent of ipv6, the whol
Re: (Score:2)
Psuto-Code:
Select @LastTried = Max(LastTried) from LoginLog where LoginName = @LoginName
insert into LoginLog (now, @LoginName)
if @LastTried (now - 30 seconds) {
return error
} else {
return checkifpasswordiscorrect(@LoginName, @LoginPass)
}
Re: (Score:2, Insightful)
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.
Re: (Score:3)
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.
Re: (Score:2)
Pseudo. [reference.com]
Not to be confused with sudo [about.com]
Re: (Score:3)
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 (th
Re: (Score:3)
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 us
Re: (Score:2)
Isn't this normally a bad idea as a non-root account can listen on those non-reserved ports should yourprimary daemon die or get restarted?
Re: (Score:2)
Yes, you are right and I stand corrected. In fact late yesterday, I happened upon a blog post teaching me the same explanation you gave me just now:
Re: (Score:2)
Here's the link to the blog post, that didn't make it into my previous reply: https://www.adayinthelifeof.nl... [adayinthelifeof.nl]. It clarifies several reasons for using the standard port 22 for ssh.
Re: (Score:3)
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 6
Re: (Score:3)
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 automatica
Re: (Score:2)
And then every 2 seconds, the malware beats you to your password log-in attempt. You have a 2000mS period with a 5mS window, good job. I can keep all your staff sitting in their chairs not working all day with ssh and rdp.
Re: (Score:2)
This is essentially the one problem with the implementation, it facilitates a DoS attack.
As stated in the last paragraph, the choice is confidentiality or availability, depending on which trumps which, pick your poison.
Re: (Score:2)
It's never that simple. There's all kinds of stupid dogma in every industry; things like "confidentiality or availability" and "security or ease of use" are industry dogma.
Re: (Score:2)
What about just not allowing passwords to connect from a network? Is it too simple, or what?
It's simply stupid to prohibit robots from connecting. It means you'll never be able to automate your work. It's also not viable to lock the system, as it'll turn any bot anywhere into a severe DoS attak. And trying to discern intent from behaviour is way too hard a task for a computer.
Re: (Score:1)
You have limited imagination, what about an attack on a public computer via replacing its keyboard with one which includes a CPU + password cracking program?
So Windows isn't quite as retarded as you think; it's just retarded in that it doesn't rate-lim
Re: (Score:2)
That's called a movie plot security threat, and it's not a concern.
Aside from all the obvious shit like "how do you get in there unnoticed?" and "How does it know to start entering passwords?", you have the speed of the bus. Even without a 1-2 second turn-around for testing a password, keyboards can only enter 750 characters per second. That's less than 100 password attempts per second for 8 character passwords, or 10^12 seconds to try them all. 800,000 years!
In other words: console attack via keybo
Re: (Score:2)
BTW, the person who coined "movie plot security threat" doesn't exactly agree with you [schneier.com].
That's for keyloggers, not key entry. Typing is different than reading.
Where did this "750 characters per second" come from? Is this a limit built into Windows? USB 2.0 runs at 35 MB/s, according to Wikipedia.
There's this link [vetra.com] that references USB-HID specifically at 750 characters per second. I can't find other references to USB HID rates, and the HID protocol is semi-flexible (i.e. it's really fucking hard to implement NKRO on HID, since HID keyboard protocol specifies 6KRO in boot mode; but you're free to implement an alternate HID protocol once your keyboard's out of boot mode).
OTOH, comparing the "1-2 second turn-around" in your reply to the "750 characters per second" undercuts your original argument as a whole
1-2 second delay is an expected human-facing turn-aroun
Re: (Score:2)
your characterizing Windows as "retarded" for not distinguishing between 750 char/s and the much faster network, was illogical.
There are two parts to that.
The first part is that the network log-in source can be grouped as an infinite number of terminals--lots of connections--so a per-connection rate limit is useless; thus all network service log-in (caveat: Active Directory handles console log-ins... over network) must be grouped as one thing to be effective. Console log-ins are separate so that a network attack can't function as a DOS; as well, the risk is mitigated because you can't enter passwords fast enough for any use.
T
Re: (Score:2)
Re: (Score:2)
You see my point, though. Knowing your administrator log-ins isn't a never-happens situation. People get user lists all the time.
Re:Derp (Score:5, Informative)
Re: (Score:1)
Re:Infection via PHP web apps (Score:4, Interesting)
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 [wikipedia.org]. 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)?
Re: (Score:2)
Re: (Score:2)
If it's easier to hijack a million Windows boxes than to get a thousand Linux boxes, which one would you choose? Especially since the "juicier" a target gets, the better its defense will most likely be. Not only its technical ones, but also its legal ones.
What do you think is more profitable and less likely to result in a swat raid: Blackmailing a million people to pay you 200 each or blackmailing 200 high profile targets to pay you a million each?
Re: (Score:2)
The problem is that more people use Windows at home than Linux. This is why Windows is the largest "soft" target.
Linux at home is not immune. Why? Because home users are less likely to be careful about their security and more likely to download malware. They also tend to tolerate software operating slower than normal because they incorrectly associate it with the age of the computer.
Computers running at an enter
Re: (Score:2)
Just because Windows looks monolithic doesn't mean that it is. When you look a the wiring under the board, you'll notice that you have a lot of files that just happen to have the same company making them, but little else that would make them "belong" together. If you're old enough you might remember that the original winsock was such a kludge that there was actually one certain third party implementation [thanksfort...insock.com] more in use and better supported by software than the original winsock.
So just because currently the she
Re: (Score:1)
Apparently you (and I) were lied to. It's not a Linux problem, it's a problem with a PHP script. Not even with PHP itself, so your Linux machine appears to be safe even if you install PHP. Not that I would recommend installing PHP.
Re: (Score:2)
Everybody picks on PHP. Like every language it's not perfect, by far. But by several orders of magnitude (my estimate), the vast majority of all vulnerabilities regardless of operating system have directly resulted from design flaws in C (and C++) - buffer overflows, pointer issues, assignment instead of evaluation in conditionals due to missing equals, etc. Even many/most of the vulnerabilities in PHP have been the result of these same C design flaws. While _some_ of those flaws can be argued to be nec
Re: (Score:2)
It's funny how every time we see an article like this, it eventually comes out in the comments that, as per standard Slashdot fare, the summary was a lie and you have to give the infection several permissions to get it to work. That's been the conclusion of literally every Linux infection article I've seen here for years (although admittedly I don't read every day), with the exception of Heartbleed I suppose.