Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Curious Case of SQLi

10,195 views

Published on

These are the slides from a talk "Curious Case of SQLi" held as part of HackPra 2013 (Germany / Bochum 11th December 2013) by Miroslav Stampar

Published in: Technology
  • Be the first to comment

Curious Case of SQLi

  1. 1. Curious Case of SQLi Miroslav Štampar dev@sqlmap.org
  2. 2. Target (1) • High profile (i.e. very important to be secure) • It was a fancy new Web 2.0 site (lots of Javascript) – while it first appeared as a Flash site • Very little user interaction (but lots of clicking) • Automatic vulnerability scanners reported nothing more than usual nagging (e.g. clickjacking possible, lack of security headers, etc.) • Used Javascript libraries were up-to-date • Custom Javascript parts were clean (e.g. no DOM based XSS, open redirections, etc.)
  3. 3. Target (2) • No user management (everybody is/was anonymous) • Web server was up-to-date • Only attack points suceptable to (malicious) user interaction were: ➢ ➢ Ajax call for user search (let's call it search.asp) search.asp) Ajax call for search within categories (let's call it category.asp) category.asp) • Burp to the rescue
  4. 4. Attack points (1)
  5. 5. Attack points (2)
  6. 6. Typical response
  7. 7. Day #1 (.1) • First tests resulted only with #FAIL • Trashing of values (e.g. foo')><"bar) foo')><"bar) resulted in prolonged HTTP error 500 responses (cca. 90 seconds before server timeout) • '-- resulted with SQLi (response differentiation) • '-- WAITFOR DELAY '0:0:5' resulted in immediate HTTP error 500 response • Though, ' WAITFOR DELAY foobar resulted the same • Usual stuff like ' AND 1=1-- and/or ' OR 2>1-- resulted in prolonged error responses too
  8. 8. Day #1 (.2) • Everything point(ed) that there was some kind of WAF involved (as said, high profile target) • Colleagues told me to "just leave it" • Boss told me that there is no hurry and that I can work on it as much as I want :) • As a sqlmap developer I had an "obligation" to, at least try to, "break it" • I told that I need 1-2 more days to be 100% sure • One of first ideas was to write a SQLi fuzzer that would do the "monkey test" job
  9. 9. Day #1 (.3) • At the end of the working day, left sqlmap (over the night) to test all the parameters • Turned on all possible boundary & payload combinations (--level=5 --risk=3) (--level=5 --risk=3) • Hoped that something usable will turn out of it • During commuting (local overcrowded bus) thought of all the stuff learned through years • ..., WAF bypass tricks, non-ASCII SQLi payloads, non-disclosed SQLi attacks, non-mainstream SQL statements (Love Thy Reference Manual), etc.
  10. 10. Day #2 (.1) • • • • • Tried literary everything in my knowledge domain Lots of delayed responses (very cumbersome) sqlmap was still running (still nothing) Almost quit (during the coffee break) Had a hard look once more into the original requests • That ASC was "provoking" as hell • Tried to Google in hope that something will turn out
  11. 11. Day #2 (.2)
  12. 12. Day #2 (.3)
  13. 13. Day #2 (.4)
  14. 14. Day #2 (.5)
  15. 15. Day #2 (.6)
  16. 16. Day #2 (.7) • Windows Search/Indexing Service can be SQL-ed • Advanced Query Syntax (AQS) #FTW • "AQS is the default query syntax used by Windows Search to query the index and to refine and narrow search parameters" • A basic query searches for items that satisfy a restriction over a property • Users can limit the scope of their searches to specific folder locations or data stores • There is no single reported case of SQLi
  17. 17. Day #2 (.8)
  18. 18. Day #2 (.9)
  19. 19. Day #2 (.10)
  20. 20. Day #2 (.11)
  21. 21. Day #2 (.12)
  22. 22. Day #2 (.13)
  23. 23. Day #2 (.14)
  24. 24. Day #2 (.15) • At the end of the day, summarized findings • Columns of interest (SYSTEMINDEX catalog): (SYSTEMINDEX System.ItemFolderPathDisplay, System.ItemFolderPathDisplay, System.Filename, System.Filename, System.ItemPathDisplay, System.Size, System.ItemPathDisplay, System.Size, System.FileOwner • Some columns had interesting names, but appeared to be always empty (System.Author, (System.Author, System.Comment, System.ComputerName, System.Comment, System.ComputerName, System.Keywords, System.Subject, System.Keywords, System.Subject, System.Title, etc.) System.Title, etc.)
  25. 25. Day #2 (.16) • All in all, nothing special than proof of SQLi and complete file listing with (semi-)interesting attributes • Went home and thought (again) in overcrowded local bus "is that the best I can do?" • That SQL/AQS was really limited (i.e. crippled) • Nothing special is stored inside (than local file listing) from security point of view • "...or, wait a minute..."
  26. 26. Day #2 (.17) • There must be a way how to search files with keywords (it's called Search for a reason) • Came to homeplace and immediatelly read the whole reference manual • Found a special operator: CONTAINS • Using it's wildcard functionality it should be possible to infer the content of files • ...AND System.ItemPathDisplay='...' AND CONTAINS('""a*""')--
  27. 27. Day #3 (.1) • Manually tried file content inference trick and it worked as charm • Usually, user permissions of process running the search would pose a problem (e.g. if run with default anonymous IIS account IUSR_<computer_name>) IUSR_<computer_name>) • Administrator used external VBS script, most probably because of simplicity and usability • It was being run with different (more permissive) credentials
  28. 28. Day #3 (.2) • Retrieved a list of "all" local files (accessible by the searching VBS process) • System directories were missing (e.g. C:Windows & C:Program Files) Files) • Out of the rest, directories that appeared especially interesting were: C:InetpubwwwrootfoobarOld & C:InetpubwwwrootfoobarBackup • Inside both of those there was a web.config file • Started implementing file content inference mechanism using CONTAINS
  29. 29. Day #3 (.3)
  30. 30. Day #3 (.4) • • • • • • • • • • ..AND ..AND ... ..AND ..AND ..AND ..AND ..AND ... ..AND CONTAINS('""a*""').. CONTAINS('""aa*""').. (true) (false) CONTAINS('""ad*""').. (true) CONTAINS('""ada*""').. (false) CONTAINS('""adb*""').. (false) CONTAINS('""add*""').. (true) CONTAINS('""adda*""')..(false) CONTAINS('""add""').. (true)
  31. 31. Day #3 (.5)
  32. 32. Day #3 (.6) • Inference of a configuration file containing a sa password for a (local) SQL Server was a pretty good catch :) • As said, search process was constrained with used user rights (limiting wider exposée) • There were no opened ports than 80 (e.g. port 1433 would be great) • There were no (exposed) administrator pages • Called it a day and finished a test altogether
  33. 33. Conclusion • Use automatic vulnerability scanners only to get a "sense" of target's security settings • To get a deep understanding of target's inner workings you'll always need to "get dirty" • If you have a "hunch" stick with it • You'll most probably be wrong, but you'll learn a lot along the way • In case that your "hunch" was right, you'll have an interesting story to tell (highly subjective opinion ;)
  34. 34. Questions?

×