2017년 1월 27일 금요일

Low-Level Software Vulnerabilities

1. Vulnerability
 - High-level Vulnerability: Security
  e.g. Authentication, Privilege Escalation, Inappropriate Authorisation, Access Control, Integrity etc
 - Low-level Vulnerability: Safety
  e.g. Buffer Overflow, Heap-based exploitation, Stack-based exploitation, Integer overflow, File / Memory management  etc

2. Buffer Overflow

 : a bug that affects low-level code, typically in C and C++, with significant security implications
 - an attacker can alter the situations that cause the program to do much worse than a simple crash
  e.g. Steal private information / Corrupt valuable information / Run code of the attacker's choice

 - Buffer: Contiguous memory associated with a variable or field

 - Overflow: Put more into the buffer that it can hold

 - Heap Overflow

 - Integer Overflow
 - Read Overflow / Format String Overflow
   e.g. Heartbleed

http://www.thegeekstuff.com/2013/06/buffer-overflow/?utm_source=feedly


3. Code Injection

 : the exploitation of a computer bug that is caused by processing invalid data
  1) Create the injection vector
   the vector = Shellcode address + Shellcode + NOP sled
  2) Get injected code to run

https://www.techopedia.com/definition/20022/code-injection


4. Defence Strategies

 - Avoid the buffer overflow entirely
  * Secure coding: use C functions that support bounds checking
   ! Automatic Techniques



 Stack Canaries
Non-Executable Stacks
ASLR
(Address Space Layout Randomisation)
 Goal  make sure we detect overflow of a return address  prevent an attacker to execute his code  prevent the attacker from guessing the memory address of his code
 Idea  - The functions' prologues insert a canary on the stack
 - The canary is a value inserted between the return address and local variables
 - Mark data memory as non-executable  - Randomise the address in memory of all code, heap, stack, global variables, etc
 - Buffer overflow: the attacker does not know the address of shellcode
 Advantages  - Useful to protect against buffer overflows that overwrite the return address  - Prevent only execution of malicious code on the stack
 Limitations  - Do not protect the program from exploits that modify variables, object pointers, or function pointers
 - Do not protect against heap buffer overflow
 - Do not prevent buffer overflow attacks that modify return address, variables, object pointers, or function pointers
 - Do not prevent buffer overflow in the heap or data segments of the memory of the program
 - May affect performance
 - Do not prevent the return address on the stack from being overwritten
 - Do not prevent attacks where the attacker overwrites data

http://security.stackexchange.com/questions/20497/stack-overflows-defeating-canaries-aslr-dep-nx


  * Code Review



 Static Analysis
 Dynamic Analysis
 Definition  all about what we can learn from the program without running it  all about what we can learn from the program while it is running
 What can you find?  - Checking against pre-defined rules
  e.g. Flow issues, Security issues, Memory issues, Input issues, Resources leaks
 - Runtime error detection
 - Memory issues/leaks
 - Input / output validation issues
 - Pointer arithmetic errors
 - Performance
 What cannot you find?  - non-trivial properties of programs are undecidable  - Anything off the runtime path
  e.g. input dependent
 Tools  - Source code analysers
 - Byte code analysers
 - Binary code analysers
  => Intermediate Representations
    * Abstract Syntax Trees (AST)
    * Control Flow Graphs (CFG)
 - Valgrind: a tool suite that provides a number of debugging and profiling tools
   esp. Memcheck
 - Pin: a dynamic binary instrumentation framework => Pintools
 Limitations  - False positives: the tool reports bugs that program does not contain
 - False negatives: the program contains vulnerabilities that the tool does not report
 - No false positives or negatives on a given run
 - Do not need source code
 - Clear which path was taken
 - Can be used on live code

 - Detect vulnerabilities only on execution path

 - Significant computational resources are required to perform the analysis
 - It is more difficult to track back a vulnerability to its exact location in the code

http://www.testingexcellence.com/static-analysis-vs-dynamic-analysis-software-testing/


  * Testing

 - Make the buffer overflow harder to exploit

5. Types of Malware

 - Target: Mass, Specific
 - Forms: Trojan Horse, Virus, Worm etc.

 - Characteristics

  * Information stealing: Keyloggers, sniffers, Password stealers, Intercepting etc
  * Remote access: Backdoor, Botnet etc
  * Ransomware: Once everything is encrypted, inform the user and demand money
  * Rootkit: Hooking into OS calls and changing their behaviours
  * Scareware: Generally, disable general computer operation
  * Downloader / Launcher: bundle other malware

 - Common techniques

  * Persistence: Malware generally needs to persist between system boots
  * stealth: camouflage against legitimate system files
  * Packing
  * Obfuscation
  * Rootkits
  * Anti-analysis

 - Basic Static Analysis: Examine the PE file itself

  * Signature: What was it compiled with?
   => Detect it Easy
  * Structure: Is it packed?
  * Sections: How is the file made up?
   => PEStudio
  * Metadata: what other information is there?
  * Certification: Has the file been digitally signed?
  * Imports: What does it use
   => Dependency Walker
  * Exports: What does it make available?
  * Strings: What text does it contain?
   => Strings
  * Resources: What icons, menus, dialogs does it have
   => Resource Hacker

 - Advanced Static Analysis: Taking the malware on the disk in binary form and disassembling it into assembly code

  => IDA

http://usa.kaspersky.com/internet-security-center/internet-safety/what-is-malware-and-how-to-protect-against-it#.WHuPIRvJxnI

댓글 없음:

댓글 쓰기