Latest TweetsAll o' me plugins freshly updated and ready for WP 5.0 :) profiles.wordpress.org/special…
Perishable Press

Blacklist Candidate Number 2008-05-31

Welcome to the Perishable Press “Blacklist Candidate” series. In this post, we continue our new tradition of exposing, humiliating and banishing spammers, crackers and other worthless scumbags..

[ Photo: Bob Barker waves at you ] Just under the wire! Even so, this month’s official Blacklist-Candidate article may be the last monthly installment of the series. Although additional BC articles may appear in the future, it is unlikely that they will continue as a regular monthly feature. Oh sure, I see the tears streaming down your face, but think about it: this is actually good news. After implementing the 3G Blacklist, finding decent blacklist candidates is becoming increasingly difficult. This is a good thing because it indicates that the new blacklist strategy is working. Nonetheless, every now and then, some brainless bozo will magically appear and poke around where it shouldn’t be poking. Such is the case with this month’s Blacklist Candidate Number 2008-05-31:

Come on down! You’re the next worthless turd to get banished from the site!

Synopsis

After a several quiet weeks in the access logs, IP address 210.210.119.145 suddenly rears its ugly head with a repeat single-vector exploit attempt. On May 8th, 2008 at 2:28 PM, IP address 210.210.119.145 made fifteen different non-existent resource requests in less than ten minutes. Each URL request targeted a legitimate, search-engine indexed URL with an appended “_vpi.xml” character string. Each of the 15 attempts record a user agent called “Firebat”. Let’s have a look at an excerpt from the attack log:

Note: in the following log entries, each instance of perishablepress.com was replaced with example.com. This was required to prevent endless 404 errors from googlebot constantly crawling plain-text URLs.
TIME: May 8th 2008, 02:28pm
404: *https://example.com/press/2007/07/_vpi.xml
SITE: https://example.com/
SOURCE: Perishable/Perishable
REFERRER: 
QUERY STRING: 
REMOTE ADDRESS: 210.210.119.145
USER AGENT: Firebat 2.7.12
REMOTE IDENTITY: 

TIME: May 8th 2008, 02:28pm
404: *https://example.com/press/2007/_vpi.xml
SITE: https://example.com/
SOURCE: Perishable/Perishable
REFERRER: 
QUERY STRING: 
REMOTE ADDRESS: 210.210.119.145
USER AGENT: Firebat 2.7.12
REMOTE IDENTITY: 

TIME: May 8th 2008, 02:28pm
404: *https://example.com/press/_vpi.xml
SITE: https://example.com/
SOURCE: Perishable/Perishable
REFERRER: 
QUERY STRING: 
REMOTE ADDRESS: 210.210.119.145
USER AGENT: Firebat 2.7.12
REMOTE IDENTITY:
.
.
.
[ + 12 similar records omitted for clarity ]

I know, I know, not nearly as exciting as some of the previous Blacklist Candidates, however, as the only bozo to apply, IP address 210.210.119.145 wins the prize.

Discussion

As mentioned, the entire round of attacks occurred over a period of approximately ten minutes. However, within that time-frame, the assault is broken down into three distinct, five-request chunks. The first five hits were executed in less than a minute, and demonstrate a deliberate loosening of URL specificity:

TIME: May 8th 2008, 02:28pm
404: *https://example.com/press/2007/07/16/allow-google-reader-to-access-hotlink-protected-images/_vpi.xml
SITE: https://example.com/
SOURCE: Perishable/Perishable
REFERRER: 
QUERY STRING: 
REMOTE ADDRESS: 210.210.119.145
USER AGENT: Firebat 2.7.12
REMOTE IDENTITY: 

TIME: May 8th 2008, 02:28pm
404: *https://example.com/press/2007/07/16/_vpi.xml
SITE: https://example.com/
SOURCE: Perishable/Perishable
REFERRER: 
QUERY STRING: 
REMOTE ADDRESS: 210.210.119.145
USER AGENT: Firebat 2.7.12
REMOTE IDENTITY: 

TIME: May 8th 2008, 02:28pm
404: *https://example.com/press/2007/07/_vpi.xml
SITE: https://example.com/
SOURCE: Perishable/Perishable
REFERRER: 
QUERY STRING: 
REMOTE ADDRESS: 210.210.119.145
USER AGENT: Firebat 2.7.12
REMOTE IDENTITY: 

TIME: May 8th 2008, 02:28pm
404: *https://example.com/press/2007/_vpi.xml
SITE: https://example.com/
SOURCE: Perishable/Perishable
REFERRER: 
QUERY STRING: 
REMOTE ADDRESS: 210.210.119.145
USER AGENT: Firebat 2.7.12
REMOTE IDENTITY: 

TIME: May 8th 2008, 02:28pm
404: *https://example.com/press/_vpi.xml
SITE: https://example.com/
SOURCE: Perishable/Perishable
REFERRER: 
QUERY STRING: 
REMOTE ADDRESS: 210.210.119.145
USER AGENT: Firebat 2.7.12
REMOTE IDENTITY:

Notice the pattern here:

  • [...]/press/2007/07/16/allow-google-reader-to-access-hotlink-protected-images/_vpi.xml
  • [...]/press/2007/07/16/_vpi.xml
  • [...]/press/2007/07/_vpi.xml
  • [...]/press/2007/_vpi.xml
  • [...]/press/_vpi.xml

The legitimate portion of the target URL begins with a specific post, and proceeds with an upward traversal of the (permalink) directory structure. This same pattern is repeated in the subsequent two attacks, which also were executed in less than one minute each.

So to summarize the structure of the attack, we have three sets of scripted requests, each consisting of five URLs of decreasing directory specificity. The total duration of sequential attack execution is probably less than a couple of minutes. Scripted? Yes. Deliberate? Yes. Malicious? Definitely.

Identification

Here is what we know about the identity of this month’s Blacklist Candidate:

  • IP Address: 210.210.119.145
  • Reverse IP Lookup: 210-210-119-145.lan.sify.net

Complete reverse lookup courtesy of kloth.net:

Reverse Lookup Results

Host    145.119.210.210.in-addr.arpa
Type    PTR
Value   210-210-119-145.lan.sify.net

IP Address Contact Information

OrgName:    Asia Pacific Network Information Centre 
OrgID:      APNIC
Address:    PO Box 2131
City:       Milton
StateProv:  QLD
PostalCode: 4064
Country:    AU

ReferralServer: whois://whois.apnic.net

NetRange:   210.0.0.0 - 211.255.255.255 
CIDR:       210.0.0.0/7 
NetName:    APNIC-CIDR-BLK2
NetHandle:  NET-210-0-0-0-1
Parent:     
NetType:    Allocated to APNIC
NameServer: NS1.APNIC.NET
NameServer: NS3.APNIC.NET
NameServer: NS4.APNIC.NET
NameServer: NS-SEC.RIPE.NET
NameServer: TINNIE.ARIN.NET
NameServer: DNS1.TELSTRA.NET
Comment:    This IP address range is not registered in the ARIN database.
Comment:    For details, refer to the APNIC Whois Database via
Comment:    WHOIS.APNIC.NET or http://www.apnic.net/apnic-bin/whois2.pl
Comment:    ** IMPORTANT NOTE: APNIC is the Regional Internet Registry
Comment:    for the Asia Pacific region. APNIC does not operate networks
Comment:    using this IP address range and is not able to investigate
Comment:    spam or abuse reports relating to these addresses. For more
Comment:    help, refer to http://www.apnic.net/info/faq/abuse
Comment:    
RegDate:    1996-07-01
Updated:    2005-05-20

OrgTechHandle: AWC12-ARIN
OrgTechName:   APNIC Whois Contact 
OrgTechPhone:  +61 7 3858 3188
OrgTechEmail:  search-apnic-not-arin@apnic.net

# ARIN WHOIS database, last updated 2008-05-30 19:10

Blacklist

As discussed in the Building the 3G Blacklist series, securing your site against these types of malicious attacks is greatly facilitated by identifying and immunizing against common elements. For example, each of the logged requests for this month’s Blacklist Candidate are associated with the same IP address. Thus, we could prevent all future attacks from this specific address with the following HTAccess code:

# blacklist candidate 2008-05-31: block _vpi.xml attacks 
Deny from 210.210.119.145

..or, to block via PHP:

<?php // blacklist candidate 2008-05-31: block _vpi.xml attacks
$deny = array("210.210.119.145");
if (in_array ($_SERVER['REMOTE_ADDR'], $deny)) {
   header("location: http://www.google.com/");
   exit();
} ?>

However, a much better approach to protecting your site from these so-called “_vpi.xml” attacks is to simply blacklist the malicious character string itself. In doing so, we can block this type of attack from any IP address. Users of the 3G Blacklist can prevent all future occurances of the “_vpi.xml” attack by adding a single line to the first part of the 3G Blacklist:

RedirectMatch 403 \_vpi\.xml

Done.

This concludes this edition of the Blacklist Candidate. Thanks for playing, #2008-05-31 — we wouldn’t have done it without you!

Download

For the purists among us, here is a copy of the logged activity recorded for this month’s Blacklist Candidate.

Download log file »

Jeff Starr
About the Author Jeff Starr = Web Developer. Book Author. Secretly Important.
Archives
4 responses
  1. Heiner Wolf June 24, 2008 @ 3:33 am

    Hi,

    the “_vpi.xml” request are not an attack. They come from people visiting your site. These visitors run a program called “weblin”. It fetches the “_vpi.xml” file from your server to find the chat room that belongs to your pages.

  2. Jeff Starr

    Yes, that does make sense, especially given the way in which the directory structure is traversed while the program is looking for the _xpi.xml file(s). Even so, if my site happened to have a chat room, I would certainly link to it if I wanted people or software to find it. What makes the weblin program assume that my site or any other site has one of these _xpi.xml files to begin with? Are they that common? And if so, why was I unable to find any significant documentation on them? Sorry to bury you with questions, but this information would have good to know before writing the above article.
    Regards,
    Jeff

  3. Heiner Wolf June 24, 2008 @ 8:57 am

    > What makes the weblin program assume that my site or any other site has one of these _xpi.xml files. Are they that common?

    Actually, they are very uncommon. But these requests are very important to give web admins complete (and simple) control where people chat while they visit the site.

    > why was I unable to find any significant documentation on them?

    Any suggestion how you’d want to find the information based on the HTTP logs? We’d love to make it easier accessible.

    Google Firebat 2.7.12 -> yours 1st, “XMPP Client Features Extension – Weblin Code” 2nd

    Google vpi.xml -> 2nd (lmslog.virtual-presence.org)

    Google _vpi.xml -> many public server logs, no help

    Google “virtual presence” would be it, but how can we tell this in a way that shows up in the logs.

    Sorry for the confusion. I created a google alert for “_vpi.xml” to catch it earlier. Would it help to add “virtual-presence.org” to the User-Agent header?

  4. Jeff Starr

    Thank you, Heiner, that is some very useful information. I agree that additional information in the user-agent header would benefit everyone involved. Being able to quickly and easily identify the myriad bots that are constantly crawling around everything could mean the difference between being blacklisted as malicious or identified as a legitimate agent. If it were my project, I would bend over backwards to ensure that everyone knew the purpose, intent, and behavior of the agent in question. This of course would include an easy-to-understand summary that includes anything that webmasters might be stumbling over in their log files (e.g., the _xpi.xml file requests). I would then also include in the user-agent header a direct URL to that documentation for easy access. Eliminating doubt by answering questions up-front is an excellent way to keep people from assuming the worst (as I did) and banning the agent entirely.

[ Comments are closed for this post ]