This document describes a case study of discovering and exploiting a SQL injection vulnerability. Over the course of three days, the researcher tested various parameters of a web application using sqlmap and custom payloads. After initial failures, the researcher realized the application was using Windows Search and leveraged its Advanced Query Syntax to conduct file queries and infer file contents. This allowed retrieving a local web.config file containing a SQL Server password. The researcher concluded that thorough manual analysis is needed to fully understand vulnerabilities beyond just using automated scanners.

1. Curious Case of SQLi
Miroslav Štampar
dev@sqlmap.org

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. 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. Attack points (1)

5. Attack points (2)

6. Typical response

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. 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. 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. 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. Day #2 (.2)

12. Day #2 (.3)

13. Day #2 (.4)

14. Day #2 (.5)

15. Day #2 (.6)

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. Day #2 (.8)

18. Day #2 (.9)

19. Day #2 (.10)

20. Day #2 (.11)

21. Day #2 (.12)

22. Day #2 (.13)

23. Day #2 (.14)

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. 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. 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. 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. 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. Day #3 (.3)

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. Day #3 (.5)

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. 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. Questions?