Onderzoekers ontwikkelen iOS-keylogger

Beveiligingsonderzoekers hebben een methode ontwikkeld die hen in staat stelt via een app alle iOS-handelingen van een gebruiker te registreren en naar een server te sturen. De app werkt ook op iPhones zonder jailbreak, omdat de onderzoekers de App Store kunnen omzeilen.

Medewerkers van het beveiligingsbedrijf FireEye tonen op hun blog een proof-of-concept-app die ze buiten de App Store om kunnen distribueren. De app draait op de achtergrond en is in staat informatie over alle handelingen van de gebruiker op te slaan, zo worden ook aanrakingen van het touchscreen opgeslagen, inclusief schermcoördinaten. De app is getest op iOS 7.0.4, maar werkt volgens de onderzoekers ook op versies 7.0.5, 7.0.6 en 6.1.x.

Gebruikers kunnen in de instellingen aangeven welke apps op de achtergrond mogen blijven draaien. Apps kunnen deze instelling echter omzeilen voor specifieke doeleinden. Als een app bijvoorbeeld aangeeft dat er muziek moet blijven spelen, krijgt de app automatisch toestemming om in de achtergrond te draaien.

Vanwege het strenge review-proces van Apple zou een dergelijke app echter nooit in de App Store worden toegelaten; de onderzoekers van FireEye zouden een manier hebben gevonden om de App Store te omzeilen. Door middel van phishing zouden ze een gebruiker kunnen overhalen om de app te installeren. Het kan ook via een kwetsbaarheid in een ander app. De onderzoekers hebben nog geen verdere informatie bekendgemaakt over de gebruikte methode. Ze zeggen met Apple samen te werken om het probleem op te lossen.

Reacties (78)

[TMC]

De onderzoekers van FireEye zouden echter een manier hebben gevonden om de App Store te omzeilen. Door middel van phishing zouden ze een gebruiker kunnen overhalen om de app te installeren, ook kan het via een kwetsbaarheid in een ander app.

Kan ik hieruit concluderen dat er een nieuwe exploit is gevonden die de jailbreak scene niet heeft gevonden? Anders heb ik geen idee hoe het mogelijk is een app te installeren die niet in de AppStore staat.

[arjankoole]

Kan ik hieruit concluderen dat er een nieuwe exploit is gevonden die de jailbreak scene niet heeft gevonden? Anders heb ik geen idee hoe het mogelijk is een app te installeren die niet in de AppStore staat.

Developers met een developer account en bedrijven met een enterprise account bij Apple hebben al sinds het eerste begin hun eigen applicaties kunnen installeren. Daarnaast kan iedere developer zo'n 150 iOS devices aanmelden in zijn account, en daaraan apps distribueren. Test Flight werkte ook op een soortgelijke manier.

Legio mogelijkheden dus. Deze applicatie is een proof of concept, en zal dus niet verstopt worden in een App in de appstore, en de bedoeling is ook niet om op afstand een iOS device te infecteren. Het dient alleen als bewijs dat een background app systeem acties en touchscreen activiteit kan onderscheppen.

[Reactie gewijzigd door arjankoole op 25 juli 2024 08:12]

[Anoniem: 75167]

Allereerst een misvatting uit de wereld helpen. Dat een App buiten de AppStore om gedistribueerd kan worden is gewoon bestaande functionaliteit een feature (niet een bug). Zo kan je corporate Apps buiten de AppStore distribueren. Als iOS developer heb je een drietal manieren van distributie:
- Development (je compileert de App en zet hem op je telefoon of op die van iemand anders; als Developer kan je (jaarlijks!) 100 device ID's in je developer account registreren)
- Ad Hoc (je hebt een productie app die je distribueert buiten de App Store om; bijvoorbeeld via TestFlight)
- Productie/Release (je distribueert de App via de AppStore)

Daar is helemaal niets bijzonders mee, en je kan inderdaad via Ad Hoc distributie via een e-mail iemand een App laten installeren (zie bijvoorbeeld het recent door Apple gekochte TestFlight). Daar moet je echter wel eerst een certificate voor installeren op je iDevice (ik heb toevallig gisteren nog dit hele proces doorlopen).

Waar het het hier om gaat is in feite multitasking; dat een malafide App in de achtergrond kan blijven draaien zelfs als hij zich niet als zodanig bij het OS heeft geregistreerd. In iOS vraagt een app toestemming om in de background te draaien. Als een app zich niet op de juiste manier heeft geregistreerd dan krijgt hij als hij is ge-background ook geen clock cycles (waardoor het loggen van touch screen events in andere apps onmogelijk is), en deze proof of concept bypassed dat. Dat is het enige…

M.i. niet eens een gigantische bug en eentje die waarschijnlijk vrij snel gedicht kan worden.

[Reactie gewijzigd door Anoniem: 75167 op 25 juli 2024 08:12]

[Vincentio]

Via een Enterprise licentie kan je gewoon een App distribueren buiten de App Store om. Deze kan je dan ook gewoon door een gebruiker zonder jailbreak laten installeren via een website.
Dus enige wat je hoeft te doen is de gebruiker trigger de installatie te starten.

[ronaldmathies]

Krijg je als gebruiker alleen wel de melding of je een susteem profile wilt installeren en een certificaat wilt accepteren. Dus geheel onopvallent is het niet.

Maarja, op deze manier kan je alles op een iOS systeem geinstalleerd krijgen. Zo werkt Testflight bijvoorbeeld ook om beta's te testen

[t1mmy]

Bij een enterprise build krijg je dus geen popup van profielen, je kunt met een enterprise profiel echt een app signeer alsof hij in de App Store staat, voor een enterprise profiel hoef je dus ook niet alle losse devices voor het profiel te registreren. Mede hierom is het ook een hele opgave om een enterprise profiel te krijgen.

Testflight werkt (volgens mij) alleen met "normale" profielen, en niet met enterprise accounts

Bron: Ik werk elke dag met Apple's scheit systeem.

LOL 6 ongewenst omdat ik mijn ervaring en kennis deel? What the fuck Tweakers. Overigens ook bedankt voor het uitleggen waar ik deze beoordeling aan verdient heb.

[Reactie gewijzigd door t1mmy op 25 juli 2024 08:12]

[Glashelder]

Volgens mij ben je dat enterprise profiel ook zo kwijt als je malware gaat produceren

Verder is elk systeem wel voor een deel gebaseerd op vertrouwen. Het idee (met deze profielen die weer certificaatgebonden zijn) is dat je dat vertrouwen weer relatief eenvoudig kunt opzeggen.

[Alphyraz]

Dat deze app op de achtergrond draait en niet door Apple gesigneerd is, wil niet zeggen dat deze ook onder root draait - wat vereist is voor een jailbreak.

[blorf]

Het ding lijkt in staat te zijn gebruikersinput te registreren/opslaan en te verzenden over internet. Als een non-root gebruiker van een systeem dat gewoon kan, waarvoor zou je dan bijv. het root-account nog nodig hebben? Voor dat keyloggen heb je info nodig van het OS die beschermd zou moeten Dit zou heel iOS dubieus maken als je het mij vraagt. Tenminste, als het verhaal klopt waar ik aan twijfel omdat de activiteiten van de betreffende app los staan van het weten te omzeilen van het appstore systeem. Er worden twee zaken op een onduidelijk manier bij elkaar gehaald. Zo lijkt het op slechts interessant geklets.

[Shunt9]

Een gokje van mij hoe dit wellicht mogelijk is:

Een mogelijke manier om apps te installeren buiten de store om is het gebruik van ad-hoc provisioning profiles/certificates. Deze heb je ook op corporate niveau en stellen je in staat om apps te on-the-fly te signeren en de installeren. Er zijn zelfs plugins om dit in je build-systeem hangen (jenkins bijvoorbeeld).

Apple weert deels apps die wellicht exploits bevatten door ze gewoon nooit toe te laten. Denk aan bijvoorbeeld apps die met een truc (hack, memory leak, etc) alsnog root kunnen krijgen. Zo'n exploit misbruiken om mondiaal jailbreak voor elkaar krijgen middels ad-hoc builds gaat niet lukken; dan trekt apple gewoon het account in (met de bijbehorende certificaten) waardoor vanaf dat moment vleugellam bent.
Echter zou je een vergelijkbare opstelling wel kunnen gebruiken voor een keylogger, want die moet juist onder de radar blijven. In tegenstellen tot de heisa en media-aandacht die gepaard gaat met een nieuwe jailbreak.

[Reactie gewijzigd door Shunt9 op 25 juli 2024 08:12]

[Cerberus_tm]

Ah! Het interessantste punt is inderdaad hoe ze die applicatie überhaupt geïnstalleerd krijgen buiten de vruchtenwinkel om, en jij beschrijft precies een mogelijke manier waarop dat kan. Is deze manier eigenlijk algemeen bekend? Je zou denken van wel?

[Shunt9]

Jazeker, het is iets wat vrijwel elke developer die software voor iOS schrijft wel bekend mee is. Een enterprise account krijgen is niet een kwestie van een vinkje zetten maar heel lastig is het proces ook niet.
Het systeem is bedoeld om in-house apps te ontwikkelen. Denk bijvoorbeeld aan een autofabrikant die een eigen ipad-app maakt om systemen in de gaten te houden.
Ik werk zelf bij een softwarehuis met circa 400 medewerkers. We hebben ook zo'n account en het was niet lastig om aan te komen. Een lege bv opzetten om dit te regelen en daar vanuit de exploit faciliteren lijkt me dus een reële mogelijkheid

[houtig]

De app draait op de achtergrond. Kan best zijn dat hij een layer over het scherm legt en geen gegevens van het besturingssysteem. Je weet het niet omdat de werken van de app niet wordt uitgelegd, alleen dat hij kan loggen.

[Intrepidity]

Daarmee capture je de volume buttons en de home knop niet Al valt dat wellicht ook op andere manieren te achterhalen.

[Intrepidity]

Klopt, maar in het screenshot zie je dat dat wel gecaptured wordt. Wat mij doet geloven dat het niet gebruik maakt van een overlay om aanrakingen te registreren.

[NSG]

Dat denk ik niet, hoogstwaarschijnlijk gaat dit op dezelfde manier als de emulator "GBA4iOS", je installeert een certificaat en de app wordt vervolgens naar je toestel gepusht.

[kdhoe]

Dat klopt. Apple kan deze certificaten wel van op afstand revoken, dan werkt de app niet meer.

[laurens0619]

Precies. Het hele nieuwsartikel is eigenlijk irrelevant mbt de keylogger. Het gaat erom hoe je malware in de app store krijgt. Jammer dat ze daar niet op in gaan

[Carbon]

Precies. Het hele nieuwsartikel is eigenlijk irrelevant mbt de keylogger. Het gaat erom hoe je malware in de app store krijgt. Jammer dat ze daar niet op in gaan

Deze keylogger (of andere mallware) zou je kunnen verbergen in een andere app.
Om ontdekking door Apple te vorkomen maak je de keylogger pas na b.v. een maand actief.

Het echte probleem is dat een app in de achtergrond key- en touchevents kan afvangen!

[laurens0619]

Zo simpel is het niet om je keylogger te verbergen in een app gelukkig
De code staat er dan nog steeds in (met de private api calls) en je app zal niet geaccepteerd worden.

Een app kan nog veel andere nare dingen dan key en touche events afvangen. Daarom is het code review proces zo belangrijk in het model van Apple.

[Carbon]

De code staat er dan nog steeds in (met de private api calls) en je app zal niet geaccepteerd worden.

private API calls kun je (conditioneel) verbergen met NSSelectorFromString

[laurens0619]

Ik denk dat Apple ook wel op zulke methodes scant hoor (mag het hopen!)
Malware verbergen gaat wel iets verder. Er zijn wel een aantal onderzoekers geweest die het vorig gelukt is : Jekyll on iOS: When Benign Apps Become Evil

[Carbon]

Ik denk dat Apple ook wel op zulke methodes scant hoor (mag het hopen!)

De NSSelectorFromString methode is niet te detecteren.

[Reactie gewijzigd door Carbon op 25 juli 2024 08:12]

[Zyphrax]

Wat een onzin, natuurlijk wel. Apple hangt een debugger aan je app en ziet dat je bepaalde calls doet. Of dat nou direct een message is of een message via een string.

Dan kun je zeggen: ja maar mijn app roept dat alleen aan bij blauw maanlicht. Moet je zien hoe snel Apple dan je app uit de App Store haalt en je een ban krijgt.

[Carbon]

Wat een onzin, natuurlijk wel. Apple hangt een debugger aan je app en ziet dat je bepaalde calls doet.

Niet als je de calls doet na toelating van de app.

Dan kun je zeggen: ja maar mijn app roept dat alleen aan bij blauw maanlicht. Moet je zien hoe snel Apple dan je app uit de App Store haalt en je een ban krijgt.

De truuk is om zoveel mogelijk apparaten te voorzien van de malware alvorens je slag te slaan. Dat Apple de app na ontdekking zal verwijderen is logisch maar voor de eventuele slachtoffers is het te laat.

[SgtElPotato]

En begrijpelijk, want deze exploits kunnen ze dan eventueel later gebruiken voor een Jailbrek of andere dingen.

[TMC]

Uiteraard. Maar in het artikel wordt gesproken over 'een probleem'. Het is pas een probleem als gebruikers hier mogelijk mee geconfronteerd worden. Zolang het niet duidelijk is of en hoe gebruikers hiermee geconfronteerd kunnen worden, kan je ook niet zeggen of er echt een probleem is.

[Anoniem: 118226]

Het artikel gaat niet over slinkse methoden om een app in de store te krijgen, maar om op slinkse manier een app op je device te krijgen, dmv side loading.

[laurens0619]

iOS/Android bestaat uit public en uit private API's. In de regel worden public api calls toegestaan en private niet.

Een private api kan vaak wel gewoon aanspreken. Een paar voorbeelden:
Android 2.3: Je kon de private API aanspreken om bv flight modus vanuit code aan/uit te zetten. Niet gedocumenteerd, wel bruikbaak maar ook exploit?

iOS: Je kan via de private api bv de UUID ophalen van het toestel. Enige tijd werd dit goedgekeurd door Apple maar tegenwoordig kom je er niet meer de app store mee in. Het uitlezen van het touchscreen is een voorbeeld hiervan.

Android en Apple scannen voor het plaatsen in de playstore op het gebruik van private api calls. Een manier om hier voorbij te komen is om functionaliteit in je app te maken die code sideload na de installatie. Ook het bestaan van deze functionaliteit wordt gescand voordat de app geplaatst wordt.

Een voorbeeld van (tot iOS 6) private/public apis kan je hier vinden

[Soldaatje]

Waarom geen geldig certificaat of gewoon zonder SSL gebruiken?
Het lijkt me niet relevant voor de hack, tenzij er een bug zit in de manier waarop iOS met niet geldige certificaten omgaat?

[arjankoole]

Waarom geen geldig certificaat of gewoon zonder SSL gebruiken?
Het lijkt me niet relevant voor de hack, tenzij er een bug zit in de manier waarop iOS met niet geldige certificaten omgaat?

ik denk dat je hier SSL certificaten (voor beveiligde verbindingen) en code signing certificaten (die developers gebruiken om hun applicatie te ondertekenen, en apple om apps goed te keuren voor distributie in de appstore) door elkaar haalt.

[Soldaatje]

Nee, ik bedoel het plaatje met https met een streep erdoorheen.

[Anoniem: 567346]

Een keylogger die niet te installeren is zonder user medewerking (certificaat installeren), die door apple zeer eenvoudig te blokkeren is (certificaat intrekken) is op tweakers nieuws. Dit tegenover de niet meer bij te houden hoeveelheid malware in android.

Ik vind dat tweakers zijn verantwoordelijkheid moet nemen in dit soort scheve berichtgeving. Dit kan voor de niet wetende gebruiker een compleet scheef beeld opleveren.

[Vincentio]

Dat komt omdat een veronderstelling is bij iOS dat het allemaal erg secure is, terwijl meeste van Android weten dat het niet zo is.
Daarentegen komt nu aan het licht dat SSL bij Apple helemaal niet naar behoren werkt en ook keylogging dus gewoon mogelijk is.

[Anoniem: 567346]

Als op tweakers constant berichten komen dat IOS niet secure is (ondanks dat het veel veiliger is dan Android), maar geen berichten over de structurele problemen binnen Android. Dan ontstaat er een scheef beeld, dan is er geen sprake van ' terwijl meeste van Android weten dat het niet zo is.'.

[Anoniem: 286841]

Is het zelfde als zeggen dat windows niet veilig is, omdat als je iets zelf installeert waarvan je niet weet wat het is, je dan geïnfecteerd raakt...

[OkselFris]

Op zich is het niet erg dat er aandacht aan wordt besteed, alleen slaat het af en toe wat door.
Op Appleinsiders staat daarover recentelijk wel een leuk artikel.
Men duikt vol op Apple bij het minste of geringste (al is de SSL bug natuurlijk erg serieus) maar men wil geen druppel inkt meer besteden aan bugs en security issues op bijvoorbeeld Android, waar de versnippering en matige update strategy security lekken veel minder snel worden gedicht.

Maar ach af en toe mag er best wel aandacht voor zijn.
Scheef beeld betwijfel ik, over het algemeen heerst toch wel het beeld dat op IOS de zaken toch wat strikter geregeld zijn met alle security voordelen van dien.

[Reactie gewijzigd door OkselFris op 25 juli 2024 08:12]

[CharlesND]

Ik heb een hekel aan al het over en weer ophemelen en afkraken van de verschillende fabrikanten en besturingssystemen maar als Apple-gebruiker maak ik graag een grote uitzondering als het veiligheidszaken betreft. Dan kunnen de Android- en Windows fanaten wat mij betreft niet hard genoeg aan de bel trekken omdat het mijn computer of iPad een stuk veiliger maakt.

Niet omdat de beveiliging zelf dan direct beter wordt, maar het maken van een exploit is echt veel meer werk dan het vinden van een kwetsbaarheid. Een exploit maken is geen vrijblijvende zaak, als crimineel moet je daar een hoop geld in steken -een beetje OSX exploit schijnt tienduizenden euro's te kosten-, je moet het organiseren, een netwerk opzetten en je bent wel strafbaar bezig dus er zitten risico's aan.

Als je dan al die investeringen hebt gedaan en je je exploit listig op het net gooit en een kwartier later staat die exploit uitgebreid met hoofdletters en uitroeptekens en LOL op alle Android-sites dan lijkt mij dat een niet zo best business-model...

Dus Android- en Windowsfans: ik lees over veel graag goed beargumenteerde commentaar op Apple of waardering voor het eigen merk maar als het veiligheid betreft mag het van mij met een gestrekt been erin! Ik als Apple-gebruiker ben daar tenminste zeer erkentelijk voor.

[blouweKip]

En dat terwijl praktisch alle android "malware" door gebruikers zelf moet worden geinstalleerd buiten de markt om (goh, dat klinkt precies als wat men hier op iOS gedaan heeft).

[[Remmes]]

Nee, Er zijn vele Android apps in de market geweest die malware bevatten.

[WallieBTY]

Mogelijk ben ik tegen deze exploit aangelopen. Mijn baas kwam 2 weken geleden aan met dat allemaal in app purchases had gedaan. Zijn zoontje had de avond ervoor een melding gekregen op de iPad om het AppleID wachtwoord in te vullen en dat ook braaf gedaan.

Nu kreeg hij verschillende facturen op vanuit zijn AppleID over in app purchases van 2 verschillende games, die gewoon netjes in de Appstore staan. De games hadden ze al verwijderd die zelfde avond nog.

Uiteindelijk de aankopen kunnen stoppen door zijn AppleID wachtwoord te resetten. Het uitzetten van in app purchases in settings had die avond er voor niet geholpen.

Uiteindelijk €1500 aan kosten gehad. Deze krijgt hij overigens wel als 'coulance' terug van Apple.

[ronaldmathies]

Klinkt meer als dat zoon lief de app store had gevonden en heeft gebruikt. Dan had hij namelijk ook een extre systeem profiel moeten hebben ( buiten de app store gaat via een enterprise licentie en daarvoor krijg je een profiel ). Of hij had hem gejailbreaked en had iets geinstalleerd wat niet handig was.

Profile moet je nogsteeds terug kunnen vinden via settings -> general -> profiles.

[77slevin]

Neen, je bent niet tegen deze exploit aangelopen. Het artikel gaat over een proof of concept en is niet verspreid onder gebruikers.

[winwiz]

Artikel lezen? Het hoeft helemaal niet via de appstore...

Door middel van phishing zouden ze een gebruiker kunnen overhalen om de app te installeren, ook kan het via een kwetsbaarheid in een ander app

[laurens0619]

Ik lees hier niet in dat het niet via de appstore hoeft te gaan

[Voutloos]

Toch staat er herhaaldelijk in het artikel dat de App Store omzeild wordt.

[laurens0619]

Waarschijnlijk bedoelen ze dan een manier als TestFlight inderdaad. Certificaat installeren, met een dev key een app signed maken voor het toestel (voor test doeleinden) en deze op het apparaat installeren.

[Zyphrax]

Spannend allemaal hoor, tenzij je zelf ook iOS apps maakt...

Apple staat het toe dat apps die aangeven dat ze op de achtergrond moeten blijven draaien dit (beperkt) kunnen doen. Er wordt tijdens het reviewen wel gecheckt dat dit daadwerkelijk met een correct doel gedaan wordt.

Ik ga er sterk vanuit dat voor deze mate van logging een private API gebruikt wordt. Tot iOS 7 was er hier een bekend en simpel te gebruiken recording (private) API voor. Apple heeft dit in iOS 7 aangepast, ik vermoed dat dit bedrijf de nieuwe API kent of zelf op basis van andere APIs wat geschreven heeft.

Met private API kom je bijna niet in de App Store, als je er wel in komt en het lekt uit dan ligt je app er ook zo weer uit en maak je het echt bont dan heffen ze je developer account op.

Dan heb je nog Ad Hoc distributie (denk TestFlight). Hiervoor moet een provisioning profile op het iOS device gezet worden (dit valt de gebruiker wel op). En er kan maar naar 100 devices gedeployed worden, die van te voren in de Apple Developer Portal geregistreerd moeten worden (een device registratie staat meteen voor een jaar vast).

Als laatst hebben we nog enterprise distributie. Hiervoor moet je behoorlijk wat informatie bij Apple aanleveren over je bedrijf. Vervolgens lijkt het erg op de distributie die ik hierboven beschrijf, echter zonder device registratie. Dit type account is gericht op bedrijven die een app intern aan veel medewerkers wil kunnen deployen. Apple houdt dit soort accounts goed in de gaten. Bij onjuist gebruik trekken ze de stekker er uit (voor meer info, lees over de MacBuildServer service).

Kortom het loopt allemaal nog zo'n vaart niet. Ik raad je zeker niet aan om het te maken, maar een Windows key logger lijkt me simpeler.

Het valt mij wel op dat Tweakers erg graag iOS nieuws opblaast. Hoe zit het met Android?

[Reactie gewijzigd door Zyphrax op 25 juli 2024 08:12]

[Anoniem: 9278]

Off topic:
Als we het nu dan toch over security risks hebben. Ik hoor hier nooit iemand over het feit dat minder dan 5% van de Android toestellen de laatste versie draait. Met 80% marktaandeel lijkt me dat toch wel een veel groter probleem dan een key logger "bug" die nog niet in het wild is gesignaleerd.

On topic:
Wellicht is het goed als ze hier op Tweakers gewoon een apart kopje in het menu maken genaamd: "Mobile Bugs" en daar ALLE bugs die in iOS, Android, BB, Windows Phone etc gevonden worden. Het lijkt nu op makkelijk willen scoren met bezoekers voor de adverteerders

[Dr.Root]

OS 7 geeft de mgoelijkheid voor een background app refresh. Wat niet noodzakelijke apps uitschakeld. Het kan dit omzeilen: Voorbeeld:
Een app die muziek afspeelt op de achtergrond kan draaien zonder de ''Back ground App Refresh'' switch aan te hebben. Dus een frauduleuze app kan zichzelf dan ook vermommen als een muziek app en vervolgens jouw gehele handelingen op de achtergrond monitoren.

Technisch gezien, is het een stuk lastiger, Fire Eye zal hier al enige tijd mee bezig zijn geweest of krijgen zelfs hulp vanuit Apple Inside. Dit soort shit vindt je niet zomaar.

[dcl!]

"Door middel van phishing zouden ze een gebruiker kunnen overhalen om de app te installeren."

De gebruiker is dus nog steeds (als hij/zij oplet) de baas.
Ik installeer nooit apps direct, doe het nog altijd via iTunes zodat ik gelijk een back up van de app heb, dus ik maak me (nog) geen zorgen.