Wordpress is the CMS most used Worldwide. According to WordPress is used by 61.1% of all the websites whose content management system they know. This is 23.2% of all websites.

My partner @cor3dump3d from and me believe in responsible disclosure, that is the reason why we have waited until a patch has been released by Wordpress security team before revealing full details.

Notice that this security issue is exactly the same we talked about yesterday. Both of them, Drupal and Wordpress had the same security flaw which is now  solved in the latest versions.

Wordpress affected versions 

Wordpress versions prior to 4.0.1

More info:

Vulnerability Details

We've been researching about the security in Wordpress and we would like to share our results with you. We have discovered a vulnerability which can be used against default Wordpress installations in order to:

  • Guess usernames
  • Perform a Denial of Service

With the scenarios below, we will show you how this attack works. When we want to login to Wordpress site, we need to type a username and a password:

Scenario 1:
If the username doesn't exist, the password hash is not calculated because the username doesn't exist.

Scenario 2:
If the username exists, the password hash is calculated and compared with the hash stored in the database. If the hash compared is the same, you are granted access to the system. If not, you are rejected.

Scenario 3 - Taking advantage of the vulnerability:

User guessing
If the username exists and the password typed is for example 1000000 A's, the fact that when a hash of such a long password is generated in order to compare it with the hash stored in the database, it takes much longer and the time measurement is increased. So if the delay is increased, the username exists.

In Wordpress, the way of calculating the password hash (MD5 with a salt) by using phpass results in the cpu resources being affected when really long passwords are provided.

Denial of service
If we perform several login attempts by using a valid username at the same time with long passwords, that causes a Denial of Service in the server. We have observed two different scenarios in a Wordpress 7.32, Apache and MySQL default installation. Depending on how many login attempts and the time between them, we will have two different scenarios:

  • The DOS attack crashes the entire server because the RAM and swap is  reached. Also the CPU is reached.

  • The DOS attack crashes the database.

Notice the server doesn't crash because of the hash calculation. The vulnerability appears in conjunction with Apache, because Apache waits to PHP to finish the hash calculation. In a concurrent authentication process with a valid user and very long passwords, on the one hand PHP consumes the CPU with calculation processes and in the other hand, the Apache processes which are waiting, consumes the memory until the server or the database crashes.

If the apache configuration is optimized and tuned to the hardware resources, we are able to reach all sessions available quickly and handle them for 30 seconds which performs a DOS without crashing the server or database.

Why did we say 30 seconds?

30 seconds is the maximum time a script is allowed to run before it is terminated by the parser. By default, max_execution_time value is set to 30 in the php.ini config. This helps prevent poorly written scripts from tying up the server.

How to fix

If you don't have set the automatic updates in Wordpress do it or install the latest version.

In the latest version, Wordpress only calculates the hash for passwords < 4096 length.

Proof of Concept

CVE Information

CVE-2014-9034 has been assigned to this vulnerability.