Here is the report back from ABUSE Support folks last week. These are the corrupted files that I believe our original developer/support person fixed but I’m not sure he did all of them. He confessed that the security issues were beyond his scope of work experience. I’m not clear about setting up the the default ‘755’ permissions setting for directories, and ‘644’ for files. Is that something you can do or tell me how to do? Are there other things we need to do to keep hackers like the one that got into our site from having such access in the future?
- - - - - - - -
[wilboy5 59216844] Web site sign in problem
From: DreamHost Security / Abuse Team [mailto:email@example.com]
Sent: Tuesday, June 19, 2012 6:08 PM
Subject: Re: [wilboy5 59216844] Web site sign in problem
1) Update all pre-packaged web software to the most recent versions available from the vendor. The following site can help you determine if you’re running a vulnerable version:
You should check ALL domains for vulnerable software, as one domain being exploited could result in all domains under that user being exploited due to the shared permissions and home directory.
2) Remove ALL third-party plugins/themes/templates/components after upgrading your software installations, and from those that are already upgraded under an infected user. After everything is removed, reinstall only the ones you need from fresh/clean downloads via a trusted source. These files typically persist through a version upgrade and can carry hacked code with them. Also, many software packages come with loads of extra content you don’t actually use and make searching for malicious content even harder.
3) Review other suspicious files under affected users/domains for potential malicious injections or hacker shells. Eyeballing your directories for strangely named files, and reviewing recently-modified files can help. The following shell command will search for files modified within the last 3 days, except for files within your Maildir and logs directories. You can change the number to change the number of days, and add additional grep exception pipes as well to fine-tune your search (for example if you’re getting a lot of CMS cache results that are cluttering the output).
find . -type f -mtime -3 | grep -v “/Maildir/” | grep -v “/logs/”
In scanning your michigandoc user we found 1 hacked files that we were able to try and clean. Backups of the original hacked files can be found at /home/michigandoc/INFECTED_BACKUP_1340143654 under your user, with a full list of the original files at /home/michigandoc/INFECTED_BACKUP_1340143654/cleaned_file_list.txt. You should verify that your site is working fully after being cleaned and then delete the INFECTED_BACKUP directory fully.
Likely hacked code / hacker shells that we could not automatically clean were found under michigandoc here:
IMPORTANT NOTE: One or more of your users has been found to have a file or directory with fully open ‘777’ permissions. This allows full read, write, and execute access to everyone on the server. This makes your site vulnerable because if there is another user on your server that is hacked or malicious they could be looking to exploit other users with improper permissions. You should always use the default ‘755’ permissions setting for directories, and ‘644’ for files. The directories/files listed below have been reset to these values, but you must keep this in mind going forward in case this was a point of intrusion. More general information on filesystem permissions for Unix/Linux systems can be found here:
- - - - - - - - - - - - - - - - - - - - - - - Files under michigandoc that had full write permissions:
Listed 5 out of 43 files. Full list located at: /home/michigandoc/bad_permission_files.txt.
- - - - - - - - - - - - - - - - - - - - - - -
For information specific to WordPress hacks please see: