By

Our take on the “soaksoak” (revslider) infection

Ethical reportingHere’s our review of the recent revslider plugin exploit – or as some call it, “soaksoak” (ouch).

On November 22, 2014 while removing malware from a number of sites, we noticed a large number of them had backdoor shells buried in the revslider folder. After the first 100+ sites, we noticed the pattern.

A little Google searching found this site: http://whatisgon.wordpress.com/2014/11/30/another-revslider-vulnerability/

Our first notification was to hosting providers we work with. We told them what to search for so they could alert their customers. The problem was that we did not report it to the right people. That was our mistake.

The first sites did not have any code injected into the swfobject.js or collect.js files, or the .html or .php files. The sites simply had numerous backdoor shells spread throughout the wp-includes, wp-admin and wp-content folders. It appears as if the hackers were looking for the deepest level folders they could find.

Some online searching showed very few infected sites. 1,100 sites. We did reach out to those website owners to let them know – not to try and drum up business but to be responsible. And discrete.

Many of the forums are reporting links to 122.155... but we’re also seeing links to other IP addresses as well. The injected malscript can be in just the swfobject.js files or all .js files, all .html and selected .php files.

Some of the sites have code injected into the collect.js file which apparently is the same code that the malicious links point to. This leads us to believe that the hackers could use these infected sites in their future malicious links and most recently we see the infectious code using the local sites URL pointing to the infected collect.js file.

You’ll find the malicious code in the template-loader.php file located in wp-includes folder. This should be replaced with a copy of the original file downloaded directly from the WordPress site.

We choose not to alert all the script kiddies
I know what you’re thinking, if we knew about this back in November, why didn’t we blog about it?

Our searches showed a growing number of sites being infected. As of December 17, 2014, we saw 307,000 sites still infected with this – and they have all been verified by us as well.

We did not want to be the one to let every script-kiddie know so they could go out searching for these sites and take advantage of the backdoor shell on all these sites. We’ve been contacting these site owners to let them know and we feel that is the responsible thing to do.

I’m not saying that this was reported wrong. I’m just saying we made the decision to not report it to the masses.

Maybe a missed opportunity. It’s not the first time and it won’t be the last.

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

Website security plugins exploited

website security is only as strong as your weakest link
This post is not to bash or degrade the work that some security plugins do for website security.

We don’t believe in them, but that’s our opinion. You’re free to have your own opinion.

The purpose of this post is to drive home 3 main points:

  • There is no “set it and forget it” website security strategy
  • There is no substitute for updating – daily
  • Sometimes the function of website security is also the point of entry

During the month of September 2014, three main WordPress security plugins had some major vulnerabilities.

First (I believe) was WordFence. This plugin provides many security features for a WordPress site:

  1. Two-factor authentication
  2. File Integrity Montioring
  3. Firewall
  4. Blocks ranges of IP addresses
  5. Scans for over 44,000 different forms of malware
  6. and many other features

As of 9-29-2014, according to the WordPress Plugin repository, there were 3,223,158 downloads. This plugin receives some very high ratings as well.

In early September it was disclosed that this plugin suffered from some vulnerabilities.

Next, came the vulnerabilities of the All In One WP Security & Firewall plugin. This plugin:

  • Helps you change the admin username
  • Protects against brute-force attacks
  • Block ranges of IP addresses
  • Adds CAPTCHA to login forms
  • Automates backups
  • and other features

As of October 11, 2014 this plugin shows 475,663 downloads and again is very highly rated.

September of 2014 closed out with vulnerabilities in the BulletProof Security plugin. Some of the features of this plugin are:

  • htaccess Website Security Protection (Firewalls)
  • Login Security & Monitoring
  • Security Logging
  • Backups
  • HTTP Error Logging
  • and other features

As of October 7, 2014 this plugin has been downloaded 1,290,979 times.

For all 3 that’s potentially almost 5 million vulnerable websites. It’s actually less than that because quite often we remove malware from WordPress sites with all three plugins installed. I’m sure they’re not all properly configured, but they are installed.

You see, quite often people are looking for “plug and play” security. We know it doesn’t quite work that way. It sounds cliche but security is a journey, not a destination. You don’t someday do this and this and that and then you’re secure – forever.

Check!

That’s done.

website security is all finished!

Not quite.

If there was a website security strategy that was “set it and forget it” then there wouldn’t be any need for our industry (website security). Someone would have published a YouTube video or a downloadable PDF report detailing the steps involved in this apply once and never worry again strategy.

Instead, website security is more like, “lather, rinse, repeat”, only the lather is applying new layers of shampoo. In this case, updating WordPress and your plugins is the shampoo. It must be done consistently. I’m sure you don’t wash your hair once and then you’re good for life, right?

Website security strategy is the same way. What’s safe today, could be vulnerable tomorrow. You can’t rest on what you’ve done today.

While you’re scouring the Internet or the WordPress Plugin repository for that “one” magic plugin that will end all your website security worries, just remember, it too has to be updated. There is no substitute for good, sound security principals.

This isn’t the website security blame game

You’ll notice I didn’t elaborate on the specific vulnerabilities of these plugins. That doesn’t really matter. What matters is that each of these had updates very soon after learning of the vulnerabilities. They did what they’re responsible for.

Or as some of our customers say, “they did the needful”. After that, it’s your responsibility to apply their updates.

I’ve said it before, hackers only need one way in. You need to keep every potential point of entry secured. Your website security is only as strong as your weakest link. Don’t forget that.

If you have any opinions about this post, please post a comment. If you feel this is something to be shared, please do.

Thank you.

By

Large website used to attack other websites

As a player in the website security space, we frequently find research of other organizations and we like to bring it to your attention so you learn more about the cybercriminals who want to infect your website with malware for their nefarious purposes.

In research announced by Incapsula: http://www.incapsula.com/blog/world-largest-site-xss-ddos-zombies.html, a website in the Alexa’s Top 50 was used to launch DDoS (Distributed Denial of Service) attacks on other websites.

As usual, you might ask, “Tom, why is this website security news important to me?”

It’s important that you learn why hackers want your website. You need to know why website malware is so prevalent. Yes, even if it’s a small blog that only covers events in your local community. Hackers can use your website for any of their money making schemes.

which flooded our client with over 20 million GET requests originating from the browsers of over 22,000 Internet users

In this report, which gets a little technical, they also mention that the new code is tracking the attack for what appears to be for billing purposes. Yet another income stream for cybercriminals.

The hackers could be offering this as a service, for which they charge a fee.

If you have questions about this, please ask in the comment section.

Thank you.

By

Previewing Outlook messages can lead to infected computer

Microsoft has announced a vulnerability in Word 2010. For those of you who aren’t intimately familiar with Microsoft Office products, Microsoft Word is the default reader for Outlook 2007, Outlook 2010 and Outlook 2013.

https://technet.microsoft.com/en-us/security/advisory/2953095

If you’re using Microsoft Outlook as your email program, this could affect you.

Why would a company dedicated to website security make you aware of this?

This particular vulnerability exposes your local computer to remote code execution exploitation. This means that if a hacker sends you a carefully crafted email message in RTF format, just previewing the message in Outlook, with Word 2010 as your default reader, would allow remote code to be executed on your computer – which means your computer could be infected.

We want to bring this to your attention so that you update all your software. If your local computer gets infected the hackers could steal your login credentials to your hosting account, your CMS (WordPress, Joomla, etc.), login to your account and infect your website.

We are concerned with your website security, but along with this comes being concerned about your local computer security as well.

We’ve stated this before, but it becomes clear in Microsoft’s announcement that the attacker, if successful, will have the same rights as the currently logged in user. If you login to your local computer as administrator, guess what? The hacker will have the same rights – administrator.

An attacker who successfully exploited this vulnerability could gain the same user rights as the current user.

It’s advised that you create a separate “user” account on your computer. This user does not have the ability to install programs. If you want to install a new program on your computer, you logout as this user, login as administrator, install the software, then logout as administrator, login as the user and proceed with your normal activity.

Yes, this is not the most convenient way, however, neither is having your computer compromised.

Always keep your local computer software updated. This helps us keep your website security at the highest level.

Please post a comment if you find this helpful. Tweet this to your friends and family.

By

How hackers use your website

Due to our work in website security, quite often we’re asked “Why?”

As in, “why do hackers want my website?”

From this article by Webroot: http://www.webroot.com/blog/2013/07/11/new-commercially-available-mass-ftp-based-proxy-supporting-doorwaymalicious-script-uploading-application-spotted-in-the-wild/

you can see that sometimes hackers use your website as a proxy. A proxy is a buffer to their real location. Some of you ask if we can tell you exactly where the hacker is. Unfortunately we can’t. Not for any legal reason, but because hackers hide behind multiple layers of these proxies.

The website security industry would love to be able to track down hackers, but it’s rarely possible.

For instance, they might be in one country. Their computer connects to a server in South America (that they’ve already compromised), from there to a server in Switzerland, then to a compromised server in North America. The last IP address is all that will appear in your log files. In our example here, the last IP address would be from the compromised server in North America.

When we have access to the log files, we mine the IP addresses out of the log files and report them to the proper abuse department. This is a small step toward making the Internet safer, and is some what time consuming, but we do it to help notify others that they have an infected website or server.

The tool mentioned in that article also shows one of the tools used by hackers to upload infectious content to your site – automatically. Many of you believe that someone is sitting behind a computer and attacking your website, or uploading malicious files to your site.

Not at all.

Most, if not all, of today’s website infections are the result of an automated tool.

After one of the screen captures this caught my attention:

The tool works in a fairly simple way. It requires a list of user names and passwords, which it will then use to automatically upload any given set of files/scripts through the use of automatically syndicated fresh lists of proxies.

So, when the hackers have a list of compromised FTP users, they load it up in this tool and then they can send the same infectious code to hundreds or thousands of websites.

With the log files activated, we can see the FTP account used and the IP address of where the connection originated (the last proxy IP address).

Here’s our Website Security Best Practices for FTP accounts:

  • Create a separate FTP account for each user. Not all hosting providers allow this. Many only allow one. But if you’re with a hosting provider who provides cPanel, then you can create separate FTP accounts. Also make certain they have good strong passwords.
  • Activate the logs. Most hosting providers have the logs turned off by default. They know that nobody other than us, ever read the logs so why consume so much disk space? Again, if you’re on a cPanel account, scroll down to the section labeled “Statistics” and select the “Access Logs” icon. It might be different on various hosts, but that should get you in the general area. You can check both boxes. If you’re not on a cPanel account, then ask your hosting provider.
  • If you provide access to a web developer or anyone else, ask them what anti-virus program they use on their local computers. Every potential point of entry needs to be accounted for. If they have a virus on their computer and it steals the login credentials for the FTP account you provided them, guess what? You could have the best website security team in the world (yes – us!) and your website will still get infected.
  • Be diligent about the FTP accounts. If someone that you’ve provided FTP access to no longer needs that access, then delete their FTP account. Remember, hackers only need one way in. Yes, this is a pain, but so is getting your website infected.

You’ll notice that we didn’t recommend SFTP as many do.

Why?

We understand how hackers work. While SFTP sounds more secure, the reality of it is – that it really isn’t.

All SFTP does is encrypt the traffic between your computer and the destination – your website. However, a few things to mention.

Most hosting providers will only allow you to create one SFTP account and frequently it’s the same account used to login to your hosting account. If you want to provide access to someone who will be making changes to your website – legitimate changes, you have to give them access to your hosting account. If you have 3 or 4 people who need access to your website files, now you have 3 or 4 more potential points of entry for hackers.

With only one account, you have lost the advantage of FTP logging. There will only be one account listed in there. If your website security is compromised, looking in your log files will tell you how it happened, but you have no idea who has the virus that is stealing the account information.

Which brings me to the last reason we don’t recommend SFTP.

We’ve seen the way the viruses/trojans work. They steal the login URL, username and password from your computer. It doesn’t matter if you you’re using SFTP or FTP, it steals the login address and protocol. The hackers will login and upload their malicious files using an encrypted channel (SFTP). They can thank you later for thinking of their need for security.

This is the same reason we don’t recommend changing the login URL and username for WordPress. When hackers steal the information you may have changed your login URL to http://(yoursite.com)/Supercalifragilisticexpialidocious and your admin user to: rumpelstiltskin, but when the hackers steal the information, they steal that as well.

Let me know your thoughts about this. Post a comment. Ask a question.

Thank you for your time.

By

l_backuptoster.php still showing

Over the past few weeks we’ve cleaned a number of websites that were infected with l_backuptoster.php and while it’s been around awhile, we thought we would share our experience. This infection isn’t so much about website security as it is about computer security, but it does eventually affect your website security as well – which is why we’re involved.

For those of you unfamiliar with this little gem, it’s used by hackers to send SPAM. It is uploaded to the website via FTP – which means that the FTP password has been compromised, or worse, the hosting account password has been compromised.

In the most recent instances of websites infected with the l_backuptoster.php file, a new FTP account was created on the hosting account and that was used to upload the files. The files is uploaded with 2 other files: body1.txt and body.txt, used, then deleted until the next time the hacker wants to send SPAM.

Here is what you might see in your FTP logs:

Tue Dec 20 06:32:41 2011 0 xx.xx.xx.xxx 320 /home/path/public_html/body1.txt b _ i r candy@yourdomain ftp 1 * c
Tue Dec 20 06:32:42 2011 0 xx.xx.xx.xxx 292 /home/path/public_html/body.txt b _ i r candy@yourdomain ftp 1 * c
Tue Dec 20 06:32:42 2011 0 xx.xx.xx.xxx 8160 /home/path/public_html/l_backuptoster.php b _ i r candy@yourdomain ftp 1 * c

The xx.xx.xx.xxx would actually be where this traffic is originating. The number after is the file size, the path and the FTP account used.

You see that first the body1.txt file, with a size of 320, was uploaded to the folder shown, followed by body.txt with a size of 292 and finally the l_backuptoster.php file with a size of 8160.

If you’ve been infected with this, and you have your Raw Access Logs activated, you will probably also see entries like these in your access logs:

xx.xx.xx.xxx – – [12/Jan/2012:12:34:58 -0700] “GET /l_backuptoster.php?id=4550&ipAddr=xx.xx.xx.xxx&serv_name=www.yourdomain HTTP/1.1” 200 205 “-” “-”
xx.xx.xx.xxx – – [12/Jan/2012:12:34:58 -0700] “GET /l_backuptoster.php?id=4554&ipAddr=xx.xx.xx.xxx&serv_name=www.yourdomain HTTP/1.1” 200 205 “-” “-”

Again, the xx.xx.xx.xxx would actually show the originating IP address. In our work, we track down this IP address and report it to the proper people as this is an indication that the originating IP address is being used in a suspicious manner.

In the above log file entries the ipAddr matches the first IP address and the serv_name parameter would be your, or the infected URL.

You will probably see hundreds of these lines if your website is being used with the l_backuptoster.php file.

What we found in each case of a website infected with l_backuptoster.php was that the FTP account used to upload these files was not created by the hosting account owner. The only way this could have been achieved was if the hosting account password had been compromised.

If this is true, then the hackers are no longer just stealing the FTP login credentials, but their keyboard loggers are also recording all logins and the hackers are very interested in infecting websites so why not create their own FTP account.

As stated earlier, after the activity in the access logs, we found that the 3 files uploaded were deleted so there was no trace. The hackers would simply upload the files again at a later time, use them and delete them.

Without constant watching of the log files, we would not have seen this.

If you have been a victim of the l_backuptoster.php website infection, here’s what you should do:

  • Change your hosting account password
  • Check your hosting account for unused or unauthorized FTP accounts and delete any that you aren’t familiar with
  • Create new passwords for remaining FTP accounts
  • Perform a full system virus scan with either Avast! or AVG anti-virus and use Malwarebytes as a secondary scanner. If you’re using a Mac try BitDefender
  • Check your log files on regular basis. Download them to your computer and search for ‘l_backuptoster.php’

One point to remember, do not ever have your browser save your hosting account password or the any passwords. We have copies of the viruses hackers use to steal passwords and they work extremely well on browser saved passwords!

If you’ve been infected by this and have more to add, please leave a comment. If you need help in cleaning this up and getting everything “locked down”, please email me at traef@wewatchyourwebsite.com or call at (847)728-0214.

Thank you.

If you found this useful, Tweet about us, like us on Facebook or follow us on Google+.

By

CBI website hacked by ‘Pakistani Cyber Army’

According to the website: hindustantimes.com, the website for the Central Bureau of Investigation (CBI) cbi.gov.in, was defaced by a group calling themselves ‘Pakistani Cyber Army’. CBI is connected to the world police organization called Interpol.

Anyone visiting that page was redirected to another page claiming the defacement was in response to Pakistani websites being hacked by a group calling themselves, ‘Indian Cyber Army’.

In addition to the CBI website, the Pakistani Cyber Army also claims to have hacked 270 other websites.

What’s also interesting is that the Pakistani Cyber Army has a Facebook page and a few of the websites we visited in researching this, international news sites, were infected as well, but apparently not from the Pakistani Cyber Army.

This is what’s referred to as ‘hacktivism’ or hacking for a group of activists.

However, keep in mind that while it was simply a defacement, imagine if they had setup some type of ‘drive-by’ download. All the people visiting a trusted .gov.in site would have been infected, or at least been subjected to an infection attempt.

Website security is no longer an option.

Let’s be careful out there, huh?