I can say with absolute certainty that AddToAny doesn’t run 3rd party
ads at all (never has), and I think it’s unlikely that someone would
try to hijack vicariously through our widget in particular.
Technically, it wouldn’t work unless you’re using forked AddToAny
code, but your requests seem to be from our CDN.

In which case, sorry AddToAny.

So the investigation is continuing: something is hijacking publisher IDs and stealing Adsense.

I installed the AddToAny social bookmarking plugin on a different website about a month ago. I would really like this not to be the culprit, because is it so useful. Here’s what happened:

A few weeks after installing it, I noticed something odd in Statcounter: under the ‘Exit Link Activity’ option, Adsense exit links were showing up with someone else’s Adsense Publisher ID. The rogue Adsense ID I found was this one: ca-pub-7957824725474864

I checked in Adsense, and obviously the clicks from my site with the other publisher id had not been recorded there.

Here is a screenshot from Statcounter (sitename removed), showing the beginning of the exit link with someone else’s publisher ID:

Statcounter exit links showing the rogue Adsense Publisher ID

The visitor had come in from a normal Google search to a landing page on my website, and appeared to have left from a page on my website, as opposed to a page that was saved to someone’s desktop.

I went to the page itself and reloaded it a few times to check the Adsense, but everything looked normal, both on the page and in the HTML source code.

Next I checked the Adsense code that was set up on my website, but again, everything was as normal.

So I did a search to see if anyone else had experienced this, and found this thread on Google Help forums. Not only was someone else experiencing the same thing, but with the same other person’s Adsense publisher ID.

Like the original poster, I reported this to Google AdSense. They replied that any extra ads on my site were placed without their knowledge, I should take security precautions (which I have) and that they would investigate this, but wouldn’t be able to tell me any of the results they found.

Meanwhile, on the Google forums, people were very helpful. Various causes were suggested for the rogue ID, including:

• stealware in browser toolbars and third party applications on the visitors’ PCs (see this post about stealware in peer to peer file sharing programs,
• pages loading in iframes,
• adsense and banner advertising manager programs,
• and third party javascript scripts.

Apparently it is well known for ‘stealware’ programs to hijack ids for affiliate marketing, although I could not find a reference to them hijacking Adsense.

There was a link to the Jensense Adsense blog, describing a Tell a Friend script that was inserting Adsense ads at the bottom of web pages: http://www.jensense.com/archives/2005/07/using_a_third_p.html

The original poster and I established that our websites were running on different software (one WordPress, one Joomla), with different advertising programs (Advertising Manager and Banners Manager). The original poster had uninstalled Advertising Manager a month ago and had not seen the rogue ID since then, but I was not using Advertising Manager. However, one thing we did have in common (apart from Statcounter and Adsense) was the AddToAny social bookmarking code. The original poster had the AddToAny WordPress plugin, and I had the version for other websites.

Although it is very popular, this plugin had also been criticised in the WordPress forums for nondisclosure of privacy issues: http://wordpress.org/support/topic/364390?replies=17, and in Futtta’s technology blog post ‘AddtoAny Removed from here‘.

So because of the timing, with it being the most recent thing I had installed, the privacy concerns and because it was one of only three scripts our sites had in common (Adsense, AddToAny and Statcounter), we were starting to wonder about it. But I was still not convinced it was a script on the page, because I hadn’t seen it in action, apart from exit clicks reported after the fact in Statcounter.

One of the helpful people who answered on the thread suggested reloading the page 5 or 10 times and checking the source code, as many third party scripts are up to similar tricks. So I tried, and found nothing, then tried again while running the Fiddler HTTP debugging tool, and I found something very very sneaky.

On the fifth pageload, the HTTP requests appeared the same at first. I could see the adsense loading with my own publisher ID. I could see the AddToAny button code loading, then Google Analytics, which I don’t use on that website, and then something from media6degrees.com, the website discussed in the WordPress privacy thread. All of these sources were the same each time the page loaded, but on the fifth pageload, after the last line of that code there was a new line, inserting Google Adsense code with the rogue publisher ID. Here is the section with the AddToAny HTTP requests:

The HTTP request URLs:

HTTP Debugging: URLs requested

The bottom line shows Adsense being reloaded with someone else’s publisher ID instead of mine.

The body size, caching and content types:

Next I wanted to compare the caching and content types for the rogue adsense with my genuine adsense, to see if there were any more clues there.

(The first line on the white background below is from my genuine adsense, to show how the rogue version (the last line in blue) is comparable in size and content):

HTTP Debugging: Content types and caching

Both have a same day expiry date, type of ‘text/html’ and size of around 4300.
From the similarities between the two requests, it looks as if Adsense is being completely reloaded, with the other publisher ID.

The URLs (my site and directory names changed):

Here are the full URLs requested in that section, (names changed again):

It looked suspicious to me, seeing the Adsense being reloaded like that right after the AddToAny code, as if either AddToAny was doing it, or something was hijacking AddToAny for this purpose, or something else was hiding itself by appearing immediately afterwards to look like part of the AddToAny code.

The sneakiest thing was that when I looked in my HTML source file, everything still looked normal: the rogue ID was not there. So many people who had concerns about missing Adsense clicks or strange exit links would check the HTML view of their page and not see anything.

But I have no doubt that if I clicked on that ad, the rogue ID would appear in the exit link in Statcounter and nothing would show up in my adsense account.

I spent some time trying to get it to show up again so that I could test that out (after all it wouldn’t technically be an invalid click would it!). When I was testing the rogue ads didn’t appear again, but then looking back through the Fiddler logs I saw that sometimes they appeared later, after a second call to Google Analytics (which I don’t use on that site), so there may be an occasional time delayed attack as well.

I also checked my server access logs for the visit when the rogue link was clicked, but nothing unusual showed up, presumably because it was all requested from other websites. In any case, I did not see anything else unusual going on.

Next I wondered if this was something I had missed that was authorised somewhere in the AddToAny terms, although I know I checked them at the time. Google forum member Steven G had seen such provisions for hijacking publisher IDs left out of the agreements by third party scripts, but listed in FAQs, or even the manual (as he put it, a great place to hide it!). Steven G discusses this more in his pay per click blog.

Checking the AddToAny terms, there is nothing mentioned about Adsense, or revenue sharing. I couldn’t find the manual, but in their FAQ it specifically states:

Does this service cost anything?
AddToAny is free, and always will be.

AddToAny also confirmed to me that they do not run third party advertising, and they did not believe that their plugin could have been hijacked in this way.

Well it’s true that it’s free, as are all the scripts on that website, but if any free script is the culprit, it is certainly costing me something, along with many of its other users.

As Steven G put it,

As long as people monetize their sites and have no choice but to trust the scripts they install to do certain things, there will be programmers to offer their scripts that hijack a portion of your earnings.

– and also hackers taking advantage of another doorway into your system: cross site scripting only works if there is a way in.

In the case of some scripts, the user base is enormous, eg here are the download statistics for AddToAny’s WordPress plugin:

AddToAny WordPress Plugin has been downloaded 880,378 times in the last 2 years

The annoying thing is that if I knew one of the scripts was going to do this (and only this), as long as it was ok with the Google Adsense terms, it would have been ok with me. They could have been upfront about some kind of Adsense revenue sharing arrangement, and I would probably have agreed to it, for a useful plugin. But as it is, I don’t know what else it might come up with, because whatever is happening here is dishonest.

However, having been in contact with AddToAny, I don’t believe they are the ones who are being dishonest, in spite of the coincidences implicating their button code, or other services it uses.

But there are still other possibilities.

Firstly, the two remaining scripts should be considered, ie Google Adsense and Statcounter.

Statcounter

It’s obvious that Statcounter itself is not doing this: for one thing, if they were, they would be able to hide it from the website statistics!

It does not seem very likely to me that Statcounter is involved via hijacking either, firstly because their code loaded after the rogue Adsense, and secondly because the reloaded Adsense always appeared after a call to Google Analytics. Why would something that hijacked Statcounter make itself more noticeable by calling Google Analytics, which would probably not be installed if Statcounter was there.

Also, the other site owner had posted in Statcounter forums, including the rogue Adsense ID.

Google Adsense

The final script that my site had in common with the other site that found the rogue Adsense Publisher ID was Google Adsense itself, and as a third party script that loads code from another website into the page, it also has to be considered.

Obviously there’s no way Google itself is doing this. It just wouldn’t make sense for Google to be jeopardising the service it provides to its Adwords customers by fraudulently loading Adsense units twice on one pageload.

Would it make sense for an Adsense ad to include a script that inserted a different publisher ID? Well it wouldn’t make sense to do it with their own ads, since they’d be paying more for the user to click it than they’d get for having it fraudulently clicked.

But would they make a profit if their ad caused Adsense to reload with a different ad including a publisher ID that they would profit from? They would have a lot of impressions, with no clicks on their own ads, and profit from clicks on other ads that should have been earned by the website owner. I just can’t see them getting away with that from Google.

Ads Serving Malware

There have been security bulletins for a long time warning of malware being hidden in Flash adverts and other hotlinked graphics files, exploiting unpatched vulnerabilities in certain software and browser plugins.

Over the last few weeks, there have also been discussions online about malware being served through third party ad networks provided through Adsense.

Here’s a post from six weeks ago about malware being served by ad networks, including ad networks including Google Adsense, Adultadwords, and Adbrite. There’s also a Google Help forum thread from today about websites and visitors being attacked by malware served by advertisers in third party networks supplied by Adsense. http://www.google.com/support/forum/p/AdSense/thread?tid=420c791905c1c74d&hl=en

The Anti-Malvertising website (http://www.anti-malvertising.com/) is a useful resource for those dealing with malware and malvertising.

Browser Vulnerabilities

Another possibility to consider is unpatched vulnerabilities in Internet Explorer 8, since all the rogue exit links were clicked by visitors with Internet Explorer 8. However, many visitors do use Internet Explorer 8, and the number of rogue exit links we have visitor data for is too small to generalise from. I’ve also only been able to use the HTTP debugger with IE 8. So it’s a possibility to consider, but not at all conclusive (as it seems to be with all the options so far).

In the meantime, I have uninstalled the AddToAny code and disabled third party ad serving networks through Adsense (this is done by disabling image ads via your Adsense ‘My Account’ page). I am continuing to monitor my pageloads, so if I see the rogue ID without these being installed I will post it here immediately.

If anyone has found similar exit link activity, found this publisher ID elsewhere, or has more suggestions about this, please do post a comment below.

(Click for comments)

So it was obviously done for a hidden, longer term purpose, rather than to take the site down, and that worried me too. Could it be rescued?

This is a long post, detailing the steps I took to trace the problem, minimise the damage and rescue the website, so the steps I took are linked in this step-by-step list:

How I noticed something was wrong

Because I usually use Firefox, which hadn’t had any problems with the site, I only realised my site was hacked when I tested a new page in Internet Explorer 8. There was an error message I hadn’t seen before.

The message said, ‘This website wants to run the following add-on: ‘Remote Data Services Data Control’ from ‘Microsoft Corporation’. If you trust the website and the add-on and want to allow it to run, click here’.

Now this website and I have been through stormy times together. If I’ve ever made a lot of sales calls, spent a whole day cold calling at trade shows, or I’m at home with flu and a hyperactive toddler, that’s the day the site will crash. True to form, I had just applied to some new affiliate programs and was about to stop work for the day and start cooking for my son’s 4th birthday party. So did I trust this website? Erm…

At first, I thought maybe there was a script I hadn’t noticed in some content I had just added from Wikipedia, so I checked the source code, but I didn’t see anything unusual there. I browsed to other pages on the same website, and then back again, and didn’t see it again. I wondered if it was something left over from my MSN Internet Explorer home page, so I went back to that and it wasn’t there. Then I went back to the same page, and there it was again.

Back to list

What is Microsoft ‘Remote Data Services Data Control’?

I tried searching for ‘Remote Data Services Data Control’, assuming it was some kind of Microsoft script, and found a post on a Microsoft Security newsgroup leading to this ‘Can You Spot the Fake?’ post on Hosts News, warning,

‘any time you see that warning “Remote Data Services Data Control” watch out! … this is NOT from Microsoft! This is the generic warning IE7 throws up when an exploit is trying to enter the system.’

Starting to feel alarmed, I following a trackback from Hosts News to the post that saved my day (though ruining my night first ) : the Little Big Tomatoes post The one with the evil jscript on my blog.

Back to list

HTTP Debugging with Fiddler

The hacked site there appeared to be WordPress based, but the errors looked similar. The post showed a useful free web debugging tool called Fiddler, which logs all HTTP(S) traffic between your computer and the Internet. Fiddler allows you to inspect all HTTP(S) traffic, set breakpoints, and “fiddle” with incoming or outgoing data. There’s an instruction video for Fiddler here.

So I downloaded Fiddler and ran it. I’d never run Fiddler before, but when I loaded the web page again in Internet Explorer, Fiddler picked it up automatically. So I looked down the list of http requests, and in the middle of my normal HTTP requests (site name blocked out) I found these (don’t go to any URLs listed here!):

Back to list

‘Yourgoogleanalytics’ and ‘Statscounter’???

Looking down the list, I saw ‘statscounter’ and did a double take: I do use Statcounter for website statistics, but here it’s misspelt, and I hadn’t used Google Analytics at all, so that was another red flag. Some Google Adsense HTTP requests appeared around the same time, but it just looked dodgy. Was this really something Google Adsense did?

The next requests, for ‘dos.ms’ were completely unfamiliar, and called PHP scripts called ‘redir.php’ and ‘in.php’, whose names alone sounded worrying. I wondered: shouldn’t hackers have called them something less sinister, perhaps kittens.php and flowers.php? Or had they just stopped pretending? Most of all, I wondered what was going on with my website.

I should say at this point that the website often needs work and doesn’t get much traffic (a good thing, for once).  In  the words of Courtney Tuttle, it’s a time sucking money pit.   But I leave my money pits on my own terms, thanks.
So there weren’t any visitors right then and I thought I had a bit more time to figure out what was going on.

I searched for ‘yourgoogleanalytics’, and found nothing for ‘yourgoogleanalytics.us’, but there were posts about ‘yourgoogleanalytics.cn’ on Google’s support forum from a site using Microsoft software, with a useful answer about rogue javascript added to external .js files:

“Have you looked at the code in menus/milonic_src.js ?

What do you suppose is the long line starting with this: document.write(unescape(‘%3C%69%66%72%61%6D%65%20%73%72%63%3D ?

I suggest you check all of your external javascript js files for code tampering.”

More reading turned up a couple more examples of obfuscated javascript being added to js files, creating invisible (0 x 0 dimensional) iframes, which would then call php files on other domains to pull in dodgy code such as trojan downloaders.

Andrew Martins security blog lists the yourgoogleanalytics.us domain as being used for ‘Money Mule Recruiting’, and gives an example of Money Mule Recruiting on a related domain:

“During the trial period (1 month), you will be paid 2000 USD per month
while working on average 3 hours per day, Monday-Friday, plus 5
commission from every transactions or task received and processed. The
salary will be sent in the form of wire transfer directly to your
account. After the trial period your base pay salary will go up to
3,500USD per month, plus 5 commission.”

I couldn’t see my visitors falling for that, so I hoped if it was hacked it was for money mule recruitment rather than the various trojans and downloaders that were mentioned on other sites as possibilities.

Back to list

Checking the Javascript files

My site has a lot of javascript files, so I thought the best place to start looking for this would be the file Fiddler reported just before the odd domain names: moscom.js, moscom.jquery.js, and moscom.ui.tabs.js, which were all part of a comments extension I had installed a few weeks earlier.

So I downloaded those three files, and checked them one by one in Notepad, and when I got to the top of moscom.jquery.js, there it was:

document.write(unescape('%3C%69%66%72%61%6D%65%20%73 ... and so on.

I didn’t know if the file had always been like that, but that line of code appeared before the header section with the package and file names and looked very suspicious, so that was enough for me: it was clear the website had been hacked.

I felt awful, thinking of people visiting my website, and being at risk from trojans and viruses.

Back to list

Preventing further infection

I didn’t want to be infecting my visitors with malicious downloads, so I took the site offline via the Global Configuration settings.

I set off a backup of the database and files, in case uninstalling or repairing anything might trigger off some kind of malicious code. Then I noticed that the backup program itself was trying to access the malicious files, so I stopped it and downloaded the files and database separately.

Back to list

Telling the Web Hosting Provider

Then I emailed my web hosting provider, told them the situation, and apologised for the inconvenience. I told them that I had identified the infected files and taken the website offline to visitors, and that I would be uninstalling the infected components and upgrading everything that needed upgrading.

I also asked them to let me know if they could please check for anything they knew of that could have got the javascript into the site, so I could prevent it from happening again.

I was pretty nervous about this, having heard of other hosts deactivating hacked accounts, and I stared at the backups, willing them to go faster…

That didn’t work. My web hosts were really helpful though, and sent me this reply:

“It appears that your site has been subject to an attack via a method known as script injection. Typically, this works by forcing a site to execute code when it was expecting to process another input, fake .txt files are often used for this purpose.

Because script injection attacks the site code itself, it is able to completely avoid webserver security. Unfortunately, some content management systems (especially older versions of Joomla) are extremely susceptible to this form of attack.

Here’s the best way to get your site back up and running:

1. Begin by clearing out your public_html directory, ensuring no anomalous files or hidden files are left, this way you know that any backdoors the hacker might have left in are completely eradicated.
2. Change any passwords relating to the site, along with the ftp password.
3. At this point we can turn scripting back on for you – as the hacker’s entryway is now gone.
4. Restore the site from your last known good backup.

If you feel confident removing this infection by hand, please inform us when the site is completely clean and we will turn it back on for you. However, if the infection does recur, we would ask that you completely clear the public_html directory before we reactivate the site again.

I would also suggest contacting the author of the script as it appears there maybe some security issues with the code. “

Script injection? I’d heard of cross site scripting, and SQL injection (see the ‘Bobby Tables’ cartoon about this), but not script injection. A quick look at the Wikipedia page told me that script injection (or code injection) is the more general name for the type of website hacking that adds extra code to a computer program, and can be accomplished using cross site scripting or SQL injection, among other methods.

Back to list

Checking my Desktop PC

I’d like to say the next thing I did was to run the virus and spyware checker on my local PC. But in fact, I changed all my hosting account’s FTP and database passwords, and then thought, “What if I have keylogger spyware on my local PC…?” Then I ran the virus and spyware checker on my desktop PC and changed my passwords all over again.

When your website has been hacked, your desktop PC’s security is easy to overlook (apparently!), but can be crucial. This post from Brian Teeman’s blog discusses why it’s important to consider keylogging trojans and viruses when dealing with hacked Joomla sites.

Checking on the Joomla security forums (the Joomla 1.0.x security forum and the Joomla 1.5.x security forum), I found advice to check the desktop PC with several different antivirus and spyware tools, as each of them might miss something different.

I was able to run AVG antivirus, PC Tools Anti-virus, and Lavasoft’s Ad-Aware. I also tried Kaspersky, but it wouldn’t install because it found remnants of an old AVG version, which I couldn’t find and couldn’t uninstall.

Some more recommended security tools can be found listed here:

Free virus checkers:

• AVG free anti virus
• House Call
• Bit Defender
• Kaspersky
• F-Secure
• PC Tools free antivirus for Windows XP and Vista

I ran the quick check first, then the thorough ones, but my desktop PC was apparently ok.

I also discovered Secunia’s free check for vulnerable software on desktop computers.

Back to list

Securing the Web Hosting Account

Just in case, I had changed the FTP and database passwords again, because it was easy to do. Looking through the files, I didn’t find any others that were infected, but wasn’t convinced they were safe either. I didn’t see anything else like the encrypted Javascript, but neither do I know every line of code like the back of my hand.

So I decided that in the long run it might be quicker to take the drastic route. I uninstalled the infected component first, then deleted all the files. While the files were deleting, I used phpMyAdmin to export a text file of the database, and I searched it for anything I could think of that had been out of place so far.

Back to list

Finding the Vulnerabilities

Obviously, I wanted to avoid this happening again, so it would help to know how the hackers got in.

I’d added extra code to my php.ini and .htaccess files that was recommended on the Joomla Security forums for blocking common exploits, so I’d thought my site would be safer than most, but apparently part of it wasn’t. So where was the problem, and how could I track it down?

The first place I looked was in the new component with the infected files. The infected files had the same date stamp as the others from the same component, so either they were infected on the day I installed them, or the date of hacking had been hidden. So I checked the same file in the installation package, and the rogue javascript wasn’t there.

I emailed the author anyway, as advised by my web host, and eventually received a reply telling me not to store my files with permissions set to world writable. Ok, that’s valid advice, except that wasn’t what happened and I don’t know why he thought it was.

Another place where I have often seen hacking attempts is the Friendly URLs list of my Search Engine Friendly (SEF) URLs program. When hacking attempts arrive via the browser URL, they are not known URLs, so the SEF program makes FURLs for them. In the past I’ve often checked through these to see which components are being targeted, but this time I’d recently cleared them out and deleted the invalid FURLS. So I didn’t find anything there.

The next thing I did was to download the access and error logs from my web hosting server. All I found from the error logs was that one of my graphics files was missing. The access logs were long text files, but only went back to about 5 days after I installed the files that became infected.

I started looking back through them. I’ve seen SQL injection attempts in my access logs in the past, and there was one almost immediately in the most recent log file. But when I looked up references to SQL injection in the component that was targeted, the attack I saw was known and the vulnerability had been patched many versions previously. I contacted the author and he confirmed this (although not long afterwards they did produce a new security release). I also didn’t see any administrator activity or unusual file accesses in the log entries around it.

I found lots of hacking attempts by the bot libwww-perl, which is often used for automated hacking attempts. Many were targeting Community Builder, which I hadn’t seen targeted before, and many were bringing up my ‘page not found’ page.

I continued trawling through the logs, finding nothing that looked successful. Occasionally, the infected files appeared when I didn’t think they should have done. Eventually, the log files ended, leaving me with that half a week gap.

I changed tack and itemised the components in the website to see what needed upgrading.

Joomla itself was up to date, but Community Builder was known to have an exploit, and I had put off upgrading it because the new version required PHP 5, and I had only had PHP 4.4.7 on my server. In the meantime, however, my web hosts had installed a capability to switch hosting accounts to the upgraded PHP version.

Back to list

Improving Security in Future

So the first change I made was to upgrade the PHP version to 5. Then I restored the files from a backup taken before installing the infected component, working on the assumption (or hope!) that the site was only hacked once.

I had already made the .htaccess and php.ini changes recommended in the Joomla Security Forum, but I added some new lines to my .htaccess file to block libwww, as recommended in these useful and detailed blog posts: ‘Hackers, Botnets and libwww-PERL’ by WebGeek and ‘Block LIBWWW-PERL and web addresses to protect your site from botnets’ by incrediBILL.

Unfortunately, there are some legitimate uses of Libwww-perl that would also be blocked, but so far the only disadvantage I have found to blocking it is that if I want to run the W3C link validator, that uses Libwww-perl so I have to temporarily allow it again.

I also added lines to block the domains used in the hacking attempts. For more .htaccess protection, the Webmasterworld forum has a useful discussion on ways to block bad bots.

I had a couple of small PHP errors to fix after upgrading to PHP 5, and then I tested the site thoroughly using Internet Explorer and Fiddler, and all seemed ok.

Next I upgraded Community Builder, followed by checking and upgrading any other components that needed it.

My users’ passwords are all stored in encrypted form, and the site does not collect personal information about them, so there wouldn’t be a security risk from that. I checked the user list to see who had logged in recently, and checked their data. Then I changed the passwords to prevent fraudulent logins in future. If they try to log in, the ‘forgot password’ option can be used to reset passwords. It’s not great, but no damage has been done there.

The users’ passwords did give me some scary moments: this is another example of why it’s so important to use different passwords for anything important you do online: if the users’ passwords had been on a website where they weren’t encrypted, and they used the same password for their email, that would be extremely risky. And if I’d used the same passwords for logging in to my website as I did for online banking, email or anything involving credit cards, for example, I could be in deep trouble now. If you’re not convinced, check this entertaining but scary “One Man’s Blog” post on “How I’d hack your weak passwords”.

Looking back, I may be in good company too: I can think of several online services I’ve joined where the password has mysteriously stopped working. None of them told me why, and some of them did have more information of mine than I’d want to let go.

Back to list

Why was my website a target for hackers?

I can think of a couple of reasons why my site might have been targeted:

1. When I first launched it, I posted links in various ‘Site Showcase’ type threads in the forums for the Joomla components I’d used. At the time, I thought this was great, because it brought me visitors from all over the world, as well as a truly improbable sounding Alexa ranking. But then, when any of those components develop a vulnerability, my site is an obvious target. Thankfully, component owners tend to develop patches or eventually take their sites offline, and my links with it. But I wouldn’t post links there again unless it was truly relevant to the website’s focus.
2. Social networking sites are increasingly becoming targets for hackers (see Facebook and Twitter becoming Top Targets for Hackers at Brick House Security), which could lead to Community Builder being targeted more than in the past, with hackers assuming that any site using Community Builder would be a social networking / membership site. Plus, the older version of Community Builder had a vulnerability posted. I haven’t been able to find out what it is anywhere, but hackers could have tried attacks in many variations
3. What’s most likely, considering that my website isn’t a high value target, is that hackers were using bots such as libwww-perl to run scripted attacks with many variations, and eventually one of them worked. Woohoo, lucky me! Should have kept all my extensions up to date

Back to list

Online Tests for Malware in your Website

There is an online service called Unmask Parasites which tests web pages for malware. To check your web pages you can either bookmark their service or place their Security Check shortcut links on every page you want to be able to check.

Every time you click the Security Check link the Unmask Parasites service will automatically check the referring web page so you don’t have to type any URLs.

The shortcut links should work for any public web pages, however, I have found since then that when I checked a hacked oscommerce website, the security report service appeared to crash with error messages, so if you see errors they should also be treated as a warning that your website may have been hacked.

Back to list

Google Malware / Security Warning

If your website has been unlucky enough to be flagged by Google as hosting malware or in some other way risky, this post explains how to get that warning removed from your website’s Google listings: How to remove ‘This site may harm your computer’ from Google search results.

There’s some more information here about Google’s safe browsing diagnostic pages.

Back to list

General Website Security Links

• Description of a recent attack that infected 40,000 websites
• Sign up for Websense Attack Alerts
• Websense Security Labs Blog
• SANS: Top Cyber Security Risks
• Stop Badware: Tips for Cleaning and Securing Your Website

Joomla Security Links

• Joomla 1.0.x security forum
• Joomla 1.5.x security forum
• Joomla! Security Checklist
• Joomla Advisory: dealing with hacked websites and hacking attempts
• Joomla Security Forum: Malicious Javascript in Your Site
• List of Vulnerable Joomla! Extensions

Back to list

If you’ve also had your Joomla website hacked, you might find these security links useful, and I wish you luck with it! In the meantime, with the files backing up, then deleting, then restoring, and the anti-virus running, the computer ran so slowly that I had lots of time that night to get things ready for my little boy’s birthday party: I may have felt like a zombie but at least the scumbag hackers didn’t ruin his special day. Comments, advice, suggestions etc welcome – if there’s one thing I’ve learned above all from this it’s that I’d rather improve my knowledge of website security at more convenient times