I just read about a new issue with WordPress here at SecurityFocus. It’s a potential credential stealing vulnerability, so I quickly created these ModSecurity 2 rules:
SecDefaultAction “log,deny,status:403,phase:2,t:lowercase,t:escapeSeqDecode”
SecRule REQUEST_FILENAME “/wp-login.php$” “chain,msg:’WORDPRESS wp-login.php redirect_to credentials stealing attempt’,severity:2,t:normalisePath”
SecRule ARGS_NAMES “^redirect_to$” “chain”
SecRule ARGS:redirect_to “(ht|f)tps?://”
I can still login to my WordPress install, so it seems that the rule does no harm. Use at your own risk!
Update: I’ve created a Snort rule as well:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”WORDPRESS wp-login.php redirect_to credentials stealing attempt”; flow:to_server,established; uricontent:”/wp-login.php”; nocase; uricontent:”redirect_to”; pcre:”/redirect_to=(ht|f)tps?://iU”; classtype:web-application-attack; sid:4000003; rev:1;)
Update 2: fixed the Snort rule, thanks to Shirkdog for pointing out that it had some broken pcre in it. The rule is now included in the BleedingThreats ruleset (check here), however that (slightly modified) rule doesn’t detect the attack for me.
Update 3: the Bleeding rule is now fixed. I’ve updated the above rule as well.
Update 4: updated the ModSecurity rule to prevent a possible evasion by prepending tab chars to the redirect url. Thanks to Ryan Barnett for pointing this out.
Inliniac 
Bing gets caugth:
–e0640000-A–
[20/Aug/2011:13:17:30 +0200] Tk@XysCoAQIAAD*********t 65.52.110.86 57108 ***.***.***.*** 80
–e0640000-B–
GET /blog/wp-login.php?redirect_to=https://****************/blog/?page_id=81 HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Accept: */*
Accept-Encoding: gzip, deflate
From: bingbot(at)microsoft.com
Host: ****************
User-Agent: Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)
–e0640000-F–
HTTP/1.1 403 Forbidden
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 189
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
–e0640000-E–
–e0640000-H–
Message: Access denied with code 403 (phase 2). [file “conf/extra/sec2rules/activated_rules/modsecurity_crs_46_slr_et_wordpress_attacks.conf”] [line “65”] [id “2003508”] [rev “6”] [msg “SLR: ET WEB_SPECIFIC_APPS WordPress wp-login.php redirect_to credentials stealing attempt”] [data “”] [severity “CRITICAL”] [tag “web-application-attack”] [tag “url,www.inliniac.net/blog/?p=71”]
Action: Intercepted (phase 2)
Apache-Handler: application/x-httpd-php
Stopwatch: 1313839050162641 15624 (- – -)
Stopwatch2: 1313839050162641 15624; combined=15624, p1=0, p2=15624, p3=0, p4=0, p5=0, sr=0, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.6.1 (http://www.modsecurity.org/); core ruleset/2.2.2.
Server: Apache
I believe this rules generates many false positives with the newer versions on WordPress as the redirection is now a normal part of the admin login process.
Should this rule be updated or removed in your opinion?
It’s a very old issue, so I think it’s safe to disable the rule. If your WP install still isn’t patched, you have bigger problems 🙂