Google: ontwikkelaars voegen achteraf malware toe aan apps uit Play Store

Google stelt dat malafide ontwikkelaars na enige tijd malware aan hun apps uit de Play Store durven toevoegen. Deze praktijk heet versioning en houdt in dat er na het downloaden van de ogenschijnlijk betrouwbare app via een aparte server code aan de app kan worden toegevoegd.

In het jaarlijkse beveiligingsrapport van het Google Cyber Security Team staat te lezen dat er malafide ontwikkelaars zijn die een eerste versie van hun app via de Google Play Store aanbieden. Die versie doorstaat alle controles van de appwinkel en komt volgens Google dus ook als betrouwbaar over. Zodra de app echter geïnstalleerd is, kan die na enige tijd een update krijgen via een aparte server met daarin nieuwe code. Deze nieuwe code kan malware bevatten en gaat in sommige gevallen op zoek naar gevoelige informatie van de eindgebruiker. Deze praktijk heet volgens Google versioning.

Google vermeldt in het bijzonder apps die in de bedrijfswereld worden gebruikt. Het Amerikaanse bedrijf meent dat enterprisegebruikers het beste enkel apps en app-updates toelaten die afkomstig zijn van betrouwbare bronnen zoals de Google Play Store of van het mobiledevicemanagementplatform van het bedrijf zelf.

Het Amerikaanse bedrijf stelt in het rapport dat minder dan 1 procent van alle apps in de Google Play Store potentieel gevaarlijk is. Het is niet duidelijk of de apps die aan versioning doen ook in deze schatting opgenomen zijn. Het bedrijf zegt de Play Store uitgebreid te controleren op potentieel gevaarlijke apps, maar dat ontwikkelaars in sommige gevallen de controles alsnog kunnen omzeilen.

Uitsnede van het Threat Horizons Report van het Google Cyber Security Team

Reacties (152)

[Creadion]

Er wordt dus gebruikt gemaakt van DCL (Dynamic Code Loading), meer info in het artikel van Hacker News: https://thehackernews.com...neaky-versioning.html?m=1

Dit Medium artikel gaat wat verder in op DCL: https://kalpeshchandora12...g-in-android-dea83ba3bc85

[GekkePrutser]

Het gekke is dat Google dit al niet meer toestond sinds Android 10. Daarbij mag een app alleen nog maar code uitvoeren die in de app bundle is meegeleverd.

Om deze reden kan Termux niet meer worden geupdate in de play store, omdat je daarmee dan geen packages meer kan installeren via het ingebouwde PKG commando (immers download je dan uitvoerbare code!). Google noemt dit een "W^X violation"

https://github.com/termux...iki/Termux-and-Android-10

Untrusted apps that target Android 10 cannot invoke exec() on files within the app's home directory. This execution of files from the writable app home directory is a W^X violation. Apps should load only the binary code that's embedded within an app's APK file.

Hierdoor kan Termux helaas alleen via F-Droid verspreid worden tegenwoordig.

Maar het gekke is dus, google heeft de complete policy om dit tegen te gaan al in huis. Dus de vraag is eerder waarom het alsnog gebeurt door malware.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 16:23]

[kodak]

Het is inderdaad dan ook niet nieuw dat criminele ontwikkelaars zo malware toevoegen.
Google lijkt het rapport hier vooral te gebruiken om schuld af te schuiven, zichzelf te promoten en hun enterprise tool te verkopen.

Ze stellen dat het om slechts 1% zou gaan die de 'rigoureuze" controle van Google Play store controle weet te misleiden. Maar ze geven geen enkele uitleg wat er zo bijzonder aan die 1% is dat het door hun controle komt. Dat criminelen de controle proberen te misleiden is niets nieuws, dus waaruit blijkt nu dat Google dat niet had kunnen vermoeden en toch goedkeurde? Dar blijkt niet uit de 1%.

Om daarbij bedrijven te suggeren dat die bijvoorbeeld de Google enterprise software kan aanschaffen om het probleem van het installeren van foute extra code die niet uit de Play store komt tegen te gaan. Google lijkt dus hun onwil of onkunde bij hun Play store controles liever op te lossen door bedrijven een Google tool te laten gebruiken. Op zich is een extra controle niet verkeerd om ook tijdens gebruik dit soort risico te voorkomen. Maar dan nog blijft de vraag waarom Google het niet eerder zelf kon voorkomen.

Het probleem bij het achteraf dynamische laden van code uit een afwijkende onbetrouwbare locatie is dat de code hiervoor vaak verborgen in de app staat en de controle onvoldoende is. Maar dat wil niet zomaar zeggen dat het proberen te verbergen of toevoegen van die code niet opvallend is. Het is eerder vaak juist herkenbaar doordat het afwijkt van de andere code. Een controle is niet zomaar rigoureus als dat soort afwijkingen en toevoegingen niet herkend of zelfs geaccepteerd worden. Laat Google dus maar uitleggen waarom het redelijk was dat ze het bij die 1% niet herkende of alsnog (of hoe dan ook) goedkeurde, in plaats van het te hebben dat het 'maar' 1% van alle aps betreft.

[Reactie gewijzigd door kodak op 22 juli 2024 16:23]

[Anoniem: 80910]

Volgens mij kun je de code toch scannen, of dit soort mogelijkheden in de software aanwezig is en zo blokkeren, niet toestaan? Mis ik iets?

[kodak]

Scannen is een manier om apps te controleren. Maar hoe ze dat controleren doen maakt nogal een verschil. De criminelen doen namelijk hun best hun foute bedoelingen te verhullen zodat de controle het niet kan vinden. Wat google hier niet toont is of hun controle, zoals fe manier van scannen, wel redelijk is zodat dit side loaden kan gebeuren. En ze lijken zelfs maar sommige versies te scannen, wat het probleem alleen maar groter maakt.

[Anomnomnomymous]

Ik vraag me af of dit ook een probleem is voor Apple phones/tablets - eigenlijk nooit iets over gelezen.

[84hannes]

Ik vraag me af of dit ook een probleem is voor Apple

Wat ik me kan herinneren is dat alternatieve browsers voor iPhone/iPad het moeten doen met een hele trage javascript engine omdat Apple niet wil dat arbitraire (JiT-compiled) code in een app kan draaien. Apple lijkt dus het draaien van code die niet uit de App store komt onmogelijk te maken, dat zou dit soort malware onmogelijk maken. Of het Apple ook succesvol lukt weet ik niet; het scannen en testen van apps is altijd een kat muis spel, ze kunnen alleen voor bekende vulnerabilities scannen en toegankelijke paden testen.

edit:
Zie ook de post van @MisterData

[Reactie gewijzigd door 84hannes op 22 juli 2024 16:23]

[Anomnomnomymous]

Aha, bedankt voor de extra informatie

[d3burt]

Dat kan als je patronen van bekende malware herkent. In je virus scanner wordt dat vaak als een "heuristic scan" aangeduid. Het probleem ervan is dat je relatief veel false positives hebt die "met de hand" bekeken moeten worden, en dat er veel varianten op het patroon mogelijk zijn.

Ik weet dat Google dat soort patroonherkenning toepast, maar kennelijk kom je er mee weg bij updates. Ik hoop dat ze naar aanleiding van deze ontdekking beter patroonherkening gaan loslaten op updates. Ik zou verwachten dat dat juist bij updates false positives een minder groot probleem zijn, omdat als opeens zo'n patroon opduikt in een update de kans er groot is dat er iets mis is, en zelfs als je dat handmatig moet beoordelen de kans zo veel groter dat er echt iets mis is dat het me de moeite waard lijkt.

Het grootste probleem voor Google is niet eens dat het geld kost, maar dat de mensen niet te vinden zijn die handmatige beoordeling kunnen doen op de schaal van Google.

[Aldy]

Ik begrijp uit het redactionele stukje juist dat de update buiten de Playstore geïnstalleerd wordt. Daar heeft Google geen invloed op, maar in de originele app moet een code zitten zodat de update buiten de Playstore plaatsvindt. En op die code moet Google dus alert zijn.

[cricque]

Ij pij weten kan je al jaren javascript laden buiten de store om en zelfs updates zo voorzien in beperkte mate. Maar als ik iets extra kan downloaden en uitvoeren. Dit hebben ze als het mij goed voorstaat gedaan om de klagende ontwikkelaars sneller te laten updaten. Dus het is niet 100% de fout van Google.

[batjes]

1% is niets om mee te koop te lopen.

Als 1% van <insert distro> repository malware bevat, kan je die repository wel weggooien. Niemand laat die repo nog in zijn of haar sources.list staan.

En daar willen ze op enterprise niveau vertrouwen mee winnen? Microsoft krijgt al de volle laag voor 0,000000001% aan malafide software.

[killergrave]

1% op het schaal van Google zijn App Store is toch gigantisch. Gezien de groep kwaadwillenden een behoorlijk kleine groepje is. Betekend dat dat die 1% toch een bizar hoge succes rate is voor de malware verspreiders. Dat is alsof je zegt 1% van alle mensen tussen ons zijn “sleepers” voor een of andere onbekende organisatie met kwade bedoelingen. Dus 1/100. Nou dan voel ik me echt niet meer veilig in dat ecosysteem.

[kabelmannetje]

Je kan Google moeilijk verantwoordelijk houden voor allerlei zaken die niet door de beugel kunnen. Dat de Playstore een basisveiligheid biedt, wil niet zeggen dat Google claimt dat er geen malware bestaat. En dat is ook logisch. Het toevoegen van malware is zo simpel als wat.

[kodak]

Het verantwoordelijk houden te laten blijken waarom ze het 'rigoureuze' controle noemen en die 1% dan redelijk is heeft niet als doel ze verantwoordelijk te houden voor wat criminelen doen. Google gebruikt hun controles en beveiliging als verkoopargumenten, daar hoort verantwoording bij voor wat ze redelijk vinden waar ze klanten en de rest van de wereld mee opzadelen.

[kabelmannetje]

Opnieuw, nergens beweert Google dat het onmogelijk is om malware te voorkomen. Verder haal jij verzonnen argumenten aan. Het artikel zegt dat minder dan 1% potentieel" deze techniek gebruikt. Nergens wordt gezegd dat deze 1% malware bevat, slechts dat het potentieel tech isch mogelijk is en dat verder onderzoek nodig is.

En, die 100% garantie geeft geen enkel bedrijf. Volkomen logisch.

[Reactie gewijzigd door kabelmannetje op 22 juli 2024 16:23]

[kodak]

Waar lees je dat ik stel dat google het 100% kan voorkomen? Want verantwoordelijkheid nemen genoeg te doen wil niet zomaar zeggen dat alleen 100% genoeg is. Die 1% op het totaal kan prima genoeg zijn, maar het kan net zo goed dat ze met die 1% 75% van al deze problemen doorlaten door onredelijke gebreken in hun controles. Google legt op dit moment geen enkele inhoudelijke verantwoordelijkheid af.

[kabelmannetje]

> waar lees je dat ik stel dat google het 100% kan voorkomen?

Waar lees je dat jij dat claimt?

> Die 1% op het totaal kan prima genoeg zijn, maar het kan net zo goed dat ze met die 1% 75%

Opnieuw, dat is niet wat dit onderzoek van Google zegt.

> onredelijke gebreken in hun controles.

Opnieuw iets dat niet uit dit onderzoek blijkt.

> Google legt op dit moment geen enkele inhoudelijke verantwoordelijkheid af.

Dat doen ze wel, door interne zwakheden te communiceren.

[oltk]

Wat heeft Google hiermee te maken? De ontwikkelaar voegt later, via een update en via eigen servers, de malware toe.

Even je boze anti-google pet afzetten.

[_Pussycat_]

Uiteraard heeft Google hiermee te maken. Het is idee is dat via de Playstore je veilig dingen kunt installeren. Wanneer dat niet het geval is is dat een behoorlijk problem voor de gebruikers.

[CivLord]

De vraag is echter of het achteraf dynamisch laden van code verboden is (tegen de voorwaarden van de Play store) en of het verbieden ervan niet tot grotere problemen leidt?

[kodak]

Het nieuws, wat google er zelf van maakt, is dat het dynamisch laden van malware niet toegestaan is. Dat google dynamisch laden mogelijk maakt is dus juist een reden dat ze meer verantwoording horen af te leggen voor de nadelen van googles keuze en 'rigoureuze' controles.

[rvt1]

is natuurlijk ook de reden waarom Apple dit vanaf het begin niet wilde.

[kabelmannetje]

Ook in het Apple ecosysteem is het toevoegen van malware een eitje. Maak een app, zet er wat versleutelde code in die na executen uitvoerbaar is, en je kan binnen de rechten van iOS doen wat je wil.

[StGermain]

Binnen de rechten van iOS, dan zitten ze in een sandbox.

[batjes]

Want die sandbox is moeilijk om uit te breken als dit, meerdere malen, met drive-by websites te doen is.

[rvt1]

Je hebt het hier over wat anders. Waar het in het artiesten om gaat is het uitvoeren van code dat ergens anders opgehaald wordt.

[kabelmannetje]

Dat klopt. Bij Apple moet je daarvoor iets anders verzinnen.

[schrikbeeld]

Of het DCL heet of iets anders, je zou verwachten dan Google zo’n malafide ontwikkelaar onmiddellijk blacklist. Google heeft er belang bij dat de Store schoon blijft, temeer omdat Apple hierin toch een betere reputatie heeft.

[CivLord]

Maar die ontwikkelaar heeft een uur later onder een andere naam een vergelijkbare app in de store staan.

[schrikbeeld]

@CivLord als dat gebeurt moet het toch opvallen!
Voor de gebruikers van, zeg bijvoorbeeld, de NOS app is het niet handig als die app een andere naam krijgt of een ander logo, dus die malafide ontwikkelaar moet dat hetzelfde houden, anders verliest hij klanten.
Dan kan Google daar makkelijk op testen en de malafide ontwikkelaar onmiddellijk weer blocken.

[CivLord]

Wanneer zo'n malafide ontwikkelaar gaat voor de langdurige relatie, waarin informatie voor langere tijd van het slachtoffer binnengehengeld wordt, dan heeft hij inderdaad een probleem wanneer de app uit de store gehaald wordt. (En wanneer Google er voor kiest om de app ook van alle besmette telefoons te verwijderen. Dat heft namelijk niet te gebeuren.)
Wanneer de ontwikkelaar er voor gaat om eenmalig alle data binnen te halen, dan is een catchy naam en beschrijving waarom dit programma onontbeerlijk is genoeg om geïnstalleerd te worden. Na een bepaalde tijd wordt de malafide code opgehaald en geïnstalleerd en nadat die zijn werk heeft geaan is het in principe klaar. Wnneer Google er daarna achterkomt dat het malware is en de app uit de Play Store verwijdert is het kwaad al geschied en kan de ontwikkelaar onder een andere naam dezelfde app onder een andere naam opnieuw in de Play Store zetten en hengelen naar nieuwe slachtoffers.

[TheMaster004]

Jammer dat de term versioning wordt gekozen, die in de software engineer discipline gewoon een best practice is, dus iets positiefs. Nu gaan twee termen door elkaar heen lopen. Noem het Dark Versioning of wat voor suggestie doet een LLM voor een betere naam?

[Christoxz]

Het staat ongelukkig in het artikel. De praktijk heet geen versioning. De actie wordt gedaan doormiddel van versioning, exact als jou engineering term.

One way malicious actors attempt to circumvent
Google Play’s security controls is through versioning.
Versioning occurs when a developer releases an
initial version of an app on the Google Play Store that
appears legitimate and passes our checks, but later
receives an update from a third-party server changing
the code on the end user device that enables
malicious activity.
One common form of versioning is using dynamic
code loading (DCL). DCL is defined as an app which
downloads and loads code files from untrusted
sources.

[Reactie gewijzigd door Christoxz op 22 juli 2024 16:23]

[nullbyte]

Dit valt onder "Download New Code at Runtime" https://attack.mitre.org/techniques/T1407/

Bijvoorbeeld:
Judy is auto-clicking adware that was distributed through multiple apps in the Google Play Store.
Judy bypasses Google Play's protections by downloading a malicious payload at runtime after installation.

[Reactie gewijzigd door nullbyte op 22 juli 2024 16:23]

[sdsnatcher73]

Google kan toch wel een permissie zetten op DCL? Net als op toegang tot contacten of foto’s en zo. Dan kun je als gebruiker 1. zien dat een app DCL wil doen en 2. dit toestaan of weigeren…

[R4gnax]

Dat wordt een wapenwedloop tussen het uitvogelen van nieuwe verborgen manieren om DCL in te zetten; en het te detecteren.

Betere aanpak: alleen het uitvoeren van signed code toestaan. Maar het mogelijk maken om het OS zelf de code te laten signen met een door de beheerder van de originele app-store co-signed certificaat (zodat zowel de eindgebruiker als de store vendor schadelijke updates de nek om kunnen draaien).

En dan het signen van die code niet achter een toekenbare permissie steken; maar gewoon altijd bevestiging van de gebruiker vereisen.

[Reactie gewijzigd door R4gnax op 22 juli 2024 16:23]

[qlum]

Dat klinkt leuk van een beveiligingsoogpunt maar heeft wel gevolgen qua usibility voor apps waarbij het uitvoeren van code van de gebruiker of de app maker wel wenselijk is. Denk aan addons voor de mobile versie van firefox, of bijvoorbeeld termux in het extreeme of misschien zelfs apps met de rechten om apps te installeren.

Android is minder gesloten dan ios, ja dat brengt beveiligingsrisico's met zich mee maar bied ook meer vrijheid.

[batjes]

Android is ten opzichte van een Linux of Windows nauwelijks minder gesloten dan iOS. Je moet je eigen toestel hacken om die vrijheid te krijgen en dit kan in principe enkel bij de gratie van de fabrikant.

F-Droid is leuk, maar het kan zonder root niet eens auto-updaten. Of probeer op een recente android die *($#(*#$# gestures maar uit te schakelen zonder onscreen toetsen te krijgen.

Wat vrijheid, die elke Android release verder beperkt wordt.

Het is dat je met het hacken van Android meer vrijheid krijgt dan bij het hacken van iOS, maar het verschil voor end-users is eigenlijk minimaal.

[qlum]

Ja Android heeft zijn beperkingen, ja ik gebruik root, maar ios is toch echt een heel stuk verder gesloten.

[mcyh]

Daarom ben ik blij dat bij Apple alles langs hen moét passeren.

MaariIk begrijp wel dat - om verschillende redenen— niet iedereen daar om blij om
is; zoals het financiële plaatje icm cross platform abonnementen.

[Bongoarnhem]

Waarom zou dit op ios niet kunnen? Als de app door de initiële controle heen komt kan deze toch zelfstandig een update binnenhalen? Denk aan een spelletje dat nieuwe “game data” moet binnenhalen, gaat bij Apple alles via hun servers en is dat niet gewoon via ssl/vpn af te schermen voor een kwaadwillende?

[RefriedNoodle]

Van Apple's guidelines mogen apps geen code downloaden en uitvoeren, en dat is reden om een app te weigeren in de store. Dus als ze bij de reviews hun werk goed doen, zou dit niet voor mogen komen.

[Anoniem: 718943]

Bij mij weten reviewt Apple de functionaliteit en niet de code. Aangezien het al een gebouwd en signed pakket is en ik aanneem dat ze dat niet zomaar weer uitelkaar kunnen trekken, heb ik daarnaast ook nog nooit code-gerelateerde feedback gehad van Apple, enkel over bugs. Dus het reviewproces is in feite een testproces.

[MisterData]

Ze reviewen wel degelijk welke API’s je aanroept.

Als daar iets tussen zit dat entitlements nodig heeft werkt je app niet (tot je de entitlements aanvraagt en Apple dat goedkeurt).

Als je private API’s aanroept weigeren ze gewoon je app.

Als je met JavaScript/webviews het gedrag van je app nadien aanpast, dan ben je in principe nog altijd beperkt tot datgene waar je app bij mocht ten tijde van review..

[MisterData]

Een iOS-device zal alleen (Apple-) signed code uitvoeren, dus zomaar code downloaden gaat niet. Iets als JIT is ook niet toegestaan door het OS. Dus native code downloaden en uitvoeren gaat niet zomaar zoals bij Android kennelijk wel kan met Java-code. Je zou wel een interpreter in je app kunnen draaien natuurlijk (iets als Lua oid). Dan nog controleert Apple welke API’s je gebruikt (specifieke toestemming is soms nodig via speciale entitlements, zonder welke je app de api niet kan aanroepen).

[Accretion]

Je kan wel een app maken die via een webview een pagina laat zien met 'nieuws'.

En dan (zonder de app te updaten) die webpagina veranderen naar een scam-site.

[Reactie gewijzigd door Accretion op 22 juli 2024 16:23]

[Lord Anubis]

Fout, ze checken ook de code. MAAR, er schiet wel eens wat ertussen door. Ik weet er was een developer die tientallen apps aanbood, en die allemaal verborgen code had die andere code wilde binnen halen; elke app werd afgekeurd.
Tevens alle apps are signed dus je kan niet zomaar iets in de app zelf veranderen.

[Happyme]

Dit is oud nieuws toch? In voorgaande iOS releases en toestellen destijds? En daarbij de Boston attacks en het FBI verhaal wat er helemaal een sport van heeft gemaakt voor menig hacker nu ze weten dat het te doen is.

[Anoniem: 718943]

iOS heeft ook gewoon hybride apps. Daarmee is het vast wel mogelijk op een later tijdstip je JS code aan te vullen met wat extra externe logica.

Even googelen; kan wel, mag niet. (Duh).

[Lord Anubis]

Je JS code?
Kan alleen een webview beinvloeden maar kan geen app code starten.

[Reactie gewijzigd door Lord Anubis op 22 juli 2024 16:23]

[well0549]

Als dat echt zo zou zijn dat er alleen gesigneerde code gedraait mag worden....

Waarom zijn er dan kwetsbaarheden in iOS...

Natuurlijk grote onzin, open de eerste de beste browser op iOS, ga naar een web pagina en presto, ongecontroleerde Java code is al uitgevoerd...

[aikebah]

Natuurlijk grote onzin, open de eerste de beste browser op iOS, ga naar een web pagina en presto, ongecontroleerde Java code is al uitgevoerd...

Niet op iOS (geen support voor Java) en op andere systemen heb je dan heb je wel een zwaar verouderd systeem, want java applet technologie is (gelukkig) al lang de nek om gedraaid.

Ff scherp blijven Java <> Javascript ondanks de overeenkomsten in een deel van de naam zijn het twee losstaande technologieën

[Reactie gewijzigd door aikebah op 22 juli 2024 16:23]

[CivLord]

Gefeliciteerd! Je hebt iemand gecorrigeerd omdat hij niet de juiste naam van de scripttaal gebruikte.

Maar je bent niet ingegaan op waar het in de reactie om ging, dat het mogelijk is om in een browser code uit te voeren die op een webpagina staat.

[well0549]

Dan voor de steun,
Maar als iemand de boodschap niet kan begrijpen omdat ie struikeld over een verkeerde geformuleerd antwoord ben ik zowiezo geen zin en een reactie.

Inhoudelijke heeft hij totaal niet gereageerd dus een beetje een sneu figuur in mijn ogen.

Hij ziet wel wat ik bedoelde gezien zijn reactie maar wordt zo geobsedeerd door een woordje dat ie totaal vergeet ook inhoudelijk te reageren....

Sneu mannetje

[Reactie gewijzigd door well0549 op 22 juli 2024 16:23]

[well0549]

Leg dan uit waarom er kwetsbaarheden in iOS kunnen zitten...

[aikebah]

Omdat programmeren mensenwerk is en een foutje in een klein hoekje genoeg is voor een exploit. Ook iOS is een complex software systeem. Met genoeg mens- en computerkracht van hackers is het vrijwel altijd mogelijk om een 'undocumented, unintended' feature in de codebase te vinden die het mogelijk maakt met speciaal geconstrueerde input code uit te voeren die nooit had gemogen.

iOS is daarin in mijn ogen niks beter dan andere OSen, enkel net iets sterker gelimiteerd (dichtgetimmerd) in wat langs openbare methoden toegestaan is.

En net als andere OSen is iOS in de loop van de tijd ontdaan van een aantal van zulke exploit mogelijkheden. Of er daardoor ook minder zijn is moeilijk vast te stellen, want de gaten zijn weliswaar gedicht, maar er is ook weer het nodige aan nieuwe code/features bijgekomen.

De enige veilige computer is nog altijd de computer die volledig uitstaat.

[MisterData]

1. Signed code kan nog steeds zwakheden bevatten
2. Safari heeft speciale ‘entitlements’ waarmee het (JavaScript-)code naar native mag compileren en uitvoeren (JIT).

[lenwar]

Game data is geen executable data.
Het idee is dat alles dat ‘uitgevoerd’ wordt (scripts, executables, enz) altijd in de app moet zitten.
Content kan je later aanbieden.
((Een foto/filmpje/kaart/wapen/gebouw/enz heeft geen code. Alleen eigenschappen))

In theorie zouden de eigenschappen van een onderdeel een stuk code kunnen activeren, maar dat zou dus gecontroleerd moeten worden bij het toelaten van de app

Dit is bijvoorbeeld één van de redenen dat je geen addons voor browsers hebt die je achteraf installeert op iOS.

Ze hebben nu dus eventjes ‘apps’ in de App Store die bepaalde hooks van Safari kunnen beïnvloeden, maar dat is natuurlijk niet hetzelfde als wat je met Firefox op een pc doet.

[kabelmannetje]

Nee, dat geldt niet voor executable code. Je kan natuurlijk wel in deze app een blok encrypted data zetten die buiten de automatische scanners blijft. En dan de malware draaien.

[TrekVogel]

Oprechte vraag. Is DCL bij Apple geheel niet mogelijk?

[xFeverr]

Alleen JavaScript voor zover ik weet in een browser-view. Maar dat is logisch natuurlijk en die heeft alleen toegang tot Safari API’s. Daarin zit ook een mogelijkheid om berichten te sturen naar je native app zodat die ook native code kan uitvoeren. Maar die code is al aanwezig en gecompileerd. Daar kun je dus geen nieuwe zaken toevoegen.

[R4gnax]

die heeft alleen toegang tot Safari API’s

Behalve wanneer er van exploits gebruik gemaakt wordt om uit Safari's sandbox te ontsnappen en arbitraire code uit te voeren. En die zijn er over het verloop van het bestaan van iOS heel wat geweest.
Werden ook heel vaak ingezet om iOS apparaten te jailbreaken. (Bepaalde onderdelen van Safari hebben vziw ook gewoon root rechten, waardoor dat op zich ook weer makkelijker zou worden.)

[xFeverr]

Die exploits zullen veelal ook via en met behulp van de Safari API’s zijn. Die zijn dan te misbruiken.

Als er bijvoorbeeld een fout zit in de Safari implementatie van console.log, dan is het dus nog steeds bia die weg gebeurt.

En anders doen ze het wel via lettertypes in PDFjes, zoals dat ging met jailbreak.me
Mooie tijd.

[kodak]

Zowel Google als Apple zijn afhankelijk van het op tijd herkennen van dit soort pogingen door criminele ontwikkelaars. Ze zullen hooguit andere aanpak voor het proberen herkennen hebben, maar proberen is zelden genoeg om 100% van een ander te winnen. Apple is wat dat betreft bijna als Google: heel onduidelijk en vaag om als klant te kunnen controleren of hun controles voldoende zijn en ze verantwoordelijk te houden.

[Lord Anubis]

Vind dat wel meevallen.

[SpaceMarine]

Ja dit klinkt nogal als "klok en klepel" want waarom zou dit niet kunnen bij apple?
Grote verschil is dat bij Apple dit nooit naar buiten wordt gebracht

[Frame164]

Heb jij dan voorbeelden waarbij dit wel gebeurd is?

[SpaceMarine]

een vraag met een wedervraag beantwoorden alleen omdat je het niet eens bent met de vraag...
Mocht je een carrière in de politiek ambiëren, er is weer genoeg ruimte in de 2e kamer

Maar mijn punt is meer dat Apple nogal beschermend is over alles wat ze doen en naar buiten brengen. Het is een veel meer gesloten platform maar dat wil niet zeggen dat bij 3rd party apps dat dit soort dingen niet kunnen gebeuren. Als iemand claimt dat het waterdicht is en ze daar best extra voor willen betalen dan ben ik wel nieuwsgierig of dat ergens op is gebaseerd. That's all.

[FONfanatic]

een vraag met een wedervraag beantwoorden

Een heel normale gang van zaken in de wetenschapsfilosofie met het doel drogredenaties zoals cirkelredeneringen te voorkomen.

alleen omdat je het niet eens bent met de vraag...

Mocht je een carrière in de politiek ambiëren, er is weer genoeg ruimte in de 2e kamer

Dat heet sofisme: de wijsneus uithangen, enkel om een debat te vertragen en terloops de aandacht te verleggen. Te pareren door de wijsneus erop te wijzen dat het geschikte middel in zulke gevallen is, per motie om een aanvulling van de precondities te vragen, zoals de Raad van State immer verzorgt als preambule bij beoordelingen van wetsvoorstellen. Waardoor dat soort moties zelden aangenomen of uitgevoerd worden.

[watercoolertje]

'Onze zon kan niet uitgaan want dat heeft ie nog nooit gedaan.' - dat iets (nog) niet gebeurt is zegt precies niks over of het kan (gebeuren).

De vraag was waarom zou dit niet bij Apple kunnen waar je ook externe data kan ophalen? Heb je daar ook nog antwoord op of wilde je bewust van die vraag afdwalen?

[Reactie gewijzigd door watercoolertje op 22 juli 2024 16:23]

[blackjack21]

De vraag was waarom zou dit niet bij Apple kunnen waar je ook externe data kan ophalen? Heb je daar ook nog antwoord op of wilde je bewust van die vraag afdwalen?

Nee, eerst wordt de vraag gesteld om vervolgens te zeggen dat Apple het nooit naar buiten brengt.

Grote verschil is dat bij Apple dit nooit naar buiten wordt gebracht

Met stellen dat het nooit naar buiten wordt gebracht wordt de aanname gegeven dat het wel gebeurd alleen dat Apple hier nooit over informeert. Dan moet je ook aantonen dat het wel gebeurd en dat Apple het vervolgens onder het tapijt veegt. De weder vraag van @Frame164 is dan ook geheel logisch.

De vraag was waarom zou dit niet bij Apple kunnen waar je ook externe data kan ophalen? Heb je daar ook nog antwoord op of wilde je bewust van die vraag afdwalen?

Het op een iets normalere manier vragen is wel zo netjes, dan zou je zelfs het sectie nummer erbij krijgen Maar vooruit, lees de Apple's App Review Guidelines door voor de details en is onderdeel van het validatie proces. https://developer.apple.com/app-store/review/guidelines/

Uiteraard kan iets dergelijks gebeuren dmv een 0-day exploit, maar dat is heel wat anders dan dat dit gewoon bewust mogelijk gemaakt wordt door de fabrikant zoals Google.

[Ortep]

Afwezigheid van bewijs is geen bewijs van afwezigheid.

[PrimusIP]

En ook niet voor aanwezigheid. Dus dan is het een onbewezen claim. En normaalgesproken ligt de bewijslast toch bij de persoon die iets stelt.

Intressanter is of wat hier bij Android gebeurt ook met IOS mogelijk is of niet.

[kabelmannetje]

Ja hoor, dat kan. Code encrypten zodat het buiten de checks blijft. Na executen app, kan je de meegebrachte malware ook draaien.

https://www.komando.com/s...ps-hiding-malware/852291/

[blackjack21]

Beetje jammer dat het artikel dat je aanhaalt het over iOS heeft maar de bron, research paper, over de MacOS Apple Appstore, wat totaal verschillende dingen zijn.

Link naar de bron in het artikel is https://privacyis1st.medi...nvestigation-6151114bb10e, de titel zegt het zelfs al: "Investigation report about the abuse of the Mac Appstore".
Zelf als je snel zoekt komt je nergens het woord iOS of iPhone tegen...

Ja hoor, dat kan.

Dat zou ik niet zo snel stellen op basis van een volledig onjuist artikel als bron.

Offtopic: de slogan van Komando "Tech advice you can trust™" kan linea recta de prullenbak in. Maar ja, dan hebben ze wel een artikel geschreven om een AV product aan te prijzen met commissie

[kabelmannetje]

Dit gaat over applicaties in de store smokkelen met malware, niet over betreffende OS.

[blackjack21]

@PrimusIP vraagt of dit op iOS ook mogelijk is, jij geeft aan van wel met een bron die over een andere App Store gaat waarmee je geen Apps op iOS installeert

Mac App Store, voor apps op MacOS: https://en.m.wikipedia.org/wiki/Mac_App_Store

Apple App Store, voor apps op iOS:
https://nl.m.wikipedia.org/wiki/App_Store_(iOS)

[kabelmannetje]

Ja, in die link staan duidelijke voorbeelden hoe malware ook in iPhone-land binnenkomt.

[snollygoster]

Apps waar ik aan werk worden zowel op Android als Apple buiten de desbetreffende appstores om geüpdate.
Zal wel niet mogen, maar het werkt wel.

[Reactie gewijzigd door snollygoster op 22 juli 2024 16:23]

[Lord Anubis]

Onder MacOS, maar denk niet onder iOS.

[Happyme]

Het kan wel degelijk, omdat het een computer is. Een leuk voorbeeldje zijn de jailbreaks waar het de hackers ook om draait per iOS release en desbetreffende getargette toestel.

[Sangreall]

Alleen voor de recente modellen is geen jailbreak uitgekomen de laatste jaren

[Lord Anubis]

Met een jaibreak daar ben je zelf bij.

En mijn hele woning wordt geregeld op drie Jailbreaked oude iPads. Maar daar staan geen andere apps op, alleen de mijne.

[Bongoarnhem]

Kennelijk is het toch niet waterdicht @mcyh …

[xFeverr]

Daarom ben ik blij dat bij Apple alles langs hen moét passeren.

Alles is een groot woord. Je kunt ook foute functies achter een feature toggle zetten die tijdens het reviewproces uit staat. Zaken die tegen Apple’s guidlines in gaan. etc. Maar de lijst met API’s die je kan aanspreken is bekend en kan niet meer wijzigen. Dat is waar.

Ik probeer alleen maar te zeggen dat het reviewproces niet waterdicht is en dat het ook enorm veel scheelt van review tot review of ze opeens ergens iets van vinden of niet, ookal zit het er jaren in.

Maar ze hebben wel een stok achter de deur. Als achteraf iemand komt klagen ben je toegang tot de app store kwijt, je geld kwijt, etc. Dat is de grootste stok waarmee ze kunnen slaan wat mij betreft.

[bwerg]

Je kunt ook foute functies achter een feature toggle zetten die tijdens het reviewproces uit staat.

Hoewel het niet precies bekend is wat apple doet bij het analyseren van een app zullen ze wel iets van een malware scan doen. Dan heeft iets achter een toggle verstoppen natuurlijk weinig zin, tenzij je de boel gewoon zodanig obfuscate dat het een virusscanner om de tuin leidt.

[kiang]

Er is geen enkele reden dat zulke veiligheid niet zou kunnen zonder dat apple de iphone dicht timmert: ze kunnen prima dit soort strenge veiligheidsnormen hanteren in hun eigen store en tegelijk andere stores toestaan.

Dat zij zullen strenge eisen aan apps in hun app store stellen is dan net een USP waar jij blijkbaar waarde aan hecht, wat ervoor zorgt dat developers absoluut zullen overwegen om toch in de app store te blijven, ook als er alternatieven zijn.

Kortom: jlde veiligheid die je wilt staat volledig los van apple die zichzelf een monopolie positie toeeigent.

[FONfanatic]

Och jee, het gebekvecht tussen Apple en Android fans barst weer los. Google doet dat tenminste nog met humor.

[paulvd89]

Met Ionic capacitor kun je web apps native draaien op iOS. Je kunt daarmee ook updates aan de app doorvoeren die niet opnieuw door de store gereviewd worden. Dat komt toch op het zelfde neer of heb ik dat mis?

[cricque]

Het nadeel is wel dat je een lange tijd moet wachten op goedkeuring van Apple, dus als er een serieuze bug is heb je gewoon pech

[poststamp]

Minder dan 1% klinkt niet zo veel maar als er 3.5 miljoen apps staan dan is dat toch geen klein probleem.

[PartyPenguin]

Ik schat dat de apps die ik persoonlijk en voor werk gebruik allemaal minstens bij de top 20% van meest gedownloade apps horen (denk behalve een paar niche uitschieters zelfs dat het vooral in de top 1% zit, aangezien die top 1% dus ook gaat om 35.000 apps).
Waar ik mee bedoel dat ik me afvraag me af hoe "laag" je moet zoeken om bijvoorbeeld bij de 10% minst gebruikte apps te geraken, zelfs al zijn dat er 350.000. Dat heeft natuurlijk geen rechtstreeks verband met die 1% die "potentieel gevaarlijk" is, er kunnen best malafide apps zijn met veel gebruikers en dat is in het verleden ook al zo geweest, maar als je dus bedenkt hoeveel van die 3.5 miljoen apps er zijn die maar een paar downloads hebben, en de apps met hogere gebruikersaantallen normaal ook wel afkomstig zijn van meer betrouwbare bedrijven of meer sociale controle krijgen denk/hoop ik dat het risico voor de gemiddelde smartphonegebruiker nog wel meevalt.

[Anoniem: 24916]

Wat dacht je van rechtstreekse zoekopdrachten?
Kinderen die horen over een leuk spelletje en die zoeken ze, ze scrollen niet.

[Kaoh]

Aangeprezen door een youtuber voor specifieke hack voor game x etc etc, inderdaad een terugkerend onderwerp van gesprek met mijn zoon. Pubers hebben werkelijk een natuurlijke hardhorendheid voor ouderlijk advies, maar die idioot op YouTube wordt gelijk gelooft.

[Artz]

Of mensen die 5 vage zaklamp apps downloaden omdat ze de ingebakken versie niet kunnen vinden. Jazeker, deze mensen bestaan!

[JWL92]

na enige tijd malware aan hun apps uit de Play Store durven toevoegen.

enkel apps en app-updates toelaten die afkomstig zijn van betrouwbare bronnen zoals de Google Play Store

Heb ik nou te weinig koffie op? of zou je ze juist beter UITZETTEN?

daarnaast, was dit toch niks nieuws?

[lethalseni]

Er wordt hier bedoeld dat je dus geen apps moet gebruiken die zichzelf updaten tijdens runtime. Updates via de Play Store laten geen malware door.

[Anoniem: 1777010]

Ja en hoe moet je dat weten dan?

[blorf]

Het grote probleem met 2 mobiele besturingsystemen. Niet kunnen zien wat er gebeurt is een groot risico, maar iedereen moet dat al jaren normaal vinden.
Alleen maar een firewall zou al een goed begin zijn. Programmatuur dat iets ergens heen probeert te sturen hoort niet zomaar te kunnen. Ook niet exact kunnen tonen waar dingen worden opgeslagen of vandaan gehaald is een groot risico. Helemaal bedenkelijk wordt het als een app meer mag dan de gebruiker. Dat is iig bij Android niet raar.

[skatebiker]

En dir firewall is het hem nu juist. Noch Android, noch iOS hebben een firewall. En dan bedoel ik eentje waarbij je per app permissie moet geven voor internet toegang, net als alle andere zaken, zoals file system, camera, etc.
Want de vanzelfsprekendhetid dat alles zomaar met internet mag verbinden is het grootste veiligheidslek. We proberen allerlei security patches om die gaten te dichten maar voor elk gat komt er weer minstens een nieuw gat. Dweilen met de kraan open dus.
Klinkt gek in deze online wereld, maar dat is wel het grootste lek. Waarom moet een smart home app constant met internet verbonden zijn als je alleen maar je eigen huis bedient? Voor zulke apps moet je af en toe als er een update nodig is (ja en dan buiten de Play Store om) de gebruiker om permissie gevraagd worden.

[lethalseni]

Bepaalde apps laten weten wanneer ze op het punt staan data te downloaden vanaf een externe bron, zoals bijvoorbeeld mobiele games.

In alle andere gevallen: niet.

Alleen apps gebruiken van een uitgever die je vertrouwt.

Edit: Er zijn apps die aangeven vanuit de Play Store een update nodig te hebben, als die dan ook daadwerkelijk de Play Store openen, zit je goed

[Reactie gewijzigd door lethalseni op 22 juli 2024 16:23]

[mbbs1024]

"Alleen apps gebruiken van een uitgever die je vertrouwt."

Maar hoe weet je als gewone gebruiker welke uitgevers te vertrouwen zijn of niet ?
Google op Apple zijn daar volgens mij veel beter toe in staat dan om het even welke gebruiker, want zij hebben daarvoor de nodige expertise en tools in huis, iets wat een normale gebruiker niet heeft.
En 100% detectie is een utopie, zoals met alles zal het altijd een kat en muis spel blijven om zulke dingen te weren.

[Anoniem: 1777010]

En als ze niet de Play Store openen ben je al te laat dus? Gouden tip hoor, wauw.

[lethalseni]

Humor herkennen is soms lastig, ik begrijp het

[Anoniem: 1777010]

Wat er niet is kan je niet herkennen

[Bruin Poeper]

Er wordt hier bedoeld dat je dus geen apps moet gebruiken die zichzelf updaten tijdens runtime. Updates via de Play Store laten geen malware door.

Helaas komt Samsung regelmatig met updates, wat totaal niet transparant is. Je moet ze maar vertrouwen...
Ik haal nooit/zelden updates via de playstore.

[bapemania]

Bedoel je dat je NIET update of daarvoor hoe dan ook de niet door Google Playstore gecontroleerde bronnen opzoekt om te updaten? Beide zijn niet aan te raden lijkt me, getuige dit artikel.

[Bruin Poeper]

Ik update Samsung wel, want krijg het door de strot gedrukt. Het zijn "beveiligingsupdates" he, maar er komen altijd nieuwigheden mee.
Ik moet er maar op gokken dat het goed komt.

[watercoolertje]

Wat moet je met een Samsung/Google/Apple/etc als je ze niet vertrouwt?

[Reactie gewijzigd door watercoolertje op 22 juli 2024 16:23]

[Bruin Poeper]

Wat moet je met een Samsung/Google/Apple/etc als je ze niet vertrouwt?

Tsja, het moet van de Overheid. Inloggen bij DigiD bijvoorbeeld. Of handsfree de telefoon opnemen in de auto.

[Anoniem: 718943]

Je kunt digid gebruiken met de meest domme telefoons. Zelfs met je oude nokia 3310 zou je nog in kunnen loggen via digid. Je krijgt dan gewoon de code doorge-smst of doorgebeld. En ook voor feature phones zijn er carkits (je kunt ook kiezen niet te bellen tijdens autorijden).
Zelfs dat hele corona spul kon zonder smartphone.

Dus wie het je ook verplicht een smartphone te hebben, de overheid is het niet.

[bwerg]

Tsja, het moet van de Overheid. Inloggen bij DigiD bijvoorbeeld. Of handsfree de telefoon opnemen in de auto.

Digid kan prima zonder Samsung/google/apple, dat kan ook gewoon op een desktop/laptop met een telefoon die SMS ontvangt. En als je dan nog iets over Windows of MacOS te klagen hebt kun je altijd nog 1000 smaakjes aan linux of BSD gebruiken.

Hands-free bellen: dat moet helemaal niet. Je kan ook gewoon even naar een parkeerplaats rijden en daar terugbellen.

[William_H]

Vertrouwen begint ergens, anders kan je niks...

[Frame164]

Als je een leverancier niet vertrouwt, waarom doe je er dan zaken mee? Of vind je het ook normaal dat jouw klanten jou niet vertrouwen?

[polord1]

Is zoiets bij apple ook mogelijk? En nee, ik ben geen apple-fanboy..

[SierraPapa]

Volgens mij niet, Apple heeft alles wat meer dichtgetimmerd met signed code. Precies tegen dit soort issues. Voor mij bewijst dit ook weer precies waarom ik geen behoefte heb aan extra appstores op mijn Apple. Laat maar lekker dicht, ik waardeer de veiligheid.

En nee, ook hier geen fanboy. Maar dat is een ander verhaal.

[langestefan|IA]

Maar code signing heeft helemaal niks te maken met alternatieve appstores. Validatie van code signature gebeurt namelijk op het device zelf, op kernel niveau. Zie ook: App code signing process in iOS and iPadOS

Dus sterker nog, het feit dat apple aan code signing doet is juist een reden om wél alternatieve appstores toe te staan.

[Reactie gewijzigd door langestefan|IA op 22 juli 2024 16:23]

[Lord Anubis]

Haha wat een fantasie om dat als reden te gebruiken.

[langestefan|IA]

Hoezo fantasie? Het betekent dat je dus niet afhankelijk bent van de app store om de app te authenticeren. Dat is een heel sterk argument om 3d party app stores toe te laten.

[Lord Anubis]

Ik vind het juist een slecht argument omdat je meer ongecontroleerde rommel toelaat.
Wat is de werkelijke reden om iets buiten de appstore te houden? Ik vertrouw zo’n figuur of organisatie niet.

Vertrouw ik Apple? I.i.g Meer dan andere software winkels.

[langestefan|IA]

Ik vind het juist een slecht argument omdat je meer ongecontroleerde rommel toelaat.

Maar jij snapt dus niet wat code signing is. Apple signeert jouw code, oftewel valideert dat deze van de juiste bron afkomstig is en geen malware etc. bevat. Hoe jij die code dan download maakt dan niks uit.

[Lord Anubis]

Ik snap zeker wat code signing is; heb enkele apps voor bedrijven in de store staan.

Maar dat is voor mij geen reden omdie andere winkels te vertrouwen. Jij spreekt misschien over iOS maar er is ook macOS waar je ongesigneerde apps kan laten draaien.

Ik koop of gebruik apps van derden buiten de/een app store maar weet dat ze gerenommeerd zijn, en kan ze persoonlijk benaderen en aanklagen bij problemen. Een App store als weder verkoper is een ander verhaal.

[Reactie gewijzigd door Lord Anubis op 22 juli 2024 16:23]

[langestefan|IA]

Dit gaat natuurlijk alleen over telefoons, niet over PC's. Dat is een heel ander verhaal.

Ik koop of gebruik apps van derden buiten de/een app store maar weet dat ze gerenommeerd zijn, en kan ze persoonlijk benaderen en aanklagen bij problemen.

Zie geen reden waarom dat niet bij een third party app store zou kunnen.

[FrostyPeet]

Tja, wat doe je tegen dit soort gasten die duidelijk overal lak aan hebben? In een land met een degelijke rechtstaat kun je ze nog voor de rechter slepen. Aangifte doen in een land met een zwakke it rechtsstructuur lijkt vrij zinloos.

- Borg (geld) vragen, gaan ze over de schreef dan is in elk geval (een deel van) de herstelkosten betaald. Als de dev het account "schoon" afsluit krijgt hij de borg terug.

- Met naam en toenaam en foto op een schande lijst? Beetje als de diamantbeurs in Antwerpen. Dan kom je er nooit meer in.

[sovereignthrone]

Off topic, maar wat doen ze dan in antwerpen? Ja ik kan het googlen, maar dan krijgen andere lezers dit ook niet mee

[FONfanatic]

De apps uit de Play Stores verwijderen is het minste dat er als reactie gedaan kan worden. Helaas kom je er dan als eindgebruiker pas achter dat er mogelijk iets loos is als je handmatig je apps nalopen gaat die al een tijd geen updates meer gekregen hebben. Dan kun je nagaan of ze nog in de Play Store of als webapp of als website beschikbaar zijn.

Helaas is er over dat soort apps kennelijk nog geen beleid dat virusscanners ze toevoegen aan de lijsten malware.

[S-1-5-7]

In de afbeelding staat: Enterprise-specific Play Store policy permits app installation
Betekent dit dat dit enkel mogelijk is als er bewust is gekozen om installaties van onbekende bronnen toe te staan? En dat daarmee de "gewone" gebruiker helemaal niet vatbaar is voor de 'kwetsbaarheid'?

Daar lijkt het namelijk wel op, omdat er ook staat:
Het Amerikaanse bedrijf meent dat enterprisegebruikers best enkel apps en app-updates toelaten die afkomstig zijn van betrouwbare bronnen zoals de Google Play Store of van het mobile devicemanagementplatform van het bedrijf zelf.

[Reactie gewijzigd door S-1-5-7 op 22 juli 2024 16:23]

[FONfanatic]

Niet "gewone" maar avontuurlijke dan wel naïeve dan wel onvoldoende geïnformeerde gebruikers laten het installeren van onbekende apps toe. En dan is het ook nog de vraag wat er met "instant apps" uitgehaald kan worden: apps die je niet geïnstalleerd hebt maar die Google je wel laat gebruiken.

[westlym]

Vraag hierbij. gebeurt dit alleen via Google? Of kan dit ook gebeuren bij Apple?

[Groningerkoek]

Tenzij je aan sideloaden doet is versioning bij Apple niet mogelijk.