Rapporto sui test di penetrazione per lo scambio centralizzato

Sommario di gestione

Il team di Exchange centralizzato ha contattato Sayfer per eseguire test di penetrazione blackbox completi sulla loro applicazione Web e revisione whitebox per la loro architettura crittografica nel dicembre 2021.

Prima di valutare i servizi di cui sopra, abbiamo tenuto una riunione iniziale con il team tecnico di Centralized Exchange e abbiamo ricevuto una panoramica del sistema e degli obiettivi di questa ricerca.

Durante il periodo di ricerca di 4 settimane, abbiamo scoperto 10 vulnerabilità nel sistema. Le vulnerabilità più pericolose erano SQL injection e difetti nella logica aziendale.

L'impatto sul sistema è critico in quanto un utente malintenzionato potrebbe sfruttare alcune di queste vulnerabilità per sfruttare il sistema, modificando il proprio ruolo utente in "super_user" tramite l'iniezione SQL o abusando del sistema e rubando denaro dall'Exchange centralizzato utilizzando il meccanismo di aggiornamento del sistema degli anni '30.

Metodologia di valutazione della sicurezza

Sayfer utilizza OWASP WSTG come nostro standard tecnico durante la revisione delle applicazioni web. Dopo aver acquisito una conoscenza approfondita del sistema, abbiamo deciso quali test OWASP sono necessari per valutare il sistema.

Risultati della valutazione della sicurezza

Salvataggio non sicuro delle chiavi MPC private

Descrizione

Gli scambi centralizzati soffrono di pratiche di gestione delle chiavi di bassa qualità. Ci sono molti esempi di tali casi in cui le chiavi sono state perse o rubate causando la perdita di tutti i fondi del portafoglio da parte del servizio o il blocco completo dei fondi.

Durante il controllo dei file di configurazione, abbiamo esaminato l'archiviazione di gestione delle chiavi. Abbiamo scoperto che le chiavi utilizzate per il cold wallet multi-sig non sono archiviate in luoghi sufficientemente distribuiti.

Ci sono 3 chiavi che vengono utilizzate all'interno della firma della chiave MPC. 1 è memorizzato in una macchina fisica protetta. Gli altri 2 sono archiviati all'interno della stessa macchina dedicata in GCP.

Sono state prese un paio di misure di sicurezza per proteggere queste macchine, ma il problema si basa sulla distribuzione, se la macchina distribuita su GCP viene compromessa, un utente malintenzionato può firmare qualsiasi transazione dal portafoglio freddo.

Questo è un luogo ad alto rischio e delicato in cui molti hanno fallito in passato, le migliori pratiche dovrebbero essere seguite rigorosamente.

Mitigazione

Utilizza il servizio di custodia di terze parti per gestire gli hot wallet e le casseforti. Saremo lieti di consigliare uno dei nostri partner.

Questi servizi gestiscono MPC e la gestione delle chiavi per te, con altri livelli di sicurezza aggiunti che rendono l'uso di tali servizi la scelta migliore per gli scambi centralizzati.

SQL Injection

Descrizione

Un attacco SQL injection consiste nell'inserire o "iniettare" una query SQL parziale o completa nell'input di dati che viene trasmesso dal client all'applicazione web. Un attacco SQL injection riuscito può leggere dati sensibili dal database, modificare i dati del database (inserimento/aggiornamento/cancellazione), eseguire operazioni di amministrazione del database (come l'arresto del DBMS), ripristinare il contenuto di un determinato file sul file system DBMS o scrivere file nel file system e, in alcuni casi, inviare comandi al sistema operativo.

Usando il transaction endpoint siamo stati in grado di abusare del more Parametro di query URL per iniettare payload SQL dannoso:

/api/transactions?size=10&more=te');INJECTION_PAYLOAD

Il payload che abbiamo utilizzato è stato:

/api/transactions?size=10&sort=time,DESC&more=te');SELECT+CASE+WHEN+(substring(versio n(),12,2)+%3d+'10')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END%3b – Che in questo caso controlla se l'istanza in esecuzione di Postgres è la versione 10 o meno.

Un utente malintenzionato che sfrutta questa vulnerabilità potrebbe assumere il controllo del sistema. Siamo stati in grado di estrarre gli schemi delle tabelle, aggiornare il ruolo del nostro utente o scaricare qualsiasi informazione salvata sul DB e persino modificare il saldo del nostro utente sul DB.

Mitigazione

La vulnerabilità SQL injection è facile da correggere ma difficile da mitigare. Sono necessari un forte linting o l'implementazione di regole di compilazione che impongono modifiche future.

La mitigazione delle vulnerabilità di SQL injection viene in genere eseguita seguendo un framework di scelta, il che significa che lo sviluppatore non dovrebbe mai concatenare le stringhe in un'istruzione SQL completa.

Ogni input dell'utente dovrebbe essere disinfettato in un esecutore SQL anziché essere utilizzato come una semplice stringa di query SQL.

Per ulteriori informazioni sulla perfezione dell'iniezione SQL, fare riferimento a SQL ICheatSheet per la prevenzione delle iniezioni.

Riferimenti di oggetti diretti non sicuri

Descrizione

I riferimenti a oggetti diretti insicuri (IDOR) sono un tipo di vulnerabilità del controllo degli accessi che si verifica quando un'applicazione utilizza l'input fornito dall'utente per accedere direttamente agli oggetti. Come risultato di questa vulnerabilità, gli aggressori possono aggirare l'autorizzazione e accedere direttamente alle risorse nel sistema, ad esempio record di database o file.

Abbiamo scoperto che l'API █████████ consente a un utente malintenzionato di visualizzare le informazioni della dashboard di altri utenti, inclusi tutti i dati finanziari di questo utente.
La vulnerabilità si basa sul parametro id dashboard che è un numero intero indovinabile. Esempio di richiesta per un singolo dashboard (per un dashboard che non è di proprietà dell'utente corrente):

GET ████/dashboard/827371 HTTP/1.1

Host: ██████████████████

api-key: ██████████
…

Ciò indica che il /dashboard/DASHBOARD_ID l'endpoint non controlla l'autorizzazione per la risorsa richiesta. Un utente malintenzionato autenticato potrebbe eseguire lo scraping di ogni singola dashboard che contiene informazioni sui fondi dell'utente e sulle transazioni passate.

Mitigazione

Esistono diversi modi per mitigare le vulnerabilità IDOR, in questo caso sembra che la soluzione potrebbe essere quella di verificare l'autorizzazione per ogni singola richiesta.

Ciò significa che ogni chiave di richiesta sarà in grado di recuperare solo i dashboard del proprio account

Autenticazione più debole nel canale alternativo

Descrizione

Anche se i meccanismi di autenticazione primari non includono alcuna vulnerabilità, è possibile che esistano vulnerabilità in canali utente di autenticazione legittimi alternativi per gli stessi account utente.

Questa vulnerabilità fa parte di una catena di 2 vulnerabilità che ci ha permesso di prendere il controllo di qualsiasi account con solo un indirizzo email.

Come parte della nostra fase di ricognizione in cui proviamo a trovare un vettore di attacco più ampio enumerando i principali sottosistemi bersaglio, abbiamo trovato un'interfaccia di amministrazione sotto il sottodominio ██████████████████. È possibile accedere all'interfaccia di amministrazione utilizzando un normale utente dell'app, ma per quasi tutte le richieste di rete che abbiamo ispezionato durante il caricamento della pagina principale, il server restituisce un errore 401.

[IMAGE_REDATTO]

Abbiamo decodificato il file bundle main.js che contiene il codice front-end per l'app e abbiamo trovato tutti i potenziali endpoint con cui un amministratore può interagire.

Potremmo sfruttare solo l'endpoint di api/updateUser. L'endpoint ci ha consentito di modificare qualsiasi e-mail dell'utente e, così facendo, siamo stati in grado di reimpostare la password della vittima e assumere il controllo dell'account

[IMAGE_REDATTO]

Mitigazione

Si consiglia vivamente di realizzare un meccanismo di autenticazione o una VPN per il debug o per i servizi amministrativi del sistema per prevenire la presenza di applicazioni pubbliche non sicure che possono essere sfruttate da un utente malintenzionato.

Inoltre, esiste un meccanismo di autorizzazione nell'interfaccia di amministrazione, ma questo non rientra nell'ambito di questo progetto.

Esamina i metafile del server Web per perdite di informazioni

Descrizione

Come parte della nostra ricerca sull'obiettivo e sui suoi sottodomini, abbiamo trovato alcuni metafile che non dovrebbero essere pubblici, o almeno non senza l'appropriato meccanismo di autenticazione.

• ████████████████████████.gitignore
• ██████████████████████████████/docker-compose.yml
• ████████████████████████/swagger-ui.html

[IMAGE_REDATTO]

[IMAGE_REDATTO]

[IMAGE_REDATTO]

Abbiamo trovato tre tipi di file che potrebbero danneggiare i servizi ████████, .gitignore, swagger-ui e la docker-compose.yml file. Questi tre file rivelano dati sensibili

sull'architettura del servizio. Un attore malintenzionato può utilizzare queste informazioni per aumentare il suo vettore di attacco sul bersaglio.

Mitigazione

Se possibile, rimuovere questi file dal servizio pubblico o implementare un meccanismo di autorizzazione che garantisca l'accesso solo agli utenti privilegiati.

Intestazione del criterio di sicurezza dei contenuti mancante

Descrizione

Content Security Policy (CSP) è un ulteriore livello di sicurezza che consente di rilevare e mitigare determinati tipi di attacchi, tra cui Cross-Site Scripting (XSS) e attacchi di data injection.

Non abbiamo trovato un'intestazione CSP in nessuna delle risposte del server.

[IMAGE_REDATTO]

Utilizzando CSP gli amministratori di siti Web aggiungono un'altra linea di difesa contro XSS o attacchi di clickjacking, in questo modo il sistema sarà sicuro anche se future modifiche non garantite verranno apportate al codice sorgente.

Un criterio CSP di base dovrebbe almeno descrivere i domini predefiniti nella whitelist per i file statici (come script, immagini e CSS). E frame-ancestors per prevenire attacchi di click-jacking.

Ulteriori informazioni:

1. https://cspvalidator.org/
2. https://csp-evaluator.withgoogle.com/

Mitigazione

Aggiungere il Content-Security-Policy: [policy] su ogni risposta in cui il caricamento di risorse esterne potrebbe essere pericoloso

Consigliamo vivamente di utilizzarlo e testarlo prima con la variante "Solo report" per testare la policy prima di rilasciarla in produzione:

Content-Security-Policy-Report-Only: [policy]

Test per le intestazioni di sicurezza

Descrizione

1. I browser supportano molte intestazioni HTTP che possono migliorare la sicurezza delle applicazioni per proteggersi da una varietà di attacchi comuni, le intestazioni vengono scambiate tra un client Web (di solito un browser) e un server per specificare i dettagli relativi alla sicurezza della comunicazione HTTP.

Guardando le intestazioni di sicurezza di ████████, mancano le seguenti informazioni:

• X-Content-Type-Opzioni

L'impostazione di questa intestazione impedirà al browser di interpretare i file come qualcosa di diverso da quanto dichiarato dal tipo di contenuto nelle intestazioni HTTP.

• Strict-Transport-Security

HSTS è un meccanismo di politica di sicurezza Web che aiuta a proteggere i siti Web da attacchi di downgrade del protocollo e dirottamento dei cookie. Consente ai server Web di dichiarare che i browser Web devono interagire con esso solo utilizzando connessioni HTTPS sicure e mai tramite il protocollo HTTP non sicuro.

• Referrer-Politica

L'intestazione Referer è un'intestazione della richiesta che indica il sito da cui ha avuto origine il traffico. Se non è in atto una prevenzione adeguata, l'URL stesso e persino le informazioni sensibili contenute nell'URL verranno divulgate al sito di origine incrociata.

• Accesso-Controllo-Consenti-Origine

L'intestazione ha il valore di "*" che espone l'API per ogni sito Web, questo potrebbe non essere il risultato desiderato.

Mitigazione

Aggiunta delle intestazioni sopra menzionate a tutti i servizi di back-end.

Esamina i metafile del server Web per perdite di informazioni

Descrizione

Durante la ricerca del target con DevTool siamo stati in grado di visualizzare il codice sorgente del frontend senza alcun offuscamento. Questa vulnerabilità si verifica perché i bundle JS vengono forniti con sourcemaps alla produzione, che consentono di leggere il codice sorgente originale con commenti che potrebbero rivelare informazioni, ad esempio il seguente file path.ts:

█████████████████████/paths.ts [IMAGE_REDACTED]

Avendo la mappa dei sorgenti, un utente malintenzionato può conoscere la base di codice, leggere commenti e trovare parti di codice obsolete che in seguito possono essere utilizzate per trovare vulnerabilità.

Mitigazione

Non spedire le mappe di origine alla produzione, la maggior parte dei sistemi di registrazione e di tracciamento degli errori ha l'opinione di caricare le mappe di origine in un sistema di back-office. Un altro approccio sarebbe quello di servire le mappe di origine solo agli utenti autenticati tramite VPN o altri meccanismi.

Server web di impronte digitali

Descrizione

Anche se le informazioni sui server esposti di per sé non sono necessariamente una vulnerabilità, sono informazioni che possono aiutare gli aggressori a sfruttare altre vulnerabilità che possono esistere. La maggior parte degli endpoint non rivela alcuna informazione sul server tramite intestazioni HTTP o pagine di errore.
Utilizzando la seguente richiesta HTTP non corretta siamo stati in grado di rilevare un server Nginx tramite una risposta 400
GET /v2 HTTPMALFORMED/1.1
Host: ██████████████████
Accept: */*

Il corpo di risposta è:
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx 1.14.0</center>
</body>
</html>

Mitigazione

Esistono diversi modi per oscurare le intestazioni del server Web, i metodi più comunemente utilizzati sono:

1. Server proxy inverso che si frappongono tra l'Internet globale e l'interno
2. Configura ogni server Web per eliminare queste intestazioni.

Appendice A: correzioni per la valutazione della sicurezza

Verrà aggiornato dal team Sayfer dopo la prima revisione.