Archive for category: Security

If you have a WordPress site that is suddenly attacking your site visitors and you discover Silence is Golden in some of your index files then you may find this post helpful. I had to deal with this security issue as well for one of our customers. The following is how we dealt with it. The first portion of remediating any attack is obviously discovery. The discovery portion for this particular attack was blatant… Google blacklisted my client. Doesn’t get much more obvious that you have a problem with your website, then when the gods of the internet blacklist you. Anyhow, first inspection of the site immediately revealed the following javascript at the top of my client sites pages.

if(window.document)try{new location(12);}catch(qqq){aa=[]+0;aaa=0+

Only slightly further inspection reveled a few newly introduced index.php files with the following

// Silence is golden.

Following identification I moved on to attempting to determine the scope of this attack. This turned out to be much trickier then I first thought it would be. For a full run down of how I finally ascertained the attackers access (through blunt force trial and error), please read my post on WordPress and Toolpack. Short of the long is that the attacker had multiple successful attack vectors and was able to execute their own php code on our clients server through a few different instances of Toolspack.php. In order to identify malicious php files that were placed on the server I used grep to search for any files that contained base64_decode. I removed all the files that contained bas64_decode which did not match the core files in Wordress. It is important to note that some of the default WordPress files used for rss and atom feeds utilize basee64_decode. Following removing ALL the malicious code (this took awhile) I generated new keys for WordPress, changed all the passwords to the site using the WordPress Key Generator. You need to check all files on your website and your database for any issues. I used the following script to check my database content

SELECT * FROM wp_posts WHERE post_content LIKE '%<iframe%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<noscript%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%display:%'

As recommended by this fairly popular post. I will be the first to acknowledge that the above script is absolutely not the end all be all for checking your database content. It is simply a good start for identifying anything obviously malicious. So that was pretty much it, same remediation as every other attack: Discovery, Scope and Vector Identification, Remediation, and Continuous Monitoring following the attack. Here are a few good links that may help you out if you WordPress site is hacked.

So I’m sure that a large number of people have experienced a similar pain to the one that I went through as you will read soon, however, this is my experience and I’m hoping that someone out there will benefit from me writing it down. So the short version of what I’m about to say is what every security consultant already knows and consistently re-learns : ALWAYS CHECK YOUR ASSUMPTIONS. In other words, If the machine isn’t booting start by making sure that there is power coming from the outlet. This blog should also let you know why most security professionals recommend nuking your server once you have a WordPress hack. A DrIST Coach client was having issues with rogue javascript getting injected into every page on their site. I was able to accurately deduce that someone had somehow gained the ability to write to a few of the index files on our client’s server. When the customer contacted me they sheepishly admitted that they were using the default user and password. So my first ASSUMPTION was that the attacker must have walked through the front door of an insecurely configured WordPress site. Yes it’s plausible and in all actuality it may have been what happened, however, I should have checked my ASSUMPTION and verified there was no other way that an attacker could easily gain access. In my effort to secure my client’s site I logged in deleted the offending code from the 3 index files affected (listed below)

index.php

wp-content/index.php

wp-admin/index.php

I did think to check the database for possible injections and it did not appear that any malicious code had made it’s way to the database. Following checking the database and removing what I ASSUMED was all the malicious php code I changed the admin password patted myself on the back and informed the client that we would want to continue to monitor their site, but that most likely everything was fine. You could translate that last sentence to “Over confidence led me to sticking my foot in my mouth”. Within about 2 or 3 hours the malicious javascript was again showing up on my clients site. [email protected]#$. Alright so there were some options about could have happened, but at this point I thought replacing all the default files with the original WordPress files was probably appropriate. My customer didn’t have a large number of plugins and I thought that replacing the core files and deleting any extra core files would mostly likely illuminate any issues. Wrong again. I replaced the core files, changed the admin password again and again 2 hours later (like clockwork) the rogue code was present again. Alright so at this point I’ve got the issue nailed down (so I think) to either an exploit against the theme or the plugins and some sort of bot. The regularity of the attack returning just seemed to indicate a bot to me. I decided to check the access logs in Webalizer to see what types of clients were accessing the site. Not to my surprise I did find a non standard bot regularly accessing the infected files. Weird. Well a little .htacess modification should help deter that issue. I still needed to check the plugins and the theme to see where this issue was stemming. I started by checking the plugins directory and there it was… ToolsPack. My reaction was something like this…

Well this has to be the problem I ASSUMED. If you aren’t familiar with what Toolspack.php does, here is the breakdown. It basically evaluates whatever base64 encoded code is sent to it. You can imagine the evil that can be done by someone who is remotely able to run code on your system. This should have been an HUGE indicator to me to CHECK ALL MY ASSUMPTIONS. Rather then checking all of my assumptions, I only checked my clients WordPress files and database which I was requested to check. I informed my client once again that they were most likey good to go, but that we should continue monitoring the site (at least I had the presence of mind to keep monitoring the site) . Feel free to translate that last sentence as “Over confidence led me to sticking my foot in my mouth, again.” To recap at this point :

I removed all malicious code from the plugins and theme files

Changed the admin password (literally 3 times by this point)

Checked the database for malicious code

Replaced all the core WordPress files with the original WordPress files

Configured the .htaccess files to reject a few malicious bot’s access to the site

Regenerated the salt and key in the wp.config file

So at this point I didn’t assume anything I knew that if there was an issue within the client’s WordPress instance that I had resolved it. I literally had left nothing to chance. However my initial ASSUMPTION was never validated partly because I gave my client the benefit of the doubt that this attack was limited to a single website/Wordpress instance. When the malicious code returned this time, I flipped out. I informed my client that this attack had to be wider then the site and that I needed shell login access. In case I didn’t make it clear earlier Toolspack.php allows you to evaluate code remotely. If I were an attacker and I could evaluate code I would instantly install a backdoor. Which is exactly what the attacker did utilizing a number of the other websites hosted on my clients server. I started by greping for base64_decode on all the websites that were sharing the hosting space. Ooh the evil I found. MadCmdShell shown above is one of the many many evils that I found hosted on these shared sites. Once I had login access and could grep all the files on the server I informed the client of the extent of the pain they were suffering, to which they quickly decided to remove old sites and unneeded code. Fortunately good did seem to prevail as their site now appears to be running smoothly without serving up malicious code.

It’s hard to believe with as many commercials and warnings that we see out there we still need to talk about not putting usernames and password or credit card information in email… and yet here I am about to talk about it again. The fact of the matter is that I still have customers that don’t understand how easily attackers are able to gain access to email accounts. Most security professionals will admit that at some point or another their email has been compromised. Why does this happen? Mostly because we check our email from literally everywhere, and every location that we check our email from could be location that an attacker has been before us. The process is fairly simple. If an attacker has installation rights on a computer, than they install a program called a key-logger. The key-logger simply logs the keys that are pressed and then sends them to the attackers machine. Libraries, colleges and hotels are notorious for having key loggers installed on their computers. Having an attacker gain access to your email is annoying, but as long as you don’t have all your passwords, medical information and credit card information stored in your email then you don’t have much to worry about. Another very common approach is simply through a process called man in the middle. Man in the middle attacks require more explanation which you can read about elsewhere. The primary point is simple don’t be the easy email target and don’t put information in your email that is highly sensitive. It’s just not worth the risk. When you need to share sensitive information, I recommend a phone call, or text message. Not to say that either of these techniques are flawless, but I do believe that they are the lesser of two evils.