Kwaadwillenden stelen gegevens iPhone door vervangen authentieke app

Onderzoekers zijn er in geslaagd om door middel van een malafide app data van een iPhone te stelen, waaronder mailtjes en sms-berichten. De applicatie vervangt een authentieke app die via de App Store is geïnstalleerd. Apple heeft nog geen oplossing vrijgegeven voor het lek van iOS 7 en 8.

Dat ontdekten onderzoekers van het Amerikaanse beveiligingsbedrijf FireEye. Zij hebben een video online gezet die laat zien hoe de aanval werkt. Aanvallers zouden de methode in de praktijk al toepassen, constateert FireEye.

De aanval heet Masque Attack en staat een aanvaller toe om een authentieke iOS-applicatie te vervangen door een malafide programma. Daarvoor stuurt hij een sms-bericht met een link naar het slachtoffer. Die gaat naar een site zodra hij op de link klikt. De site toont vervolgens de vraag of de gebruiker een applicatie wil installeren, zoals het populaire spel Flappy Bird.

Via de site kan de aanvaller een authentieke iOS-app vervangen. In de video demonstreert FireEye hoe de Gmail-app wordt vervangen door het installeren van het zogenaamde Flappy Bird-spel. Dit is mogelijk doordat Apple niet controleert of apps met hetzelfde Bundle ID ook hetzelfde certificaat gebruiken.

Daar blijft het niet bij, zo laten de onderzoekers zien. Zij tonen aan dat de neppe Gmail-app de onderwerpen en de inhoud van mailtjes in Gmail kan uitlezen en kan doorsturen naar de aanvaller. Daarnaast kan de malware ook sms-berichten doorsturen naar server. Een reboot zorgt er niet voor dat het doorsturen van berichten wordt afgebroken.

In theorie is Masque Attack gevaarlijker dan het onlangs ontdekte Wirelurker, waarvoor een usb-verbinding met een pc of Mac noodzakelijk is. Die malware verspreidt zich via geïnfecteerde apps in de Maiyadi-applicatiewinkel voor OS X en probeert na een infectie iOS-apparaten te besmetten.

Volgens FireEye gebruiken kwaadwillenden Masque Attack al in het wild. De aanval werkt in combinatie met iOS 7.1.1, 7.1.2, 8.0, 8.1 en 8.1.1 beta. Daarbij maakt het niet uit of Apples software is gekraakt of niet en alle officiële applicaties uit de App Store zijn te vervangen, behalve de software die Apple zelf meelevert op iOS-apparaten. FireEye heeft Apple in juli al geïnformeerd over het lek, maar het Amerikaanse bedrijf heeft nog geen patch uitgebracht.

Volgens het beveiligingsbedrijf kunnen gebruikers zichzelf voor Masque Attack beschermen door geen apps te installeren buiten de App Store of de eigen organisatie om. Daarnaast moeten gebruikers volgens het bedrijf nooit op 'install' klikken zodra een website een applicatie probeert te installeren. Ook moeten ze onbekende ontwikkelaars niet toestaan, aldus FireEye.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Reacties (83)

[4x4]

Een iOS probleem maar dan wel een app van Google gebruiken om het lek te bewijzen.

Wat voor hardcore Apple fan moet je dan wel niet zijn.

[nassau]

De standaard apple apps (die voor-geïnstalleerd staan) kunnen niet op deze manier worden 'vervangen'. Een hacker neemt dan de meeste populair app van een derde partij.

Niet zo'n vreemd voorbeeld lijkt me? Maar in principe kun je elke app-store app gebruiken. Onderzoeker FireEye staat niet bekend als apple-fan. In hun onderzoek noemen ze Flappy Bird als voorbeeld.

[RobbieB]

Belangrijk lek om snel te dichten, maar er is echt een absurd klein percentage gevoelig hiervoor. Dus voor 99,99999% vd iOS gebruikers niks om je zorgen over te maken.

[Croga]

Waar haal je dat vandaan? Zover ik hier lees is iedereen met een moderne iOS versie kwetsbaar en is de enige remedie goed opletten.

[ouweklimgeit]

Het gaat om de laatste zin van het bericht, zolang je niet de 'installeer vanuit onbekende bronnen' optie aan hebt staan, is er niets aan de hand. En dit is waarschijnlijk bij 99,9% van de gebruikers het geval.

[David Mulder]

"Installeer vanuit onbekende bronnen" is een Android concept. Ik heb net rondgezocht en kan toch echt niet zo'n optie op iOS vinden. Ik weet niet waarvandaan die applicatie exact word geinstalleerd, maar als ik het goed begrijp hoeft de gebruiker daarvoor niks in z'n instellingen aan te passen en heeft de aanvaller een "enterprise provisioning profile" nodig. Zou iemand met ervaring weten te vertellen wat de beperkingen zijn en hoe lastig het is om dit concreet uit te voeren?

Wat ik namelijk niet volg is het volgende: Als ik dit lees dan lijkt het bijna alsof iedereen zo'n third party app zou kunnen installeren als je éénmaal bij iOS enterprise program binnen bent, maar zou dat zo zijn dan zou ik weer hier en daar toch third party apps 'illegaal' opduiken.

edit:
Ah, alles wat Apple vraagt is het volgende:
http://www.fireeye.com/bl...oads/2014/11/IMG_0001.jpg
Waar zonder enige twijfel 80% van de mensen lekker ja op gaat klikken... want natuurlijk vertrouwen ze "Gmail"... want dat is de app die ze aan het openen zijn, zelfs als er in beeld staat "Another Development Network b.v." (Dat laatste heb ik toegevoegd na aanleiding van Sidewalk Super's comment, en ook dus maar m'n percentage omlaag gegooid)

Hoe dan ook, de belangrijkste regel uit het artikel is natuurlijk weer

We disclosed this vulnerability to Apple in July.

En Apple vind/vond blijkbaar dat hun huidige 'bescherming' goed genoeg was lijkt het op...

[Reactie gewijzigd door David Mulder op 22 juli 2024 19:32]

[SidewalkSuper]

"Gmail" is niet degene die ze moeten vertrouwen, want dat zal er niet in beeld staan. De naam die in beeld staat is de naam van de developer die bij Apple aangemeld is om certificaten te kunnen krijgen, zoals ook duidelijk op jouw plaatje staat.

Gebruikers zullen daar dus niet zo snel intrappen, maar het mag zeker gefikst worden.

Het is inderdaad niet lastig om een enterprise certificaat te krijgen, maar als het ingetrokken wordt kun je het niet meer gebruiken en kan je app niet meer starten. Iedere keer als je een app start zal dat gecheckt worden.

De huidige bescherming is natuurlijk ook niet verkeerd. Het is lastig om iets te verzinnen waardoor je dit kan afvangen. Je wil natuurlijk enterprise apps kunnen installeren en dat moeten alle soorten apps kunnen zijn die je wil. Dus als jij een enterprise app wil maken met het Gmail icoontje en de naam Gmail moet dat gewoon kunnen. Codesign pinning zou een deel van de oplossing kunnen zijn, zodat een bundle id aan een dev certificaat vastgepind kan worden.

[Reactie gewijzigd door SidewalkSuper op 22 juli 2024 19:32]

[David Mulder]

Comment hierboven aangepast, maar goed, zelfs als er een totaal onbekende naam staat, vanuit hun perspectief zijn ze nog steeds Gmail aan het openen 'en zal het dus wel goed zijn'.

Of stel je voor dat je de aanval nog net wat beter maakt. Eerst bied je deze app aan, daarna toon je in de browser dat de installatie is mislukt en dat ze het opnieuw moeten proberen. Tweede keer installeer je wel echt een 'nieuwe versie van flappy bird'. Na installatie is dat het eerste wat mensen gaan openen (en dus ook trusten) en als ik het goed begrijp krijg je daarna niet meer de melding als je Gmail opened later.

[SidewalkSuper]

Je kan in de browser niet controleren of een app goed geïnstalleerd is. Je loopt altijd tegen de sandbox aan. Wat je verder zegt klopt natuurlijk wel, daarom waarschuwde ik mensen in het iOS topic op GoT ook al voor problemen met deze manier van installeren.

Je weet gewoon niet wat je je op de hals haalt.

Als eerste stap zou het handig zijn als er een knop komt om enterprise mogelijkheden helemaal uit te schakelen en dat die knop standaard ingeschakeld is. Daarnaast zou het handig zijn als inzichtelijk is op je device welke apps allemaal een enterprise certificaat gebruiken.

[David Mulder]

Je kan in de browser niet controleren of een app goed geïnstalleerd is.

Nee, maar dat weerhoud je er niet van om te *beweren* dat het mis is gegaan. Na de eerste keer is alleen de gmail app ge-update zijn, dus als ze gaan kijken dan zien ze daadwerkelijk hun Flappy Bird app niet staan.

Als eerste stap zou het handig zijn als er een knop komt om enterprise mogelijkheden helemaal uit te schakelen en dat die knop standaard ingeschakeld is. Daarnaast zou het handig zijn als inzichtelijk is op je device welke apps allemaal een enterprise certificaat gebruiken.

Of gewoon zoals op Android: Apps kunnen alleen zichzelf update'en.

[SidewalkSuper]

Dit is ook geen updaten. Een app wordt herschreven en met het enterprise certificaat opnieuw gesigneerd. Het is dus in feite een nieuwe app, maar met dezelfde mogelijkheden en instellingen als de oude.

[Ranney]

Ik zou denken dat als je in IOS de afhandeling aanpast naar:

1. "Je mag alleen apps updaten/vervangen als die door dezelfde ontwikkelaar(/certificaat) zijn ondertekend"
2. "Er mogen buiten de appstore om geen apps aangepast of geüpdatet worden die door de appstore zijn geïnstalleerd."

je al een groot probleem oplost. Of denk ik nu te eenvoudig?
Als je dan een App download en er staat in eens iets heel anders op je apparaat valt het al meer op. Dan is het 'overschrijven' niet meer mogelijk.

[revertive]

Het eerste punt is al in gebruik bij Android, als de developers/certificaat verschilt met het origineel kan je hem niet updaten. Je kan hem dan pas installeren als je de oude app (met originele developer/certificaat) uninstalled.

[Verwijderd]

Huh? Heb ik iets gemist? Je kan op iOS toch alleen via de Appstore installeren?

[Frustus Maximus]

Klopt bijna. Er is een mogelijkheid om als groot bedrijf je eigen apps te laten installeren, buiten de appstore om. Maar daar zijn meerdere handelingen en instellingen voor nodig om dat voor elkaar te krijgen.

Dit artikel is weer clickbait voor Tweakers. Zoals zoveel artikelen de laatste tijd. Het hoort bij de commercialisering van T.net

[Armin]

Er is een mogelijkheid om als groot bedrijf je eigen apps te laten installeren, buiten de appstore om

Nog een stapje verder. Het kern-probleem van de security van Apple is dat het een security tegen gebruikers was, en nooit voor gebruikers. Dat bedoel ik niet als sneer, maar het heel idee was gebruikers niet toe te staan uit andere bronnen te installeren. Enkel door Apple uitgegeven certifciaten zijn geldig. Apple echter is heel vrij in het geven van certificaten.

Dat zijn namelijk niet enkel certifcaten van ondernemingen ('enterprise') maar ook elke willekeurige developer die een ontwikkel-certificaat heeft. En zo'n certificaat krijgen is een fluitje van een cent.

Het zwakke punt is dat default élk certificaat geldig is op iPhone. Je krijgt wel een popup als gebruiker de eerste keer om een certificaat te accepteren, maar daarna is het hek van de dam.

Bij Windows Phone is het bijvoorbeeld precies andersom. Ontwikkelaars moeten een telefoon unlocken om niet-ondertekende apps toe te staan. Een wikkeleurige ontwikkelaar kan dus niet een malware app maken en deze installeren op een andere Windows Phone. Op iPhone wel.

Immers dit is de bug: Ik maak een app genaamd "Mijn App" en geeft het het ID van Google Mail, en onderteken met mijn eigen certificaat. Een niets vermoedende gebruiker denkt dat hij/zij "Mijn App" installeerd, maar in realiteit vervangt het nu de Google Mail app met alle gevaren van dien.

Dat is het fundamentele "probleem" met iPhone. Nu moet een gebruiker dus nog steeds het certificaat accepteren dus zo verschrikkelijk is het ook niet, maar dit is ook niet iets wat men makkelijk kan oplossen.

EDIT: typos.

[Reactie gewijzigd door Armin op 22 juli 2024 19:32]

[jasjenl]

Wat je hier zegt klopt niet helemaal: een enterprise certificaat is niet hetzelfde als het certificaat dat een normale ontwikkelaar krijgt, want die laatste kan alleen maar ad-hoc certificaten aanmaken die alleen installeren op iOS devices waarvan het UDID in het certificaat is opgenomen. M.a.w. dat installeert niet zomaar op elk willekeurig apparaat maar alleen op de apparaten die specifiek aan dat certificaat zijn toegevoegd. Enterprise certificaten kan dit wel mee maar die krijg je niet zomaar van Apple, dan moet je een veel uitgebreidere procedure doorlopen om hiervoor in aanmerking te komen.

[Aionicus]

Men vergeet helemaal in de discussie mee te nemen dat het ook gaat om dat er gewoon malefide apps in de orginele apple store kunnen komen staan , enkele maanden geleden was er ook al een tweakblog over dat het zo makkelijk bij elke partij naar binnen kwam , dat sommige geneens een code check doen.

Dus zeggen dat 99,9% van de gebruikers er geen last van heeft. In theory betekend deze methode dat elke "populaire" ontwikkelaar nu ook nog een extra target word , hack je zijn id dan heb je ineens 6mil infecties....

[vistu]

Maar dat gaat dus niet, ik kan niet zelf een app inschieten bij apple met het bundle id van google (melding: bundle id bestaat al). Deze aanval is dus in elk geval niet mogelijk via de App store.

[Aionicus]

Je snapt het niet helemaal , de opzet is dat een developer zelf een valide app schrijft , na het installeren van die app en hem wilt openen zou de developer bijvoorbeeld een melding kunnen geven dat er een app bijgewerkt moet worden voor goede integratie, de gebruiker moet 2x op ok drukken en dan werkt het . Hierna is de schade verricht want genoeg gebruikers zullen toch niet snappen dat ze toestemming geven om bepaalde instellingen (zoals dus externe pakketbronnen) aan te vinken. Je moet alleen zorgen dat de gebruiker niet ziet dat ze daar de toestemming voor geven. Hierna word dus het malifice appje geinstalleerd die bv net zo werkt als de laatste gmail app maar intussen een kopietje van elk berichtje opslaat of doorstuurd of misschien wel al je toetsaanslagen opslaat.

Je hoort er een stuk minder over bij apple maar toch zijn ook daar genoeg malifide apps te vinden , het is maar hoeveel moeite en hoe creatief de gedachtegang is van de kwaadwillige in hoeverre ze je om de tuin kunnen leiden.

[Armin]

want die laatste kan alleen maar ad-hoc certificaten aanmaken die alleen installeren op iOS devices waarvan het UDID in het certificaat is opgenomen

Als dat verandert is, ben ik op dit punt inderdaad gecorrigeerd, maar in het verleden was dat niet zo. Dwz er was geen koppeling tussen UDID en certificaat. Wél moest inderdaad het device gekoppeld worden aan jouw certificaat, hetgeen een limitatie kan zijn afhankelijk van hoe de hack uitgevoerd kan worden.

Probleem is namelijk dat dat koppelen ("provisioning") automatisch gebeurd (of gebeurde indien dat recent gewijzigd is, maar ik begreep van niet) in sommige gevallen. Kern is namelijk dat deze beveiliging meer bedoeld was voor de hoofdontwikkelaar om te zorgen dat niet elke teamlid zomaar op alle apparaten kan. Maar niet zozeer om devices te beschermen tegen de apps zelf. Ben je dus zélf de hoofddeveloper, valt die bescherming geheel weg, en blijft enkel de onpraktischheid van het nodig hebben van fysieke toegang.

En bij enterprise certifciaten is de fysieke toegang dus niet eens nodig.

Wat ook niet noodzakelijk waar is is dat enterprise certifciaten moeilijk te verkrijgen zijn. Het is een kwestie van een formuliertje invullen en in de praktijk zit daar geen strenge controle op. De bekende gebruiksvriendelijkheid en openheid tov bedrijven die iOS apps willen maken vs veiligheid.

Bij Wirelurker was er bijvoorbeeld ook een enterprise certificaat gebruikt. Dat kan Apple dan bij misbruik meteen intrekken, maar dat wordt dan "wack a mole" als Apple niet oppast.

De beveiliging van Apple is dus vooral dat het 'lastig' is, dan dat het systeem zelf waterdicht is. Dat is zoals ik eerder aangaf logisch, want het was vooral bedoeld als beveiliging tegen altermatieve app stores, en niet zozeer malware.

[johnkeates]

Dat is het fundamentele "probleem" met iPhone. Nu moet een gebruiker dus nog steeds het certificaat accepteren dus zo verschrikkelijk is het ook niet, maar dit is ook niet iets wat men makkelijk kan oplossen.

Hier klopt heel weinig van. Daar hebben we CRLs voor en OCSP. Certificaten kunnen op elk gewenst moment ongeldig verklaard worden, op afstand.

Daarnaast is dit dus een probleem voor mensen die certificaten en profielen en andere dingen 'buiten' de AppStore om gaan toevoegen. Zoals met alle 'problemen' tot nu toe is het altijd pas raak als je zelf beveiliging uit zet/omzeilt. Er zijn nog steeds geen hacks die ongemerkt iets met je toestel kunnen doen.

[Armin]

Hier klopt heel weinig van. Daar hebben we CRLs voor en OCSP. Certificaten kunnen op elk gewenst moment ongeldig verklaard worden, op afstand.

Klopt, ware het niet dat, dat niet terzake doet. Sterker nog, dat zeg ik juist letterlijk:

Dat kan Apple dan bij misbruik meteen intrekken, maar dat wordt dan "wack a mole" als Apple niet oppast.

[tomvleeuwen]

maar dit is ook niet iets wat men makkelijk kan oplossen.

Waarom niet? Ik weet niet hoe het bij Windows Phone zit, maar bij Android is het niet zo makkelijk om een nieuwe versie van een App te installeren die met een andere key gesigned is (je moet eerst handmatig de oude app eraf gooien).
Ik verwacht dat Apple dit in zijn volgende update ook doet, in het artikel zelf staat het ook:

Dit is mogelijk doordat Apple niet controleert of apps met hetzelfde Bundle ID ook hetzelfde certificaat gebruiken.

[Armin]

Bij Windows Phone kan dat dus geheel niet, omdat developer apps altijd niet-ondertekend zijn.

1) Een Windows Phone accepteerd accepteerd geen niet-ondertekende apps tenzij je dat apparaat handmatig registreerd onder je Microsoft-account.
Je kunt zo dus wel je eigen niet-ondertekend app in aanbouw installeren op je eigen unlocked device. Maar die app zal nooit gedownload kunnen worden van een URL naar een gewone consumenten Windows Phone.

2) En zelfs als je een Windows Phone van een slachtoffer weet te unlocken (vereist én fysieke toegang én de pincode van de gebruiker), dan nog kan je niet een ondertekende app vervangen door een niet-ondertekende.

Dit is mogelijk doordat Apple niet controleert of apps met hetzelfde Bundle ID ook hetzelfde certificaat gebruiken.

Dat zou een goede optie zijn, doch het probleem daarmee is wel dat Apple dan wel het probleem van 'expired' certificaten moet oplossen. Verschillende versies van legale apps zijn soms met verschillende certificaten ondertekend simpelweg omdat de oude verlopen is.

[GWTommy]

Ik snap werkelijk niet waarom deze reactie +3 krijgt. Wat voegt het toe?

Je legt simpelweg uit hoe het werkt en noemt het een probleem. Ik moet eerst het UDID opnemen in een certificaat wil ik een app (development en/of ad-hoc) op een iOS apparaat van een vriend/kennis zetten.

Dus jouw hele verhaal, het "fundamentele probleem met iPhone", is op te lossen om bij het update proces te checken op certificaat én bundle ID.

[Armin]

het UDID opnemen in een certificaat wil ik een app

Het UDID is niet in het certifciaat opgenomen. Als ik jouw UDID heb, kan ik jouw apparaat toevoegen aan de geautoriseerde devices. Zoals ik aangaf is dat namelijk enkel bedoeld als beveiliging van het development account, en niet als beveiliging van de telefoon.

het "fundamentele probleem met iPhone", is op te lossen om bij het update proces te checken op certificaat én bundle ID..

Klopt, maar:
1) dat wordt vandaag niet gedaan en is dus vandaag wel degelijk een fundamenteel probleem. Wat ik zei was geen sneer naar Apple, maar het is wel degelijk een inherent probleem vanwege de manier waarop het systeem opgezet is. Het is namelijk een beveiliging tegen gebruikers (alternatieve app stores), en niet voor gebruikers.

2) verschillende versies van dezelfde app kunnen een verschillend certifciaat hebben. Dus je kunt niet enkel kijken of het certificaat gelijk is. Je moet dan dus al een groupering hebben. Deze is echter vandaag de dag niet aanwezig in Apple's certificaat structuur.

Ik vermoed dat men wel een soort zachte check kunnen doen op basis van de naam, en dat dat de drempel al behoorlijk hoog maakt zodat de meeste hackers zullen afvallen, maar het is zeker niet triviaal.

[Gohan040]

In mijn ogen is dit een terecht nieuws bericht en van belang dat mensen hiervan op de hoogte zijn. Dat de gemiddelde tweaker hier niet in trapt dat geloof ik wel , maar er zullen er genoeg zijn die zonder waarschuwing hier wel in trappen. Dmv zo'n nieuws bericht worden mensen hiervan op de hoogte gebracht die dan de niet Tweakers.net bezoekers hier ook weer van op de hoogte zouden kunnen brengen.... Kortom het balletje gaat rollen en de onwetende medemens krijgt hier misschien ook lucht van en gaat hopelijk hier dus niet in trappen....
Imho nou niet bepaald clickbait...

[BoringDay]

Niet zonder waarschuwingen want je moet in eerste instantie al een wachtwoord invoeren en ten tweede moet het ook nog je beveiligingsinstelling zijn gewijzigd om het uberhaud te kunnen installeren.

En dat gebeurd niet door kaboutertjes die midden in de nacht achter je computer gaan zitten.

De commotie is dus ook zwaar overtrokken, wellicht om media-aandacht te krijgen. Zoals in de meeste gevallen.

[Mathijs]

Exact, zolang het om particuliere gebruikers gaat.
Ten eerste moet install from unknown sources aan staan en daarnaast moet je dan op een link klikken die je via een sms binnen krijgt en dan daadwerkelijk ook nog de app installeren die je dan aangeboden wordt. Dat lijkt me een combinatie van factoren die niet snel zo zal zijn.

Dit is waarschijnlijk wel groot nieuws voor de it afdeling van een bedrijf dat iphones met eigen apps aan de werknemers heeft verstrekt.
Kijk maar eens hoeveel procent van het klikvee op een link klikt in een overduidelijke phishing email.

[[Remmes]]

Install from unknown sources? Dat heb ik op iOS nog nooit gezien of ik kijk niet goed. Wel op Android.

Maar inderdaad de kans is zeer klein dat dit veel schade aanricht. Je moet eerst zelf een keer of twee toestemming geven.

[Reactie gewijzigd door [Remmes] op 22 juli 2024 19:32]

[The Underminer]

Aan de ene kant zullen tweakers meer op hun hoede zijn voor scam smsjes, aan de andere kant hebben ze vaker de optie aanstaan om apps van buiten de store toe te staan lijkt me, zodat ze apps kunnen draaien die niet door de policies van Apple heen komen. Hebben ontwikkelaars deze optie om altijd aan, zoals bij Android?

[monojack]

Het is terecht een bericht dat nieuwswaardig is maar het wordt wel een beetje dramatisch gebracht als je op het einde leest dat je of sowieso al beveiligd bent of gewoon met een paar klikken al beveiligd bent.

Maar er zijn denk ik wel een degelijk percentage vatbaar voor dit virus momenteel en dit soort nieuws maakt dan ook dat dat percentage sneller naar beneden kan.

[Gohan040]

Mee eens, het drama gehalte is idd wat aan de hoge kant. Maar de nieuwswaarde is er zeker wel al is het enkel om mensen te waarschuwen. Imho dus geen clickbait...

[huntedjohan]

Bij jou is elk negatief nieuws omtrent Apple clickbait. Echt origineel is jou beschuldiging niet.

Dat integendeel met dit nieuws. Heel veel gebruikers vinden het wellicht wel handig om die instellingen aan te zetten om buiten de store om te kunnen installeren, dus een oplossing van Apple is gewoon meer dan normaal.

[Verwijderd]

Tenzij je fysieke toegang hebt tot het toestel, en een apple developer-account. Dan kan je ook de app vervangen.

Dit artikel geeft hier meer uitleg over trouwens:
http://www.zdziarski.com/blog/?p=4002

Het artikel legt ook uit waarom dit probleem ook niet zo eenvoudig te fixen is.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 19:32]

[SidewalkSuper]

Dit is precies hetzelfde lek als de nieuwsberichten over WireLurker. Deze manier van verspreiden is alleen anders. Ook belangrijk dat er gemeld wordt dat een Apple app nooit vervangen kan worden, maar alleen apps van derden, die normaal gesproken via de app store geïnstalleerd kunnen worden.

nieuws: Mac-malware infecteert iPhones en iPads
nieuws: Wirelurker richt zich ook via Windows op iPhones en iPads

Inderdaad een belangrijk lek om snel iets aan te doen. De gemiddelde gebruiker zal er waarschijnlijk niet zo snel intrappen.

Een infectie kan zich niet verspreiden vanaf de ene iPhone naar de ander en het is ook makkelijk ongedaan gemaakt, door de app te deleten.

[Reactie gewijzigd door SidewalkSuper op 22 juli 2024 19:32]

[orange.x]

Mij lijkt het belangrijkste feit dat het gaat om alleen 3rd party apps. Tuurlijk is het zuur dat iemand die Google Mail gebruikt op zijn iPhone zijn mailgegevens op deze manier kan "doorsturen". Maar indien je dus geen superbelangrijke software gebruikt maar bijvoorbeeld alleen games, wat maakt het dan nog uit. Ik kan nergens terug vinden dat als je een "vervanger" installeert voor bijvoorbeeld Angry Birds dat er dan allemaal systeeminfo of alle andere info van 3rd party apps uitgelezen kan worden. Er kan dus in principe alleen maar kwaad gedaan worden bij apps die daadwerkelijk prive-informatie bevatten en dus niet door Apple zelf gemaakt zijn. Plus dat je dus zelf ook nog op een knop moet drukken om het echt toe te staan.

Niet goed natuurlijk maar tis wel een beetje een "storm in een glas water"-verhaaltje.

[revertive]

Wat je nou zegt is dat phishing nooit een probleem is of geweest is want mensen klikken toch niet op de link, en niemand vult zijn gebruikersnaam en wachtwoord in bij een site die lijkt op het origineel maar het toch niet is want je kan het aan de URL zien.
Maar wat blijkt het is toch best wel een probleem want aardig wat mensen trappen erin.
Dat je ergens op moet drukken heeft virusmakers ook nog nooit in de weg gezeten, als je het maar officieel genoeg maakt trappen er genoeg mensen in om het te laten werken.

En je gaat natuurlijk ook niet angrybirds vervangen maar je laat de gebruiker denken dat ze angrybirds installeren en vervang op de achtergrond de g-mail app. Gebruikers denken er zal wel iets fout zijn gegaan want ik heb geen angrybirds op me telefoon, maar ondertussen is hun g-mail app vervangen door een nep app zonder dat ze dit weten, en worden hun mails/smsjes netjes naar een server verstuurd die daar weer verder mee kan werken.

Je hebt bij 1 ding wel gelijk als je je telefoon alleen gebruikt als een spelletjes computer ben je niet echt in gevaar, maar wie gebruikt zijn telefoon nou alleen om spelletjes te spelen? ik denk dat de meeste mensen er ook mee bellen hun mail lezen en wat smsen.

[orange.x]

Ik zeg niet dat phishing niet een probleem is of nooit geweest is.
Ik stel alleen maar dat in deze situatie er niet zoveel problemen zijn. Inderdaad denk je dat je app A installeert terwijl dit dan app B vervangt. Maar dan alsnog is het zo snel ik kan bedenken alleen een probleem voor mensen die prive-zaken doen met 3rd party apps EN dus gebruik maken van die link + accepteren dat een untrusted developer iets mag installeren. Ik denk dat heel veel gebruikers namelijk gewoon gebruik maken van de Mail app zelf.

Vanuit dat oogpunt zeg ik dus: zal wel meevallen. Want het is situatie A + B + C etc. Kans wordt dus steeds kleiner naarmate er meer moet gebeuren.

[SidewalkSuper]

Je kan nooit info van andere apps uitlezen, iOS heeft daar de sandbox voor. Ook informatie zoals contactlijsten, agenda, locatiegegevens, camera, foto's etc moet de gebruiker goedkeuren alvorens een app (malafide of niet) erbij kan.

[Luno]

Dat suggereert 1 op 10 miljoen.
Ik schat dat eerder 1 op 5 gevoelig zijn.
En zelfs al zou de waarheid in het midden liggen heb je nog een heleboel 9's teveel.

[SoloH]

Ik vind het nogal een serieuze hack. Er zijn echt wel veel mensen die op dat soort links klikken.

[Verwijderd]

Met het risico op een -100 : Apple en snel fixen? Not going to happen.
Als ik denk aan Poodle / Heartbleed .. Dat duurde me al veel te lang. En wat denk je van iedereen die op iOS 7 zit omdat iOS 8 op veel apparaten gewoon bagger is? (Zoals op mijn iPad 3).

Ik ga hier niet flamebaiten op iOS / Android, of wat dan ook. Wie het zoo ziet leest niet goed. Maar Apple zal dit niet snel fixen, en voor veel mensen zal de fix buiten bereik liggen.

Het hele eco systeem van smartphones en tablets leent zich niet voor snelle fixes. Dat zien we keer op keer. Het enige systeem dat echt snel gepatched wordt is Linux. In mijn geval Debian server en Ubuntu. Windows wacht op patch tuesday, uitzonderingen daargelaten, en van de rest (you name it) weet ik het niet.

Edit: dat bedoel ik nou, binnen 5 minuten geminned omdat mensen niet willen of kunnen lezen ..

[Reactie gewijzigd door Verwijderd op 22 juli 2024 19:32]

[Verwijderd]

Oprechte vraag: Waarom zou Apple het niet snel dichten denk je? Ze waren in het verleden ook acceptabel snel met de lockscreen fixes, enzo, toch?

(Android gebruiker)

En trouwens laten we eerlijk wezen, bedenk ik 30 seconden na het plaatsen.. Al fixed Apple het niet heel snel, verleden heeft bewezen dat 90% IOS gebruikers de fix wel meteen installeerd doormiddel van update (8.1.x). Dat scheelt al een stuk

[Reactie gewijzigd door Verwijderd op 22 juli 2024 19:32]

[Verwijderd]

Ze waren, zoals ik al schreef, met Heartbleed en Poodle ook niet snel. Bovendien, als ik nog terug kon naar iOS 7 had ik dat gedaan, maar Apple laat dat niet toe. Was dat wel gelukt dan had ik nu het probleem dat ik alleen een fix zou kunnen krijgen met een volledige update naar iOS 8, wat ik niet zou wilen omdat het mijn iPAD zowat onbruikbaar heeft gemaakt.

[Neko Koneko]

Oprechte vraag: Waarom zou Apple het niet snel dichten denk je? Ze waren in het verleden ook acceptabel snel met de lockscreen fixes, enzo, toch?

(Android gebruiker)

En trouwens laten we eerlijk wezen, bedenk ik 30 seconden na het plaatsen.. Al fixed Apple het niet heel snel, verleden heeft bewezen dat 90% IOS gebruikers de fix wel meteen installeerd doormiddel van update (8.1.x). Dat scheelt al een stuk

Als het lek in Juli al kenbaar is gemaakt en Apple heeft er nog steeds niets aan gedaan, vind ik dat niet snel...

[timonb]

Er zijn voor Apple niet veel redenen om dit heel gauw te fixen.

Zij hebben een eco systeem gecreëerd rondom hun eigen appstore. Als je netjes je apps koopt/download via hun app store, hoef je je niet druk te maken om dit soort zaken.

Immers zij controleren, tot frustratie van vele ontwikkelaars, de software die in de appstore komt te hangen. Zo voorkomen ze dat virussen en andere rommel door gepusht wordt naar hun klanten. Kies jij er voor om je device te jailbreaken, dan kies je bewust voor risico.

Voor Apple is dit juist het argument om niet te jailbreaken of iets te installeren uit onbekende bronnen. Net zoals ze aanraden om kabeltjes te kopen van een officiële Apple retailer. Immers die namaak kabels kunnen je telefoon doen ontploffen.

[Verwijderd]

True.. Het is ultieme marketing voor ze om hun eigen App store te kunnen prezen.. Je hebt een goed punt met dat ze het zelfs liever zo laten, legt ze geen windeieren

[Keypunchie]

Voor Apple is dit juist het argument om niet te jailbreaken of iets te installeren uit onbekende bronnen. Net zoals ze aanraden om kabeltjes te kopen van een officiële Apple retailer. Immers die namaak kabels kunnen je telefoon doen ontploffen.

Wat een onzin. Apple heeft geen 'eigen' malware nodig om hun eigen store te promoten. Er zijn domweg geen alternatieven.

Dit sideloaden is niet om alternatieve app stores mogelijk te maken (die mogen al niet van Apple), maar voor ontwikkelaars om hun eigen apps te testen en voor grote bedrijven om in-house apps te distribueren.

Zonder certificaat van Apple, geen installatie mogelijkheid. En mocht je een certificaat misbruiken, dan trekt Apple je certificaat in. (Zie bvb. http://www.iphonehacks.co...-signing-certificate.html)

De bug is dat blijkbaar het niet uitmaakt _welk_ enterprise certificaat je een app ondertekent, iOS slikt het en gaat de "nieuwe" versie installeren. Je hebt nog steeds een enterprise certificaat nodig.

Zelf dacht ik dat je eerst als gebruiker dat enterprise certificaat moest inlezen in een trust store, voordat je apps van een leverancier kon gebruiken, blijkbaar is het andersom, na installatie vraagt hij om 'trust' voor het signerende certifcaat. Het vervelende is dat je dan al de app hebt overschreven!

[edit]
Wat ik me wel afvraag, wat gebeurt er vervolgens als je op "check for updates" drukt in een verbinding met de app store. Kan Apple dan zien dat er een 'verkeerde' versie opstaat en bieden ze een update aan? Dat zou namelijk de toepasbaarheid/nut van de hack wel flink doen afnemen.

[Reactie gewijzigd door Keypunchie op 22 juli 2024 19:32]

[Banath]

Gnoeg sukkels die op een link tappen die ze per sms krijgen ... zelfs in 2014 nog steeds.

[Keypunchie]

In de screenshots staat "Install". Volgens mij moet je voordat je dat doet, ook nog eerst eens een corporate provisioning profile geaccepteerd hebben, anders kun je uberhaupt niet buiten de Apple Store om dingen installeren?

[nanoChip]

Dat moet na de installatie.

Hier een voorbeeld

iOS 7 users can check to see if they've been the victim of an attack by going to Settings --> General --> Profiles to see what provisioning profiles are installed. iOS 8 devices do not show installed provisioning profiles, making it more difficult to detect an attack.

[Reactie gewijzigd door nanoChip op 22 juli 2024 19:32]

[Niemand_Anders]

Uit de IOS documentatie over Bundle ID:

The product name and company identifier you enter are concatenated to create the default bundle ID using reverse domain name service (reverse DNS) notation. The bundle ID needs to be unique to your app, so it’s important to set the company identifier to a unique string as well.

Dat maakt de fix (patch) eigenlijk heel erg simpel. Aangezien het Bundle ID uniek moet zijn kan IOS gewoon weigeren om een tweede applicatie met een al bestaand Bundle ID te installeren.

Ik ben niet erg bekend met hoe IOS updates verwerkt, maar als bij een update tijdelijke een Bundle ID duplicaat aanwezig moet zijn, zou men ook de installatie source kunnen bijhouden. Dus een applicatie geinstalleerd vanuit de AppStore, kan dan alleen vanuit de AppStore geupdatet worden..

De patch zoals ik deze nu snel voorstel kan mogelijk wel voor een conflict situatie zorgen:
Stel dat jij de malware app als eerste installeerd buiten de AppStore om, laten we zeggen gmail. Dat zou dan betekenen dat je op dat moment niet de originele gmail app zou kunnen installeren omdat er al een applicatie met het 'gmail' Bundle ID aanwezig is. Dergelijke conflicten kun je half oplossen met een popup scherm welke een bevestiging vraag om de bestaande applicatie overschreven moet worden, maar gebruikers staan er niet bekend om dergelijke meldingen goed te lezen..

[pauldaytona]

lijkt erg een houtje touwtje oplossing. Als je een app voor het eerst installeert, worden er een aantal checks gedaan, neem aan dat er ook een geldig certificaat moet zijn. Die checks worden bij updaten dus niet gedaan als ik op de info afga. Oplossing, die checks ook bij updaten doen.

[Roel911]

Dit werkt voor zowel gejailbreakte als niet gejailbreakte toestellen. Oppassen met apps installeren dus. Hopelijk komt Apple snel met een fix.

[HoppyF]

Volgens het beveiligingsbedrijf kunnen gebruikers zichzelf voor Masque Attack beschermen door geen apps te installeren buiten de App Store of de eigen organisatie om. Daarnaast moeten gebruikers volgens het bedrijf nooit op 'install' klikken zodra een website een applicatie probeert te installeren. Ook moeten ze onbekende ontwikkelaars niet toestaan, aldus FireEye.

De gebruiker is dus zelf schuld aan een mogelijke besmetting door iets te doen wat niet juist is.
Waarom zou je lukraak ergens op klikken?
Een zelfde doelgroep als phishing email klikkers?

[Bloemstukje]

Snap wel waarom een patch geen prioriteit heeft in dit geval. Apps installeren doe je via de App Store, dit is de vertrouwde omgeving. Ga je buiten die grenzen is het ook eigen risico dunkt me.

[ouweklimgeit]

Yep, hetzelfde idee zoals Appaddict werkt maar dan met bekende certificaten. Maar inderdaad, de laatste zin is het belangrijkst, niet de optie inschakelen om software uit onbekende bronnen te accepteren.

[pauldaytona]

als ik het verhaal gaat het mis doordat hij een bestaande app vervangt en daarbij opeens niet de dingen gecontroleerd worden die bij een nieuwe app wel gechecked worden. Ik vind het nogal een gat als ik het zo lees. En de fix lijkt niet moeilijk. Voor tweakers is het geen probleem die zijn slim genoeg. Maar de meeste IOS gebruikers zijn niet zo handig. Want daarom hebben ze IOS.

[- peter -]

Wow, dat is wel een slechte zaak. Dat je een app kan overschrijven met een app die hetzelfde 'heet' maar niet hetzelfde certificaat heeft. Dat is wel een misser. Maar moet ook makkelijk op te lossen zijn. Gewoon dat verbieden.

Op Android is dat vrij streng, als je je signing key verliest, kan je je app nooit meer updaten. Het certificaat moet overeenkomen, anders krijg je een error.

[Reactie gewijzigd door - peter - op 22 juli 2024 19:32]