In begrijpelijke taal: Keychain en Sandbox OS X en iOS op 4 manieren gekraakt

Raymon op 17 juni 2015 22 reacties Laatste door andrevdvries

Onderzoekers van de universiteiten van Indiana, Peking en Georgia hebben de beveiliging van iOS en OS X in een nieuw paper onder de loep genomen en zijn daarbij op maar liefst vier nieuwe, serieuze problemen in de systemen van Apple gestuit.

De onderzoekers leggen bloot hoe een kwaadaardige app gegevens uit de Keychain en Sandboxes van iOS en OS X kan stelen. Wij hebben de hele paper gelezen en leggen de problemen in begrijpelijke taal uit.

Kwaadaardige app nodig

Om de aanvallen uit te voeren is een kwaadaardige app nodig. Deze kan ook uit de App Store komen, want de onderzoekers zeggen dat de kwaadaardige apps door de App Store-controle kwamen.

1. Sleutelhanger OS X

In de sleutelhanger (Keychain) van OS X is het mogelijk om wachtwoorden voor apps en diensten op te slaan. Welke app tot welke gegevens toegang heeft, wordt door middel van een Acces Control List (ACL) geregeld. Meerdere apps kunnen toegang tot logingegevens informatie hebben, zo hoef je bij een update voor de Twitter-app niet opnieuw in te loggen.

De namen van apps in de sleutelhanger zijn voorspelbaar. Zo heet Twitter com.twitter.twitter-mac. Wat de malware doet is deze naam alvast claimen en een willekeurig wachtwoord opslaan. Als je de Twitter-app later installeert, krijgt ook de vraag of je wachtwoord bewaard moet worden. Als je dit doet, wordt het nep-wachtwoord overschreven door de echte Twitter-app, maar kan de malware er ook nog steeds bij.

Slordig hierbij is dat alle apps kunnen kijken welke velden al in gebruik zijn en data uit de Keychain kunnen verwijderen. Een kwaadaardige app kan zo je Keychain uitlezen, de velden verwijderen, zichzelf opnieuw met die velden registeren. Wanneer je een app opent wordt je gevraagd je wachtwoord opnieuw in te voeren en is het bing voor de malware.

Kwaadwillenden kunnen op deze manier je iCloud-login onderscheppen en alle accounts die in Google Chrome opgeslagen zijn uitlezen.

2. Sandbox Cracking (OS X)

Apps draaien op OS X van elkaar gescheiden in een sandbox. Dat wil zeggen dat ze allemaal hun eigen stukje geheugen hebben en ze niet bij elkaar kunnen spieken. Zo kan Google Chrome niet bij je foto’s in de Foto’s-app. Dit blijkt toch niet helemaal veilig.

OS X-apps kunnen een helper-app bijleveren, dat is een mini-app die op de achtergrond werk doet zonder dat de hoofd-app open staat. Handig om gegevens op de achtergrond met de cloud te synchroniseren. Deze helper-apps krijgen ook toegang tot de sandbox van de hoofd-app nodig om hun werk te doen.

De onderzoekers hebben gemerkt dat iedere app zich als helper-app voor een andere app voor kan doen en dat OS X dit niet checkt, maar de app direct toegang tot de Sandbox van de andere app geeft. Een app kan zo beweren een helper te zijn voor Evernote en alle gegevens binnenhalen.

3. Cross-app communicatie I

Websockets worden veel door bijvoorbeeld browser plug-ins gebruikt. Een plugin kan een klein serverje opzetten waarmee het met de hoofd-app kan praten. Zo geeft de browser plug-in van 1Password bijvoorbeeld wachtwoorden die onthouden moeten worden door aan de hoofd-app. Deze Websocket-servers draaien vaak op een vaste poort.

Kwaadwillenden kunnen een eigen websocket server maken en zorgen dat deze eerder opgestart wordt dan die van de app zelf. Zo kan een een man-in-the-middle-aanval uitgevoerd worden. Een kwaadaardige websocket-server doet zich voor als de echte server en stuurt de data nog steeds door naar de echte app, maar houdt ook een kopie voor zichzelf. Ontwikkelaars kunnen dit zelf verhelpen door authenticatie toe te passen, maar veel apps hebben dit standaard niet.

4. Cross-app communicatie II

Apps kunnen ook op een andere manier met elkaar communiceren. Iedere app krijgt op iOS en OS X een eigen URL. Zo opent sms:// de berichten-app. Deze URL’s worden door veel apps gebruikt om inlog-tokens door te geven. Inloggen met Facebook? Dan geeft de app Facebook op deze manier een token mee: fbauth:////access_token=CAAAAP9uIENwBAKk&X=Y.

Een kwaadaardige app kan een url claimen en zo een man-in-the-middle-aanval uitvoeren. iOS blijkt altijd de app die het laatst een url geregistreerd heeft te openen. Veel OS X- en iOS-apps blijken de URL’s niet te inspecteren, maar ontwikkelaars kunnen dit zelf verhelpen.

Apple: werk aan de winkel

De meeste problemen zijn door ontwikkelaars of Apple op te lossen. De meeste problemen kunnen opgelost worden door meer verificatie toe te passen. Er is geen reden te bedenken waarom helper-apps zonder enige controle in de sandbox van hun hoofd-apps belanden. Waarom alle OS X-apps data uit de Keychain mogen halen is ook een raadsel.

De laatste twee problemen kunnen vaak door ontwikkelaars zelf opgelost worden, maar hen is nooit verteld dat de standaard methodes beveiligingsrisico’s opleveren. Gelukkig geven de onderzoekers in hun paper ook een aantal aanbevelingen.

En nu?

OS X 10.10.3, 10.10.4, iOS 8.3 en iOS 8.4 zijn kwetsbaar, maar een kwaadaardige app blijft nodig om de fouten in OS X en iOS te misbruiken. Ons advies: wees voorlopig voorzichtig en installeer geen apps van onbekende uitgevers, zelfs niet als ze in de App Store staan.

Schermafbeelding 2015-06-17 om 21.25.18

Overzicht van geteste en kwetsbare apps.

Raymon is vaste redacteur bij OMT, maar noemt zich liever redactieninja. Ook te volgen op Twitter en wekelijks te horen in de TechSnacks Podcast. Lees meer artikelen van Raymon.

En nu?

22 reacties

Profielfoto

djleon97 op 17 juni 2015

Ik heb afgelopen dagen geen rare apps gedownload op mijn Mac, maar toch moest ik ineens al m’n wachtwoorden invullen op safari, overal van uitgelogt. Hoe zit dat dan?

Profielfoto

whaha op 17 juni 2015

2-staps verificatie is je vriend!

Profielfoto

belfortmac op 17 juni 2015

@whaha
Geloof je het zelf!!:evil:

Profielfoto

SunKeeper op 18 juni 2015

Van alles wat genoemd wordt heb ik alleen MoneyControl op iOS staan.
Alleen is het me een raadsel wat iemand anders met de gegevens moet van de activiteit op mijn betaalrekening. De rekening zelf kun je via daar echt niet bijkomen. iCloud/Dropbox-sync is niet actief, zou niet weten waarom. Dus veel plezier met de data, lijst het in en hang boven je bed.:grin:

In Chrome gebruik ik geen wachtwoorden uit de Sleutelhanger. Alleen in Safari, maar die zie ik niet in de tabel.

Profielfoto

donut op 18 juni 2015

Goed artikel!

Blijkt maar weer eens dat je Apple ook niet kan vertrouwen als het om veiligheid gaat. De problemen zijn al sinds oktober 2014 bij Apple bekend!

Ons advies: wees voorlopig voorzichtig en installeer geen apps van onbekende uitgevers, zelfs niet als ze in de App Store staan.

Ja, ik weet er nog een: gebruik je computer niet meer en sluit geen internet meer aan. Die kwaadaardige apps heb je gedownload…

Profielfoto

Art-art op 18 juni 2015

Dank voor dit artikel. Als niet-expert nu eens wel kunnen begrijpen hoe dit soort zaken werken. Zal vast dieper, gedetailleerder etc. kunnen, maar voor een leek lekker leesbaar.

Profielfoto

SusanUSA op 18 juni 2015

Maar wat heeft Bing hiermee te maken?

Profielfoto

Facundo op 18 juni 2015

en zijn daarbij op maar liefst vier nieuwe, serieuze problemen in de systemen van Apple gestuit.

Wees volledig en vertel er ook bij dat Apple al meer dan een half jaar op de hoogte is en (waar kennen we dat toch van?) NIETS heeft gedaan.

Profielfoto

Facundo op 18 juni 2015

En hetzelfde flikt Apple met Yosemity: Ze wisten al 8 mnd. dat discoveryd de hoofdoorzaak is van die wifi/bluetooth-ellende, maar ze laten de gebruikers er gewoon mee zitten.

Profielfoto

ozzie X op 18 juni 2015

Dat dit soort lekken bestaan lijkt me weinig nieuwswaardig. Het is vooral dat Apple dit al een half jaar weet en nog geen actie heeft ondernomen.

Ofwel het is zo ingewikkeld dat het heel veel tijd kost,of er zit een strategie achter: eerst het nieuws halen en vervolgens snel met een update komen. Bij Apple weet je het nooit…

Profielfoto

bitsflew op 18 juni 2015

@Facundo

“Wees volledig en vertel er ook bij dat Apple al meer dan een half jaar op de hoogte is en (waar kennen we dat toch van?) NIETS heeft gedaan.”

Er is een reden voor dat Apple tot op dit moment nog niet met een oplossing is gekomen!

Als je wat dieper in de materie duikt dan kom je al snel tot de ontdekking dat het onderliggende probleem niet met een eenvoudige patch is op te lossen zonder dat dat gevolgen heeft op de werking van andere programma’s

Voor de geïnteresseerden: Een poster op Ars-technica gaat wat dieper in op de problematiek:

We want to restrict the extent to which apps can interact with each other (so that they can’t, for example, steal information from each other). BUT we also (sometimes) want apps to have communication channels between each other.

Now, how do you create a channel between two different apps, A and B? You can’t just say “well A will ‘tell B’ the name of the channel then B will join” — the whole point is that, before the channel exists A and B have no way to communicate.
The traditional solution to this has been to rely on various sorts of conventions. In this particular case, the convention is “we will use local socket number XXX”, another convention might be “we will use a shared memory segment named XXX” or even “we will start things by trading the information about the channel in a file named XXX”. The common thread in all of these is that there is a name that both A and B understand as being the rendezvous point — and that same name is visible to anyone else who takes the trouble to look. Which means someone else can create that rendezvous point instead and pretend to be one or both of A and B. There is nothing (in all the standard IPC mechanisms) that enforces ONLY apps A and B can create a channel named XXX, not anyone else.

Now, under normal circumstances, this doesn’t matter. Normal apps don’t care how A communicates with B. But (whole point of this article) there ARE cases where malicious apps can learn something useful from faking a rendezvous point.

So the problem to be solved is not minor issues of how exactly does 1PasswordMini interact with Safari; it’s how do you solve this problem in general? How do you allow two apps (ideally using conventions or without a shared secret) to create a rendezvous point in a way that cannot another app cannot perform the same task?
Perhaps the answer to this is private and public keys — Apple provides a way to create SecureXPC channels from A to B that rely on A and B’s public and private keys ala ssh? Done right this would allow both sides of the XPC channel to know that “they are who they claim to be.

Obviously this is not a trivial undertaking. First you have to design the idea, then code it, then test it. Then you have to tell developers how to use it, and how to embed the appropriate public keys in their apps (and how do they hide the private keys? deposit them with Apple? so this only works with a network connection? or rely on Apple to rely on further encryption voodoo to get them onto the Mac in a secure way?)
Then you have to change Safari, in particular, which for all we know has no mechanism right now to allow plugins to create their own XPC channels — and god knows what the security consequences are of allowing that — someone has to think that through.

Now IF Apple have been doing this work, it’s reasonable to expect that it could take longer than 6 months, and the researchers were dicks for going public. On the other hand, it’s not a good sign that Apple didn’t talk about any of this at WWDC — not necessarily describing the exact problem, but saying something like “we now have a secureXPC channel; here are the APIs, here’s how to provide keys to make it work, etc”. That suggests Apple have not been using these six months productively.”

Profielfoto

hopsa op 18 juni 2015

Goed artikel, ik ben gewaarschuwd!

Profielfoto

ozzie X op 18 juni 2015

@Bitsflew:

On the other hand, it’s not a good sign that Apple didn’t talk about any of this at WWDC — not necessarily describing the exact problem, but saying something like “we now have a secureXPC channel; here are the APIs, here’s how to provide keys to make it work, etc”. That suggests Apple have not been using these six months productively.”

Als ik deze alinea lees, moeten we ons dus toch wel zorgen maken over de aanpak van Apple. OK: het is een ingewikkeld en tijdrovend probleem, maar het is wel verontrustend dat Apple na die 6 maanden nog weinig concreets weet te melden.

Profielfoto

SMTR op 18 juni 2015

Blij dat ik 1Password gebruik….

Profielfoto

Maikelw op 18 juni 2015

Blij dat ‘k n brein heb wat ze kan onthouden….

Profielfoto

SMTR op 18 juni 2015

Als jouw brein alle verschillende wachtwoorden voor alle diensten die je gebruikt kan onthouden, heb je waarschijnlijk veel te zwakke wachtwoorden.

Profielfoto

toineenzo op 18 juni 2015

Windows is veiliger

Profielfoto

Scout op 18 juni 2015

@toineenzo

Trol (?)

Profielfoto

Maikelw op 18 juni 2015

Als jouw brein alle verschillende wachtwoorden voor alle diensten die je gebruikt kan onthouden, heb je waarschijnlijk veel te zwakke wachtwoorden.

Hmm ben ik wel met je eens tot op zekere hoogte. Het zijn geen reeksen als “78hdbubr7690jjko” maar denk ook weer niet zo makkelijk als “qwerty”.

Gezien je reactie lijkt het me verstandiger om ze aan te passen naar zinnen die ik alleen kan weten, blijf er toch bij dat onthouden beter is dan ergens opslaan. Zoals je ziet kan ook zo een service gekraakt worden.

Profielfoto

farl4web op 19 juni 2015

1Password is erg belangrijk voor mij. Dus als ik 1Password mini niet gebruik is er weinig aan de hand.. oh ja, en ff geen nieuwe apps installeren.

Profielfoto

Facundo op 20 juni 2015

@ozzie X: Precies! Het gaat hier om een KEUZE van Apple, niet om overmacht.

Profielfoto

andrevdvries op 24 juni 2015

Ik kon tot vandaag zelf niet eens bij mijn keychain

 


Je kunt alleen reageren met een gratis OMT account.
Heb je geen OMT account? Registreer je dan nu gratis!

Inloggen

 

of Wachtwoord resetten?