Recently, ScanSafe STAT investigated blocks on the nature.com website. Nature is an internationally recognized journal of research articles pertaining to science and medicine. Turns out, Nature may also be a victim of the FerTP Trojan, which scans infected machines looking for FTP login credentials, then uses those credentials to log onto any websites found and append a malicious iframe to the default loading pages. That iframe loads exploit code from a path on the money2008.org domain, hosted in Israel. The exploit code attempts to download malware from 89.149.253.17, hosted in Germany. Of course, just because a site is hosted in a particular country it doesn't mean the attackers are from that country. The web creates an international playing field and the actual attackers could be anywhere.

The malware contained on 89.149.253.17 is a DNS changer which can then forcibly (and surreptitiously) redirect the user to sites other than they expected. And because the DNS changer can resolve any domain to any IP, the effect would be seamless - and serious. For example, an infected user that typed in the URL for the bank website could have it resolved to an IP not owned by the bank. That IP could (and likely would) host a look-alike site for the legitmate bank and steal their account credentials when they attempted to login.

There's an old saying in the industry that you are only as secure as your weakest link. In this case, presumably, that weakest link was a workstation somewhere within Nature Publishing Group. And because of their considerable web presence, that single Trojan infection was able to impact an untold number of users who might have visited nature.com over the past couple of days. Within Wikipedia, nature.com is one of the top 500 linked sites (#333 according to Newswriter). And according to Quantcast, Nature.com is "a top 5,000 site that reaches over 877K U.S. monthly uniques". That would be about 29.3k unique visitors each day that risked exposure during the compromise (which fortunately has since been remedied).

Who's your weakest link?

It's good to say goodbye to April - it was a busy month of malware. As noted, the SQL injection attacks represented 12% of all ScanSafe malware blocks for the month. But that 12% pales when one considers that blocks in April were up 35% overall (and that's on top of an increase seen in March). What's driving the increases are large (very large) numbers of middle tier sites which have been apparent victims of stolen FTP credentials. The stolen credentials have been having ballooning impact.

All of this is having an enormous impact on web surfers. Because while individually these middle tier sites may not pack in the visitors, collectively they make up the long tail of the Web and account for the bulk of all Web traffic. In April alone, 49% of customers, or a ratio of 1:2 customers innocently accessed one of these impacted sites (of course, protected by ScanSafe throughout).

We'll be sending out more details about this ongoing attack in the coming week.

Following are seven malware hosts involved in SQL injection attacks since October 2007:

yl18.net (Oct/Nov)
uc8010.com (Dec/Jan)
2117966.net (Mar)
nmidahena.com (Apr)
414151.com (Apr)
aspder.com (Apr)
nihaorr1.com (Apr)

The attacks, targeting improperly code ASP/ASPX running under Microsoft SQL Server, are rendered using hexadecimal queries, as seen in the following abbreviated example:

DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x6400650063006C00610072
006500200040006D00200076006100720063006800610072002800380030003000300029003B00730065
007400200040006D003D00270027003B00730065006C00650063007400200040006D003D0040006D002B
0027007500700064006100740065005B0027002B0061002E006E0061006D0065002B0027005D00730065
0074005B0027002B0062002E006E0061006D0065002B0027005D003D0072007400720069006D00280063
006F006E007600650072007400280076006100720063006800610072002C0027002B0062002E006E0061

Briefly, the CAST command seen in the example above converts the hexadecimal into a standard string. The converted result is a SQL query that searches for table objects which contain text strings, looping through those found and appending the malicious iframe to each.

That the method is nearly identical between all the attacks means little -  an automated tool is presumably used in each of the instances, thus one would expect similarly formed attacks. However, the attacks share many other commonalities with one another which point to a possible connection.

 Four of the domains - uc8010.com, nmidahena.com, 414151.com, and nihaorr1.com - have very similar (though obviously bogus) whois info (including the repeated use of the surname "Zhang", the most common surname in China). And each of the four also share the same primary and secondary DNS:

    Primary DNS:  dns.51ym.com  219.153.20.207
  Secondary DNS:  dns1.51ym.com  61.128.198.181

Though the aspder.com whois info varies considerably from the others, the IP address for the domain (60.172.219.4) is also shared by 414151.com - which as mentioned, shares many similarities to uc8010.com, nmidahena.com, and nihaorr1.com.

The two that don't match directly (other than via the method of attack) are yl18.net and 2117966. There is no whois data for yl18.net to which to compare. But there are interesting patterns in some of the whois details that indicate a possibility of a connection between 2117966 and aspder.com (and, as noted, aspder.com appears to have a direct link to 414151.com, which in turn shares many similarities with the rest).

The attacks themselves appear to be progressive in nature. With each successive attempt, the attacker(s) appear to be honing their targeting skills. As an example, the uc8010 attacks in December/January targeted obscure, seldom visited pages (the Ikea website was one of the few exceptions - multiple highly visited pages on that site were impacted). And while the 2117966.net attacks impacted considerable numbers of sites, an equally considerable number of the attacks failed because the output was munged and incapable of running. 

In April, however, both the targeting and the output quality had evolved considerably - most particularly in the nihaorr1.com attacks.

As an example of that targeting, in addition to tens of thousands of sites worldwide, the nmidahena.com attacks compromised hundreds of gov.cn sites, the effects of which can still be seen in this Google search. Coincidentally, the nmidahena.com domain also had one of the shortest lifespans of any of these seemingly related SQL injection attack domains (ScanSafe's TTL estimate is 4 days). When the nihaorr1.com attacks appeared later in April, the attackers appeared to take great care to avoid gov.cn domains. As ssen in this Google search, of those Chinese sites that were impacted, most were primarily those with English language pages. 

In the month of April, approximately 12% of all ScanSafe malware blocks were a result of the nmidahena.com, 414151.com. aspder.com, and nihaorr1.com attacks - and approximately one in five customers attempted to access one of the infectious pages (but they were protected, of course, by ScanSafe).

So, a likely connection between most or all of these seven attacks and an increase in proficiency such that the latest round targeted not only much higher profile pages, but was also honed to avoid certain types of sites. Wonder what's next?

This SANS handler diary entry discusses one of the automation tools used in the SQL injection attacks we've seen so much of lately. These include the search cache poisonings that were so ubiquitous throughout March.

The entry led with a link to their post on the mystery host server compromises first reported by ScanSafe. The context for inclusion of that link (http://isc.sans.org/diary.html?storyid=3834) wasn't made clear. This led to assumptions that the SQL injection tool that SANS was discussing was the tool used in the host server compromises, as seen in this article: "Security gumshoes locate source of mystery web compromise".

In fact, the two are unrelated. SANS was kind enough to post an update to clarify this. That update reads, in part:

"First, let me clarify that this attack is a pure SQL injection. There was another mass attack at the beginning of the year which was more sophisticated and involved complete compromise of the web servers (i.e. the bad guys had the root access to the servers).
The tool described in this diary was used in the attack described in Kevin's diary (http://isc.sans.org/diary.html?storyid=4139)."

In other words, not the attacks discussed in Mari's SANS diary entry @ http://isc.sans.org/diary.html?storyid=3834.

On April 3, Trend Micro had also reported on the use of automated tools in the ongoing SQL injection attacks. It's not clear whether SANS is reporting on the same tool or a different one. What's interesting is that the tool(s) native language is Chinese, casting some doubt on claims that the recent round of SQL injection attacks are originating in Russia.

Now getting back to the still unsolved mystery web host compromise, we continue to block malware resulting from those host server attacks and the investigation into the source of those attacks is still ongoing. The situation has improved dramatically though. In March, the blocks from the host server attacks represented .3% (that's point three percent) of all malicious traffic, down from a high of 15% (fifteen percent) when the attacks were first reported in January.

It seems several pages on the Honda Thailand website are outfitted with a malicious iframe that loads exploit code intended to install a keylogger/data theft Trojan. ScanSafe STAT discovered the compromise while investigating a series of zero-day blocks on the site. 

The malicious script referenced by the iframe attempts to exploit the Microsoft XMLHTTP ActiveX Control Code Execution Vulnerability described in MS06-071, as well as the RDS Data Control vulnerability described in MS06-014). The following CLSIDs are targeted:

BD96C556-65A3-11D0-983A-00C04FC29E36 (RDS Data Control)
AB9BCEDD-EC7E-47E1-9322-D4A210617116 (Business Object Factory)
0006F033-0000-0000-C000-000000000046 (Outlook Data Object)
0006F03A-0000-0000-C000-000000000046 (Outlook.Application)
6e32070a-766d-4ee6-879c-dc1fa91d2fc3 (Microsoft Update Web Control)
6414512B-B978-451D-A0D8-FCFDF33E833C (Software Distribution Web Control)
7F5B7F63-F06F-4331-8A26-339E03C0AE3D (WMI Object Broker)
06723E09-F4C2-43c8-8358-09FCD1DB0766 (VsmIDE.DTE)
639F725F-1B2D-4831-A9FD-874847682010 (DExplore.AppObj)
BA018599-1DB3-44f9-83B4-461454C84BF8 (Microsoft Visual Studio DTE)
D0C07D56-7C69-43F1-B4A0-25F5A11FAB19 (Microsoft.DbgClr DTE Object)
E8CCCDDF-CA28-496b-B050-6C07C962476B (VsaIDE.DTE)

As with several other known malware hosts, the IP for the site hosting the malicious script resolves to HopOne Internet, a US-based co-location provider. HopOne doesn't host sites directly, they do that through their resellers. Those resellers likely sell to other hosting resellers, and so on. These multi-tiered affiliate relationships can short change users, since the time it takes to play "who's the real host" extends the time the malware site is live. And, of course, that's exactly what the attackers want.

Some of the pages that have been compromised were completely replaced by the malicious iframe. For example, a page that should point to a specific automobile model will instead appear (on the surface) to be blank. Other pages have the malicious iframe embedded in the normal page source.

This is the second (known) compromise of the Honda Thailand website in recent months. In October 2007, the Honda Thailand website was defaced by a Turkish hacker who uses the moniker PowerDream.