×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

New Mayhem Malware Targets Linux and UNIX-Like Servers

Soulskill posted about 5 months ago | from the keep-calm-and-patch-on dept.

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

Sorry! There are no comments related to the filter you selected.

frosty piss! (-1)

Anonymous Coward | about 5 months ago | (#47481701)

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

Derp (-1)

Anonymous Coward | about 5 months ago | (#47481719)

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 (-1)

Anonymous Coward | about 5 months ago | (#47481755)

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 (1)

Anonymous Coward | about 5 months ago | (#47481805)

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

*goes back to my VMS box*

Re:Derp (4, Informative)

TheRaven64 (641858) | about 5 months ago | (#47481865)

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 (1)

Anonymous Coward | about 5 months ago | (#47481903)

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

Re:Derp (1)

Opportunist (166417) | about 5 months ago | (#47482037)

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

Re:Derp (1)

Anonymous Coward | about 5 months ago | (#47484273)

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

Re:Derp (2, Insightful)

Anonymous Coward | about 5 months ago | (#47482051)

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 (4, Insightful)

Lumpy (12016) | about 5 months ago | (#47481939)

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 (1)

dkman (863999) | about 5 months ago | (#47482283)

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 (2)

avgjoe62 (558860) | about 5 months ago | (#47483431)

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 [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:Derp (1)

nogginthenog (582552) | about 5 months ago | (#47483867)

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 (1)

mlts (1038732) | about 5 months ago | (#47482535)

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 (1)

Lumpy (12016) | about 5 months ago | (#47483175)

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

Re:Derp (1)

Mathinker (909784) | about 5 months ago | (#47482643)

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 (1)

jellomizer (103300) | about 5 months ago | (#47481975)

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 (2, Insightful)

Anonymous Coward | about 5 months ago | (#47482173)

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 (2)

mlts (1038732) | about 5 months ago | (#47482407)

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 (0)

Anonymous Coward | about 5 months ago | (#47482795)

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 (2)

SpzToid (869795) | about 5 months ago | (#47483745)

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 [elasticsearch.org] rocks! Here's a guide to setup your own machine [vandeplas.com] , for the purpose of reading logs in a very user-friendly way.

Re:Derp (0)

Anonymous Coward | about 5 months ago | (#47484215)

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

Re:Derp (2)

bluefoxlucid (723572) | about 5 months ago | (#47481887)

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 (2)

Opportunist (166417) | about 5 months ago | (#47482087)

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 (1)

Mathinker (909784) | about 5 months ago | (#47482719)

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 (4, Informative)

Zero__Kelvin (151819) | about 5 months ago | (#47482517)

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 (1)

draxil (198788) | about 5 months ago | (#47481771)

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 (1)

Detonia (3694291) | about 5 months ago | (#47481779)

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

Re:Derp (1)

Anonymous Coward | about 5 months ago | (#47481825)

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

Re:Derp (2, Informative)

rgbatduke (1231380) | about 5 months ago | (#47482593)

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 (0)

Anonymous Coward | about 5 months ago | (#47483881)

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 (1)

mark-t (151149) | about 5 months ago | (#47482393)

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 (2)

Barsteward (969998) | about 5 months ago | (#47482773)

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

Re:Derp (1)

Anonymous Coward | about 5 months ago | (#47481859)

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

Fscking idiot.

lrn to *nix.

Re:Derp (1)

amalcolm (1838434) | about 5 months ago | (#47481875)

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

Re:Derp (1)

Kythe (4779) | about 5 months ago | (#47482141)

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

Re:Derp (1)

graphius (907855) | about 5 months ago | (#47482239)

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 (0)

Anonymous Coward | about 5 months ago | (#47484277)

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.

How does one detect these things (1)

carlos92 (682924) | about 5 months ago | (#47481723)

Too bad TFA doesn't mention this.

Re:How does one detect these things (0)

Anonymous Coward | about 5 months ago | (#47481777)

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 (1)

MightyMartian (840721) | about 5 months ago | (#47483287)

"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 (1)

AHuxley (892839) | about 5 months ago | (#47481809)

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

Re:How does one detect these things (1)

Anonymous Coward | about 5 months ago | (#47481835)

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 (3, Informative)

dan_linder (84060) | about 5 months ago | (#47481845)

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 (1)

mlts (1038732) | about 5 months ago | (#47482739)

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 (0)

Anonymous Coward | about 5 months ago | (#47482901)

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

Tripwire, SELinux, AppArmor...

Re:How does one detect these things (1)

mlts (1038732) | about 5 months ago | (#47483135)

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 (1)

Anonymous Coward | about 5 months ago | (#47481891)

Too bad TFA doesn't mention this.

SHA256 hashes are provided for all the code analyzed.

Re:How does one detect these things (1)

Barsteward (969998) | about 5 months ago | (#47482823)

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

Infection via PHP web apps (0)

Anonymous Coward | about 5 months ago | (#47481737)

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 (0)

Anonymous Coward | about 5 months ago | (#47481799)

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 (0)

Bengie (1121981) | about 5 months ago | (#47481821)

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 (0)

Anonymous Coward | about 5 months ago | (#47483703)

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 (3, Interesting)

Opportunist (166417) | about 5 months ago | (#47482235)

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

Barsteward (969998) | about 5 months ago | (#47482735)

" 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 (0)

Anonymous Coward | about 5 months ago | (#47483515)

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.

From virusbtn (1)

AHuxley (892839) | about 5 months ago | (#47481757)

"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 (2)

jones_supa (887896) | about 5 months ago | (#47481785)

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

Re:Too many colors in syntax highlighting (0)

Anonymous Coward | about 5 months ago | (#47481819)

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 (1)

Detonia (3694291) | about 5 months ago | (#47481829)

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

Re:Too many colors in syntax highlighting (0)

Anonymous Coward | about 5 months ago | (#47481871)

but but! sooo pwettttty...

Re:Too many colors in syntax highlighting (1)

Ceriel Nosforit (682174) | about 5 months ago | (#47482309)

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 (0)

jellomizer (103300) | about 5 months ago | (#47481921)

Its not the Colors it is just PHP.

Re:Too many colors in syntax highlighting (1)

dkman (863999) | about 5 months ago | (#47482323)

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 (0)

Anonymous Coward | about 5 months ago | (#47482509)

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

Re:Too many colors in syntax highlighting (0)

Anonymous Coward | about 5 months ago | (#47483957)

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

Update yo software (2)

stewsters (1406737) | about 5 months ago | (#47481797)

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 (2)

smooth wombat (796938) | about 5 months ago | (#47481831)

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 (1)

Opportunist (166417) | about 5 months ago | (#47482275)

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

For reference, see politics and lobbying.

Re:Update yo software (1)

houstonbofh (602064) | about 5 months ago | (#47483031)

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 (4, Insightful)

Gothmolly (148874) | about 5 months ago | (#47481851)

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 (-1)

Anonymous Coward | about 5 months ago | (#47481899)

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 (0)

Anonymous Coward | about 5 months ago | (#47481969)

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 (0)

Anonymous Coward | about 5 months ago | (#47482099)

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 (1)

Opportunist (166417) | about 5 months ago | (#47482285)

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

Re:Update yo software (1)

segedunum (883035) | about 5 months ago | (#47482649)

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 (1)

houstonbofh (602064) | about 5 months ago | (#47483079)

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 (1)

hawkinspeter (831501) | about 5 months ago | (#47482557)

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 (0)

Anonymous Coward | about 5 months ago | (#47481909)

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 (0)

Anonymous Coward | about 5 months ago | (#47482231)

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.

But how does it get there? (1)

Anonymous Coward | about 5 months ago | (#47481877)

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 (4, Informative)

raymorris (2726007) | about 5 months ago | (#47481993)

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 (1)

Anonymous Coward | about 5 months ago | (#47482329)

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 (1)

Anonymous Coward | about 5 months ago | (#47482961)

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 (0)

Anonymous Coward | about 5 months ago | (#47483117)

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

/usr/bin/host ? (1)

Gothmolly (148874) | about 5 months ago | (#47481905)

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

Still old-school (3, Insightful)

bluefoxlucid (723572) | about 5 months ago | (#47481931)

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.

What? (-1)

Anonymous Coward | about 5 months ago | (#47481989)

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

Re:What? (0)

Anonymous Coward | about 5 months ago | (#47482303)

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

B-b-but the thousand monkeys?!! (-1, Flamebait)

kvvbassboy (2010962) | about 5 months ago | (#47482033)

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?!! (0)

Anonymous Coward | about 5 months ago | (#47482101)

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?!! (1)

Anonymous Coward | about 5 months ago | (#47482291)

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.

Attack Vector (5, Insightful)

Anonymous Coward | about 5 months ago | (#47482091)

"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 (0)

Anonymous Coward | about 5 months ago | (#47482635)

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 (1)

rgbatduke (1231380) | about 5 months ago | (#47482647)

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

rgb

Don't fix stupid (0)

Anonymous Coward | about 5 months ago | (#47483717)

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.

Re:Attack Vector (1)

houstonbofh (602064) | about 5 months ago | (#47483129)

So, Plesk then... :)

Not a bug (1)

CauseBy (3029989) | about 5 months ago | (#47483095)

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

THE L9NUX (0)

Anonymous Coward | about 5 months ago | (#47483929)

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

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?