I found a vulnerability which allows me to run any query on an Amazon RDS server. I was able to extract the user hashes by using the --passwords parameter of sqlmap, and one of the hashes was cracked before. The thing is, I'm not sure that first the Amazon RDS Instance is accessible from the internet (specifically any IP), and I'm not sure how I could get the ip of the RDS instance (--hostname returns internal 172.x.x.x address). I'm wondering if there is anything I can do to further escalate the vulnerability.
2 Answers
Two options come immediately to mind -
Exfiltration
You can learn more by Googling 'sql injection exfiltration', but generally, this involves using SQL primitives that make DNS lookups or HTTP connections. You can build a query that selects data from a table and injects it into a host lookup to a domain that you control; then your DNS server will see the data.
This option takes advantage of the fact that while you may not have a good route to the database, it probably has some sort of route outbound. DNS, especially, is indirect and can be used even if the DB server itself has zero Internet access.
Front End Leverage
If the database (and credentials accessible within) are backend for a front end web UI that is accessible over the network, then you can use the information to get into the app, which may be just as useful as getting into the database.
answered Oct 18, 2018 at 12:47
-
Thanks for the answer. For reference, this is a MySQL server, and I was going to do an HTTP connection, but unfortunately that didn't work. I'll see if there is anything else I can do before trying to attack the frontend. Commented Oct 18, 2018 at 12:59
You can go ahead and report this directly to Amazon, see https://aws.amazon.com/security/vulnerability-reporting/ and it would be good to know what the follow up is from them.
-
My question isn't "what should I do with it", it's "what can I do with it to further escalate the vulnerability"... Commented Oct 18, 2018 at 12:59
-
Ok. I had read 'escalate' in the way of 'escalating to Amazon.' Commented Oct 18, 2018 at 13:04
@@hostnameis especially meaningless because there is an undocumented static NAT translation layer between the AWS customer's network and the RDS-managed network, so the private IP you see there has no actual relevance, even if you were inside their network by some other mechanism. It isn't even the internal address the client machines are connecting to. If it's actually an Aurora/MySQL instance (SELECT @@AURORA_VERSION), you could try invoking a Lambda function in your account, and use your CloudTrail to see which principal was denied access. Maybe useful.