Full Trust Asp Net in Security Secure Asp Net

Full Trust Asp. Net (in)Security Secure Asp. Net Web Application Development OWASP App. Sec 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

This presentation

Challenge to the JAVA camp

Asp. Net is used in hosting! OWASP App. Sec 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 App. Sec 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 App. Sec 2004 7

ANSA, ANBS and SAM’SHE

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 App. Sec 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 App. Sec 2004 10

ANSA and SAM’SHE Demos 1) ANSA - Security Analyser. avi…………… 2) ANSA - Run tests individually. avi……… 3) ANBS - Sam. She. avi……………. 4) ANBS - XML database and Metabase explorer. avi………………… OWASP App. Sec 2004 11

Current SAM’SHE tests (1/2) < WMI(. Aspx) 4 4 4 4 4 WMI Enabled WMI. Enabled. List. Anonymous. Account. Details WMI. Enabled. Create. Processes WMI. Enabled. List. User. Names WMI. Enabled. List. Process WMI. Enabled. List. Services WMI. Enabled. Read. System. Log. Files WMI. Enabled. Read. Application. Log WMI. Enabled. List. Logical. Disks WMI. Enabled. List. Network. Shares < WSH(. aspx) 4 WSH. Enabled. Create. Processes < Machine. Config (. Aspx) 4 Read. Machine. Config. file < Win 32 (. Aspx) 4 win 32. Create. Process. Win. Exec OWASP App. Sec 2004 12

Current SAM’SHE tests (2/2) < Metabase (. Aspx) 4 4 Read. Metabase. file Read. Metabase. Backup. files After. Revert. To. Self. Read. Main. Anonymous. Account. Details After. Revert. To. Self. Read. Websites. Anonymous. Account. Details < Revert. To. Self (. Aspx) 4 4 4 Revert. To. Self. Reflection Revert. To. Self. Win 32 Revert. To. Self. After. Revert. Change. Identity Revert. To. Self. After. Revert. Check. If. Reverted. To. System Revert. To. Self. After. Revert. Create. Process < Token. Handles (. aspx) 4 Token. Handles. List 4 Token. Handles. System. Token < WSH (. Asp) 4 ASPCLASSIC. WSH. Enabled. Create. Processes OWASP App. Sec 2004 13

Shared hosting environments (examples of) SCENARIO A SCENARIO B SCENARIO C SCENARIO D (SME dedicated) (SME Shared) (Big Development team) 1 x Administrator (also the developer and content manager) 10 x Marketing 1 x 1 x Developer, 1 x 3 x Developer, 5 Administrator or content Administrator manager 10 x product dev. 10 x Web designers Dedicated Web Server Shared Web Server Dedicated Shared Web Server (hosting different internal websites) INTERNET OWASP App. Sec 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: 4 4 < 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 ‘system 32’ 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: 4 4 4 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 App. Sec 2004

Admin vs User privileges The Administrator can: < Administrate the server, for example: 4 Create new users and manage security groups 4 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 App. Sec 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 App. Sec 2004 17

Full Trust Asp. Net: What makes it worse?

Full Trust Asp. Net vulnerabilities (incomplete list) < Revert. To. Self < Metabase (WMI, ADSI, ABO) < Metabase after Revert. To. Self < 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 Win. NT, WMI, WSH, raw TCP packets and much more … ) < DEMO “IIS Security Token Vulnerability. avi” (video) OWASP App. Sec 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 already 100, 000 s of web applications developed on Asp. Net < TRAIN, TRAIN, TRAIN developers < DOCUMENT, DOCUMENT how to do all this OWASP App. Sec 2004 20

Full Trust. Net: Why it is used?

Not the developer but the environment < Making the developer the SOLE responsible entity for producing secure applications is not realistic 4 Developers are focused of features, they are paid for features and they are fired for features 4 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 4 Multi-Layer defence system, i. e. 4 Defence-in-Depth < “. Net Framework book story” & “Euro 2004 website” OWASP App. Sec 2004 22

What is needed: Real-Time Sand. Boxing 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 App. Sec 2004 23

What is needed: Custom Sand. Boxing 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 App. Sec 2004 24

What is needed: 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 Sand. Boxes < In essence: ‘Tools to Create Secure Hosting Environments’ , which: 4 Allow the Sys. Admins to make conscious choice 4 ‘Force’ the developers to ‘describe the resources they need’ 4 Give buyers ‘metrics’ OWASP App. Sec 2004 25

What we have today: . Net’s CAS OWASP App. Sec 2004 26

Partially Trust Asp. Net: Today

Full Trust Asp. Net: What is the Risk?

We have been very lucky <(comparatively) Very low level of damage cause 4 How many bankruptcies caused by attacks? serious business loss caused by attacks? many deaths caused by attacks? many WARs caused by attacks?

Simple ISP attack scenario (executed slowly……. . with patience……) 1. 2. 3. 4. 5. 6. 7. 8. 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. 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 Root. Kit 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 DDo. S) OWASP App. Sec 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: 4 50, 000 websites (50 web servers) 4 IIS 5. 0 in low process* (all user ASP Classic pages run with SYSTEM privileges) 4 Active directory controls all user accounts, and website isolation (each website has a unique anonymous user) 4 Servers are built automatically using installation script which automatically configures everything and registers server in AD 4 AD’s admin password used to register server 4 AD’s admin password hard-coded into the install script which is saved in a local (Administrator ACLed) folder 4 Since the ASP Classic scripts run under SYSTEM, you can write a script that reads the install script 4 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 App. Sec 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: 4 Poor ACLing allows the attacker to read most files on the system 4 All websites are configured automatically using an Asp. Net web application 4 This Web Application needs admin rights over the SQL server (to create databases) 4 Web Application is executed from the ‘Shared server’ 4 SQL connection string is stored in web. config (including sa’s password) 4 sa password provides FULL access to SQL server (all SQL servers since the password is reused) , including the ISP’s customer database 4 sa password allows the execution of commands on the SQL SERVER with SYSTEM privileges 4 GAME OVER OWASP App. Sec 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: 4 Full Asp. Net allows the upload and execution of EXEs 4 Upload a DCOM exploit to server 4 Execute it (from the inside) and gain root access (how many networks can survive an internal attack? ) 4 GAME OVER 4 And much more…. . OWASP App. Sec 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 App. Sec 2004 34

‘Security Decisions’ and ‘Project Man-hours’ Security Decisions Manufacturer Security Consultants (Local, 3 rd party, open community) Developers Project man-hours OWASP App. Sec 2004 35

‘Writing Secure Code’ 5 day Security Course < Developed by Intense School (www. Intense. School. com) < Based on the Microsoft’s ‘Writing Secure Code 2 nd Edition’ < Michael Howard and David Le. Blanc 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 Over. Run” OWASP App. Sec 2004 36

Happy Fathers day & What wakes me up in the morning…. . OWASP App. Sec 2004 37

Links to my stuff about ‘Full Trust Asp. Net’ < Security Guides and White. Papers 4 "Secure Shared Hosting with IIS 5. 0 Version 0. 95. doc" 4 "Security vulnerabilities in ASP. NET V 0. 60. doc" 4 Undocumented ASP. NET Security V 0. 89. doc (110 page document) < Technical Articles 4 Developer. com § ASP. NET's Hidden Dangers § Malware: Is Your Workstation at Risk? 4 Developers. Dex. 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 4 '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 App. Sec 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 < Find. APTC (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 App. Sec 2004 39

I need your help with my OWASP. Net projects!

Questions?