## Challenge
![The Buggy .Net challenge](https://www.sigflag.at/assets/posts/hitconctf2019/buggy.net.png)
## Initial reckoning
The web page shows a POST form that has a single text field called filename:
![Main page of Buggy .Net service](https://www.sigflag.at/assets/posts/hitconctf2019/buggy.net_page.png)
HTTP headers reveal that the server is a Microsoft-IIS/10.0 with ASP.NET 4.0.30319:
```httpHTTP/1.1 200 OKCache-Control: privateContent-Type: text/html; charset=utf-8Server: Microsoft-IIS/10.0X-AspNet-Version: 4.0.30319X-Powered-By: ASP.NET[...]```
Using "Default.aspx" as the file name in the form retrieves the page source ?... but wait, the source is available at http://52.197.162.211/Default.txt anyways.Also, using "Default.txt" as the file name in the form retrieves that file. Andobviously we cannot access the flag at neither "C:\\FLAG.txt" nor "..\\..\\FLAG.txt" ?.
## Source code
```csharpbool isBad = false;try {    if ( Request.Form["filename"] != null ) {        isBad = Request.Form["filename"].Contains("..") == true;    }} catch (Exception ex) { } 
try {    if (!isBad) {        Response.Write(System.IO.File.ReadAllText(@"C:\inetpub\wwwroot\" + Request.Form["filename"]));    }} catch (Exception ex) {
}```
## Interesting observations
My first though was something like "wtf? two separate try-catch-blocks?" Can we usethat for anything evil? Certainly `isBad` will remain `false` if the first exceptionhandler kicks in.
So how could we raise an exception in the first try-catch-block in order to permitpath traversal without raising an exception in the second try-catch-block?
- Can `String.Contains` raise an exception?- Can `Request.Form[...]` return anything that does not have a `Contains()` member method  but still concatenates as useful string later on?- Can `Request.Form[...]` raise an exception in some cases (particularly on first invocation) but not in others?
## Known bugs in ASP.NET 4.0 regarding request fields/forms?
So lets ask Google if there are any known bugs in ASP.NET ...
Interesting, [request validation has changed in ASP.NET 4.0](https://docs.microsoft.com/en-us/aspnet/whitepapers/aspnet4/breaking-changes#0.1__Toc256770147)(right, that's the version of our attack target!). This seems to have resulted in manycomplaints!
- [stackoverflow.com: A potentially dangerous Request.Form value was detected from the client](https://stackoverflow.com/q/81991/2425802)- [How to prevent the Exception "A potentially dangerous Request.Form value was detected from the clientside" when Template column is used.](https://www.syncfusion.com/kb/9213/how-to-prevent-the-exception-a-potentially-dangerous-request-form-value-was-detected-from)- [ASP.Net Error: A potentially dangerous Request.Form value was detected from the client](https://www.aspsnippets.com/Articles/ASPNet-Error-A-potentially-dangerous-RequestForm-value-was-detected-from-the-client.aspx)- [how to try-catch potentially dangerous Request.Form value exception](https://bytes.com/topic/asp-net/answers/316222-how-try-catch-potentially-dangerous-request-form-value-exception)
That did not help so far ... but then I stumbled upon this: [There's actually someone\*telling us that it might not be a good idea to ignore the exception that's thrown on **the firstaccess** to the `Request` collections.](https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2017/september/rare-aspnet-request-validation-bypass-using-request-encoding/)
\*) NCC Group is certainly not just someone, but to be honest, I did not really care who'sexploit I could recycle back then ?.
## Basic idea
The basic idea of that vulnerability is that, for POST requests, request validation prevents"dangerous content" (e.g. HTML tags or similar, such as `