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,
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);
Response.End();
}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.
