Hackers


#1

One hacked site is a blog, run only on Word Press. The solution to the first hacking and takeover was to upgrade to a new version of Word Press through the One Click procedure. That was done, but the site was hacked again. Do other bloggers have problems with Word Press? Are you saying Word Press is the problem? The other site, hacked once so far, was done in Dreamweaver. Out of 6 Web sites, most hosted by others over the past ~8 years, this is the only time a security breach has ever occurred. All routine precautions and protections on our end are in place. Passwords were changed after the first hacking. No one has access to those. Please explain how the hacker got access to the DOMAIN. If the domain is on the server… and the software is on the server… isn’t the hacker there, as well?


#2

Did you remove the “.old” directory created by the “one-click” upgrade (beta!) process? If you left the “.old” directory on the server, an attacker with knowledge of DH could continue to exploit any vulnerabilities that may have been present in the older version of WordPress.

You said that the “solution” was to upgrade WordPress. Did your access logs give you any indication that WordPress was the culprit? Could it have been a WordPress “plugin” that was exploited? If so, reinstalling the plugin to the “upgraded” WordPress might have “reinstalled” the vulnerability.

Not at all. My experience with numerous WordPress installations has been exactly the opposite. While any script has the potential to be exploited, WordPress has been thoroughly vetted, and is a very robust application. Again, a careful inspection of your access and error logs around the time of the corruption, close attention to your stats information (esp referrers and failure reports), and a close inspection of your files and directories should give you a clue as to the vector of attack.

Unfortunately, that provides very little additional information to help us track down the problem; it only describes the tool used to create the site and not the code that was present.

Changing the passwords is a “good thing” and since you are sure “no one has access to those” I can only assume that you have never used telnet to access your server, do not use the same password with your email account(s), have not used a wireless connection to administer your account, etc. I’m not sure what you mean by “routine precautions”, but hopefully that includes regular inspection of all your server logs, making sure no files on your server have permissions set any more loosely than absolutely necessary to provide the necessary functionality, and periodic (especially in the wake of the attacks) inspection of your files and directories looking for things like inappropriate modifed file dates/times, files you do not recognize, etc. Have you logged into your server space with SSH and stepped backwards through the command line history to see if there are commands in the history that you do not recognize? In my experience, one (or more) of those procedures has always provided a clue to the source of the “hackish” activity.

I cannot answer your question, as I do not have access to your server, logs, or code, and have not seen your site in it’s native state. I have given you several suggestions as to where to look to attempt to determine that. Should you put the site “back up” in it’s pre-hacked state and provide me with the url, I would be happy to take a look at it in hopes of spotting a potential vulnerability if you think that might be helpful. I still believe, however, that the previously described steps will provide you with a better starting point, as you can do that before you re-build the site(s) and see what tracks the attacker left.

As for “domain is on the server/software on the server/hacker on the server” question, well, yes, I suppose in some sense that could be true depending on what you mean by “on”. The whole process initiated when as user visits a site (asking for, loading, sending, and displaying a webpage) actually takes place “on” (or “over”) a whole lot of different machines and networks. There are a lot of potential “holes” in this process and lot’s of ways to “attack” a site. Most commonly, the attacker has manpulated files residing in your public webserver directory by means of a scripted exploit, compromised passwords, loose permissions, or a combination of those items in order to modify what is displayed to a visitor to your site (or send spam from your site, or other malicious activity).

The challenge is to find out how they “got in”, and only you have the tools to pursue that. We can help you interpret what you find, but we cannot do it for you,as we do not have access to the resources needed to investigate.

The answer likely lies somewhere within your directories/logs/stats and the actual files on your site.

I don’t want to sound discouraging, as the answer can almost always be determined with proper investigation. I just want you to understand that, while anything is possible, my experience in hosting dozens of sites with Dh since 1998 has proven DH to be one of the most secure providers I have encountered. Most of the idiosyncratic characteristics of the DH Debian Linux distro DH runs, “restrictions” on the use of certian modules, DH “quirks”, etc. are the result of DH’s high attention to possible security risks and their attempts to ensure a secure environment. I have not yet encountered a server based vulnerability exploited at DH; I have seen numerous “hacks” of sites on DH that were perpetrated in various other ways due to the code on the site or other previously described “routine” security exposures.

If you have any additional information re. the above mentioned items and wish to share, I’ll be happy to help you investigate further. Anecdotal statements like “Out of 6 Web sites, most hosted by others over the past ~8 years, this is the only time a security breach has ever occurred” are only helpful in helping us understand your frustration. Unfortunately, we need “hard” information to help you determine how your site was compromised.

–rlparker


#3

Are you sure it is not an “inside job”

What is running at the Dreamweaver site? Any scripts? You need to look at your scripts. Plain HTML is safe unless there is some way hackers are exploiting scripts to gain access to your backend.

Third party scripts are third party scripts. If you want to install them and use them to run your website, you need to make sure you understand what you are dealing with. Go to the script development forums and see what sort of security issues are being discussed/fixed.

Also, remember that these scripts are open-source. They are being developed constantly by their communities.

After a hack (I have been hacked) you need to get rid of all traces of the intruder. Often, restoring from a pre-hacked databse is a good start.

Were you using the same password for your FTP as for your admin of wordpress? If so, your hacker knows it unless you changed it.

Wordpress is not particularily vunerable to hacking, although it is not immune.

If I were you, I would delete everything, re-upload the dreamweaver pages, install a new wordpress and populate it from a pre-hacked back-up of your database.

DH uses mod_security to protect sites from hacking attempts. Make sure it is enabled at your site.