Concordia Institute for Information System Engineering (CIISE)

Concordia University

INSE 6140 Malware Defenses & Application Security

Project Report

A vulnerability Analysis of WordPress v4.4.2

Group Name: BaChDa2016

Submitted to:

Professor Dr. Makan Pourzandi

Submitted By:

Student Name Student ID

Akhilesh Batra 27682794

Akashdeep Chauhan 27895801

Reza Dadgostar 27397488

Date: 15th April 2016

Table of Content:

1. Introduction………………………………………………………………………………………………………………3

2. Vulnerabilities Detected in Linux via Tools…………………………………………………………………5

3. Windows Operating System Exploits………………………………………………………………………….8

4. Conclusion……………………………………………………………………………………………………………….15

5. References……………………………………………………………………………………………………………….15

1. Introduction:

In a modernized era, there are various computer application that allows publishing and maintaining content from a central interface. It is used to manage the content of a website containing blogs, news, shopping, and weather. As a group, we decided to take WordPress as our project because large number of people takes interest in WordPress to create their own sites and blogs in the simplest way. Users find limitless possibilities with WordPress plugins.

WordPress is an online, open source application which has developed in JAVA and it is famous for blog writing. It is probably the easiest and most widely used blogging and website where content has been managed rigorously. WordPress is completely customizable and can be used for almost anything. WordPress powers on a daily basis of the web- a figure that rises exponentially. Everything from simple websites, to blogs, to complex portals and enterprise websites, and even applications are built with WordPress.

Because of various features such as Built-in comments, search engine optimization, multilingual, plugins, themes, application framework, it needs to be maintained and it is vulnerable to security threats.

We are using WordPress version 4.4.2 for our project which is vulnerable to XSS, SQL injection and many critical vulnerabilities.

1.2 Methodology/Approach:

Since we have worked on different operating systems (LINUX-UBUNTU & WINDOWS) so that we can cover

the broader perspective to find exploits or vulnerabilities. In order to find exploits we need to have some

testing environment and tools. We are going to explain the testing shell as well the tools that we have

used in respective OS.

We have prepared the Testing Environment to be secure.

We have used tools to find exploits in open source web application

After scanning and exploiting, we understood the attacks behavior

After finding critical exploits, we prevented the attacks.

1.3 Testing Environment:

Each and every application is being tested on some environment, so in order to find critical vulnerabilities

in LINUX (UBUNTU) we have installed LAMP bundle on UBUNTU OS. Therefore, LAMP which is an acronym

for Linux, Apache Server, MySQL database and PHP respectively. It’s a pivotal testing software which helps

tester to test an open source application whether it has exploits or not. On the other hand, LAMP is most

effective and popular ways of developing web application because of its flexibility and cost effectiveness.

1.4 Scanning and Code Analysis Tools:

When it comes to penetration, forensics, and security testing in LINUX OS, we have more than 200-300

open source scanning tools which is arguably the best of all to find exploits and the tools that are being

used to scan an application is WPScan, RIPS, Vega.

WPScan RIPS VEGA

It’s an out of box solution. Stands for WordPress Scanner to exploit applications.

Well known free and open source scanner to find exploits in PHP applications using static code analysis.

Open source system for web application vulnerability testing. It is used to find and validate SQL injections and XSS.

Install abundant packages for WPScan and we can launch it remotely.

No need to type any command to work on RIPS, just login to the environment and it connects by default.

Quick test and an intercepting proxy for tactical inscpection.

Tester needs to work with commands and doesn’t know anything how it works internally.

Tester needs to give the path of an application and it would be ready to scan it. It’ll give the detailed output so that tester can understands it and works on it.

Vega needs an actual program to run on operating system.

1.5 System Characteristics:

The following step briefly explains the operation of the working environment:

1. The first and foremost step is to create a Virtual Machine (VM) by simply using Virtual Box

Software.

2. Install LINUX Operating system (Ubuntu) on Victual Machine

3. Install LAMP packages on LINUX OS with their dependencies.

Apache: It’s a well know Open source Web server Version 2.4.7 which is being used to test

an application.

MySQL API Version 5.5.47 is used to manage web application’s database.

PHP Version is used to support web server (Apache) to read PHP files.

We created a database in MySQL for the WordPress application.

Installing the latest version of Web Application i.e. latest version of WordPress 4.4.2

Installing WPscan, RIPS and Vega scanning tools with their dependencies on Virtual

Machine.

1.6 Threats Statement:

Attack Vector:

An attack vector is a path or mean by which a hacker can gain access to a computer or network or an

application in order to deliver malicious outcome. Attack Vectors enables attackers to exploit systems

vulnerabilities, including the sensitive data which may contains password, credit card information etc.

Threat Types:

Our main motive was to exploit an application with the help of open source scanning tools. We came

across a bunch of vulnerabilities which includes XSS, directory traversal etc. With XSS vulnerability, we

inserted a java script and without any validation it got executed, there wasn’t any sanitization. So proper

sanitization is required with this kind of vulnerability. Since we have inserted a java script in the title post

and published it, any malicious user can be opportunist to insert a malicious code and steal user’s

information.

When we trying to delete the default plugins of WordPress and using a path traversal command instead

of plugin name in the URL, it gave us an awestruck result i.e. revealing the path of a directory of a file

which was deleted including with the other files.

Un-sanitized Input:

Since we came across the cross-site scripting vulnerability which happened because of the improper

sanitation in the “title” field of the “post-template.php” & “plugins.php” for directory traversal. The

pivotal point is that there isn’t any sanitization in those fields and codes and any malicious user can take

an advantage of it and steal sensitive information.

2. Vulnerabilities Detected in Linux via Tools:

2.1 WPScan Result:

WordPress Vulnerability Low Medium High

1. Stored Cross-Site Scripting (XSS)

2. Denial-of-Service (DoS)

3. CSRF in wp-login.php

4. Server side request forgery

5. Directory Traversal

6. Session ID

Description of Vulnerability found:

With XSS vulnerability, we inserted a java script and without any validation it got executed, there wasn’t

any sanitization. So proper sanitization is required with this kind of vulnerability. Since we have inserted

a java script in the title post and published it, any malicious user can be opportunist to insert a malicious

code and steal user sensitive information. This vulnerability is found in the WordPress folder where

destination would be var/www/WordPress/wp-includes/post-template.php. Since it could steal user

private or sensitive information, the severity of this vulnerability is too high, we could also say that this

could be considered as cross-site script forgery. The only way to mitigate this type of vulnerability is the

proper sanitization of code.

2.2 RIPS Result:

Vulnerability detected via RIPs tool (SQL injection):

SQL injection has been detected with the help of RIPS scanning tool. SQL injection is a code injection

technique which is used to attack open source application in which malicious SQL command is inserted

into an input field. It has a medium severity as it doesn’t succeed most of the time. According to OWASP,

there are two theoretically ways by which it could be mitigated. The first one would be parameterized

queries and the other one is by careful use of stored procedure.

2.3 Exploit in Source Code:

Code 1:

Code 2:

2.4 Mitigations:

With XSS vulnerability, an attacker can insert a java script in any input field and without any validation it

got executed, there wasn’t any sanitization. So proper sanitization is required with this kind of

vulnerability. This vulnerability is found in the WordPress folder where destination would be

Vulnerable Code

Vulnerable Code

var/www/WordPress/wp-includes/post-template.php. Since it could steal user private or sensitive

information, the severity of this vulnerability is too high, and it should be mitigated. The only way to

mitigate this type of vulnerability is the proper sanitization of code

With Code 1 and Code 2, we need to insert “htmlentities” function in order to mitigate this

vulnerability.

For example:

Code 1 Code 2

echo htmlentities ($title);

return htmlentities ($title);

The function of htmlentities () function in PHP is used to convert characters into corresponding html

entities where applicable. This is the reason a malicious attacker cannot insert harmful codes into a site.

Since we have worked on two operating systems (LINUX & WINDOWS) so that we can cover a broader

perspective of the project. Here we have found Vulnerabilities in Windows OS.

3. Windows Operating System Exploits:

The Zed Attack Proxy known as ZAP is one of the most popular free security tools. ZAP is open source and is developed by OWASP. It is available for Unix/Linux, Windows, and Macintosh platforms. This tool a great for experienced pen-testers to use for manual security testing. ZAP provide test cases and attack vectors that can be used for vulnerabilities such as spoofing, buffer overflows, information disclosures, format strings, XSS injection and SQL injection, XML, SOAP, denial of service, canonicalization issues, ActiveX controls and managed code.

3.1 Directory Browsing Vulnerability:

Directory Browsing is one of the vulnerability that we discovered by scanning latest version of WordPress until 25th February 2016 (4.4.2) with ZAP scanning tool. This vulnerability has shown in the below picture:

Directory browsing vulnerability

Vulnerability description:

If a directory listing is inappropriately exposed, it resulted to revealing potentially sensitive information to the adversary. A directory listing brings an adversary with the total index of all the resources located inside of the directory. The consequence and specific risks could be different depending on which files are listed and accessible. Exposing the contents of a directory can result to gaining access to the source code or providing valuable information for the adversary to develop exploits, such as creation times of files or any information that may be encoded in file names. Also the directory listing could lead to compromising confidential or private data.

Mitigations:

Mitigations include restricting access to critical directories or files by applying a necessity to know requirement for both the server root and document, also turning off features such as Automatic Directory Listings that could expose private files which cloud resulted in to providing the information that could be exploited by an adversary when conducting an attack. To apply the mitigation we need to modify the .htaccess file which is in the root directory then we need to add Options All – indexes to prevent non legitimate user browse our directory.

After applying the modification in .htaccess file directory browsing is not available to the ono legitimate users.

3.2 Path Traversal:

Path traversal is another vulnerability that we have found during the test via our scanning tool ZAP. This vulnerability has shown in the below picture:

Path traversal vulnerability

Vulnerability Description:

For doing path traversal in WordPress we have to log in as a user of WordPress then we could manipulate

the action link to execute path traversal command “../”. By exploiting this vulnerability non root users

could view or list the files or directories that they shouldn’t see, so this provide them to gain important

information to exploit the server or gain the information which could result in to taking the root access or

full compromise of the server.

Depending on how the WordPress access is set up, the adversary would execute commands by

impersonating himself as the root user of WordPress. So it all depends on how the WordPress user has

been given access to the system.

3.3 Password Autocomplete in browser:

WordPress is offering custom "remember me" functionality to let users to stay logged in on a specific

client system this feature could give a clue to the attacker that how the token is stored on the client

system which could be lead to exposing the users passwords. To avoid this problem it is recommended to

use autocomplete="off" in web authentication form. We have shown this vulnerability in WordPress

admin log in form which autocomplete="off" feature should be applied this file name is wp-loging.php

and modification should be applied in line 717, 883 and 887.

3.4 X-Frame-Options response header (Clickjacking):

By using the X-Frame-Options HTTP response header we can point out if a browser is allowed to render a

page in a <object> , <iframe> or <frame>. Websites can use this option to prevent clickjacking attacks, by

making sure that their content is not included into other websites.

Mitigations Against Clickjacking:

Commanding the browser to not allow framing from other domains by sending the appropriate X-Frame-Options HTTP response headers.

Configuring Server:

In order to configure Apache server to include the X-Frame-Options header for all pages, the

following line should be added to “httpd.conf” setting file then restarting the server:

Header always append X-Frame-Options SAMEORIGIN

3.5 X-Content-Type-Options Header Missing:

When the value, "nosniff" is sent by X-Content-Type-Options response header it could prevents from

MIME1-sniffing in Internet Explorer and Google Chrome. This also applies when downloading extensions

for Google Chrome. So the line below should be applied to server configuration then restarting the server:

Header set X-Content-Type-Options: nosniff

3.6 X-XSS-Protection:

X-XSS-Protection enables the XSS (Cross-site scripting) filter. This header is supported in IE 8+, and

in Google Chrome In order to improve the security of websites against cross-site scripting attacks

The following instruction can enable X-XSS protection in Apache server:

Header set X-XSS-Protection "1; mode=block"

3.7 Cookie set without HttpOnly flag:

HttpOnly is a flag which could be included in a Set-Cookie HTTP response header. If the browser supports

this flag and the HttpOnly flag is included in the HTTP response header, as a result the cookie cannot be

accessed through client side script. So, even if user accidentally accesses a link that exploits this

vulnerability, the browser won’t reveal the cookie to a third party. By setting the HTTPOnly flag on a cookie

server creates this issue could be mitigated, this flag indicate that on the client side the cookies which

came from this server should not be accessible to a third party. This could be achieved by following

command in Apache servers:

Header always edit Set-Cookie (.*) "$1; HTTPOnly"

When the browser detects HttpOnly flag in cookie if a malicious client side script code wants to read

the cookie the browser returns an empty string as a result.

Now we can compare the result before and after applying these mitigations.

ZAP Scanning Report Summary of Alerts before applying the mitigations

High (Medium) Path Traversal

Medium (Medium) X-Frame-Options Header Not Set

Medium (Medium) Directory Browsing

Low (Medium) Web Browser XSS Protection Not Enabled

Low (Medium) X-Content-Type-Options Header Missing

1 Multipurpose Internet Mail Extensions

Low (Medium) Cookie set without HttpOnly flag

Low (Medium) Password Autocomplete in browser

ZAP Scanning Report after applying the mitigations

Low (Medium) Web Browser XSS Protection Not Enabled

Low (Medium) X-Content-Type-Options Header Missing

URL http://localhost/wordpress

URL http://localhost/robots.txt

URL http://localhost/sitemap.xml

These two vulnerabilities are false positive.

We look after file location to see the problem and we realize those files which is shown as vulnerable

files does not exist.

Also we inspect the header packet to see the difference before and after applying the mitigations the

elements that are shown were not included in the header before applying the mitigation.

After applying the mitigations

Vega is another security tool that we used in our project .Vega is an open source scanner which can help

to find and validate Cross-Site Scripting (XSS), SQL Injection, inadvertently disclosed sensitive information,

file inclusion, and other vulnerabilities. Vega is GUI based, written in Java, and can be used on Linux, OS

X, and Windows.

We have scan WordPress with Vega and found below vulnerabilities:

Before applying mitigation

After applying mitigation

3.7 Cross Site Tracing:

Trace is a method that whatever string has been sent to the server will be echoes back to the client, this

feature is mainly used for debugging purposes. Trace method, can be used to launch an attack which is

known as Cross Site Tracing.

Mitigation:

The following lines should be applied in server configuration file “httpd.conf”:

RewriteEngine On

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)

RewriteRule .* - [F]

4. Conclusion:

In this project we have approached a broader way in such a way that we worked on two operating systems

so that we can cover wider area of finding an exploit in the latest version 4.4.2 of WordPress. In Linux we

have found a critical stored XSS vulnerability and directory Traversal which could result in revealing the

session cookie or session ID and revealing a path of a directory respectively. Therefore, it should be

mitigated with proper sanitization of code.

In windows, we have used various open source tool such as ZAP, VEGA etc. which helped us in finding an

exploit in the latest version of WordPress. The critical vulnerability we have found here is Path traversal,

Directory browsing. With this kind of vulnerability, attacker can observe the files that it is not supposed

to be shown and it could lead to taking the root access or full compromise of the server. Since it is critical,

it needs to get mitigated.

5. References:

1. http://www.wpmayor.com/wordpress-security-based-facts-statistics/

2. https://github.com/wpscanteam/wpscan

3. https://subgraph.com/vega/download/

4. https://wordpress.org/about/security/

5. http://www.computerweekly.com/tip/Cross-site-scripting-explained-How-to-prevent-XSS-

attacks

6. https://cwe.mitre.org/data/definitions/548.html

7. http://www.acunetix.com/websitesecurity/directory-traversal/

8. https://wordpress.org/support/topic/recommendations-for-x-xss-protection-x-frame-options-x-

content-type-nosniff

9. https://www.perpetual-beta.org/weblog/security-headers.html

10. https://developer.mozilla.org/en-

US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion

11. https://www.owasp.org/index.php/Testing_for_Vulnerable_Remember_Password_(OTG-

AUTHN-005)

12. https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options

13. https://www.owasp.org/index.php/Clickjacking

14. http://stackoverflow.com/questions/18337630/what-is-x-content-type-options-nosniff

15. https://www.owasp.org/index.php/List_of_useful_HTTP_headers

16. https://kb.sucuri.net/warnings/hardening/headers-x-xss-protection

17. https://www.owasp.org/index.php/HttpOnly

18. http://stackoverflow.com/questions/24129201/add-secure-and-httponly-flags-to-every-set-

cookie-response-in-apache-httpd

19. https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006)

20. http://www.techstacks.com/howto/disable-tracetrack-in-apache-httpd.html

21. https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project#tab=Main

22. http://resources.infosecinstitute.com/14-popular-web-application-vulnerability-scanners/