Friday, November 21, 2014

Introduction

Wordpress is the CMS most used Worldwide. According to w3techs.com 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 www.devconsole.info 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

http://www.behindthefirewalls.com/2014/12/cve-2014-9016-and-cve-2014-9034-PoC.html

CVE Information

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

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9034

References


http://codeseekah.com/2012/04/29/timing-attacks-in-web-applications/

https://administratosphere.wordpress.com/2011/06/16/generating-passwords-using-crypt3/

http://www.breaksec.com/?p=6362


Posted on Friday, November 21, 2014 by Javier Nieto

No comments

Wednesday, November 19, 2014

Introduction

First of all, let me introduce you to my partner @cor3dump3d from www.devconsole.info We have written this post together and we hope you enjoy it. More technical information about this topic could be found at my partner post: http://www.devconsole.info/?p=1050

Before starting with our findings, we would like to thank @drupalsecurity team for their quick response and for their interest in keeping Drupal secure. It is the fastest and most efficient security team we have ever talked to... Around two hours after sending the vulnerability, we received the vulnerability confirmation and a patch was proposed...

As you already know, Drupal is an open source content management platform powering millions of websites and applications. It’s built, used, and supported by an active and diverse community of people around the world.

We believe in responsible disclosure, that is the reason why we have waited until a patch has been released by Drupal security team before revealing full details.

Drupal affected versions

Drupal core 7.x versions prior to 7.34
Secure Password Hashes 6.x-2.x versions prior to 6.x-2.1.

More info:

Vulnerability Details

We've been researching about the security in Drupal and we would like to share our results with you. We have discovered a vulnerability which can be used against default Drupal 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 Drupal 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 Drupal, the way of calculating the password hash (SHA512 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 Drupal 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

Install the latest version:

  • If you have configured a custom password.inc file for your site you need to make sure that it is not prone to the same vulnerability.

Drupal 7.34 version verifies that passwords longer than 512 bytes are not hashed

Proof of Concept

http://www.behindthefirewalls.com/2014/12/cve-2014-9016-and-cve-2014-9034-PoC.html

CVE information

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

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9016

Timeline

October 23, 2014 at 5:11am - We sent a complete report about the vulnerability  to Drupal.

October 23, 2014 at 6:43am - Drupal answered confirming the vulnerability and proposing a patch.

November 19, 2014 at 8:54pm - A Drupal security update and the security advisory is published.

December 01, 2014 16:05 - Proof of concept published

References


http://www.devconsole.info/?p=963

http://codeseekah.com/2012/04/29/timing-attacks-in-web-applications/

https://administratosphere.wordpress.com/2011/06/16/generating-passwords-using-crypt3/

http://www.breaksec.com/?p=6362


Posted on Wednesday, November 19, 2014 by Javier Nieto

2 comments