WordPress Hacking – Client Side Vulnerabilities

I had a hosting client call me recently telling me the site wasn’t working in Chrome. I duly checked and saw a warning given that the site contained links to malware.

Initially I thought that the WordPress install had been compromised in some manner, but I knew that the code base was the latest as I use a cron job based on this update WordPress script and the plugins were minimal and again up to date.

It soon became apparent that the “hack” had actually been via FTP. Each page of the website, and every html / cgi / php script in any directory (including the ones above the web folder) had been downloaded and various JavaScript exploits had been added.

To recover, I had to unpack the WordPress files again, change the passwords for FTP, WordPress and the database. Recover all the files outside of the web tree. I also dumped the database and made sure that no code had been hidden within the posts. Then followed quite some time spent making sure that no other sites had been compromised on the server.

Normally as a web developer one considers the server to be the point of attack, but just as most hacking stems from social engineering this too was much simpler. Rather than brute force passwords or find a vulnerable server a trojan relaying any and all passwords had found its way onto the client’s computer.

There’s no moral to the story other than to ensure all links in the website chain from client to developer to the web server are patched and as secure as can be.