Vulnerabilitat en la nova funció TouchID posa en risc els comptes d'iCloud de ser vulnerats

Iniciar sessió amb TouchID/FaceID a Safari - sense 2FA?

A iOS 13 i macOS 10.15, Apple va afegir la possibilitat d'iniciar sessió als seus propis llocs utilitzant TouchID/FaceID a Safari en dispositius que inclouen el maquinari biomètric necessari.

Quan visites qualsevol pàgina amb un formulari d'inici de sessió per a un compte Apple, es mostra un avís per autenticar-te amb TouchID. Si t'autentiques, s'inicia sessió immediatament. Això salta el pas d'autenticació de dos factors que normalment hauries de fer quan inicies sessió amb la teva contrasenya. Té sentit perquè el procés ja es pot considerar que requereix dos factors: les teves dades biomètriques i el dispositiu. Pots cancel·lar l'avís per iniciar sessió normalment, per exemple si vols utilitzar un AppleID diferent del que està iniciat al telèfon.

Esperem que l'ús principal d'aquesta funció no sigui per iniciar sessió a iCloud (ja que és força rar utilitzar icloud.com a Safari en un telèfon), però esperem que el principal motivador fos per a "Iniciar sessió amb Apple" a la web, per al qual aquesta funció també funciona. Per a aquests llocs es mostren opcions addicionals quan es crea un compte nou, per exemple si vols amagar la teva adreça de correu electrònic.

Inici de sessió en dominis d'Apple mitjançant OAuth2

L'inici de sessió en dominis d'Apple es fa mitjançant OAuth2. A https://icloud.com, s'utilitza el mode "web_message". Això funciona de la següent manera quan es fa un inici de sessió normal:

1. https://icloud.com incorpora un iframe que apunta a 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. L'usuari inicia sessió (incloent passos com introduir un token 2FA) dins de l'iframe.
3. Si l'autenticació té èxit, l'iframe envia un missatge a la finestra pare amb un grant_code per a l'usuari utilitzant window.parent.postMessage(, "https://icloud.com") en JavaScript.
4. El grant_code és utilitzat per la pàgina icloud.com per continuar el procés d'inici de sessió.

La validació correcta de la URI de redirecció és essencial per protegir el codi de concessió de l'usuari

Dos dels paràmetres són molt importants a la URL de l'iframe: el client_id i el redirect_uri. El servidor idmsa.apple.com manté un registre d'una llista de clients OAuth2 registrats i les URIs de redirecció que estan permeses per a cada client. En el cas del flux web_message, la URI de redirecció no s'utilitza com una redirecció real, sinó que s'utilitza com l'origen de pàgina requerit del missatge enviat amb el codi de concessió (el segon argument per a postMessage).

Per a tots els modes OAuth2, és molt important que el servidor d'autenticació validi correctament la URI de redirecció. Si no ho fa, el grant_code de l'usuari podria ser enviat a una pàgina web maliciosa. Quan s'inicia sessió al lloc web, idmsa.apple.com realitza aquesta comprovació correctament: canviar el redirect_uri per qualsevol altra cosa resulta en una pàgina d'error.

Ús de resposta falsa per Safari

Quan l'usuari s'autentica utilitzant TouchID, l'iframe es gestiona de manera diferent, però la pàgina exterior roman igual. Quan Safari detecta una nova pàgina amb una URL que coincideix amb l'exemple anterior, no descarrega la pàgina, sinó que invoca el procés AKAppSSOExtension. Aquest procés es comunica amb el dimoni AuthKit (akd) per gestionar l'autenticació biomètrica i per recuperar un grant_code. Si l'usuari s'autentica amb èxit, Safari injecta una resposta falsa a la sol·licitud pendent de l'iframe que envia el missatge de tornada, de la mateixa manera que ho faria la pàgina normal si l'autenticació hagués tingut èxit. akd es comunica amb una API a gsa.apple.com, a la qual envia els detalls de la sol·licitud i de la qual rep un grant_code.

Impacte de la vulnerabilitat: actors malintencionats poden iniciar sessió al compte iCloud d'altres usuaris

El que vam trobar és que l'API de gsa.apple.com tenia un error: tot i que el client_id i redirect_uri estaven inclosos en les dades enviades per akd, no comprovava que la URI de redirecció coincidís amb el client ID. En canvi, només s'aplicava una llista blanca per part d'AKAppSSOExtension als dominis. Es permetien tots els dominis que acabessin en apple.com, icloud.com i icloud.com.cn. Això pot semblar prou segur, però cal tenir en compte que apple.com té centenars (si no milers) de subdominis. Si algun d'aquests subdominis es pot enganyar per executar JavaScript maliciós, es podria utilitzar per desencadenar la sol·licitud d'inici de sessió amb el client_id d'iCloud, permetent que aquest script recuperi el codi de concessió de l'usuari si s'autentica. Aleshores, la pàgina pot enviar-lo a un atacant que pot utilitzar-lo per obtenir una sessió a icloud.com.

Com podrien els actors malintencionats accedir?

Alguns exemples de com podria passar això:

• Una vulnerabilitat de cross-site scripting en qualsevol subdomini. Aquestes es troben bastant regularment, https://support.apple.com/en-us/HT201536 en llista almenys 30 candidats del 2019, i això només cobreix els dominis prou importants per investigar.

• Un subdomini penjant que pot ser pres per un atacant. Tot i que no tinc constància de cap cas d'això amb Apple, recentment algú va trobar 670 subdominis de microsoft.com disponibles per a la presa de control: https://nakedsecurity.sophos.com/2020/03/06/researcher-finds-670-microsoft-subdomains-vulnerable-to-takeover/

• Un usuari que visita una pàgina en qualsevol subdomini via HTTP. Els subdominis importants tindran un capçal HSTS, però molts no. El domini apple.com no està pre-carregat amb HSTS amb includeSubdomains.

Ús del portal captiu d'Apple

Els dos primers requereixen que l'atacant enganyi els usuaris perquè visitin la pàgina maliciosa. El tercer requereix que l'atacant tingui accés a la xarxa local de l'usuari. Tot i que aquest tipus d'atac és generalment més difícil, permet un exemple molt interessant: captive.apple.com. Quan un dispositiu Apple es connecta a una xarxa Wi-Fi, intenta accedir a http://captive.apple.com/hotspot-detect.html. Si la resposta no coincideix amb la resposta habitual, el sistema assumeix que hi ha un portal captiu on l'usuari haurà de fer alguna cosa primer. Per permetre que l'usuari ho faci, s'obre i es mostra la pàgina de resposta. Normalment, això redirigeix l'usuari a una altra pàgina on ha d'iniciar sessió, acceptar termes i condicions, pagar, etc. No obstant això, no cal que ho faci. En canvi, la pàgina podria incloure JavaScript que desencadeni l'inici de sessió TouchID, que serà permès ja que està en un subdomini apple.com. Si l'usuari s'autentica, el JavaScript maliciós rep el grant_code de l'usuari.

'Inicia sessió amb Apple'

La pàgina podria incloure tot tipus de contingut per fer que l'usuari sigui més propens a autenticar-se, per exemple fent que la pàgina sembli part d'iOS o un botó de “Inicia sessió amb Apple”. “Inicia sessió amb Apple” encara és força nou, així que els usuaris podrien no notar que la sol·licitud és lleugerament diferent del normal. A més, molts usuaris probablement s'autentiquen automàticament quan veuen una sol·licitud TouchID, ja que aquestes gairebé sempre són per autenticar-se al telèfon; el fet que els usuaris també haurien de determinar si volen autenticar-se a la pàgina que ha obert la sol·licitud no es fa evident.

Resposta d'Apple a la nostra divulgació responsable

Vam informar d'aquesta vulnerabilitat a Apple a través del seu programa de divulgació responsable, i la van solucionar el mateix dia que la van avaluar. L'API gsa.apple.com ara comprova correctament que el redirect_uri coincideix amb el client_id. Per tant, això es podria solucionar completament des del servidor.

Ens sembla molt lògic com aquesta vulnerabilitat podria haver passat desapercebuda: les persones que la provaven probablement s'haurien centrat en utilitzar dominis no confiables per al redirect_uri. Per exemple, de vegades funciona utilitzar https://www.icloud.com.attacker.com o https://attacker.com/https://www.icloud.com. En aquest cas, ambdós fallen, però intentant només aquests hauries perdut la capacitat d'utilitzar un subdomini maliciós.