Support => cpg1.4.x Support => Older/other versions => cpg1.4 permissions => Topic started by: Joachim Müller on April 15, 2008, 04:44:00 pm

Title: Yikes, I've been hacked! Now what?
Post by: Joachim Müller on April 15, 2008, 04:44:00 pm
There have been efforts of users who have fallen victim of hacking attacks to share their insight with others. However, you need to understand in the first place that not all hacking attacks are the same: once an attacker has managed to break your site's security, he can do virtually anything. Some hackers may just deface your site (i.e. display an unwanted message or ads on your page), others may abuse to store your site to store content (malware, warez, porn etc.).
There is no saying what the hacker may have done to your page, so I suggest you don't believe in simple recipes from a cooking book that say "delete file X and Y and you will be good". Instead, believe me: there's no saying what the attacker may have done, so you better clean your site thoroughly.
Title: Scope of this article
Post by: Joachim Müller on April 15, 2008, 04:44:20 pm
Scope of this article
I have created this article as a result of the attacks performed by the site owner of that has been discussed in the thread "Someone has Redirected my Site to do I do? (,51671.0.html)", and I'll refer to a coppermine-driven gallery and how to clean it, but this thread should give you an idea as well how to clean any hacked site.
I will try to write the instructions for users with intermediate skills - I assume that you have read the coppermine documentation, that you know your way around in your FTP app and have good skills on your Windows-driven client PC. I'm sure that there are easier methods to clean your site for power users - Linux users might want to perform the cleaning directly on the server's shell. Those users probably know what to do anyway and don't need the advice posted here.
If the instructions posted here are over your head you better seek professional help from a computer specialist - consult your webhost for a start in that case, but don't expect them to perform the job for free: it's your task in the first place and you can't expect others to do your job. Your webhost might offer sanitization of the site as a paid extra.
Title: The simple method
Post by: Joachim Müller on April 15, 2008, 04:44:40 pm
The simple method
In an ideal world, you'd be making regular backups of everything, so you could just restore your backup to the stage before the hack. You'd then just have to close the hole that the attacker used to get into your site and you'd be good. But I'm aware that this is not an ideal world - you probably don't have a backup. You wouldn't be reading this article if you had one ;-). I understand that - we're all human. But as a result of the disaster with your site getting hacked, you might want to perform regular backups in the future.
Title: So what do you have to do?
Post by: Joachim Müller on April 15, 2008, 04:44:56 pm
So what do you have to do?
First of all: don't panic! You may be tempted to delete everything that looks funny or causes issues, but this might result in losing precious data. So here's what we'll do: first, create a backup of all files (including the infected ones). Then, create a backup of your database. Next, we'll close the hole the attacker used to get control over your site. Finally, we'll clean all files and unwanted database entries.
Title: Back up ALL files that reside on your webhost to your client PC
Post by: Joachim Müller on April 15, 2008, 04:45:17 pm
Back up ALL files that reside on your webhost to your client PC
No matter what security hole the attacker has used to break into your site, the payload of the hack (i.e. the files that the attacker has tampered with or created) might reside all over your site - even outside your gallery folder. Therefore, you'll need to make a backup of all of the files that reside on your webspace, even the files that reside outside of your webroot (one level up).
So you better use your FTP app (use a real FTP app, not a lame crutch like a web FTP application or something built into your editor) and start the backup. Depending on the amount of files on your webserver and your connection speed, this may take some time. You better use an FTP app that is capable of re-connecting and continuing the backup even if it gets interrupted. The coppermine dev team recommends FileZilla or Smart FTP (see "Tools recommended by the devs (,31423.0.html)").
As a target for the backup, create a new folder on your desktop PC, e.g. c:\working_copy\ - I'll refer to that folder name in this thread accordingly.
For this article I will asume that your coppermine gallery doesn't reside in your webroot, but within a sub folder named "coppermine", so your gallery URL is http://your_site.tld/coppermine/. Subsequently, your actual coppermine files in your working copy should reside in c:\working_copy\coppermine\. It doesn't matter if this is not the case for you - probably, the folder is named differently or your gallery resides in the web root - I just needed a naming scheme in this article to follow; make the changes accordingly. Please note: I'm not suggesting that you rename your gallery's URL or the folder names of your local copy: keep them as they are. I'll just refer to the folders in this article accordingly.
We will use the folder c:\working_copy\ as a working copy (i.e. we will later modify the files that reside in that folder), so you should make a copy of that folder to another location to keep a forensic copy in case you need it later. That second copy should reside in a safe place - you might even burn it to a CD or DVD. You're welcome to store it inside a ZIP archive. For this article, I'll assume that you have stored this copy in c:\forensic_backup\
Title: Backup your database
Post by: Joachim Müller on April 15, 2008, 04:45:51 pm
Backup your database
Many users shy away from performing a database backup because they are not used to it. However, it's mandatory that you learn how to perform such backups anyway, so at least now after you have issues with your site being hacked, you'll need to learn it "the hard way".
I understand that newbies will find it hard to understand how to perform a backup, and you might find it frustrating being told to learn about additional apps like phpMyAdmin or mySqlDumper instead of going ahead and just sanitizing your gallery. Therefore, skip this step (backing up the database) if you're really busy, but perform it later - after having performed the other steps below.
Title: Put your gallery into maintenance mode
Post by: Joachim Müller on April 15, 2008, 04:46:09 pm
Put your gallery into maintenance mode
Go to your gallery's URL, log in as admin, go to coppermine's config, scroll to the bottom and enable within the section "Maintenance settings" the option "Gallery is offline". Save your changes. This is meant to make sure that while we're in the process of sanitizing the files locally your users don't upload additional files that would get lost.
Putting your gallery into maintenance mode will not accomplish anything in terms of sanitizing your gallery - the only benefit will be that the legitimate visitors of your site won't be adding content after having performed the backup that might be lost later. If you can not access coppermine's config to set your gallery offline, skip this step; it's merely cosmetical.
Title: Get the most recent coppermine release
Post by: Joachim Müller on April 15, 2008, 04:46:29 pm
Get the most recent coppermine release
Go to coppermine's download section ( and get the most recent stable coppermine release (currently cpg1.4.19). Download it and unzip the file to a temporary folder on your hard drive. For this article, let's assume that you have downloaded and unzipped it to c:\cpg1419\.
Title: Replace the files in your working copy with files from the most recent release
Post by: Joachim Müller on April 15, 2008, 04:47:43 pm
Replace the files in your working copy with the files from the most recent release
As suggested in the upgrading section of the docs, copy the entire content of the most recent release you just downloaded (the content of c:\cpg1419\) over the working copy of your coppermine folder (c:\working_copy\) except the file anycontent.php. If your coppermine gallery resides in the webroot (e.g. your gallery is accessible under the URL http://your_site.tld/) and you have no folders one level above the root folder, you have to copy the content of c:\cpg1419\ into c:\working_copy\. If your gallery URL is http://your_site.tld/coppermine/, you'll have to copy the content of c:\cpg1419\ into c:\working_copy\coppermine\. Make sure to overwrite all files in your working copy (except anycontent.php) with the files from the new release, as explained in the upgrade section of the docs. This is "business as usual", i.e. it is the same as if you were upgrading without the need to sanitize anything. Don't upload the files from your working copy to your webserver yet, we still need to sanitize things.
Title: Get a diff viewer
Post by: Joachim Müller on April 15, 2008, 04:48:03 pm
Get a diff viewer
For sanitization purposes, we'll need a diff viewer. A diff viewer is a piece of software that will compare folders and files and will display the difference between files. The coppermine dev team recommends the free tool WinMerge (see "Tools recommended by the devs: WinMerge (,31423.msg229891.html#msg229891)"). Download that tool and install it on your PC.
Linux users should use the free tool Meld (
Title: Compare the working copy and coppermine's core files
Post by: Joachim Müller on April 15, 2008, 04:48:46 pm
Compare the working copy and coppermine's core files
Now this is the step most regular coppermine probably are not familiar with: we'll use the diff viewer to see what files that might be harmful exist in your working copy. For this, you'll need to understand some things first:

Now, let's start our diff viewer (WinMerge) using the shortcut on your desktop or from your start menu. You'll notice that at the very start of the application, there is a dialog that asks you to specify two folders (the two folders we're going to compare). Use the "browse" button and navigate to the folders we want to compare. For the left pane, browse to the folder that contains the clean coppermine archive that you have extracted to c:\cpg1419\ previously. Make sure to choose "Folder selection". For the right pane, select the coppermine folder of your working copy (c:\working_copy\coppermine\), again with "Folder selection" for the file name. Once you set both folders to compare, tick the option "Include subfolders" and hit "OK". Winmerge will then start comparing your folders and after a while (depending on the size of your gallery) come up with a result screen.
On the result screen, click on the "folder" tab to sort the results by folder name, then click one "View" - and disable (untick) the option "Show identical files", since we don't want to display safe files (i.e. files that are identical in your working copy and your fresh coppermine package).

We'll now take care of potentially dangerous files. For this, you'll have two options later:
Decide for one method now (or later) - anyway, we'll delete the malicious files from our working copy right now, so let's start:
Title: Compare custom files outside of coppermine's root folder
Post by: Joachim Müller on April 15, 2008, 04:51:54 pm
Compare custom files outside of coppermine's root folder
You should by now know your way around in WinMerge. If Coppermine is not the only app on your webserver, you will have to scan everything else outside of coppermine in the same way you just scanned the coppermine folder: if you for example use phpbb, it's possible that the attacker has managed to break into your site using a vulnerability in coppermine, but has uploaded the payload (i.e. the malevolent code) not into coppermine folder, but into the phpbb folder to cloak his hack from you. Therefore, you have to sanitize the entire site. If you're using another pre-made script like phpbb or SMF, do exactly the same thing you did for coppermine: download the fresh package of your "other" application, then use WinMerge to compare the working copy (that corresponds to the live-content on your webserver) and the fresh (vanilla) copy of the "other" app.
The same thing is the case for custom content: if you have created "hand-made" content, you have to make sure that it hasn't been corrupted on your server, so you should use WinMerge to compare your local, untampered copy with the working copy that represents your webserver's content.
Title: After sanitizing the working copy, clean up your actual webspace
Post by: Joachim Müller on April 15, 2008, 04:52:34 pm
After sanitizing the working copy, clean up your actual webspace
So far, we have only cleaned the local copy that represents your webspace. We'll have to upload the sanitized files and get rid of the ones that we deleted locally. That's why I suggested to make a note of what you did before. In case that you don't want to delete the entire content of your webspace and then upload everything from your local hard-drive (maybe because you're not sure that you have done everything as you should or because you haven't understood parts of this article), you can use an alternative: you have already found out about the powers of WinMerge, so let's use it as well to figure out what needs to be uploaded to your server or deleted; for this, you should close WinMerge and re-start it. Then select the working copy (the folder that contains all your edits) for one pane and the backup that you have made of that folder before modifying it (we named it c:\forensic_backup\ in one of the above steps) for the other pane. Again, choose not to display identical files. What you have then in WinMerge's results screen is a list of files that only exist in your working copy, but not on the forensic backup and vice versa, and files that exist in both folder that differ. Files that only exist in the forensic backup folder, but not in your working copy need to be deleted from the webserver as well. Files that differ in both folders need to be uploaded from the working copy to your actual webspace. Now it's time to start your favorite FTP app and perform the needed transaction - deleting the unwanted files, replacing the updated files on your webserver. Make sure that your FTP app is configured to actually replace existing files (some FTP apps by default are set to not replace existing files - you may have to override that default behaviour).
This is the step you need to perform very thoroughly. Don't perform this if you're tired or not concentrating - making a mistake here might result inYou need to really understand what you're doing.
Title: Perform the database upgrade
Post by: Joachim Müller on April 15, 2008, 04:52:53 pm
Perform the database upgrade
So far, we have done two things: we have upgraded coppermine (as we copied the clean coppermine package over the local working copy) and sanitized the gallery. As suggested in the docs, you need to perform another step to finish the upgrade: you'll have to run the corresponding script in your browser at least once (it won't hurt to run it several times). Going to http://your_site.tld/coppermine/update.php should do the trick.
Title: Scan the database for admin accounts
Post by: Joachim Müller on April 15, 2008, 04:53:18 pm
Scan the database for admin accounts
The attacker may have left backdoors that allow him to get into your gallery later and doing whatever malevolent things he's up to. This usually happens using two methods: they leave one or more script files on the webserver that allow them to take over control (we should by now have taken care of that by sanitizing all unwanted files in the working copy) and/or they create an admin account in your hacked application that allows them control over the site later. Therefore, you'll have to go to your gallery in your browser, log in as admin and review the user list - you need to make sure that none of the accounts that are not supposed to be admins actually have admin privileges. To accomplish this, click on "Users" from the admin menu (or go to http://your_site.tld/coppermine/usermgr.php directly) and then click on the arrow-up icon (to sort in ascending order) in the "Group" column to sort your user list by groups. All admin accounts (membership in the group "Administrators"). If you see an admin account that you haven't created, delete it.
This can be a time-consuming task for large galleries with a lot of user accounts, so this is where your mySQL database dump that you have created before comes into play; alternatively, you can use phpMyAdmin and browse your members table. What we're looking for are members that are members of the group number 1 - find them and get rid of all illegitimate accounts.

If you are running coppermine bridged to another app this step does not apply, but you should check your forum for added admin accounts just in case.
Title: Review your config options
Post by: Joachim Müller on April 15, 2008, 04:53:37 pm
Review your config options
Some hacks (like the one that lead to the release of cpg1.4.18) perform changes of coppermine's config, so you'll have to undo those changes. In an ideal world, you would have a backup of your database, so you could just restore the config table. But sadly, you probably don't have that backup, so you'll have to log in as admin and go to coppermine's config. Go through all settings and review them - if you're not sure what a particular setting does, use the help icons or look the setting up in the documentation that comes with coppermine.
The notorious cdpuvbhfzz hack (,51671.0.html) changed the size of the intermediate-sized image to one pixel, so you'll need to restore that to what you had before.
Title: Review groups permissions
Post by: Joachim Müller on April 15, 2008, 04:53:58 pm
Review groups permissions
There is a slight chance that the hacker has changed the settings on the groups page as well - as an example, he might have enabled anonymous comments to be able to flood your gallery with comment spam. Although this is not directly related to security in the first place, you should go to your groups page as well and review the settings there.
Title: Disable offline mode
Post by: Joachim Müller on April 15, 2008, 04:54:19 pm
Disable offline mode
Once you're done with all the sanitization works, don't forget that your gallery is still in offline mode, so you better go back to coppermine's config and disable offline mode there.
Title: Alternative sanitization methods
Post by: Joachim Müller on April 15, 2008, 04:54:42 pm
Alternative sanitization methods
Particularly for the cdpuvbhfzz hack (,51671.0.html), there are two sanitization scripts available, one as a PHP file (,51671.msg251701.html#msg251701) and one as a shell script (,51671.msg251771.html#msg251771). I don't think that they will work in every case and haven't looked into them, so there are no guarantees.
Title: Read on
Post by: Joachim Müller on April 15, 2008, 04:55:00 pm
Read on
This thread has got a second page. You just reached the end of the first page. The thread is not over yet. Yes, I admit that it's a long thread and that it has been a lot of reading so far, but it won't be much more - I promise.
Click on the tab at the very top or bottom of this page that will send you to page 2 of this thread. Alternatively, click here: go to page two of this thread (,51927.20.html).
Title: Hidden files
Post by: Joachim Müller on June 19, 2009, 07:53:33 pm
Hidden files
On Linux/Unix driven webservers (most webservers are Linux/Unix-driven, which is great in terms of stability and performance), hidden files/folders have a leading dot in their names. This is different on Windows, but easy to understand.
As the name suggests, hidden files usually are not being displayed. That's a fact that legitimate applications like the webserver "Apache" use: the configuration file for that webserver usually is a hidden file named .htaccess (mind the leading dot). The presence of a .htaccess file (and even several of them) is not a bad thing in itself, nor is it an indication of a hacking attempt if  there are one or more of those .htaccess files on your server. Your server and the FTP application you use to control it usually is configured not to display hidden files (remember: they start with a dot in their name), so you won't be aware of .htaccess-file(s) existing on your webspace. However, with such a webserver configuration file, hackers can do all kinds of unwanted things to happen, like redirecting. Hackers often use the fact that their victims are not very experienced and therefor hardly know about the power of .htaccess files.
There is an exploit (the payload of a hack) that drops a .htaccess file into the gallery folder that redirects all images to google, which results in all images embedded into your gallery appearing to be broken.
Therefor: before starting the sanitization by downloading the working copy to your PC, make sure that hidden files (if they exist) are being transfered from your webspace to your local working copy: this way, you can examine .htaccess files that may exist on your webspace. Those .htaccess files are plain-text files that you can view with any plain-text editor (notepad.exe will be fine). If you're not sure about what a particular .htaccess file does, just temporarily remove it from your server (i.e. keep a backup somewhere) and test if anything works as expected. You might just as well rename it (e.g. from .htaccess to htaccess_renamed) to check. There may be .htaccess files on your webspace that your webhost put there, so don't panic if you see such a file. When in doubt, ask your webhost for support - ask them if they put the file there. Alternatively, post the content of your .htaccess file on the support board if you're not sure and ask for help with it.
Coppermine itself doesn't come with a .htaccess file, so if neither you nor your webhost have created a particular .htaccess file, it probably is the payload of a hacking attempt, so try to delete it (keep a backup!) and see what happens then.
Title: No support
Post by: Joachim Müller on June 19, 2009, 07:54:40 pm
No support
I'm not ready to support this thread, it comes as-is, as a courtesy for those who find it helpful. Please do not start new threads that refer to this thread with further question. Under no circumstances are you allowed to contact me individually (by PM or email).
Title: Re: Yikes, I've been hacked! Now what?
Post by: Joachim Müller on June 12, 2010, 10:00:22 am
Jeff aka onthepike has come up with an excellent summary as well
Steps in attempting to identify a potential threat and/or embedded malware.

First and foremost, a few things bear repeating: You, as a webmaster, regardless of skill level, are responsible for your website, and responsible for the safe passage of visitors to and from your web space. You are responsible for maintaining a safe environment, which means, but by no means is limited to, keeping whatever applications/scripts/programs you have running (or available) as up-to-date as possible. Do not expect your web host, a volunteer or anyone else to come to your rescue should disaster strike. A good webmaster understands these basic principles and takes steps towards that end.

These steps include keeping all scripts up-to-date by regularly visiting that programs homepage and/or support forum and subscribing to their newsletter (if applicable). These steps include setting proper permissions on files and directories. These steps include removing old or unused scripts from the web space (or removing read/write access to these scripts if they are necessary for documentation purposes).  These steps include backing-up. It cannot be stressed enough how important it is to regularly back-up your files. While it can be very time consuming to fully back-up your web space, consider the alternative -- being directed to this thread overwhelmed with fear, frustration, anxiety, stress and confusion. Weighing these, backing up really isn't that bad after all! And in some cases, may be your only recourse in reviving a site that's been infected with malware, etc.

The above topics have been covered within this Yikes thread. This post deals with actually identifying a (hidden or otherwise) threat that's embedded in your web space. The webmaster, of course, has (or should have) full and complete access to the servers file and directory structure. As a site visitor, options are much more limited and restricting. Still, there are available tools to help identify potential threats. Some are outlined below:

  • Unmask Parasites ( Scans entered website seeking embedded malware, known signatures and potential unsafe links and redirects.
  • Norton Safe Web ( Similar to above, however relies on cached results based upon prior automated scanning. Also allows comments from registered users, which can prove helpful.
  • Google Safe Browsing Diagnostic ( Cached results of malware scanning.
  • McAfee Site Adviser ( Uses a cached database to display results of previously scanned websites.
    Trend Micro Web Reputation Search ( Similar to Norton Safe Web and uses cached results.
  • Virus Total (*: Virus Total is a service that analyzes suspicious files  and facilitates the quick detection of viruses, worms, Trojans, and all kinds of malware detected by anti-virus engines. Works in real-time as well as cached results. *Note however, this tool is best suited for webmasters in most cases.

In addition, an excellent supplemental article to this Yikes thread, and a generally informative outline regarding repairing an infected website can be found here: How to prevent your site from getting hacked. How to repair a damaged site. Website security precautions. ( Extremely large galleries with many hundreds or thousands of files and folders may benefit from utilizing cron to list all the files in your (Linux) website (, where the output may be visually inspected to verify no rogue files/folders and their permissions.

Important: Before attempting to resolve a website issue, it is imperative that you first activate the anti-virus program of your choice and update it to the latest definitions. Activate your backup anti-malware program (such as Malware Bytes and/or SpyBot Search & Destroy's IE Resident -- if applicable) and fully scan your computer to identify and resolve threats there before accessing an infected website. It makes no sense to cleanse a website of an infection that your own PC may re-infect upon access. Resolve your PC issue(s) first, then move onto your website issue. After successful scanning of your virus-free computer, and using each of the tools listed above, carefully scan the infected website.

As a visitor, I begin with Unmask Parasites, a scanner that uses both cached results from previous scans as well as real-time scanning to identify possible threats and suspicious links (to known malware sites).  The scanner will display results as well as potential suspicious links and scripts. Viewing the source code of a given page will accomplish some of what Unmask Parasites accomplishes, but doesn't "red flag" anything. A supporter or helper has no way of knowing what external links are legitimate and what external links are problematic. Unmask Parasites (as well as the rest of the tools) will highlight these for you for later review -- or in some cases -- provide an in-depth explanation of the type of risk identified. Or both. Note any suspicious links or scripts and rescan again using the rest of the above tools. Upon scan completion, we should now have a pretty good idea of where to begin. Compile the list of suspicious items and head to your favorite search engine and begin the process of identifying each suspicious link and script.

Armed with whatever knowledge learned from searching, begin the process of removing potential threats.

Identify the obvious first, if possible. Visually inspect the directory structure in question (and in some respects, in general) and scan for blatantly obvious files and/or folders that aren't part of the Coppermine directory structure. Coppermine utilizes a meta-redirect within index.php files, so unless the webmaster has explicitly added them, there should be no .htaccess files; especially under the /albums directory tree. Some legitimate plugins do include an .htaccess file; verify these by inspecting with Notepad (or any other equivalent plain-text editor). In general however, an .htaccess file usually resides within the /www or /public_html directories and is usually legitimate. Note however, this file can be hijacked as well, so a visual scan and inspection of this file is a must, if such file exists. If an .htaccess file is indeed found within the /albums directory tree, delete it/them. And all others found under this directory.

If, after inspection, files and/or folders are found that shouldn't be there, delete them. If, after inspection, files and/or folders are found that shouldn't be there and can't be deleted or modified, the webmaster's options are limited.

The first step is to verify file ownership and permissions. The file in question should be "owned" by the domain name (or name that your host has given you). Verify ownership from the web host's control panel (usually cPanel or similar) file manager. While FTP apps prove extremely useful for most website publishing needs, most FTP apps do not furnish the required authentication necessary to take ownership of a rogue file or folder. So it's best to utilize the online file manager that comes as part of your domain package. Attempt to delete the folder in question. If this fails, attempt to change the permissions of the file in question to 755 (0755). If this fails, you will need to contact your web host and seek assistance in deleting the file.

Once the rogue file/folder has been removed, website cleansing may resume. Upon completion, gallery restoration, including database manipulation, if necessary, may begin.