Note : This article was inspired by content from Pwned Labs. Special thanks to Pwned Labs for providing insightful resources and awesome learning experience for learners.

Lab Link : https://pwnedlabs.io/labs/bypass-azure-web-app-authentication-with-path-traversal

Overview -> On an engagement for our client Mega Big Tech, we used a custom phishlet and successfully performed an Evilginx man-in-the-middle attack to gain valid company credentials. You are tasked with demonstrating the impact of the breach and gaining access to business critical information.

For this lab we have been given credentials to start with ;

Password: **********
Username: [email protected]

We can go ahead and use the below command to authenticate to Az Services for further enumeration

Connect-AzAccount

We can check the resources our current user has access to by using the below command

PS sec-fortress@Pwn-F0rk-3X3C /home/sec-fortress/Az_lab> Get-AzResource  

## Output

Name              : megabigtech-dev
ResourceGroupName : megabigtech-dev_group
ResourceType      : Microsoft.Web/sites
Location          : eastus
ResourceId        : /subscriptions/ceff06cb-e29d-4486-a3ae-eaaec5689f94/resourceGroups/megabigtech-dev_group/providers/Microsoft.Web/sites/megabigtech-dev
Tags              :

We have got access to the resource group named megabigtech-dev_group, which serves an Azure Web App. We can go ahead and get the enabled host names.

PS sec-fortress@Pwn-F0rk-3X3C /home/sec-fortress/Az_lab> (Get-AzWebApp -ResourceGroupName "megabigtech-dev_group" -Name "megabigtech-dev").EnabledHostNames

megabigtech-dev.azurewebsites.net
megabigtech-dev.scm.azurewebsites.net

According to pwnedlabs ;

Any time an app is created, App Service creates a Kudu companion app for it that allows us to manage the app instance, including getting terminal access. The location of this app can vary depending on the configuration.

  • https://<app-name>.scm.azurewebsites.net (if the app isn’t in an isolation tier)
  • https://<app-name>.scm.<ase-name>.p.azurewebsites.net (if the app is internet-facing and in an isolated tier)
  • https://<app-name>.scm.<ase-name>.appserviceenvironment.net (if the app is internal and in an isolated tier)"

Further Explanation ;

Accessing the kudu Az App service we have an authorization error for our present authenticated user

However accessing the other host name gotten from our previous enumeration we have a functioning website

Clicking the “Status” session as shown in the above image we are referred to a URL with a parameter.

It is worth checking for LFI/Path Traversal vulnerabilities, Go ahead and intercept this request with burpsuite and send the request to the “Repeater” tab.

Firstly we can confirm if we truly have a path traversal vulnerability, by changing the value of the endpoint as shown below.

Instead of ../latest we can use the URI location ../status.aspx to see if this works and as shown below we have the following output confirm that this vulnerability exists

Since the path in the URI worked let go ahead and fuzz for other paths, we can do this using burp also by sending the request from “Repeater” to “Intruder” and highlighting the full path including the parameter to be fuzzed

For the wordlist you can go ahead and use this as provided by PwnedLabs, Also go over to the “Options” tab and enable both options as shown below to avoid future errors.

Running the attack as shown below and filtering by “Length” we can see that we have two 403 status code prompt meaning the paths exist but we don’t have permissions to view this paths.

Since we have a path traversal vulnerability and reading files via this way doesn’t imply whether we have permissions to read the file or not, nevertheless we can still read the file, sweet!!

We can go ahead and fuzz for files in the /admin endpoint, since it is the most juicy, don’t forget to append the .aspx extension as this server is an ASP.NET server as shown in the below screenshot

Once implemented you can go ahead and start the attack, just to understand this more, the below image should help ;

Filtering by “Status Code” we can see that we successfully have access to the /admin/login.aspx endpoint as shown in the below screenshot

We can go back to the repeater tab and try to read the source code of this login file as shown below

We are referred to ../admin/login.aspx.cs so let go ahead and see what we have there, whereas sending the request we have hardcoded credentials ;

We can navigate to the login endpoint and login with the credentials we have at hand

Be cool ⋆˚🐾˖°