Why there are so many web servers which get exploited by generating obfuscated files?

Question

TL & DR

How do those obfuscated files many users complain on this SE-site about get on their systems? And after that, even more interesting how they get executed? Is this caused by the way php works? Or is it a problem of preinstalled configs which need to be changed to secure a system¹?

---

I have read many times here about people complaining about some files on their system they don't know what they do, where they come from nor how they got there.

I actually can't understand it either, so how can this be? Is this constituted to the mechanics of PHP²?

I for example set up my webserver as fcgi-app, written in plain C which is communicating over CGI with nginx.

The FCGI daemon (under which the webhost is invoked) is in a user group that has special permissions for reading/writing to the paths where files are stored. So first of all, when a user is uploading something, my app is exactly parsing the whole HTTP package. So I can't really get how there could get something stored I don't want to be stored there. But ok, chances are high I don't know everything (of course I don't) so let us assume some one made a HTTP packet with malicious body content get through the nginx so its the input of my app. This app now doesn't notice it isn't a $WhatEverUsersAreSupposedToUpLoad$ and even puts this malicious file now to the place where all the other files are. With the same restricted access all other files have (named just this daemons group can read/write the file).

So all I can imagine how one can use such a file now to exploit my system requires a major bug in my FCGI-app resulting in

• 1: Some how lets an web-user change the access rights of the app it self to the files to executable AND somehow executes it
• 2: Lets my web app just access the file as it is supposed and then somehow uses the content to exploit the app itself

Or

• 3: somehow makes my app which parses its input data, make execute the parsed file in the app itself. (Since the C executable code has to be compiled I can't imagine any scenario where this could happen as long I ensure no buffers will flow over)

as I have written out all 3 points now I have to admit they sound nonesense... But what else?

Are those concerns not about their applications itself, but about the configurations of an naked OS and the apps they installed making just bypass any meassurments made to the stuff beeing worked with but some default main features of the OS are exploitable if not disabled those configurations?!

If so should I be concerned as well?

All I ever configured is disabling remote root login and restricted SSH access to key authentification only.

installed:

• postgresql (restricted it to local acess by the web-daemons usergroup only)
• nginx (configured it to allow fcgi with my app as execution path)
• installed the latest fcgi for freeBSD supported by nginx.

I actually don't even have php on my system.

But since I'm not a security person (otherwise I would probably not ask this),

I dont know if that's the source, and it's the last thing remaining I could imagine to be causing this threat. Are there other preconfigured files in a naked install that are causing this kind of securitythreat by itself?

---

¹_{This would let me assume a naked latest OS install is to be considered exploitable?!}

²_{My assumption comes from the fact that this complaint everytime is related to php}

Answer 1

When you pry a bit deeper in these cases, you will notice that these victims almost always use some 3rd party content management system written in PHP, like Wordpress or Joomla.

There are some problems with these:

• They had lots of security vulnerabilities in the past.
• There are lots and lots of plugins available for them of varying quality which also have vulnerabilities.
• Uploading files is part of the core functionality of a CMS, so security-related bugs which allow to abuse this functionality unauthenticated are actually quite conceivable.
• People tend to not update these systems as often as they should, so installations with unpatched vulnerabilities stay online.
• There is a huge number of installations for these, so they can be easily found through automated bots.

You might wonder why are there so many problems with PHP applications? PHP is a language with several paradigms which make it quite easy for a novice programmer to write insecure applications full of XSS and SQL injections. Also, PHP files do not need to be compiled and are usually immediately accessible under an URL. A .PHP file on a webserver can be executed just by requesting them with a web browser, so when the attacker manages to upload one, they have already pwned the server.

As a C programmer, these problems affect you less, but you have a whole set of different problems, like for example having to think about buffer overflows whenever you write data to a char* or other type of array.

Answer 2

How do those obfuscated files many users complain on this SE-site about get on their systems?

A mixture of:

• server access being compromised (usually FTP accounts; often credentials extracted from FTP applications on desktops infected by malware)

• vulnerable, often wildly outdated and poorly-written commonly-installed applications running with weak permissioning

being taken advantage of by automated scripts.

The FCGI daemon (under which the webhost is invoked) is in a user group that has special permissions for reading/writing to the paths where files are stored

Well, you are doing much better than most here already.

At my-cheap-crap-shared-php-host.com you are much more likely to see each customer having one account used both for uploading the site content (usually through unprotected FTP, joy) and for the web server to run it. Or maybe the web server is an unprivileged user but the umask makes sure everything is world-writable.

Consequently any vulnerability that allows a file to be uploaded to an existing path or sensitive filename (and boy do typical PHP apps have a ton of these) can write PHP code and so immediately escalate the file-writing to an execute-arbitrary-code vulnerability.

You don't have to deploy PHP this way, but lots of hosts do, because the alternative is that their customers will have to be taught how the POSIX user/group/permission system works, and that kind of support cost will eat your profit margin pretty quickly when you are charging a coupla bucks a month.

The key to PHP's success is that you can easily deploy an application by dropping a load of files in a directory without having to think too much about the environment. This is also the key to PHP's security downfall.

I can't imagine any scenario where this could happen as long I ensure no buffers will flow over

Ensuring you have no buffer-handling bugs when you're writing in C is no mean feat! Webapps do a lot of string manipulation and the stdlib string tools are pretty weak...

Answer 3

If you dig into these, I'm fairly sure that you'd find a pattern: they're either running outdated CMS software, or outdated plugins for CMS software, and they're either on shared hosting, or have set up shared hosting for themselves.

This is a massive generalisation, but outdated CMS software can usually write to pretty much any folder within the webroot - it often had bugs relating to installation routines or thumbnail generation, which both required the ability to write to filesystem, and traded the security of using a distinct connection for the convenience of being able to do updates from within the software. It's not impossible to have a secure web-based installation system, but most early ones weren't.

Similarly, shared hosting can be perfectly secure, but low end hosts often seem to cut corners. They don't segregate users properly, so one person running outdated software often results in multiple sites being compromised. Naturally, the users can't see any reason why this has happened - their sites are secure, they're just running on insecure servers.

The reason for many of these scripts using PHP is a remnant of the above two factors: low end hosts tend to offer PHP rather than Python/Ruby/etc, so you can be pretty confident that the script will run, and it raises less suspicion when a PHP file turns up in a PHP based CMS - it's pretty obvious in a folder full of .rb files, for example.

The obfuscation is generally just to prevent easy monitoring. It's trivial to look for files containing eval, but harder to look for files which contain a string which is base64 encoded and decodes to lave, which is then reversed and executed using another vulnerable function. Some of the encoding methods are quite ingenious though.

Answer 4

A trivial analysis of the stats would suggest that PHP is a security disaster. However dig a little deeper and the reasons become clearer. And most of them are not about PHP.

PHP is everywhere. It's easy to set up a low cost shared hosting environment running PHP. Setting up a secure environment is a bit more complex. And that often means restricting what the user can do. And those support calls where you need to explain to your customers that, no, the policy to prevent PHP from uploading any files anywhere within the document root is there for a very good reason, are very expensive. And likely to drive the majority of your customers to a competing supplier who doesn't enforce such a basic security constraint.

A further issue is the growth of packages solutions, often promoted as a feature by providers - One-Click-Install! Ensuring that the library of packages on offer are up to date (and still work with the installer) is time consuming. Trying to ensure the deployed applications are up to date with patches is even worse.

In the case of user-installed software, most don't bother assessing the quality of the product beyond finding out how easily they can acheive a very specific goal.

From the customers point of view, code deployment is no more difficult than deploying static content.

It is easy to develop in. A hello world program is one line of code. There's no separate build stage, no configuration of your application. It will run on platforms from lots of different providers.

With such a low barrier to entry, anyone with a computer can be a PHP developer. But there's a lot more to software engineering than being able to write lines of code.

So it's not surprising that there is a lot of low quality software written in PHP floating about.

PHP has few inherent mechanisms to restrict security. But more than PERL or C. Java goes off in a completely different direction in terms of Security.

A detailed comparison of the intrinsic security would take much longer than space allows for here. Suffice to say that when White hat Security tried to compare the security of applications written in different languages, the faults they found were in the code and not the platform.