Onderzoeker: content iOS-apps makkelijk te kapen via http-redirect

Veel iOS-apps hebben last van een beveiligingsprobleem waarbij de inhoud van de apps kan worden gekaapt. Via een man in the middle-aanval kan een kwaadwillende een applicatie permanent zijn inhoud van een andere server laten ophalen.

De kwetsbaarheid is ontdekt door onderzoekers van SkyCure, die hun bevindingen later op dinsdag presenteren op de RSA-beveiligingsconferentie in Amsterdam. Het probleem zit relatief eenvoudig in elkaar. Aanvallers moeten wel het internetverkeer van gebruikers kunnen onderscheppen en manipuleren, bijvoorbeeld door een malafide wifi-hotspot op te zetten. In dat geval kan het http-verkeer van een iOS-applicatie zo worden gemanipuleerd dat een andere server zich voordoet als de server waarmee de app communiceert.

Die 'nepserver' moet vervolgens een http 301-header versturen. Die header is bedoeld om aan te geven dat een pagina op internet permanent naar een andere locatie is verplaatst. In dit geval werkt die header precies zoals bedoeld; de iOS-applicatie haalt zijn content daarna permanent op vanaf de locatie waarnaar wordt doorverwezen, ook als de man in the middle-aanval is afgelopen.

De aanval werkt vrijwel alleen met http-verkeer, maar veel iOS-applicaties gebruiken http om informatie via het json-formaat heen en weer te schuiven. Daardoor zou bijvoorbeeld de inhoud van nieuws-apps kunnen worden gewijzigd, bijvoorbeeld om malware te injecteren. Ook kunnen privégegevens worden onderschept.

Het enige wat een gebruiker kan doen als hij is getroffen, is de applicatie opnieuw installeren. Ontwikkelaars kunnen het probleem onder meer omzeilen door niet over http, maar over https te communiceren. Ook hebben de onderzoekers een work-around gemaakt. Het is niet bekend welke applicaties kwetsbaar zijn.

Reacties (49)

[Boy]

Maar ik begrijp het niet helemaal...doet het OS deze nieuwe redirect opslaan?

dus als ik op 'www.google.com' een 301 gooi met 'www.bing.com', dan zal het OS alle www.google.com calls vervangen door www.bing.com?

[kamerplant]

Ja dat klopt inderdaad.

De 301 functie is bedoeld voor het geval dat een pagina permanent is verhuist. Op deze manier kan dit effectief worden gecommuniceerd naar de browser van de eindgebruiker. Een hele mooie functie op zich, maar in dit geval uitermate onwenselijk.

[curumir]

De kwetsbaarheid, die door onzoekers van SkyCure is ontdekt, zit relatief eenvoudig in elkaar. Aanvallers moeten wel het internetverkeer van gebruikers kunnen onderscheppen en manipuleren, bijvoorbeeld door een malafide wifi-hotspot op te zetten.

Eenvoudig? Je moet een nep wifi-spot opzetten waar mensen gebruik van moeten maken. Ook moet je een server hebben waarnaar je de nieuwe link legt, deze moet al het verkeer kunnen afhandelen van alle apps die je hebt geïnfecteerd. In eerste instantie is het vooral een geweldige manier om privé data te pakken te krijgen, dat is natuurlijk altijd al een gevaar voor onbekende hotspots.
Afgezien van een privacy-risk moet je per protocol je server uitbreiden voor je kunt spoofen, elk formaat is anders.

Eventueel, afhankelijk van de implementatie van json zou je malware kunnen injecteren maar dat is een totaal andere kwetsbaarheid die niet in het artikel ter sprake komt. Sterker nog dat is een kwetsbaarheid die is te exploiten via elke fake-wife spot en gehackte website voor elke smartphone.

Alles bij elkaar is het is sowieso beter om https te gebruiken als je je app laat communiceren met een server, dat geldt net zo voor websites etc. Deze kwetsbaarheid geld met name voor de apps die dat niet doen en is een goede waarschuwing voor app-makers om er beter op te letten.
Verder is het ook een goede waarschuwing naar gebruikers om op te letten welke wifi-hotspots je gebruikt. Elke smartphone is hier kwetsbaar voor. Zo simpel is het. Zet vooral het automatisch gebruik maken van een hotspot uit.

Wat natuurlijk weer sneu is bij dit bericht is dat niemand de moeite neemt om na te gaan of dit alleen bij iOS optreedt (het is namelijk correct gedrag volgens het HTTP-protocol). Verder is de malware injection een vrolijke toevoeging van Joost zonder enige basis, net als de toevoeging dat het 'makkelijk' is.
Het bedrijf zelf heeft ook boter op hun hoofd. Uit veiligheidsoverwegingen zeggen ze niet welke apps kwetsbaar zijn - iets wat interessant zou zijn om de impact te bekijken - maar dat slaat eigenlijk nergens op. Het is namelijk helemaal niet nodig om te weten elke apps kwetsbaar zijn om hiervan gebruik te maken, het werkt voor elke app hetzelfde: nep wifi-spot met een spoofing server.
Het achterhouden is wel nodig omde impact te kunnen overdrijven.

edit: bugfixes

[Reactie gewijzigd door curumir op 29 juli 2024 05:39]

[gpgekko]

Het is niet sneu en er hoeft niet te worden nagegaan "of dit alleen bij iOS optreedt". In het bericht staat namelijk al duidelijk dat "veel apps kwetsbaar zijn voor" en niet dat "iOS kwetsbaar is voor". Het gaat hier helemaal niet om iOS, het gaat hier om de apps. En toevallig heeft deze onderzoeker ervoor gekozen om apps op het iOS platform te testen, maar dat staat er los van. Sterker nog, hij had ook een computer of laptop kunnen pakken en daarop programma's kunnen testen die communiceren met een server.

Bij een onderzoek ben je niet verplicht om alles en iedereen na te gaan. De onderzoeker vroeg zich af of iets mogelijk was, heeft zijn onderzoek op een redelijke manier afgebakend (wie zegt dat hij de tijd en resources had om alle systemen af te gaan?) en is uiteindelijk tot deze correcte resultaten gekomen. Het zou speculeren zijn als er over andere systemen gesproken werd, tenzij Tweakers eerst nog zelf uitgebreid onderzoek had gedaan.

Het probleem zit hem kennelijk in ieders interpretatie van het bericht. Het bericht gaat namelijk over ontwikkelaars die zich niet voldoende inlezen in de HTTP standaard alvorens deze te gebruiken. Iedereen die de HTTP standaard namelijk kent weet dat 301 een onderdeel is van het protocol en dat dit bijeffecten kan hebben als je niet zorgt voor extra maatregelen.

[flabber]

[...]
Eenvoudig? Je moet een nep wifi-spot opzetten waar mensen gebruik van moeten maken. Ook moet je een server hebben waarnaar je de nieuwe link legt, deze moet al het verkeer kunnen afhandelen van alle apps die je hebt geïnfecteerd.

De methode is inderdaad heel erg eenvoudig.
Genereer eenmalig een HTTP redirect en je bent klaar.

SkyCure meldt zelf expliciet het volgende :

The aforementioned attack has two limitations:
* The attacker needs to be physically near the victim for the initial poisoning (the next steps of HRH attack can be carried on the victim regardless of geolocation).

hetgeen uiteraard niet klopt op basis van de door hen zelf gegeven informatie.

Het hele verhaal van zelf een open WiFi hotspot opzetten is slechts 1 voorbeeld van een methode om die HTTP redirect bij je slachtoffers te krijgen.
Een wllekeurige andere man-in-the-middle methode is ook mogelijk om dit voor elkaar te krijgen. Of nog beter, het hacken van de doelserver zodat die zelf gedurende een paar minuten de HTTP redirect verstuurt.

Waar deze 'fout' in hun verhaal vandaan komt is mij een raadsel en zorgt ervoor dat ik aan de ernst van de door hun blootgelegde kwetsbaarheid direct al wat minder zwaar til.

[arjankoole]

Dat is eenvoudig ja, als ik in de trein of op Schiphol kijk naar de netwerken, pik ik er vaak genoeg 2 of 3 uit die nogal verdacht zijn.

[horizon1978]

Totaal geen dubbel gevoel bij het onderzoek.

Van de pagina:

'Skycure’s solution consists of a mobile app for iOS and Android devices, and a management console built to enable organizations detect, protect, and remediate security incidents. Skycure’s solution offers flexible deployment options: it can be deployed as a cloud-based solution or on-premises, and can also be integrated with an MDM solution."

Dus ze werken voor android & iOs en hebben dus geen profijt bij een of ander. Lijkt mij dat ze puur iOs onderzocht hebben in deze en niet android. Gezien het probleem zullen alle OS'en er waarschijnlijk last van hebben.

Of Android/Windows werken verplicht met https. ?

[xTmPizzaMan]

Onder Android en Windows ben je vrij om HTTP te gebruiken. Je kan het niet aan applicatie ontwikkelaars vragen om ssl certificaten te kopen om https te ondersteunen. Naja je kan altijd een self signed gebruiken...

http://developer.android....tp/client/HttpClient.html voor android en voo windows moet je denk ik de .net API hebben.

[Rembert]

Een foutieve 301 wordt gecached. Kortom, cache-poisoning. Simpelste oplossing bij vermoedelijke poisoning is dus je cache ff wissen. Laat dat nou niet mogelijk zijn op bv. iOS, tenzij je de app opnieuw installeert. Met browsers in OSX, Windows en LInux kun je wel de cache wissen maar eigenlijk vraag ik me nu wel af hoe het zit met andere desktop software die URL-access gebruiken - mogelijk cachen ze niets, maar ik heb dat nog nooit ergens gedocumenteerd gezien.

HTTPS zou een oplossing kunnen zijn maar de onderzoekers geven ook hier aan dat er een MITM mogelijk is als de gebruiker verleid kan worden om een foutief SSL certificaat te installeren - ik denk dat iedere tweaker dat wel voor elkaar weet te krijgen bij 'de gewone gebruiker'.

RFC-2616 defineert de returncodes. Als vervanger van 301 is 308 nu voorgesteld in draft - eigenlijk hetzelfde maar http-method mag dan niet veranderen. Is het een idee als er een vervanger komt met een beperkte levensduur - je voorkomt dan dat iedereen een 302 of 307 gaat gebruiken. Voor spiders wel wat overhead maar dat vind ik net even van wat minder groot belang.

De oplossing die de onderzoekers tonen aan de client-side zijn op zich ook goed maar de apps houden zich dan dus niet meer aan RFC-2616.

Meer offtopic: beetje jammer dat deze security issue gekoppeld wordt aan iOS. Ik begrijp wel dat die jongens het op iOS hebben getest maar ze hadden het best algemener mogen melden, of op zijn minst even een niet-iOS apparaat erbij gepakt kunnen hebben. Als Android of Windows Mobile er geen last van zouden hebben, dan kun je pas met recht iOS noemen in de titel, maar nu is het erg pretentieus. Jammer. Was niet nodig. Ook jammer dat Tweakers dit klakkeloos overneemt. Gelukkig zijn er veel tweakers hier die wel kritisch zijn en het doorzien.

[RutgerDB]

Lijkt vrij eenvoudig op te lossen door 301 redirects niet te laten volgen maar gewijzigde URL's gewoon via een app update uit de appstore te pushen?

[Verwijderd]

De enige echte oplossing is om https te gebruiken en alleen vertrouwde certificaten te accepteren. 301 redirects niet laten volgen kan een tijdelijk helpende maatregel zijn (want dat is toch meer bedoeld voor webspiders imho dan voor webapps), echter, dan bestaat er nog zoiets als een 302 redirect, en is alleen al het feit dat http niet versleuteld is voldoende om te stellen dat de content nog steeds te kapen is.

Alles hangt echter ook af van wat die content nu eigenlijk is. Als het nieuws is zoals tweakers.net, is het de vraag hoe erg het is als iemand de content kan kapen en ander nieuws kan sturen. Dat is grappig, misschien vervelend, maar niet heel schadelijk.

Content van whatapp zie ik echter liever niet via een andere server gaan. Hoewel whatsapp de data ook al overal voor gebruikt.

Anders wordt het bij content m.b.t. internet bankieren. Gelukkig gebruiken die wel https.

[ATS]

Ik zie geen enkele reden waarop apps op Android of windows phone niet dezelfde kwetsbaarheid zouden hebben. Wat is er hier nu iOS specifiek aan?

Edit: wel een mooie vector om spam te verspreiden natuurlijk! Je zet ergens op een drukke plek een open wifi netwerk op dat gewoon werkt, en injecteert voor kwetsbare apps een dergelijke redirect. Vervolgens injecteer je spam in de nieuwsstromen... Hoezo email? Direct in het overzicht van je nu.nl, nos of RTL app!

[Reactie gewijzigd door ATS op 29 juli 2024 05:39]

[MC Taz Man]

Het iOS specifieke komt door het onderzoek, welke zich enkel op iOS heeft gericht. Hierdoor kan er dus geen enkele conclusie getrokken worden over andere platformen.

[Pim_t]

Het kan te maken hebben met de manier waarop standaard applicaties voor het betreffende platform worden gemaakt. Mogelijk dat er meer iOS apps zijn die op deze manier communiceren?
Mogelijk dat het dus met de toolbox te maken heeft?

[gpgekko]

Er staat nergens dat dit iOS specifiek is. Echter heeft deze onderzoeker specifiek een onderzoek gedaan naar iOS apps en is daarbij op deze kwetsbaarheid gestuit. Het zou dus raar zijn als er vervolgens conclusies worden getrokken over andere apps of programma's (want in theorie kan elk programma wat via HTTP een connectie legt met een server hier vatbaar voor zijn, als de ontwikkelaar geen tijd heeft genomen om hierbij stil te staan).

[Grrrrrene]

Ik denk niet dat een onderzoeker bezig is met pogingen om flamewars te starten maar je reactie geeft al aan dat er tegenwoordig geen iOS/Android-nieuws meer kan worden gepost zonder dat zo'n flamewar uitbreekt. Hier zal voor iOS gekozen zijn omdat de iPhone een van de meest gebruikte smartphones is met een van de grootste app markets. Of heel simpel omdat hij een iPhone had en geen Android- of Windows-telefoon?

Het had T.net alleen gesierd als er een kritische noot bij stond dat de app eigenlijk gewoon doet waar HTTP 301 voor bedoeld is: netjes naar de nieuwe URL gaan omdat de oude aangeeft permanent verhuisd te zijn en dat het dus aannemelijk is dat deze methode ook met Android en Windows Phone 8 werkt. Wat dat betreft kun je amper spreken van een bug, het is vooral user error door met een onvertrouwde hotspot te verbinden. De app-bouwer daarentegen zou via HTTPS moeten communiceren.

@Pegasus: ik doelde eigenlijk meer op het feit dat het ook met andere mobiele OS'en kan. Het artikel spreekt diverse keren van "iOS apps zijn kwetsbaar" en "daardoor gaat een iOS app naar...", terwijl dat los lijkt te staan van iOS. De werkelijke kwetsbaarheid zit in de legitieme werking van HTTP 301 icm user error. Ergens gedurende de zin heb ik mijn doel uit het oog verloren blijkbaar Ik heb de zin aangepast.

[Reactie gewijzigd door Grrrrrene op 29 juli 2024 05:39]

[pegagus]

Volgens mij staat die alles al in het artikel en ik zie niet dat het artikel is bijgewerkt.

Voor de rest is het een beetje een standaard verhaal. Leidt het http-verkeer over je eigen server en je kunt van alles volgen wat voorbij komt. Malware installeren lijkt me nog weer een ander verhaal. Ik mag aannemen dat iOS daar toch wel enige beveiliging tegen heeft?

[biglia]

iOS houdt de 301 redirects bij. Misschien dat Android en Windows Phone dit ook doet, maar als desktopgebruiker vind ik dit zeer vreemd. Apple heeft dit kleine detail toegevoegd, maar het was beter om dit niet te doen.

[arjankoole]

iOS houdt de 301 redirects bij. Misschien dat Android en Windows Phone dit ook doet, maar als desktopgebruiker vind ik dit zeer vreemd. Apple heeft dit kleine detail toegevoegd, maar het was beter om dit niet te doen.

Het is conform de HTTP protocol specificatie. Die niet volgen is nog veel slechter dan hem wel volgen. Want dan krijg je weer dat iedereen z'n eigen protocollen gaat bouwen en niets en niemand meer compatible is met elkaar. Iets wat we nou eindelijk een beetje aan het voorkomen waren.

[nightwing]

Wat ik me meteen afvraag is of dit ook het geval is voor Android en Windows Phone applicaties ?
Het onderzoek heeft zich volledig op iOS gericht maar ik denk dat dit meer te maken heeft hoe een ontwikkelaar er mee om gaat dan hoe iOS er mee om gaat.

[Rafe]

Er is geen reden om aan te nemen dat Android of Windows Phone-apps automatisch niet kwetsbaar zijn voor deze aanval. Tenzij jij als app-programmeur hier rekening mee houdt, zal in principe elke HTTP-client volgens de standaard braaf de redirect volgen.

[Snake]

Er is een verschil tussen deze te volgen en de volgende keer (als de MITM er niet meer is) gewoon de ge-redirecte link klakkeloos te volgen he!

[Blaise]

Dat is ook onderdeel van de standaard, 301 redirects zijn permanent en kunnen+mogen worden bewaard in cache. (tenzij andere headers anders aangeven)

[Reactie gewijzigd door Blaise op 29 juli 2024 05:39]

[Rafe]

Klopt. Android heeft de 'mazzel' in deze dat er pas sinds 4.0 een cachingmechanisme in het platform zit, en die moet je dus zelf expliciet implementeren als developer. Bij iOS staat deze standaard aan.

Als je niet meer dan het minimale werk doet om URL requests te maken volgt je Android app dankzij geluk (ipv wijsheid) niet meer de gespoofte URLs nadat de aanval is afgelopen.

[Reactie gewijzigd door Rafe op 29 juli 2024 05:39]

[The - DDD]

Ik dacht altijd dat caching standaard uit stond voor een eigen app.

Nog is de docs ingedoken. Default gebeurt er inderdaad iets. Maar het gedrag lijkt wel erg random...

[Reactie gewijzigd door The - DDD op 29 juli 2024 05:39]

[Marcel]

Waarom zou men https moeten gaan gebruiken ipv http (afgezien van obvious redenen)? Komen dan ineens geen mitm attacks meer voor? 301 responses worden ook via https nog steeds gevolgd, alleen zit je dan met certificaten die vertrouwd moeten zijn.
Met andere woorden: Het zou mooi zijn als het artikel iets meer verdieping zou kennen en het bovenstaande zou uitleggen ipv van alleen maar melden dat men gebruik van https zou moeten maken.

[flabber]

Je hebt helemaal gelijk met je vragen.
Alleen ligt dat niet zozeer aan het artikel van Tweakers, maar aan het feit dat SkyCure's onderzoek en persbericht zelf al niet bijzonder veel diepgang heeft en dit soort vragen niet (goed) beantwoordt.

[Marcel]

Klopt, alleen zou het toch mooi zijn als Tweakers wel die diepgang biedt ipv een artikel samen te vatten en te vertalen. Daar zit normaal, wat mij betreft, de meerwaarde van Tweakers.

[Snake]

Het feit dat URL x is geredirect wordt dus ergens in iOS per app bijgehouden?

[Rafe]

Jep, zie NSURLCache. De workaround (zie bronartikel) is ook om de cache te subclassen en daarin alle HTTP 301-redirects niet op te slaan.

[RutgerDB]

@snake, wat ik ervan weet is dat het een perm redirect is. De app gaat dus voortaan naar de nieuwe URL en helemaal nooit meer naar de oude. Daarom duurt de aanval voort als de man in the middle al weg is.