## 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:

```http  
HTTP/1.1 200 OK  
Cache-Control: private  
Content-Type: text/html; charset=utf-8  
Server: Microsoft-IIS/10.0  
X-AspNet-Version: 4.0.30319  
X-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.
And  
obviously we cannot access the flag at neither "C:\\\FLAG.txt" nor
"..\\\\..\\\FLAG.txt" ?.

## Source code

```csharp  
bool 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 use  
that for anything evil? Certainly `isBad` will remain `false` if the first
exception  
handler kicks in.

So how could we raise an exception in the first try-catch-block in order to
permit  
path 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 many  
complaints!

\- [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 first  
access** 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's  
exploit 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 `

Original writeup (https://www.sigflag.at/blog/2019/writeup-
hitconctf2019-buggy-dot-net/).