Wordpress version 2.6 & ModSecurity
Today I updated my Wordpress installation to version 2.6. The upgrade went smooth as usual. However afterwards I couldn’t login anymore because one of my ModSecurity rules was triggered at the login. Turns out the Wordpress developers changed the use of the ‘redirect_to’ argument in wp-login.php. Wordpress uses it to redirect the browser to some part of the weblog software after a successful login. Some time ago there used to be a vulnerability in Wordpress as described here: http://www.securityfocus.com/archive/1/463291. To prevent exploitation on my box at the time I created the following rule:
SecRule REQUEST_FILENAME “/wp-login.php” “chain,msg:‘WORDPRESS wp-login.php redirect_to credentials stealing attempt’,severity:2,t:normalisePath” SecRule ARGS:/^s*redirect_to$/ “^(ht|f)tps?://”
This worked because Wordpress only used relative paths as values for the ‘redirect_to’ argument. With 2.6 however, this has changed. Wordpress now tries to redirect to a full URI. So the above rule needed an update. What I wanted is to adapt the rule so that it only allows the redirect to my own domain. So I created the following rule:
SecRule REQUEST_FILENAME “/wp-login.php” “chain,msg:‘WORDPRESS wp-login.php redirect_to credentials stealing attempt’,severity:2,t:normalisePath” SecRule ARGS:/^s*redirect_to$/ “^(?:ht|f)tps?://(.*)$” “chain,capture” SecRule TX:1 “!@beginsWith %{SERVER_NAME}”
What it does is take the domain name from the ‘redirect_to’ variable and strip the leading http:// or https:// from it. Next, that is compared with Apache2’s SERVER_NAME variable. It is tested using ‘beginsWith’ so the rule can’t be bypassed using something like ‘redirect_to=http://evil.com/www.inliniac.net/’.
This way the logins work again and I still should be notified when someone tries this old (and patched) trick on me!