Esposizione di dati sensibili di autenticazione in WinGesfar

Credenziali nei log dei servizi DPC e delle spese sanitarie

Il rapporto documenta la registrazione di credenziali di accesso nei log dei moduli webDPC, WgWebcare e Sole. La scrittura avveniva durante il normale funzionamento dei componenti, non soltanto attraverso una modalità diagnostica attivata appositamente. La conservazione di archivi storici estendeva l’esposizione a segreti precedenti e a copie dei log trasferite per assistenza o backup.

Il materiale documentato per i servizi DPC e per i flussi 730 appartiene a integrazioni distinte. L’impatto va quindi valutato sul singolo account o servizio coinvolto, senza attribuire automaticamente a una credenziale i privilegi degli altri sistemi.

I percorsi documentati includono anche materiale di autenticazione HTTP Basic nei log. La codifica di un valore di autenticazione non ne costituisce una protezione crittografica. Copie dei log o archivi di assistenza possono quindi conservare informazioni riutilizzabili anche quando non mostrano visivamente una password come testo semplice.

FSE: credenziali applicative, token e dati di risposta

Nei moduli FSE il report distingue le credenziali OAuth2 dell’applicazione, i token di accesso e il materiale di rinnovo della sessione. Alcune informazioni erano scritte nei log; altro materiale di sessione era persistito su disco. La protezione dell’accesso iniziale con una carta o un secondo fattore non protegge automaticamente una copia dei token generati dopo quell’accesso.

I log includevano richieste contenenti identificativi dei pazienti e risposte con informazioni prescrittive. Chi avesse avuto accesso a questi archivi avrebbe potuto associare gli identificativi ai dati sanitari presenti nelle risposte, anche senza riutilizzare una sessione remota.

API Manager SISS: separazione tra applicazione e operatore

Le credenziali conservate nella configurazione dell’API Manager erano utilizzate per l’autenticazione applicativa verso il gateway SISS/SAR Lombardia. Questo livello identifica il software che richiede il servizio e va distinto dall’identità dell’operatore sanitario.

Le operazioni prescrittive richiedevano anche una sessione operatore autenticata. L’eventuale riutilizzo congiunto delle credenziali applicative e del materiale di sessione avrebbe potuto consentire operazioni nei limiti dei privilegi dell’operatore, se i token fossero stati ancora validi e accettati dal servizio.

I file XML e i risultati delle elaborazioni prescrittive conservavano localmente informazioni sui medicinali e sul medico in chiaro. La lettura di questi artefatti avrebbe potuto esporre i dati già presenti sul disco, indipendentemente dalla possibilità di autenticarsi nuovamente al servizio.

Piattaforma Stella e WgApiConnect

I log di WgApiConnect contenevano credenziali OAuth2 e token JWT impiegati nell’integrazione con la piattaforma Stella. La documentazione collega questa piattaforma a distribuzione software, telemetria, raccolta delle configurazioni e scambio di dati. La presenza di materiale di autenticazione relativo a più funzioni rende importante distinguere l’esposizione del segreto dalle autorizzazioni che il backend gli riconosce.

L’identità applicativa era condivisa a livello di fornitore. Il recupero del relativo materiale di autenticazione avrebbe potuto consentire richieste verso la piattaforma cloud, con una portata dipendente dalle autorizzazioni associate all’identità e dai controlli applicati alle singole operazioni.

La piattaforma comprendeva risorse per distribuzione software, telemetria, raccolta delle configurazioni e scambio bidirezionale. I moduli di migrazione dati erano configurati per inviare identificativi dei pazienti e codici di esenzione a un’API con credenziali dedicate. L’esposizione del materiale di autenticazione avrebbe potuto interessare anche questi flussi, in funzione delle autorizzazioni del servizio.

Browser integrato e materiale OAuth2 persistente

WgBrowser conservava un profilo WebView2 persistente, con cookie, archivi locali e dati di sessione. Nei log erano scritti anche parametri effimeri del flusso OAuth2 con PKCE. La loro persistenza oltre il flusso che li richiedeva avrebbe potuto renderli accessibili a processi o soggetti con accesso agli artefatti locali.

Il materiale acquisito dal profilo o dai log avrebbe potuto essere riutilizzato in presenza di una sessione o di un flusso di autenticazione ancora validi. Il possibile effetto dipendeva dai tempi di acquisizione, dai vincoli del servizio e dalle protezioni applicate agli archivi del browser.

Il browser integrato inviava inoltre l’indirizzo MAC della postazione come parametro di collegamento verso un servizio di un partner. L’impiego di un identificativo hardware persistente avrebbe potuto consentire la correlazione degli accessi provenienti dalla stessa postazione.