Accessing https://asdfasdf.redacted.com revealed a login form with a userid and name field. A user was required to provide these values in order to authenticate themselves to the web application. There was no registration form to provision credentials so I would have to focus on testing for unauthenticated bugs or try and find other endpoints on the subdomain. I decided to perform content discovery which would hopefully reveal some interesting directories and files. For this purpose, I utilized ffuf and wordlists taken from the SecLists Github repo. It didn’t take long for the tool to return some interesting results ;

I was skeptical at first as to whether I could actually access the subsequent directories given the 301 HTTP response code and the fact that access to such folders was often properly restricted on targets that I’d encountered over my bug hunting journey. To my surprise, visiting each endpoint that I had discovered through directory brute-force allowed me to directly access all the available content underneath those directories. The following ones were of particular interest since they contained everything from uploaded files, backup files, and web application source files.

/upload
/UploadFile
/Application
/Bak
/init
/offline

While browsing through the various directories, I came across a aspx endpoint that could be used to upload an excel sheet with sales order data to the web application. I quickly discovered that I could upload files with a different extension. The uploaded files were accessible in /upload folder that I’d discovered earlier. I tested the upload functionality by creating a file in notepad, added some text to it, and saved it with a txt extension. I then uploaded the file to the web application and was able to access it in the upload folder.

Before discovering the endpoint that was vulnerable to unrestricted file upload, I reported the directory listing vulnerability to the program given the sensitive nature of content that was discovered in those directories. The next step involved uploading an ashx file to the web application and yet again, this got successfully uploaded to the relevant folder. Finally, I could use the web shells from this repo to execute code on the vulnerable server. After confirming this, I submitted a separate report for RCE to the program.

Hopefully, this write-up has provided some insight on aspects to look out for while testing for bugs on programs that are running Microsoft IIS.

As always you can reach out to me on Twitter if you have any questions. Till next time, happy hacking!