Applications. Cloud. See voting example (DC Internet voting pilot) Select * from userinfo WHERE id = %%% (variable)

Transcription

1 Software Security Requirements General Methodologies Hardware Firmware Software Protocols Procedure s Applications OS Cloud Attack Trees is one of the inside requirement 1. Attacks 2. Evaluation 3. Mitigation Basic Attacks on software 1. Code injection attacks i. Command line injection See voting example (DC Internet voting pilot) ii. Sql injection Select * from userinfo WHERE id = %%% (variable) We can construct this by first constructing a string and then executing it: string = SELECT * from userinfo WHERE id = + var + ; exec (string) And then if var is malicious instantiated, for example: var = 1; DROP TABLE userinfo Both commands (the SELECT and the DROP TABLE) will execute. The variable could end up this way due to user input. iii. HTML Guestbook Hi there <script> malicious.js </script> 2. Overflow Attacks i. Stack buffer overflow

2 Stack has all sorts of useful data in it Stack contains local variables, return addresses, functions, pointers, exception handlers Return address is the most common one Program [code data heap stack] 00 Main 01 F1 ( ) 20 F2 ( ) 30 HEAD 89 Return Buffer Return 99 NOOP Code What the attackers need to know? They need to know the following three things to conduct a stack buffer overflow 1) Know where buffer starts 2) Know where return is (+10) 3) Optional Know what original return value is i-e (10). (It may or may not be important depends on scenario of what you wants to do). It stops program from crashing. ii. Heap Overflow Heap contains data structures object pointers Abuse malloc/free 3. Return Oriented Programming Attack It is an advance attack. One prevention technique to combat code injection is to separate data from executable code (e.g stack is not executable) i. Data Execution Prevention (DEP) Assume all code is fixed (we can t change it so it is in read only memory) Also assume that no user supply data will ever be executed ii. Hardcoded Program

3 We have some routines and sub-routines Routines Gadgets (tail end of the code) return return return return return Normal Jump (Using buffer overflow) Ø We can jump into sub-routine but must run them until they return Ø Examine the tail end of every sub-routine (everything before a return) Ø You may also misalign the code Real (byte) = id bc, 2, ret Attack: Jump in at = id (bc) a, noop, ret Ø Collect interesting sets of operations Gadgets Build a collection of gadgets Turning completeness What kind of gadgets can we build? Evaluations We are at the mercy of the available code Anything that ends with a return is a potential gadget. Requires just one buffer overflow to insert a chain of addresses Techniques developed to do two things 1) Evaluate your code (give source code)

4 2) Evaluate someone else s code (e.g malware detection) 1. Static Analysis Just look at the code we don t run it Examine the code with an automated tool Find unbounded buffers, unsanitized inputs etc. Hard to make it inter-procedural and path sensitive Result errors (many false positives, some true negatives) Example: Fortify (HP) 2. Dynamic analysis Run the code Only see your chosen execution path Might not trigger bad behavior Does not have full code coverage Input generation is hard Fuzzing Smart fuzzing: where you start with a normal input Mutate it slightly and randomly Ø Static analysis and dynamic analysis are things we developed to find different types of bugs, e.g: not security bugs, however they application to security 3. Taint Analysis Go through the code and taint all variables that meet a rule Rule example: user supplied data When these variables interact with the other portions of the code, you taint any data that depends on the user supplied variables as well It is mostly used as a monitoring tool a run time, however can be used for analysis Mitigation Protects data from being executable (protects against code injection, some buffer overflow and NOT ROP 1. Address space layout randomization (ASLR) (Common) [code data heap stack] Put it at random locations Do this at runtime so every time you run it has different randomization It prevent buffer overflow It prevent ROP It does not prevent Code Injection

5 In Practice ASLR can often be bypassed. 2. Error correcting code (canarg) (Not Common) Place an error correcting code between buffer and return and check it doesn t get over written. 3. Encrypt Return Address (Not Common) Encrypt return address. 4. Control Flow Integrity Instrument your code with additional functions checked as it is running Run tool which will make your software run in more specific way Run at compile Almost 90% of ROP gadgets are eliminated Example Ø 3 functions in our program bool lt (int x, int y) { ret x<y } bool gt (int x, int y) { ret x>y } sort2 (int a[ ], int b[ ], int len) { sort (a, len, lt); sort (b, len, gt); } Ø Define a control Flow graph sort2 ( ) sort gt lt call sort call R (R is register with

6 call sort pointer to lt or gt) ret ret ret ret 1. Direct Call (ok) 2. Indirect call (Unique Label) 3. Returns (label return point) sort2 ( ) call sort label xyz call sort label xyz ret ABC sort ( ) call R, JXR label FZO ret xyz lt ( ) label JXR gt label JXR ret FZO ret FZO