Data duizenden Android-apps zijn te vinden door slechte database-implementatie

Beveiligingsonderzoekers hebben een kwetsbaarheid gevonden in de manier waarop Firebase-databases zijn geconfigureerd in naar schatting 24.000 Android-apps. Daardoor laten die apps gebruikersdata uitlekken.

Het lek zit in de veelgebruikte sdk Firebase. Die wordt gebruikt om onder andere NoSQL-databases en databasemanagers te gebruiken in Android-, iOS en C++-apps. De onderzoekers van beveiligingsbedrijf Comparitech zeggen dat de tool in bijna een derde van alle Android-apps voorkomt. Bij een deel van die gebruikers staat de configuratie verkeerd, waardoor data uit te lezen is.

Comparitech bekeek 515.735 apps in de Play Store die Firebase gebruiken. 4282 daarvan lieten gebruikersdata uitlekken. Het bedrijf extrapoleert dat dit betekent dat in totaal zo'n 24.000 Android-apps informatie zouden laten uitlekken, al is dat exacte aantal niet te bevestigen. Het is niet duidelijk of het lek ook op iOS of andere platforms uit te buiten is.

De databases laten onder andere e-mailadressen, telefoonnummers, gps-data en ip-adressen uitlekken, maar ook gebruikersnamen en wachtwoorden. Comparitech laat in een screenshot zien hoe die wachtwoorden in plaintext te achterhalen zijn. Uit de onderzochte apps wisten de onderzoekers zeven miljoen e-mailadressen, 4,4 miljoen gebruikersnamen en een miljoen wachtwoorden te achterhalen.

Het gaat niet om een kwetsbaarheid, maar om een verkeerde configuratie die door appbouwers zelf kan worden voorkomen. De kwetsbaarheid kan worden uitgebuit door simpelweg .json toe te voegen aan een Firebase-url. Dat werkt alleen voor openbare databases. Die urls zijn te vinden via verschillende zoekmachines. Google heeft dergelijke links eind vorig jaar uit zijn zoekresultaten gehaald, maar op Bing zijn ze nog te vinden.

Comparitech raadt databasebeheerders aan om goede regels in de software te implementeren door ze niet openbaar beschikbaar te maken, en om wachtwoorden niet in plaintext op te slaan.

Reacties (40)

[Simon Weel]

Zit een kromme zin in de tekst:

Het gaat niet om een kwetsbaarheid, maar om een verkeerde configuratie die door appbouwers zelf kan worden voorkomen. Dat kan door simpelweg .json toe te voegen aan een Firebase-url.

Dit is de oorspronkelijke tekst:
A common Firebase misconfiguration allows attackers to easily find and steal data from storage. By simply appending “.json” to the end of a Firebase URL, the attacker can view and download the contents of vulnerable databases.

[keranoz]

Ah dat veranderd het nogal! Ik las het juist zo dat .json toevoegen het probleem oplost, wat nogal raar klonk... +3

[TijsZonderH]

Oh ja slordig inderdaad, thanks. Dat moet natuurlijk zijn dat het op die manier kan worden uitgebuit.

[Eustace]

Niet heel erg secuur voor een security redacteur

[Azrona]

Het kan overal gebeuren. Ik zie het nog best veel bij nieuwsartikelen op meerdere websites. Zo had een het een keer over 13 provincies.
Fouten maken is menselijk. En zolang er bereidheid is om deze fouten te corrigeren en hiervan te leren lijkt het me nu ook weer niet zo'n slechte zaak. En al zou je het laten controleren door 10 proofreaders dan kunnen er alsnog fouten onopgemerkt blijven.

[hiostu]

Er zit een wezenlijk verschil tussen foutjes maken en de kernpunten uit een artikel verkeerd hebben. Er zijn in de afgelopen week al een aantal artikelen geweest waar in de comments duidelijk wordt gemaakt dat er gewoon aardig grote fouten in het artikel zitten. Goed dat deze worden opgelost, maar van een site met betaalde schrijvers en redacteuren mag je toch een stukje kwaliteit verwachten. Blijkbaar mag je hier op tweakers niet die kritiek uiten, want dan krijg je meteen een -1.

[frankkie12345]

Voor de app-developers onder ons; Firebase heeft documentatie hierover ;-)
https://firebase.google.c...e/security/insecure-rules

[Naafkap]

Slechte zaak. Zou dit ook bij iOS aan de hand kunnen zijn, of is de opbouw van de apps daar te afwijkend voor?

[Caayn]

Firebase is een extern product. Het wordt weliswaar door Google gebouwd maar heeft niks met Android te maken. Developers kunnen prima Firebase gebruiken in hun iOS apps.

Kortom: Ja, apps op iOS zullen er ook last van hebben.

[Gamebuster]

Ondanks de +2 is deze comment underrated: Dit heeft inderdaad echt niets met Android te maken.

[pepijntb]

Inderdaad. Lekker stemmingmakerij weer de titel. Heeft daadwerkelijk niks met Android te maken maar met een misconfiguratie van een dienst. Toevallig wordt deze dienst bij veel apps gebruikt, zowel iOS als Android, maar ook gewoon web.

[TijsZonderH]

Om ook even op de de reageerders op deze reactie terug te komen: de exfiltratie van data is alleen getest op Android door het beveiligingsbedrijf, en niet op iOS. Het zou bijvoorbeeld kunnen dat een iOS-app die Firebase gebruikt standaard niet via zoekmachines te vinden is, of dat het niet werkt om daar .json achter te zitten. Ik moet bekennen niet genoeg te weten van Firebase om dat zo te schrijven, vandaar dat ik het hou bij het onderzoek dat specifiek keek naar de implementatie in Android-apps, waarvan als enige is aangetoond dat de kwetsbaarheid er is.

[Caayn]

Het "probleem" zit in Firebase, niet in Android. Door het niet correct instellen kan je een Firebase instantie eenvoudig van buitenaf benaderen. Of die nou in Android, iOS of een webapp gebruikt wordt maakt niet uit je benaderd de instantie via REST wat platform onafhankelijk is. Ook voor de resultaten van een search engine zal dit niet uitmaken. Ook in iOS heb je resources string die naar Firebase zullen wijzen met daarin de URL die de app gebruikt, de app moet immers weten waarmee hij moet verbinden.

Firebase is een extern product wat niks met Android te maken heeft buiten dat beide door Google worden ontwikkeld. En in dit geval gaat het om een fout in de config van de Firebase instantie, oftewel de server kant als het ware, waarbij de client niet uitmaakt. Als ik nu een Firebase instantie aanmaak en deze niet correct instel kan ik daar ook overal bij zonder enige vorm van authenticatie.

Het onderzoek heeft zich gefocust op Android maar geeft tegelijkertijd aan dat vergelijkbare resultaten mogelijk zijn op andere platformen.

Although our team only examined Android apps on the Google Play Store, Firebase is a cross-platform tool used across several operating systems and platforms. These misconfigurations likely impact many more apps beyond Android.

Dit onderzoek lijkt ook meer te focussen op het aantal apps wat vatbaar is binnen één ecosysteem en minder op de kwetsbaarheid zelf. De kwetsbaarheid is al eerder ontdekt zoals ook opgemerkt is in het onderzoek. Als je doorklikt naar het eerder uitgevoerde onderzoek zie je dat iOS daar ook in opgenomen is:

Misconfigured Firebase databases have been an issue in the past for Google. Last year, application security vendor Appthority published research that found 3,000 iOS and Android apps had exposed approximately 100 million user records, including passwords and personal health information, through unsecured Firebase databases.

[Reactie gewijzigd door Caayn op 28 juli 2024 08:18]

[pepijntb]

Het gaat dus niet om een implementatie van de app maar om de configuratie van een dienst.
Tweakers mag wel wat beter fact checken.

[wjn]

Die urls zijn te vinden via verschillende zoekmachines. Google heeft dergelijke links eind vorig jaar uit zijn zoekresultaten gehaald...

En zo los je je probleem op, gewoon doen alsof het niet bestaat.

Edit: Firebase = Google.

[Yalopa]

Het is toch Firebase / Google zijn schuld niet dat een developer de beveiliging niet aan zet?
Het is toch Cisco zijn schuld niet dat beheerders het default PW van een router niet veranderen?
Het is toch de schuld van de maker die een sloot op je deur zet dat jij de sleutel op je voordeur laat.

[wjn]

Zie ook andere reacties, goede implementaties creëren zelf een random password of zetten remote access standaard uit.

Er kunnen altijd bugs inzitten, fouten maken is menselijk.

Maar dit is duidelijk een geval van lekker makkelijk voor app ontwikkelaars, heeft niets met security te maken (of het moet zijn 'security through obscurity', als je Wiki mag geloven is dat 2 eeuwen geleden al als schijnveiligheid betitelt.)

Het is toch de schuld van de maker die een sloot op je deur zet dat jij de sleutel op je voordeur laat.

De slotenmaker heeft het briefje waarop staat waar de loper ligt verborgen (zoekresultaten verwijderen), maar heeft nog steeds de loper onder mijn deurmat gelegd.
Ja, ik zou dan de loper moeten verwijderen, maar welke slotenmaker legt de loper op een openbare plek? Dat zou minstens op een afgesloten plek moeten zijn. Oftewel, deze optie zou standaard uit moeten staan, de ontwikkelaar kan het aanzetten. Niet andersom.

[Robin94]

Zojuist even een database aangemaakt en daarin kan je kiezen om deze te starten in de "vergrende modus" en de "test modus".

Vergrendelde modus: Alle lees- en schrijfbewerkingen door derden worden geweigerd
Test modus: Iedereen die uw databasereferentie heeft, kan uw database lezen en ernaar schrijven

Er wordt dus voor gekozen om iets open te zetten. Google kan hier vrij weinig aan doen.

Firebase anders dan een "gewone" database. Firebase werkt met nodes. Elke node kan weer meerdere nodes of een waarde hebben. Met zogenaamde rules kun je bijvoorbeeld nodes read-only, alleen voor ingelogde gebruikers of specifieke gebruikers zichtbaar maken. Zoiets als standaard beveiliging is niet mogelijk omdat Google niet weet welke nodes de ontwikkelaar gaat maken.

Aanvulling:
Een wachtwoord plaatsen op de database is ook niet mogelijk. Het hele idee is juist dat de database beschikbaar is voor elke client. Een wachtwoord in de code van een frontend of android app is voor iedereen uit te lezen en voegt dus weinig toe.

[Reactie gewijzigd door Robin94 op 28 juli 2024 08:18]

[Caayn]

Google is niet geheel vrij van schuld. Zij ontwikkelen een product wat default zonder security draait maar wel vanaf overal te bereiken is. Dat is vragen om problemen.

Edit:

Het is voor mij een tijdje geleden dat ik met Cisco iOS heb gewerkt. Maar staat remote access daar niet standaard op uit en kan je default enkel verbinden via de fysieke console poort

[Reactie gewijzigd door Caayn op 28 juli 2024 08:18]

[cracking cloud]

Firebase zou gewoon standaard beveiligd moeten zijn en het zou moeite moeten kosten om daar omheen te komen.

[walteij]

Prima dat Google dit voor hun eigen zoekmachine doet, maar het internet bestaat uit meer dan alleen maar Google (die daar zelf anders over denken). Bing zal waarschijnlijk binnenkort de resultaten wel aanpassen (want iets met verantwoordelijkheid), maar een zoekmachine als Shodan zal dit nooit doen (want iets met security en kwetsbaarheden inzichtelijk maken en houden).

[walteij]

Dit is natuurlijk weer een datalek van de domste versie.
1) Onbeveiligde database
2) Plaintext wachtwoorden in de database

Graag een overzicht van de apps (en hun developers) om ze even aan de openbare schandpaal te nagelen. Hoe moeilijk is het nu om het kopje "Securing your database" uit de handleiding te lezen?

[SwaggyEggs]

Welke handleiding?

[Webgnome]

nou deze: https://firebase.google.com/docs ?

[Gropah]

Deze handleiding die ook in het originele artikel word gelinkt en makkelijk te vinden is in de docs van Google zelf (word zelfs eerder genoemd dan het daadwerkelijk gebruiken van het product)

[walteij]

Ik ga er van uit dat deze opmerking sarcastisch was bedoeld .

[Luc45]

Als je de database rules op onderstaande standaard laat staan, dan kan inderdaad alle data uitgelezen worden door naar https://project.firebaseio.com/.json te gaan.

{
"rules": {
".read": true,
".write": true,
}
}

Firebase is hiervan op de hoogte, ze sturen je dan zelfs met regelmaat emails dat je database onveilig geconfigureerd is.

We've detected the following issue(s) with your security rules:

• any user can read your entire database

Without strong security rules, anyone who has the address of your database can read / write to it, leaving your data vulnerable to attackers stealing, modifying, or deleting data as well as creating costly operations.

[Reactie gewijzigd door Luc45 op 28 juli 2024 08:18]

[Xerxes249]

Welke pannenkoek heeft bedacht dat dat een slimme default is

[walteij]

Firebase is ontstaan in 2011.
In die tijd werd MySQL ook zonder wachtwoord geinstalleerd en was PHPmyAdmin ook standaard niet beveiligd.

Maar die zijn ondertussen wel aangepast en Firebase heeft dus een andere 'oplossing'.

[cracking cloud]

De pannenkoek die eerder bij MongoDB heeft gewerkt denk ik, want daar heb (had?) je een soortgelijk probleem.

[mr.Millenarian]

In dit geval lijkt mij dat de eventuele schade volledig voor de developer is.

[kiddingguy]

Om welke (bekende) apps gaat dit dan onder meer?

[Mario]

Er zijn zoveel lekken gaande, kon je maar voor betaalservices(aankopen en bestellingen) alias data gebruiken. Als er dan data van je op straat ligt, is het in ieder geval niet meteen te gebruiken.

[computerjunky]

Slimste om momenteel te doen is om voor iedere service en app een nieuw email adres aan te mmaken en voor binnen halen een catch all te gebruiken. Dan weet je precies waar de lekken vandaan komen als er zich problemen voordoen.

Hoop extra werk maar dat is de tijd waarin we leven...

[AmigaWolf]

En daarom is het verstandig om geen Apps, of zo min mogelijk Apps op je Smartphone te zetten.

[computerjunky]

Ik heb een tablet voor spelletjes en wat browsen voor als ik geen zin heb om naar de pc te lopen een telefoon voor alle apps zoals huis bediening en shopping en dergelijke en een bel telefoon waar ik alleen mee bel en buitenshuis wat mee op zoek. Ik gebruik dus wel apps maar gescheiden. Maar echt tegen gaan kan je het niet.

[AmigaWolf]

Ja das waar, het is erg jammer dat Apps zo geduwd woord, en dat je zo goed als niet zonder kan.

[josttie]

Het lijkt mij dat iOS apps en webapplicaties dus net zo geraakt worden door de onkunde van programmeurs die blijkbaar alle deuren open zetten. Google waarschuwt je hier genoeg over. Alsmede dat je voor Firestore een auth token nodig hebt en je wordt aangeraden Firestore te gebruiken, moet je gewoon de regels fatsoenlijk instellen en er is erg veel documentatie over te vinden.