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..
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:
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.
4 responses to “Blacklist Candidate Number 2008-05-31”
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.
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
> 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?
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.