Hacker News Reader

Comment by ejr | Hacker News Reader

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

View on HN

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

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.

Of course - there is still the possibility that an uploaded script can be executed by the framework, but at least it requires an exploit to do the upload and another one to make your application execute it. If arbitrary php files can be executed, they only need to be able to upload them.

Common mode of infection I have seen with Wordpress is through site owners downloading premium themes that have been uploaded into file sharing sites by malware authors.

The site owners can't, in most cases, poke around to see what is in the code. And the code often contains hooks that inject various things into the installation.

The other route in is through scripts like TimThumb, which is included in a lot of themes. TT has had some serious security holes in it, the last one being fairly recent that allows for remote file execution. At that point, at least the account hosting the file is a goner.

Brute force password guessing is very common. There's ludicrous numbers of WordPress password guessers running. That's right, someone will make several thousand password guesses over the course of a few hours.

Reply on news.ycombinator.com