Hardening in WordPress II

Wordpress in Paranoid Mode (Part 2)

02.11.2016

WHITEPAPEr_

elevenpaths.com

Chema Alonso ([email protected]) Pablo González ([email protected])

2016 © Telefónica Digital España, S.L.U. Todos los derechos reservados.

WHITEPAPER_ Wordpress in Paranoid Mode (Part 2)

Página 2 de 14

Índex 1. Threats against confidentiality, integrity and availability ....................................................................................................... 3

2. Network Packet Manipulation ..................................................................................................................................................... 4 2.1. MySQL traffic observation ................................................................................................................................................... 4 2.2. Hacking Wordpress with Network Packet Manipulation ................................................................................................. 6

3. The problem: The connection string .......................................................................................................................................... 8 3.1. Hardening of communication through encryption .......................................................................................................... 8 3.2. Dividing the connection strings for logged and non-logged users ............................................................................... 11

3.2.1. Configuring Wordpress ....................................................................................................................................... 12

About ElevenPaths ......................................................................................................................................................................... 14

More information ............................................................................................................................................................................ 14



Página 3 de 14

Executive Summary It is said that one in four Internet sites are Wordpress. This CMS has a great importance on the Internet. The protective and security measures offered by Wordpress are not enough to provide an acceptable security status to its users. This article describes two fundamental components for the protection of identity, availability and integrity of the assets of an organization/user using Wordpress. In a business environment there are internal and external threats. Some of them may be the classic SQL Injection and manipulation of packages at network level. These may involve the loss of control at confidentiality integrity and availability levels of the database of the Wordpress application.

1. Threats against confidentiality, integrity and availability When Wordpress users install the CMS (Content Management System) they face a complex scenario as security is concerned. There are many threats that can affect the integrity, availability and confidentiality of data. These three aspects are the information security dimensions that must be ensured by any protection mechanism, in any environment.

Installing Wordpress plugins is a normal activity for millions of users. These plugins provide flexibility to the platform, allowing final users to adapt its functionality to their needs, either directly developing them and inserting them so they can be executed with the CMS environment, or downloading plugins developed by third parties. These plugins are the object of the same threats as other SW parts. A poor maintenance policy, delays in updates or vulnerabilities associated with plugins may lead to a situation of insecurity for the user’s assets. One case that has been the most noted in the history of Wordpress and its plugins is the appearance or detection of SQL Injection vulnerabilities, with which an attacker could take over the CMS. This threat is generally externally exploited by attackers.

Another classic threat is the observation and manipulation of traffic between machines. Usually, these are known as Man in the Middle attacks. In a business environment it is very common to configure Web applications in certain machines, while the database be hosted in others. In many organizations, security measures on internal networks are loosened up because of the trust that relies on perimeter security. On many occasions, it has been proven that the greatest attacks against company assets were from within, taking advantage of a false sense of security.

Attacks such as the manipulation of packages through Man in the Middle techniques, like for example, ARP Spoofing in an organization’s IPv4 network data can end up being the trigger for information theft from the database. By default, database engines like MySQL or SQL Server do not configure their connections through secure protocols, and data between the web application and the database engine are, by default, unencrypted. This attack, in which any user can stand in the middle of the communication and manipulate the queries that the web application sends to the database engine, is called Network Packet Manipulation.



Página 4 de 14

2. Network Packet Manipulation The prerequisite for carrying out the manipulation is, necessarily, that traffic flows through the network card of the attacker. At the time that traffic “goes through” the network card of the attacker, they can manipulate all the traffic circulating in plaintext, that is, unencrypted.

In the case of the CMS Wordpress, in most installations a MySQL database engine is used, although it can also be configured, for example, in SQL Server. If traffic is observed, database queries can be easily distinguished. Queries to the database can even be directly read and modified with the appropriate means to do so.

2.1. MySQL traffic observation

If we carry out a Man in the Middle attack, regardless of the technique used for it, we can see the traffic at MySQL client level. In the next image, we can easily visualize how the query is in plain text, so if an attacker has access to this information, they can also modify the packet directly.

Figure 1: MySQL Query in plain text

To modify the package there are tools that allow to carry out this process on the fly. The following is an example of a filter algorithm in pseudocode, which detects when there is a request to MySQL database and modifies the Select query to a new query.

If tcp port is 3306 And package contains “Select” Then

Replace “Select” by “Select * from stolen;#”

End If

The image below shows an example of code in this filter. The tool is called Etterfilter, and belongs to the Ettercap suite.



Página 5 de 14

Figure 2: Filter implemented to modify queries to tables

When the attacker is in the middle of the communication, for example, by using the Ettercap tool itself, the filter begins to act if it intercepts a package that meets the implemented conditions. The image below shows the execution of Ettercap with the aforementioned filter.

Figure 3: Execution of Ettercap with ARP Spoofing and modification of packages

The user making the query may have two situations:

• Before the attacker is in the middle of communication, the reply of the engine database is as expected, that is, legitimate.

• When the attacker is in the middle of communication, the database engine does not receive the legitimate query. What it gets is the query modified by the attacker.



Página 6 de 14

This fact is reflected in the image below, where we can see to the right the “select * from cookie;” query and the reply expected by the client. On the left we can see the “select * from cookie;” query and the does not seem to correspond with the expected table. The filter changed the query so that it was sent to the stolen table instead of to the cookie table, and this is what has been dumped.

Figure 4: Results of modified and unmodified queries

2.2. Hacking Wordpress with Network Packet Manipulation

The default configuration of Wordpress provides in the same machine both the MySQL database server and the Wordpress web application, but in business environments this is reversed. The most logical thing is that web applications and database engines are not configured in the same machines.

The image below shows a possible business environment where internal users can be placed in the middle of communication.

Figure 5: Potential scenario in a business environment



Página 7 de 14

Using the Network Packet Manipulation technique, an attacker can be in the middle of the communication and use a filter that allows to create a user in Wordpress or to modify user passwords to take over the CMS. As mentioned above, in a scenario of internal audit we can find this type of scenario, so it is not far-fetched.

By default, as in the Manipulaton Packet Network example above, requests between Wordpress and the database are not encrypted, therefore queries can be observed and manipulated.

Figure 6: Request of Wordpress to MySQL in plain text

Once a Wordpress query to the database engine is detected, a filter can be created to carry out the aforementioned actions, that is, modifying user passwords or creating a user with admin role.

The first example shows a modification of a SELECT statement by the command UPDATE wp_users SET user_pass = <hash>. This filter changes the password for all users of the wp_users table, which is where Wordpress stores the usernames and passwords.

Figure 7: Filter to modify Wordpress user passwords

MySQL has a field named Packet_Length. It is an important field as the number indicated here will be the number of bytes read the engine. That is, the statement will be executed until the number of bytes N that the engine reads is reached. That is one thing to keep in mind when modifying the package, that is why in the previous filter we can see the statement replace(“\x49\x00\x00","\X4A\x00\x00”). It is replacing the number of bytes of the original statement with the modified statement.

Figure 8: Updated password for all wp_users users



Página 8 de 14

3. The problem: The connection string The problem of SQL Injection or Network Packet Manipulation attacks can be solved. The connection string of a database is a sensitive element the processing of which should be properly securitized. In each database engine this processing must be adjusted to the specific characteristics of how these strings are managed and, in most cases, the level of protection that can be achieved is limited precisely because of these characteristics.

Wordpress has a connection string for all users that are created in the application. That means that no matter whether it is a root user or a normal user, their requests are made through the same connection string to the database. We must differentiate the users of the web application from the users of the database: the web application or Wordpress will have a number of users with different roles or permissions over the online resources offered by the platform, while the database will have its own users and an access control scheme that will determine which permissions are defined on the tables.

For example, the Wordpress web application can have N users, but they can all use the same connection string with the same database user in an N:1 relation that is fixed during the installation process. This is a security problem because the traffic of logged and non-logged users can be manipulated, like in the Network Packet Manipulation example. In other words, a user visiting a Wordpress website is generating a request to the database (located on another machine). During that request someone could use said request to create a Wordpress database user or to modify user passwords, as we have seen before in this article and depending on the permissions assigned to the database engine user data with which the connection string is defined. Unfortunately, Wordpress is configured by default with a high level of privileges.

Only by verifying the privileges assigned to the database user with which the connection string is constructed will it be possible to determine the type of access that can be made and, still, it will be impossible to determine who executes the statement in the database. Since the authorization scheme is different from the web application with regard to the database, we can determine whether a user has privileges or not.

3.1. Hardening of communication through encryption To carry out the hardening of communication through encryption in MySQL, the latter must accept connections under SSL. The compilation version must be compatible and support SSL and if it does not, we need to install a newer version or compile it with SSL support. To verify this from the MySQL client, we must execute “show variables like ‘% ssl%’;”.

If the values for variables have_openssl and have_ssl are:

• DISABLED, it means that SSL is supported, but not active.

• NO, it means that MySQL compilation does not support SSL.

• YES, it means that it is configured and the server and supports connection under this protection mechanism.

These variables indicate as follows:

• ssl_ca. Indicates the path of the CA.

• ssl_cert. Indicates the path of the server certificate.

• ssl_key. Indicates the path of the key to the certificate.



Página 9 de 14

Figure 9: MySQL variables for the configuration of SSL

Through the use of OpenSSL the CA, the certificate and the key are generated. The commands below must be followed in order to do so:

• openssl genrsa 2048 > ca-key.pem

• openssl req –sha1 –new –x509 –nodes –days 3600 –key ca-key.pem > ca-cert.pem

With these commands, the certificate and the CA private key are generated. Finally, the private key for the server is generated.

• openssl req –sha1 –newkey rsa:2048 -days 730 -nodes -keyout server-key.pem > server-req.pem

Then the server private key is exported to RSA with the execution of the following command:

• openssl rsa -in server-key.pem -out server-key.pem

Finally, a server certificate is generated using the CA certificate:

• openssl x509 -sha1 -req -in server-req.pem -days 730 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > server-cert.pem

The cacert.pem, server-cert.pem and server-key.pem files must be copied to the /etc/mysql path. Once these actions are configured, the service must be restarted.

To verify that the settings are correct, we can make a connection to the database engine, for example, wit the command mysql –u [user] –p –ssl-ca=[ruta cacert]. Now we can check the Ssl_Cipher MySQL variable, like shown in the image below, to verify that the connection is encrypted.

https://3.bp.blogspot.com/-iy8kIONwgiQ/Vvr0sy7gsLI/AAAAAAAAgv8/sWWcQrpI1-s0xkZ34aMKBDRQp4KlokxIw/s1600/2.PNG



Página 10 de 14

Figure 10: Connection Settings

From the point of view of an attacker, they can verify that the communication between the MySQL client and the server is encrypted by opening a tool like Wireshark. Wireshark takes the traffic directly as TCP, and not as MySQL, as it would be taken if it were not encrypted and they could interpret the traffic, because the tool knows the MySQL protocol.

Figure 11: Encrypted traffic between client and database server

At this point the database server can encrypt connections, but this will depend on the client. For this reason, Wordpress must be configured so that connections to the database server are made encrypted.

In the wp-config.php Wordpress file there are a number of flags. The user must add the flag “define(‘MYSQL_CLIENT_FLAGS’, MYSQL_CLIENT_SSL);”, as detailed in the image below.

Figure 12: Configuring WordPress

https://3.bp.blogspot.com/-L7QB-MSvneA/Vvr0tHSXA9I/AAAAAAAAgwU/LSrREZHKiqMnM2Izi5KUxEi0ir0e9dptA/s1600/4.PNG

https://2.bp.blogspot.com/-CwwgRefzokg/Vvr0tR4F7bI/AAAAAAAAgwU/qRbZ7Z_b-0oUuWfmQKMqYvofk8yl9M_tw/s1600/5.PNG

https://1.bp.blogspot.com/-V_P23ocmgbQ/Vvr0tXCMdeI/AAAAAAAAgwU/eAF9Fltdl1gO9YtqTMKHgFEChXgir6CtA/s1600/6.PNG



Página 11 de 14

At this time, the traffic generated by Wordpress to the database will be encrypted by SSL, and a potential attacker will not be able to manipulate or observe it.

3.2. Dividing the connection strings for logged and non-logged users

The string division aims to increase the granularity on the privileges associated with the connection to the database. Ideally, this division would consist in each Wordpress using their own string to connect to the MySQL database engine. Each connection string will have certain privileges on the database engine, so the Wordpress user administrator will have a connection string with greater privilege than another user.

As a first approach to the proposed model, we have carried out a proof of concept where privileges of user logged in Wordpress are separated from privileges of non-logged users. The following two diagrams simplify the concept.

Figure 13: Users not logged use connection string with minimum privilege

As you can see in the diagram, users not logged in the web application (Wordpress) are generating a series of queries to the database to obtain the text from the website, the comments posted on the website, etc. These requests are made through a user named WP_NP, which is defined in the wp-config.php Wordpress file, located in the MySQL database. This user only has a SELECT permission, and it is only defined in the necessary tables: wp_usermeta, wp_posts or wp_comments. There could be more tables, but always only with the SELECT permission. This way, the potential addition of a user and the modification of passwords or contents in the database are protected. The principles of minimum privilege and minimal exposure are met.

Figure 14: Logged users use connection string with default privilege in Wordpress

The second diagram displays the default configuration of Wordpress. That is, any logged user will use a connection string with greater privilege than non-logged users. This is an approximation to the ideal case discussed below, but we can see how the risk of an SQL Injection or a Network Packet Manipulation attack has been dramatically reduced, as if it is a user not logged, the victim cannot access or manipulate sensitive information from the database.



Página 12 de 14

3.2.1. Configuring Wordpress

To achieve this basic string division, two files must be modified in Wordpress:

• wp-config.php: This file has all the “flags” or defines that the application needs them.

• wp-load.php: This file is responsible for loading the configuration showed in wp-config.php and provides access functions to the database and how they will be carried out.

First, in wp-config.php we need to add the new users of the database, in this case wp_np. In Wordpress code it will be identified by the parameter DB_USER_NP.

Figure 15: Creating DB_USER_NP and DB_PASSWORD_NP

Then, we have to modify a function in the wp-load.php file. The function to be modified is require_wp_db().

In the require_wp_db() function we add the $logged variable, which will indicate if the user interacts with Wordpress, and if they will use the database, logged in or not. In other words, it is a boolean variable.

To find out if a user is logged or not, the $COOKIE variable is analyzed and a value called “worpdress_logged_in” is searched. If such value exists, that means that the user is logged in, and if it doesn’t, it means that the user is not logged in.

Figure 16: Modifying the require_wp_db() function



Página 13 de 14

When a non-logged user connects to Wordpress, their requests go through the connection string used by the wp_np user, which means that the exposure and risk to SQL Injection or Network Packet Manipulation attacks has been reduced.

The creation of users and the assignment of permissions in MySQL is carried out through the execution of the next command:

CREATE USER 'wp_np'@'IP' IDENTIFIED BY ‘pass’;

GRANT SELECT ON wordpress.wp_usermeta TO wp_np@'IP';

FLUSH PRIVILEGES;

Figure 17: Connecting with wp_np user to the database



Página 14 de 14

About ElevenPaths At ElevenPaths we believe in the idea of challenging the current state of security, a feature that should always be present in technology. We continually rethink the relationship between security and people with the aim of creating innovative products that are capable of transforming the concept of security, so we are always one step ahead of our attackers, who are increasingly present in our digital life.

More information www.elevenpaths.com

@ElevenPaths

blog.elevenpaths.com

2016 © Telefónica Digital España, S.L.U. All rights reserved.

The information disclosed in this document is the property of Telefónica Digital España, S.L.U. (“TDE”) and/or any other entity within Telefónica Group and/or its licensors. TDE and/or any Telefonica Group entity or TDE’S licensors reserve all patent, copyright and other proprietary rights to this document, including all design, manufacturing, reproduction, use and sales rights thereto, except to the extent said rights are expressly granted to others. The information in this document is subject to change at any time, without notice.

Neither the whole nor any part of the information contained herein may be copied, distributed, adapted or reproduced in any material form except with the prior written consent of TDE.

This document is intended only to assist the reader in the use of the product or service described in the document. In consideration of receipt of this document, the recipient agrees to use such information for its own use and not for other use.

TDE shall not be liable for any loss or damage arising out from the use of the any information in this document or any error or omission in such information or any incorrect use of the product or service. The use of the product or service described in this document are regulated in accordance with the terms and conditions accepted by the reader.

TDE and its trademarks (or any other trademarks owned by Telefonica Group) are registered service marks.

http://www.elevenpaths.com/

Technology

Hardening in WordPress II