留学生作业代写 FIT3173: Security Testing

FIT3173: Security Testing
Dr Fariha Department of Software Systems and Cybersecurity
Faculty of Information Technology

Copyright By PowCoder代写 加微信 powcoder

Learning Outcomes of This Lecture
Know what is security testing and why is it different from functionality testing? Understand security testing approaches
Risk-based security testing
Penetration testing (i.e. black-box testing) and Grey-box testing Know how to use testing tools
Analyse testing specific types of applications
Develop security test plans
Source code review (i.e. white-box testing)

Security testing requires different mind set
Q: what kind of testing is appropriate to ensure software security?
Security Testing Security testing != traditional functionality testing
Software can be correct without being secure
Security bugs are different from traditional bugs
Security testing addresses software failures that have security implications

Security Testing Universe of all possible system capabilities
Capabilities the system should NOT have (Security testing)
Capabilities the system should have (Functional testing)
source: , Testing web security, p. 17

Aim is to discover the circumstances (yellow area) under which each of those functions can be performed.
Security Testing
Capabilities the system should NOT have (Security testing)
Capabilities the system should have (Functional testing)

Risk-based security testing
Source code review: “White-Box” testing
Testing is done at three levels
Manual: human peer review
Penetration testing: “Black-Box” testing, fuzzy testing
With a tool, e.g., static code analysis •
Simulate adversarial behaviours to evaluate security

Quantify the risk associated for each threat (as the ratio of threat’s impact/ ease of exploiting the threat)
Prioritise the risks for mitigation: decompose applications, identify component interfaces, and then identify vulnerability and risks
Risk-based Security Testing
Microsoft Security Development Lifecycle (SDL) Threat Modelling
Identify threats using Threat Modelling (introduced later in Week 11)

Risk-based testing is a well-known approach of security testing
Create Data Flow Diagram (DFD) and identify the security breach boundaries
Identify type of threats and check whether code for any of the possible mitigation method is incorporated.
Risk-based Security Testing

Source Code Review Code walkthrough – also known as “white box testing”
Look for bad practices of programming
Structural issues such as hard coded key/password, leaking information, etc.
Data flow issues, e.g., lack of or improper data validation.
Source code review concentrates on the language based security
Control flow issues – unreleased/unclosed resource streams, denial of services possibility, matching lock/unlock operations, etc.

Require strong experience with both software development and security Should be performed by someone outside the development team
Deliverable: a report targeted at the developers who will fix the identified vulnerabilities
Executive summary
List of technical issues identified Glossary, appendices, indexes, etc.
Source Code Review

Code Review with a Tool • Why a tool?
• Manually finding common bugs in huge pieces of code is too time consuming / error prone
• Can build in tool more common vulnerabilities than a human can keep in the mind…
• Humans better at code understanding / insight than manual search for a pattern • Static code analysers (FlawFinder, Fortify, …)
• Take code as input (static = no code execution)
• Search the code for common coding vulnerabilities • Produce results in output report file

Static Code Analysers
• Find common bugs quickly
• Allow humans to focus on parts of code likely to be risky
• Limitations
• Cannot find design level vulnerabilities
• Cannot make a judgement of importance of a found vulnerability • Only detect vulnerabilities in tool’s “rule database”
• Suffer from errors:
• False positive: reported bugs are not really bugs • False negative: missed reporting a real bug

Example: type checking
short s = 0;
int i = s;
short r = i;
error: possible loss of precision
False Positive

lf some vulnerabilities (zero-day vulnerabilities) are not included in the “rule database” (patterns) …
Call outside A environment is unknown
Other factors, e.g., scheduling of multiple threads
False Negative

Static Code Analysers • Simple (usually free) search-based tools
• Examples: FlawFinder, RATS, ITS4, …
• Search source file for “dangerous functions” known to cause common vulnerabilities, e.g., strcpy(), gets() for buffer overflows
• Produces list of “hits” and ranks them by risk • Better than just pure search
• Ignores commented code
• Risk ranking
• But little attempt to analyse relationships within code

Vulnerability Covered by FlawFinder
• Improper Input Validation
• Improper Limitation of a Pathname to a Restricted Directory (‘‘Path Traversal”)
• Improper Neutralisation of Special Elements used in an OS Command (‘‘OS Command Injection” ) • Improper Restriction of Operations within the Bounds of a Memory Buffer
• Buffer Copy without Checking Size of Input (‘‘Classic Buffer Overflow”)
• Buffer Over-read
• Uncontrolled Format String
• Execution with Unnecessary Privileges
• Use of a Broken or Risky Cryptographic Algorithm
• Concurrent Execution using Shared Resource with Improper Synchronisation (‘‘Race Condition”) • Insecure Temporary File
• Use of Potentially Dangerous Function

Advanced Static Code Analysers
Attempt to improve risk analysis and reduce false positive rate by deeper code analysis than simple analysers
Data Flow Analysis: Identifies user-controlled input that is involved in a dangerous operation (e.g., long user input data copied into fixed-size buffer)
Control Flow Analysis: Identified dangerous operation sequences (e.g., a file is configured properly before use)

• Challenges
Control Flow Integrity
If not, might be compromised
Idea: observe the program’s behaviour – is it doing what we expect it to?
Define “expected behaviour”
• Detect deviations from expectation efficiently
Avoid compromise of the control flow integrity detector

Control Flow Integrity
Control flow graph (CFG)
Define “expected behaviour”
Detect deviations from expectation efficiently
In-line reference monitor (IRM)
Avoid compromise of the detector
Sufficient randomness, immutability

Call Graph
Which functions call other functions

Control Flow Graph
Break into basic blocks Distinguish calls from returns

Monitor the control flow of the program and ensure that it only follows paths allowed by the CFG
CFI: Compliance with CFG Compute the call/return CFG in advance
During compilation, or from the binary
Assuming the code is immutable, the target address cannot be changed
Observation: Direct calls need not be monitored
Therefore: monitor only indirect calls
jmp, call, ret with non-constant targets

Control Flow Graph
Direct calls (always the same target)

Control Flow Graph
Indirect transfer (call via register, or ret)

Implement the monitor in-line, as a program transformation
Insert a label just before the target address of an indirect transfer Insert code to check the label of the target at each indirect transfer
Abort if the label does not match
The labels are determined by the CFG
In-line Monitor

• Constraints:
• return sites from calls to sort must share a label (L) • call targets gt and lt must share a label (M)
• remaining label unconstrained (N)

Defeat CFI? Inject code that has a legal label
Will not work because we assume non-executable data
Modify code labels to allow the desired control flow
Will not work because the code is immutable

Remote code injection, etc.
Nor data leaks or corruptions
CFI Assurances
CFI defeats control flow-modifying attacks
Heartbleed would not be prevented
Presence of self-modifying code
Control modification is allowed by graph

Code Review by Community
selected code review and pull requests from OpenSSL on GitHub

Limits of White Box Testing Tester must have knowledge of the program (e.g., “c” for buffer overflow)
Sometimes, it might not cover realistic cases/conditions in the program
Focus on the current implementation; missing security features cannot be discovered

Approaches for Penetration Testing
Source code reviews – white box testing
Penetration Testing – black box testing
Grey-box testing – combination of both
Evaluate the security of your application weaknesses by simulating malicious attacks

If we characterise functional testing as “testing for positives” then penetration testing is for “testing for negatives”.
Penetration Testing
It is an outside (rather than inside) testing approach
Art of testing an application without knowing the inner workings of the application
Capabilities the system should NOT have (Penetration testing)
Capabilities the system should
have (Functional testing)

Penetration test – point of view of a hacker
Penetration Testing
Function test – point of view of a normal user
It is a type of non-functional testing
application without any authorisation.
For example, one can check if anyone can hack the system or login to the

Penetration Testing

Testing for a negative poses a greater challenge compared to positive.
If a negative test does not discover any fault(s) -> offers only proof that no fault can occur under that (particular) test conditions.
Penetration Testing
But does NOT prove that no fault exist.

Penetration Testing
Enumerating actions with the intention to produce a fault.
• May not be a sound approach to gain the confidence of software security.
This can be done only by experience “hackers”
Q: How to enumerate (all) possible actions?

Penetration Testing • Exploratory – Manual
• Black box security testing without the aid of a tool and guided by the tester’s instinct and experience
• Systematic – Manual
• Black box testing without the aid of tool based upon pre-determined security test plan developed from requirements
• Fuzzing – Automated (a guest lecture on fuzzy testing)
• Black box security testing with the aid of tool to help reduce the repetitive nature of testing tasks .. fuzzing.

Fuzzing testing tools: submit malformed, malicious, and random data to a system’s entry points in an attempt to uncover faults.
Can be easily automated to try a large number of random / semi-random variations
Use combinations of “known-to-be-dangerous” values (known as fuzzy vectors) and random data
for integers: zero, possibly negative or very big numbers (e.g., -1,0,0×100,0x1000,0x7ffffffe,0x7fffffff)
Fuzzy Testing
Tools: google AFL, Microsoft’s SDL MiniFuzz File Fuzzer
for chars: escaped, interpretable characters / instructions (e.g., %s%p%x%d,. 1024d, %.2049d, %p%p%p%p, %x%x%x%x, %99999999999s)

Security Testing Plan Propose a security testing plan based on patterns
Pattern can be used many times but may not appear in exactly the same way.
Design pattern: A description of a recurring problem and a well-defined description of the core solution to the problem
Software security testing plan:
A description of a software vulnerability type that includes a template of a test case that exposes a vulnerability, typically by emulating what an attacker would do to exploit that vulnerability.
Pattern Catalog: A collection of related patterns that apply to the same domain and contain the same elements.

Pattern: Input Validation Vulnerability Test
• Keywords: record, enter, update, create, capture, store, edit, modify, specify, indicate, maintain, customise query, etc. • Targeted Vulnerabilities: SQL Injection, Path Traversal, PHP File Inclusion, etc.
• Test Procedure Template:
1. Authenticateas
2. Open the user interface for ing a