This is the message sent to CESICAT on Apr 25, 2018, 5:52 PM (Madrid time):

Benvolguts,

Tal com hem parlat per telèfon, us envio aquest correu electrònic per tal de concretar-vos els detalls de la vulnerabilitat, una proposta de resolució, i uns pasos per tal de demostrar la vulnerabilitat.

Bàsicament falta un control d'accés (o potser hi ha un però falla) a un mètode de l'API que s'utilitza a la pàgina accesuniversitat.gencat.cat.

El mètode en qüestió és el que permet obtenir les dades personals d'un estudiant en concret, i es crida de la següent manera (s'ha de tenir en compte que no tinc coneixement de l'API perquè no l'he desenvolupat jo ni tinc accés a documentació sobre aquesta, però el que escric aquí sota és el comportament que dedueixo al veure exemples de peticions que fa el codi Javascript de la pàgina):

Mètode estudiants

P​er cridar aquest mètode, s'ha de fer una p​etició GET a ​​​​https://accesuniversitat.gencat.cat/accesuniversitat/accesuniversitat-rs/AppJava/api/v1/estudiants/{id}, on {id} és el codi identificador de l'alumne de qui es vol saber les seves dades. ​​(No sé quina estructura ​segueix ​​aquest​​ codi identificador, però sospito que és un autoincremental)

La petició ha d'anar acompanyada de la capçalera ​​Authentication: Bearer {token}, on {token} és un​a cadena de caràcters​ vàlid​a​ que identifica unívocament a cada usuari i que es genera ​en el moment d​'iniciar sessió al lloc web com estudiant.

El mètode retorna un JSON amb la informació de l'usuari. Adjunto un exemple de la resposta que resultaria de fer la petició substituïnt {id} per 42 (les dades són fictícies, aquest usuari no existeix):

{"idAlumne":42,"identificador":"12345678A","tipusDocument":"A","contrasenya":null,"primerCognom":"PEPITO","segonCognom":"GRILLO","nom":"PEP","dataNaixement":"2021-01-01","adreca":"Carrer Pau Gargallo, 0","codiPostal":"08080","codiIne":"08000","codiLlogaret":"00","codiPaisDom":"ESP","codiPaisNaix":"ESP","poblacioEstrangera":null,"sexe":"H","telefon":"600000000","telefon2":"600000001","primerDni":null,"eMail":"email@example.com","autUsMobil":true,"idioma":"ca","dataNaixValidat":false,"dataNaixValidatUsuari":null,"dataNaixValidatData":null,"actiu":true,"primerLogin":false,"bloquejat":false,"intents":0,"dataModificacio":"2030-01-01","dataCreacio":"2030-01-01","usuariCreacio":"TICxCAT","usuariModificacio":"12345678A","dataBaixa":null,"usuariBaixa":null,"version":30,"nomOficial":"PEP","hashReset":null,"dataCaducitatHash":null,"baixa":false,"generatePassword":false,"contrasenyaActual":null,"referencia":null}

El problema està en què a l'aplicatiu web, aquest mètode s'utilitza per obtenir les dades de l'usuari que ha iniciat sessió, però si es fa una petició a aquesta mateixa URL amb un id que no sigui el de l'usuari, també es retornaran les dades d'aquell altre usuari i no donarà cap error. Conseqüentment, un usuari pot obtenir les dades personals d'altres usuaris introduïnt l'id d'un altre usuari (que no és difícil de fer, ja que com sembla que el camp id és autoincremental i no random, es podrien obtenir dades d'usuaris recorrent els ids un per un). Els camps que es retornen estan detallats en el JSON de l'exemple anterior, i inclouen DNI, adreça, telèfon, data de naixement, correu, etc.

Proposta de resolució

Com a proposta per solucionar aquest problema en concret, posaria un control d'accés/seguretat en aquest mètode tal com s'ha en altres mètodes de l'API. Bàsicament, l'API hauria de permetre les peticions d'alumnes per poder accedir a les seves dades personals, però hauria de denegar-les si la petició és per obtenir les d'un altre usuari diferent. Tot i així, s'ha d'anar en compte ja que si aquest mètode també és utilitzat pels administradors del lloc web, s'hauria de fer de tal manera que aquests continuïn tenint els permisos necessaris per poder accedir a les dades personals de tots els alumnes, o el que sigui convenient (no sé com hauria de funcionar).

Demostració de la vulnerabilitat

Aquests són uns pasos que permeten explotar la vulnerabilitat:

1. Obriu un navegador web, com per exemple Chromium (que és de codi obert) o Google Chrome.
2. Tot seguit, accediu a la pàgina web https://accesuniversitat.gencat.cat
3. Introduïu l'identificador d'estudiant i contrasenya d'un usuari per tal d'entrar al lloc (però no feu clic al botó "Accedir" encara). Potser necessitareu crear un usuari estudiant abans de fer això.
4. Obriu l'inspector de peticions HTTP al vostre navegador. Al Chrome, podeu utilitzar la drecera Ctrl+Shift+I per obrir les Eines de desenvolupadors, i feu clic a la pestanya Network (o "xarxa" en català).
5. Ara, feu clic al botó Accedir per iniciar sessió.
6. Es realitzarà una petició via XHR per tal d'iniciar sessió. La petició es fa a la URL https://accesuniversitat.gencat.cat/accesuniversitat/accesuniversitat-rs/AppJava/api/v1/public/login, i apareixerà a la llista de peticions. Si feu clic a aquesta petició que apareixerà al llistat de peticions de la finestra que hem obert, i accediu a la pestanya Response (o "resposta" en català) podreu veure un codi JSON similar al següent. Preneu nota del contingut del camp token (en aquest exemple seria abcdef, tot i que en realitat serà una cadena de caràcters molt més llarga).

{"token":"abcdef","hostName":"lt20stx2.cpd2.intranet.gencat.cat","activeSessions":1}

7. Obriu una terminal de Linux i executeu la següent comanda: curl --header "Authentication: Bearer {token}" https://accesuniversitat.gencat.cat/accesuniversitat/accesuniversitat-rs/AppJava/api/v1/estudiants/1218208 on heu de substituir el text {token} pel token que hem apuntat al pas anterior.

En cas de no disposar del programa curl o estar en un sistema operatiu diferent a Linux, obriu un programa que permeti fer peticions HTTP (per exemple jo utilitzo l'aplicació per Chrome ARC (Advanced Rest Client)) i configureu i executeu una petició amb els següents detalls (adjunto una captura de pantalla amb la petició):

• Mètode: GET
• Url: ​https://accesuniversitat.gencat.cat/accesuniversitat/accesuniversitat-rs/AppJava/api/v1/estudiants/1218208
• Capçalera: Authentication: Bearer {token} on {token} s'ha de substituir pel token obtingut al pas anterior.

8. Després de realitzar la petició, hauríeu de rebre com a resposta un codi JSON similar al que he posat més a dalt, quan he descrit el mètode estudiants. Per sorpresa, les dades personals que podeu llegir no són les de l'usuari que ha iniciat sessió sinó unes altres. Si es canvia el nombre 1218208 de la petició per un altre, s'obtindran les dades d'un usuari diferent, si existeix a la base de dades.

Finalment, m'agradaria informar-vos que, seguint la pràctica d'equips d'investigació de seguretat en Internet d'empreses com Google (Project Zero) i Yahoo, si transcorren 90 dies des de l'enviament d'aquest correu electrònic sense cap solució àmpliament disponible al problema, l'informe de la vulnerabilitat es publicarà a Internet.

El motiu pel qual es duu a terme aquesta pràctica, que jo també he adoptat, és perquè permet als usuaris conèixer les vulnerabilitats i els seus riscs en cas que la vulnerabilitat no es solucioni en un període de temps raonable, i alhora fa que les empreses/organismes que es fan càrrec del software arreglin ràpidament i efectivament les vulnerabilitats. Per més arguments i informació sobre aquesta pràctica es pot consultar la següent entrada del bloc del grup d'investigació de Google "Project Zero": Project Zero: Feedback and data-driven updates to Google’s disclosure policy

Espero la vostra resposta i ens mantenim en contacte.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public.