Full Trust Asp.Net (in)Security
Secure Asp.Net
Web Application Development
OWASP
AppSec
June 2004 NYC
Dinis Cruz
.Net Project Lead
dinis@ddplus.net
+44 (0)208 995 3756
Copyright © 2004 - The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License.
The OWASP Foundation
http://www.owasp.org
IMPORTANT STUFF
We have Wi-Fi!!!
Thanks to STAN GUZIK!!!!
IP: 192.168.1.x (1 and 28 are taken)
Gateway and DNS: 192.168.1.1
Portugal – Spain Euro 2004 game starts at 14:45
Can be followed at:
http://news.bbc.co.uk/sport1/hi/football/euro_2004/
Russia v Greece (is also starting at the same time)
“Toshiba question”
OWASP AppSec 2004
2
This presentation
Who am I?
DDPlus (Director, Owner)
Intense School (Curriculum Development & Training)
CISSP Ltd (CTO and Senior Security Consultant)
DBI (Senior Consultant)
Desktop Builders (Active Directory Security Expert)
What I will cover in this session
Full Trust Asp.Net (in)Security
Secure Asp.net Web Application Development
OWASP AppSec 2004
3
Challenge to the JAVA camp
All this relates to JAVA
I’m not a JAVA expert (although I can ‘read’,
review and audit java code)
I never found any of this stuff in JAVA (during my
Java Security Audit projects )
All my conversation with JAVA gurus (some in
this conference) haven’t shown that JAVA can
solve these problems
My challenge to you:
Prove that JAVA is not vulnerable to this
Port ANSA, SAM’SHE and ANBS to JAVA
OWASP AppSec 2004
4
Asp.Net is used in hosting!
OWASP AppSec 2004
5
Microsoft Security and the root of all problems
 I’m not into bashing Microsoft (what I am talking about are
industry wide problems)
 Microsoft is part of the problem
 Microsoft is part of the solution (big part)
 Microsoft is the best player in the Software world (they
invented it)
 in my view…
 The root problem is:
INSECURE WEB APPLICATION HOSTING ENVIROMENTS
OWASP AppSec 2004
6
My work at OWASP
 Donated the first version of ANSA (Asp.Net Security
Analyser)
 Created (under OWASP) SAM’SHE:
Security Analyser for
Microsoft’s Shared Hosting
Environment
 See it at http://www.owasp.org/dotnet
 Who has used these tools?
OWASP AppSec 2004
7
ANSA, ANBS and SAM’SHE
Vision
What is done
Next steps
These tools test the security from the inside
(web hosting environment)
Beretta will test the security from the outside
OWASP AppSec 2004
8
ANBS – Asp.Net Baseline Security
ANBS (Tool for Technical Users)
ANSA
(Asp.Net Security Analyser)
Asp.Net Security Analyser (ANSA) is a Windows
based online tool that tests a server's security for
known security vulnerabilities within an Asp.Net
shared hosting environment.
ACSA
(Asp CLASSIC Security Analyser)
Asp CLASSIC Security Analyser (ACSA) is
the same as ANSA but for Asp CLASSIC
CAMTs (Configuration, Auditing and Monitoring Tools)
(Asp.Net Security Analyser)
Secure User and
IIS website
manager
ACL Manager
IIS Metabase
Explorer
Port Scanner
OWASP AppSec 2004
9
SAM’SHE (Security Analyzer for Microsoft’s Shared
Hosting Environments)
SAM’SHE (Tool for NON-Technical Users*)
• Security Analyser for Microsoft’s Shared Hosting Environments
• Test the security of IIS servers
• Designed to be 1-click test
• Objective is to raise the awareness of the problems by the ones that matter
(the paying clients)
• No ‘exploits’ and ‘dangerous functionality’
* ISPs clients, CTOs, Help Desk Staff
OWASP AppSec 2004
10
ANSA and SAM’SHE Demos
1) ANSA - Security Analyser.avi……………
2) ANSA - Run tests individually.avi………
3) ANBS - SamShe.avi……………………….
4) ANBS - XML database and Metabase
explorer.avi……………………………………
OWASP AppSec 2004
11
Current SAM’SHE tests (1/2)
 WMI(.Aspx)










WMI Enabled
WMI.Enabled.List.Anonymous.Account.Details
WMI.Enabled.Create.Processes
WMI.Enabled.List.UserNames
WMI.Enabled.List.Process
WMI.Enabled.List.Services
WMI.Enabled.Read.System.LogFiles
WMI.Enabled.Read.Application.Log
WMI.Enabled.List.Logical.Disks
WMI.Enabled.List.Network.Shares
 WSH(.aspx)
 WSH.Enabled
 WSH.Enabled.Create.Processes
 Machine.Config (.Aspx)
 Read.Machine.Config.file
 Win32 (.Aspx)
 win32.CreateProcess.WinExec
OWASP AppSec 2004
12
Current SAM’SHE tests (2/2)
 Metabase (.Aspx)




Read.Metabase.file
Read.Metabase.Backup.files
AfterRevertToSelf.Read.Main.AnonymousAccountDetails
AfterRevertToSelf.Read.Websites.AnonymousAccountDetails
 RevertToSelf (.Aspx)





RevertToSelf.Reflection
RevertToSelf.Win32
RevertToSelf.AfterRevert.ChangeIdentity
RevertToSelf.AfterRevert.CheckIfRevertedToSystem
RevertToSelf.AfterRevert.CreateProcess
 TokenHandles (.aspx)
 TokenHandles.List
 TokenHandles.SystemToken
 WSH (.Asp)
 ASPCLASSIC.WSH.Enabled
 ASPCLASSIC.WSH.Enabled.Create.Processes
OWASP AppSec 2004
13
Shared hosting environments (examples of)
SCENARIO A
SCENARIO B
SCENARIO C
SCENARIO D
(SME dedicated)
(SME dedicated)
(SME Shared)
(Big Development team)
1x Administrator
(also the developer
and content manager)
10x Marketing
1x
1x Developer,
1x
3x Developer,
5
Administrator or content
Administrator or content
Administrator
manager
manager
10x product dev.
10x Web designers
Dedicated
Web Server
Dedicated
Web Server
Shared
Web Server
Dedicated Shared
Web Server
(hosting different
internal websites)
INTERNET
OWASP AppSec 2004
14
Definition: What is a secure Web Application Hosting
Environment?
Is an environment that (very partial list):

The hosting server is securely built and:





only exposes to the Internet’s Anonymous users the WWW, FTP and HTTPS ports
don’t have any software installed apart from the necessary to run the WWW, FTP and
HTTPS services (i.e. most of the ‘system32’ directory should not be there)
the server is only able to respond to inbound connections (for example web requests
or terminal service sessions) and NOT be able to initiate any un-solicited outbound
connections
only accepts administrative access from pre-defined sub-nets and via secure channels
(for ex: VPN or SSL)
… and doesn’t allow authenticated users (i.e. clients) to:





see





secure sensitive information about the server such as:
user accounts or security groups
services running
current connections
system information (operating system, disk space available)
the IIS Metabase (which provides details about the other websites hosted in the
same server)
execute commands on the server / create processes on the server
browse on directories outside the assigned web space (i.e. from another website)
see files outside the assigned web space (i.e. from another website)
15
create TCP connections to unauthorized IPs / Ports OWASP AppSec 2004
Admin vs User privileges
The Administrator can:
 Administrate the server, for example:
 Create new users and manage security groups
 Install software (require admin priv.)
 Execute programs (*.exe, *.com)
 Read metadata from hosted websites
 Read data from other co-hosted websites (.Net
assemblies, connection strings, etc…)
 Impersonate other users (grab other user’s security
tokens)
Full Trust
ASP.NET
allows this!
The Developer, or content manager can:
 Edit its own website data (i.e. folder that store its data)
 Execute Asp.Net within a Sandbox (so that the Asp.Net
script CANNOT access dangerous resources)
OWASP AppSec 2004
16
Full Trust Asp.Net
 Mode where all .Net CAS (Code Access Security) features
are disabled or easily bypassed
 Full Trust Asp.Net is too powerful and dangerous
 But (in web applications) everybody (including most
ISPs) runs their web applications with Full Trust
 90% (or 99.9%) of Asp.Net web applications are
designed to run with Full Trust
 This makes all shared web application hosting
environments (and servers) two hits away from full
compromise (hit 1: the web app, hit 2: the server)
OWASP AppSec 2004
17
Full Trust Asp.Net: What makes it worse?
There are barely any (official) acknowledgments
of the problem (Microsoft, ISPs and Web
Application Developer)
There is barely any documentation about these
problems on the dozens of published Asp.Net
security books
The clients are not aware (the ISPs clients and
the end users)
If malicious activity is happening right now it will
not be disclosed by the affected parties (there
are some rare exceptions).
OWASP AppSec 2004
18
Full Trust Asp.Net vulnerabilities (incomplete list)
 RevertToSelf
 Metabase (WMI, ADSI, ABO)
 Metabase after RevertToSelf
 Unmanaged code (do what ever you want with the IIS
process)
 Reflection (access private members of reflected
assemblies; execute the entire .Net API)
 Asp.Net Temporary Files
 Security Token Vulnerability
 Bypass CAS
 (ADSI LDAP, ADSI WinNT, WMI, WSH, raw TCP packets
and much more … )
 DEMO “IIS Security Token Vulnerability.avi” (video)
OWASP AppSec 2004
19
Full Trust Asp.Net: The Solution
 Create standards to measure the quality of ‘a secure
hosting environment’
 Create tools to test, fix and monitor hosting security
 Create tools to develop Web Applications in Partially
Trusted environments
 Raise the client’s, developer’s, end user’s and
government’s awareness of the problem
 Secure coding using CAS (Code Access Security)
implementing role and code based security
 NOTE: this solutions must be backward compatible since
there are already 100,000s of web applications
developed on Asp.Net
 TRAIN, TRAIN, TRAIN, TRAIN, TRAIN, TRAIN developers
 DOCUMENT, DOCUMENT, DOCUMENT how to do all this
OWASP AppSec 2004
20
Full Trust .Net: Why it is used?
Asp.Net Partial Trust environments:
Can’t call Unmanaged Code
Can’t create COM objects
Can’t use OLEdb or ODBC
Most core .Net assemblies don’t have the APTCA
(Allow Partially Trusted Callers Attribute)
All local code is executed with Full Trust (in .Net
and Asp.Net)
In Office 2003, Macros (now .Net assemblies)
require Full Trust
OWASP AppSec 2004
21
Not the developer but the environment
 Making the developer the SOLE responsible entity for
producing secure applications is not realistic
 Developers are focused of features, they are paid for features
and they are fired for features
 Developers only get security budget (time and resources) after
security incidents
 Secure coding is a journey, NOT a destination
 Secure Web Application Environments is the
DESTINATION
 Multi-Layer defence system, i.e.
 Defence-in-Depth
 “.Net Framework book story” & “Euro 2004 website”
OWASP AppSec 2004
22
What is needed: Real-Time SandBoxing
Web Server
Web Application
Local Security
Policies
SANDBOX
CODE
Web Application
WHAT DO I NEED TO
RUN?
• .Net Assemblies or COM
objects
Security
Engine
CODE
Requested
(or allocated)
resources
• File (Path and ACLs)
• Registry (Path and
ACLs)
• TCP ports
• etc..
User privileges
OWASP AppSec 2004
23
What is needed: Custom SandBoxing
Web Server
Web Application
SANDBOX
CODE
Web Application
WHAT DO I NEED TO
RUN?
CODE
• .Net Assemblies or COM
objects
allocated resources
• File (Path and ACLs)
• Registry (Path and
ACLs)
• TCP ports
User privileges
• etc..
OWASP AppSec 2004
24
What is needed: TOOLS
 Tools
 Tools
 Tools
 Tools
 Tools
to create ‘Real-Time Sandboxes’
to create ‘Custom Sandboxes’
evaluate the security of Sandboxes (ANBS)
to evaluate the security of Applications (Beretta)
to develop Web Applications for these SandBoxes
 In essence: ‘Tools to Create Secure Hosting
Environments’ , which:
 Allow the SysAdmins to make conscious choice
 ‘Force’ the developers to ‘describe the resources they need’
 Give buyers ‘metrics’
OWASP AppSec 2004
25
What we have today: .Net’s CAS
OWASP AppSec 2004
26
Partially Trust Asp.Net: Today
There are two ways to create partial trust Web
Applications
Publish Full Trust Code to the GAC
 Development scope is small since only the required
functionality is required
 Manual process that requires code review before each
publish
Create ‘Wrapper Assemblies’ for functionality that
requires Full Trust
 One-time development process (and GAC publishing)
 Big Development scope since one needs to cover for most
developer’s needs
 Security bugs can be dangerous
OWASP AppSec 2004
27
Full Trust Asp.Net: What is the Risk?
If Risk = Vulnerabilities * Impact * Probability
In Full Trust Asp.Net:
Vulnerabilities = 99% (VERY HIGH)
Impact = 80% (High)
Probability = 0.01% (Very Low)
So the Risk is 0.99 * 0.8 * 0.01
Which is = 0.00792 (i.e. 0.792%) which is either
LOW RISK or NO RISK
OWASP AppSec 2004
28
We have been very lucky
(comparatively) Very low level of damage cause
How
How
How
How
many bankruptcies caused by attacks?
serious business loss caused by attacks?
many deaths caused by attacks?
many WARs caused by attacks?
Most virus are very harmless (if fact they are
very healthy to the industry)
No major ISPs have been attacked
OWASP AppSec 2004
29
Simple ISP attack scenario
(executed slowly…….. with patience……)
1.
2.
Attacker buys a Asp.Net shared hosting account ($20/month or trial
account) in a major ISP (more that 10,000 hosted accounts and with
+300,000 unique visitors a day)
Because the account allows Full Trust Asp.Net the attacker:
1.
2.
3.
3.
4.
5.
6.
7.
8.
Compromises the server (gain root access)
Compromises all surrounding servers (gain root access)
Compromises all ISP’s servers, desktops, PDAs, Printers, Scanners, Cell
Phones, Email System, Customer Database, Financial System, etc…
Scan the ‘compromised items’ for valuable data: Databases, Personal
details, SSL certificates, etc…
Install Root-Kits, backdoors and Zombies on all (or the more relevant)
‘compromised items’ (can you find a RootKit in device’s memory? NICs,
Sound Cards, Graphic Cards, etc…)
Infect all websites (or the ones with higher traffic) with an un-patched IE
vulnerability which allows remote command execution with local privileges
Exploit visitor’s computers
Blackmail data owners (threat with information disclosure)
Blackmail ISP (threat with internal DDoS)
OWASP AppSec 2004
30
Paths to the first ‘root’ (real life example 1/3)
“Because the account allows Full Trust Asp.Net the attacker:
Compromises the server (gain root access)”
 ISP A:
 50,000 websites (50 web servers)
 IIS 5.0 in low process* (all user ASP Classic pages run with SYSTEM
privileges)
 Active directory controls all user accounts, and website isolation (each
website has a unique anonymous user)
 Servers are built automatically using installation script which
automatically configures everything and registers server in AD
 AD’s admin password used to register server
 AD’s admin password hard-coded into the install script which is saved
in a local (Administrator ACLed) folder
 Since the ASP Classic scripts run under SYSTEM, you can write a script
that reads the install script
 GAME OVER
* An Asp.Net variation of this example occurs if Asp.Net is
configured in Machine.Config or the Application Pool used to
OWASP AppSec 2004
run under SYSTEM
31
Paths to the first ‘root’ (real life example 2/3)
“Because the account allows Full Trust Asp.Net the attacker:
Compromises the server (gain root access)”
 ISP B:
 Poor ACLing allows the attacker to read most files on the system
 All websites are configured automatically using an Asp.Net web
application
 This Web Application needs admin rights over the SQL server (to
create databases)
 Web Application is executed from the ‘Shared server’
 SQL connection string is stored in web.config (including sa’s
password)
 sa password provides FULL access to SQL server (all SQL servers since
the password is reused) , including the ISP’s customer database
 sa password allows the execution of commands on the SQL SERVER
with SYSTEM privileges
 GAME OVER
OWASP AppSec 2004
32
Paths to the first ‘root’ (real life example 3/3)
“Because the account allows Full Trust Asp.Net the attacker:
Compromises the server (gain root access)”
 ISP C:
 Full Asp.Net allows the upload and execution of EXEs
 Upload a DCOM exploit to server
 Execute it (from the inside) and gain root access (how many networks
can survive an internal attack?)
 GAME OVER
 And much more…..
OWASP AppSec 2004
33
ISP’s Shared Hosting environments
must be the Benchmark!
 ISPs should be examples of ‘best practices’
 Everything is ‘shared hosting’ (unless you trust everybody and
everything)
 ISPs should be judged on their Hosting environments (i.e. how good
is their sandbox?)
 This process (securing ISPs and creating Sandboxes) can be used to
create ‘metrics’ and TONS of documentation on how to create
partially trusted Code
 The users must be educated about these issues so that they use
their ‘buying power’ to demand secure services
 Then SECURITY becomes a BRAND VALUE
(“OS economist story”)
OWASP AppSec 2004
34
‘Security Decisions’ and ‘Project Man-hours’
Security Decisions
Manufacturer
Security Consultants
(Local, 3rd party, open community)
Developers
Manufacturer
Security Consultants
(Local, 3rd party, open community)
Developers
Project man-hours
OWASP AppSec 2004
35
‘Writing Secure Code’ 5 day Security Course
 Developed by Intense School (www.IntenseSchool.com)
 Based on the Microsoft’s ‘Writing Secure Code 2nd
Edition’
 Michael Howard and David LeBlanc are actively
participating in the project (weekly meetings, material
review and new material development)
 I’m working on a DEMO application which will be used
on all practical exercises
 DEMO: “SQL Injection”
 DEMO: “Buffer OverRun”
OWASP AppSec 2004
36
Happy Fathers day &
What wakes me up in the morning…..
OWASP AppSec 2004
37
Links to my stuff about ‘Full Trust Asp.Net’
 Security Guides and WhitePapers
 "Secure Shared Hosting with IIS 5.0 Version 0.95.doc"
 "Security vulnerabilities in ASP.NET V0.60.doc"
 Undocumented ASP.NET Security V0.89.doc (110 page document)
 Technical Articles
 Developer.com
 ASP.NET's Hidden Dangers
 Malware: Is Your Workstation at Risk?
 DevelopersDex.com
 An 'Asp.Net' accident waiting to happen
 Microsoft must deliver 'secure environments' not tools to write 'secure code'
 Asp.Net.Vulnerability: Full Trust (current security problems and possible
solutions)
 Newsgroups
 'Asp.Net Security' forum in www.asp.net




Thread: Idea to solve the current shared hosting ‘Full trust’ issue.
Thread: FSO in ‘Medium trust’ environments
Thread: examples of 'Medium' or 'high' trust Asp.Net applications
Thread: When will Microsoft take Asp.Net Security seriously
OWASP AppSec 2004
38
Some more links to Asp.Net CAS resources
 Improving Web Application Security: Threats and Countermeasures – by far the
best book (and online resource) on this subject (includes real examples of
‘assembly wrapping’ and ‘GAC publishing’). But even this book doesn’t really
explain the dangers of Full Trust.
 Beware of Fully Trusted Code (Keith Brown) – explains how all CAS security
features can be bypassed on a Full Trust environment
 FindAPTC (Keith Brown) – “…. I wrote this to point out how infeasible it is today
to write locally installed code that doesn't run with full trust …”
 Writing managed code for semi-trusted environment (by Ivan Medvedev, 2003)
– interesting but of not much real live use
 ASP.NET Websites running under Partial Trust and third party controls –
describes the problem of partial trust in ISPs but doesn’t provide a real solution
 Code Access Security (CAS) and Design Patterns - very good explanation of CAS
but its Partial Trust example is about creating a custom policy
 Code Access Security (CAS) – "Guilty until proven Innocent" (Partially Trusted
Code) - has just been published (17 June 2004) and provides more details on
how to write partial trust .Net applications (the contradictions and ‘loop-holes’
existent in this article are a good example of how complicated (if not impossible)
it is to write meaning Partially Trusted Applications)
 A Google search for full trust Asp.Net , partial Trust Asp.Net and partially trusted
Asp.Net shows how little information is available today
OWASP AppSec 2004
39
I need your help with my OWASP .Net projects!
In Testing
In Deploying
In Creating new Vulnerability tests
In Working on the new modules
In Documenting
In Creating Asp.Net applications in Partially
Trusted environments
The first step to participate is to
JOIN the OWASP-DotNet MAILING LIST
OWASP AppSec 2004
40
Questions?
Any Questions
Thank you very much….
OWASP AppSec 2004
41