I’ll let Francois’ comment explain the problem (emphasis mine):

Tuesday, July 08, 2008 4:16 PM by Francois Ward

Hmm, I didn’t look into it much, but is that -safe-? I mean, if the variables in the index function are filled up automatically… it would be ok if it was only one type (all cookies, or all server variables), but since you can mix and match, whats to present me from forging a request with a cookie with the same name as the server variables?

I mean, it is already possible to forge anything client-related, for obvious reason… but forging info that potentially come from the server? That seems…awkward…

(again, keep in mind this is just my first reaction, maybe if I think it through I’ll realise what I just said is totally stupid )

Like Francois said, cookies are easily forged client-side anyway, but most developers tend to rely on the truthiness of our server variables, specifically those that don’t come over in the HTTP request. Let me demonstrate how the issue plays out.

For our example I have created a method on the HomeController named Test that takes four parameters that match server variable names. Below are the descriptions of each from MSDN’s IIS Server Variables article:

• REMOTE_ADDR
  MSDN Says, “The IP address of the remote host that is making the request.”
• LOGON_USER
  MSDN Says, “The Windows account that the user is impersonating while connected to your Web server. Use REMOTE_USER, UNMAPPED_REMOTE_USER, or AUTH_USER to view the raw user name that is contained in the request header. The only time LOGON_USER holds a different value than these other variables is if you have an authentication filter installed.”
• REQUEST_METHOD
  MSDN Says, “The method used to make the request. For HTTP, this can be GET, HEAD, POST, and so on.”
• SERVER_NAME
  The server’s host name, DNS alias, or IP address as it would appear in self-referencing URLs.

My biggest concern is LOGON_USER. As described by MSDN this variable normally stores whatever the value of REMOTE_USER, UNMAPPED_REMOTE_USER, or AUTH_USER is, except when you have a third party authentication filter installed. The purpose of these authentication filters is to map the value of one of the above three request variables to a different local name. For example, you may be using a filter to map “DOMAINTroyGoode” to “DOMAIN-DMZStandardUser” and to map “DOMAINScottGuthrie” to “DOMAIN-DMZAdministrator”. If you are using such a filter and then add LOGON_USER as a parameter to one of your actions, you are suddenly opening up the ability for anyone to circumvent that authentication filter.

Here is the action I have created:

   1: public void Test(   string REMOTE_ADDR,

   2:                     string LOGON_USER,

   3:                     string REQUEST_METHOD,

   4:                     string SERVER_NAME )

   5: {

   6:     Response.Write(

   7:         string.Format(  "<div>Remote IP: {0}</div>" +

   8:                         "<div>User: {1}</div>" +

   9:                         "<div>Request Method: {2}</div>" +

  10:                         "<div>Server Name: {3}</div>",

  11:             REMOTE_ADDR,

  12:             LOGON_USER,

  13:             REQUEST_METHOD,

  14:             SERVER_NAME

  15:         )

  16:     );

  17: }

And here is what this action will output without any fiddling:

Now I’ll tweak the Url a bit:

First Url:

http://localhost:63260/Home/Test

Second Url:

http://localhost:63260/Home/Test?REMOTE_ADDR=Any.IP.I.Want&LOGON_USER=YourDomainAdministrator&REQUEST_METHOD=POST&SERVER_NAME=microsoft.com

And voilà, mischief achieved:

Now I’m no Kevin Mitnick, but I can assure you that if I can come up with something like this in an hour or so, a dedicated hacker that is probably far smarter than I will likely give you a lot of heartache if you make use of this feature. Have any “developer mode checks” that check for 127.0.0.1 or localhost? Have any filters to try and prevent GETs on certain actions? Relying on server variables passed in to your actions would make those scenarios (and many others) unwise.  Just say no.

In my opinion this feature (the server variable portion) should just be removed from the MVC framework entirely or something should be put in place to prevent overwriting parameters named the same as a server variable.

I would advise anyone running BlogEngine.net to immediately go to Danny's blog and download & install the fix.

The faster we can get word out about this, the faster we can shut down this particular attack vector, so please try and get the word out to any BlogEngine.net users you are aware of and please kick Danny's post at DotNetKicks.

Thanks Danny!