
Mayhem – A hidden threat for *nix web servers - WestCoastJustin
https://www.virusbtn.com/virusbulletin/archive/2014/07/vb201407-Mayhem
======
donatj
I read and then rescanned as best I could, does the article actually bother to
explain the infection process? How the code gets on the system?

Presumably I have to get this onto my system via some flaw for it to be
executed.

I mean of course you can be a pain in the ass with limited access, I didn't
realize that was up for debate. That's not that interesting as I see it.
Actual vulnerabilities relating to holes these things can get through to get
onto your system is what we need to be worried about.

The attack it self seems pretty run of the mill for shared hosting attacks as
we had seen many of at my previous job, often infecting through old unpatched
Wordpress installations, old copies of phpbb and plesk admins. Honestly I
curse Wordpress to this day for the trouble it would cause us.

~~~
jasey
Remote file inclusion (RFI)

Brute force FTP accounts

Brute force logins, eg wordpress login

------
jbangert
As far as malware attacks go, this seems to be pretty run-of-the-mill (no
clever vulnerabilities used). The key seems to be that the automated malware
dropping is adapted to all sorts of 'restricted environments' (i.e. chroot,
virtual servers, non-root accounts, etc). It doesn't look like there is any
privilege escalation involved (which, say in the case of most targeted
attacks, there usually is).

~~~
nwh
I think the point of the article was showing that none were really needed to
still cause massive damage.

~~~
INTPenis
> I think the point of the article was showing that none were really needed to
> still cause massive damage.

No privilege escalation needed?

I disagree, this article shows nothing new at all unless it shows how the
malware gains privileges on the system. As an SELinux user that is what I am
most interested in.

Normally these malwares make it in through some poorly secured web server, in
my experience.

------
ejr
While the dropper was written in PHP, it's important to keep in mind that
Perl, Python or other language could just as easily have been used. If you're
using a shared host that otherwise doesn't allow many configuration changes,
you're very limited in what you can do to protect yourself.

If you use PHP, you can add the following to php.ini to mitigate risks like
these (mitigate != bulletproof) :

    
    
      ; Mayhem dropper uses "system" so let's kill that and other dangerous functions
      disable_functions = system,eval,curl_exec,curl_multi_exec,exec,passthru,shell_exec,show_source
    

If this breaks your software, your software is badly written.

Allowing write permissions in the script directory is always a dangerous
thing. It's best to put the application files outside root and enable execute
permissions only on the script directory. If uploading files is allowed, it
should be to read/write enabled directories only. Execute permissions should
be turned off.

The dropper tries to kill critical processes as mentioned so chrooting
services individually is a good idea.

Or you could just use OpenBSD ;-)

~~~
McGlockenshire
Do you really understand what each of these functions _does_?

Go look up show_source in the PHP manual. Tell me, what do you think disabling
it, but not disabling highlight_file will get you? What does disabling either
of these to prevent the functionally identical
highlight_string(file_get_contents(...))? And how in the blue blazes is this
functionality supposed to be used in some sort of exploit?

What does disabling curl get you? There's nothing that it does that can't be
done through the _built in_ stream handlers. Why don't you try and disable
those as well?

Why disable exec but not create_function? assert can also be used to evaluate
string as code.

This smells like some PHP4-era copy/paste cargo cult _crap_ that should be
avoided, not recommended.

~~~
ejr
I've addressed these concerns and more in my subsequent replies. Your tone
suggests my efforts to reply here will be wasted. Have a nice day.

~~~
shanelja
I don't understand why you would include curl in your listing? There are
plenty of legitimate uses for it, for example as part of my work I recently
used it on a data processing server to trigger post creation of Wordpress
posts via the xmlrpc server which is built in to Wordpress.

~~~
ejr
[https://news.ycombinator.com/item?id=8056882](https://news.ycombinator.com/item?id=8056882)

------
Chromozon
Can someone explain how this infects and gets activated on a system? It sounds
like I have to download a certain PHP file onto the system and then execute
it. Is this correct, or are attackers using other ways to automatically start
the malware?

~~~
ejr
The dropper has to be present on the server somehow to get the rest of the
payload so you have to have uploaded it there, allowed a user to upload it[1]
or be in some way included by a malformed script or some other existing
vulnerability. This includes a very large scope of potential access points.

Ex: This particular sample was in PHP so Wordpress comes to mind. Plugins in
particular are notorious for poor programming practices that allow such file
inclusions.

[1] Disallowing by extension doesn't always work as some filters allow
img.php.png or img.png.php. Besides this, an image can skip the .php
altogether and still be executed as a PHP script

Ex:
[https://security.stackexchange.com/a/32970](https://security.stackexchange.com/a/32970)
and
[https://security.stackexchange.com/a/32969](https://security.stackexchange.com/a/32969)

Note however, this doesn't just apply to PHP. There are potential vectors in
Perl, Python and Ruby when adequate measures are not taken to sanitise user
input and filter arbitrary uploads.

~~~
singlow
It's important to not only to try to prevent them from being uploaded, but to
make sure that any directory which is writable by the web server or php
engine, is not executable. In the case of WordPress, this can largely be
mitigated by using specific location parameters in nginx which allow the
execution of your intended entry points such as the primary index.php file,
rather than a blanket fastcgi forward for all urls ending in .php.

`location ~ .php$ { [forward to fcgi] }`

This is a common configuration that allows the client to execute any php file
within the web root. If you accidentally allow a php file to be uploaded, it
may be executed.

Instead something like the following means that the web server will not allow
arbitrary php files to be executed, only the ones you want to be executed:

`location ~ /(index\\.php|wp-admin/ajax.php)$ { [cgi] }`

(Just an approximation - I don't feel like looking up the exact expression I
use.)

~~~
girvo
I've converted my colleagues over to nginx from Apache, and one of the nicest
parts of it (for PHP) is how easy it is to make sure nginx is only serving
exactly what you want it to, and no more. The blanket "run any PHP in
/var/www" configs that seem to be the copy-pasta default make me sad.

------
ck2
Sigh, if only people this clever were trying to do good in this world.

~~~
InclinedPlane
The number of people this clever or more doing good in the world is enormous,
but their exploits largely go unnoticed and unheralded. Because things going
well can often be difficult to differentiate from a non-event. Think about all
of the sophisticated technology behind something as common as smartphone. Or,
just think about the clever folks working on, say, the linux kernel. Other
than Linus most of those people are not famous and a great many people who use
linux every day don't even realize they are doing so or know anyone involved
with the project, even Linus (such as android phone users, anyone who uses a
website or service hosted on linux, people who use devices running linux in
the firmware, etc.)

~~~
ejr
This is a very well reasoned point. Thank you for writing this.

------
vmiroshnikov
In case you get 503 error, article snapshot at
[http://www.peeep.us/9dcbdec9](http://www.peeep.us/9dcbdec9)

------
nobullet
So I assume I'm safe if I have no PHP on server?

~~~
vmiroshnikov
Its not about PHP, any vulnerable software may be used for infection.

PS You're safe if you have no server :)

~~~
nitrogen
The malware described in the article uses PHP.

~~~
milkshakes
the php dropper discussed is the least interesting part of the article. it
could be implemented in any language.

~~~
shitlord
Furthermore, if your web server (or database server, or any other interet-
facing service) is vulnerable, it won't matter which programming language you
are using. Assume that all input is hostile.

------
Zardoz84
Interesting ... now How detect if is it (or any other similar ) on our web
servers ? And How remove it and protect against it ?

------
rurban
root_ordner: german only word

------
dang
Url changed from [http://www.itnews.com.au/News/390053,new-mayhem-malware-
targ...](http://www.itnews.com.au/News/390053,new-mayhem-malware-targets-
linux-unix-servers.aspx), which points to this.

