Onderzoekers: veel Android-apps bevatten privésleutels

Onderzoekers van de Amerikaanse Columbia-universiteit hebben ontdekt dat duizenden apps in de Play Store privésleutels bevatten, bijvoorbeeld voor Amazon Web Services. Die privésleutels zouden door kwaadwillenden kunnen worden gestolen.

De kwetsbaarheid werd ontdekt door onderzoekers van de Columbia-universiteit. Het gaat om duizenden apps. Daarbij gaat het om sleutels voor diensten als Amazon Web Services, Facebook en LinkedIn. Zo werden er ruim zesduizend Twitter-sleutels aangetroffen.

Er is geen reden om privésleutels mee te leveren; onbekend is waarom de apps het toch doen. Volgens de onderzoekers maken ook ontwikkelaars die door Google als 'topontwikkelaar' worden aangemerkt zich schuldig aan het beveiligingsprobleem.

De onderzoekers hebben samengewerkt met Google, maar ook met Amazon en Facebook, om het beveiligingsprobleem in te dammen. Daarnaast scant Google nu automatisch apps in de Play Store op aanwezige privésleutels. Ontwikkelaars die privésleutels meeleveren, worden gewaarschuwd dat ze daarmee moeten stoppen.

De ontwikkelaars ontdekten het beveiligingsprobleem door automatisch apps uit de Play Store te downloaden en die vervolgens geautomatiseerd te analyseren. Daarvoor bouwden ze een tool, PlayDrone. Met dank aan die tool weten de onderzoekers ook te melden dat een kwart van de apps in de Play Store exacte kopieën zijn van apps die al in de Play Store stonden.

Reacties (60)

[BtM909]

Jammer dat dit artikel niet als bron is aangehaald: http://www.cnet.com/news/...ys-found-in-android-apps/

Even wat highlights:
• PlayDrone uses "hacking techniques" to circumvent Google's security to download Google Play apps, and then recover and analyse their sources. It scales by simply adding more servers.

• it managed to decompile over 880,000 of the 1.1 million free apps it downloaded.

• What Nieh and Viennot found was that developers often store their secret keys in their app software -- similar, the researchers said, to username and password data -- which can then be used to steal user data or resources from entities such as Amazon and Facebook.

Als je dit plaatje bekijkt, dan wordt het ook duidelijker waarom developers dat zo lukraak opslaan. Ik zeg overigens niet dat het zo moet, maar verklaart wel waarom het zo gebeurt.

Waar ik dan weer nieuwsgierig van ben, waarom slaan zoveel programmeurs dit soort "secret" codes dan zo op? Zijn er tutorials geweest die dit zo hebben gepubliceerd, heeft dit misschien ooit zo in de API voorbeelden vanuit Google gestaan of was dit vroeger common practice?

Als je nu op Github zoekt op een van de eerste regels, dan kom je iig genoeg code tegen waar een secret key open en bloot in de code te vinden is

[Reactie gewijzigd door BtM909 op 31 juli 2024 02:29]

[martinineter]

Toch wel erg dat een kwart van alle apps gewoon clones zijn. Tegenwoordig is er geen respect meer voor de software die een ander maakt. Het gaat alleen maar om de reclame imkomsten tegenwoordig. Zonde dat het zo moet...

[Anoniem: 154887]

Nou, dit heeft Google ook gewoon zelf mogelijk gemaakt. Google Play is gewoon onoverzichtelijk geworden en neigt zelfs naar het chaotische...

Zoek maar eens op een populair spel 2048, je vind het letterlijk tientallen keren terug, met identiek dezelfde naam. Hoe kan dit als ontwikkelaar nog aantrekkelijk zijn?

https://play.google.com/store/search?q=2048&c=apps

[martinineter]

Zelfs de game 2048 was een clone van een game waar ze een vrij lange tijd mee bezig waren. Vrijwel niemand kent het origineel(naam ontschiet me, was met een 1 starten ipv een 2), maar het concept werd in een paar dagen al gekopieerd. Zo wordt innovatie natuurlijk de kop ingedrukt.

[Zenety]

Volgens mij was "Threes" één van de eersten in de Apple Store. Natuurlijk bestaat dit concept al heel lang, maar op de mobiele markt was dit één van de eerste populaire.

http://asherv.com/threes/

Ik dacht dat ik ook al een keer eerder 1024 voorbij zag komen. Voor de hype van 2048.

Nog even OT: Ik zou het echt een heel goed idee vinden om apps te blokkeren die ergens een kopie van hebben gemaakt. Google is hier op andere platformen ook niet afwachtend mee. Ikzelf kijk eigenlijk nooit meer in de play store om een app te vinden. Ik zoek op xda-developers naar informatie over een applicatie en download hem dan pas.

[beerse]

Volgens mij is de naam veranderd toen het aantal clonen over de 1024 kwam en richting de 2048 ging.

Maar hoeveel Tetris implementaties zijn er eigelijk?

[vide]

Ik denk dat je "Threes" bedoelt, op iOS.

[Xymie]

Er staat "een kwart van de apps in de Play Store exacte kopieën zijn".

Een exacte kopie is dat niet gewoon dezelfde app onder een andere naam. Een beetje het coolblue principe. Ze de app onder meerdere namen in de store waardoor hij beter gevonden wordt bij een search.

[cedal]

Vreemde vooringenomen uitlating... Het artikel gaat helemaal niet over clones.

Het lijkt me vrij lastig om privé sleutels uit een apk te halen. Heb ik dat mis? Ik heb me er namelijk nooit in verdiept.

Ik ben trouwens benieuwd hoe dat bij iOS ligt. Daar zijn apps toch wel doordachter omdat de fee voor Apple zo hoog is.

[-=bas=-]

Het lijkt me vrij lastig om privé sleutels uit een apk te halen.

Niet bijzonder moeilijk omdat vrijwel alle tools ervoor al beschikbaar zijn.
Stappen plan :
1. download de apk uit de app-store
2. geeft hem de extensie .zip en pak hem uit
3. zet de class bestanden om nar java bestanden
4. scan alle files op strings
5. kijk of de string een bekende sleutel (MD5 of SHA2) kan zijn
6. extract de sleutel

iOS apps schijnen ook best wel te doen zijn :
http://www.slideshare.net/mbazaliy/i-os-reverseengineering

[Quacka]

Ik zal wel dom zijn, maar wat zijn privesleutels?

edit:
Het artikel van nu.nl maakt iets meer duidelijk:
http://www.nu.nl/tech/380...-privedata-in-gevaar.html
Maar dan nog begrijp ik echt niet wat er nu precies gebeurd.

[Reactie gewijzigd door Quacka op 31 juli 2024 02:29]

[Armin]

Dat zijn de sleutels die zoals de naam zegt prive moeten blijven. Het hangt af van de toepassing, aangezien sleutels voor verschillende toepassingen gebruikt kunnen worden.

Maar ik geef twee voorbeelden:

- Asymetrische encryptie. Veel secure protocollen gebriken asymetrische encryptie om een geheim uit te wisselen. Denk aan het opzetten van de beveiligde communicatie met jouw bank bij SSL/TLS. De bank stuurt jouw een publieke sleutel, waarmee jij een geheim kunt versleutelen. Enkel diegene met de private sleutel kan die uitlezen. Normaal heeft enkel die bank die sleutel, maar als die uitgelekt is ...

Ofwel alle versleutelde app communicatie die onderschept wordt, kan nu dus uitgelezen wordt door derden die die sleutel bemachtigd hebben. Hangt van de app af hoe erg dat is natuurlijk, maar denk eens aan telebankier apps ...

- Ondertekening. Bestanden - denk aan updates - kunnen ondertekent worden. Enkel de private sleutel kan ondertekenen. De ontvanger van een bestand kan controleren of de sleutel klopt via een publieke sleutel.

Meestal maakt men een wiskundige hash van het bestand en ondertekent de hash. Elke wijziging van het bestand wijzigt de hash. Dus de ontvanger kijkt of de hash correct ondertekent is. Zo nee, is het bestand niet te vertrouwen. Zo ja, kijkt de ontvanger of de hash nog klopt. Zo nee, is het bestand gewijzigd door een onbekende, en is het bestand ook niet te vertrouwen. Zolang de hash-ondertekening niet vervalst kan worden ben je als ontvanger/gebruiker veilig.

Echter heeft een onbekende persoon de private sleutel in handen, kan die het bestand wijzigen en daarna gewoon ondertekenen met een geldige handtekening. Of zijn eigen 'updates' ondertekenen als echte updates. In realiteit kan dat dus een malware bevattende update zijn.

[Quacka]

Thanks. Ik kan antwooorden op mn eigen reacties niet beoordelen, maar dit maakt het veel duidelijker!

[vide]

Het is vrij triviaal om die eruit te halen: apk is gewoon een archief bestand, met daarin een hoop bestanden en directories. Dan kwestie van code te decompileren. Je zou er verbaasd van zijn hoeveel mensen totaal geen code obfuscation gebruiken.

In het gelinkte artikel wordt ook gezegd dat ze dan in de decompile gaan zoeken naar variabelen genaamd "secret" en wat varianten.

[YopY]

Ik ben trouwens benieuwd hoe dat bij iOS ligt. Daar zijn apps toch wel doordachter omdat de fee voor Apple zo hoog is.

$99 / jaar is niet hoog. De apps zijn doordachter omdat de apps grondiger worden nagekeken door Apple (ik weet niet of dat over de jaren strenger / grondiger geworden is). Ik denk dat de $99 / jaar wel de script kiddies wat buiten houdt, en dat er een Mac nodig is ook (= ook investering). Met andere woorden, ik geloof dat de gemiddelde iOS developer iets serieuzer is dan de gemiddelde Android developer.

[Ikkerens]

Mijn bedrijf verkoopt een iOS app en merk er persoonlijk weinig van dat het grondiger is geworden. Ik denk eerder juist minder grondig.

Vroeger werd de app zo nu en dan wel eens geweigerd door subtiele fouten/crashes.
Laatste 2 jaar is de app geen enkele keer geweigerd.

Ik gok zelf dat Apple nu alleen nog maar in grote lijnen controleert (malware/pornografie), en niet zozeer meer inhoudelijk qua veiligheid/stabiliteit.

[Anoniem: 125509]

Laatste 2 jaar is de app geen enkele keer geweigerd.

Grin, dat kan natuurlijk betekenen dat in twee jaar de kwaliteit van de code flink is gestegen binnen je bedrijf.

[Anoniem: 154887]

Vreemde vooringenomen uitlating... Het artikel gaat helemaal niet over clones.

Het lijkt me vrij lastig om privé sleutels uit een apk te halen. Heb ik dat mis? Ik heb me er namelijk nooit in verdiept.

Ik ben trouwens benieuwd hoe dat bij iOS ligt. Daar zijn apps toch wel doordachter omdat de fee voor Apple zo hoog is.

Laatste alinea gaat wel degelijk over clones...

En over welke fees heb jij het bij iOS? Je bedoelt toch niet die 99 USD per jaar? Want de percentages op inkomsten zijn identiek bij iOS/Android/Windows Phone.
Als je geen 99USD over hebt per jaar voor je account, verdien je het voor mij niet om een app te publiceren, houdt het in ieder geval al een pak properder...

[Tarabass]

Met dank aan die tool weten de onderzoekers ook te melden dat een kwart van de apps in de Play Store exacte kopieën zijn van apps die al in de Play Store stonden.

Toch staat het in het artikel. En dat is een vrij ernstige zaak. Een kwart van alle apps zijn dus rip-offs en dat is wel heel veel..

[MacD]

"Daar zijn apps toch wel doordachter omdat de fee voor Apple zo hoog is."

WTF? Rare conclusie, wat betreft het gebruik van keys en wat betreft clones. De appstore van Apple zal identiek zijn op deze punten.

[Luxx]

Als Google wil kunnen ze deze apps prima detecteren/tegenhouden. Het aantal Apps op hun platform moet echter hoog zijn, want dat verkoopt, en daarmee is de kwaliteit / diversiteit minder belangrijk. Dat er apps nagemaakt worden heb je altijd. Er is zelfs niets mis met meerdere apps die min of meer hetzelfde, maar net iets anders, doen.

Als een scanner kan zien dat het exacte kopieën zijn, kan het volgens mij geen na-maak zijn, en laat je wel de boel vervuilen. Dit zal meestal met dubieuze bedoelingen zijn en niet afgesproken met de originele ontwikkelaar.

n.b. het kan zijn dat een app meerder keren voorkomt, als trial/full/extended versie 'dezelfde' app zijn maar dan met andere 'key.'
nav reactie raro iets genuanceerd om m'n punt duidelijk te maken.

[Reactie gewijzigd door Luxx op 31 juli 2024 02:29]

[raro007]

Waarom moet er weer getrold woorden...
Playstore is een zo goed mogelijk open markt.
Daarbij spelen kunnen wel op elkaar lijken maar hebben een eigen twist.
Kijk maar naar flappybird is een gewoon helicopter spel van vroeger maar de met een eigen twist.

[Armin]

Playstore is een zo goed mogelijk open markt.

Open markt =/= plagiaat toestaan.

Natuurlijk kun je betwisten wat plagiaat is en ik wil zeker geen discussie over software-patenten oprakelen, maar in deze context gaat het om binary copieen. Dat is geen grijs-tint of hellend vlak.

Maar het blijkt dus dat het aantal apps voor Android dus opeens 25% lager is dan gerapporteerd.

Veel erger is dat pricate certificaat geval overigens. Maar ook dat mag geen verassing zijn.

"The most dangerous code in the world"

https://crypto.stanford.e...acts/ssl-client-bugs.html

Applicatie-ontwikkelaars hebben vaak en geen kennis (en helaas ook vaak geen interesse) om iets veilig te maken. API's helpen ook vaak niet om het makkelijk te maken.

Maar bij deze apps in kwestie is het private certificaat nu effectief uitgelekt, en dus kan iedereen een MITM aanval doen. Het certificaat zou eigenlijk heroepen moeten worden en een nieuwe aangevraagd (wat geld kost en dus niet gedaan gaat worden) moeten worden.

[Anoniem: 80466]

Als een geautomatiseerde controle app identiek vind is het gewoon een cloon en zou Google die moeten weren uit de play store.
Dat kunnen zij dan namelijk ook geautomatiseerd controleren.

[Creesch]

Het gaat hier niet om apps die geïnspireerd zijn op andere apps maar die exact de zelfde code gebruiken.

[Anoniem: 405779]

Het aantal apps in de playstore was ooit een verkoop argument voor andere platforms dan Android. Die situatie hebben we inmiddels al jaren achter ons en dus vervalt je argument.

Wat er dan nog overblijft van je argument is dat Google bewust de kwaliteit laag laat zijn. Echt?

[Anoniem: 302359]

Het aantal apps in de playstore was ooit een verkoop argument voor andere platforms dan Android. Die situatie hebben we inmiddels al jaren achter ons en dus vervalt je argument.

Wat er dan nog overblijft van je argument is dat Google bewust de kwaliteit laag laat zijn. Echt?

Google houd niet bewust de kwaliteit laag maar dit is wel direct een gevolg van een open appstore. Met een open Appstore krijg je natuurlijk meer rotzooi aangeboden want iedereen kan er tenslotte van alles in zetten zonder al te veel controle.

[MatthiasDS]

Het aantal apps in de playstore was ooit een verkoop argument voor andere platforms dan Android. Die situatie hebben we inmiddels al jaren achter ons en dus vervalt je argument.

Hoezo?
Het aantal apps in de Play store was een verkoopsargument tegenover alle andere platformen uitgezonderd Apple's App Store.
Bij mijn weten is aan die situatie nog niets veranderd. Andere platformen dan deze 2 blijven achterlopen.

[3x3]

Op mijn andere platform, heb je in totaal een groter app aanbod dan op android.

Hij speeld apk's, html5 apps, en blackberry.
Waarbij je in de snap-store beschikking hebt over de 1.2 miljoen android apps, maar ook in de blackberry store met 200.000 apps vrijwel geen kwalitatieve app hoeft te missen, voordeel van die laatste apps is wel dat ze getest zijn op veiligheid.

Ook het aanbod van kwalitatieve apps op ios is niet significant minder dan dan op android, de windows phone market heeft misschien wat minder exotische apps beschikbaar dan ios, android en blackberry maar ook daar zijn wel de meeste essentiële apps in de app-winkel te vinden.

als je apps-stores gaat vergelijken, dan kun je hoogstens zeggen, dat standaard google ontwikkelaars veel ruimte laat om data van gebruikers te verzamelen ten opzichte van andere platforms, maar voor veel gebruikers is de negatieve impact daarvan nihil, en zijn de baten, zoals veel gratis en diverse apps wel voordelig.

[MatthiasDS]

2 vragen:

• Kan je met Blackberry connecten op de Play store?
• Zijn er veel apps die op BB bestaan en in de Play store?

Indien het antwoord op de eerste vraag 'nee' is het totaal aantal apps weliswaar groter, maar de bruikbaarheid veel beperkter. Je moet dan de apk's nog ergens vinden en sideloaden. En niet alleen dat: app updates, malware, ... worden dan een groter probleem.

Tweede vraag: indien er eigenlijk geen tot weinig unieke apps in de BB store staan, is het totaal aantal niet echt groter, er is vooral erg veel dubbel in dat geval.

En wat met de L&F van Android apps tov BB?

[3x3]

Ja via snap download je gewoon via de g-account, direct uit de playstore daarbij loopt het installatieproces als gewoon, kiezen, downloaden, bevoegdheden controleren,malwarescan, installeren.

De blackberry-store kent een aantal apps die specifiek en alleen in de BB-store zijn uitgebracht. Daarnaast kent de store nog twee extra voordelen voor de apps in de BlackBerry store die je in de play-winkel niet hebt:

• Bevoegdheden beheer: voor je een app installeerd kun je als gebruiker bepalen bij welke data hij niet en wel mag.
• Tijdelijke gratis aanbiedingen van apps die in de play-store alleen soms met korting worden aangeboden.

De look en feel van android apps, is exact hetzelfde als op android. Dus in mijn geval, zoals ik gewend ben. Zowel android als BlackBerry apps zijn daarin in de praktijk inconsistent.
Ook komen android notificaties door de ondersteuning van api's ook netjes in het notificatiecentrum/de hub te staan.

[MatthiasDS]

Ja via snap download je gewoon via de g-account, direct uit de playstore daarbij loopt het installatieproces als gewoon, kiezen, downloaden, bevoegdheden controleren,malwarescan, installeren.

En automatische updates ook? In dat geval hebben ze het wel mooi voor elkaar.

Het toont dan weer wel, naar mijn mening, de pijnpunten aan van het eigen platform.

De look en feel van android apps, is exact hetzelfde als op android. Dus in mijn geval, zoals ik gewend ben. Zowel android als BlackBerry apps zijn daarin in de praktijk inconsistent.

Android apps zijn wel meer en meer aan het convergeren naar een consistente ervaring.
De L&F is hetzelfde als op Android maar ik kan me voorstellen dat de L&F van Android apps anders is dan die van native BB apps?

[MatthiasDS]

Waarom zou je denken dat ik aan het trollen ben? Ik snap helemaal niets van die opmerking van je. Laat dat dus maar achterwege.

ikkuh61 leek te stellen dat het aantal apps geen verkoopsargument meer is aangezien de situatie ten opzichte van vroeger op dat vlak is veranderd - dit terwijl die volgens mij nog gewoon identiek is. Wat is hier trollen aan?

Het maakt me verder persoonlijk ook niet echt uit hoeveel miljoenen apps er bestaan, zolang ik alles maar kan vinden.

[bigbadbull]

Jou opmerking "uitgezonderd Apple's App Store."

en zoals je nu zelf zegt het aantal maakt niemand meer uit, bewijst het dat het geen verkoop argument meer is.

[Anoniem: 405779]

thanks

[MatthiasDS]

Jou opmerking "uitgezonderd Apple's App Store."

Dat zei je in je vorige post al. Gelieve uitleg te geven waarom dat trollen zou zijn.

Ik gaf gewoon aan waarom, in mijn opzicht, de situatie nog niet gewijzigd was. Het was en is nog steeds een verkoopsargument dat Android veel apps kan bieden, uitgezonderd ten opzichte van Apple's iOS.

en zoals je nu zelf zegt het aantal maakt niemand meer uit, bewijst het dat het geen verkoop argument meer is.

Ik ben nog net niet zo arrogant dat ik mezelf gelijk stel aan de hele populatie. Daarnaast heb ik al genoeg gemerkt dat een grotere hoeveelheid apps ook een grotere kans betekent op meer goede apps. Dat hoeft niet per sé zo te zijn maar ik heb al gemerkt dat bij WP (en RT) bepaalde zaken niet te vinden zijn.

[Veenix]

Je hebt ook app ontwikkelaars die zelf dezelfde app meerdere malen plaatsen, met een iets andere naam en/of icon. Maar je ziet het bijvoorbeeld ook met vertaal/woordenboek apps die meerdere talen aankunnen. Zo'n app wordt voor iedere taal apart in de app store gezet. Een zo'n app komt al snel 50 keer voor.

[Enai]

Dat is juist goed voor de klant want je kunt de beste app uitkiezen.

Ideeën zijn vrij, wat telt is de uitvoering ervan.

[tomvleeuwen]

Veel open source apps laten de API keys weg uit de source (uiteraard). Deze werken dan ook niet met twitter/fb/dropbox etc. als je ze via f-droid installeert. Ik snap de opmerking dus niet zo goed dat de keys niet nodig zijn. Wat is het alternatief?

Ze zijn er vaak overigens heel eenvoudig uit te halen, ze staan bijvoorbeeld gewoon in het manifest bestand.

[DEVoTi0N]

Wat niet helemaal goed duidelijk wordt uit het nieuwsartikel, is dat het gaat om de wijze waarop deze geïmplementeerd worden. Het probleem zit hem in het feit dat developers apps gecompileerd aanleveren, waardoor ze het idee hebben dat hun data veilig is. Deze binaire data is echter tot op zekere hoogte prima te decompileren, waardoor gebruikte keys en dergelijke vrijkomen.

Het onderzoekt maakt onderscheidt tussen twee groepen. De tokens van Amazon en die van OAuth diensten. De diensten van Amazon worden gebruikt voor clouddiensten, waaronder online opslag en on-line rekenkracht bijvoorbeeld. Hiervoor is een API van Amazon beschikbaar. Duidelijk is gedocumenteerd hoe je verschillende keys aan kan maken met verschillende rechten. Op het moment dat een app alleen on-line data uitleest, is het dus niet nodig dat jij je applicatie voorziet van een rootkey, die volledige controle biedt.

OAuth diensten zijn de inlogschermpjes die af en toe in apps verschijnen. Denk hierbij bijvoorbeeld aan het inloggen op Facebook om je spelletje aan je Facebook te koppelen. Of het inloggen op Dropbox om een applicatie on-line data op te laten slaan. Dit is een volledig veilig systeem. In het onderzoek wordt echter de wijze van implementatie bekritiseert door credentials direct in de code in te bakken.

Hieronder nog wat extra info direct uit de bron:

Amazon Web Services
AWS provides various cloud computing resources that can be purchased by developers using AWS accounts and accessed by the developers' applications using AWS tokens associated with the respective AWS accounts. [...] we found 308 unique AWS tokens from the June 22, 2013 snapshot. [...] We found 94% of the tokens were still valid five months later. [...]
Amazon provides documentation describing best practices and a variety of ways to configure AWS tokens with different levels of privilege [2]. Despite this documented exibility, we were surprised to and that even though some developers only intended their applications to use AWS tokens to access AWS Simple Database or Flexible Payment Services, the tokens embedded in the applications were rootlevel credentials providing access to all the other AWS services, including creating and shutting down Elastic Compute Cloud (EC2) instances or freely accessing S3 data.

OAuth Tokens
Applications often request access to users' data to perform actions on their behalf. The standard protocol used by service providers to give access to users' data is OAuth. [...]
When implemented correctly, the OAuth authentication protocol never reveals the tokens associated with a client's OAuth credentials. The tokens are stored on the third-party's server where it can be properly safeguarded. Requests can then be proxied through the third-party's server where the tokens reside. Unfortunately, developers often adapt this protocol to mobile applications by embedding OAuth tokens directly into their mobile applications without realizing their credentials are easily compromised through decompilation. Once an attacker acquires a secret OAuth token, a wide range of attacks can be performed as the targeted third-party application is open to impersonation. For example, an attacker can perform denial of service attacks on rate limited services, access and modify application settings, expose private user information, and launch phishing attacks in an attempt to get users' access tokens.

edit:
Even voor de duidelijkheid: Jij als eindgebruiker hebt niets te vrezen voor je inloggegevens, hooguit jouw data die je vrij hebt gegeven aan een app en de kans op fishing attacks. Het zijn zogezegd de inloggegevens van de developers tot bepaalde diensten, die op straat liggen. Daarnaast staat dit alles ook geheel los van het feit dat er zoveel "clone-apps" zijn.

[Reactie gewijzigd door DEVoTi0N op 31 juli 2024 02:29]

[YopY]

Nouja, de public key mag je gewoon in de app stoppen, geen probleem (hence the name). Het gaat hier om private keys, die dus alleen bekend mogen zijn bij de app developer (= jezelf) en de partij waar ze verbinding mee willen maken (= Amazon etc).

[Anoniem: 457607]

Dat is niet correct. Bij diensten als Amazon dien je wel degelijk de private keys mee te leveren in de applicatie, anders gaat het gewoon niet werken. Het punt is dat je een low access private key meegeeft, en niet een root level private key.

[Belgar]

De publieke sleutel? Een 2-stage key handshake via een vertrouwde 3de partij? En zo nog wel een paar technieken. Je prive sleutel hoef je in principe niet te gebruiken.

[bombadil]

Wat voor nut heeft het om prive-sleutels mee te leveren? App makers stoppen ze er toch niet voor niets in lijkt me. Mogelijke reclame- of referal-inkomsten voor de App maker? In wat voor gevallen worden die sleutels dan relevant; bij aankopen op bijv. Amazon via een link uit die specifieke app?

[lappro]

Waarschijnlijk zitten die er in door luiheid, onzorgvuldigheid en/of onwetendheid. Voor zover ik weet is een private key meegeven in je app een beetje hetzelfde als jouw wachtwoord meesturen in plain text. Normale gebruikers zien dit niet, maar als je in de code gaat neuzen kom je het tegen. Op die manier kan je je voordoen als iemand anders wat vanzelfsprekend vervelende gevolgen kan hebben.

[YopY]

^ dit. Developers doen van "ja ik wil iets met facebook, euh... iets met sleutels... ja werkt niet... oh als ik dit bestand er in pleur en met wat trial & error AH het werkt *ship it*".

(of misschien was ik dat, ).

[-=bas=-]

Het zijn de prive-sleutels voor toegang tot de backend servers en diensten.
Hoewel bv Amazon AWS mogelijkheden biedt om een goede beveiliging op te zetten zonder gebruik van prive sleutels, is het verrekte makkelijk om je communicatie op te zetten met je eigen prive sleutels. In het slechtste geval kan een hacker je backend server overnemen.

[MacD]

Gebruik van Google API's? Maar wat ik me afvraag is wat ze precies onder "prive sleutels" bedoelen: de app specifieke Google API key moet in het manifest geplaatst worden, en zo moeten meerdere keys daar geplaatst en meegeleverd worden.

[FoOnEeN]

Lijkt me dat dit voornamelijk sleutels zijn om externe API's aan te roepen of niet? Veel van die externe API's vereisen dat je je authenticeert via een Apikey, die je als ontwikkelaar persoonlijk moet aanvragen. Vervolgens gebruik je deze apisleutel voor alle requests richting de API.

Rol je vervolgens een app uit die dat gebruikt, dan moet elke app ook toegang tot die apikey hebben, en moet deze dus meegeleverd worden in de app. Ergens in de code moet deze dus vermeld staan, en vervolgens kom je hem dus tegen.

[theduke1989]

als ik dit hoor maakt het me wel bang.
Echter moet je ook vaa kijken naar de uitgever.
Vaak welke apps ik gebruik zijn denk ik in mijn ogen geen clones of wat dan ook .
whatsapp/facebook en noem zo maar ....

[Anoniem: 125509]

Ik vraag me af wat dit onderzoek nu eigenlijk zegt. het open character van Play Store en Android maakt dit soort onderzoeken relatief eenvoudig mogelijk. Ik vraag me af of, als dit onderzoek op de Apple en Microsoft stores gedaan zou worden, wat dan de uitkomsten zouden zijn. Ik mag hopen dat Apple dit in haar beoordeling al afblocked, maar aangezien de procedures voor afwijzen vrij mistig zijn weet ik dat niet zeker.

Maar goed. Ik ben in elk geval blij dat Google nu toch begint in te zien dat klakkeloos toelaten van Apps geen goed idee was. Het controleren en melden van deze privésleutels is weer een stapje vooruit.

En exacte kopieën in de store? Ik vraag me dan af wat een aanbieder daarmee wil bereiken? Gaan bij een exacte kopie eventuele ad inkomsten dan niet naar de originele maker van de app? Of probeert de originele maker door vele kopieën in elk geval eentje onder de aandacht van de gebruiker te brengen? Ik tast hier eerlijk gezegd een beetje in het duister.

Ik vind in elk geval dat Google dit zo snel mogelijk mag gaan blokkeren. Slechte namaak is tot daar aan toe, maar exacte kopieën heeft een winkel volgens mij niets aan.

"Meneer, waar vind ik de suiker?"
"Onder andere naast de koffie, naast de thee en naast de yoghurt mevrouw."

[bammette]

De exacte kopieën gaan in alle waarschijnlijkheid dezelfde Apps met een andere naam. Dit om makkelijker gevonden te worden. Echter lijkt me het juist gebruik van Tags hiervoor veel nuttiger, maar mischien werkt dat niet goed in Play Store?

Het zou ook best goed kunnen dat de Play Store straks juist veiliger is dan de stores van de concurrentie, juist omdat dit soort onderzoeken zo goed mogelijk zijn. Hier gaan we vast nog wel vaker iets over horen.

[Danot]

Hier staat de source code voor het onderzoek: https://github.com/nviennot/playdrone

[computerjunky]

Ik heb nog NOOIT 1 exacte kopie van een app gezien.

Wel apps die hetzelfde deden maar er anders uitzagen enz. maar dat valt niet onder exacte kopieën.

[TiTbB]

Het jammerlijke eraan is dat je Android troll niet eens klopt. Dit zijn de ontwikkelaars van de apps zelf die fout zitten en niet Google of Android in zijn geheel.

[3x3]

Als je een markt creëert, en ook aangeeft daar zelf marktmeester van te zijn, kunnen de gevolgen van het gebrek aan controle je wel worden toegerekend denk ik.

Die data verzoeken van apps uit de play store zijn trouwens exorbitant hoog. Bij het installeren en gebruiken van de populairste apps kwamen Nederlandse journalisten erachter dat er 14.000x met servers over de hele wereld gecommuniceerd. Waarvan de meeste connecties met bedrijfsservers waren van adverteerders. Op andere platforms gebeurd dit ook, maar dan wel in veel mindere mate.

[Anoniem: 125509]

kunnen de gevolgen van het gebrek aan controle je wel worden toegerekend denk ik.

Toch zie je op marktplaats en ebay bijvoorbeeld ook gestolen spul aangeboden worden. Een gebrek aan controle dat ze maar zelden wordt aangerekend kennelijk. Het zal toch echt van de voorwaarden afhangen.

dat er 14.000x

Per seconde? Per App? Per telefoon? Per account? Per land?

Toegegeven, het klinkt heel spannend, maar het is een beetje nietszeggend. Je kunt zien dat de journalist zijn best heeft gedaan, het is ook een leuk artikel, maar het doet tegelijk zijn best om een flink aantal open deuren in te trappen en nieuws te fluffen.

Vervolgens zijn er dan mensen die de getallen van zo'n nieuwtje klakkeloos optellen en als groot nieuws in een reactie plempen.

Dat er veel verbindingen gemaakt worden met ad-servers op een platform dat bij uitstek gebruikt wordt om inkomsten uit ads te genereren is niet meer dan te verwachten. Het enige wat aangetoond wordt is dat ads gebruikt worden en dat er kaf onder het koren zit in de Play Store. Iets wat in een open markt nu eenmaal gebeurt, hoe vervelend ik dat zelf ook vind.

[Anoniem: 593041]

Het is wel door Android en/of Google...!
Waarom denk je dat de ontwikkelaars fouten maken? --> Omdat de voorwaarden die Google stelt voordat een app toegelaten word, veel te laag liggen... Als ze strenger zouden zijn, dan zou zoiets niet of amper gebeuren.