Rapporto sulla risposta agli incidenti di sicurezza: vulnerabilità di tipo SQL injection

Panoramica sulla vulnerabilità

‍

Tipo di vulnerabilità: SQL Injection
Data di segnalazione: 10 marzo 2025
Stato: Risolta e corretta
Metodo di divulgazione: Divulgazione responsabile da parte di Searchlight Cyber/Asset Note

‍

Versioni contenenti la risoluzione

Versione stabile
2.174.94 (o qualsiasi versione che inizi con 2.174 e finisca con un numero superiore a 94 – ad esempio 2.174.103)
Versione candidata
2.184.23 (o qualsiasi versione che inizi con 2.184 e finisca con un numero superiore a 23 – ad esempio 2.184.35)
Versione beta
2.186.2 (o qualsiasi versione che inizi con 2 e sia seguita da un numero maggiore di 186 – ad esempio 2.187.1)

‍

Ambito e analisi delle cause alla radice

La vulnerabilità consentiva un attacco di tipo SQL injection su un endpoint non autenticato tramite un payload appositamente creato. È stata condotta un’analisi completa delle cause alla radice, dalla quale è emerso che la vulnerabilità era stata introdotta nella versione 2.11.13, rilasciata il 12 giugno 2020. Nonostante fossero state effettuate numerose valutazioni di penetrazione sia interne che da parte di terzi, il problema è rimasto inosservato a causa della natura complessa del payload richiesto. Ciò ha ridotto significativamente la possibilità di exploit o di compromissione dei dati.

Vale la pena sottolineare che questa vulnerabilità è stata introdotta nel 2020 e che, da allora, le nostre pratiche di sviluppo interne sono notevolmente migliorate. Inoltre, nel corso della ricerca non sono state individuate altre vulnerabilità di questo tipo.

‍

Esposizione dei dati e impatto

È stata condotta un'indagine sui log di Azure Application Insights e AWS WAF relativi ai clienti cloud/hosted. Da tale analisi non è emersa alcuna compromissione dei dati dei clienti . L'analisi suggerisce che lo sfruttamento di tale vulnerabilità richiederebbe un elevato grado di specificità, limitando così la probabilità di un abuso diffuso e riuscito.

‍

Cronologia delle attività di individuazione e bonifica

• Data di introduzione: 12 giugno 2020 (v2.11.13)

• Data di segnalazione: 10 marzo 2025

• Patch distribuita: lo stesso giorno per tutti i clienti in hosting (10 marzo 2025)

• Tempo di risposta: distribuzione immediata della patch al ricevimento della notifica

Searchlight Cyber/Asset Note ha pubblicato i propri risultati prima del previsto, lasciando alcuni clienti con soluzioni on-premise esposti al rischio per un breve periodo di tempo.

Abbiamo aiutato alcuni di questi clienti a condurre indagini volte a individuare prove di violazioni o attacchi, ma finora non ne abbiamo riscontrate.

‍

Frequenza e copertura

Ogni anno effettuiamo test completi di autenticazione e di penetrazione delle API tramite una società di sicurezza esterna accreditata CREST, al fine di garantire valutazioni indipendenti e di alta qualità. Oltre a queste verifiche esterne, prima di ogni rilascio trimestrale della versione stabile vengono eseguiti test di penetrazione interni, che ci consentono di identificare e risolvere in modo proattivo potenziali vulnerabilità all’interno del nostro ciclo di sviluppo.

‍

Metodologia di prova

Il nostro processo di test di penetrazione comprende sia test con autenticazione che senza autenticazione, al fine di garantire una copertura completa a tutti i livelli di accesso. Queste valutazioni vengono condotte da un gruppo composto da team di sicurezza interni e specialisti esterni, garantendo così una valutazione completa dei nostri sistemi da molteplici prospettive.

‍

Ultima valutazione della sicurezza (test di penetrazione)

Il 10 gennaio 2025 è stato completato un test di penetrazione approfondito. La sintesi gestionale contenuta nel rapporto è disponibile e può essere condivisa su richiesta per garantire una maggiore trasparenza.

‍

Standard di codifica e formazione degli sviluppatori

Tutti gli sviluppatori di Halo ricevono una formazione sugli standard di programmazione sicura e seguono le migliori pratiche riconosciute dal settore, comprese quelle delineate dall’OWASP. Questa formazione viene aggiornata periodicamente per garantire l’allineamento con le minacce più recenti e le tecniche di mitigazione.

‍

Revisione del codice e automazione

Tutte le modifiche al codice sono sottoposte a un rigoroso processo di approvazione in più fasi che prevede la revisione da parte di un membro senior del team di sicurezza, incaricato specificatamente di valutare i potenziali rischi per la sicurezza. Inoltre, utilizziamo strumenti di test statici di sicurezza delle applicazioni (SAST) durante l'intero processo di sviluppo, consentendo l'individuazione tempestiva delle vulnerabilità e promuovendo pratiche di programmazione sicure sin dall'inizio.

‍

Gestione della superficie di attacco

Sebbene non sia possibile ridurre il numero di endpoint API a causa di requisiti funzionali essenziali — come la necessità di accettare le risposte dei webhook — la nostra priorità rimane quella di mantenere e rafforzare costantemente il nostro livello complessivo di sicurezza. Abbiamo già condotto valutazioni rigorose degli endpoint non autenticati nell’ambito delle nostre prassi di sicurezza regolari; per questo motivo, nonostante la presenza di numerosi endpoint non autenticati, la recente revisione non ha individuato ulteriori vulnerabilità. Questi endpoint vengono attentamente valutati e monitorati e utilizzati solo quando assolutamente necessario, al fine di ridurre al minimo i rischi.

‍

Segmentazione delle infrastrutture

Nei nostri ambienti in hosting, la separazione funzionale viene applicata a tutti i componenti chiave — tra cui l’API, i servizi di autenticazione e quelli di integrazione — per ridurre il rischio di movimento laterale in caso di violazione. Inoltre, i database e i server di database sono isolati dai livelli applicativi e tutti i dati crittografati vengono decrittografati esclusivamente dall’API e dai servizi di autenticazione, garantendo una netta separazione tra l’archiviazione dei dati e i meccanismi di accesso.

‍

Convalida dell'efficacia

Per rafforzare il nostro quadro di sicurezza complessivo, stiamo avvalendoci della collaborazione di diverse società di sicurezza esterne affinché garantiscano un controllo aggiuntivo e una verifica indipendente dei nostri sistemi. Parallelamente, stiamo ampliando e potenziando i nostri controlli di sicurezza interni per garantire una copertura più ampia, un’analisi più approfondita e un miglioramento continuo in tutte le fasi dello sviluppo e dell’implementazione.

‍

Comunicazioni sulla sicurezza

Riconosciamo che alcuni clienti siano venuti a conoscenza di questa vulnerabilità tramite una pubblicazione di ricerca sulla sicurezza di una terza parte, prima di ricevere una comunicazione diretta da Halo. Ciò è dovuto in parte alla tempistica inaspettata della pubblicazione del rapporto esterno, avvenuta mentre stavamo ancora fornendo supporto attivo ai clienti on-premise nel loro processo di aggiornamento.

Riconosciamo l’importanza di una comunicazione proattiva e tempestiva e, di conseguenza, abbiamo adottato misure volte a migliorare le nostre procedure interne. In futuro, garantiremo che tutti i clienti che utilizzano i nostri servizi in hosting ricevano tempestivamente una notifica non appena verrà applicata una patch, indipendentemente dallo stato delle implementazioni in loco.

‍