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."

Comments

frosty piss!

[Anonymous Coward]

Don't mod me down! It was the worm! (and the mezcal)

Derp

[Anonymous Coward]

Linux and FOSS so secure. Windowz blows. M$ derp.

You faggots asked for it. More market share. Now the world will see how truly insecure your toy OS is.

Re:Derp

[Anonymous Coward]

Mayhem appears to be the continuation of the Fort Disco brute-force password cracking attack campaign that began in May 2013.

Derp, indeed.

Re:Derp

[draxil]

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:Derp

[Detonia]

Insecure for the hours it takes for this to be patched.

Re:Derp

[Anonymous Coward]

Wow, Linux still doesn't rate-limit login attempts by default? What is this, 1985?

*goes back to my VMS box*

Re:Derp

[Anonymous Coward]

Same can be said for all the Windows malware, most of which targets flaws that have been fixed for years.

Re:Derp

[Anonymous Coward]

"Toy OS..." ...that runs most of the modern web and nearly every mobile device in your home.

Fscking idiot.

lrn to *nix.

Re:Derp

[TheRaven64]

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...

Re:Derp

[amalcolm]

Please don't feed the trolls - it gives them indigestion!

Re:Derp

[bluefoxlucid]

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.

Re:Derp

[Anonymous Coward]

different login attempts to the same account from different IPs continuously doesn't seem at all suspicious?

Re:Derp

[Lumpy]

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:Derp

[jellomizer]

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:Derp

[Opportunist]

If that account is "root", it's pretty much normal these days on the internet...

Re:Derp

[Anonymous Coward]

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

[Opportunist]

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.

Re:Derp

[Kythe]

Stupidity, bigotry, and grammar violations all in a two-line post. I suppose that's par for the course. Kids these days.

Re:Derp

[Anonymous Coward]

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:Derp

[graphius]

a properly managed windows box is good, a poorly managed windows box is crap a properly managed linux box is pretty much bomb proof, a poorly managed linux box is good.

Re:Derp

[dkman]

I know that the information can be found, but is there a nice easy list of IP range and what region they belong to?
I know:

• ARIN - North America
• LACNIC - South America
• APNIC - Asia
• AFRINIC - Africa
• AUNIC - Australia

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:Derp

[mark-t]

Did you read the attack vector? The problem isn't the technology, it's idiot admins that allow random users to install and execute code which can affect anyone else.

Re:Derp

[mlts]

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.

Re:Derp

[Zero__Kelvin]

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.

Re:Derp

[mlts]

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 limiting dynamic IP pools.

I've wondered, at an extreme, having a custom sshd that had a list of IPs in place, and if someone connected from a blacklisted IP, it would randomly just deny them, or perhaps give them a fake shell before closing the connection. Of course, tarpitting can't hurt either, but a botnet only connecting 2-3 times from an IP at a time, that won't help much.

Another idea would be to combine it with port knocking so that the sshd would give bogus reponses to anything that connects unless it previously knocked on another port. Of course, this would be in combination with blacklists.

Re:Derp

[rgbatduke]

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

Re:Derp

[Mathinker]

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:Derp

[Mathinker]

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.

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-limit the two kinds of logins separately (i.e., still very retarded).

Re:Derp

[Barsteward]

its PHP that's the problem not linux so i guess it could also affect other systems such as Windows

Re:Derp

[Anonymous Coward]

Exactly. Disabling password authentication seems to mitigate this attack entirely. If you still use a password to connect to your server, you are basically asking to be owned.

Re:Derp

[Lumpy]

We used to also block all of AOL's ip pools as well as many of the large UNI address pools.

Re:Derp

[avgjoe62]

Firewall. Whitelist. Limit access to SSH to systems on the whitelist.

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.

Re:Derp

[SpzToid]

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.

Re:Derp

[nogginthenog]

Don't forget to add a SSH private key. Also, I was getting *lots* of failed ssh login attempts on my OpenWrt box. Changing the port to a different number helped.

Re: Derp

[Anonymous Coward]

You're absolutely correct. MS literally has billions in revenue and *chooses* to not secure their OS. They could allocate sufficient resources and make the very best commercially available OS, but instead, they make a crappy toy.

Apparently commies and hippies can make an OS that challenges MS's best efforts. The terrible truth is terrible but true.

Re:Derp

[Anonymous Coward]

The higher you put the ssh port, the better. I myself like 65535.

Re:Derp

[Anonymous Coward]

Nobody should ever be logging in as root remotely. That's what sudo is for.

Re:Derp

[Anonymous Coward]

a properly managed windows box is good, a poorly managed windows box is crap
a properly managed linux box is pretty much bomb proof, a poorly managed linux box is good.

Poorly punctuated posts are also crap.

Re:Derp

[Anonymous Coward]

Thanks for explaining that this is a difficult topic.
'Always listen to experts. They'll tell you what can't be done, and why. Then do it.'

Re:Derp

[bluefoxlucid]

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: Derp

[Anonymous Coward]

Who cares. Stop using passwords and start using rsa keys and they can try and guess your 'password' all they want.

Re:Derp

[bluefoxlucid]

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 keyboard is no threat. I proscribed accounting per-tty direct console attempts separately because of shell scripts (on the console), which might lock you out of sudo in x11, so you open a new xterm and get pts/17 and sudo there. Of course that creates other oddness (users can create terminals, i.e. screen, xterm), which needs addressing.

Re:Derp

[Opportunist]

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:Derp

[Opportunist]

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:Derp

[bluefoxlucid]

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:Derp

[jellomizer]

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:Derp

[aix tom]

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.

Re:Derp

[Mathinker]

> That's called a movie plot security threat, and it's not a concern.

Do you always start out your arguments by "poisoning the well"? BTW, the person who coined "movie plot security threat" doesn't exactly agree with you.

> Aside from all the obvious shit like "how do you get in there unnoticed?"

Did you miss the "on a public computer" part of my post? Never heard of social engineering?

> Even without a 1-2 second turn-around for testing a password, keyboards can only enter 750 characters per second.

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.

OTOH, comparing the "1-2 second turn-around" in your reply to the "750 characters per second" undercuts your original argument as a whole --- if the password check itself is the limiting factor, even for the "slow" keyboard, it make no sense to make a distinction between password attempts from the keyboard and those from the network, so it would be silly to call Windows "retarded" for doing so.

> That's less than 100 password attempts per second for 8 character passwords,
> or 10^12 seconds to try them all. 800,000 years!

Your naivety about the average entropy in a typical 8 character password is striking.

Re:Derp

[bluefoxlucid]

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 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-around: this actually happens on most modern systems. I pointed it out and then theorized eliminating that rate limit entirely, instead relying on the limits of the HID keyboard protocol at 750 characters per second, which is the faster measurement and thus can be taken as a worst case.

Your naivety about the average entropy in a typical 8 character password is striking.

We're talking about theoretical password complexity here, not dictionary attacks. If you only have 5000 or so passwords to try, a rate limit of 5 seconds to enter each will give you a maximum time of less than half a day. That's a rate of 12 per minute. Even at 3 per minute, it takes barely over a day; weak passwords are quite weak.

I also consider the full entropy of an 8 character password as a weak measurement. My typical recommendation is all lower case, with the space or underscore, and minimum 16 characters. This is to enforce a 4 dictionary word standard (passwords like "red_ant_room_lake" illustrate why so short), although you could say 20 characters and all full dictionary words, minimum 4 (which means 5 words sometimes!). The entropy is much higher even with small vocabularies.

In other words: I used conservative numbers. Real world numbers FOR A HARDWARE PASSWORD BRUTE FORCE DEVICE will involve longer time frames (log-in subsystem delays), higher-entropy passwords, and so on. I also made a final comment about console scripts and the complexity they add--because they're vastly faster than hardware HID brute force devices.

Because hardware brute force devices are not useful--not faster than a human in any reasonable case and, even then, not fast enough to actually crack anything--your proposed attack is a movie plot.

Re:Derp

[rduke15]

For Europe at least, you can get RIPE IP blocks from their web site or through their RIPEstat Text Service. I use it for one of my servers to get daily lists for one country, and feed it to ipset. Maybe others like ARIN etc. also publish lists? Or you can get GeoIP databases. Or you could try a (Perl) module like IP::Country?

Re:Derp

[marcosdumay]

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:Derp

[Mathinker]

There's this link 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).

Thanks for the hint to look at the USB-HIB standard (1.1) in which even high-speed devices are limited to 64KB/s. That's interesting info. Does the USB hardware + operating system on most computers actually enforce that?

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-around: this actually happens on most modern systems. I pointed it out and then theorized eliminating that rate limit entirely, instead relying on the limits of the HID keyboard protocol at 750 characters per second, which is the faster measurement and thus can be taken as a worst case.

You don't actually seem to be addressing my argument here, perhaps you misunderstood? It's clear to me what you did, my argument was that doing what you did made no sense given the "1-2 second delay" you state, and given that datum, your characterizing Windows as "retarded" for not distinguishing between 750 char/s and the much faster network, was illogical.

Your naivety about the average entropy in a typical 8 character password is striking.

We're talking about theoretical password complexity here, not dictionary attacks.

Yes, I am capable of reverse engineering your math. You err, though. "We're talking about..."? No, you're talking about...

I'm not quite getting this. You dismiss the possibility that weak passwords are used, so that hardware password attacks are dismissable, but at the same time address the problem that these same non-weak passwords aren't strong enough to withstand network password attacks without lock-outs? Yes, I suppose there is some real-life situations in which that's true, but why would you rag on Microsoft for trying (in what I agree is not a reasonable way) to cover other possible situations (and, given their user base, much more probable ones)?

Re:Derp

[ratsg]

I have long since given up the use of passwd's for DSA keys in ssh.

I had always considered Bob Beck's post the definitive guide concerning ssh'ing as root, but it seems a number of users feel otherwise.

http://archives.neohapsis.com/...

Re:Derp

[CaptnZilog]

Oooh... 1400 linux servers infected? Um, out of how many on the internet?!?

Re:Derp

[Anonymous Coward]

Thanks. I'll give it a try.

Re:Derp

[mpol]

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 whole idea of ip-blocks might change.

Re:Derp

[bigtrike]

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:Derp

[SpzToid]

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:

when we start SSH on port 22, we know for a fact that this is done by root or a root-process since no other user could possibly open that port. But what happens when we move SSH to port 2222? This port can be opened without a privileged account, which means I can write a simple script that listens to port 2222 and mimics SSH in order to capture your passwords. And this can easily be done with simple tools commonly available on every linux system/server. So running SSH on a non-privileged port makes it potentially LESS secure, not MORE.

Thank you for your important clarification regarding my security practices.

Re:Derp

[SpzToid]

Here's the link to the blog post, that didn't make it into my previous reply: https://www.adayinthelifeof.nl.... It clarifies several reasons for using the standard port 22 for ssh.

Re:Derp

[bluefoxlucid]

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.

The second part is that a console brute-force is slow. Your concern about what amounts to typing really, really fast (i.e. programmed HID plugged into USB) isn't a real concern because of password complexity. It's not that passwords are necessarily that complex; it's that a password which isn't complex enough can be readily brute forced under strong password policies like "3 passwords per minute", it just takes a week or two.

You dismiss the possibility that weak passwords are used, so that hardware password attacks are dismissable, but at the same time address the problem that these same non-weak passwords aren't strong enough to withstand network password attacks without lock-outs?

No, I dismiss the possibility that short lock-out intervals help with weak passwords.

You can attack 129,600 passwords per 30 days if you have a 3 failure per minute policy. Basic English 1250 extends out to about 5000 words with conjugations and domain language (medical, legal, whatever) for most people. Weak passwords in the traditional complexity scheme are like "rainman" becomes "Rainman1", so 100,000 attempts has a fair chance of getting it eventually. That's within the realm of a hardware keyboard typist. Common policy is 60 or 90 day retention, which increases the risk into strong viability; while public kiosks are too visible for a multi-hour console log-in attack, which makes these attacks less viable even at high rates.

Complex passwords reach 10^14 theoretically, and four-word passwords reach 10^16. Reasonable rate limits of 20 attempts per minute carry this out to hundreds of thousands of years. A human can type barely that fast. Remember the original argument:

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.

If the attacker tries to log in over RDP or telnet or such, and locks the account, the actual console log-in box no longer works. That's dumb, because no attacker can possibly brute force the password through that, unless the password is laughably weak--in which case, as stated above, the rate limiting doesn't actually help.

tl;dr: I can lock you out of your server by constantly trying to log into your server, so you can't apply patches anymore. Then I hack it on Tuesday.

Re:Derp

[dl_sledding]

Nobody should ever be logging in as root remotely. That's what sudo is for.

Servers are infected through the execution of a hypertext preprocessor (PHP) script that establishes Mayhem on the victim computer and sets up a communications channel with a command and control server.

...it doesn't need root to operate.

RTFA, AC dumbass troll.

Re:Derp

[TangoMargarine]

Pseudo.

Not to be confused with sudo

Re:Derp

[Mathinker]

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.

OK, I agree that your argument here is OK, if the 1-2 second delay is an artificial one generated by the OS (and the OS doesn't sufficiently limit the number of active connections). If the 1-2 second delay comes from actual computational overhead of the authentication process (e.g., PBKDF2), then your argument still fails.

I can lock you out of your server by constantly trying to log into your server, so you can't apply patches anymore. Then I hack it on Tuesday.

Well, if I understand correctly, the lock-out is on a per-account basis, so you'd have to know the usernames of all my admin accounts, so this seems to me to not be very likely to succeed if I have heard about the attack ahead of time (thanks to your post)...

Re:Derp

[bluefoxlucid]

We're getting spam here because someone, somehow, got our Active Directory mailing list out of Outlook Web Access. I know all of your admin accounts.

Re:Derp

[Mathinker]

We're getting spam here because someone, somehow, got our Active Directory mailing list out of Outlook Web Access. I know all of your admin accounts.

Well, well, sounds like both of us are in big trouble because of Microsoft, and not even because of the problem you originally complained about. :-)

Anyway, thanks for the interesting discussion. As someone whose job doesn't include having to worry about Microsoft's idiocies... I wish you the best of luck!

Re:Derp

[bluefoxlucid]

You see my point, though. Knowing your administrator log-ins isn't a never-happens situation. People get user lists all the time.

How does one detect these things

[carlos92]

Too bad TFA doesn't mention this.

Re:How does one detect these things

[Anonymous Coward]

bascially, tt looks like what needs to be done is the PHP runtime needs to be tightned up.

Re:How does one detect these things

[AHuxley]

Antivirus software for Linux might help over time for some issues?
http://en.wikipedia.org/wiki/C...

Re:How does one detect these things

[Anonymous Coward]

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:How does one detect these things

[dan_linder]

From reading TFA, they mention some possible names:

and drops a malicious shared object named 'libworker.so'

or

After that, the PHP dropper creates a shell script named '1.sh',

And for each of those, they present some example contents that could be used to verify it is part of this infection.

Re:How does one detect these things

[Anonymous Coward]

Too bad TFA doesn't mention this.

SHA256 hashes are provided for all the code analyzed.

Re:How does one detect these things

[mlts]

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 scripts that don't change often, this functionality would come in handy and would nip something creating scripts or executables on the fly almost immediately.

Even better would be to combine trustchk with BSD's securelevel so that a signed list of executables can be created, then locked down until the machine reboots.

Re:How does one detect these things

[Barsteward]

one other thing it doesn't mention is "how" they detected the numbers of "affected" systems out there

Re:How does one detect these things

[Anonymous Coward]

Sometimes I wonder if Linux should have functionality similar to AIX's trustchk.

Tripwire, SELinux, AppArmor...

Re:How does one detect these things

[mlts]

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 access. One can use -noexec flags and ACEs in SELinux for similar effect, but having a feature overlap wouldn't hurt.

Re:How does one detect these things

[MightyMartian]

"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.

Re:How does one detect these things

[r.freeman]

Sometimes I wonder if Linux should have functionality similar to AIX's trustchk.

Tripwire, SELinux, AppArmor...

grsecurity is more advanced then AppArmor, and even then SELinux. AppArmor does some simple RBAC SELinux does good RBAC GrSecurity does good RBAC, and provides wonderfull set uf kernel self-protection, memory protecion, randomization, logging, chroot jailing stuff (from PAX project). http://grsecurity.net/features.php

With friends we now develop a Hardened Debian offspin that includes grsecurity, for now just a tiny addon to Debian, but it does provide grsecurity kernel for debian pre-built and checksummed realibly for well over half year now. mempo.org project.

Re:How does one detect these things

[mythosaz]

Or even "why" they use "quotes" on things.

Re:How does one detect these things

[Anonymous Coward]

isn't that what ossec does? checks binaries? (among other things)

Re:How does one detect these things

[Anonymous Coward]

Do any of those scan for malware that doesn't target Windows?

Re:How does one detect these things

[sjames]

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:How does one detect these things

[Anonymous Coward]

Your comment is so uninformed, it's untrue. Go read some forums and educate yourself instead of just presuming all AVs are ineffective.

Re:How does one detect these things

[sjames]

You should read again. Where did I say ineffective?

Re:How does one detect these things

[Anonymous Coward]

If it is creating and runing a cron job it may be logged.

Try
grep CRON /var/log/syslog

Infection via PHP web apps

[Anonymous Coward]

So, the infection happens through insecure PHP code.

I highlight this because I still think the assertion "Linux and opensource in general, can't be attacked by viruses" is still true. The insecure PHP code that this malware benefits from for its infection must not be opensource, otherwise the security hole would be patched, and most people would get their updates on their systems within hours.

Re:Infection via PHP web apps

[Anonymous Coward]

So, the infection happens through insecure PHP code.

I highlight this because I still think the assertion "Linux and opensource in general, can't be attacked by viruses" is still true.

Yeah, it was never true.

Re:Infection via PHP web apps

[Bengie]

PHP is the poster-child of what popular isn't always good. At least it's brute-forcing passwords instead of a security vuln.

Re:Infection via PHP web apps

[Opportunist]

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)?

Re:Infection via PHP web apps

[Barsteward]

" Not only are Windows machines far more numerous than Linux boxes" - while this is true, if the hackers could do the same to the linux servers that they can easily do to windows desktops, they'd probably get more money because they could hold a vast section of the internet to hostage, e.g. if they hacked Google/Facebook/Amazon etc servers rather than some individual windows desktops. Windows machines are just easy pickings

Re:Infection via PHP web apps

[Anonymous Coward]

Disingenious much?

Comparing third party scripts running in a third part interpreter to integral parts of OS shipped by OS maker. Quite a litte "nitpick".

While "Internet Explorer or Silverlight" is valid comparison, but call me back with your "nitpick" when you'll be able to easily throw away win32k.sys and shell32.dll from Windows. As in, you know, "display-a-rectangle-too-big-get-pwnd" win32k.sys and "just-look-at-a-file-with-malicious-embedded-icon-get-pwnd" shell32.dll.

Re: Infection via PHP web apps

[Anonymous Coward]

So we should use what for websites? ASP? ASPX? Sharepoint? M$ drops support like a bad habit anytime they want to increase revenues/license fees etc. This is not sustainable to rebuild every 3-5 years.

Re:Infection via PHP web apps

[Opportunist]

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:Infection via PHP web apps

[Opportunist]

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 more in use and better supported by software than the original winsock.

So just because currently the shell32.dll is made by Microsoft doesn't make it irreplaceable without making Windows no longer Windows. It COULD be replaced. It's very unlikely, granted, that MS repeats the winsock blunder anytime soon, but it is entirely possible to replace it with some third party library.

Re:Infection via PHP web apps

[Bill_the_Engineer]

hey'd probably get more money because they could hold a vast section of the internet to hostage

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 enterprise level (aka. the ones running the internet) are harder targets than what you would find running on a personal computer at the typical household regardless of OS .

Re:Infection via PHP web apps

[Anonymous Coward]

They also tend to tolerate software operating slower than normal because they incorrectly associate it with the age of the computer.

Why bother with this assumption? It adds nothing.

Re:Infection via PHP web apps

[Anonymous Coward]

its important to note that this attack does not get root access to the entire system like most attacks on windows do. So your attempt at false equivalency has failed miserably.

Re:Infection via PHP web apps

[Anonymous Coward]

Why bother with this assumption? It adds nothing.

Says you.

Running slower than normal speed is a sign that your computer may be running malware. How many computer geeks have gone to their parents home and discovered that their parent's computer is running extremely slow due to all the malware installed from the internet? To top it off when asked, the parents just thought they needed to buy a new computer to run the new versions of software?

From virusbtn

[AHuxley]

"a very interesting and sophisticated piece of malware that has a flexible and complicated architecture." as linked.
What do the plug ins offer?

Too many colors in syntax highlighting

[jones_supa]

The code snippets have too many colors which in my opinion make them hard to read. What do you think?

Re:Too many colors in syntax highlighting

[Anonymous Coward]

I see what you mean, but for me, it actually makes it much easier to understand, as I am very unfamiliar with the code. Still, very busy like you said.

Re:Too many colors in syntax highlighting

[Detonia]

I agree. I find it hard to concentrate on code that looks like rainbows.

Re:Too many colors in syntax highlighting

[Anonymous Coward]

but but! sooo pwettttty...

Re:Too many colors in syntax highlighting

[jellomizer]

Its not the Colors it is just PHP.

Re:Too many colors in syntax highlighting

[Ceriel Nosforit]

Constant distractions on the internet have made it hard to concentrate for me too. Learning to multitask helped a bit though.

Re:Too many colors in syntax highlighting

[dkman]

numbers are purple
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:Too many colors in syntax highlighting

[Anonymous Coward]

Just to confuse you, escaped characters in strings appear to be purple too.

Re:Too many colors in syntax highlighting

[Anonymous Coward]

I don't even see the code anymore. There's just purple, yellow, red, cyan...

Re:Too many colors in syntax highlighting

[Tarlus]

I still prefer grey-on-black and full screen. Easy on the eyes and easy to concentrate.

Re:Too many colors in syntax highlighting

[stderr_dk]

I don't do PHP, but wouldn't $n = unpack("C*", fread($f, 8)); make $n an array of size 8, from $n[0] to $n[7]?

If so, isn't there a bug in the next line, $so[7] = sprintf("%c", $n[8]);?

Re:Too many colors in syntax highlighting

[sjames]

It does seem overdone there.

Re:Too many colors in syntax highlighting

[Anonymous Coward]

It looks similar to sublime. I like them. I like the font too, it's pretty comfortable, although it's a little blurry.

Re:Too many colors in syntax highlighting

[jones_supa]

It could be Ubuntu Mono. Yeah, I like it too.

Re:Too many colors in syntax highlighting

[TangoMargarine]

angry fruit salad

Update yo software

[stewsters]

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.

Re:Update yo software

[smooth wombat]

For those who don't read articles, this appears to happen if you don't auto-update your software

So it's like Windows?

Re:Update yo software

[Gothmolly]

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:Update yo software

[Anonymous Coward]

This only effects the morons running php, so nothing of value will be lost.

Also, who the fuck allows password auth over ssh on internet machines these days? Jesus. The very first thing I do on my systems is install a key and disable password auth.

Re:Update yo software

[Anonymous Coward]

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.

Thanks, you just broke my CentOS servers.

Re:Update yo software

[Anonymous Coward]

A remote exploit (though not gaining root) vs a crash? yes, ill take secure + crash any day of the week. you can pick insecure but no crash and be smug about your uptime if you want.

security is ofcourse an unatainable goal - but worth working towards, but something blatantly insecure is certainly worse than "secure" (as
you put it)

Re:Update yo software

[Anonymous Coward]

I guess you dont do backups. so to you this would probably be catastrophic. Because all those people peddling security also claims backups and testing before deployment are important. but what do they know, right?

Re:Update yo software

[Anonymous Coward]

So, it's not targetting Linux or Unix, it's targetting PHP?

Thanks. I suspected something like that, when they mentioned targetting Linux and then completely failed to write how.

Re:Update yo software

[Opportunist]

It's like any system where abusing a known system weakness leads to profit.

For reference, see politics and lobbying.

Re:Update yo software

[Opportunist]

No, you weren't. If that happens to you, your backup policy sure as hell was lacking!

Re:Update yo software

[hawkinspeter]

You can smugly assert that you were "secure", but everyone else can smugly assert that "you're doing it wrong!" by not testing or having any kind of backups to rollback any unwanted changes.

Re:Update yo software

[segedunum]

A backup policy isn't going to help you here. The machine still needs to be re-installed via whatever method you choose along with the associated downtime and disruption - and then you do your restores. No one with any experience at all does 'auto' updating. Updates are scheduled in if they are needed.

Re:Update yo software

[houstonbofh]

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

[houstonbofh]

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:Update yo software

[Anonymous Coward]

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".

The only secure computer is one that is not functiong.

Re:Update yo software

[Anonymous Coward]

Testing? What's that?

Re:Update yo software

[Anonymous Coward]

Or a

sudo apt-get delete *php*

But how does it get there?

[Anonymous Coward]

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.

Re:But how does it get there?

[smaniak]

peruse - I don't think that word means what you think it means.

/usr/bin/host ?

[Gothmolly]

So this only works if you have /usr/bin/host installed?

Still old-school

[bluefoxlucid]

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.

Re:Still old-school

[Anonymous Coward]

http://blanu.net/curious_yellow.html

What?

[Anonymous Coward]

I have been told by friends that use Linux. That they don't have malware, viruses, or trojans.

Re:What?

[Anonymous Coward]

True, unless a complete idiot is using Linux, which can't happen because Linux is Idiot proof, unless a complete idiot is using Linux, which can't happen because Linux is Idiot proof, unless a complete idiot is using Linux, infinite loop...

PHP suexec, mostly. Thanks Plesk

[raymorris]

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:PHP suexec, mostly. Thanks Plesk

[Anonymous Coward]

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 permitted write access.

Re:PHP suexec, mostly. Thanks Plesk

[Anonymous Coward]

The idea that to make a system secure you have understand numerous configuration options is not a feature but a sign of the immaturity of the technology. At one time televisions had fine tuning knobs because the tuner oscillators were insufficiently stable but they are unnecessary with modern digital tuners. I appreciate the ego boost one gets by claiming one's system is secure and that insecure systems are run by those not a clever, however the goal should be a system designed by geniuses but run run by morons. Its obvious many features of Unix were designed to show off the ingenuity of the developers rather than mere utility.

Re:PHP suexec, mostly. Thanks Plesk

[Anonymous Coward]

?? There is no switch for "secure" or "insecure".

Just as there is no single control for a TV set. Some handle channels, others handle volume, others handle color control.

The UNIX design was done by geniuses. And it has been extended by other geniuses.

But any system operated by morons will be insecure.

Re:PHP suexec, mostly. Thanks Plesk

[Anonymous Coward]

people that have vps or dedicated servers and then put plesk, cpanel, etc on them are jackasses.

B-b-but the thousand monkeys?!!

[kvvbassboy]

I thought linux was secure because there were thousands of monkeys looking at the code. How did they let this happen - or was I lied to?

Re:B-b-but the thousand monkeys?!!

[Anonymous Coward]

You were lied to: there are no monkeys working on Linux security, only apes.

Turns out you're very easy to troll.

Re:B-b-but the thousand monkeys?!!

[Anonymous Coward]

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:B-b-but the thousand monkeys?!!

[garyebickford]

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 necessary for writing at the bare metal level - device drivers and such, they are completely unnecessary for application programming.

The standard counter argument is that "C programmers (must) learn better programming habits, and deal with those things." To which I merely append, "Some ..." and note that many of these bugs have demonstrably been put there by highly skilled, experienced developers who know better, but just forgot "this one particular time."

It's enough to make one yearn for Haskell, or Erlang, or something. :D

Re:B-b-but the thousand monkeys?!!

[Anonymous Coward]

You appear to be making the assumption that your pet language is being unfairly picked on. Seriously, grow up.

Attack Vector

[Anonymous Coward]

"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:Attack Vector

[Anonymous Coward]

Seriously, there's a reason that the article numbers are less than 1% of the size of the average windows server infection..

Market share?.

Hahaha, sorry, i couldn't resist.

Re:Attack Vector

[rgbatduke]

Or, to put it another way, you can't fix stupid.

rgb

Re:Attack Vector

[houstonbofh]

So, Plesk then... :)

Re:Attack Vector

[StormReaver]

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:Attack Vector

[Anonymous Coward]

The admin must have content authors (coders) that are incompetent in their job and get selected by customers that are being cheap and won't even listen if either party warns them.

Bring up your brains in the morning and grasp a little of the world around you.

Admins run the half-baked incoherent shit others produce for people that LET THEM PRODUCE SHIT.
The admins work is to limit damage and somehow keep it going while there are hundreds of people recommending users to chmod 777 because they can't even *spell* permission but think they can code.
Half of the tools at their disposal (i.e. ACLs or SELinux) they can't even use unless they work for an enterprise environment because the customers or their bosses might hire complete idiots that just so managed to complete LPIC2 and who would never, ever understand an ACL.

this is reality. it only works because us admins have unlimited amounts of duct tape and sometimes get really radical stuffing your whole shit on a readonly filesystem.

Re:Attack Vector

[Anonymous Coward]

Mod him up for sarcasm please!

Re:Attack Vector

[Anonymous Coward]

I noticed that too. This isn't really a bug or a hole in the *nix systems, it's just a set of scripts.

Re:Attack Vector

[ebvwfbw]

Market share?.

Hahaha, sorry, i couldn't resist.

Also not true. Most web servers today are STILL Linux/Unix. Microsoft never did take that even with their fake azure stuff.

Not a bug

[CauseBy]

"Mayhem appears to be the continuation of the Fort Disco brute-force password cracking attack"

So, it doesn't exploit any security vulnerabilities? Awesome. The UNIX family continues its extremely good record for security. It isn't perfect but it's pretty close.

Don't fix stupid

[Anonymous Coward]

Or, to put it another way, you can't fix stupid.

You shouldn't even try.

Fixing stupid requires thinking like an stupid. And that is what has left the nice discipline of design in its sorrow actual state.

THE L9NUX

[Anonymous Coward]

IS NEVER CAN BE HAKED! SUPER SECUR1!! NEVER CAN ANY ONE DO THIS.
iwwont use many caps i swear...please dont hate me slashdot submitter button

Re:THE L9NUX

[TangoMargarine]

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.

Yuo FailR It

[Anonymous Coward]

this is consistent Something ccol reaper Nor dO the cycle; take a fanatic known

That's very tricky with newer SuExec and not trans

[raymorris]

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 used in a smart way, though few people did. Suppose you have a user named "joe". You could create a script user named "joes_scripts". In that way, Joe's scripts would run as their own user. The new checks won't allow the joes_scripts user to run within a the home directory of "joe", so there goes the proper use of suexec.

On a dedicated server, the you CAN create a user that safely isolates scripts, so scripts run as a separate user from everything else. That user is called "httpd" or "nobody", and that's the default you get by NOT using suexec.

Whitelisting with mobile admins

[tepples]

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:Whitelisting with mobile admins

[avgjoe62]

VPN to an admin workstation in the DMZ. That admin workstation will of course be on the access list.

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:Whitelisting with mobile admins

[Anonymous Coward]

Assuming you mean that it is close to impossible to do in a useful manner; one wouldnt, but lots of ones would never need that so the advice is still good except for the ones who have special needs. Ofcourse there are solutions - but they all require you to think beyond just following his advice step-by-step blindly - that might be too much effort for you, so stick to the way you do it now instead.

People still use php after all the security proble

[Anonymous Coward]

People still use php after all the security problems?
I'm shocked!

It is like saying that people still use Java and anything from adobe. Crazy people out there.

Still old-school

[Anonymous Coward]

Data written in memory should never become code: So you want to kill all interpreted langauges?