An exceptionally dumb spambot from China visited my blog and tried to run several Wordpress vulnerabilities that might have worked once with ancient versions. Let me split its traces into several parts:

1. Checking for a no longer existing article and not quite understanding the difference between mod-rewrite fake directories and actual directories. Maybe this script was optimised for blogs who run Wordpress in its stock query string mode (which is brief but not really the most you can get from your blog search engine wise):

58.241.255.38 - - [13/Nov/2008:21:28:15 +0100] “HEAD /using-bbclone-with-wordpress-232-the-almost-easy-way/wp-admin/index.php HTTP/1.1″ 404 - “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”
58.241.255.38 - - [13/Nov/2008:21:28:16 +0100] “GET /using-bbclone-with-wordpress-232-the-almost-easy-way/ HTTP/1.1″ 404 6045 “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”

I’m seeing this quite often and usually this is all that will happen. But not at this time…

2. Trying to mess around in the admin section and not figuring out that I restricted access to my own ip address ranges. Obviously the script has no handler for 403 responses and thus keeps on trying something which isn’t going to work…

58.241.255.38 - - [13/Nov/2008:21:28:18 +0100] “HEAD /wp-login.php?action=logout HTTP/1.1″ 302 - “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”
58.241.255.38 - - [13/Nov/2008:21:28:19 +0100] “HEAD /wp-admin/theme-editor.php HTTP/1.1″ 403 - “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”
58.241.255.38 - - [13/Nov/2008:21:28:20 +0100] “HEAD /wp-login.php?action=logout HTTP/1.1″ 302 - “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”
58.241.255.38 - - [13/Nov/2008:21:28:21 +0100] “HEAD /wp-admin/theme-editor.php HTTP/1.1″ 403 - “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”
58.241.255.38 - - [13/Nov/2008:21:28:22 +0100] “HEAD /wp-login.php?action=logout HTTP/1.1″ 302 - “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”
58.241.255.38 - - [13/Nov/2008:21:28:23 +0100] “HEAD /wp-admin/theme-editor.php HTTP/1.1″ 403 - “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”
58.241.255.38 - - [13/Nov/2008:21:28:24 +0100] “HEAD /wp-login.php?action=logout HTTP/1.1″ 302 - “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”
58.241.255.38 - - [13/Nov/2008:21:28:25 +0100] “HEAD /wp-admin/theme-editor.php HTTP/1.1″ 403 - “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”

This silliness went on for a minute like this, apparently trying to exploit a long fixed vulnerability in Wordpress’ admin section.

3. It follows another try at exploiting an old security hole in the admin section (still not getting that access if forbidden….) before the script finally resorts to plugging trackback spam, which isn’t working either :-). Most people have turned off this feature in the interim, because spammers rendered this feature entirely useless and there are alternative means to learn about one’s backlinks.

58.241.255.38 - - [13/Nov/2008:21:29:11 +0100] “POST /wp-admin/admin-ajax.php HTTP/1.1″ 403 225 “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”
58.241.255.38 - - [13/Nov/2008:21:29:12 +0100] “GET /xmlrpc.php HTTP/1.1″ 200 42 “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”
58.241.255.38 - - [13/Nov/2008:21:29:13 +0100] “POST /xmlrpc.php HTTP/1.1″ 200 774 “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”
58.241.255.38 - - [13/Nov/2008:21:29:14 +0100] “POST /wp-trackback.php?tb_id=1 HTTP/1.1″ 200 135 “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”

4. Attempts at an SQL injection

58.241.255.38 - - [13/Nov/2008:21:29:16 +0100] “GET /index.php?cat=%2527+UNION+SELECT+CONCAT(666,CHAR(58),user_pass,CHAR(58),666,CHAR(58))+FROM+
wp_users+where+id=1/* HTTP/1.1″ 301 - “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”
58.241.255.38 - - [13/Nov/2008:21:29:17 +0100] “GET /index.php?cat=999+UNION+SELECT+null,CONCAT(666,CHAR(58),user_pass,CHAR(58),666,CHAR(58)),null,null,null+
FROM+wp_users+where+id=1/* HTTP/1.1″ 301 - “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”

This has already been fixed for a while and is designed to compromise the admin account (user id=1). Spammers use this for adding or modifying content on a compromised site which then will be spamvertised via blogspam or, if the site attracts enough traffic, for running exploits via inserted iframes.

5. Looking for non-existing trackbacks

58.241.255.38 - - [13/Nov/2008:21:29:18 +0100] “GET /wp-trackback.php?p=1 HTTP/1.1″ 200 135 “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”
58.241.255.38 - - [13/Nov/2008:21:29:19 +0100] “GET /wp-trackback.php?p=2 HTTP/1.1″ 200 135 “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”
58.241.255.38 - - [13/Nov/2008:21:29:20 +0100] “GET /wp-trackback.php?p=3 HTTP/1.1″ 200 135 “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”
58.241.255.38 - - [13/Nov/2008:21:29:21 +0100] “GET /wp-trackback.php?p=4 HTTP/1.1″ 200 135 “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”
58.241.255.38 - - [13/Nov/2008:21:29:23 +0100] “GET /wp-trackback.php?p=5 HTTP/1.1″ 200 135 “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”

This went on till “p” reached the value 25 and was entirely useless because even if trackbacks were enabled, the request was malformed (lacking an id).

6. Repeating trackback spam attempts that didn’t work out before…

58.241.255.38 - - [13/Nov/2008:21:29:48 +0100] “GET /xmlrpc.php HTTP/1.1″ 200 42 “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”
58.241.255.38 - - [13/Nov/2008:21:29:50 +0100] “POST /xmlrpc.php HTTP/1.1″ 200 473 “-” “Mozilla/4.0 (k1b compatible; rss 6.0; Windows Sot 5.1 Security Kol)”

The host 58.241.255.38 is located in China and looks like a compromised machine nobody bothers to fix:
http://www.google.com/search?q=58.241.255.38

route:        58.240.0.0/15
origin:       AS4837
descr:        CHINA169-BACKBONE CNCGROUP China169 Backbone
lastupd-frst: 2008-05-19 12:06Z  202.249.2.169@rrc06
lastupd-last: 2008-11-13 13:38Z  193.232.244.111@rrc13
seen-at:      rrc00,rrc01,rrc03,rrc04,rrc05,rrc06,rrc07,rrc10,rrc11,rrc12,rrc13,
              rrc14,rrc15,rrc16
num-rispeers: 113
source:       RISWHOIS

The script itself, as indicated by its user agent and modus operandi, has been seen for a while at different occasions:
http://www.google.com/search?q=k1b+compatible%3B+rss+6.0%3B+Windows+Sot+5.1+Security+Kol

Blocking the user agent via SetEnvIf/Rewrite rules should already take care of the problem. Additionally firewalling or denying access for this unmaintained machine may be a good idea, too.

Five weeks ago I changed my email address for MySpace and that should usually do to stop receiving emails on the previous address. To make matters more complicated, my preference is to receive notifications but not MySpace’s newsletter and one would think that should prevent the reception of promo blasts. Well, not quite, it seems ;-).

I was more than astonished not only to receive a newsletter I did not ask for today, but also one that was sent my old email address. Oddly enough, I did not receive another copy at my currently used email address, just at the old one. Things happen, and sometimes it helps to utilise the unsubscribe link. Unfortunately their implementation of opt-out does not involve removing an email address but providing a link to one’s profile preferences, which of course ensures the problem will persist. Newsletters are bulk email and each copy that reaches an inbox that did not subscribe to it is unsolicited. That makes their misdirected newsletters spam. Therefore, I flagged this message as spam in my affected Gmail account and wrote to their support stuff making them aware of the issue. Not that I expected any reaction, other than some boilerplate responses that do not fit to the actual situation, but at least future mailings will be dealt with appropriately by Gmail’s junk filters.

In any case, the outcome will have the final say as to whether I will continue using their services in the future. It does not lack some irony that a company which tries to position itself as “anti spam” fails at trivial things like mailing list management. So far, I’ve never encountered a mailing list that continued to deliver to an old email address, but then again there is always a first time…

Last night someone (ab)using a cable connection in Quebec left a long trail of entries in my weblogs, because the harvester’s link extraction mechanism was broken and resulted in lots of erraneous requests. The user agents were variants of IE explorer strings, some of them apparently truncated (maybe they exceeded the maximum allowed length in the spamware) and thus easy to distinguish from genuine visitors. François had encountered these visits before me, as you can read in this forum thread.

Here is a sample from my weblogs to give an idea about how these requests look like:

24.200.17.2 - - [23/Jan/2008:03:08:35 +0100]
"GET / HTTP/1.1" 200 6547 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"
24.200.17.2 - - [23/Jan/2008:03:08:37 +0100]
"GET / HTTP/1.1" 200 37342 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET"
24.200.17.2 - - [23/Jan/2008:03:08:39 +0100]
"GET /category/misc/ HTTP/1.1" 200 12797 "-"
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1"
24.200.17.2 - - [23/Jan/2008:03:08:40 +0100]
"GET /feed/ HTTP/1.1" 200 33547 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET"
24.200.17.2 - - [23/Jan/2008:03:08:42 +0100]
"GET /2007/12/ HTTP/1.1" 200 36766 "-"
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

Note the randomly changing user agent. Whois reveals the following about 24.200.17.2 (modemcable002.17-200-24.mc.videotron.ca):

CustName:   Videotron Ltee
Address:    300 Viger Est
City:       Montreal
StateProv:  QC
PostalCode: H2X-3W4
Country:    CA
RegDate:    2006-06-28
Updated:    2006-06-28

NetRange:   24.200.17.0 - 24.200.17.255
CIDR:       24.200.17.0/24
NetName:    VL-D-MM-18C81100
NetHandle:  NET-24-200-17-0-1
Parent:     NET-24-200-0-0-1
NetType:    Reassigned
Comment:
RegDate:    2006-06-28
Updated:    2006-06-28

I am not certain about the origin, though: It is possible that these requests came from the actual spammer. But this might as well be some zombified Windows machine on autopilot, which is now part of a botnet and serves as socks proxy to those who have good reasons to conceal their identity. Neither the ip addresses in François’ weblog nor that one here return any search results in Google, as one would expect from known sources of abuse. Often this signalises an individual or outfit that utilises a botnet with “fresh” proxies. Sometimes this is automatically done by malware which includes a scan and spam engine as payload.

As a workaround, I added the following SetEnvIf rule to my list of fake IE user agents:

SetEnvIfNoCase User-Agent "\.NET( CLR( [0-9.]{1,9})?)?$" block

The spamware’s broken link extraction is good for another rule:

SetEnvIfNoCase Request_Uri "//|%20title=%22" block

The “//” check within Request Uris also eliminates a lot of probes for vulnerable scripts that originate from compromised servers. In case you are worried about any http requests being blocked as result of the rule, rest assured that the protocol string http:// is not part of the Request Uri environmental variable.

Not all email addresses can be concealed from visitors passing by on our site. Ideally a webmaster should be reachable with a visibly attached email address so he/she can be notified of potential problems, ranging from spam to legal issues such as copyright infringement. By the time an email address is exposed on an easily accessable site, however, it is prone to being spidered by spambots and will inevitably lead to the webmaster being delighted with unsolicited pi11s, p0ker and pr0n offers. User Agent or Ip based filtering does not entirely solve the problem, because a User Agent can be easily forged so it will look like an average browser and if the spammer uses his home connection for data gathering there’s no way to tell him/her from legitimate visitors. In a situation like this, disposable email addresses that forward messages to one’s actual accounts come in pretty handy, as they can be deleted and replaced by a new one, once the spam threshold has surpassed the webmaster’s patience level.

On of these services is Spambob: Spambob comes in three flavours to satisfy one’s particular needs:

spambob.org addresses like example@spambob.org can be arbitrarily specified without registration, any mail for this address will be immediately deleted on the server, thus they are only useful for processes that do not require a confirmation.

spambob.com addresses like example@spambob.com can be arbitrarily specified without registration, too, but messages for an address are kept for at least seven days on the server. There is a query mask allowing you to review incoming messages for the account in use. Note that these addresses are not suitable for private or confidential messages as they can be viewed and fetched by anyone.

spambob.net addresses like example@spambob.net work exactly like casual forwarders: You specify the account name and an email address where your messages will be forwarded to, receive a confirmation mail to that address and once confirmed the address will be ready to go. Contrary to the previous addresses these ones do ensure privacy and can only be viewed by the actual user, so they are ideal whenever addresses have to be exposed in public but inquiries have to be kept confidential. Once an account gets flooded with spam it can be deactivated by going to the Spambob site and following the same procedure as during the registration, with the difference that “Deactivate forwarding” has to be selected as option.

There is no limit regarding the number of accounts to be created, so you can use multiple accounts for each website, pretty handsome for analysis of the spam’s origin. And the best of all, the service is entirely free. I have been using this service for quite a long time now and have been happy with it so far, because it keeps my actual email addresses safe from harvesters.

Update: It appears that some time around March the service gave up its ghost and went away to meet its maker, as since then the servers have no longer been reachable. So those who still had redirectors in use may found themselves in the inconvenient situation that all the mail that was supposed to reach the inbox is now lost in Nirvana.

Yeah, California demise has got me: As reaction to my Attributor article, there was a lot of activity on my server. Not only by employees of that company, but also by some twit in the San Francisco area, who thought probing my POP3 server for accounts would be a terribly good idea. I am not clear about the motive though: Was it just some spammer in need for fresh addresses? Or was it rather somone with an axe to grind, who hoped I would use easy to guess email accounts with rather silly passwords?

first a part of the pop3 log as evidence:

Jan  6 12:47:30 my.pop3.server in.qpopper[26407]: Possible probe of
account access from host 207.213.142.74 (207.213.142.74) [pop_quit.c:29]
Jan  6 12:47:36 my.pop3.server in.qpopper[26412]: Possible probe of
account accounts from host 207.213.142.74 (207.213.142.74)
[pop_quit.c:29] Jan  6 12:47:39 my.pop3.server in.qpopper[26417]:
Possible probe of account adm from host 207.213.142.74 (207.213.142.74)
[pop_quit.c:29] Jan  6 12:47:44 my.pop3.server in.qpopper[26415]:
Possible probe of account account from host 207.213.142.74
(207.213.142.74) [pop_quit.c:29] Jan  6 12:47:49 my.pop3.server in.qpopper
[26430]: Possible probe of account admin from host 207.213.142.74
(207.213.142.74) [pop_quit.c:29] Jan  6 12:47:51 my.pop3.server in.qpopper
[26432]: Possible probe of account temp from host 207.213.142.74
(207.213.142.74) [pop_quit.c:29] Jan  6 12:47:58 my.pop3.server in.qpopper
[26441]: Possible probe of account admin2 from host 207.213.142.74
(207.213.142.74) [pop_quit.c:29] Jan  6 12:48:02 my.pop3.server in.qpopper
[26439]: Possible probe of account test from host 207.213.142.74
(207.213.142.74) [pop_quit.c:29] Jan  6 12:48:04 my.pop3.server in.qpopper
[26453]: Possible probe of account test2 from host 207.213.142.74
(207.213.142.74) [pop_quit.c:29] Jan  6 12:48:07 my.pop3.server in.qpopper
[26459]: Possible probe of account test3 from host 207.213.142.74
(207.213.142.74) [pop_quit.c:29] Jan  6 12:48:09 my.pop3.server in.qpopper
[26461]: Possible probe of account web from host 207.213.142.74
(207.213.142.74) [pop_quit.c:29] Jan  6 12:48:16 my.pop3.server in.qpopper
[26471]: Possible probe of account web2 from host 207.213.142.74
(207.213.142.74) [pop_quit.c:29] Jan  6 12:48:16 my.pop3.server in.qpopper
[26473]: Possible probe of account test1 from host 207.213.142.74
(207.213.142.74) [pop_quit.c:29] Jan  6 12:48:24 my.pop3.server in.qpopper
[26486]: Possible probe of account webmaster from host 207.213.142.74
(207.213.142.74) [pop_quit.c:29] Jan  6 12:48:25 my.pop3.server in.qpopper
[26476]: Possible probe of account web1 from host 207.213.142.74
(207.213.142.74) [pop_quit.c:29] Jan  6 12:48:30 my.pop3.server in.qpopper
[26484]: Possible probe of account webadmin from host 207.213.142.74
(207.213.142.74) [pop_quit.c:29] Jan  6 12:49:57 my.pop3.server in.qpopper
[26590]: Possible probe of account webmaster from host 207.213.142.74
(207.213.142.74) [pop_quit.c:29] Jan  6 12:54:19 my.pop3.server in.qpopper
[...]

In case you have been wondering what kind of email addresses are not really a brilliant idea to use, you have more or less an answer now :-). Contrary to an SMTP server, the POP3 server will, independent from the existence of an account, keep complaining about an invalid password. Therefore any probe here is not really suitable for collecting spammable email addresses. But maybe the focus was on getting one’s hands on emails that were meant for someone else? I leave that interpretation to those who received my complaint about 207.213.142.74, the company responsible for the network:

CustName:   IS West
Address:    268 Bush St.
Address:    Suite 5000
City:       San Francisco
StateProv:  CA
PostalCode: 94104
Country:    US
RegDate:    2002-03-26
Updated:    2004-11-05

NetRange:   207.213.142.0 - 207.213.143.255
CIDR:       207.213.142.0/23
NetName:    SBC207213142000020325
NetHandle:  NET-207-213-142-0-1
Parent:     NET-207-212-0-0-1
NetType:    Reassigned
Comment:
RegDate:    2002-03-26
Updated:    2004-11-05

When I checked for 207.213.142.74 for any occurances in anti-spam blocklists, it turned out to be unknown to them. There were no new connection attempts since that probe, but to be on the safe side this range rests in my iptables ruleset for now.

Due to a leak in my defences a spammer was able to plug a spam comment on my netlabel site. Nothing serious: as each new comment by a stranger requires moderation, the spam will not see the light of day anyway. I have already been wondering that it took so long, maybe my choice of troublesome hosting companies for the firewall was quite effective. Of course you can do little about hand crafted spams or bots harboured by smaller hosting companies. Let us not forget that firewalling has to be done carefully in order not to lock out valuable bots or legitimate corporate visitors. But in this case, to get back to the comment spammer, the hosting company was safe fodder for the filters:

At first there was a request for a particular article by a bot with a blank referrer from 65.23.153.40:
Arin lists this as the following:

OrgName:    Datarealm Internet Services, Inc.
OrgID:      DIS-91
Address:    PO Box 1616
City:       Hudson
StateProv:  WI
PostalCode: 54016
Country:    US

NetRange:   65.23.128.0 - 65.23.159.255
CIDR:       65.23.128.0/19
NetName:    SERVE-BLK-1
NetHandle:  NET-65-23-128-0-1
Parent:     NET-65-0-0-0-0
NetType:    Direct Allocation
NameServer: NS1.SERVE.COM
NameServer: NS2.SERVE.COM
Comment:
RegDate:    2003-03-14
Updated:    2004-07-29

The netname is a sure sign of a hosting company and that means that the entire AS will wind up in my filter rules except for port 25. Why that? There is no reason for a server to visit my pages, however the server may well be used for sending legitimate email. So unless I came across a spam hydrant, I prefer to leave that communication channel open. Anyway, after this initial data fetch, just a mere five seconds later, someone from the home cable address 24.40.134.7 and using the same blank user agent tried to post his spam comment to my blog. This cable block belongs to:

CustName:   EARTHLINK, INC
Address:    1375 PEACHTREE STREET, LEVEL A
City:       ATLANTA
StateProv:  GA
PostalCode: 30309
Country:    US
RegDate:    2005-10-10
Updated:    2005-10-10

NetRange:   24.40.128.0 - 24.40.143.255
CIDR:       24.40.128.0/20
NetName:    ERLK-TW-RALEIGH12
NetHandle:  NET-24-40-128-0-2
Parent:     NET-24-40-128-0-1
NetType:    Reassigned
Comment:
RegDate:    2005-10-10
Updated:    2005-10-10

That’s a rather small segment with 4096 addresses, so it is safe to assume that customers in Atlanta/Georgia are served from this pool. Clear evidence? Not so fast… If I search for the ip address 24.40.134.7 in Google combined with the term “proxy”, several sites are returned who list this address as open socks proxy listening on non standard ports for a couple of months(!) already. Usually socks proxies on kinky ports are utilised for botnet spamming, thus the odds are quite high this could be a compromised Windows machine. This assertion would also be supported by the spam which was pointing to Eastern European resources. Perhaps it still was the server itself which first collects data and uses a proxy shield for planting spams only, so the activity will not violate the hosting company’s Terms of Services.