Day 1
Security basics
What is security?
Threat and risk
Types of threats against computer systems
Consequences of insecure software
Constraints and the market
Bugs, vulnerabilities and exploits
Categorization of bugs
- Seven pernicious kingdoms
- Common Weakness Enumeration (CWE)
- CWE/SANS Top 25 Most Dangerous Software Errors
- SEI Cert Secure Coding Guidelines
- Vulnerabilities in the environment and the dependencies
Buffer overflow
x86 assembly and calling conventions
- X86 assembly essentials
- Registers and addressing
- Instructions
- Calling conventions on x86
- Calling convention – what it is all about
- The stack frame
- Prologue and epilogue
- Stacked function calls
- Recursion
Buffer overflow on the stack
- Buffer overflow – basics
- Buffer overread and overwrite
- Stack smashing
- Exploitation – Hijacking the control flow
- Lab – Buffer overflow 101, code reuse
- Exploitation – Injecting a shellscript
- Lab – Code injection, BoF exploitation with a shellcode
- Buffer overflow on the heap
- Buffer overflow on the heap – an example exploitation
- Lab – Heap overflow
- Heap overflow best practices
- Case study – Heartbleed
- Lab - Heartbleed
- Pointer subterfuge
- Pointer manipulation
- Write-what-where
- Modification of jump tables
- Hijacking GOT and RELRO protection
- Overwriting function pointers
- Lab – Overwriting virtual function table
- Some typical mistakes leading to BoF
- Off-by-one
- Allocating nothing
- String length calculation mistakes
- Lab – Analyze UTF-8 encoding
- String termination confusion
- Lab – String termination confusion
- Other typical BoF weaknesses
BoF protection best practices
- Safe and unsafe function
- base_string and std::string
- Some less-known dangerous function
- Lab – Fixing buffer overflow
- Compiler options and instrumentation
- Using FORTIFY_SOURCE
- Lab – Effects of FORTIFY
- Compile-time instrumentation
- Stack smashing protection
- Detecting BoF with the canary
- Argument cloning
- Stack smashing protection on various platforms
- The changed prologue and epilogue
- Lab – Effects of stack smashing protection
- Runtime protection
- Runtime instrumentation
- Address Space Layout Randomization (ASLR)
- ASLR on various platforms
- Lab – Effects of ASLR
- Circumventing ASLR – NOP sledging
- Heap spraying
- Non-executable memory areas
- The NX bit
- Write-xor-execute (W^X)
- NX on various platforms
- Lab – Effects of NX
- NX circumvention – Code reuse attacks
- Arc Injection – Return-to-libc
- Lab – Exploit return-to-libc
- Cascading return-to-libc
- Return Oriented Programming (ROP)
- Lab – ROP demonstration
- Whatever Oriented Programming
- Protection against ROP
Day 2
Common software security weaknesses
Input validation
- Input validation principles
- Blacklists and whitelists
- Validation with regex
- What to validate – the attack surface
- When to validate – validation vs transformations
- Where to validate – defense in depth
- Injection
- Injection principles
- Injection attacks
- Code injection
- Command injection
- Lab – Command injection
- Command injection best practices
- Case study – Shellshock
- Lab - Shellshock
- Process control – library injection
- DLL hijacking
- Lab – DLL hijacking
- Injection best practices
- Input validation
- Output sanitization
- Encoding and escaping the output
- Encoding challenges
- Integer handling
- Representing signed numbers
- Integer visualization
- Integer problems
- Integer overflow
- Lab – Integer overflow
- Case study – Android Stagefright
- Signed / unsigned confusion
- Lab – Signed / unsigned confusion
- Integer truncation
- Case study – Wannacry
- Best practices
- Upcasting
- Precondition testing
- Postcondition testing
- Using big integer libraries
- Lab – Integer handling best practices
- The AIR integer model
- Other numeric problems
- Division by zero
- Working with floating-point numbers
- Format string issues
- The problem with printf()
- Format specifiers of printf()
- Exploiting the printf format string weakness
- Lab – Exploiting format string
- Some other input validation problems
- Improper address validation in IOCTL
Security features
- Authentication
- Authentication basics
- Authentication weaknesses
- Case study – PayPal two factor authentication bypass
- User interface best practices
- Password management
- Inbound password management
- Storing account passwords
- Plaintext passwords at Facebook
- Lab – Why just hashing passwords is not enough?
- Dictionary attacks and brute forcing
- Salting
- Adaptive hash functions for password storage
- Password in transit
- Password policy
- Weak and strong passwords
- Using passphrases
- Lab – Applying a password policy
- The Ashley Madison data breach
- The dictionary attack
- The ultimate attack
- Exploitation of the results and the lessons learnt
- Outbound password management
- Hard coded passwords
- Lab – Hardcoded password
- Password in configuration file
- Protecting sensitive information in memory
- Challenges in protecting memory
- Heap inspection
- Compiler removal of memory clearing code
- Sensitive information in non-locked memory
- Authorization
- Access control basics
- Missing or improper authorization
- File system access control
- Improper file system access control
- Ownership
- chroot jail
- Using umask()
- Linux filesystem
- LDAP
- Access control in databases
- Lab – Database access control
- Privileges and permissions
- Permission manipulation
- Incorrect use of privileged APIs
- Exposed IOCTL with Insufficient access control
- Permission best practices
- Principle of least privilege
- Principle of separation of privileges
- Permission granting
- Privilege dropping
- Handling of insufficient privileges
- Information exposure
- Exposure through extracted data and aggregation
- System information leakage
- Leaking system information
- Relying on accessibility modifiers
- Lab – Inappropriate protection by accessibility modifier
- Information exposure best practices
- UI security
- UI security principles
- Sensitive information in the user interface
- Misinterpretation of UI features or actions
- Insufficient UI feedback
- Relying on hidden or disabled UI element
- Lab – Hidden or disabled UI element
- Insufficient anti-automation
Day 3
Common software security weaknesses
Time and state
- Thread management best practices
- Thread management best practices in C/C++
- Race conditions
- Race condition in object data members
- Lab – Race condition
- File race condition
- Time-of-check-to-time-of-usage (TOCTTOU)
- Lab - TOCTTOU
- Insecure temporary file
- Potential race condition in C/C++
- Race condition in signal handling
- Forking
- Bit-field access
- Mutual exclusion and locking
- Deadlocks
- Lab – Locking
- Synchronization and thread safety
- Synchronization and thread safety in C/C++
Errors
- Error and exception handling principles
- Error handling
- Returning a misleading status code
- Error handling in C
- Error handling in C++
- Information exposure through error reporting
- Exception handling
- In the catch block. And now what?
- Empty catch block
- Best practices for catch blocks
- Overly broad throws
- Catching NULL pointer exceptions
- Exception handling in C++
- Lab – Exception handling mess
Code quality
- Data
- Type mismatch
- Lab – Type mismatch
- Function return values
- Unchecked Return Value
- Case study – MacOS X password hash change
- Omitted return value
- Returning unmodifiable pointer
- Initialization and cleanup
- Uninitialized variable
- Constructors and destructors
- Class initialization cycles
- Declaration and allocation issues in C
- Allocation and deallocation in C++
- Unreleased resource
- Array disposal
- Lab – Mixing delete and delete[]
- Object oriented programming pitfalls
- Accessibility modifiers
- Inheritance and overriding
- Implementing the copy operator
- Mutability
- Cloning
- Cloning sensitive classes – object hijacking
- Object hijacking – best practices
- Serialization
Wrap up
Secure coding principles
- Principles of robust programming by Matt Bishop;
- Secure design principles of Saltzer and Schröder;
- Some more principles.
And now what?
- Further sources and readings;
- .NET and C# resources;
- Further labs and challenges to do.
