Onderzoekers van de universiteiten van Indiana, Peking en Georgia hebben de beveiliging van iOS en OS X in 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.

Overzicht van geteste en kwetsbare apps.