hardening in wordpress i

Wordpress in Paranoid Mode (Part 1)

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 1)

Página 2 de 17

Índex 1. Threats against identity, confidentiality, integrity and availability ....................................................................................... 4

2. Fortification at user level with 2 Factor Authorization ............................................................................................................. 4 2.1. Installing the Latch Plugin for Wordpress .......................................................................................................................... 5 2.2. Pairing of the Latch Plugin for Wordpress ......................................................................................................................... 6 2.3. Verification after an attempt of phishing in Wordpress .................................................................................................. 7

3. Fortification at table level with 2 Factor Authorization ............................................................................................................ 7 3.1. Mode of action ....................................................................................................................................................................... 7 3.2. Affected tables ....................................................................................................................................................................... 8 3.3. WPM overall scheme .......................................................................................................................................................... 10 3.4. Triggers algorithm ............................................................................................................................................................... 11 3.5. Installation Process ............................................................................................................................................................. 13 3.6. Protecting Wordpress against malicious actions ........................................................................................................... 14

About ElevenPaths ......................................................................................................................................................................... 17

More information ............................................................................................................................................................................ 17



Página 3 de 17

Abstract 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. Protection of identity through a second factor authorization is essential. On the other hand, the protection of the availability and integrity of the data that are stored in the Wordpress database is essential. Both measures multiply the level of security provided to CMS.



Página 4 de 17

1. Threats against identity, 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 security dimensions that must be covered by any IT protection mechanism, in any environment. A proper management of identity by proposing robust and usable authentication mechanisms is essential to ensure these dimensions of data security. The authentication/authorization of a user allows Wordpress to determine whether it is a legitimate user and to determine which resources they have access to. Any threat to the identity management system is critical to the security status of any IT system.

The threats are, generally, on the Internet and may take the form of different types of attacks. The most common ones seek to compromise the authentication mechanisms, and this can be achieved in different ways:

• Theft of credentials in attacks to communications, for example, unsafe channels.

• Theft of credentials after the exploitation in one of the plugins installed in Wordpress, or vulnerabilities in the CMS itself.

• Theft of credentials after identity theft or deception through a phishing or spear phishing attack.

• Theft of credentials after attacks to a trojanized client computer.

The endangerment of the credentials associated with the identity of a user not only means that someone unauthorized can access to resources for which they have no authorization. Potentially, a derivative of this security breach is that critical information about the user or about the organization where users develop their work may be exposed in areas unknown to the victim.

The proliferation of services as “haveibeenpwned” or “hesidohackeado” can help with a constant digital surveillance to know when and in which security breach the identity is exposed. Logically, these services only provide information about attacks or major incidents, so in the case of an isolated attack or an attack against a specific person, it may not notice that their identity is exposed.

2. Fortification at user level with 2 Factor Authorization Authentication mechanisms must ensure that the user requesting access to a resource is a legitimate user. These mechanisms are designed to validate different authentication factors in a secure way. These authentication factors allow users to prove that they are who they claim to be. For this, there are different strategies to propose authentication factors. Authentication factors can be based on:

• Something the user knows. In other words, an access password and that it verifies that the user knows it.

• Something the user has. Possession of a mobile device or an RSA token allows the identity verification system to have an alternative channel where to contact the user. One of the most common uses is token generation or text messaging with a code via said channels, in order to allow the user to enter a second authentication step.

• Something the user is. Biometrics has burst into the security world, allowing a system to verify a biometric feature of a user. Again, it is a further step in the authentication.

• Something the user does. At the end of the day, all users interact in a timely way with information systems. This pattern helps defining an expected behavior that can be used as an authentication factor.



Página 5 de 17

Traditionally, it was considered that some factors were better than others, and the creation of increasingly complex passwords or increasingly invasive biometric systems was forced. However, in recent years it has been proven that it is more effective to reduce the probability of an attack being successful by using more than one authentication factor rather than using just a very robust one. Typically, the use of these additional authentication factors involves defining an extra channel through which protocols that ensure that their validation increase the reliability of the authentication process are defined. There are multiple ways to build these channels but, lately, the widespread use of mobile phones has forced the channels that exploit their use to be the most used (SMS, SSL, notification systems, etc.).

Latch is one of these solutions that build an extra level of protection to any authentication/authorization mechanism. Actually, Latch can incorporate to the credential validation process the constrains that the legitimate user has defined for the use of a specific system or service (user constrains). Unlike other global protection measures, Latch lets the user decide when and under what circumstances access to certain operations defined by a system of which they are a legitimate user can be accessible. Latch can be seen as an authorization factor more than as an authentication one, which reduces the exposure faced by the systems or services to be attacked. Somehow, it reduces the potential impact of attacks involving the endangerment of the credentials associated with an identity. It is similar to putting a lock on the use of resources depending on the use that the legitimate user gives or hopes to give them.

The implementation of a second factor authorization with tools like Latch increases the robustness level of a digital identity in Wordpress. The inclusion of a Latch Plugin in Wordpress helps protect and detect identity theft when the attacker tries to use the identity. This type of protection is provided at user level, that is, each user is responsible for the use of the second factor.

The login process in Wordpress allows to check if the password entered by the user actually belongs to that user (authentication mechanism based on “something the user knows”). In the event that this is so, Wordpress authorizes access to its resources according to its authorization policy. During the decision of granting access to resources it is possible to add Latch as an authorization factor. Once the Latch Plugin for Wordpress has been installed, it will ask Latch about the status of the lock. In the event that the lock is open, the user is authorized to access their own resources. If, however, the lock is closed, access to resources is denied. In addition, in the negative case, the user will receive a notification that it is paired with the account, so they can know at all times if someone has attempted to use their digital identity.

2.1. Installing the Latch Plugin for Wordpress To install the Latch Plugin for Wordpress in order to harden the login process and minimize the exposure time of identity, the user must follow these steps:

• In the php.ini file, uncomment the line “extension=curl.so”.

• Wordpress version should be at least 1.5.

• Create an App in the developers Latch area, in the URL https://latch.elevenpaths.com.



Página 6 de 17

Figure 1: Creating App in Latch

2.2. Pairing of the Latch Plugin for Wordpress

The pairing process of a user with the Latch Plugin for Wordpress is a simple process. From the user profile any attribute can be edited. Among these fields, we can find the tag “Latch Setup”.

Figure 2: Inserting a Latch token in Wordpress

After generating a token with Latch and entering it into the text box above, the pairing process takes place. The Latch app receives a notification that the protection has been generated.

Figure 3: Pairing Latch with Wordpress Plugin



Página 7 de 17

2.3. Verification after an attempt of phishing in Wordpress

To verify that the user has their identity protected against loss or theft of credentials, the lock must be enabled, as shown in the image below.

Figure 4: Locked Latch

In the case of a phishing attempt, Wordpress first checks that the username and password are correct. In this case, a query is sent to Latch to check the status of the lock. If the lock is enabled, Wordpress denies access to the user and Latch generates a notification to alert the user of a potential attempt of phishing. In the event that the lock is open, that is, disabled, the login takes place as it normally would, giving the user access to the Wordpress internal area.

3. Fortification at table level with 2 Factor Authorization When attacks like SQL Injection or Network Packet Manipulation impact on the Wordpress database engine, they can cause loss, alteration or insertion of information. A SQL Injection can cause loss, manipulation or insertion of data in Wordpress critical tables Reviews, such as “wp_users” or “wp_usermeta”. On the other hand, a Network Packet Manipulation attack allows an attacker, placed in between of the communication between the Wordpress web application and the database, to modify the query that the CMS sends to the database. The aim of the attacker is to alter, delete or insert information. It is understood that these two threats are important and affect the confidentiality and integrity directly, and the availability indirectly.

The proposed solution, which has been carried out, is the implementation of a series of triggers that monitor the actions that occur in Wordpress critical tables, allowing the owner to enable or disable actions on Wordpress tables with a second factor authorization. These triggers communicate with Latch to check the status of the operation to be carried out. In the event that the operation has its lock closed, the trigger blocks the query, whereas if the lock of the operation is open, the trigger allows the primary action.

3.1. Mode of action To better understand the proposed security model based on the hardening at table level of a CMS, the following modes of action are described:

• “Read-Only” mode. The read only mode allows the owner of the Wordpress to disable the capability of a user to login, as well as administrative operations such as adding, modifying or deleting users. Comments or posts are not allowed either in the CMS.

• “Administration” mode. The administration mode allows the owner of the Wordpress to decide when inserts, updates or deletions of users are allowed, that is, to carry out user management when the owner requires so.



Página 8 de 17

• “Edition” mode. Edition mode allows the owner of the Wordpress to delegate the possibility to post content only when they want to.

Figure 5: Operating modes with Latch WPM

These modes respond to a clear protection; certain critical operations can only be carried out when the owner enables the possibility with a second factor authorization. The first factor authorization would be the permissions of the database itself.

It can be understood that SQL Injection or Network Packet Manipulation attacks will be protected against the insertion, modification and deletion of content. Triggers are the element of table monitoring, they are located in database engines and allow code execution. This code execution serves as a second factor authorization to check whether to perform an action or another.

3.2. Affected tables A default Wordpress installation creates 12 tables in its database engine, usually MySQL. The next image displays the different tables that are created in a Wordpress installation.

Figure 6: Default tables in Wordpress



Página 9 de 17

According to the analysis carried out to meet the different modes exposed in the previous section, triggers must be created on tables wp_comments, wp_posts, wp_users and wp_usermeta.

The wp_comments table stores comments and relates them with posts. In addition, there are other metadata, such as author, email, URL, etc. The idea is that when the “Read-Only” mode is enabled, the possibility to insert, update or delete contents of this table is protected, so new comments cannot be created.

Figure 7: Fields of the wp_comments table

The wp_posts table contains different attributes related to the identity of the author of the post, the date, visibility, etc. The edition mode is responsible for protecting insertions, updates or deletions of table values. Also, if the “Read-Only” mode is enabled, the table cannot be manipulated.

Figure 8: Fields of the wp_posts table

The wp_users and wp_usermeta tables are strongly related. The first table stores information about users, such us password, email, URL, nickname, etc. This table is used by the CMS to compare whether the password entered by the user is valid and corresponds to the user name indicated.



Página 10 de 17

Figure 9: Fields of the wp_users table

When the user is validated, a session cookie is created and stored in wp_usermeta. The structure of the wp_usermeta table is shown below.

Figure 10: Fields of the wp_usermeta table

The session cookie is created as “session_tokens” and stored in the “meta_key” column, while the value of that cookie is stored in “meta_value”. Another important value is the role, which is also stored in the wp_usermeta table. This value is crucial, as it is associated with the permissions the user has in the CMS.

This information is key when designing triggers. There are some critical scenarios that may need special treatment:

• When a new user is deleted, updated or added, the wp_users table is modified, as well as the wp_usermeta table, since the role, nickname and other attributes are related to the user.

• When a user logs in, the wp_users table receives queries to verify that the password is the one it has stored. When this is checked and validated, an insertion in the wp_usermeta table is generated to add, among other things, the session_token. If the event that it already exists, instead of conducting an INSERT operation, an UPDATE operation with the new value would be carried out and stored in “meta_value”.

The design of the solution takes into account these scenarios, in which both tables are related. We have detected that the table that can be the object of more alterations or modifications is wp_usermeta, and so the next section details the algorithm used to implement the solution.

3.3. WPM overall scheme The proposed solution to protect Wordpress at table level with Latch has different elements, which are listed as follows:



Página 11 de 17

• Binaries implementing queries to Latch, depending on the operation that needs to be checked.

• Binary called token for pairing with Latch.

• Binary called operations that is responsible for creating the operations once the pairing is successful.

• Generated triggers that interact with the binaries that check the status of Latch’s operation.

Figure 11: WPM scheme

3.4. Triggers algorithm

The triggers associated with the tables are identical in their three possible operations (INSERT, UPDATE, DELETE). Their algorithm can slightly change between tables. This section provides examples of the triggers designed and implemented as a main protection part in Wordpress in Paranoid Mode. The generic algorithm for operations in pseudocode is as follows:

CREAR TRIGGER nombreTrigger

ANTES|DESPUES en baseDatos.tabla

PARA CADA FILA

Readonly = Ejecutar y almacenar estado operación “Read-Only” a Latch

SI Readonly != 0 ENTONCES

Bloquear modificación en la tabla “modo sólo lectura”

FIN SI

Operación = Ejecutar y almacenar estado operación X a Latch

SI Operación != 0 ENTONCES



Página 12 de 17

Bloquear modificación en la tabla “modo X”

FIN SI

FIN TRIGGER

The case of the wp_usermeta table presents a critical scenario, presented above: that when a login takes place, a value needs to be changed or modified in that table. If the Administration mode is enabled, the login cannot be carried out. To solve this, the following algorithm has been designed for the triggers of the wp_usermeta table.

CREAR TRIGGER nombreTrigger

ANTES|DESPUES en baseDatos.tabla

PARA CADA FILA

Readonly = Ejecutar y almacenar estado operación “Read-Only” a Latch

SI Readonly != 0 ENTONCES

Bloquear modificación en la tabla “modo sólo lectura”

FIN SI

SI NEW.meta_key != ‘session_tokens’ ENTONCES

Admin = Ejecutar y almacenar estado operación “Administration” a Latch

SI Admin != 0 ENTONCES

Bloquear modificación en la tabla “modo Administration”

FIN SI

FIN_SI

FIN TRIGGER

To illustrate this with the implementation, the following example shows the trigger to be executed before an insert command in the wp_usermeta table.

CREATE TRIGGER LatchUsermetaUpdateWP

BEFORE UPDATE ON wordpress.wp_usermeta

FOR EACH ROW

BEGIN

DECLARE readonly int;

DECLARE result int;

SET readonly = sys_exec('ruby %PATH%/comment.rb');

IF readonly NOT IN (0) THEN



Página 13 de 17

SIGNAL SQLSTATE '45000'

SET MESSAGE_TEXT = 'Latch Cerrado';

END IF;

IF NEW.meta_key <> 'session_tokens' THEN

SET result = sys_exec('ruby %PATH%/users.rb ');

IF result NOT IN (0) THEN

SIGNAL SQLSTATE '45000' -- "unhandled user-defined exception"

SET MESSAGE_TEXT = 'Latch Cerrado';

END IF;

END IF;

END

3.5. Installation Process The installation process is fully automated through the BASH console. This process is divided into different steps, which are listed below:

• Create an Latch App in the developers area: https://latch.elevenpaths.com. The Application ID and Secret values must be taken into account to send them to the WPM installer.

Figure 12: Creating an App in Latch

https://latch.elevenpaths.com/



Página 14 de 17

• Pairing with Latch. The pairing process is performed through the request of a token to Latch.

Figure 13: Pairing of WPM

• Once the pairing process is complete, the process of copying and customizing files with data from APP ID, SECRET, ACCOUNT ID starts. Subsequently, the creation of operations “Read-Only”, “Administration” and “Edition” in Latch is performed. In addition, binary files that interact with Latch are personalized with the different OPERATION ID.

• At this point, everything needed to interact with Latch has been created and configured. Dependencies and necessary applications are installed and the database engine is configured with what it takes to then perform the dumping and creation of triggers.

• During this last point, the creation of triggers in the database engine on the tables specified above is carried out.

Figure 14: Successful completion of installation of WPM

3.6. Protecting Wordpress against malicious actions The “Read-Only” mode configures Wordpress so that it cannot be written on, so it will neither carry out any user login. As we can see in the image, the “Read-Only” operation is closed with the Latch App.



Página 15 de 17

Figure 15: Read-Only mode enabled

In the moment that someone tries to write a comment in Wordpress (no need to be logged in, and it could be any user on the Internet) or any user tries to log on, the triggers check the status of Latch for that operation. At that moment, attempted insertions, updates or deletions in the tables will be aborted. In addition, the user owner of Wordpress will receive a notification of attempted access. This means that there has been an operation against a table, and that the associated trigger has blocked it.

Figure 16: Attempted access of any user with the Read-Only mode enabled



Página 16 de 17

In the case of the “Administration” mode, if someone tries to delete, update or insert values in the wp_users table, and indirectly in wp_usermeta, the action will be blocked, provided that the Administration operation is closed. The next image shows how to delete a user.

Figure 17: Deleting users in Wordpress

If the operation is open, the deletion of the user can be performed, but if the owner of Wordpress has closed the lock in Latch for that operation, said DELETE will be blocked in the table. The following image shows how the attempt to administrative action is notified.

Figure 18: Attempt to remove blocked by the Administration user mode



Página 17 de 17

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/

hardening in wordpress i

Technology