foobert

To be totally fair, I posted on Mike’s support page, as he requested. I’ve captured a packet log of how the spammers are going about their deed.

This is the summary of how this 1 instance played out:

** Client 1 loads page. Client 1 is using a Canadian IP address.
** PHPSESSID is assigned for the session to Client 1.
** ~3 seconds later, Client 1 loads captcha image
** Client 1 made no other requests that would have been needed to properly render the page
** 12 seconds later, Client 2 (happened to have been an IP in Spain) comes in and directly makes an HTTP POST to /wp-comments-post.php with the same PHPSESSID that was given to Client 1 above. The POST contains a captcha code which I presume was correct (I couldn’t validate it due to not knowing what image was presented to client 1). The POST is successful and the comment is accepted.

I’ll leave it to folks to speculate as to how the captcha code is being derived. But, what I said about a distributed bot that was sharing session context appears to be exactly what is happening. There are some very clever bot herders out there.

I haven’t heard back from Mike yet, but, it hasn’t been very long either.

I have shared the packet trace with Mike.

I’m getting the same basic signature that Bradleyhu posted with lots of randomish gibbersh words. It all started about 24 hours ago.

I’ve poured through my server logs and every time the IP address comes in directly with a HTTP POST to wp-comments-post.php.

216.118.70.2 - - [17/Mar/2011:15:49:39 -0700] "POST /blog/wp-comments-post.php HTTP/1.1" 302 854 "https://www.foobert.com/blog/2009/09/09/oshkosh-trip-day-7?replytocom=5147" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

Of particular note is that they are getting code HTTP status 302, and not 200 as I’d expect.

They are not human posts since they are never accessing the page to fetch the captha image. Thus, unless it’s some massive distributed bot that’s sharing session context between clients (highly unlikely), there is a vulnerability in the si-captcha that is being exploited.

I’m getting hits at a rate of 1-2 times per hour, so, I may try to capture some packet traces to see if I can figure out what they are actually submitting.

Anyone interested in the packet log?

I agree with foolip about this being a “problem” that appears to only surface as the result of poorly implemented spambots. That being said, I’ve generally stopped worrying about it.

However, that doesn’t answer my principle question of the matter: Is passing the #anchor from the browser to the web server legal in the HTTP protocol or not? And if it is legal, then I think there is a bug in wordpress, even if it’s a mostly beneficial bug!

Of course, since I’m too lazy to even find the HTTP protocol spec to answer what amounts to a passing curiosity at this point in time, much less spend any time wading through it, I’m not the least bit surprised that no one else has bothered either ??

Cheers,
~foobert

Samboll — I should mention that I used /blog/#respond as an example to clarify what I meant by a “named anchor”. Although that anchor doesn’t exist in the main page, your second link is a perfectly valid case that DOES exist.

The point is: passing the named anchor to the webserver shouldn’t cause a 404.

Additional information — this is not an apache problem. If I do a test with a simple file.html page and pass bogus #anchors, apache doesn’t care and still serves the file up just fine. I think the problem is in how WP is attempting to decipher which post to fetch and it is including the #.* string in this process. Looking through xmlrpc.php, is what leads be to beleive this, but — I’ve got a lot to learn about PHP before I’d be able to begin debugging it.

You seamed to have a fairly recent version of firefox — which doesn’t pass the #respond to the webserver. Here’s you’re (I think) entry in apache’s access log:

70.136.64.147 - - [18/Oct/2006:14:02:23 -0700] "GET /blog/2006/10/16/mooney-homecoming/ HTTP/1.1" 200 4048 "https://foobert.ath.cx/blog/" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7"

I do not have a list of browsers/vesions that pass the #respond, but. Here’s an entry that got the 404:

203.28.159.168 - - [18/Oct/2006:09:18:31 -0700] "GET /blog/2006/09/02/blue-border-around-
mplayer-videos/#respond HTTP/1.1" 404 5337 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Window
s NT 5.1; SV1)"