«

At the moment the only method available to disable direct Win32 calls
from Asp.Net pages (using for example: " Declare Function WinExec Lib
"kernel32" Alias "WinExec" (ByVal lpCmdLine As String, ByVal nCmdShow
As Long) As Long") is to reduce the website's trust level from 'Full
trust' to 'Medium trust'.

Although in some scenarios this is a valid solution, for ISPs this is
not acceptable because in the current (V1.1) release of the .Net
Framework the following objects don't support partially trusted code
(i.e. only work with 'Full trust')

- 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, until Microsoft releases the next version of .Net (V2.0) or a
patch for this problem, the ISPs and anybody responsible for .Net
shared hosting environments, will have to execute their client's
website code with 'Full trust'.

Given the dangers and risks created by situation (remote command
execution, disclosure of usernames and system information, etc... ),
the only solution is prevention and detection.

After some online research we couldn't find any relevant discussions
about this issues, so we would like to propose the following ideas and
see if one of them does produce a valid and acceptable solution for
this problem:

1) Code Validation -

a) Create a tool that executes after all compilation is done (i.e.
when IL code is created) but before the IL code is converted to
machine code and executed by the OS. This toll would validate the DLLs
/ EXEs and approve or disapprove its execution based on the calls that
are made. For example if a DLL contains a call to the Win32's
"winExec" function then (unless the DLL has a special permission) its
execution will be denied.

b) This tool could be used on 'live' websites or could be used
offline (some of this might have to be developed by Microsoft). The
offline mode could be part of an 'Approval Mechanism'

c) This concept is the same as the one applied by the Anti-Virus
software that check for 'dangerous code' (i.e. virus signatures) on
files (downloaded from the web, attached to an email or copied to
disk) before they are executed by the system. The AV companies should
develop such products because they already have the core system, the
automatic updates, the report engine, the 24/7 security response teams
and the brands.

2) Improved security infrastructure:

a) Full daily backups on all data stores
b) Monthly re-Builds of all servers (automated procedure)
c) ability to rebuild a server in 1h:
i) Install OS and applications
ii) Install security policies and settings
iii) Import databases from backup (or live servers)
iv) Add users (if required)
v) Assign IPs
vi) decommission old server (if still live) and publish rebuilt
server without any loss of service

d) the ideal situation would be to have the servers in a cluster
environment where when one server is rebuilt (due to normal rebuild
practices or it was compromised), it can be removed from the network
without any loss of service

3) Have one website per virtual server (both running in a main server)

a) the idea would be to have the equivalent of VMware where a server
would host each website in its own 'virtual' server (like mainframes).
This would require a much lighter version of windows 2003 which would
have to be designed for such scenario. Another possibility would be to
use Linux which will be possible once the porting of the .Net platform
is fully completed.

4) Audit Website Folders and Files:

a) monitor and audit at OS level (using NTFS) all files that belong
to each user by analysing the logs stored in the Event Viewer
b) create custom reports per site / per user with details of whom
(from the inside) accessed those files

5) Only execute signed and approved code -

a) Two server scenario:

i) Development server (insecure)
ii) Live server (secure)

6) Reduce customer anonymousity -

a) Require authorized IPs to edit site
b) Require IPSec key to edit site
c) Validate identity using Credit Card system and other identity
schemes

7) Improve protection of important information (Such as usernames,
passwords, database connection strings, database data, etc...)

a) Never strore these information in clear text (always stored them
encrypted)
b) Etc....

Although Asp.Net is a giant leap forward on the technological
frameworks required to build more robust and secure web services,
unless these applications can be securely hosted, they will never gain
public acceptance and wide usage.

And unless a solution is found for this 'Full Trust' issue, nobody
will be able to provide secure hosting of Asp.Net code.

We believe in shared knowledge and the power of peer-review, that is
why we published our Asp.Net Security Analyser (see
http://www.gotdotnet.com/Community/W...e-320edf64fba5)
as an open source web application, and why we are posting this
information online and asking for your ideas and suggestions.

Best regards

Dinis Cruz

..Net Security Consultant
DDPlus (www.ddplus.net)

Dinis ..why not forward this as it should be to

The Microsoft Security Response Center (MSRC) draws on the hundreds of
security professionals at Microsoft to form virtual teams that respond
to reports of security issues with Microsoft products or technologies.
To report a suspected vulnerability, please send e-mail to
.



Dinis Cruz wrote:
> At the moment the only method available to disable direct Win32 calls
> from Asp.Net pages (using for example: " Declare Function WinExec Lib
> "kernel32" Alias "WinExec" (ByVal lpCmdLine As String, ByVal nCmdShow
> As Long) As Long") is to reduce the website's trust level from 'Full
> trust' to 'Medium trust'.
>
> Although in some scenarios this is a valid solution, for ISPs this is
> not acceptable because in the current (V1.1) release of the .Net
> Framework the following objects don't support partially trusted code
> (i.e. only work with 'Full trust')
>
> - 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, until Microsoft releases the next version of .Net (V2.0) or a
> patch for this problem, the ISPs and anybody responsible for .Net
> shared hosting environments, will have to execute their client's
> website code with 'Full trust'.
>
> Given the dangers and risks created by situation (remote command
> execution, disclosure of usernames and system information, etc... ),
> the only solution is prevention and detection.
>
> After some online research we couldn't find any relevant discussions
> about this issues, so we would like to propose the following ideas and
> see if one of them does produce a valid and acceptable solution for
> this problem:
>
> 1) Code Validation -
>
> a) Create a tool that executes after all compilation is done (i.e.
> when IL code is created) but before the IL code is converted to
> machine code and executed by the OS. This toll would validate the DLLs
> / EXEs and approve or disapprove its execution based on the calls that
> are made. For example if a DLL contains a call to the Win32's
> "winExec" function then (unless the DLL has a special permission) its
> execution will be denied.
>
> b) This tool could be used on 'live' websites or could be used
> offline (some of this might have to be developed by Microsoft). The
> offline mode could be part of an 'Approval Mechanism'
>
> c) This concept is the same as the one applied by the Anti-Virus
> software that check for 'dangerous code' (i.e. virus signatures) on
> files (downloaded from the web, attached to an email or copied to
> disk) before they are executed by the system. The AV companies should
> develop such products because they already have the core system, the
> automatic updates, the report engine, the 24/7 security response teams
> and the brands.
>
> 2) Improved security infrastructure:
>
> a) Full daily backups on all data stores
> b) Monthly re-Builds of all servers (automated procedure)
> c) ability to rebuild a server in 1h:
> i) Install OS and applications
> ii) Install security policies and settings
> iii) Import databases from backup (or live servers)
> iv) Add users (if required)
> v) Assign IPs
> vi) decommission old server (if still live) and publish rebuilt
> server without any loss of service
>
> d) the ideal situation would be to have the servers in a cluster
> environment where when one server is rebuilt (due to normal rebuild
> practices or it was compromised), it can be removed from the network
> without any loss of service
>
> 3) Have one website per virtual server (both running in a main server)
>
> a) the idea would be to have the equivalent of VMware where a server
> would host each website in its own 'virtual' server (like mainframes).
> This would require a much lighter version of windows 2003 which would
> have to be designed for such scenario. Another possibility would be to
> use Linux which will be possible once the porting of the .Net platform
> is fully completed.
>
> 4) Audit Website Folders and Files:
>
> a) monitor and audit at OS level (using NTFS) all files that belong
> to each user by analysing the logs stored in the Event Viewer
> b) create custom reports per site / per user with details of whom
> (from the inside) accessed those files
>
> 5) Only execute signed and approved code -
>
> a) Two server scenario:
>
> i) Development server (insecure)
> ii) Live server (secure)
>
> 6) Reduce customer anonymousity -
>
> a) Require authorized IPs to edit site
> b) Require IPSec key to edit site
> c) Validate identity using Credit Card system and other identity
> schemes
>
> 7) Improve protection of important information (Such as usernames,
> passwords, database connection strings, database data, etc...)
>
> a) Never strore these information in clear text (always stored them
> encrypted)
> b) Etc....
>
> Although Asp.Net is a giant leap forward on the technological
> frameworks required to build more robust and secure web services,
> unless these applications can be securely hosted, they will never gain
> public acceptance and wide usage.
>
> And unless a solution is found for this 'Full Trust' issue, nobody
> will be able to provide secure hosting of Asp.Net code.
>
> We believe in shared knowledge and the power of peer-review, that is
> why we published our Asp.Net Security Analyser (see
> http://www.gotdotnet.com/Community/W...e-320edf64fba5)
> as an open source web application, and why we are posting this
> information online and asking for your ideas and suggestions.
>
> Best regards
>
> Dinis Cruz
>
> .Net Security Consultant
> DDPlus (www.ddplus.net)

--
"Don't lose sight of security. Security is a state of being,
not a state of budget. He with the most firewalls still does
not win. Put down that honeypot and keep up to date on your patches.
Demand better security from vendors and hold them responsible.
Use what you have, and make sure you know how to use it properly
and effectively."
~Rain Forest Puppy
http://www.wiretrip.net/rfp/txt/evolution.txt

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'
() 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/tre...n/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 ()

- 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)