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 50 % of all computer attacks are some variations of a buffer overflow 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) CSCE 548 -- Buffer Overflow

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 CSCE 548 -- Buffer Overflow

12. Cases and Effects What if it’s on the stack? Allocated page Potentially visible changes Corruption Controlled corruption  Stack smashing CSCE 548 -- Buffer Overflow

13. Cases and Effects What if it’s on the heap? Change the value of variables DisableSecurity = true Clobber pointers (linked lists, trees, …) Alter malloc() data! Change what memory ranges are used/free Use dynamically allocated memory (same location as something previously allocated) as an alias. Useful to overwrite function pointers! CSCE 548 -- Buffer Overflow

14. 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! CSCE 548 -- Buffer Overflow

15. 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 CSCE 548 -- Buffer Overflow

16. 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?v CSCE 548 -- Buffer Overflow

17. 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 CSCE 548 -- Buffer Overflow

18. 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 CSCE 548 -- Buffer Overflow

19. 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 CSCE 548 -- Buffer Overflow

20. 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 CSCE 548 -- Buffer Overflow

21. Sin # 4 SQL Injection

22. 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

23. 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

24. Code Examples C# • string ccnum = “None”; • try{ • SqlConnection sql = new SqlConnection( • @”data source=localhost;” + • “user id=sa; password=pAs$w0rd;”); • Sql.Open(); • string sqlstring = “SELECT ccnum” + • “ FROM cust WHERE id=“ + Id; • SqlCommandcmd = new SqlCommand(sqlstring,sql); • ccnum = (string)cmd.ExecuteScalar(); • }catch (SqlException se){ • // Print Errors • } • }catch (SqlException e){ • // OOops! • }

25. Code Examples continued… • string ccnum = “None”; • try{ • SqlConnection sql = new SqlConnection( • @”data source=localhost;” + • “user id=sa;password=pAs$w0rd;”); • Sql.Open(); • string sqlstring = “SELECT ccnum” + • “ FROM cust WHERE id= %ID%”; • String sqlstring2 = sqlstring.Replace(‘%ID%’,id); • SqlCommandcmd = new SqlCommand(sqlstring,sql); • ccnum = (string)cmd.ExecuteScalar(); • }catch (SqlException se){ • // Print Errors • } • }catch (SqlException e){ • // OOops! • }

26. 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)

27. 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

28. 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 • Public string Query(String ID) • string ccnum; • string sqlstring =“ “; • // only allow valid IDs (1-8 digits) • Regex r = new Regex(@”^\d{1,8}$”); • if (!r.Match(ID).Success) • throw new Exception(“Invalid ID”);

29. 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.

30. 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

31. 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

32. 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

33. 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