Threat Model
1
STRIDE approach
• Spoofing, Tampering, Repudiation, Information Disclosure, Denial of
Service, and Elevation of Privilege
Threat
Spoofing
Tampering Repudiation Information disclosure Denial of service Elevation of privilege
Security Property Authentication Integrity Non-repudiation Confidentiality Availability Authorization
• To follow STRIDE, you decompose your system into relevant components, analyze each component for susceptibility to the threats, and mitigate the threats
2
Identify threats
• Experts can brainstorm
• How to do this without being an expert?
– Use STRIDE to step through the diagram elements – Get specific about threat manifestation
Threat
Spoofing
Tampering Repudiation Information Disclosure Denial of Service Elevation of Privilege
Property we want Authentication
Integrity Nonrepudiation Confidentiality Availability Authorization
3
Threat: Spoofing
Threat Property Definition
Example
Spoofing
Authentication
Impersonating something or someone else
Pretending to be any of billg, microsoft.com, or ntdll.dll
4
Threat: Tampering
Threat Property Definition Example
Tampering
Integrity
Modifying data or code
Modifying a DLL on disk, or a packet as it traverses the LAN
5
Threat: Repudiation
Threat Property Definition
Example
Repudiation
Non-Repudiation
Claiming to have not performed an action
“I didn’t send that email,” “I didn’t modify that file,” “I certainly didn’t visit that Web site, dear!”
6
Threat: Information Disclosure
Threat Property Definition
Example
Information Disclosure Confidentiality
Exposing information to someone not authorized to see it
Allowing someone to read the Windows source code; publishing a list of customers to a Web site
7
Threat: Denial of Service
Threat Property Definition Example
Denial of Service
Availability
Deny or degrade service to users
Crashing Windows or a Web site, sending a packet and absorbing seconds of CPU time, or routing packets into a black hole
8
Threat: Elevation of Privilege
Threat Property Definition
Example
Elevation of Privilege (EoP) Authorization
Gain capabilities without proper authorization
Allowing a remote Internet user to run commands is the classic example, but going from a “Limited User” to “Admin” is also EoP
9
Process diagramming
• Use DFDs (Data Flow Diagrams)
– Include processes, data stores, data flows – Include trust boundaries
– Diagrams per scenario may be helpful
• Update diagrams as product changes
• Enumerate assumptions, dependencies • Number everything (if manual)
10
Diagram elements: examples
Data Flow
External Entity
• • •
Process
DLLs
EXEs
COM object Components Services
Web Services Assemblies
Trust Boundary
• •
Data Store
Database
File
Registry Shared Memory Queue / Stack
People • Other systems • Microsoft.com •
• • • •
• • •
Function call • Network traffic • Remote • Procedure Call • (RPC)
•
Process boundary File system
11
Diagrams: trust boundaries
• Add trust boundaries that intersect data flows
• Trust boundaries represent the border between trusted and untrusted elements
– Trust is complex. You might trust your mechanic with your car, your dentist with your teeth, and your banker with your money, but you probably don’t trust your dentist to change your spark plugs.
• Points/surfaces where an attacker can interject
– Machine boundaries, privilege boundaries, integrity boundaries are examples
of trust boundaries
– Threads in a native process are often inside a trust boundary, because they share the same privileges, rights, identifiers and access
• Processes talking across a network always have a trust boundary
– May create a secure channel, but they’re still distinct entities – Encryptingnetworktrafficisan‘instinctive’mitigation
• But doesn’t address tampering or spoofing
12
Context diagram – the highest layer
Resource integrity information Integrity App
Analysis Instructions
Administrator
13
Different threats affect each element type
ELEMENT
External Entity
STRIDE
?
Process
Data Store
Data Flow
14
Standard mitigations
Spoofing
Authentication
• Cookie authentication
• Kerberosauthentication
• PKI systems such as SSL/TLS and
certificates
• Digital signatures
•Digital signatures •Hash
• Secure logging and auditing • Digital Signatures
• Encryption •Filtering
• Quotas
•Group or role membership
• Privilege ownership
15
Tampering Repudiation
Information Disclosure
Denial of Service Elevation of Privilege
Integrity
Non Repudiation Confidentiality
Availability Authorization
• Buffer overflow
16
How malicious user input can affect program execution
Buffer Overflow (or overrun / overread) vulnerabilities
•Program allocates a buffer of length N for user input
•Copies input data without checking input length – If length(input) > buffer length N:
•Excess input will overwrite memory addresses after buffer
•Normally, with honest users, causes a program crash
•But, if carefully controlled, can be used by hacker to:
– Overwrite critical program variables (Demo example 1)
– Overwrite function return address to point to either desired existing program code (Demo example 2) or code injected by hacker, e.g. a root user shell – “shellcode” (example 3)
17
Process Memory Segments
Memory is divided into segments for storing different types of information: •Text (code) segment: program code and fixed program constants
•Data segment: Initialized global and static variables
•BSS (Block Started by Symbol) segment: Uninitialized global and static variables •Heap segment: dynamic program data (e.g., use in C program with malloc())
•Stack segment: function local variables, arguments, context (calling function return address/stack frame) – can also contain code!
18
Example: program memory layout
example.c:
int x =100;
int main() {
int a = 2; float b = 2.5; static int y;
int *ptr = (int *) malloc
(2*sizeof(int));
ptr[0]=5;
ptr[1]=6;
free(ptr);
return 1; }
• Data segment: x
• BSS segment: y
• Stack: a, b, ptr
• Heap: ptr[0], ptr[1]
• Buffer overflow can happen on both stack and heap!
19
•
Stack Segment
How functions are called: Stack
– Stores each called function’s local variables/context/arguments in a stack frame
– Grows from high addresses low addresses:
• Stack pointer (ESP register) points to current top of stack
• Push instruction inserts value on top of stack, decrements ESP
• Pop instruction removes a value from top of stack, increments ESP
flag offset:
[ebp-4]
ebp reg.
ebp: Current
frame pointer
Stack grows
Buffer Overflows: Example 1
auth_overflow.c:
int check_authentication(char *password) { int auth_flag = 0;
char password_buffer[16];
strcpy(password_buffer, password);
if(strcmp(password_buffer, “brillig”) == 0) auth_flag = 1;
if(strcmp(password_buffer, “outgrabe”) == 0) auth_flag = 1;
return auth_flag;
Memory Contents after strcpy of password “ABCDEFGHIJKLMNOPQ”
Address
0xbffff7a0
0xbffff7a8
0xbffff7b0
0xbffff7b8
0xbffff7c0
0xbffff7c8
0xbffff7d0
Contents
Comments
password_buffer
auth_flag
SFP
0x44434241
0x48474645
0x4c4b4a49
0x504f4e4d
0x00000051
0xbffff7c0
0xa0003300
0xb0005300
}
int main(int argc, char *argv[]) { if(argc < 2) {
printf("Usage: %s
} if(check_authentication(argv[1])) {
printf(“\n-=-=-=-=-=-=-=-=-=-=-=-=-=-\n”); printf(” Access Granted.\n”); printf(“-=-=-=-=-=-=-=-=-=-=-=-=-=-\n”);
} else { printf(“\nAccess Denied.\n”);
Overfflow
by 1 byte!
}
}
Buffer allocated for passwords up to 16 chars length: longer passwords overflow into auth_flag local variable
Buffer Overflows: Example 2
What if password_buffer is stored after local vars? buffer overflow cannot overwrite auth_flag variable.
Solution: attacker overwrites ret. address to jump to desired code!
auth_overflow2.c:
int check_authentication(char *password) {
char password_buffer[16]; int auth_flag[1]; auth_flag[0] = 0;
strcpy(password_buffer, password);
if(strcmp(password_buffer, “brillig”) == 0) auth_flag[0] = 1;
if(strcmp(password_buffer, “outgrabe”) == 0) auth_flag[0] = 1;
return auth_flag[0];
}
int main(int argc, char *argv[]) {
if(argc < 2) {
printf("Usage: %s
}
if(check_authentication(argv[1])) {
printf(“\n-=-=-=-=-=-=-=-=-=-=-=-=-=-\n”); printf(” Access Granted.\n”); printf(“-=-=-=-=-=-=-=-=-=-=-=-=-=-\n”);
Memory Contents after strcpy of password
“\xbf\x84\x04\x08” x 10
Address
0xbffff7a0
0xbffff7a8
0xbffff7b0
0xbffff7b8
0xbffff7c0
0xbffff7c8
0xbffff7d0
Contents
Comments
auth_flag
password_buffer
SFP
check_auth ret addr
0x00000000
0x080484bf
0x080484bf
0x080484bf
0x080484bf
0x080484bf
0x080484bf
0x080484bf
0x080484bf
0x080484bf
0x080484bf
} else {
printf(“\nAccess Denied.\n”);
} }
attacker wants to return exec. here: address 0x80484bf
Attacker uses repeated return address to avoid needing to know exact location of check_auth ret addr relative to buffer start
Buffer Overflows: Example 3
What if we want to change ret. address to jump to our own hacker code (in this case, shellcode for root user access)?
•Put shellcode bytes in the overflowing input string, followed by repeated ret. address
•Set ret. addr = address A of shellcode beginning in buffer
•How do we know what is A exactly? We may not, but may estimate it:
•Use a “NOP sled” : insert a sequence of L consecutive NOP (do nothing) instructions (opcode = 0x90) before actual shellcode.
Memory Contents after strcpy overflow
Address
0xbfffe000
0xbfffe010
Address A: 0xbfffe01c
Contents
0x90909090
0x90909090
0x90909090
0x90909090
0x90909090
0x90909090
0x90909090
0x3158466a
0xcdc931db
….
0xbf80cd0b
0xbfffe010 23 0xbfffe010
0xbfffe010
0xbfffe010
….
NOP sled
Shell Code
•Underestimating A by up to L bytes will still jump somewhere into NOP sled and will execute shellcode.
Repeated ret. Addr.
main() ret. Addr.
• SQLinjection
24
•
Common Threats (Our Focus) Attacks on Server side (Week 9 lab):
– Attacksetting:Attackerinteractsaswebapp.clientwithserverweb application
– Goal: Inject attacker code to modify web app. behaviour on server
– Common Vulnerability: SQL code injection
Attacks on Client side (Week 11 lab):
– Attack setting:
(1) Malicious web app. client attacking another web app. client
(2) Malicious web server attacking a web app. client
– Goal: Inject attacker script into target client web browser to attack client’s interaction with web. app.
– Common Vulnerability: Cross-Site Scripting (XSS)
•
25
•
SQL Injection Vulnerabilities
SQL Injection:
– Lack of user input validation vulnerability
– Allows attacker to directly inject SQL code into SQL database server
– Often gives attacker complete control!
•
How users are supposed to behave: Example: authenticated web site login
– Honest Authorised user’s “proper” behaviour Name: john
Password: monkey
– Misbehaviour by ignorant attacker
Name: john
Password: guess
•Site rejects incorrect login password
26
• •
SQL Injection Vulnerabilities
Attack Example 1: Clever attacker’s misbehaviour Name: john’ —
Password: guess
Why does this work?
– Login verification checked by server by passing a command string to an SQL database interpreter
– Command string consists of a concatanation of SQL language commands and user input data
– Attacker’s password input string contains both data (guess) and command (‘ – -), which is Line Comment
– Attacker’s command string passed to SQL interpreter and executed!
– SELECT * FROM members WHERE username = john’–‘ AND password = ’guess’
This is going to log you as john, because rest of the SQL query will be ignored.
Vulnerable due to invalid assumption by developer: assumed users
will only enter alphabetic characters!
•
27
SQL Injection Vulnerabilities
• “Under the Hood”: Client-Server-Database Setup
Client
Server
Database
Client Web Browser (HTML)
Server Script (PHP)
Database interpreter (MySQL)
HTTP
SQL
28
SQL Injection Vulnerabilities
“Under the Hood” : Vulnerable Server php code $lUsername = $_REQUEST[“username”]; $lPassword = $_REQUEST[“password”];
$lQueryString = ” SELECT * FROM accounts WHERE
username=’ ” . $lUsername . ” ‘ AND
password=’” . $lPassword . “‘” ;
$lQueryStringResult = $MySQLHandler->executeQuery($lQueryString);
Command string $lQueryString passed to SQL interpreter for honest user login (user=john, pwd=monkey):
SELECT * FROM accounts WHERE username=’john’ AND password=’monkey‘
Command string $lQueryString passed to SQL interpreter for attacker login (user=john’ — , pwd=guess):
SELECT * FROM accounts WHERE username=’john’ — ‘ AND password=’guess’
•“–” interpreted by SQL server as “begin comment” command
• ignores following “AND…” password check!
29
SQL Injection Vulnerabilities
• Control of SQL commands in the hands of attacker can lead to even more devastating attacks
• What if the hacker doesn’t know any user’s name? Wants to get ALL users info from Database?
Attack Example 2: Clever attacker’s misbehaviour
Name: bob’ OR 5=5 –-
Password:
Command string $lQueryString passed to SQL interpreter:
SELECT * FROM accounts WHERE username=’bob’ OR 5=5 — ‘
AND password=’guess’
All DB entries satisfy username=’bob’ OR 5=5!
• Lesson: Server app. must not pass user input blindly to SQL server
• Must ensure even malicious user input can not be interpreted as commands
• Use SQL parameterized queries (more details later).
30
SQL Injection Vulnerabilities
• Why just modify existing SQL code?
• Injection Vulnerability allows attacker can do even more damage by injecting own code!
• Attack Example 3: Attacker own code injection Name: bob′ ; DROP TABLE accounts –- Deletes the accounts table…
• Similarly, can insert new tables, users, …
• or even shutdown the whole database:
• Name: bob′ ; shutdown —
31
• •
SQL Injection Vulnerabilities LOTS of variants of SQLi exploits
– Can often be used to bypass simple SQLi countermeasures, such as character escaping filters
Bypassing simple SQLi filter countermeasures:
– In previous attacks, attacker needed to add ‘ character to terminate the data string and start entering commands
– What if the ‘ character is escaped by the application?
• E.g. Application can replace any occurrence of ‘ char by ‘‘
– SQL interprets ‘‘ in a data string as the data character ‘ rather than the string termination symbol (Our previous injection attack examples fail )
29
•
SQL Injection Vulnerabilities
Bypass example: Injection into numeric data
– The application may also accept numeric user input data
– Numeric data can be passed directly to database without ‘ quotes
– E.g. for vulnerable code like
$lQueryString = ” SELECT * FROM customers WHERE
customerID=” . $customerID;
– Attacker input: 1 OR 5=5 –- (no need for quote symbol)
29
•
SQL Injection Vulnerabilities
Another method to bypass escaping: second-order SQLi
– ‘ character in user input string was escaped (replaced by ’’) by web application
– A second-order vulnerability for string inputs may still be exploitable:
• Consider app. registering users in database and then retrieving
• Attack first phase: attacker registers escaped input into database
– Attacker registers into database user name such as: bob‘ OR 5=5 —
– Due to escaping of ‘ character, user name is processed and inserted into database
• No injected code execution in phase 1. But now the stored username string is bob‘ OR 5=5 — without escaping…
•
SQL Injection Vulnerabilities
How to defend effectively against SQLi?
– Filtering (input validation): whitelist untrusted against a safe list
– Input escaping: escape untrusted input so it will not be treated as a command
– Filtering / escaping is tricky / can often be bypassed
Preferred robust solution: parameterized queries
– A.k.a prepared statements
– Fix root cause of injection problem: SQL database treating user data as code
•
35
•
SQL Injection Vulnerabilities
Idea: Application passes SQL statement to SQL server in two distinct phases:
– Phase 1 (pass code): Pass desired SQL statement with placeholders (? Symbol) for data values, e.g.
$stmt = $mysqli-
>prepare(“SELECT District FROM City WHERE Name=?”);
– Phase 2 (pass data): Pass the data values for placeholders, e.g.: $stmt->bind_param(”bob”, $Name);
– Finally, execute and get result, e.g.:
• $stmt->execute(); /* This executes the prepared
statement $stmt */
• $result = $stmt->get_result(); /* Get result into $result */
• $stmt->close(); /* This completes the prepared statement */
– Any malicious user data passed in Phase 2 will be interpreted as data, not
code.
36
• XSS attack
37
What is XSS?
• An XSS vulnerability is present when an attacker can inject scripting code into pages generated by a web application
• Methods for injecting malicious code: – Reflected XSS (“type 1”)
• the attack script is reflected back to the user as part of a page from the victim site
– Stored XSS (“type 2”)
• the attacker stores the malicious code in a resource
managed by the web application, such as a database
38
Reflected XSS attack
1
2
5
Attack Server
Victim client
Victim Server
39
XSS example: vulnerable site
• search field on victim.com:
– http://victim.com/search.php ? term = apple
– search.php is supposed to accept a query and show the results
• Server-side implementation of search.php:
Results for : . ..
Results for apple : .. .
echo search term into response
40
•
Bad input
Consider link: (properly URL encoded)
http://victim.com/search.php ? term =
•
What if user clicks on this link?
Pre-‐setup by attacker Results for
1. Browser goes to victim.com/search.php
2. Victim.com returns
3. Browser executes script: •Sendsbadguy.comcookie forvictim.com
41
Attack Server
www.attacker.com
http://victim.com/search.php ? term =
Victim client
Victim Server
42
www.victim.com
Results for
Stored XSS
Download it
Attack Server
1
Inject malicious
Server Victim
script
Store bad stuff
43
•
Stored XSS using images Suppose pic.jpg on web server contains HTML !
– request for http://site.com/pic.jpg results in:
HTTP/1.1 200 OK
…
Content-‐Type: image/jpeg fooled ya
– IE will render this as HTML (despite Content-‐Type) Consider photo sharing sites that support image uploads
– What if attacker uploads an “image” that is a script?
44
•
Defenses at server
1
2
5
Attack Server
Server Victim
45
Injection Defense • Defenses:
– Input validation
• Whitelist untrusted against a safe list
– Input escaping
• Escape untrusted input so it will not be treated as a
command.
– Use less powerful API
• Use an API that only does what you want • Prefer this over all other options.
46
Input Validation
• Check whether input value follows a whitelisted pattern. For example, if accepting a phone number from the user, JavaScript code to validate the input to prevent server– side XSS:
• This ensures that the phone number doesn’t contain a XSS attack vector or a SQL Injection attack. This only works for inputs that are easily restricted.
47
Input Escaping or Sanitization
• Sanitize untrusted data before outputting it to HTML. Consider the HTML entities functions, which escapes ‘special’ characters. For example, < becomes < .
• Attack input becomes text showing in browser. 48
Use a less powerful API
• The current HTML API is too powerful, it allows arbitrary scripts to execute at any point in HTML.
• Content Security Policy allows you to disable all inline scripting and restrict external script loads.
• Disabling inline scripts, and restricting script loads to ‘self’ (own domain) makes XSS a lot harder.
• See XSS cheatsheet for more attack/defense details https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
49
• Blockchain
50