News Security Migliaia di server Apache Superset esposti ad attacchi di Remote Code Execution

Sono state trovate su Apache Superset due diverse vulnerabilità (authentication bypass and remote code execution) a causa dell'utilizzo delle configurazioni predefinite del prodotto, consentendo ad eventuali attaccanti di accedere e modificare dati, raccogliere credenziali ed eseguire i comandi arbitrari.​

Migliaia di server Apache Superset esposti ad attacchi di Remote Code Execution​

Apache Superset è uno strumento open-source per la visualizzazione e l'esplorazione dei dati, inizialmente sviluppato per Airbnb e successivamente divenuto un progetto di punta della Apache Software Foundation, nel 2021.

Horizon3, durante alcuni controlli di sicurezza, ha notato che il prodotto utilizza una Flask Secret Key di default per firmare i cookie di autenticazione (CVE-2023-27524). Di conseguenza, gli attaccanti possono utilizzare questa chiave predefinita per falsificare dei cookie di sessione ed accedere quindi con privilegi di amministratore ai server che non hanno modificato la chiave - circa 2.124 (il 67% del totale) secondo le stime di Horizon3.​

Sebbene la documentazione di Apache indichi agli amministratori di modificare le chiavi segrete, Horizon3 afferma che questa pericolosa configurazione predefinita è attualmente rilevabile in numerosi server esposti su Internet, tra cui università, aziende di varie dimensioni, organizzazioni governative e altro ancora.​

È importante dire, anche se scontato, che se gli amministratori hanno cambiato la chiave predefinita con una sconosciuta, le loro installazioni non sono vulnerabili a questo attacco.

La vulnerabilità è stata scoperta e comunicata da Horizon3 l'11 Ottobre 2021. L'11 gennaio 2022, gli sviluppatori del software hanno rilasciato la versione 1.4.1 del prodotto, che ha cambiato la SECRET_KEY predefinita con una nuova stringa ed è stato inoltre aggiunto un messaggio di log quando la stringa predefinita viene rilevata all'avvio dell'applicazione.​

A seguito di ulteriori notifiche e segnalazioni, il 5 Aprile 2023 è stata rilasciata la versione 2.1 dove non viene consentito al server di avviarsi se questo utilizza una SECRET_KEY predefinita.​

fix: refuse to start with default secret on non debug envs by dpgaspar · Pull Request #23186 · apache/superset

SUMMARY Impose harsher measures when a default SECRET_KEY is identified. On non development environments on Flask debug mode Superset will refuse to start BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF ...

github.com

​

Conclusioni​

Il problema delle chiavi segrete hardcoded di Flask non è nuovo. Apache Airflow, un progetto gemello di Superset, era affetto da un problema simile, classificato come CVE-2020-17526, in cui metodo di aggiramento dell'autenticazione è praticamente lo stesso descritto sopra, poiché sia Airflow che Superset sono basati sullo stesso framework comune, Flask AppBuilder. Una vulnerabilità simile (CVE-2021-41192) è stata identificata anche in Redash, un altro strumento open source di visualizzazione dei dati basato su Flask.

È cosa nota che gli utenti non leggano la documentazione e che le applicazioni debbano essere progettate in modo da costringere i devs a seguire un percorso in cui non hanno abbiano altra scelta che la sicurezza by default. Sappiamo tutti che le credenziali e le chiavi predefinite sono un male, ma quanto lo sono davvero? Nel caso di Superset, l'impatto dell'utilizzare una chiave predefinita insicura si estende a circa 2/3 di tutti gli utenti. Ancora una volta, abbiamo la dimostrazione che gli utenti non leggono la documentazione. E nemmeno i log, a dirla tutta.

L'approccio migliore è, quindi, quello di togliere la scelta agli utenti e richiedere loro di intraprendere azioni deliberate per essere volutamente insicuri.​

---

​

Fonti:​

• https://www.bleepingcomputer.com/ne...ache-superset-servers-exposed-to-rce-attacks/
• https://www.horizon3.ai/cve-2023-27...ache-superset-leads-to-remote-code-execution/
• Horizon3 Vuln Check/Exploit Script
• Configuring Superset
• Apache Superset on GitHub
• Flask Unsign Toolkit
• Apache Superset Pull Request to not Start Server if Running with default SECRET_KEY
• Flask Configuration Handling: SECRET_KEY
• Superset Deployment Template
• CVE-2023-27524: Superset Session Validation Vulnerability When Using Provided SECRET_KEY
• CVE-2020-17526: Airflow Authentication Bypass Misconfiguration
• CVE-2021-41192: Redash Authentication Bypass Misconfiguration

---

Made with ❤ for Inforge​

---

 

[--- Ra ---]

Arrivati a questo punto, come è stato già fatto, credo anch'io che sia necessario vincolare l'utente a rispettare meccanismi di sicurezza obbligati, altrimenti l'utilizzatore, di per sé, non lo farà mai. @0xbro, potrebbe essere una soluzione valida impostare all'avvio del server un meccanismo di generazione/crittografia automatico della chiave segreta? Non sarebbe meglio questo piuttosto che impedire l'avvio del server?

 

[0xbro]

potrebbe essere una soluzione valida impostare all'avvio del server un meccanismo di generazione/crittografia automatico della chiave segreta? Non sarebbe meglio questo piuttosto che impedire l'avvio del server?

Così su due piedi ti direi di sì, e non riesco a capire come mai non sia una scelta di default adottata in tutti quei casi in cui si debba hardcodare qualche segreto nelle configurazioni. Sicuramente, fossi nei devs, bloccherei l'esecuzione del programma costringendo alla modifica della chiave, però anche implementare un automatismo che generi una chiave randomica sicura sarebbe una buona scelta (secondo me).

Forse non si genera la chiave randomicamente per evitare di avere responsabilità in caso di generazione di una chiave poco sicura? Proprio non so

 

[--- Ra ---]

Forse non si genera la chiave randomicamente per evitare di avere responsabilità in caso di generazione di una chiave poco sicura? Proprio non so

Mh...non credo...forse sarà legato a qualche motivo strettamente tecnico del server che solo gli sviluppatori conoscono. In fondo di strumenti sicuri per fare la crittografia ce ne sono in giro tipo openssl, GnuPG ecc.