I have manually confirmed an SQLi authentication bypass in a user login portal. The payload itself is quite simple. Can this vulnerability be used to do anything else such as enumerate users or inject a web shell?
1
-
Have you tried using sqlmap on the vulnerable endpoint?– WouterCommented Aug 4, 2022 at 17:21
Add a comment
|
3 Answers
Can this vulnerability be used to do anything else such as enumerate users or inject a web shell?
Maybe, maybe not. Once you bypassed authentication using SQLi you can do what the impersonated user can do - no additional SQLi needed. But if the specific attack vector you've used for authentication bypass can also be used for other attacks depends on the exact vulnerability, the database design, the execution environment ...
answered Aug 4, 2022 at 19:33
-
As I am experienced with using sqlmap, I tried enumerating info from the database, however, I was not successful. my command took the form "sqlmap -u <URL> --data="<data tags>" --dbs– ishy987Commented Aug 5, 2022 at 10:50
-
But the output was quite weird, looking something like: [INFO] retrieved: ~vNp|\r?^_m [INFO] retrieved: }Є~~p|X\x7f莡t\x10\x7f|\x7f~ݺ߿x\x02\n [INFO] retrieved: t%01J|N_\x03\r+\x0fM [INFO] retrieved: J9hd4 Do you have any clue on why the output seems to be so weird? Also the database is an MSQL and the injection command took the form "or 1=1"– ishy987Commented Aug 5, 2022 at 11:11
-
@ishy987: Like I said, it depends on "the exact vulnerability, the database design, the execution environment ..." . Nothing of this is known here. Commented Aug 5, 2022 at 11:13
Probably. It depends on the application (and what input it allows and/or filters), the existence of a WAF, the query you are injecting into, the DBMS used, the configuration/permissions of the DBMS, etc.
In most situations, you should be able to perform a blind SQL injection to extract information from the database. That's because most often, you will be injecting into the WHERE statement of a SELECT query. This will likely allow you to extract user password (hashes) and the like (this may include passwords for other logins/apps than the one you are bypassing the authentication for).
You might be able to execute INSERT/UPDATE statements, depending on the DBMS (eg via stacked queries). Writing data can be useful (you could escalate privileges to admin, add a new admin user, or exploit vulnerabilities that are only exploitable from the database (sometimes RCE is possible when directly controlling database values)).
You might be able to read/write files (writing files might lead to RCE) or execute commands. Options to do so would be stacked queries (executing multiple queries separated via ;), subqueries, etc. A properly configured server would probably not allow reading/writing files or executing commands, but it's always worth a try.
The short answer is yes you might be able to dump the whole database including users and even write to disk and upload a webshell.
Some good resources:
-
Downvoted because the answer is not actually helpful: You simply claim "yes" without further explanation. The resources you link are generic information about SQL injection which do not provide any explanation matching the OPs question either. Commented Aug 4, 2022 at 19:25
-
I believe the problem is not my answer but the question which is too vague. Why would you downvote my answer which as some really usefull resources for someone who would ask this kind of question ? You did not even provide a better answer...– nullCommented Aug 5, 2022 at 9:53
-
Kind of. The OP is basically asking if some unspecific vulnerability can not only be used for authentication bypass but also for other things. The most specific answer possible to this is: maybe, maybe not :) But I don't think that your "yes" is the correct answer, since it depends on the details of the vulnerability. Commented Aug 5, 2022 at 10:01
-
The question is using "can". I answered "yes you might". Definition of might: used to say that something is possible.– nullCommented Aug 5, 2022 at 10:13
-
@null: That's an interesting play with the meaning of words. I personally would read "yes you might ...." as "the vulnerability allows in general to do this and it is up to your knowledge to use the vulnerability this way - and here are some resources about it". I instead would argue that it depends on the exact vulnerability if this is even possible and the best resources don't help if the vulnerability does not allow it. Maybe clarify the intended meaning in your answer? Commented Aug 5, 2022 at 11:18