Dear Miss Bradley
Thanks for your comment, to which you make 3 claims:
1) we should have send this email to Microsoft, before we posted it
in such a public forum
2) that publishing details of such vulnerabilities in public is
dangerous
3) that I should act more responsible so that the whole industry
gains
I do agree that when a security consultant finds potential security
problems with software as widely used as Asp.Net, it must act
responsibly and provide details of the vulnerabilities discovered to
the software manufacturer. With this in mind, I would like to tell you
what happened on the last 6 months between us (DDPlus) and Microsoft:
- Jan-May 2003 : We (DDPlus) worked on a couple of security
projects that involved IIS and FPE2002 (FrontPage Extensions 2002) and
we discovered that there where serious security problems with the way
ACL permissions are managed and changed by FPE2002
* During this period I participated in a couple of online
discussions that where talking about the vulnerabilities that we
discovered (some posts where from 2002, and nothing had been done
since to fix the problem)
- 16/May/2003 : Sent an email explaining the problems that we
found to 22 Microsoft contacts (some I had meet in Microsoft
briefings, some I found in security focused online newsgroups. This
list included the UK's Microsoft Customer Services).
- 90% of my emails where ignored or produced no relevant
answers from those Microsoft staff (including the UK Microsoft
Customer Services, which I never received a reply)
- 11/June/2003 : Since the email exchange with the few
Microsoft contacts that replied back was going nowhere, I sent an
email to the ‘Microsoft Security Response Center'
(
[email protected]) detailing the problem and asking for
Microsoft's solution for the IIS 5.0 FPE2002 vulnerability we
discovered (although it affected all IIS 5.0 systems with FPE2002
installed, it is a very serious problem for ISPs providing shared
hosting environments). We mentioned on this email to Microsoft
Security Response Center that we had just produced a Security guide
for IIS 5.0 (sent attached) and wanted to include Microsoft's solution
in the final version.)
- 11/June/2003: posted on some newsgroups the fact that we had
produced a security guide for IIS 5.0 and that we would send it on
request. Please note that this guide contained a solution for the
problem (i.e. vulnerability) that only the ‘unofficial' Microsoft
contacts later confirmed its existence, but:
- so far (20/Oct/2003), Microsoft never provided a Public
solution for the vulnerability, which is probably caused by the fact
that:
- so far (20/Oct/2003), Microsoft never Publicly admitted
that this was a security problem (at least for ISPs)
- 13/June/2003 : Some of my original contacts finally started
providing relevant information. They confirmed to me that it was a
problem but that Microsoft had no plans to fix it.
- In one email their words about this problem where:
"...Yes, unfortunately I am saying that there is not solution for the
problem in IIS5. It is acknowledged as an issue, and it *might* get
fixed, but there is no firm plan to fix it...".
- Regarding the fact that apparently windows 2003 had a
solution (the use of Application Pools in IIS 6.0) they said
"...Unfortunately, we don't currently have a plan to integrate this
into IIS5. Actually there has been talk of it, but there are no firm
plans and definitely not a timetable. If it's any consolation you are
one of many who have requested this, so it might happen. The
feasibility is being looked at right now..." and "...This was fixed on
Windows Server 2003 as described in the article but the problem
existed and was well known for previous versions. The solution for
IIS 5 has been to disable things like the File System Object, Perl
scripts and shared FTP access to sites in shared hosting boxes. It's
not an issue on a dedicated box..."
It is worth pointing out that our efforts are targeted to a Shared
Hosting environment, a situation where dozens (or hundreds) of
websites are hosted on the same server. This is clearly the situation
of ISPs, but also affects companies that have dozens (or hundreds) of
users editing their websites using FrontPage (for example:
universities, major corporations, web developers)
And I would challenge you to find an ISP that provided windows shared
hosting services with FPE2002 and .ASP scripting enabled, that had
disabled (in their servers) the File System Object or FTP.
As you will see later on, this is a common response tactic by
Microsoft, their answer to a problem is: "If you disable this
‘feature', the vulnerability will be resolved". The problem is that in
the ‘real world' of (for example) ISPs, these ‘features' cannot be
disabled, because normally they are the reason why the users are using
the Microsoft development platform. This means that although
Microsoft's response was technically correct, it didn't address my
issue, since I was specifically talking about shared hosting scenarios
such as ISPs.
- 17/June/2003: I receive an email from the Microsoft Security
Response team saying: "… We are having trouble identifying the
specific vulnerability you are leveraging to exploit the system
remotely. Right now it looks like you are gaining system access due
to IIS configuration issues and insecure .asp pages ..."
- Basically what Microsoft is saying ‘officially' is: "We
(Microsoft Security Response Center) don't think that what you
(DDPlus) found are vulnerabilities, since you are just creating
‘insecure' pages containing normal .asp code. So if you don't allow
that ‘insecure' code to be uploaded to your server, you will be ok
(i.e. secure)"
- Which again, is technically correct, but they are
assuming that I would be able to control the code uploaded to my
server, which is something impossible to do by an ISP.
- 20/June/2003 : Microsoft Security Response team sends me a
link to a white paper that doesn't provide a solution to the
vulnerabilities identified
- 30/June/2003: I send a long email to Microsoft Security
Response team explaining:
- (again) what was the vulnerability that I was talking
about and the fact that one of his colleagues at Microsoft had already
confirmed that it was a problem
- That I was specifically talking about shared hosting
environments (such as ISPs) and not dedicated boxes
- That I knew about that white paper and that it is was
not relevant
- What I thought should be Microsoft's next steps: 1)
publicly acknowledge the problem and 2) work with the ISPs currently
providing shared hosting services to fix the servers hosting hundreds
of thousands of websites.
- 01/Jul/2003: received an interesting email from one of my
Microsoft contacts: "…I looked a bit more at your paper and while I
can't comment in detail or officially endorse it in any way, I think
it summarizes much of the common wisdom for securing IIS on Windows
2000 based on what I've seen others do to secure the platform. I
think you spent too much focus on the vulnerability and impact rather
than showing how to secure the OS and webserver up front, but I think
you may have been trying to get administrators attention on why they
need to do this. If I wrote such a document, I'd probably come in
with a different approach – indicating that IIS/Windows 2000 can be
secure as long as you pay attention to the details, then providing the
steps for making it secure. Still, I think it's always good to get
out this information to customers no matter what the format if it
helps them make their machines more secure. …"
- This shows very well what is Microsoft's current
position on security: "We will tell you how to make it secure, but we
will not tell you how the system can be compromised (i.e. what are the
vulnerabilities)", which create a couple on interesting scenarios
1. If one doesn't know the risks, how can one know, when
one is secure?
2. How can one protect what one doesn't know?
3. What happens when Microsoft knows the existence of an
vulnerability but doesn't disclosed it to their users? Nor it advises
those users of the potential problems?
4. What happens when the vulnerability is also a feature?
- What is interesting about this comment is that Microsoft
does think that creating documents such as the one we created is a
good way to raise awareness to the existent security vulnerabilities
(note that our document contained a description of the problems, but
is also provided a step-by-step guide to build a secure server)
- 01/Jul/03: I sent to Microsoft our new security document
"Security Vulnerabilities in Asp.Net" which contained an analysis of
what we considered to be security problems when Asp.Net was used in
shared hosting environments (such as ISPs).
- The document contained detailed information about these
security problems with Asp.Net: WSH and FSO, Authentication and
impersonation, WMI – Windows Management Instrumentation, ADSI – WinNT
accesses, ADSI – LDAP accesses, Internal Port Scan, W32 DLL calls,
RevertToSelf()
- 08/Jul/03: Microsoft Security Response Center finally responds
to the issue raised in my 11th June email:
"... In your initial E-mail to us you presented a whitepaper, that
after clarification revealed one core issue--the Network+Interactive
role that is shared in FPSE2002 and IIS5.0..."
"... Currently, for FPSE2002 customers running Microsoft Windows 2000,
an immediate mitigation is to disable FSO and WSH as presented in
http://www.microsoft.com/technet/tr...et/prodtechnol/sharepnt/maintain/stssecur.asp...
"
"... Dinis, we take every security incident seriously, and our primary
goal is to protect our customers. Here at the MSRC we work diligently
to respond to vulnerabilities, and are dedicate to making sure that
each one is resolved. While we normally do not review white papers,
we've taken time to review each paper that you've presented to us and
extrapolate vulnerabilities and respond to them in turn. Fortunately,
not every report is actually a vulnerability. Often there are cases
where a series of misconfigurations, or lack of best practices can
lead to an suboptimal security situation for a customer. In that case
we make every effort to provide detailed security guides and
documentation to provide guidelines for successful employment of our
products..."
So basically Microsoft Security Response Center said "We know it is a
problem and the solution is to disable FSO and WSH". This does solve
most problems identified, BUT:
1) as said before no ISP that I know provides shared hosting
services with FSO (File System Object) disabled. And the main reason
is because most .asp based websites would break if that object was
disabled.
2) the WSH (Windows Script Host) contains less side effects when
its disabled. Actually it should had never been enabled by default in
the first place! The WSH object allows the execution of commands on
the server! This is one of the most serious vulnerabilities that we
found. Now the problem here is that I have read most books that
explain IIS 5.0 security and .asp security (I also have probably all
‘Hacking' books published today) and I never found the WSH identified
as a serious vulnerability and the only times that I saw the
recommendation about disabling is in 1 paragraph hidden in the middle
of huge articles (which went completely unnoticed by the industry).
The WSH is very dangerous for another reason:
In IIS 5.0 (Windows 2000) If the WSH is not protected and the web
server is configured to run in "Low process" application mode, then
the commands will be executed under the rights of the system account,
which means the script could easily create an administrator account,
format the hard drive or access any website's data hosted in that
server. And to bring this home, I have found several major ISPs that
run their websites in "Low (IIS process) "application mode with WSH
enabled!.
3) but the main question is: "What do you do, if you can't disable
FSO and WSH?" Well if you follow the guidelines from the security
guide "Secure shared hosting with IIS 5.0", published by DDPlus (that
is us) then you would still be safe! And this lead me to my next point
which is:
4) Microsoft Security Response Center, didn't review our white
paper (as they claim), because our white paper contained much more
information to which they never commented, namely:
* What was their opinion on our solution? What is a viable
and scalable one?
* What could be done to make it more robust?
* What really happens when FPE2002 using in conjunction with
SharePoint team services, is upgraded with the Office XP service pack
2? Did that really solve the problem?
* What was their opinion of the 2 custom security templates
we created (based on Microsoft's HiSecWeb.inf and NSA's
W2k_server.inf) the ‘DDPlus_Mst_hisecweb.inf' and
‘DDPlus_NSA_w2k_server.inf'
* What was their opinion on the proposed IPsec policy
(‘DDPlus_ipsec_policy.ipsec') which aimed to close all unnecessary
ports and communications?
* And if the information contained in the security guide was
accurate and would help ISPs to secure their servers, why didn't
Microsoft publicly acknowledge the guide or released a similar one?
At this moment in time (08/Jul/2003 , one month after I sent them the
information) from the point of view of the Microsoft Security Response
Center this case was closed. I haven't received any more information
from them regarding this issue.
Of course that meanwhile most ISPs where still vulnerable (except the
ones that also found the solution or, the ones that read our security
guide and used it to fix their security problems)
- So now Microsoft's attention was focused on the document
‘Asp.Net Security Vulnerabilities' which we never published publicly
(we only distributed it to known contacts or to who had requested the
original guide). As I mentioned before this document advised Microsoft
Security Response Center for the following security problems with
Asp.Net when used in shared hosting environments:
- WSH and FSO
- Authentication and impersonation
- WMI – Windows Management Instrumentation
- ADSI – WinNT accesses
- ADSI – LDAP accesses
- Internal Port Scan
- W32 DLL calls
- RevertToSelf()
- 17/Jul/2003 : I received Microsoft's response to the Asp.Net
document:
{Beginning of Microsoft's email}
"…. We've taken a look at the issues you've presented in your
whitepaper. Thank you for your patience, we did a deep analysis of
each issue and that took some time. In the end, we've determined
that, while you are showing interesting attack vectors, they all
require full trust, and as a result are not new vulnerabilities. If
you have full trust then you will be able to leverage that trust in a
negative manner, as you have indicated. People that can execute
arbitrary code can always try things like the attacks that you
document; it's one of the costs of running arbitrary full trust code
on someone else's behalf. …"
"…The use of the V1.1 release of the .NET Framework and code access
security will mitigate these threats that result from running code in
full trust. Admins that choose to run applications in full trust can
greatly mitigate what they can do by running them as an appropriately
unprivileged account…."
" …. In order to provide you with as much detail as possible, I've
included a point-by-point analysis of each of the issues in your
paper.
" - WSH & FSO: This requires the use of COM interop, which
also requires full trust"
" - Authentication & Impersonation: this is basically someone
running in a web process trying to guess passwords using whatever
mechanism they might use (e.g. LogonUser or ADSI binds or WMI or
whatever). All of these things require full trust today: LogonUser
requires a platform invoke, System.DirectoryServices requires full
trust, as does anything in native WMI or System.Management.dll (the
managed WMI wrapper)"
" - WMI: Use of unmanaged WMI through scripting or interop
requires full trust."
" - ADSI: Winnt Provider, requires full trust, whether via
interop the activeds.dll or System.DirectoryServices"
" - ADSI LDAP Provider: same as above"
" - Port scans: Use of sockets in form from managed code is
controlled via permissions. If desired, admins can grant no network
access, HTTP access to selected URLs, or any set of socket access. "
" - RevertToSelf: full trust code can always do this (as can
COM objects in ASP or wherever else). As a side note note for the
external, impersonation is not effective as an isolation mechanism
even without RevertToSelf—merely switching threads will demonstrate
this. Use of code access security or process/account isolation is
required."
" - Arbitrary native code in DLLs: requires full trust to do
either interop or p/invoke..."
{End of Microsoft's email}
So the message is: If you don't allow your Asp.Net code to run with
full trust, your applications will be safe, and none of the attack
vectors that we (DDPlus) described would work.
The problem (and now I will quote my last post which prompted you to
criticize my public action) is that at the moment the only method
available to disable direct Win32 calls (and the other issues
mentioned) from Asp.Net pages is to reduce the website's trust level
from 'Full trust' to 'High' or' Medium trust' (there is also the
option to write a custom trust policy).
Although in some scenarios this is a valid solution, for ISPs this is
not acceptable because one the side effects of reducing the trust
level are the disabling of functionality such as:
- UI
- OleDb
- EventLog
- ODBC
- Oracle
- MessageQueue
- ServiceController
- DirectoryService
- Performance Counter
- Win32 calls required for User Impersonation
Although some of this restrictions would even be welcomed (for example
MessageQueue or EventLog), today it is unthinkable to offer .Net web
hosting services without support for ODBC or OleDB .
Most database accesses are programmed using ODBC calls and one of the
main reasons for the use the .Net (and previously the .asp) platform
was the ease of use and rapid development features of Access and SQL
server databases.
So, again, Microsoft does have a solution that only works in servers
dedicated to one client and hosting a couple of websites.
I also find interesting their comment "...In the end, we've determined
that, while you are showing interesting attack vectors, they all
require full trust, and as a result are not new vulnerabilities …".
Maybe these are not new vulnerabilities for Microsoft's Security
Response Center, but I know that for the majority of the Asp.Net
community and ISP industry, they are.
Just do a research on the Net (Google, MSDN) for Asp.Net security
issues in: WMI, IIS Metabase, ADSI WinNT provider, ADSI LDAP provider
and the problem of having to run Asp.Net web applications with full
trust; and you will find none or little information about these
vulnerabilities.
And as one can see from the title of the last email "RE: Document with
ASP.NET security Vulnerabilities [MSRC1737mr] - Closed", from
Microsoft's Security Response Center point of view this call was now
closed. And indeed I didn't received any more communications from them
since this date (17/Jul/2003)
Although Microsoft didn't took this issues seriously, us (DDPlus) and
a couple of (responsible and dedicated to security) ISPs that we are
working with, continued to work on these problems, and without
Microsoft help, arrived at the following conclusions:
1) ‘Full trust' is not viable if it removes support for ODBC and
OleDB, so there is no way an ISP will only host websites that run in
‘medium' or ‘high' trust in the current version of the .Net framework
2) Assuming that the websites will have to run in ‘full trust' mode
then what can be done to resolve the problems or reduce the risk:
a) ' The FSO and WSH vulnerabilities can be resolved by
applying custom ACLs on each website folder
b) The IIS Metabase, ADSI WinNT and ADSI LDAP
vulnerabilities can be eliminated by applying custom ACLs on the
relevant Dlls
c) The WMI vulnerability can be eliminated by using the
WMI control MMC or applying custom ACLs on the WMI's dll
From the original list provided to Microsoft Security Response
Center the only one that we don't have a solution is the direct Win32
calls which need more research and testing.
But isn't something wrong with this picture? Why is this work being
done by a couple of companies (us and some collaborating ISPs), and
not Microsoft themselves? They have the resources and direct access to
the .Net framework developers! Shouldn't they be the ones doing this
research and publishing this results?
Our overall objective is to be able to securely configure Asp.Net in
windows 2000 and 2003 servers, which we as DDPlus will offer as part
of our security consultancy services.
- 08/Oct/2003 – We compiled most of all our knowledge and ‘proof of
concept' code into a security tool called ANSA (Asp.Net Security
Analyser) which runs as a web application in a server providing shared
hosting services and tests that server for some of the identified
vulnerabilities (we still haven't added all know vulnerabilities).
NOTE that this tool was published with an OPEN SOURCE license,
where we are providing for FREE our knowledge and experience. The idea
is to leverage on the Asp.Net community in order to create short,
medium and long term solutions for this problem.
The tool was published on GotDotNet and we posted announcements on
several newsgroups. I also sent an email to everybody that had
requested our security guides in the past, AND to Microsoft Security
Research Center (
[email protected])
- 20/Oct/2003 (Today) – I haven't received any response or feedback
regarding this tool from Microsoft Security Research Center, or any
Microsoft employee (somehow I thought that the Asp.Net developers
would be interested in this), BUT I have received very good feedback
and usage reports from several ISPs and IT managers.
I can actually claim that ANSA (Asp.Net Security Analyser) has already
helped several companies to improve their server's security (most
where not aware that they servers where in such ‘insecure' state)
Sorry about the long story, but I felt that only if I gave you the
full picture you could understand my actions.
--------------------------------------------------------------------------
Now, coming back to your original comments:
1) we should have send this email to Microsoft, before we posted it
in such a public forum
2) that publishing details of such vulnerabilities in public is
dangerous
3) that I should act more responsible so that the whole industry
gains
I think that I have answered point number 1). We did send this
information to Microsoft, just to be told that it wasn't new
vulnerabilities and that as long as the websites where executed in
‘high' or ‘medium' trust (which most ISP don't) these problems don't
exist.
On the second point: "publishing details of such vulnerabilities in
public domain", I would call to your attention the following details
- We sent this information to Microsoft on the 1st of July 2003,
this is 3 ½ months ago. The common practice in the industry is to give
the manufacturer 1 month (30 days) to solve the problem and publish a
patch, before the vulnerability details are made public
- From the Microsoft's point of view, these are not new
vulnerabilities, so this information is already in the public domain
- Our original security guide contained ‘proof of concept' code
which we didn't publish publicly and only gave to security consultants
or IT managers
On the third point of "Should act more responsible so that the whole
industry gains", taking into consideration that we have published a
security guide for IIS 5.0 and an Security Analyser for Asp.Net I
think that I can claim that our actions are benefiting the whole
industry. But if you disagree I would be very interested in knowing
your reasons.
Let's also not forget the knowledge of a crowd is always bigger than
the knowledge of an individual or small group. I am a firm believer in
the Open Source model and in the free and unconditional exchange of
information. I hope that in my posts this message is clear and that
people will be motivated to participate because their contributions
will help their community and themselves in the end.
I hope that this (long) post explains the reasons behind our actions
and also why we are having more a public debate about these Asp.Net
vulnerabilities.
I also hope that somebody at Microsoft will take this post seriously
and convince the Microsoft's Asp.Net development team to start
collaborating with us, and everybody that needs to provide secure
Asp.Net shared hosting services.
Thanks for your patience in reading all this,
Looking forward to your comments
Best regards
Dinis Cruz
..Net Security Consultant
DDPlus (
www.ddplus.net)
