AppSec Blog

Anatomy of a Form Spam Run

At the Internet Storm Center, we feature a poll on our home page. As part of the poll, you will find a comment field. Sadly, this comment field is frequently abused for spam. Not that it does any good. The spam is easily filtered and all comments have to be approved anyway. But just today, we had a large number of hosts trying to post spam at a rate of several posts a minute. The timing suggests that all these hosts are part of a single bot net. The "attack" is ongoing as I type this.

Here is a captured full sample request (note that the upper case header names are an artifact of the collection)

POST /poll.html HTTP/1.1
HOST: isc.sans.org
ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
REFERER: http://isc.sans.org/
USER-AGENT: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
COOKIE: dshield=a56291441771f2d3d948a383fe774889e2d2f018
COOKIE2: $Version="1"
VIA: 1.1 hebergement.gratisim.fr
CONNECTION: Keep-Alive
Post Data:
token:
poll: 1
poll_comment: qYAV4f <a href="http://vjrimatpckvt.com/">vjrimatpckvt</a>, [url=http://zdzyzolzspzd.com/]zdzyzolzspzd[/url], [link=http://zloyarufkbun.com/]zloyarufkbun[/link], http://mlsorofkvzxa.com/
subject: NBxnTAriuXTkDjGJ

There are a couple of odd and interesting attributes to this request:

  • The "ACCEPT" header looks very real. Many scripts and bot do not spoof it that well
  • The request uses a correct "Referer" header.
  • The User-Agent looks real too, but a bit "short". A windows XP host without .Net and anything else?
  • The cookie is in particular interesting. A different session cookie is used for each request. But oddly, the (local) Google Analytics cookies are missing.
  • Not sure what the Cookie2 is supposed to do... Maybe identifying the bot?
  • the "Via:" header is only present in some of the requests, and probably incidental. Some of the infected systems appear to be housed behind a proxy server.

Finally, the content: The domains "advertised" do not appear to be exist. This may be a trial to figure out if these URLs are posted to the site or not. Note that the attack uses 4 different link styles:

  • Standard HTML Link <a href="x">x</a>
  • BBCode [url link
  • BBCode [link link
  • "naked" URL

Given that these URLs don't exist (and they change from request to request), I think this is just a test run.

If anybody knows what the Cookie2 header is supposed to do... please comment below or let me know directly.

8 Comments

Posted February 3, 2010 at 3:54 PM | Permalink | Reply

Ben

From http://www.ietf.org/rfc/rfc2965.txt
Looks to me like they want to know what kinds of cookies the server supports. Info gathering definatly

Posted February 3, 2010 at 5:49 PM | Permalink | Reply

Al Thiel

I see this type of attack all the time on websites that do not protect the comment forms well. One of them is a hospital I work for managing the AIX servers and Cisco routers/switches. I built the server but I do not manage the website. I do support it periodically with custom code when they ask me to help out.
About the attack..
Eventually some real words like Vicodin will show up once the perp has a good feel for the form he is hitting. I believe it is a filtering test after they crack the image algorithms.
The attack is automated as you assume, and in my experience is coming from a few select hosts that can push out high volumes of data from Romania and China, at least to here. They appear to be motivated to do this. It is not a BOT. Once they crack your codes to post they will sell it to the highest bidder. At some point a human intervention is made where they help "train" the attack.
-Al

Posted February 3, 2010 at 7:47 PM | Permalink | Reply

Jeff Singleton

Looks like Cookie2 comes from http://www.ietf.org/rfc/rfc2965.txt.
The Cookie2 request header facilitates interoperability between clients and servers that understand different versions of the cookie specification. When the client sends one or more cookies to an origin server, if at least one of those cookies contains a $Version attribute whose value is different from the version that the client understands, then the client MUST also send a Cookie2 request header, the syntax for which is:
cookie2 = "Cookie2:" cookie-version

Posted February 3, 2010 at 7:51 PM | Permalink | Reply

dr strangep0rk

set-cookie2
http://rfc-ref.org/RFC-TEXTS/2965/kw-set-cookie2.html
May help

Posted February 3, 2010 at 7:54 PM | Permalink | Reply

dd

The cookie2 is part of the specification''
http://www.ietf.org/rfc/rfc2965.txt
" The Cookie2 request header facilitates interoperation between clients and servers that understand different versions of the cookie specification. When the client sends one or more cookies to an origin server, if at least one of those cookies contains a $Version attribute whose value is
different from the version that the client understands, then the client MUST also send a Cookie2 request header, the syntax for which..
"

Posted February 3, 2010 at 7:57 PM | Permalink | Reply

dd

Aha, the cookie2 option used to be set by default by the LWP (Perl WWW library).. So they are probably using an old version of the library and didn' t bother to modify that.

Posted February 3, 2010 at 9:26 PM | Permalink | Reply

David Walpitscheker

COOKIE2: $Version="1''
http://www.ietf.org/rfc/rfc2965.txt
Cookie2: $Version="1''
The Cookie2 header advises the server that the user agent understands new-style cookies. If the server understands new-style cookies, as well, it SHOULD continue the stateful session by sending a Set-Cookie2 response header, rather than Set-Cookie. A server that does not understand new-style cookies will simply ignore the Cookie2 request header.

Posted February 4, 2010 at 3:57 PM | Permalink | Reply

Shane

This looks exactly like some that have b een stoppedc by our WAF. ModSecurity auditlog below (some obfuscation so it can be published).
''"6203f52a-A''"
[03/Feb/2010:09:29:07 ''"0700] t66Ssn8AAAEAAHXreZMAAAAC 119.161.157.158 31561 172.31.251.32 80
''"6203f52a-B''"
POST /transportation/_vti_bin/shtml.dll/Comments.htm HTTP/1.1
Host: http://www.xxxxx.org
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://www.xxxxx.org/transportation/Comments.htm
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Content-Type: application/x-www-form-urlencoded
Max-Forwards: 10
Connection: close
Content-Length: 366
''"6203f52a-C''"
VTI-GROUP=0&Name=tmudwkjh&Email=frqspb%40rgtvfe.com&City=&Comments=Qj4CNy++%3Ca+href%3D%22http%3A%2F%2Fwmvkhzcxtkkf.com%2F%22%3Ewmvkhzcxtkkf%3C%2Fa%3E%2C+%5Burl%3Dhttp%3A%2F%2Fxpupytznnata.com%2F%5Dxpupytznnata%5B%2Furl%5D%2C+%5Blink%3Dhttp%3A%2F%2Fegyriocavgee.com%2F%5Degyriocavgee%5B%2Flink%5D%2C+http%3A%2F%2Flprosgnfhbga.com%2F&verify=2&submit=Send+Email&reset=
''"6203f52a-F''"
HTTP/1.1 500 Internal Server Error
Content-Length: 538
Connection: close
Content-Type: text/html; charset=iso-8859-1
''"6203f52a-H''"
Message: Access denied with code 500 (phase 2). Pattern match "\\

Post a Comment - Cancel Reply






Captcha


* Indicates a required field.