Critical misconfiguration in Firebase — Bug bounty
In my latest post, I shared how I escalated a Local File Intrusion to Remote Code Execution, If you haven’t read it yet, go ahead and take a look!
I would love to connect on LinkedIn with you, if you haven’t, send me a request!
HAPPYHACKING
I started doing some reconnaissance, gathering subdomains using Subfinder and old domains using Waybackurls or Gau.
I got hundreds if not thousands of results when I used Waybackurls, I kinda wanted a high level of what I was going to be dealing with so I used the following command:
waybackurls TARGET.com | httpx -status-code
After I ran it, immediately saw a few really interesting eye-catching Javascript files at the top of the results.
While Waybackurls was printing all indexed domains, I started checking those files and found:
Huge disclosure of secret information!
How can we use this info to further exploit the app and show critical impact:
I used this exploit:
I can write in the database! If the owner of the Web Application has set the security rules as true for both “read” & “write” — ie:
An attacker could write/dump the database! In this case, their security settings were true for both read and write. If they had:
read: false
write: true
I was going to be able to write in the database but not see the .json file that I created.
I decided to go deeper and brute-force the potential .json files!
After half an hour I found contactForm.json and BAAAANG!
For more info. about Firebase penetration testing:
Let’s connect on LinkedIn! Let me know if you have any questions!