By

The main difference – between those that do and those that don’t

We are the ones who do malware removal. We work in the trenches

We are the ones who do malware removal. We work in the trenches

The main difference – between those that do and those that don’t.

This is something I’ve been toiling over for some time now and it’s reached a full boil.

I continually read blog posts and articles about what “you” should do to protect your website from hackers.

I read it, then read the bio at the end and it all makes sense – these people are not living in the world of website security. They’re not even vacationing here.

One article I read actually focused on one main actionable item for website owners looking to increase their website security – add a section in your agreement with your web developer that makes it their responsibility for all website security issues.

Really?

How many of you web devs out there, think that’s justified?

And more to the point, does it really make your website more secure?

Today I read a blog post about what you can do about website security. It started off with keeping software updated. Which is totally sound advice. However, after that the author talked about SQL injection and cross-site scripting. Not what you should do to prevent it, but what it is.

Does awareness make you more secure by itself?

Knowing one way that SQL injection can be successful does nothing to the majority of website owner’s website security.

Nothing!

That’s like saying that since I know it’s illegal to drive 60 miles per hour in a 45 mile per hour zone, that I’m qualified to be a lawyer. Does that little bit of knowledge make me qualified to practice law? I think not.

To turn this around and not have this just be my rant, here are some things you can do to increase your website security. This is advice from someone “in the trenches” (someone that “does”).

  1. First, make certain that someone is responsible for updating your software and your plugins. Don’t even think this is the same as that blog post referenced above about making it your web developer’s responsibility.

    I want you to be certain that it’s someone’s responsibility to login to your WordPress, Joomla, etc… and check for any core updates or any plugins, components, modules, etc. updates at least once every two days.

    You check your Facebook, Twitter, (insert other social media sites here) numerous times a day and that does nothing for your website security. So why not login to your website and see if there are any updates?

  2. Next, activate your log files. If you’re on a hosting account with cPanel, most hosting providers will have the Access logs off by default. They know that storage costs can sky rocket and drives their prices up and they know that probably nobody ever, other than us, ever reads them so they have access logs deactivated. However, that is the first thing we do when we log into your cPanel account is to activate them.

    In your main cPanel window, look for the section titled, “Statistics”. You’ll see an icon for “Access Logs”. Click on that and put a check in the top two boxes. This activates the logs and “flushes” the previous months logs at the end of each month. This prevents your local storage from going through the roof and having your account deactivated for performance issues.

    As much as I hate to admit it, nobody can guarantee your website will never get infected. However, with a forensic audit trail, we can at least determine how it happened so we can take steps to insure that the possibility of your website getting infected again, is less.

  3. Consider your circle of trust. Shameless plug: https://www.youtube.com/watch?v=oCLRaonXf8M

    We created this video to help you understand the concept of trust. If you use a web developer, an SEO expert, a blogger, an administrator, or a security company, you must realize that you’re trusting people they trust – without even knowing them. You should start analyzing your circle of trust.

    Watch the above video. Start thinking about who you trust.

  4. Create a separate FTP account for each user.

    If you have a web developer, an SEO expert and yourself all accessing your files, create a separate FTP account for each of you. That way if your website is infected via FTP, you (or us) can see in the FTP logs which user account was compromised and used to upload infectious/infected files to your website.

    Without that, you’ll only see one account and now you have no idea who’s computer was used to steal the FTP password.

    Often times, we see websites infected due to stolen passwords. These passwords are stolen by a virus/trojan on someone’s local computer and when that person logs into the website, either through FTP, CMS login, cPanel, etc., the virus/trojan steals the login URL, the username and password, sends it to the hacker’s server where it logs in as a valid user and uploads or injects malicious code.

  5. If you are using cPanel, create a separate cPanel account for each website.

    Then, if one website gets infected, the chances are the other sites will not due to the separation of accounts.

    You can suspend the infected website (cPanel account), get the malware removed and the website secured, then reactivate it – all without disrupting the other websites.

  6. Monitor your files.

    No, this is not another shameless plug. But the fact is that hackers are constantly changing their tactics. The only sure way to detect when your website has been infected is to monitor the files constantly. Not just once a day. Not from the outside like a browser. But actually monitor all the files and folders frequently to see if any file or folder has been added or changed.

Notice the slant above?

It presumes that your website will get re-infected.

That’s right!

Nobody can guarantee that your website will not get infected – NOBODY!

Understand the hackers are making money off of their work. They will not stop. All you can do is to follow advice from someone “in the trenches” and take the necessary steps to make your site less prone to being infected, setup a strategy for early detection and remediation and get back to doing what it is you do.

Post a comment about your thoughts on this.

By

Nutcountry.ru and Parkperson.ru iframes

Over the past week we’ve been seeing a lot of infected websites that have an iframe that contains one of these two URLs:

nutcountry.ru:8080/index.php
parkperson.ru:8080/index.php

A little searching found that approximately 25,000 web pages have the nutcountry.ru:8080/index.php iframe and another 516 web pages reference parkperson.ru:8080/index.php iframe.

What’s interesting is that none of the websites listed in the Google search for either of these two iframes, are listed with “this site may harm your computer” label.

We checked the Google Safe Browsing Diagnostic for nutcountry.ru and it shows:


It appears that Google just listed nutcountry.ru on 8-03-2010 which would explain why the web pages listed in a Google search aren’t showing the warning, “this site may harm your computer”.

And for parkperson.ru we found this:

parkperson.ru Google Safe Browsing Diagnostic page

Shows that as of 8-04-2010, Google has not found this site to be harmful or suspicious.

We attempted to download the files from parkperson.ru, or watch what infection might occur if visited and found that the domain does not exist and neither does nutcountry.ru.

What does all this mean?

It means, that over 25,000 websites were infected, but with an iframe that is harmless because the URL inside the iframe doesn’t go anywhere.

The other interesting aspect of this infection is that all the web pages appear to be ASP code (.asp or .aspx). Based on the location of the harmless iframes, it appears to be another ASPROX infection.

If it is ASPROX, you’ll probably see the iframe in your SQL database. Based on the location of where the iframe appears in the web pages, it’s not a simple iframe injection. The iframe is actually buried in your SQL database. This will make it more difficult to remove. You should consult the services of a database administrator or a security company that knows SQL (yes we do!).

The next thing will be to determine how the code was inserted. This type of infection is referred to SQL injection. This happens when the input from a form or dynamically generated web page isn’t properly sanitized. If there’s a code plugin you’re using, or utilizing some standard software package in your .ASP code, please check for security updates. If you’ve had a programmer create something for you, contact them and have them check over all the code they created for you. Some where on your site you have a SQL injection vulnerability and it needs to be closed.

As stated, this time, the domains included in the iframe don’t exist. However, the next time, your visitors could get infected and your site could be blacklisted by Google and many other services.

If you need assistance with this, please send me an email at traef@wewatchyourwebsite.com.

If you have other information about this infection, please post it as a comment.

Thank you.

By

Another Round of Beladen? Or, The New "Go" Infection

On Wednesday July 22, 2009 we started seeing what looks to be a new round of beladen style website infections by cybercriminals.

The reason we think they’re beladen style is that they appear to infect all the websites on shared servers and they also seem to be remotely controlled with a “on as needed” mode.

This infection resulted in thousands more sites being tagged with Google’s “This site may harm your computer”.

According to Google Diagnostics for certain websites we were asked to help with, this is what was shown:

“Malicious software is hosted on 4 domain(s), including: ventsol.info/, ina6co.com/, goscansoon.com/.”

Other sites we were asked to help with were also showing these domains in their Google Diagnostics:

  • daobrains.info/
  • safetyshareonline.com/
  • goslimscan.com/
  • goscansome.com/
  • globalsecurityscans.com/

Our scanners were detecting suspicious obfuscated javascript on the sites we were helping with, but it appeared to only be setting cookies to expire the following day. The obfuscated javascript was this:

malscript-0-11

Which deobfuscated looks like:

sessionid=39128605A531; path=/; expires=Thu, 23 Jul 2009 18:42:32 GMT

We found similar code with various names for the “var” part (replacing oigmlob) above in the obfuscated code. Other names were:

  • dtxzidl
  • bmno
  • wcdg
  • tpet
  • stqfpbc
  • meuhgor

In addition, we also saw various combinations of the hexidecimal numbers to replace the actual letters. For instance, instead of pa\x74h=/\x3b ex\x70ir\x65s we found these as well:

  • p\x61th=/\x3b exp\x69r\x65s
  • p\x61\x74h=/\x3b \x65x\x70i\x72es
  • p\x61t\x68=/\x3b expi\x72e\x73

All of these deobfuscate to: path=/; expires

One common theme was the hosting providers. Wouldn’t you know that a day after we blog about how wrongly accused many hosting providers are for the gumblar, martuz and iframe infections that they actually become the target.

It appears that these recent infections are a server issue and not just a specific website on a shared server. How the server became infected is purely speculation. Could it have been from one set of compromised FTP credentials that was able to infect the server and then control other sites as well? Could it have been SQL injection for one site that then gave the attackers a method to start a process on the server thereby controlling all the websites on that server?

Who knows. At this point all we do know is that this does affect all the websites on infected servers.

How do we know that?

We created a program for situations like this. It grabs a list of all the websites for a specific IP address and starts checking them. On some IP addresses 91% of the websites were showing the obfuscated cookie code from above. Our thought is that since this is an “on again – off again” type of infection, the other 9% were dormant when our program scanned those sites.

Another interesting observation was that for a specific IP address, each website showed the exact same obfuscated code. While websites on different IP addresses had similar obfuscated code with the slight variations mentioned previously.

The first step in this “drive-by” infection was to set a cookie on the visitor’s PC. Then if that same visitor came back within the expiration period of the cookie (24 hours), this would be delivered to their browser:

malscript-1-1

Which essentially does a Meta tag redirect. The above deobfuscates to:

malscript-2-1

We did see some of the other domains mentioned earlier in place of safetyshareonline.com and the goscansoon.com.

The whole purpose of this attack is to infect the PCs of visitor’s to these websites. This is done with this bit of social engineering code:

malscript-3-1

This code uses some fake graphics (okay the graphics are real, but they’re not the “official” graphics of Microsoft) in an attempt to trick the visitor into believing they have a virus. The code starts by checking to see if the operating system on the visitor’s PC is Microsoft’s Vista. If it is, it displays “Vista” looking graphics. If not Vista, then it assumes Windows XP and shows different graphics.

No matter who you are or what operating system and browser you have, this code shows a window that looks like a “Windows Security Center” window and it informs you that:

 “Virus (I-Worm.Trojan.b) was found on your computer! Click OK to install System Security Antivirus.” If you select “OK” from their screen it will download their “antivirus”.

If you cancel, a new alert is displayed with this message:

 “Windows Security Center recommends you to install System Security Antivirus.”

If you cancel that, it will display again.

One more cancel gets you to this message:

“Your computer remains infected by viruses! They can cause data loss and file damages and need to be cured as soon as possible. Return to System Security and download it to secure your PC”

This is some very elaborate scheming by hackers and cybercriminals just to get visitors to download their “mother lode of infectious code”, but it will probably work on many people.

We decided to show the code here, although the code is inserted graphic files, so that if your website starts being tagged as suspicious by Google with some of the domains listed here, and you get the “This site may harm your computer” moniker, you can compare this code to some of the code you might see in your site and have a better understanding of what is going on.

What To Do

First you need to contact your hosting provider. Have them read this blog post so they can also better understand what’s going on.

Have them check at the server level for unusual processes running on the server. If you’d like, have them contact us and we can help them diagnose this further. We can show them the other websites on your server that are also infected with the exact same code.

At this point we still don’t know how the server gets infected. Be prudent and scan your PCs with a different anti-virus than what you’re currently using. Why? Because if you are infected and you have anti-virus already installed, then it’s obvious that the virus knows how to evade detection of your current security.

We’ve had good success with AVG, Avast or Avira. If you already have one of those installed, then use one of the others. You need to use something different. Scan and clean all PCs with FTP access to your site.

Then change FTP passwords on all of your accounts.

This will have to be done as soon as you start seeing these infections as it may take some time to fully investigate and remediate – so don’t be late (sorry, it’s been a long few days).

Post comments below if you’ve been infected by this or know someone who has.

Thank you.

Friday July 24, 2009 update: We worked with a couple different hosting providers who had servers infected with this and it appears the way these malscripts are injected into the the webpages is through a process on the server. The cybercriminals have cleverly named this process “crontab” however this process runs under the user name “nobody” typically the same user name that Apache (or httpd) runs as.

The file that executes this process is remotely deleted by the cybercriminals controlling it so it just runs in memory. Once the server is rebooted, the process disappears and doesn’t appear to return. The hosting providers also mentioned implementing suPHP as an aid to blocking this from happening again.

This is quite clever as how many times does a shared server really get rebooted? Probably not very often unless there’s a reason to shut-down numerous (hundreds?) websites all at once.

Keep posted, we’ll be adding more information as we get it.

By

www.tiscali.co.uk was hacked

According to information freely available, the website www.tiscali.co.uk has been hacked.

Primary Method: SQL Injection

Hazard to Humanity: Low

Date: March 15, 2009

Although hundreds of thousands of people login to this website, unless they’re using the same username and password for this site that they do for all their online activity; banking, bill paying, ebay, etc., then the actual risk is low. We gave this one a Low rating because it isn’t a site with financial information, but it is a very popular website.

Remediation and Preventative Measures: Properly sanitizing all data prior to inserting into database

By

www.telegraph.co.uk hacked

According to reports, the website for The Telegraph was hacked.

Primary Method: SQL Injection

Hazard to Humanity: Very Low

Date: March 6, 2009

Actually the site was: search.property.telegraph.co.uk and only the usernames and passwords of people who login to the site were exposed. As always, often times people use the same username and password for a variety of logins so an incident like this could grow bigger than just having someone post comments using a “hacked” username and password.

Remediation and Preventative Measures: Same as for all SQLi attacks – properly sanitizing all data submitted to a SQL database.