UPDATE: They're still here. Help me stop or trap them!

Hi SF'ers,

I've just had someone hack one of my clients sites. They managed to get to change a file so that the checkout page on the site writes payment information to a text file.

Fortunately or unfortunately they stuffed up, the had a typo in the code, which broke the site so I came to know about it straight away.

I have some inkling as to how they managed to do this:

My website CMS has a File upload area where you can upload images and files to be used within the website. The uploads are limited to 2 folders. I found two suspicious files in these folders and on examining the contents it looks like these files allow the hacker to view the server's filesystem and upload their own files, modify files and even change registry keys?!

I've deleted some files, and changed passwords and am in the process of trying to secure the CMS and limit file uploads by extensions.

Anything else you guys can suggest I do to try and find out more details about how they got in and what else I can do to prevent this in future?

If your (client's) site has already been compromised, then you should first take it offline. You have no way to prove easily that the hacker didn't install a rootkit. You have to assume that all data on that serve has been compromised, and potentially lost. For your sake, I hope you weren't storing credit card or other payment data in a SQL database unencrypted, or storing it encrypted with the key somewhere on the same system.

Then you have to rebuild it from a known good image, and restore from the last known good backup. That is the only way to be sure. Nuke it from orbit.

As far as figuring out how they got into your system, have a look at the event logs for when people logged in, and possibly audit logs too, might tell you if they executed any code from the upload area. This will serve as a good learning experience for you, especially when it comes to executable permissions on publicly accessible areas of the website, as well as auditing and logging.

Your first priority must be to rebuild the site on a known good server, and protect that more heavily that the original site was.

You might find this "Recovering from a compromised system" an interesting read.

RobertMoir's highly acclaimed answer to this question might help you out too.

My website CMS has a File upload area where you can upload images and files to be used within the website. The uploads are limited to 2 folders. I found two suspicious files in these folders and on examining the contents it looks like these files allow the hacker to view the server's filesystem and upload their own files, modify files and even change registry keys?!

It is for this very reason that file-upload-areas are exceedingly dangerous. You have to take great steps to ensure that uploaded content can't then be re-used as part of a hack attempt. If you block executable content, a script vulnerable to XSS somewhere else on the site might be able to call that code and run it under its own context, which is executable.

They got in by uploading something they could later run. Perhaps they called it directly, in which case you need to make sure only non-executable content can upload to those directories. Perhaps they invoked it from some other script, discovering this will require digging through log-files to see what script invoked those files you identified, and then secure the script.

Once you rebuild your server, take a closer look at these holes and re-evaluate the need for the upload directories.

If you running asp.net and only as you tagged on SO, then you only need to add this web.config on the root directory that your users upload files. With that web.config you do not allow anyone to run aspx pages on this directory tree.

<configuration>
    <system.web>
      <authorization>
        <deny users="*" />
      </authorization>
    </system.web>
</configuration>

The most important thing is to ensure that if you have any upload areas, those areas are prevented from having any executable files within them.

If the area is web accessible and the uploads can be anything - all they need do is upload an aspx/php/etc script to that location and navigate to it to activate.

Prevent this by:

• renaming files on upload
• checking the file type by content before you move it to the location
• setup your webserver not to allow scripts to execute within that location
• if the upload location does not need to be web accessible, move it outside

If they have access at the moment, particularly if they have for awhile, with custom software that you may not find with virus checkers, ensure you have a clean copy of your code that they have not had access to elsewhere; then rebuild the server. Yes it probably is totally unnecessary if they only had limited access, but if you don't know, then take no chances.

Oh yes, obviously change all passwords everywhere. If your website has accounts that have a readable password database, those two. If your website hosts personal data of users, you probably need to inform them and possibly the authorities depending on your national law.

From the IIS log you should be able to findout when the files were upload and which ip address they came from