From: dinis at ddplus.net (Dinis Cruz)
Subject: RE: [Owasp-dotnet] Re: (Asp.Net Full Trust Vulnerabilities) RE: Apache VS IIS Security model question

Hello Ken, 

Sorry for the delay in responding to your email, but I am currently very
busy.

I originally wanted to respond to your questions via an article (since that
would allow me to present my arguments in a better format), but since I
don't have time to do it now, I will (for now) just answer directly to your
questions.

> However I am still unsure how an ASP.NET application, running in Full
> Trust,
> can circumvent NTFS permissions. Given the following situation, how would
> this be accomplished?
> 
> a) Windows 2003 / IIS 6.0 running in Worker Process Isolation Mode
> b) Each client of the server (say, each department of a company, or each
> customer of a hosting company) has their own website
> c) Each website is placed into its own custom application pool
> d) Each application pool has it's own custom identity, placed into IIS_WPG
> e) Each website uses its own custom "anonymous user" account - ACLs are
> secured in the metabase for each website, ACLs are set for each website's
> folders/files

This configuration that you have here is most secure way to configure IIS
6.0 websites (anything less, and you will be introducing massive
vulnerabilities). 

But even with this configuration (which has serious scalability problems),
there are several powerful attack vectors. For example:

 I) With Full Trust Asp.Net (after a call to 'RevertToSelf()') it is
possible to upload and execute malicious applications (i.e. malware) which
could allow the:

	- Elevation of Privilege into Administrator or System: possible if
the server (or any local server) is not fully patched (or if the malicious
user knows a 0-day exploit)

	- Execution of cmd.exe (uploaded to the server if the original
version is ACLed) in order to (initially) execute commands such as 'Net
User', 'Net View', 'Ipconfig', etc... (note that even if an Anti-Virus is
present in the server that considers cmd.exe to be a malicious file, all
cmd.exe commands can be created using direct Win32 API calls). This
information would allow (for example) the execution of a brute force
password attack to all accounts (including the administrators). In such BF
scenario, the 'better-case' scenario is a DoS attack (where all accounts are
locked) and the 'worse-case' scenario is the discovery of ALL user's
passwords (including the administrator's ones)

 	- Create a remote shell and access the system remotely: possible if
the server allows outbound connections

 II) If on your step e) you didn't explicitly remove the IIS_WPG ACL from
ALL website's Metabase entries, then the malicious script could (after
"RevertToSelf()"):

	1) read from the Metabase the "Anonymous User" account details (i.e.
the username and password) from all websites that are ACLed (in the
Metabase, not in NTFS) to IIS_WPG (which is the default setting). Note that
the current tool to change the Metabase ACLs is not (or wasn't until a
couple of months ago) supported by Microsoft.

     2) Impersonate those accounts (the "Anonymous User") and access their
resources (which now will be accessible using normal IO classes)

 III) Read the other website's source code in the "Temporary Asp.Net Folder"
which contains the source-code of all Asp.Net pages that required real-time
compilation (ok, this is not accessing the files directly but the end result
is the same). Note that by default all websites share the same "Temporary
Asp.Net Folder", but Asp.Net allows the definition of a unique folder per
Asp.Net Application (which must be ACLed to the "Application Pool User" and
not to IIS_WPG)

> The points below:
> 1) presupposes that administrators setting up the server have left stuff
> lying around, and un-ACLed

Which is more common than you think! (if I told you the names of the
real-live examples that I know, you would probably fall off your chair)

> 2) can't be done as far as I can tell

Yes, "...read (from the Metabase) other website'sAnonymous and Application
Pool Account details (Username and Password)...", unfortunately can be done

After you call 'RevertToSelf()' you are acting under an account belonging to
the IIS_WPG which by default has FULL access to the "/LM/W3SVC" section of
the Metabase (and the ABO, ADSI IIS and WMI classes know how to decrypt the
encrypted Metabase passwords)

Go to the OWASP (http://www.owasp.org/software/dotnet.html) website and
download the ANBS (Asp.Net Baseline Security) Open Source tool (that I
developed) which contains:

	a) an "Online Metabase Explorer" tool which allow you (from an
normal account) to navigate the "/LM/W3SVC" section of the Metabase

   	b) a SAM'SHE (Security Analyser for Microsoft's Shared Hosting
Environments) test for this vulnerability (look in the source code to
understand how it works)

Alternatively, you can download the other tool I also developed for OWASP,
ANSA (Asp.Net Security Analyser) which contains a PoC (Proof of Concept) for
this vulnerability

> 3) can't be done as far as I can tell

Yes, "... If other websites share the same application pool, you can search
the current w3wp process for their security tokens, use those tokens to
impersonate those users (no need to know their password) and access
website's data...", unfortunately can be done

Email me directly, and I will send you a PoC which clearly shows this.

The latest version of SAM'SHE already tests for this vulnerability

> 4) depends on the privileges of the process account 

Which belongs to the IIS_WPG and has access to most of the Win32 API. 

> - you probably can't do much unless you attempt to run something that 
> exploits Windows, or SQL Server or other product

Which is exactly what a malicious would do :)

This point is reinforced by some of the "10 Immutable Laws of Security"
(http://www.microsoft.com/technet/archive/community/columns/security/essays/
10imlaws.mspx):

	* "...Law #1: If a bad guy can persuade you to run his program on
your computer, it's not your computer anymore..."

	* "...Law #4: If you allow a bad guy to upload programs to your
website, it's not your website any more..."

Think about it, do you allow your clients to upload and install COM objects
on your server? I'm sure you won't for obvious security reasons.

But, for all practical reasons: "Unmanaged code in Full Trust Asp.Net = COM
objects (i.e. DLLs)"

> 5) etc etc etc doesn't count as an exploitable vector in my book.

Fair enough

What about:

 - Reflection
 - WMI - Windows Management Instrumentation
 - ADSI WinNT provider
 - ADSI LDAP provider
 - ADSI IIS provider
 - Authentication and Impersonation features (exploitation of)
 - Internal Network (for example Internal Port Scan)
 - Denial of Service attacks
 - FPSE2002
 - WSH (Windows Script Host)
 - SNMP or NetBIOS queries
 - Use the server to attack other servers (internal and external)
 - Use the server to attack the clients accessing the hosted websites
 - AD Corruption

> 
> Thanks

No problems,

I'm looking forward to your comments, and am especially interested to know
if you now agree with me that the only REAL solution for these
vulnerabilities is to: 

"run ALL web applications hosted in one server under Partially Trusted
environments".

Best regards

Dinis Cruz
.Net Security Consultant
DDPlus

> 
> 
> Cheers
> Ken
> 
> ----- Original Message -----
> From: "Dinis Cruz" <dinis@...lus.net>
> Subject: (Asp.Net Full Trust Vulnerabilities) RE: Apache VS IIS Security
> model question
> 
> 
> : If the code is running with full trust it can call RevertToSelf() and
> change
> : the current Asp.Net (Thread) Identity into the Process' Identity (which
> : belongs to the IIS_WPG).
> :
> : Once this is done:
> :
> :  1) You can probably already bypass several NTFS restrictions and see
> other
> : website's data (and other sensitive information usually left on the
> server)
> :
> :  2) You can read (from the Metabase) other website's Anonymous and
> : Application Pool Account details (Username and Password), use that
> : information to impersonate those users (which you can with Full Trust)
> and
> : access other website's data
> :
> :  3) If other websites share the same application pool, you can search
> the
> : current w3wp process for their security tokens, use those tokens to
> : impersonate those users (no need to know their password) and access
> : website's data
> :
> :  4) You can upload to the server an exploit and execute it. With full
> trust
> : it is almost impossible to stop the upload and execution of a malicious
> : .EXE. The only defence could be if the Anti-Virus installed on the
> server
> is
> : able to detect the Malware (although this limitation could be easily
> : bypassed by any half-decent malicious attacker with access to the
> exploit's
> : source code)
> :
> :  5) etc, etc, etc..... There any many more attack vectors, but these
> should
> : be enough to make my point
> :
> : Note that even if the attacker is only able to gain read access to
> another
> : website's data, most likely he/she will be able to retrieve the Database
> : Connection String and gain FULL access to that website's database.
> :
> : If this is news for you (i.e. how dangerous Full Trust Asp.Net can be),
> then
> : I would recommend that you take a good look at the work I have done over
> the
> : last year at OWASP (Open Web Application Security Project), namely Open
> : Source tools: ANSA (Asp.Net Security Analyser) and SAM'SHE (Security
> : Analyser for Microsoft's Shared Hosting Environment).
> :
> : Some links:
> :
> : - OWASP .NET section: http://www.owasp.org/software/dotnet.html
> :
> : - Post with Links to some of my online posts (Security issues with
> Asp.Net
> : in Shared Hosting Environments, OWASP .Net tools and OWASP AppSec
> : Presentation):
> :
> http://sourceforge.net/mailarchive/forum.php?thread_id=5203278&forum_id=24
> 75
> : 4
> : - presentation that I did last June at the OWASP AppSec NYC 2004
> conference
> : entitled "Full Trust Asp.Net (in)Security / Secure Asp.Net Web
> Application
> : Development":
> :
> : -
> :
> http://prdownloads.sourceforge.net/owasp/AppSec2004-Dinis_Cruz-
> Full_Trust_As
> : p.Net_Security_Issues.ppt?download (main PPT)
> :
> : -
> :
> http://prdownloads.sourceforge.net/owasp/AppSec2004-Dinis_Cruz-
> Full_Trust_Vi
> : deos.zip?download (the support videos: "ANBS - SamShe.avi", "ANBS - XML
> : database and Metabase explorer.avi", "IIS Security Token
> Vulnerability.avi",
> : "ANSA - Run tests individually.avi", "ANSA - Security Analyser.avi")
> :
> : Best Regards
> :
> : Dinis Cruz
> : .Net Security Consultant
> : DDPlus
> : > -----Original Message-----
> : > From: Ken Schaefer [mailto:ken@...penstatic.com]
> : > Sent: 14 September 2004 03:10
> : > To: webappsec@...urityfocus.com; pen-test@...urityfocus.com
> : > Subject: RE: Apache VS IIS Securiyt model question
> : >
> : > I'm pretty sure that Mike is talking about NTFS permissions (and
> Windows
> : > users and groups). Can you point us to how ASP.NET code running as
> fully
> : > trusted gets around that?
> : >
> : > Cheers
> : > Ken
> : >
> : >  -------- Original Message --------
> : > > From: "Dinis Cruz" <dinis@...lus.net>
> : > > Subject: RE: Apache VS IIS Securiyt model question
> : > >
> : > > Please note that these security settings will only be relevant (in
> IIS)
> : > in a
> : > > Partially Trusted Website (i.e. the Asp.Net code is NOT running with
> : > Full
> : > > Trust).
> : > >
> : > > If the code is running with Full Trust, then most likely those
> security
> : > > permissions will be easily bypassed.
> : > >
> : > > Dinis Cruz
> : > > .Net Security Consultant
> : > > DDPlus
> : > >
> : > > > -----Original Message-----
> : > > > From: mthompson [mailto:mthompson@...nkster.com]
> : > > > Sent: 11 September 2004 01:56
> : > > > To: webappsec@...urityfocus.com; pen-test@...urityfocus.com
> : > > > Subject: Apache VS IIS Securiyt model question
> : > > >
> : > > > Hello,
> : > > >
> : > > > I am doing research and I am stuck.
> : > > >
> : > > > Pitch: In IIS there is the ability to set permissions on a per
> website
> : > > > basis. In other words the ability to limit access to files and
> : > > > directories based on the users credentials that the website is
> running
> : > > > under. Additionally, you would in turn add this user to a group
> and
> : > > > apply group permissions to an object that needed to be accessed by
> : > more
> : > > > than one site.
> : > > >
> : > > > Question: Is there a similar security model for apache that would
> : > allow
> : > > > credentials from a user to run a virtual website and access files
> only
> : > > > for a specific virtual site.
> : > > >
> : > > > Also, does any one have a diagram of the apache process?
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Owasp-dotnet mailing list
> Owasp-dotnet@...ts.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owasp-dotnet

Powered by blists - more mailing lists