Kwetsbaarheid in nieuwe TouchID-functie brengt iCloud-accounts in gevaar voor inbraak

Inloggen via TouchID/FaceID in Safari - geen 2FA?

In iOS 13 en macOS 10.15 heeft Apple de mogelijkheid toegevoegd om in te loggen op Apple’s eigen sites met TouchID/FaceID in Safari op apparaten die de benodigde biometrische hardware bevatten.

Wanneer je een pagina bezoekt met een inlogformulier voor een Apple-account, wordt een prompt getoond om te authenticeren met TouchID. Als je authenticatie slaagt, ben je direct ingelogd. Dit slaat de stap van tweefactorauthenticatie over die je normaal gesproken moet uitvoeren bij het inloggen met je wachtwoord. Dit is logisch omdat het proces al als twee factoren kan worden beschouwd: je biometrische gegevens en het apparaat. Je kunt de prompt annuleren om normaal in te loggen, bijvoorbeeld als je een ander AppleID wilt gebruiken dan degene die op de telefoon is ingelogd.

We verwachten dat de primaire gebruikssituatie van deze functie niet het inloggen op iCloud is (aangezien het vrij zeldzaam is om icloud.com in Safari op een telefoon te gebruiken), maar we verwachten dat de belangrijkste motivatie was voor “Inloggen met Apple” op het web, waarvoor deze functie ook werkt. Voor die sites worden extra opties getoond bij het aanmaken van een nieuw account, bijvoorbeeld of je je e-mailadres wilt verbergen.

Inloggen op Apple-domeinen met OAuth2

Inloggen op Apple-domeinen gebeurt met OAuth2. Op https://icloud.com wordt hiervoor de “web_message” modus gebruikt. Dit werkt als volgt bij een normale login:

1. https://icloud.com embedt een iframe dat verwijst naar https://idmsa.apple.com/appleauth/auth/authorize/signin?client_id=d39ba9916b7251055b22c7f910e2ea796ee65e98b2ddecea8f5dde8d9d1a815d
   &redirect_uri=https%3A%2F%2Fwww.icloud.com
   &response_mode=web_message
   &response_type=code.
2. De gebruiker logt in (inclusief stappen zoals het invoeren van een 2FA-token) binnen het iframe.
3. Als de authenticatie slaagt, stuurt het iframe een bericht terug naar het bovenliggende venster met een grant_code voor de gebruiker via window.parent.postMessage(, "https://icloud.com") in JavaScript.
4. De grant_code wordt door de icloud.com-pagina gebruikt om het inlogproces voort te zetten.

Correcte validatie van redirect URI essentieel voor het beschermen van de gebruikersgrantcode

Twee van de parameters zijn erg belangrijk in de iframe-URL: de client_id en redirect_uri. De idmsa.apple.com-server houdt een lijst bij van geregistreerde OAuth2-clients en de redirect-URI's die voor elke client zijn toegestaan. In het geval van de web_message-flow wordt de redirect URI niet gebruikt als een echte redirect, maar wordt deze gebruikt als de vereiste pagina-origin van het geposte bericht met de grant code (het tweede argument voor postMessage).

Voor alle OAuth2-modi is het erg belangrijk dat de authenticatieserver de redirect URI correct valideert. Als dat niet gebeurt, kan de grant_code van de gebruiker naar een kwaadaardige webpagina worden gestuurd. Bij het inloggen op de website voert idmsa.apple.com die controle correct uit: het wijzigen van de redirect_uri naar iets anders resulteert in een foutpagina.

Gebruik van nepantwoord door Safari

Wanneer de gebruiker zich authenticeren met TouchID, wordt het iframe anders behandeld, maar de buitenste pagina blijft hetzelfde. Wanneer Safari een nieuwe pagina detecteert met een URL die overeenkomt met de voorbeeld-URL hierboven, downloadt het de pagina niet, maar roept het in plaats daarvan het proces AKAppSSOExtension aan. Dit proces communiceert met de AuthKit-daemon (akd) om de biometrische authenticatie af te handelen en een grant_code op te halen. Als de gebruiker succesvol authenticeren, injecteert Safari een nepantwoord in het hangende iframe-verzoek dat het bericht terugplaatst, op dezelfde manier als de normale pagina zou doen als de authenticatie was geslaagd. akd communiceert met een API op gsa.apple.com, waar het de details van het verzoek naartoe stuurt en waarvan het een grant_code ontvangt.

Impact van kwetsbaarheid: kwaadwillenden kunnen inloggen op iCloud-accounts van andere gebruikers

Wat we ontdekten was dat de gsa.apple.com API een bug had: hoewel de client_id en redirect_uri waren opgenomen in de gegevens die door akd werden verzonden, controleerde het niet of de redirect URI overeenkomt met de client ID. In plaats daarvan werd alleen een whitelist toegepast door AKAppSSOExtension op de domeinen. Alle domeinen die eindigen op apple.com, icloud.com en icloud.com.cn werden toegestaan. Dat klinkt misschien veilig genoeg, maar houd er rekening mee dat apple.com honderden (zo niet duizenden) subdomeinen heeft. Als een van deze subdomeinen op de een of andere manier kan worden misleid om kwaadaardige JavaScript uit te voeren, dan kunnen ze worden gebruikt om de prompt voor een login met de iCloud client_id te activeren, waardoor dat script de grant code van de gebruiker kan ophalen als ze zich authenticeren. Vervolgens kan de pagina deze terugsturen naar een aanvaller die deze kan gebruiken om een sessie op icloud.com te verkrijgen.

Hoe kunnen kwaadwillenden toegang krijgen?

Enkele voorbeelden van hoe dat kan gebeuren:

• Een cross-site scripting kwetsbaarheid op een willekeurig subdomein. Deze worden vrij regelmatig gevonden, https://support.apple.com/en-us/HT201536 vermeldt minstens 30 kandidaten uit 2019, en dat betreft alleen de domeinen die belangrijk genoeg zijn om te onderzoeken.

• Een loshangend subdomein dat kan worden overgenomen door een aanvaller. Hoewel ik niet op de hoogte ben van gevallen waarbij dit bij Apple is gebeurd, vond iemand onlangs 670 subdomeinen van microsoft.com die beschikbaar waren voor overname: https://nakedsecurity.sophos.com/2020/03/06/researcher-finds-670-microsoft-subdomains-vulnerable-to-takeover/

• Een gebruiker die een pagina op een willekeurig subdomein bezoekt via HTTP. De belangrijke subdomeinen zullen een HSTS-header hebben, maar veel niet. Het domein apple.com is niet HSTS vooringeladen met includeSubdomains.

Gebruik van Apple's captive portal

De eerste twee vereisen dat de aanvaller gebruikers misleidt om de kwaadaardige pagina te bezoeken. De derde vereist dat de aanvaller toegang heeft tot het lokale netwerk van de gebruiker. Hoewel zo'n aanval over het algemeen moeilijker is, biedt het een zeer interessant voorbeeld: captive.apple.com. Wanneer een Apple-apparaat verbinding maakt met een Wi-Fi-netwerk, probeert het http://captive.apple.com/hotspot-detect.html te benaderen. Als het antwoord niet overeenkomt met het gebruikelijke antwoord, gaat het systeem ervan uit dat er een captive portal is waar de gebruiker eerst iets moet doen. Om de gebruiker dat te laten doen, wordt de responspagina geopend en getoond. Meestal leidt dit de gebruiker door naar een andere pagina waar ze moeten inloggen, de voorwaarden accepteren, betalen, enzovoort. Het hoeft echter niet zo te zijn. In plaats daarvan kan de pagina JavaScript insluiten die de TouchID-login activeert, wat wordt toegestaan omdat het op een apple.com subdomein staat. Als de gebruiker zich authenticeren, ontvangt de kwaadaardige JavaScript de grant_code van de gebruiker.

'Aanmelden met Apple'

De pagina kan allerlei inhoud bevatten om de gebruiker meer geneigd te maken zich te authenticeren, bijvoorbeeld door de pagina eruit te laten zien alsof het deel uitmaakt van iOS zelf of een "Aanmelden met Apple"-knop. "Aanmelden met Apple" is nog vrij nieuw, dus gebruikers merken misschien niet dat de prompt iets anders is dan normaal. Bovendien zullen veel gebruikers waarschijnlijk automatisch authenticeren wanneer ze een TouchID-prompt zien, omdat die bijna altijd bedoeld zijn om zich te authenticeren op de telefoon; het feit dat gebruikers ook moeten bepalen of ze zich willen authenticeren bij de pagina die de prompt heeft geopend, wordt niet duidelijk gemaakt.

Apple's reactie op onze verantwoordelijke melding

We hebben deze kwetsbaarheid gemeld aan Apple via hun verantwoordelijke meldingsprogramma, en zij hebben het dezelfde dag nog opgelost nadat ze het hadden beoordeeld. De gsa.apple.com API controleert nu correct of de redirect_uri overeenkomt met de client_id. Daarom kon dit volledig aan de serverzijde worden opgelost.

Het is voor ons heel begrijpelijk hoe deze kwetsbaarheid over het hoofd gezien kon worden: mensen die dit testen zullen zich waarschijnlijk hebben gericht op het gebruik van niet-vertrouwde domeinen voor de redirect_uri. Bijvoorbeeld, soms werkt het om https://www.icloud.com.attacker.com of https://attacker.com/https://www.icloud.com te gebruiken. In dit geval falen beide echter, maar door alleen die te proberen zou je de mogelijkheid missen om een kwaadaardige subdomein te gebruiken.