Insecure websites are responsible for most malware infections. In this post I will show you how a typical WordPress site that was poorly configured got hacked, leading unsuspecting visitors to a very bad surprise.
If you can browse the underlying structure of a site, it is usually not a good sign. It does not mean the site has been hacked (yet!), just that whoever set it up does not really know what they’re doing… Unfortunately that makes the site a prime target for automated hacks. Let’s take a look at why this happens and what it can lead to.
File / directory permissions and ownership are crucial to a website’s security. They determine who is allowed to view, edit and run programs. If they are not managed well, they can lead to a compromise of the entire website.
Permissions are divided into:
- Read
- Write
- Execute
Ownership has the following categories:
- User
- Group
- Others
When looking at permissions and ownership on a Linux server, you will see something like this:
-rw-rw-r– 1 apache web 1208 Jan 29 09:48 index.html
In this case, we have Read and Write for the user, Read and Write for the Group, and Read for others. The user is apache and the user group is web.
File permissions are also often represented with numbers (one number for each owner):
- 1 – EXECUTE
- 2 – WRITE
- 3 – WRITE, EXECUTE
- 4 – READ
- 5 – READ, EXECUTE
- 6 – READ, WRITE
- 7 – READ, WRITE, EXECUTE
So, we need to add the 3 types of ownership to translate -rw-rw-r– into 664.
There are certain rules to go by when applying security permissions and ownership. You want to give the least amount of permissions needed by each owner and only add them as required.
So what exactly is the problem then? Well, many web apps can be a pain to configure if permissions are too strict. A lot of people will just enable all permissions to bypass this inconvenience. This is the infamous 777 (Read, Write, Execute for everybody). In fact, you will see such bad advice on many forums and while it may be helpful to set files or folders to 777 for debugging, it should never be done on a live site (only an offline test site).
As a rule of thumb, files should be set to 644 and directories to 755. That will work on most configurations but can certainly be hardened even more for specific files (for example .htaccess) or folders (wp-admin).
Case in point, when a website is poorly configured, someone can upload backdoors (program used to completely take control of a server) as well as alter core files. By injecting malicious code (iframe or other type of redirect), the bad guys will leverage a site’s traffic and send anyone browsing to it to some exploit site (i.e. a BlackHole Exploit page).
This is what happened here. Content was injected inside a legitimate JavaScript within the wp-includes folder (a prime location for malware because it often requires more laxed permissions). When the website loads, it calls various plugins to launch and render the page. Keep in mind that JavaScript is client side scripting, meaning that it will execute on the end user’s machine. So by infecting one single JavaScript, you can essentially load the malicious payload from any page of the site.
Here, a jquery.js has been injected with an encrypted piece of code for some evil purpose… 
This is the URL that will launch the exploit. We recognize the BlackHole toolkit version 2 using PluginDetect version 0.7.9 (which is a legit program by the way). 
