CSCE 548 Buffer Overflow SQL Injection

1. CSCE 548 Buffer OverflowSQL Injection

2. Process Memory Organization • Process memory: 3 regions • Text: fixed by the program, includes code, read-only (attempt to write: segmentation fault) • Data: initialized and uninitialized data • Stack: stores application data and control data • Low-level languages: direct access to application memory

3. Memory Lower memory address Text Data Stack pointer Frame pointer Stack Higher memory address

4. How do applications use the stack?

5. Example void function(int a, int b, int c) { char buffer1[5]; char buffer2[10]; } Void main() { function(1,2,3); }

6. Buffer Overflow Inserting more data into the buffer than it can handle Stack-base attacks most common Most vulnerable languages: C, C++

7. Example cont. void function(char *str) { char buffer[16]; strcpy(buffer,str); } void main() { char large_string[256]; int i; for( i = 0; i < 255; i++) large_string[i] = 'A'; function(large_string); }

8. Exploitation of Buffer Overflow • Lack of input validation • Default case: mistrust input • Never allow input over the maximum length to be stored in a variable • Process input one character, word, or byte at a time • Never leave extra input on the incoming line

9. Types Stack overflow: buffer, which has been declared on the stack, is written to with more data than it was allocated to hold, static overflow, very common Heap overflow: similarly to the stack overflow, it can lead to overflow and corruption, dynamic, may be harder to exploit, common Array indexing error or integer overflow: unchecked index is a signed/unsigned integer mismatch where a negative number was supplied to an array index

10. Cases and Effects Overwriting local variables  change the program’s behavior Overwriting a return address  execution will resume at the attacker’s specified address, executing the attacker’s code Overwriting function pointers or exception handlers (note, heap: overwrites memory allocation linkage, such as malloc)

11. Cases and Effects Allocated page: Unused memory: nothing happens… …at least, nothing visible happens until you try to use that memory Corruption and invalid results Potentially change local variables Administrator = true Potentially change exception handler or function pointer to execute arbitrary function call jmp_buf / SEH

12. Controlling Program Flow Controlled corruption of the stack allows an attacker to exploit buffer overflows Most commonly exploited buffer overflow – stack based Writing into function arguments (inputs) Writing into the return address Jump to arbitrary address – alter program flow Execute arbitrary code Including attack payload in the buffer!

13. Problems for Attackers Find the location of the buffer Not a big issue, since the code is usually loaded in the same place for performance Use a “NOP sled” Pad the payload with NOP (no operation) instructions, or effectively NOP instructions Jump anywhere into the NOP sled to get to the payload

14. Defensive Measures Canaries Pad buffers with a random, secret value determined at compile time or runtime Check to see if the secret value is the same before allowing transfer of control If you smash the boundaries of the array on the stack, how do you know what the values are?

15. Defensive Measures Write xor execute Mark pages as executable code or data von Neumann architecture  Harvard architecture Prevent data from being executed Buffers are data, thus not executable

16. Defensive Measures ASLR Randomize locations for loading of code Requires compiler, linker, and runtime support for position-independent code (PIC) Prevent attackers from being able to jump reliably to function calls or payload in the stack Why? Because regular code is linked in by the runtime linker whereas the payload is not

17. Defensive Measures Stop using unsafe code! strcpy  strlcpy strncat  strlcat scanf  fgets on %s gets  fgets Use a safer language Anything with bounds checking – Java, C#, VB.net, Python, Perl, Ruby, PHP, D… …but be careful when calling C/C++/asm libraries

18. Defensive Measures Input validation Allow only input that you expect Example: [a-zA-Z0-9]+ on usernames Prevent some shellcode Run static code analyzers Detects use of unsafe (unbounded) functions

19. Sin # 4 SQL Injection

20. Introduction • SQL Injection is a “code defect” • E-commerce applications are often targeted • PII (Personally Identifiable information)‏ • Threat • Compromise machine • Disclose sensitive information • Malicious attack can propagate into the server and eventually the network • All languages using a server interface are affected

21. SQL Injection- Explained • Attacker provides malformed data to application • Application uses data to create a SQL statement via string concatenation • Allows attacker to change the semantics of the SQL query • Susceptible in string parameters in a stored procedure • Why use concatenation? • Don’t know a safer way • Laziness

22. Testing Techniques to Find the Sin • Code Review • Look for code that queries the database • Automated Tools (No replacement for code review) • Watchfire - http://www.watchfire.com (Windows) • Sqlmap – http://www.sqlmap.sourceforge.net (Linux)

23. Spotting SQL Injection Takes user input Does not check user input validity Uses user-input data to query a database Uses string concatenation or string replacement to build the SQL query or uses SQL EXEC command

24. Redemption • Thou shalt never trust input to SQL statements • Always validate • Use regular expressions to parse input • Use prepared or parameterized SQL statements • Use placeholders or binding

25. Conclusions SQL injection is a code exploitation technique. Exploits security vulnerabilities occurring SQL string parsing. Always validate user input. Use code review and automated testing tools.

26. Defenses • Primary Defenses: • Option #1: Use of Prepared Statements (Parameterized Queries) • Option #2: Use of Stored Procedures • Option #3: Escaping all User Supplied Input • Additional Defenses: • Also Enforce: Least Privilege • Also Perform: White List Input Validation

27. Analysis Tools • Free Tools • Usually designed toward a specific back end database • Lack of product support • Lack of statistic collecting • Usability • Purchased Tools • Policy Based • Better support • Cost

28. Purchased Tools • N-Stalker (free version available, http://www.sharewareconnection.com/n-stalker-web-app-security-scanner-free-edition.htm ) • Policy Based Driven Engine • Able to create its own False Positive filter • Able to run reports and keep a database of vulnerabilities • GUI Based System • Requires a subscription service

29. Free Tools: SQLiX • SQLiX uses multiple techniques • conditional errors injection • blind injection based on integers, strings or statements • MS-SQL verbose error messages ("taggy" method) • SQLiX using UDF (User defined functions) • SQLix is able to identify the database version and gather sensitive information for the following SQL servers: MS-Access, MS-SQL, MySQL, Oracle and PostgreSQL. • SQLiX contains an exploit module to demonstrate how a hacker could exploit the found SQL injection to gather sensitive information

30. Integer Overflows

31. Arithmetic Operations • Number system: base, radix • 724.5 == 7102 + 2 101 +4 100 +5 10-1 • Binary, Octal, Hexadecimal representation • Fixed point representation • Sign, magnitude, decimal point • Complements: represent negative numbers • r’s complement -- 2’s complement • (r-1)’s complement – 1’s complement • 1’s complement of 1010 is 0101 • 2’s complement of 1010 is 0101 + 1 = 0110

32. Binary Fixed Point • Positive number: 0 and the magnitude by a positive binary number • Negative number: 1 (sign) and • Signed magniture • Signed 1’s complement • Signed 2’s complement • +9: 0 001001 • -9: • Signed magnitude: 1 001001 • Signed 1’s complement: 1 110110 • Signed 2’s complement: 1 110111

33. Overflow • Two numbers of n digit each are added and the sum occupies n+1 digits • True for binary or decimal numbers, signed or unsigned • Cannot occur after an addition if one number is positive and the other is negative • Using sign-magnitude representation, the overflow can be detected by the carry out of the number bit • Adding 2’s complement, the sign is treated as part of the number, therefore the carry out does not indicate overflow

34. Problems with overflow: Fixed size registers Most computers check for register overflow  overflow flip-flop

35. C/C++ Data Types Source: http://hubpages.com/hub/Data-Types-in-C-Language

36. Type Casting Converting an expression of a given type into another type is known as type-casting. Implicit Explicit Example: Unsigned int to Larger unsigned int Best case (no worries) 1011 0001 (177) #### #### #### #### 0000 0000 1011 0001 (177)

37. Casting Operations Signed int to Larger unsigned int Value is first sign-extended, then cast Positive numbers behave normally Negative numbers may cause unexpected results 1011 1101 (-67) #### #### #### #### 1111 1111 1011 0001 (65,457)

38. Casting Operations Unsigned int to Same-Size signed int Bit pattern is preserved New value depends on original sign bit 1011 0011 (179) #### #### 1011 0011 (-77)

39. Casting Operations Downcast Truncates original value Data loss may occur Value may become negative 0000 1011 0110 1100 (2,924) #### #### 0110 1100 (108)

40. Implicit Casting Operators may cause implicit casting Operators (+,-,*,/,%,&,|,^,&&,||,!) follow these rules: If either operand is an unsigned long, both are upcast to an unsigned long. Otherwise, both operands are upcast to an int and the result is an int. Source: 19 Deadly Sins. Howard, Leblanc, Viega [2005]

41. SecurityConcerns Integer overflows may lead to buffer overruns Memory allocation Array indexing Unexpected control flow Crash

42. Mitigation Understand casting (explicit / implicit, sign-extension) Understand data types (signed / unsigned, range) Understand operators (upcasting, return types) Verify user input Don't depend on your compiler