Endpoint API non protetto su HAwebsso.nl

Background
Come alcuni sapranno, lavoro come medico (medico generico) di giorno e come ricercatore di sicurezza di notte . Uno dei miei obiettivi nell'hacking etico è imparare il più possibile per essere in grado di controllare personalmente prodotti sanitari, app, siti Web o infrastrutture. È davvero, davvero sicuro? Non mi fido di emblemi o certificati luccicanti.

Oggi daremo uno sguardo alla sicurezza del Nederlandse Huisartsen Genootschap (NHG) e del Landelijke Huisartsen Vereniging (LHV). Si tratta di organizzazioni professionali per medici generici (GP) nei Paesi Bassi. Il NHG stabilisce gli standard per i medici generici e fornisce istruzione e formazione, mentre il LHV rappresenta gli interessi dei medici generici e lavora per migliorare la qualità e l'accessibilità delle cure primarie. Entrambe le organizzazioni svolgono ruoli importanti nel sistema sanitario olandese, lavorando per garantire che i pazienti ricevano cure di alta qualità dai loro medici di base. Al momento abbiamo 13k GP nei Paesi Bassi.

Ricognizione, da dove iniziare?
E se NHG e LHV fossero ritenuti vulnerabili, potremmo avere un impatto su quei 13.000 medici associati?

NHG e LHV dispongono entrambi di numerose applicazioni online che consentono ai medici di accedere e interagire. Ad esempio HAweb.nl , una comunità online per medici e richtlijnen.nhg.org che consente ai medici di aggiungere le loro note personali alle linee guida professionali.

Oggi inizio semplicemente facendo clic sul sito Web principale di LHV.nl alla ricerca di diversi sottodomini e di come funziona la procedura di accesso .

Ciò che condivide la maggior parte delle applicazioni LHV e NHG è un metodo di autenticazione Single Sign-On (SSO) che utilizza il dominio hawebsso.nl . Si apre ogni volta che provi ad accedere ad alcune applicazioni che richiedono l'autorizzazione, come haweb.nl

SSO è un metodo di autenticazione che consente agli utenti di accedere a più applicazioni e servizi con un unico set di credenziali di accesso . Ciò elimina la necessità per gli utenti di ricordare e gestire più set di informazioni di accesso e può migliorare notevolmente l'esperienza utente e la produttività. Le organizzazioni utilizzano spesso SSO per semplificare l'accesso a più sistemi e applicazioni, migliorare la sicurezza riducendo il numero di posizioni in cui sono archiviate le credenziali utente e centralizzare il controllo sull'accesso alle risorse. Inoltre, SSO può essere integrato con altre funzionalità di sicurezza, come l'autenticazione a più fattori, per fornire un ulteriore livello di protezione per sistemi e dati sensibili.

La buona notizia è che se hackeriamo l'SSO abbiamo accesso a tutto. La cattiva notizia è che la maggior parte dei sistemi SSO utilizzati sono pezzi di software pesantemente testati in battaglia (sentiti libero di scambiare good newse bad newsin questa frase).

Buona fortuna rompendo un servizio SSO collaudato in battaglia.

Bonus
Un buon trucco per vedere rapidamente il possibile ambito del sistema SSO è verificare la presenza di endpoint OpenID , provare a visitarehttps://hawebsso.nl/.well-known/openid-configuration

Un'altra cosa che controllo rapidamente è se ricevo suggerimenti su quale sistema è in esecuzione dietro l'SSO. Guardo le intestazioni di risposta di questa richiesta HTTP:

Fin qui tutto bene, niente di speciale.

E il codice sorgente della pagina di accesso?

Il prossimo passo è dare un'occhiata al codice sorgente della pagina di login. Ci sono indizi sul sistema utilizzato per l'SSO o vediamo qualcos'altro di strano?

Admin.js
Come possiamo vedere, la pagina di accesso sta caricando diversi file javascript, alcuni per aggiungere funzionalità al modulo di accesso. Nessuno dei file lascia trapelare suggerimenti sul sistema effettivo utilizzato, potrebbe essere che questo front-end SSO sia personalizzato; si tratta di un sistema back-end SSO basato su ASP.

Tuttavia uno dei file caricati ha attirato la mia attenzione: admin.js. Ogni volta che vediamo la parola 'admin' siamo ansiosi di saperne di più.

Parte del codice sorgente all'interno del admin.jsfile:

$scope.GetAdmin = function () {
        return $http({
            method: 'GET',
            url: '/api/v1/user/admin',
        }).then(function (response) {
            $scope.adminUser = response.data;
            if ($scope.adminUser.roles != null && $scope.adminUser.roles.length > 0) {
                var roles = $scope.adminUser.roles.split(",");
                $scope.permissions = {
                    admin_level_1: roles.indexOf("Admin_level_1") > -1,
                    admin_level_2: roles.indexOf("Admin_level_2") > -1,
                    allow_edit: roles.indexOf("Admin_allow_edit") > -1,
                    allow_merge: roles.indexOf("Admin_allow_merge") > -1,
                    allow_activate: roles.indexOf("Admin_allow_activate") > -1,
                    allow_deactivate: roles.indexOf("Admin_allow_deactivate") > -1,
                    allow_make_admin: roles.indexOf("Admin_level_1") > -1,
                    allow_deactivate_admin: roles.indexOf("Admin_level_1") > -1,
                    show_field_id: roles.indexOf("Admin_show_field_id") > -1,
                    show_field_firstname: roles.indexOf("Admin_show_field_firstname") > -1,
                    show_field_insertion: roles.indexOf("Admin_show_field_insertion") > -1,
                    show_field_lastname: roles.indexOf("Admin_show_field_lastname") > -1,
                    show_field_lhv_id: roles.indexOf("Admin_show_field_lhv_id") > -1,
                    show_field_nhg_id: roles.indexOf("Admin_show_field_nhg_id") > -1,
                    show_field_emailaddress: roles.indexOf("Admin_show_field_emailaddress") > -1,
                    show_field_cat_override: roles.indexOf("Admin_show_field_cat_override") > -1,
                    congres_admin: roles.indexOf("Admin_congres") > -1
                };
            }
        }).catch(function (response) {
            $scope.addMessage(response.data, response.status, response.status == 200 ? "success" : "error");
        });
    }
    
    $scope.GetAdmin();

Dato che sono uno dei medici di base con un accesso SSO, potrei accedere e raggiungere quell'endpoint.

L'endpoint non controlla correttamente chi lo richiede e restituisce tutte le nostre informazioni utente . Compresi e-mail, nome completo, hash della password e alcuni dettagli dell'iscrizione.

Cosa succede se raggiungiamo lo stesso endpoint e scambiamo /admincon un ID, come possiamo vedere ho l'ID 2027. Vediamo cosa succede se proviamo a premere ID 15000: https://hawebsso.nl/api/v1/user/15000

Ora abbiamo mostrato l'impatto di questo endpoint, fa trapelare tutti i dettagli utente delle persone iscritte al servizio SSO hawebsso.nl

In termini tecnici chiamiamo questo tipo di bug un IDOR ; Riferimenti a oggetti diretti non sicuri .

L'endpoint /api/v1/user/1è un endpoint generico che potrebbe essere facilmente scoperto dagli hacker. Si potrebbero usare elenchi di parole per forzare gli endpoint su una risorsa come questa, un buon esempio è Assetnote.io i loro elenchi di parole condivisi . La lista di parolehttps://wordlists-cdn.assetnote.io/data/automated/httparchive_apiroutes_2020_11_20.txtcontiene questo endpoint specifico con un ID che restituirebbe un hit.

Un altro approccio che l'hacker potrebbe adottare è eseguire la scansione di tutti i file javascript utilizzati per gli endpoint. Ad esempio LinkFinder fa questo per te.

Nessuna autenticazione richiesta
Ora abbiamo dimostrato che un endpoint specifico fa trapelare i dettagli dell'utente, tuttavia richiede l'autenticazione. È possibile raggiungere questo endpoint senza essere loggati?

La risposta è si. Questo endpoint non richiede alcun accesso. In termini tecnici ora abbiamo un altro bug, Missing Authentication for Critical Function . L'apertura dell'endpoint in un browser senza aver effettuato l'accesso ci restituisce tutti i dettagli dell'utente.

Hash della password, come romperlo?
Ora abbiamo l'hash della password. L'utilizzo degli hash delle password riduce l'impatto di una perdita di dati, poiché per recuperare la password è necessario prima rompere l'hash. In passato gli hash delle password come MD5 venivano facilmente violati usando qualcosa come Rainbow Tables ; elenchi di tutti i possibili hash, che vengono calcolati in anticipo per decifrare l'hash.

Al giorno d'oggi questo viene risolto utilizzando algoritmi di hashing più sicuri e includendo i sali.

Modificando la mia password con la stessa password che avevo, potrei confermare che viene generato un nuovo hash univoco. Qualcosa che ci dà un indizio sul fatto che le tabelle arcobaleno potrebbero non funzionare qui (ad esempio se includono un sale univoco per utente).

Per i test ho usato il seguente hash per decifrare (non preoccuparti, è il mio hash, con una password fittizia):em1EijmR7gmSA0NC2fbbl488pWDpX6YEfPtU4BNRsu01VX9VZFRuvSBAPaaIwVe5KC0enebMfwJC1AGZVNFbRsZ+7Pa7hj718HfKfIolp/5rDgsp/52UOqawXrNGHgwCHYsd+S0gG4K+ba3zjsjg5cVXCpIrqvlJbO45DkPqZ+B/REWhOmkBdRdie76z9oWk1qp7LFa9l/4Z3TtCgucS+m0Sl66mYcWwafRZkAas5a5z15v9iweiZK4WyEbkmUFQDgAqXMAsljftoJxSP0QN/BbXUtAm0wENIGvt7PPTg7dGxdUoySbUFpmnzm/eTeCcgbEpsJhb3bwAulMVl0F3

Dopo aver hackerato per un po', potresti identificare la maggior parte dei tipi di hashish semplicemente guardandolo, proprio come le malattie della pelle.

098f6bcd4621d373cade4e832627b4f6 - MD5
5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8 - SHA-256
$2y$12$xyq65gSoKygKl5kxKYDbjeTocAh8BcbuprbohD.kkX0PZr73pH5LC - Bcrypt

Tuttavia qui non ho la più pallida idea di quale algoritmo hash venga utilizzato. Dopo aver contattato uno dei miei colleghi hacker etici, mi è stato detto che sembrava una stringa codificata in base64 , decodificata è lunga esattamente 255 byte.

Sapendo dalla nostra ricognizione che ASP è in esecuzione sul server, potremmo ottenere ulteriori indizi dalla documentazione fornita da Microsoft:https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity

Successivamente ho trovato questo blog (vecchio di 5 anni) sui diversi algoritmi di hashinghttps://andrewlock.net/exploring-the-asp-net-core-identity-passwordhasher/e ho trovato interessante il seguente pezzo:ASP.NET Core Identity Version 3: PBKDF2 with HMAC-SHA256, 128-bit salt, 256-bit subkey, 10000 iterations

Questo mi dà un suggerimento che ASP utilizza, fuori dagli schemi, un algoritmo di hashing appropriato, uno che al momento non potrei decifrare facilmente. Alcune discussioni interessanti su PBKDF2 e sul futuro possono essere lette qui .

Per ora ho rinunciato a decifrare quegli hash.

Tuttavia mi piacerebbe saperne di più dai lettori di questo blog, sei in grado di decifrare il mio hashish? In tal caso, fammi sapere come lo faresti. Il primo a decifrarlo guadagnerà il mio raro adesivo glitterato e qualche altro gadget unico! Questo mondo è interamente dedicato agli adesivi, come sai.

Conclusione
Abbiamo trovato una fuga di dati che fa trapelare tutte le e-mail e gli hash delle password utilizzati dai medici di base nei Paesi Bassi. Questo endpoint non era protetto e non richiedeva alcuna autorizzazione. Poiché si tratta di un percorso generico, potrebbe essere facilmente individuato dagli hacker. Inoltre il riferimento a questo endpoint era nascosto nel admin.jsfile incluso nella pagina di login, strumenti come LinkFinder avrebbero informato qualsiasi hacker di scansione di questo specifico endpoint.

Discussione
L'LHV ha pubblicato una politica di divulgazione responsabile sul proprio sito web che mi ha permesso di fare questa ricerca:https://www.lhv.nl/cvd-coordinated-vulnerability-disclosure/Che è un ottimo esempio di come supportare gli hacker etici.

Inoltre cercano di migliorare la sicurezza generale nell'assistenza sanitaria primaria sviluppando linee guida su come gestire le fughe di dati . Recentemente ne hanno pubblicato su una delle riviste lette dai medici di base:https://www.syntheshis.nu/wp-content/uploads/2022/12/Synth-2022-03-Totaal.pdf(Olandese, pagina 22). I membri associati possono visualizzare questa linea guida:https://www.lhv.nl/product/praktijkwijzer-informatiebeveiliging/

Tuttavia sarebbe fantastico se tutti potessero accedere a questo documento , più condividiamo meglio siamo in grado di combattere i rischi. Nell'assistenza sanitaria di base lavoro con studenti, data manager e molte persone che non sono membri dell'LHV; se potessi condividere facilmente quei documenti che aiuterebbero (preferisco non condividere PDF obsoleti).

Un'altra cosa importante è aggiungere la politica di divulgazione responsabile su ogni risorsa online . Ad esempio hawebsso.nl non include alcun riferimento. Anche il sito web NHG.org (utilizzando l'SSO) non condivide alcuna politica di divulgazione responsabile online . Una buona cosa sarebbe pubblicare questa politica il prima possibile e mettere a proprio agio tutti coloro che lavorano in NHG con questa buona pratica; vederehttps://www.ncsc.nl/onderwerpen/cvd-beleid/cvd-beleid-opstellenper imparare come procedere come organizzazione.

Una buona protezione contro perdite di dati come queste è l'autenticazione a doppio fattore (2FA), HAwebsso.nl lo supporta, tuttavia non è attivato per impostazione predefinita. Il mio consiglio è di attivarlo per rendere più difficile agli aggressori l'accesso al tuo account ogni volta che la tua password viene trapelata. Inoltre è importante non riutilizzare le password, come mostrato in questo rapporto quando trapelate (e violate) potrebbero essere utilizzate in modo improprio su altri servizi; ripieno di credenziali .

Come potremmo evitare bug come questo?
Questo bug esiste da circa 3 anni, quindi è un sacco di tempo per scoprirlo.

Ci sono diversi modi per affrontare questa domanda. Uno è a livello di gestione; ottenere certificazioni e adottare standard di settore.

Standard di settore
Al giorno d'oggi abbiamo diversi standard di settore internazionali (ad es. ISO 27001 ) o nazionali (ad es. NEN 7510 ) che descrivono come gestire la sicurezza delle informazioni. Un ottimo modo per incorporare alcune buone pratiche di sicurezza delle informazioni nella tua organizzazione. Implementalo, chiedi a un revisore di conformarsi, tutto è implementato correttamente e il marketing può condividere la buona notizia che sei al sicuro.

"Signore, siamo certificati ISO 27001, siamo super sicuri" - Ogni reparto vendite

Come vedremo oggi, nessuna certificazione ti impedirà di essere hackerato. Tuttavia ciò non significa che non dovremmo farlo. Ogni modo strutturato per migliorare la sicurezza è qualcosa che vale la pena implementare.

Consulenti di pen test contro hacker etici
Un altro approccio consiste nell'eseguire regolarmente pen test; assumi un'azienda e chiedi loro di hackerarti. Questo bug è piuttosto semplice ed è probabile che venga rilevato in un test con penna.

Tuttavia, questi pen test si verificano spesso in periodi di tempo specifici, non è un processo continuo. Pertanto, eventuali nuovi bug nelle risorse rilasciati tra i pen test potrebbero passare inosservati.

Una soluzione potrebbe essere quella di creare una comunità di hacker etici, utilizzando piattaforme di bug bounty (come HackerOne o BugCrowd ) e iniziare a investire in hacker etici che trovano bug nelle tue risorse. Abbiamo alcuni grandi esempi di come creare comunità nei Paesi Bassi: Hack the Hague .

Modellazione delle minacce
Sono un grande fan del metodo INCLUDESNODIRT.com ; riunire un gruppo di persone (ad es. sviluppatore, hacker etico, medico di base, proprietario del prodotto e responsabile della privacy), compilare il questionario e fare brainstorming per 20 minuti. Ogni volta che introduci nuove risorse, aggiungi funzionalità a un'app o apporti modifiche alla tua organizzazione (ad es. fusioni e acquisizioni). In questo esempio ci si chiederebbe "La nuova funzionalità di amministrazione aggiunta a hawebsso.nl è adeguatamente protetta da accessi non autorizzati? Se sì, spiega come.”

Non ho ancora visto il metodo utilizzato nella produzione, tuttavia mi piacerebbe ascoltare le storie di altri che lo hanno già implementato. Cosa potremmo imparare da esso e funziona davvero?

La trasparenza è fiducia
Dall'inizio fino alla fine di questa specifica segnalazione di bug, il responsabile della privacy di LHV è stato molto attento alle mie e-mail. Mi ha spesso inviato aggiornamenti che mi aiutano ad avere la certezza che l'impatto del bug sia compreso da tutte le parti interessate e che venga risolto rapidamente. Ha fatto un ottimo lavoro ed è un esempio per gli altri su come gestire un rapporto come questo, grazie!

In ogni organizzazione la trasparenza è fiducia. Se si tratta di perdite di dati, abbiamo buoni diagrammi di flusso che ci aiutano a procedere e ad informare in modo trasparente gli utenti finali (come poter pubblicare blog come questo).

Questo rapporto mostra il potere della folla, la trasparenza e un'adeguata politica di divulgazione consente a tutti gli hacker etici del mondo di aiutarti a diventare più sicuro. Puoi applicare questo modello di folla a tutti gli altri livelli della tua organizzazione e raggiungere i tuoi obiettivi più rapidamente.

Alla fine vogliamo tutti domani un'assistenza sanitaria di base migliore e più sicura e impariamo dagli errori commessi in passato.

Sequenza temporale
04–12–2022 — Rilevato il bug, segnalato al responsabile della privacy di LHV via e-mail
05–12–2022 — Risposta del responsabile della privacy per confermare il bug
06–12–2022 — Aggiornamento del responsabile della privacy
08–12–2022 — Aggiornamento dal responsabile della privacy: il bug esiste da 3 anni (dalla fine del 2019), nessun segno di abuso nei registri degli ultimi 2 anni
11–12–2022 — Ha scritto questo blog
12–12–2022 — Ha inviato la bozza di questo blog a responsabile della privacy via e-mail
12-12-2022 — LHV e NHG hanno informato tutti i membri della fuga di dati via e-mail; ha chiesto ai membri di reimpostare la propria password.
13–12–2022 — LHV ha suggerito alcune modifiche minori
14–12–2022 — Blog pubblicato