Coppermine-driven galleries hit by RAR exploit

[Joachim Müller]

In the past few weeks, there have been a lot of users complaining that their coppermine-driven gallery has been hacked by the "rar exploit". Although this issue is not related to Coppermine, but to a webserver vulnerability, there are methods to circumvent the vulnerability. We decided to post this as reference for users who have fallen victim to the exploit and for those who are afraid of the hack:

What the hack/exploit does:
The attacker uses the upload mechanisms of Coppermine (or any other web app that allows uploads) to upload a file named "somename.php.rar" to your webspace. The file is a plain-text file that contains PHP code that usually does malicious things (attack patterns vary from sending spam emails, defacing the site, creating additional backdoors etc., depending on the PHP code). After the upload, the file resides somewhere on your webserver and can be accessed by URI (something like http://yourdomain.tld/your_coppermine_folder/albums/userpics/10XXX/somename.php.rar). Usually, a file with the extension ".rar" is not suppossed to be parsed by the PHP interpreter on your webserver - it should just be a file that webserver returns for download when accessed. Webservers that are not patched properly ignore that actual extension ".rar" and treat the file as if the name only were "somename.php". Subsequently, they parse the file with the PHP interpreter and execute the (malicious) code contained in it.

Why the exploit is not a Coppermine issue:
Developers have to rely on certain parameters, one of them being that files with certain extensions get treated by the webserver in a certain way. Files with the extension ".rar" must not be parsed by PHP. Webserver that fail to do so are not set up properly - period.

How can I find out if my webserver is vulnerable?
Create a plain-text file with this content:

Code Select Expand

<?php print 'Oops, my webserver is vulnerable'; ?>, name it test.php.rar, upload it to your webserver (by Coppermine methods or by FTP) and run it in your browser by entering the URL of the file you uploaded into the browser's address bar. If the susequent page shows the message

Oops, my webserver is vulnerable

, then you really should be alarmed. If it returns garbled text, the PHP source code or just asks you to download the file, then your webserver probably is configured OK and you're not vulnerable.

What can I do to prevent the exploit from being run on my server?
Go to your Coppermine gallery, log in as admin, go to coppermine's config. The field "Allowed document types" is the place you're suppossed to edit (as suggested in the docs): empty the field, or explicitely specify the extensions that are allowed (e.g. "doc"). There mustn't be "ALL" in the field, as this includes the extension "rar". Please understand that this is a workaround we have come up with to help users close a security hole that exists on their server (I repeat: not in Coppermine).
If your webserver is vulnerable, contact your webhost immediately and demand that they fix the vulnerability. Don't accept answers that claim Coppermine was to blame - it isn't, but your webserver is!

My webserver is affected and there appears to be a suspicious/malicious file, what should I do now?
1) Make a backup of all your files on the webserver and your database for forensic reasons
2) Delete the malicious file from the webserver
3) Scan your webserver for other suspicious files and possible subsequent backdoors and delete them
4) Go to coppermine's config and apply the suggested changes as suggested above as a method to stop further hacks
5) Contact your webhost, tell them what happened and demand that they fix their webserver. If they refuse or blame Coppermine to be the culprit, you're welcome to refer to this thread. Ask them for help to scan your webserver for malicious files. Ask them to review the server logs

I repeat: this is NOT a Coppermine vulnerability, but a webserver issue! Please don't clutter this thread with individual support requests, asking for help on cleaning your webserver if it has been hacked. You're allowed to discuss the vulnerability itself on this thread and the impact on Coppermine only. Invalid replies to this thread will be removed without further notice.

Related threads:

• 1.4.5, still hit by rar exploit
• hackers (?) creating ads
• My Coppermine Site Sent out Spamming Email. How?
• Important security issue 1.4.4
• Upload vulnerability through .rar extension for improper webserver setups
• upload.php exploit
• Prenting File Types

Possibly related hacks:
There might be similar issues on your webserver that allows not only ".rar" files to be parsed as PHP, but other file types as well (e.g. ".gz"). To be safe, only allow uploads of files that you're definitely sure to be handled correctly by your webserver.

[solarian]

This is actually a "feature" of Apache, so that any file with ".php" somewhere in the filename will be interpreted by PHP, unless there is an earlier match to a different mime-type.  Any unmapped mime-type will cause this problem, not just .rar files.  If anyone knows a way to configure Apache differently, I'd like to know too.  I understand there is a patch for one version of Apache if one uses AddHandler instead of AddType, but quite frankly there's no use blaming it on poor server configuration -- it's written into Apache.

You say "Developers have to rely on certain parameters, one of them being that files with certain extensions get treated by the webserver in a certain way."  Well, you can rely on Apache interpreting the filename "xxx.php.yyyyy" as a PHP file, so whether you like it or not this is a Coppermine security hole -- i.e., if anyone uses Apache and Coppermine with standard installation defaults they will automatically be vulnerable.  It is rather annoying to be told to "patch" Apache to get Coppermine to work safely when it would be quite simple to prevent this problem by writing a couple of lines into Coppermine to sanitize all but the final "." as an underscore.  You can solve this problem.  Please do so.

[Joachim Müller]

The Apache feature you refer to is imo badly implemented - there's no way to turn this silly behaviour off, although many other things can be configured in apache. The issue is also misdocumented.
However, as people will of course blame Coppermine to be the culprit for anything that has been uploaded using Coppermine's upload mechanisms, we (the Coppermine dev team) decided fix the issue within the app by sanitizing the filename: we added a check to the function that does file renaming on upload to replace all dots in a filename (except the last one) with an underscore. We have packaged a maintenance release that includes some other minor fixes as well see details in the thread Maintenance release CPG1.4.6 protects against Apache's .rar vulnerability (contains hotfix instructions as well).

[solarian]

Yes, I agree that this is odd behaviour in Apache, and is apparently only really useful if serving documents in multiple languages.  However, the practical applications of such a feature are, IMHO, probably close to nil, since that sort of thing can more easily be done in other ways.  I understand IIS doesn't have the same twist.

Thanks for implementing a fix for this -- it just remains for all the programmers who've written upload utilities & who were unaware of this (which included myself) to check their own scripts.  I have a feeling there are probably dozens of web-apps which are vulnerable to this Apache "feature".

I notice that this problem isn't even mentioned in the Apress Pro PHP Security 2005 book.

[hds]

The Apache feature you refer to is imo badly implemented - there's no way to turn this silly behaviour off, although many other things can be configured in apache.

well, it works as explained here:
http://forum.coppermine-gallery.net/index.php?PHPSESSID=7771f88e18e83ec1e3a7778f20877b0f&topic=22806.0
by Tarique Sani:
AddType application/rar .rar

however, i also added
AddType application/arj .arj

because this was not defined in my mime types either.

however, unfortunately any unknown filetype will work as well. for example a file called "test.php.lala" ;(

[Joachim Müller]

well, that's what the maintenance release cpg1.4.6 takes care of - such files will be renamed on upload, so the Coppermine upload mechanism can't be abused to upload malicious files to the webserver to exploit the Apache vulnerability. By default, .ARJ is not in Coppermine's filetypes list anyway, nor are files of the type .lala, so your remarks don't apply anyway.
Possibly vulnerable file types could be evil_file.php.ra, evil_file.php.rm etc., as not all webservers probably are set up to "know" real audio /real media files.
However, this whole discussion is pointless, as suggested above: the maintenance release fixes things on the Coppermine side. If you have other apps on your webserver that allow users to upload files, you should review them.

Joachim

[hds]

yeah, i know 1.4.6 takes care of this (thanks) but i was talking about apache/php in general. slightly OT, excuse
and thx for the update!

[Purrsia]

Well, I contacted my host and let them know about the apache hole given I ran that test file and it came back as vulnerable when put in the root directory.

As could be expected, they did blame coppermine. Before anyone protests, however, here's the interesting part. They suggested I try that test file in a folder with permissions set to 777 or 775. And sure enough, the same test files put in such a folder on my server returned an error 500 message instead of the 'oops my server is vulnerable' line. This is somewhat comforting as one of my art galleries did have a rar file uploaded to it before all this became such an issue, and it has since worried me, wondering about what damage it might have done. However, since it went into the userpics area, which is chmod'ed at 777, I'm willing to bet if that rar file did have anything nasty in it, it didn't do anything.

I haven't seen this discussed here yet, the issue of permissions factoring in. And I don't know what it means. I mean, since the test file failed in the root directory, but passed in a writable one, my server is still technically not configured right...right? Of course, my host still blames coppermine completely. And yes, I pointed them to this thread and the test file uploaded to my root directory and they still maintain it's a coppermine issue. They mentioned the server was configured in SuExec mode, explaining it was the reason such a file in the properly chmod'ed folder would NOT execute the code in such a malicious file. And it seems to hold true. This must be their way of making sure files uploaded by outsiders can't run this kind of exploit, which makes sense. I'm the only one uploading to my root directory, and I'm not going to hack my own work.

But what's weird is coppermine tells you to chmod the uploadable directories to 777, which stops the attack on such a configured server, so it would seem this problem shouldn't even be an issue on a properly protected server (so I tend to agree that it's more a server issue overall than a coppermine one). I'm guessing those who did the chmoding but still got attacked don't have their servers configured in this SuExec mode? Maybe that's what they should be asking their hosts. Try that test file in a writable folder to really see how vulnerable you and your coppermine install could be.

At any rate, I hope my post gives people another possibility to investigate.

[Nibbler]

Setting perms to 777 will stop *any* php script from running when using suexec, that's why files need to be 755 when the server is setup this way. Coppermine docs state 777/755 depending on server setup.

[realitycheck]

I do not like the attitude towards security that the initial handling of this issue demonstrates.  Coppermine -- for better or worse -- has a very bad reputation with regards to security.  Most of this can be blamed on issues outside of Coppermine, but the fact remains that you have a large installed base of people who are not Unix experts, but people who simply want to host pictures on cheap service providers.

This is the "reality" side of cheap hardware, free operating systems, and open source software. 

I'd urge you to really rethink your development methodology and make sure the product you deliver is in line with the realities of the marketplace.  You guys have done way too much work on something only to have it destroyed by pencil-wielding server admins who are sick of the constant nonsense that's perceived to come from your product.

[Joachim Müller]

That's why we've implemented a function in cpg1.4.6 that will sanitize the uploaded data even if the webserver itself is vulnerable, so there will be no threat via Coppermine uploads. What else do you expect from us? A security-related bug gets discovered and we provide a fix for it - what else could we possibly do? Maybe you could tell us how exactly we're suppossed to change our development methodology

This is the "reality" side of cheap hardware, free operating systems, and open source software.

This sounds like a lame flaming effort to me. Be more specific or don't post such nonsense at all.

[realitycheck]

I can assure you I'm sufficiently capable of flaming with the best of them when appropriate.  This is not such a time.

I specifically have problems with the following statements by you in the first post:

"this issue is not related to Coppermine" and "the exploit is not a Coppermine issue" and "don't accept answers that claim Coppermine was to blame" and "I repeat: this is NOT a Coppermine vulnerability".

Seriously, I feel your pain.  And it's not too hard to read between the lines (it's so subtle...) and realize that you're a little fed up with people blaming Coppermine.

Fact of the matter is that the application has a horrible reputation among "pencil wielding server admins" (note attempt at humor).

I'll cut to the chase.

You only have yourselves to blame for this reputation, and the aggressive stance toward server admins isn't helping your case.

On a technical side, the problems are due to the way you ship the app and the fundamental approach you've taken toward security since day one. You don't seem to care about what goes on out there in the ugly real world.  If you want people not to think of Coppermine as a piece of trash, you've got to change the way you deal with these issues.

One example: the reason for the wide .php parsing in Apache is, among other things, an attempt to prevent passwords and code from being exposed when dopey programmers do things like rename "supersecret.php" to "supersecret.php.old" or "supersecret.php.1" during development.  I agree, it's stupid; they're trading one problem for another.  But your first explanations to add a mime mapping for .rar reveal that you're not intimately familiar with the history of apache.  No big deal, nobody really is.

But the second solution you posted -- where you actually fixed the problem -- was the correct one.  And it should have been in the VERY FIRST REV of this product!  Likewise the "Allowed document types" list should contain an absolutely minimal set of extensions, not everything you've got a dopey huge icon for under themes.

This is not rocket science -- it became standard development procedure in most circles years ago.  I would suggest that you adopt some of these principles and reshape the way you approach security issues immediately.

Fact of the matter is that when a couple thousand sites turn into zombies because you guys weren't aware of how Apache parses php files, it most certainly IS a coppermine problem and a coppermine vulnerability -- no matter how stupid apache is.

Doctor's don't blame the gun, they sew up the hole in the patient.  The sooner you shift your thinking on these issues the better.

[Paver]

@realitycheck: You've made some good points and the detailed viewpoint you provide is informative.

I, for one, found the reason you gave for Apache's PHP parsing of xxx.php.yyy files eye-opening - that does make sense, although it does have the serious side-effects this exploit has unearthed.

The dev members realize that the last few releases in particular may make some people uneasy about the security and stability of Coppermine.  We are currently discussing this on the dev-only board.

[Holguinho]

READ THIS!

If you have one new user registration with the name "Taroq" you should be alarmed! Most likely he(she) uploads one or several rar-files to your gallery.

Find it out  with e.g. http://www.google.de/search?q=taroq
http://search.yahoo.com/search?ei=UTF-8&fr=sfp&fr2=sfp&p=%22hacked+by+el%22

Holger Riemann
______________________________
www.Travel-Island.com

[Joachim Müller]

I understand that you are concerned and appreciate your readiness to participate by alarming others, however you draw the false conclusions: you mustn't watch out for uploads by a particular user (because the malevolent user might change his nickname and because there might be other "black hat hackers" who don't go by the name "taroq" yet they might still try to ruin your site). Please refrain from trying to alarm others of particular user nicks. Instead, spread the word that it's mandatory to keep your apps up-to-date.
Bottom line: don't bother to check for particular user names, but do as suggested in this thread and update your coppermine install to the most recent version to patch the security issue discussed.

[Holguinho]

Nevertheless, you should alter your ftp-password immediately after you have been attacked, if still possible !

http://search.yahoo.com/search?ei=UTF-8&fr=sfp&fr2=sfp&p=%22hacked+by+el%22


Holger Riemann
______________________________
www.Travel-Island.com

[Sami]

coppermine do not store ftp password any where!!!
and after checking that search result, all I see it's PHPBB.

[Holguinho]

You are right COÑO! Coppermine doesn't store it.

Anyway, if you suppose being attacked you must alter your ftp-password!
You can do this while logged-in at your webspace provider.

After all not to forget to change your pw in your ftp-uploader program as well ;-)

[Stramm]

If you really got hacked then just changing the 'FTP' password is like ignoring the inevitable.
And don't use vulgar language on this board.

[Joachim Müller]

Hehe, leaving the backdoor wide open and locking the front porch. Excellent.