Divulgazione del 3 novembre 2026
Descrizione
I componenti di identità AIS distribuivano certificati con chiave privata per autenticare il client verso i servizi CGM. La richiesta di token includeva un identificativo del medico fornito dal chiamante, senza un legame crittografico individuale con il certificato condiviso. Ciò avrebbe potuto consentire richieste riferite a identità mediche arbitrarie.
Componenti interessati
Infantia, Profim, Phronesis e Venere: certificati incorporati e richiesta di token verso i servizi di identità CGM.
- Certificati e chiavi private incorporati nei componenti AIS.
- Client assertion JWT e autenticazione dell’applicazione.
- Identificativo del medico nella richiesta di token.
Causa della vulnerabilità
La chiave applicativa era distribuita e condivisa tra installazioni. Il medico era indicato dal chiamante, senza un legame individuale con quel materiale di firma. Il possesso della chiave e il diritto a rappresentare il professionista potevano quindi appartenere a soggetti diversi.
Analisi tecnica
Materiale di firma distribuito
Le librerie includevano certificati con chiavi private come risorse e il materiale necessario ad aprirli. La protezione del contenitore non separava quindi il segreto dal client.
Il recupero della chiave avrebbe potuto permettere firme attribuite all’identità applicativa finché il materiale fosse rimasto valido e accettato.
Client assertion e identità professionale
Il flusso firmava una client assertion JWT e aggiungeva l’identificativo del medico ricevuto dal chiamante. Il certificato generico identificava il client, ma non stabiliva quale medico il richiedente fosse autorizzato a rappresentare.
Una richiesta per un’identità diversa avrebbe potuto generare un token per quel medico se il server non avesse applicato un vincolo aggiuntivo tra client, professionista e richiesta.
Portata del token
L’identità attestata nel token e le autorizzazioni delle singole funzioni sono livelli distinti. L’eventuale token avrebbe potuto interessare i servizi che ne riconoscevano identità e ambiti.
L’effetto dipendeva da validità, revoca e controlli dei backend. Un certificato applicativo non equivale automaticamente alle credenziali personali o ai certificati individuali richiesti da altri sistemi.
Prerequisiti e condizioni
- Disponibilità dei componenti con il materiale di firma e raggiungibilità del servizio.
- Accettazione del materiale da parte del server.
- Assenza di un vincolo efficace tra medico richiesto e soggetto autorizzato.
Impatto potenziale
Il recupero del materiale di firma avrebbe potuto consentire richieste autenticate come client applicativo con l’identità di un medico scelto dal chiamante. Se il servizio l’avesse accettata senza vincoli ulteriori, avrebbe potuto emettere un token per quel medico. Accessi e operazioni sarebbero dipesi dai privilegi del token e dai controlli dei servizi destinatari.
Indicazioni di mitigazione
Revocare il materiale di firma distribuito e vincolare sul server l’identità del medico a un’autenticazione e un’autorizzazione distinte dalla sola identità dell’applicazione.
- Revocare le chiavi distribuite e riesaminare i token emessi con esse.
- Separare identità applicativa e professionale e verificarne il legame sul server.
- Limitare gli ambiti e rendere le identità revocabili.
- Verificare il rifiuto delle richieste per medici non autorizzati anche da client riconosciuti.
Stato della correzione
Risoluzione dichiarata dal fornitore
Il fornitore ha comunicato la risoluzione delle vulnerabilità comprese in questo advisory. Il ricercatore non ha potuto verificare le patch, poiché il fornitore non ha offerto questa possibilità. La risoluzione resta pertanto una dichiarazione del fornitore e non una verifica indipendente del ricercatore.
Fonte e aggiornamento
Documentazione tecnica di ricerca Phronesis, Venere e Infantia/Profim del 10 luglio 2026, limitata ai finding autorizzati per questo advisory. Le descrizioni riguardano le condizioni precedenti alle correzioni dichiarate dal fornitore.
Aggiornamento della scheda: 3 novembre 2026.
Metodo e divulgazione
La scheda descrive le condizioni documentate nella ricerca sui componenti e sugli artefatti del software. I possibili effetti dipendono dai prerequisiti e dai controlli indicati; lo stato della correzione è riportato separatamente. Sono pubblicati soltanto i finding con pubblicabilità confermata, senza credenziali, chiavi o istruzioni di sfruttamento.
Per riscontri tecnici, indicazioni sulle versioni corrette o richieste di rettifica: contatta l’Osservatorio.