Security

Security Blog Home

Why is There a Chinese Porn Network in Utah?

September 14, 2012 - By Chris Larsen

WebPulse has a number of modules for detecting new pornographic and "adult" Web sites. The busiest modules are the various DRTR language modules (20 of them), but there are also some porn-focused rules in the heuristics engine, and the Malnet Tracker can also track porn networks, in addition to malnets and spamnets. And that's just for the new sites that come on line; the database already has ratings for sites we've encountered in the past. In any given day, that will be a lot of porn. And that brings us to the Chinese pornsters...

...and to a tool called SeeMore which we haven't written about before. True to its name, SeeMore lets us see things in the data we couldn't before, since it ambitiously seeks to pull together ALL of the logs, from all of the WebPulse and BCWF sources, and then to collate that data. (More about SeeMore later.)

 

Anyway, one of the things SeeMore highlighted was a bunch of oddly named sites that it saw were sharing a set of IP addresses, and whose URLs were consistently being flagged as Porn by DRTR's Chinese module. And those IP addresses are registered to a company in a small town in Utah...

Looking at the data from the previous seven days, the DRTR Chinese module flagged over 75,000 porn pages (and remember, that's just from Chinese porn sites that aren't already in our database!)

If we rank the top 25 IP addresses hosting all of those sites, the table looks like this:

 

Rank IP Address Location
#1 98.126.84.__ Orange, CA
#2 204.45.68.__ Denver
#3 204.15.255.__ Las Vegas
#4 98.126.72.__ Orange, CA
#5 199.188.111.__ Hebei
#6 220.181.118.__ Beijing
#7 184.168.105.__ GoDaddy (AZ)
#8 110.34.177.__ Thailand
#9 67.215.246.__ Santa Ana, CA
#10 218.75.30.__ Zhejiang
#11 66.175.218.__ New Jersey
#12 98.126.4.__ Orange, CA
#13 114.112.56.__ Beijing
#14 69.197.33.__ Fullerton, CA
#15 203.69.40.__ Taiwan
#16 174.127.103.__ Providence, UT
#17 199.87.233.__ Los Angeles
#18 58.68.146.__ Beijing
#19 208.43.173.__ Dallas
#20 67.198.160.__ Sacramento
#21 63.141.247.__ Kansas City
#22 70.36.100.__ Los Angeles
#23 121.205.90.__ Fujian
#24 199.87.235.__ Los Angeles
#25 184.105.216.__ Fremont, CA

 

While California is clearly the Undisputed King of Chinese Porn Networks, with 10 of the top 25 sites (8 of them in the Los Angeles area), I thought it was interesting to see tiny Providence, Utah, as #16.

 

Taking a Closer Look:

Providence is a "suburb" (using the term loosely) of Logan, which is the home of Utah State University. A town near a top aerospace research university is a logical place to have some high-speed internet infrastructure... But apparently, "Hosting Services Inc." had enough extra capacity that they rented out server space and bandwidth to a big Chinese porn network to help pay the bills.

The sites in this porn network have to keep moving, presumably so that the "Great Firewall of China" will have a harder time blocking them. That means they go through a lot of domain names, and those domain names tend to be very distinctive: e.g., 82aaa.com, hhh47.com, hhh48.com and so on.

Plugging one of those domains into nslookup showed that they also like to have quite a lot of IP addresses ready to use:

 

Address: 50.23.85.__ (2 IPs, hosted at SoftLayer, in Dallas)
...
Address: 67.213.208.__ (16 IPs, hosted at Hosting Services, Providence, UT)
...
Address: 69.4.224.__ (4 more IPs at Hosting Services)
...
Address: 173.255.132.__ (22 more IPs at Hosting Services)
...
Address: 173.255.133.__ (12 more IPs at Hosting Services)
...
Address: 174.127.96.__ (4 more IPs at Hosting Services)
...
Address: 174.127.102.__ (3 more IPs at Hosting Services)

 

(That's a total of 61 IPs in Providence that are rented out to the pornsters.)

To be clear, it's not easy to prove that the Web servers are actually located in Providence. Certainly, that's what Hosting Services is telling the Internet "officially." A tracert shows that the final IP in the routing chain identifies itself as being owned by midphase.com -- which is a domain registered to Hosting Services in Utah. However, the two hops immediately prior to midphase.com are on IP addresses that are assigned to a company called SoftLayer, which says they're in Dallas. So it may be that the actual "building" is in Dallas, but the "landlord", and his "mailing address" are in Utah, to use a real-world analogy.

Not that it matters much. We just flag 'em as we see 'em, regardless of where they come from.

 

A Little More About SeeMore:

Much of our research hinges on those wonderful WebPulse traffic logs; it would be pretty hard to find the Bad Guys without them. But as much as we love our logs, there are definite love-hate elements in the relationship. Specifically, they're just so darn BIG...

...and big may be beautiful, but it's also SLOW.

We've been able to get some good results with a tool called Splunk on our smallest logs -- which aren't exactly "small" -- but the licensing costs for Splunk on the really big logs is just way too high; I'd rather have extra people on my team.

Enter Dr. Jon, one of our resident geniuses (genii? his talents are kind of magical...), who came up with SeeMore. "Inspired by" (but not directly based on) the custom high-speed, high-capacity data engine in Blue Coat Reporter, he created a system that blows Splunk out of the water for speedy high-volume searches, especially if they involve regular expressions, which we tend to use a lot.

This is game-changing technology for Blue Coat, even though it isn't customer facing, and it isn't really something we could sell to anyone, because it's built solely for our logs (and, crucially, the kinds of searches that we run a lot of), so it's tied too closely to our world. But even outsiders who aren't data miners can get the basic idea -- the WebPulse team built a data tool that's way faster than Splunk, which is an industry leader -- and understand that it lets us correlate data in fun new ways. (And potentially migrate some data-intensive background processes into the foreground...)

 

--C.L.

@bc_malware_guy