[Solved]: Remote Code Execution Exploit

[gldickens3]

I have discovered a remote code execution exploit in my Coppermine installation involving malicious redirection.  Basically, a set of directories have been created by a perpetrator with lots of names and words for search engines to find.  Then, the parent directory's .htaccess file redirects the user to another web site where the user is told that he has two viruses and is then instructed to download a program to remove the viruses.  I strongly suspect that the suggested download from the redirected site is malware as well.  I believe that this exploit is similar to that described at these two sites:

http://heapoverflow.com/f0rums/public/7660-coppermine-photo-gallery-1-4-18-lfi-remote-code-execution-exploit.html
http://www.milw0rm.com/exploits/6178

On August 12, I upgraded to Coppermine version 1.4.19.  The earliest date on any of the files is August 18. So, I must conclude that this exploit occurred after the 1.4.19 installation.  I am a bit embarrassed that I have been carrying this malware since August 12 but I thought that it would be wise to report it anyway.  I have created a tar ball of the directories and files created by the exploit and I would be happy to provide that to Coppermine developers as well.  I have removed all of the malicious files and directories from my system.  However, since I have been running the most recent version of Coppermine, I continue to feel quite vunerable.

I hope that this is the correct place to report this type of problem. Someone please reply with advice and instructions on how to prevent this type of thing occurring in the future.

Thanks,

Gordon Dickens

[gldickens3]

I want to add that the exploit's parent directory was named "modules" and  located in <document root>/gallery/include.  In other words, the path to the exploit's parent directory was <document root>/gallery/include/modules

[Abbas Ali]

The exploit you mentioned above has been fixed in cpg1.4.19 Your site might have been hacked before upgrading to cpg1.4.19.

Read Yikes, I've been hacked! Now what? to clean your site.

[gldickens3]

I understand that  1.4.19 was supposed to fix this exploit.  However, the date stamps on all the files and directories indicate that the exploit occurred after I upgraded to 1.4.19.  That is, I installed 1.4.19 on August 12 and the earliest date stamp in the malware files is August 18.  So, it appears that the attack succeeded on version 1.4.19 and I am therefore very concerned about the vulnerability of version 1.4.19 as well.  Please advise.

Thanks for the link covering recommended actions.  I had already done much of what is recommended and I will complete everything else today.

Gordon Dickens

[Joachim Müller]

If the attacker exploited the vulnerabilities pre-cpg1.4.19 by uploading a back door to your site and then uploaded the payload after you have upgraded, the results would be exactly as you described. Time-stamps can be manipulated as well btw. I'm not trying to find excuses, but it's pretty hard to say anything without more details: after upgrading to cpg1.4.19, did you scan the gallery for backdoors as suggested in the "Yikes" thread that Abbas has refered to? Did you run versioncheck? Can you get access to the server's logs?

[gldickens3]

Gau Gau,

I discovered some new information that you should be happy to hear. I believe that your back door theory, where the backdoor was planted prior to my upgrade to 1.4.19, is correct.

Today, I happened upon a backup of my coppermine files (that I had forgotten about) that was made on August 11, one day prior to my upgrade to 1.4.19 and there is a php file in <document root>/gallery/include/modules named gzip.lib.php.  This file does not appear to be a coppermine file, is not part of the 1.4.19 software and it definitely pre-dates my upgrade to 1.4.19.  While this file had a later date (after my 1.4.19 upgrade) when I discovered it two days ago, it obviously existed prior to the upgrade. So, it does look like the file dates had been altered.  While I am not yet 100% sure, I now believe that this file was the back door which subsequently uploaded the payload which constituted the exploit. In answer to your other three questions:

Did I scan the gallery for backdoors following the 1.4.19 upgrade: NO
Did I run version check: YES
Can I get access to the server's logs: My logs don't go back to August so the answer is: NO

In any event, I just wanted everybody to know this since it is important to understand that the exploit probably was not planted on 1.4.19.cd

FYI,

Gordon Dickens

[Abbas Ali]

Thanks Gordon for reporting back. I hope you have removed all backdoors and payload from your live site. If not then do so at your earliest. Since we got the root of the problem i am marking this thread as solved.

Abbas

[gldickens3]

Hi Abbas and Gua Gua,

I decided to just do a fresh install instead of attempting to identify everything in my prior installation that needed to be removed.  I felt that would be safer since I then know conclusively that nothing exists in that installation that I didn't put there myself.  In addition to backing up my mysql databases, I do periodic rsync backups to several other linux servers (one of which was the backup that I found yesterday) and so the fresh install was not difficult. I do have a custom theme and I have implemented several modifications but it was also easy to review and re-implement those mods without any problems.  In any event, I am now confident that I have a clean installation going forward.

Thanks for your help and assistance!

Gordon Dickens

[Joachim Müller]

Thanks for resolving your thread. If you need a more thorough analysis, please zip the potential backdoor file and attach it to your posting. We'll download it and then remove it so it won't do harm.

[gldickens3]

Gau Gau,

Attached it the file that I believe to be the back door exploit.  I hope that you find this useful.

Gordon Dickens

[Joachim Müller]

Confirming: the file you posted is the backdoor the attacker left behind after his initial attack. The file doesn't do anything special except creating folders and files - that's the payload of the attack that you suffered from. Not related to the initial attack in the first place: the file doesn't exploit the vulnerability in coppermine, but contains mechanisms of it's own. When run in the browser (http://yoursite.tld/your_coppermine_folder/gzip.lib.php), the file doesn't do anything yet: it requires certain parameters in the URL and some input that the attacker submit from another server to actually do something harmfull.
The file has been named that way to disguise itself - it's rather a sort of remote control that the attacker can use to upload all sorts of files to your page. Probably probing apps, warez, phishing sites or porn have been uploaded to your server using the malicious file.
I have removed the file attachment from your posting to make it harder for script kiddies to get hold of such a file that they could use against other sites.
Thanks again for your report.