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
    • Version Scanning
    • WordPress Themes
    • WordPress Plugins
    • WordPress Usernames
    • All in a single command
  • WordPress Exploitation
    • Bruteforce Attack using WPScan
    • Shell Upload using Metasploit
    • 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:

  • Detect the version of currently installed WordPress.
  • Can detect sensitive files like readme, robots.txt, database replacing files, etc.
  • Detect enabled features on currently installed WordPress server such as file_upload.
  • Enumerates the themes, plugins along with their versions and tells if they are outdated or not.
  • It even scans up the web-application to list out the available usernames.

Before going deeper, I suggest you 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.

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.

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 play 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 colour preferences.

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

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

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:

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:

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.

–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 word list 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:

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.

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 found 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.

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

Scanning over a Proxy Server

Is it 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 set up 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:

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

Scanning with an HTTP Authentication enabled

Many websites enable HTTP authentication so that they can hide some essential and critical information from 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.

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

Author: Chiragh Arora is a passionate Researcher and Technical Writer at Hacking Articles. He is a hacking enthusiast. Contact here

Comprehensive Guide on Broken Authentication & Session Management

Does just keeping secure and a strong password can really protect you? Today in this article we’ll learn, how an attacker analyzes 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 to Authentication
  •  Broken Authentication and Session Management
  • Sessions
  • Cookies
  • Impact of Broken Authentication
  • Broken Authentication
    • Credential Stuffing
    • Insecure Web-Applications
      • Insecure Login forms
      • Logout management
    • Bypassing Forget Password Option
  • Improper Session Management
    • Administrative Portal Login
    • Session Hijacking
      • Using the Browser’s Plugin
      • Using Burpsuite
    • Mitigation Steps

Introduction to Authentication

Authentication is the process of validating a user who is claiming to be a genuine one. Thus in a web-application, password plays a 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 passes it to the browser in the form of Cookie Session ID.

What is Broken Authentication & Session Management 

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 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.

 A website or application is vulnerable to Broken Authentication when:

  • Username and password are easy to guess using fuzzing or brute force.
  • Password Does not match Password complexity policy.
  • Enumeration of username/password at the of Authentication failure response invalid username or an invalid password.

A website or application is vulnerable to Session Management when:

  • Login credentials are not protected when stored and lacking hashing and salt.
  • Transmission of username and password over an unencrypted channel such as HTTP
  • Session ID exposes in URL.
  • User session or authentication tokens are not timeouts after user logout.

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 is 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 die 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 is deleted only when they are on their expiration date or when a user shuts down the browser.

To know more about cookies and session management read from here

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.

Vulnerability Walkthrough to demonstrate Various Attack 

Until 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 login 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 tools 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.

Now it’s time to configure our attack!!

Switch to the Position tab and 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 new 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. Then 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 and at last click on Start Attack.

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.

Here, 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 a bee : bug.

Insecure Login Forms

As mentioned above, when login credential is stored without the proper security majors being used, just like without the addition of hashing or salt value with username and password at the location where it is stored, this could be lead to insecure login that could be considered as vulnerable to session management.

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 vulnerabilities, where the developers simply setup the hyperlinks of the logout page at the logout text without having any concern about the generated session and do not validate the weather the session ID is getting timeout or not once the user logout from the application. 

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 the 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.

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 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 (Attacker) in order to exploit this vulnerability. To install and setup WebGoat click here.

Note: Here at port 8080 the  Webgoat server is enabled for HTTP service and at port 9090 the webwolf is enabled for SMTP.

From the left-hand side, the panel selects Broken Authentication following with Password Reset field. Thus selecting the 6th 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 [email protected] as the registered email address.

From the above image, you can see that we got the response as “An email has been sending to [email protected]

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

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

Now it’s time to break and get into the victim’s account i.e.“tom’s account” who is my target and with the help of footprinting, I have identified his email ID. Back to the WebGoat server, we’ll write the tom’s email address as [email protected]. But this time we’ll capture the request in the burpsuite before sending it to the server.

As soon as we capture the “Post Request”, we’ll send it all to the repeater.

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, you can see that “An email has been send to [email protected]. But this email has actually been sent 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 sends 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 “[email protected]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.

Woah!! We are redirected to a new “Reset your password” page, seems like we’re changing 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:

Great!! We’ve successfully changed 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

Until 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 a 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 does not need to enter his credentials every time for every single page he requests for.

But the attacker sniffs the network and steal up these freshly generated session IDs before they were sent to the user. Now the attacker just needs to send these session ID’s to the web server, the 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 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 copying them into our clipboard, which can further be used in getting an authenticated access. 

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 by pasting the exported cookies into the Cookie Editor console.

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 fail 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 ids 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 favourite 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 and replace the session ID, and further will check its generated response.

From the above image, 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, username, password, session tokens in the most encrypted way where they stored.
  2. Validate appropriate session timeout and invalidated during logout for session tokens.
  3. 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.
  4. Session ID’s should not be exposed in the URL.
  5. Use Encrypted channel for transmitting username and password to the server.

Author: Chiragh Arora is a passionate Researcher and Technical Writer at Hacking Articles. He is a hacking enthusiast. Contact here

WordPress Pentest Lab Setup in Multiple Ways

In this post, we will demonstrate how to set-up our own Vulnerable WordPress CMS for penetration testing on Ubuntu 20.04, Docker and Windows using XAMPP server.  

Table of Content

  • WordPress Setup on Ubuntu 20.04
  • Install WordPress using Docker
  • Install WordPress on Windows Platform

WordPress Setup on Ubuntu 20.04

In order to configure WordPress in your Ubuntu platform, there are some prerequisites required for CMS  installation.

Prerequisites for WordPress

  • Apache
  • Database (MySQL/Mariadb)
  • PHP

Install Apache

Let’s start the HTTP service with the help of Apache using privilege account (as root), execute the following command in the terminal.

Install MySQL

For run WordPress, you will also need a database server. The database server is where WordPress content is saved. So, we are going to choose MariaDB-server as the required database for WordPress and execute the following command

Next, execute the following commands to protect remote root login for the database server.

Then respond to questions asked after the command has been executed.

  • Enter current password for root (enter for none): press the Enter
  • Set root password? [Y/n]: Y
  • New password: Enter password
  • Re-enter new password: Repeat password
  • Remove anonymous users? [Y/n]: Y
  • Disallow root login remotely? [Y/n]: Y
  • Remove test database and access to it? [Y/n]: Y
  • Reload privilege tables now? [Y/n]: Y

Install php

And at last, install the php php-MySQL and run the following command to install this application.

Create a Database for WordPress

To access the MySQL, enter the following command which will create a database for wordpress.

WordPress Installation & Configuration

Now, its time to download and install the WordPress on our localhost, with the help of wget command we have fetched the compressed file of wordpress setup and extract the folder inside the /var/www/html directory.

Then run the given command to change ownership of ‘wordpress’ directory as well permission for upload directory.

Now, till here we are done with the installation, to create a WordPress website we need to access the application over web browser on localhost by executing following and then complete the remaining installation process.

This will open the setup file and ask to choose your preferred language. I select English and then press the continue Tab.

Read the given content and press Let’s go to continue the activity.

To continue the activity, we need to enter the required details that will help the application to connect with database, thus it should be the same information that we have entered above at the time of database we have created for WordPress.

And if your above-given detail is correct, you will get the Installation page as we have here.

Now after that, it will ask you enter details for your Website which you want to host using WordPress CMS as shown in the below image and then finally click on install Tab.

Note: The User and Password asked before the installation is referred to your Database information, and the username and password asked after installed are referred to your application (CMS).

And once it is done, you will get application login page where you have to enter credential to access the dashboard of your CMS.

You will get the dashboard where you can write your content that to be posted on the website.

Open the wp-config.php file in wordpress directory and paste the following lines in it to access the website page.

And Finally, it is over here, and your WordPress is completely ready to go😊.

Install WordPress using Docker

Install WordPress through docker will release your effort of installing prerequisites for WordPress setup. It is a very easy and quick technique to configured WordPress. All you need to have some basic knowledge of Docker and its functionalities.

To install wordpress using docker, first, we will update the Ubuntu repository and then install the latest version of docker.io. Let’s start the installation of docker packages with the apt command as below:

Docker Compose is used to run multiple containers as a single service. Let’s begin the installation of docker-compose with the help of apt by entering the following command.

After installing the composer for the Docker, we must create a directory by the name of WordPress. After creating the directory, we will create a .yml file that will contain the service definitions for your setup.

Now Paste the following text in the .yml and save the configuration. Source Code From here

Now run the docker image in detach mode using the following command

After doing all the configuration step-by-step, now access the localhost on port 8000 that will be hosting your WordPress Docker image and configure your WordPress site as done in the previous section.

You will get the dashboard where you can write your content that to be posted on the website. But here we need to make some changes inside the setting so that the wordpress after installation it will work properly. Thus, enter your localhost IP address with a port number on which your docker image is running.

And Finally, it is over here, and your WordPress is completely ready to go but over port 8000 as shown here 😊.

Install WordPress on Windows Platform

Installation of WordPress is also very easy as compared to ubuntu because to fulfil the prerequisites of LAMP Server we can use XAMPP that will complete the all required dependency like apache and MySQL for WordPress.

Now download the extract the zip file of WordPress inside the /htdocs folder in /xampp folder in C-Drive.

Now open the PHPMYADMIN in a web browser by accessing /localhost/phpMyAdmin and create the database for WordPress to store its data.

Now in order to configure wordpress, explore the /localhost/wordpress/ and then enter the detail for the database.

Note: By Default, XAMPP DB_User is root and DB_Pass is empty <blank>

So as per XMAPP database configuration, we entered the following details in the given record.

Now again repeat the same step as done in the above section.

You will get the dashboard where you can write your content that to be posted on the website.

To make it vulnerable WordPress platform in order to perform penetration testing I have installed some vulnerable plugin as highlighted in the image.

To know how we can go do WordPress Penetration testing read this article.

WordPress Vulnerable Plugin

https://www.exploit-db.com/exploits/40290

https://www.exploit-db.com/exploits/36374

https://www.exploit-db.com/exploits/44883

Author – Paras khorwal is a Certified Ethical Hacker, Technical writer and Penetration Tester at Hacking Articles. Technology and Gadget freak. Contact Here

CyberSploit: 1 Vulnhub Walkthrough

Today we are going to solve another boot2root challenge called “CyberSploit: 1”.  It’s available at Vulnhub for penetration testing. This is an easy level lab.  The credit for making this lab goes to cybersploit1. Let’s get started and learn how to successfully break it down. Level: Easy

Since these labs are available on the Vulnhub website. Let’s download the lab file from here.

Penetration Testing Methodology

Reconnaissance

  • Netdiscover
  • Nmap

Enumeration

  • Gobuster

Exploiting

  • Basic Cryptography
  • CyberChef

Privilege Escalation

  • Local Privilege Escalation ‘Overlays’
  • Capture the flag

Walkthrough

Reconnaissance

As always we identify the host’s IP with the “Netdiscover” tool:

So, let’s start by listing all the TCP ports with nmap.

To work more comfortably, I’ll put the IP address in /etc/hosts.

Enumeration

We access the web service and review the source code. We find the SSH user name.

It’s time to fuzzing! We used Gobuster and found several files. We examined the robots.txt and found a base64 text.

Exploiting

We use curl and add “base64 -d” to the command to decode the message in plain text. We get the first flag, the flag is the user’s password “itsskv“.

We access with the obtained credentials and read the file “flag2.txt“. Inside, we find a new code, this time it’s “binary code“.

We use the online tool “Cyberchef” and we get the second flag.

Privilege Escalation (root)

The root is quite simple (as the creator of the machine said it was easy level). The machine has a kernel vulnerable to “overlayfs: Local Privilege Escalation“. We download the exploit, compile it on the victim machine and run it. We get a root prompt and read our flag.

Author: David Utón is Penetration Tester and security auditor for Web applications, perimeter networks, internal and industrial corporate infrastructures, and wireless networks Contacted on LinkedIn and Twitter.