Securiteam reports of a vulnerability in WordPress’ cookie authentication. Through this vulnerability, an attacker can generate a valid login cookie for any user account without using a brute force attack (assuming that the attacker can gain at least read-only access to the WordPress database). When a cookie is generated, an attacker can perform limited SQL injection and be granted administrator access to that WordPress installation.

(Structured Query Language (SQL) injection is a technique used by hackers to execute destructive and admin-only SQL statements. Read more here.)

When a WordPress user (of any level) logs in, the WordPress system queries the database for the user name and password for authentication. If the credentials are OK, the system generates two cookies and save them in the user’s cookie cache. One of the cookies contain the user’s password encoded using double MD5 hash.

* Why save a cookie? A cookie allows a user to gain access to any WordPress administrative pages without signing in each time.
* MD5 is a cryptographic hash function used to protect passwords. When a new user registers with a WordPress-powered site, his password is encoded using MD5 and is saved in that form in the database.

Now, where is the problem? WordPress stores the password in the cookie in the MD5(MD5(password)) format. What does it mean? The password saved in the cookie is actually a password in the clear, which means that you can actually know what the password is using MD5!

What the hacker now needs is to gain access to a WordPress database. A hacker can do this by looking for a database backup that anyone can view, or looking for a WordPress installation that is vulnerable to SQL injection. When that happens, a hacker can gain administrative access.

Securiteam has listed several workarounds:

– Protect the WordPress database, and do not allow backups to be released.
– Keep your WordPress installation up to date. This should reduce the risk that your database will be compromised.
– Do not share passwords across different sites.
– If you suspect a database to be compromised, change all passwords to different ones. It is not adequate to change the passwords to the same ones, since WordPress does not “salt” the password database.
– Remove write permissions on the WordPress files for the system account that the webserver runs as. This will disable the theme editor, but make it more difficult to escalate WordPress administrator access into the capability to execute arbitrary code
– Configure the webserver to not execute files in any directory writable by the webserver system account (e.g. the upload directory).