Full Trust Asp.Net Security Vulnerabilties, and Microsoft's current position

Email I sent (on July 8th 2005) to a Microsoft Product Managed (of Web Platform and Tools) who (at the time) was still talking to me

---

From: Dinis Cruz [1] Sent: Friday, July 08, 2005 11:45 AM To: Shawn Nandi Cc: Bill Gates; Steve Ballmer; Scott Guthrie; Mike Nash; [email protected] Subject: Full Trust Asp.Net Security Vulnerabilties, and Microsoft's current position

Hello Shawn (and Bill, Steve, Scott and Mike)

[note: this email was written before yesterday's events in London, which is where I live and could had been affected if wasn't late for work]

To your question: have you had a good look at Visual Studio/Whidbey Beta 2.0, the answer is: Not really (just a install on a VPC and a quick look at some of the new security features which I showed the students of the ASP.NET Security courses that I wrote and teach).

And (correct me if I am wrong), but I didn't see any major changes in the .Net Framework between 1.1 and 2.0 (the available documentation seems to support this view).

But I have to say, that at the moment, I have no motivation to look at it in more details, since I am truly disappointed with your (Microsoft) attitude to Asp.NET security and your willingness to NOT look/discuss/acknowledge anything that doesn't fit your current definition of 'insecure software'.

By keeping a low profile with these issues and giving you the time to deal with them properly/timely, I fell that I am promoting insecurity and not helping fellow developers/sysadmins whose systems are being compromised today. Remember that I have been calling your attention to the Security Vulnerabilities with Full Trust ASP.NET since (at least) October 2003.

Every time you miss the opportunity to acknowledge the problems and deal with the issues in an honest and professional way, my motivation to help reaches a new low.

The latest ones were:

• My nth presentation about Full Trust ASP.NET in(Security) where the audience:
  • falls from their chairs when they realize what can be done in Full Trust ASP.NET (and how insecure they are)
  • says: "But.I was under the impression that IIS 6.0 and ASP.NET were VERY Secure"
  • says: "But. Why doesn't Microsoft acknowledge these problems and starts to work with the community on a solution?"
  • says: "

I agree with you (Dinis) that this is a major problem, but I don't have support from my managers (i.e. pressure from the clients) to write Partially Trusted ASP.NET code mainly because
 a) nobody is asking for it,
 b) most people don't realize what are its dangers
 c) I don't have any marketing incentive to do it (since Microsoft doesn't publicly acknowledge these vulnerabilities)
                   "

• Your complete LACK of respect, attention and acknowledgement for the hard (unpaid) work that we are doing at OWASP .NET and the following tools that we have developed:
  • ANSA (Asp.Net Security Analyzer)
  • SAMSHE (Security Analyzer for Microsoft's Shared Hosting Environments)
  • ASP.NET Reflector
  • DefApp (Asp.Net web application firewall)
  • Beretta (Web Application Black Box vulnerability scanner)
  • IIS Metabase Explorer
  • Security guide for secure IIS 5.0 shared hosting
  • Owasp Top Ten ASP.NET Security vulnerabilities (new project)

• Your current lack of interest (and vision) in not using the opportunity of the 2.0 release to really make a difference and to make it into an event which would 'force' all developers into creating Partially trusted ASP.NET applications (i.e. change the paradigm!). I have said it before (see my Owasp London Conference presentation) and will say it here again: I don't think that you should release 2.0 without solving the current Full Trust Asp.Net issue (and without widespread awareness of the need to create secure partially trusted Asp.Net applications))

• The continuous complete silence of the Full Trust ASP.NET vulnerabilities that I have been talking about. Here is just a reminder of these issues:
  • The IIS Security Token issue
  • The fact that any member of the IIS_WPG can read and decrypt most (if not all) secrets stored in the metabase.xml (including usernames and passwords)
  • the fact that Application pools provide NO ISOLATION for ALL application pools executed under the same identity and limited isolation between application pools executed with different identities
  • the fact that Windows 2003 is not able to create a secure runtime environment for processes executed under IIS_WPG (account which is able to: list usernames or running services or running process, access the TCP APIs to perform internal/external attacks, perform internal brute-force password attacks, etc, etc, etc. )
  • How bad this is in IIS 5.0
  • The fact that most published vulnerabilities included in your monthly vulnerability disclose CAN BE EXPLOITED from an ASP.NET script
  • The fact the Full Trust ASP.NET allows TOTAL control over the running process and allows a malicious attacker (with ability to run a script on the server) to upload malicious code and execute it on the server (this one you almost acknowledge in some of your documentation)
  • The fact that there is almost no difference (to the security of all hosted websites) between 1) running application pools under a normal windows account and 2) running application pools under SYSTEM (since the security of both environments assume that no malicious Full Trust ASP.NET code will be executed in that server)

Note that I am not saying that you are lying in public. What you chose to do, is to be very economical with the truth and only publicly acknowledge what you HAVE to acknowledge, not what you SHOULD acknowledge. For example:

• Your 900111 KB article "A forms authentication cookie can be used to authenticate to a forms authentication ASP.NET application after the FormsAuthentication.SignOut method has been called" which describes a serious vulnerability in very economical way and doesn't fully explain what the REAL consequences of that issue are.

• The tacit support for the irresponsible, immoral and probably (due to the latest laws that have been passed in the U.S.) illegal situation created by the Hosters that run their client's websites in Full Trust

• Your inability to admit vulnerabilities without being forced to (for example: the BCentral massive insecure hosting environment that existed for more that one year and then for additional six months after I reported the problems and placed quite a bit of pressure on Michael Howard to resolve it; the ASP.NET XSS vulnerability publicly disclosed but never created much debate/outcry; the vulnerabilities that you ARE aware internally but don't publish until there are public exploitation or exploit code published)

• Your (Microsoft) inability to read and discuss code that I have written and submitted freely (for example the code for the Permcalc batch analyzer that I wrote (and the Owasp .NET security tools)). I have to say that one was hard to swallow. Especially, because I offered to release this code under any license that you where comfortable with, and still there was no solution (it's almost as if you don't think that my code is worth the effort!). Is this how you foster your developer community? How you make people happy to help you for free and dedicate their own research time to improving the security of your products?

Anyway, I am now convinced that you (Microsoft and Mr. Gates) don't understand the security issues that we face today (or maybe you do, but are trying to ride-the-storm). It seems that you are still thinking in terms of Buffer Overflows, and Virus, and Worms, and Marketing gains, and Vulnerability-counts, and 'making sure that Windows Product X has less public vulnerabilities than Free/Open Source Software Product Y' (reference to your short-sided vulnerability count war that you are currently fighting (and winning) with the FOSS world, which is good for short-term marketing, but very bad for long-term security)

Remember that you should aim to be 2 to 5 years ahead of the current threats (not 2 years behind)

We (as a society and IT industry) cannot afford to live in a world where the security of our systems depends on our ability to avoid malicious code from executing inside those systems. Malicious code will find its way into our systems, either placed by malicious users with authorized access, or via an exploitation of vulnerabilities in the underlying OS or Support Applications (web server, .NET framework, etc...). The question is: "How can you limit the damage caused by malicious code?" That is mainly dependent on how robust and secure the run-time environment used to execute the malicious code is. And with Full Trust ASP.NET (or .NET console/windows applications) there is no protection to everything that the impersonated user has access to, and very little protection to the OS itself. As I said before, I think that CAS (Code Access Security) is one of the best ideas that come out of Microsoft and one that (if fully implemented and supported) could solve this problem.

You are still in the 'infrastructure Security Paradigm' instead of being on the 'Application Security paradigm' (I'm including things like OS, web servers, database servers in my definition of 'infrastructure'). And you are lucky that your (corporate) clients are still being mainly attacked by 'infrastructure' issues, instead of 'Application' issues. But 'Application Vulnerabilities' are one of the next big insecurity waves, and things like 'Full Trust ASP.NET' make it a disaster waiting to happen.

In other words: You are still trying to stop the barbarians at the gates, but (in 2005) the barbarians are already inside (the current Spyware wave is just the warm-up for what is coming).

Please don't read this as 'Microsoft is not investing heavily in security' and 'Microsoft is not improving the level of Security of their projects'. You ARE spending quite a lot of money in security and you have made good improvements (XP2 for example or IIS 6.0 (when compared with IIS 5.0 and viewed in isolation). But what you have done is just a fraction of what you have to do. At the moment, I think that most of the time you are climbing the wrong mountain.

The bottom line is, How many companies (in percentage) today develop Applications designed for Partially Trusted Asp.Net Environments, and how many ISPs (in percentage) run their co-hosting servers with ONLY Partially Trusted Asp.Net websites?

Coming back to my answer about I haven't spent much time on .Net 2.0.

Firstly, I have been very busy with my other (paid) projects:

• Working as a security consultant for a major bank (100,000 employees) in their Global Security Division where I am creating global security standards for the bank and performing security audits (called Penetration Tests) for all types of applications and platforms (if it makes you feel better, Java, J2EE, WebSphere and IBM also have similar security problems :) )
• Co-Writing another ASP.NET Security course (this is the 3rd one) for a US company
• Writing security tools and doing security research for a Major Security Company

Secondly, because I have dedicated (and will spend) most of my time available to research to other more productive and rewarding projects:

• Being the Owasp .NET Project Leader and developing/supporting Owasp .NET projects
• Writing a C++ injection module (based on Detours) which hooks win32 API functions and allows monitoring and manipulation of an Application's (typically a Fat Client): Socket's communications, GUI (i.e. enabling all buttons, menus, etc..), security identities and string manipulations.
• Writing a couple extensions to Fiddler to help my PenTesting projects (and to perform Low-Hanging fruit detection)
• Trying to get my head around Mono, since I think that they will be able to deliver a secure ASP.NET run-time environment, faster than Microsoft will.
• Writing my 'Rooting ASP.NET (building a CLR RootKit)' presentation for the OWASP October conference in Washington (the idea is to use the RootKit concepts to the CLR and .NET Framework
• Learning Phyton (and Ruby) and porting MetaSploit to ASP.NET (and writing some specific ASP.NET exploits)
• Researching vulnerabilities in ASP.NET/IIS 6.0 such as:
  • Authorization issues with out-of-process Viewstate (both in external local process and in external database)
  • Uses of the SYSTEM Identity token which is available in the W3WP process
  • CAS Sandboxes. Mapping of what exactly can be done in each available Partially Trusted environment, and identify vulnerabilities in them. The more I look at it the more I think that there are blind spots which will allow a partially trusted code to 'jump-out' of the given environment (for example the finally issue which would cause an elevation of privileges due to an exception management vulnerability)
  • How to host a custom version of the CLR in a different process and use remoting to securely communicate with the main .Net process (this could dramatically improve security and performance of untrusted Full Trust ASP.NET code)
  • What is the implication of reusing machine.keys by common applications and in clustered servers?
  • Race conditions inside the .NET Framework (for example in Handle (re)usage)
  • Vulnerabilities created by lack of input validation in Managed to Unmanaged transitions (the managed to unmanaged string issue)

Sorry for this long email, but these are things that I have been waiting to say to you but haven't had the time to sit down and write them.

Please note that this is nothing personal against you (Shawn) or Microsoft. I think that you and the other members of the ASP.NET team are trying your best, and I have no doubts that you are a very professional and knowledgeable team. I just think that you are making a serious mistake by not addressing these issue(s) properly.

Ultimately, I am just trying to help my customers to create and host security ASP.NET application since that is why they hire me for.

So where do we go from here? It's your call. You know what I think and what I would like to you do.

Best regards

Dinis Cruz .Net Security Consultant

Note: In principle, I will be in Seattle from July 11th till July 17th (delivering an ASP.NET Security course and doing some consultancy), so maybe we should meet and discuss these issues?