aspnet-web-forms | security | web-config

Hunting security bugs in an old web application

In this post, I am sharing one of my security bug hunting experience in an older ASP.NET web form project.

Abhith Rajan
Abhith RajanOctober 09, 2017 · 4 min read · Last Updated:

Recently one of our old (~4 years or so) website faced a big security challenge. A similar situation we faced for the same website a long time ago when it initially deployed to the production server, that time the site was hosted in GoDaddy. Due to that incident, we moved the site to a custom VPS server with a third party company (where I worked during that time) and everything was fine after that.

This year we moved the website to Everleap and then recently the same problem happened, but after it happened, we brought the site back online within 5 minutes. Scheduled database backups and file backup were configured for the same which we do for all the sites we manage. Everleap have a cloud backup service which will take care of the periodic backup of files as well as the databases.

The site was configured to use Sucuri firewall but we didn’t have access to its portal, the client had. And IP security was enabled for the site so that only Sucuri IP’s are allowed to access the site. And the site content was managed by a custom CMS built by us in the old days, which hosted in a separate domain. After the issue stricken, we did couple of things,

  • Changed DB password.
  • Cms access denied.
  • Enabled all the Diagnostics modules in the Everleap control panel. (HTTP Logging, Detailed Error Logging, Failed Request Tracing).

We blocked the CMS access to identify whether the CMS or the site is being compromised. Then the next day evening, the same thing happened. So we concluded that the website is being compromised. Next steps,

  • Changed DB password again.
  • Code review

Code review

Code review went okay, the application was built on top of Web forms. And there were 3 areas where user input is taken,

  • Search
  • Email Subscription
  • Contact form

In which Contact form input didn’t touch database since only email alert configured. So for the other two server-side input validation tightened. And we tried some ethical hacking attempts but all of them blocked by Sucuri.

Checked the site security status in the Asafaweb and the result screenshot is given below,

And did the recommended changes for the Request Validation. All the updates deployed but in the same evening, it again happened.

Next steps

Since the project was kind of outdated, the manager asked us to estimate for the project migration into Umbraco since we couldn’t find anything suspicious in the coding, YET. So I delegated the estimation task to my colleague and started to look in the HTTP log downloaded from the Everleap.

Turning point

The log file contained 10k+ lines, my first search was for “POST” requests. While navigating through search results I noticed a get request with parameter contains web.config. The log for the same was,

2017-09-24 16:44:10 1990-15390 GET /PDF/DownLoad.aspx fileName=../web.config&X-ARR-LOG-ID=1c936dd2-8679-42ad-b77c-da8a938059a4 80 xx-xxxxx-x-x-x-x-x—xx—x-x

The above request was handled by the PDF download handler module, its intended function was to provide the requested PDF file.

So I checked the request handler and its code given below,

protected void Page_Load(object sender, EventArgs e)
    string fileName = Request.QueryString["fileName"].ToString();
    Response.ContentType = "application/octet-stream";
    Response.AddHeader("Content-Disposition", "attachment;filename=" + fileName);
    Response.TransmitFile( fileName);

The above code is doing its intended function very well but it can do unintended function as well if you know what I mean. To prove my point, I tried to invoke the same handler with the suspicious input and boom, here comes the requested file.

Final steps

Removed the request handler, changed DB password again. After the bug patched, I checked the HTTP log again in the next day and found out that there is an exact same request but this time instead of 200, a 404 response. And now weeks passed, website working fine, so far so good.

This page is open source. Noticed a typo? Or something unclear?
Improve this page on GitHub

Abhith Rajan

Written byAbhith Rajan
Abhith Rajan is a software engineer by day and a full-stack developer by night. He's coding for almost a decade now. He codes 🧑‍💻, write ✍️, learn 📖 and advocate 👍.

Is this page helpful?

Related SnippetsView All

Related ArticlesView All

Related VideosView All

Yubikey - The Ultimate Beginner Guide (How to Setup & Use)

Signal - the most secure messenger for everyone

Common API Security Pitfalls - Philippe De Ryck

Related Tools & ServicesView All

Have i been pwned?

Check if you have an account that has been compromised in a data breach