Info

This post was originally published on my previous blog (poc-server.com/blog) and has been migrated to my current platform for archival purposes. Be advised that due to software transitions and evolving best practices, the formatting and content may not align perfectly with my newer posts.

TL;DR Link to heading

Most ASP.NET MVC sites have ‘customErrors’ on ‘RemoteOnly’, since this is default, which returns custom error pages outside of localhost (remote). But while on localhost, it returns the full error information including stack trace, version numbers and more (for debugging purposes). Since some SSRF’s are limited to internal addresses without the port, this can be used to retrieve full error info by requesting a localhost URL which produces an error. e.g. https://localhost/<>

General Link to heading

By default, the customErrors option is set to RemoteOnly in the web.config. This means that if the site is running on localhost, it will trow detailed error pages. While if it is running outside localhost, it will return custom error pages. We can abuse this by using that one SSRF bug where we couldn’t request much more then localhost since the ports where blocked, or for some other reasons. First lets start by requesting ‘localhost/<>’ to see if custom error pages are on or not. Normally, ASP.NET blocks this request since it thinks it is potentially dangerous. So just check if you get the default error page or a custom one. Default error:

stacktraces

After this we need to find a URL that produces an error. We can pass strings to parameters that expect an integer for example. Be creative! Next off, after we’ve got an URL, we can request this URL and hope the response contains the detailed error message with stack trace and some other juice info. Some nice example of this is to use it to get the original error from a potential SQLI, while the page normally trows a 500 page.

Scenario Link to heading

In my case, I used this technique to help me further with a SQL injection that I found, but where I couldn’t figure out where the injection was in the query. The SQL injection was in a POST to a web-service. luckily the web-service also accepted GET requests, so I created an URL with the GET parameters. Next off I fed the URL to the SSRF bug and retrieved the actual SQL error. This way I knew where the SQL injection took place and after some thinking and trying, I figured it out, created a POC, and reported the issue. 😉

Extra Link to heading

For more info about the custom error pages in ASP.NET, visit https://msdn.microsoft.com/en-us/library/h0hfz6fc(v=vs.85).aspx