I database moderni memorizzano tutti i tipi di dati. Da banale a altamente sensibile. I ristoranti che frequentiamo, le nostre posizioni sulla mappa, le nostre credenziali di identità (ad es. Numeri di previdenza sociale, indirizzi, cartelle cliniche, informazioni bancarie, ecc.) e tutto il resto è molto probabilmente archiviato in un database da qualche parte. Non c'è da stupirsi che i dati siano così preziosi.
Le tecnologie di database avanzano a un ritmo vertiginoso. Innovazione, progresso, integrità e miglioramenti abbondano sono in prima linea come risultato diretto del lavoro di ingegneri, sviluppatori e comunità solide intelligenti e devoti che supportano questi fornitori.
Eppure c'è un altro lato della medaglia. Che, sfortunatamente, coesiste all'interno di questo mondo basato sui dati sotto forma di malware, virus ed exploit su una scala enorme e di tutti i tempi.
I dati sono preziosi anche per le parti su quel lato dell'operazione. Ma per ragioni diverse. Ognuno di loro potrebbe essere, ma non è limitato a, potere, ricatto, guadagno e accesso finanziario, controllo, divertimento, scherzi, malizia, furto, vendetta... Hai capito. L'elenco è infinito.
Purtroppo, dobbiamo operare con una mentalità di sicurezza. Senza questa mentalità, lasciamo i nostri sistemi vulnerabili a questi tipi di attacchi. PostgreSQL è suscettibile di compromissione, uso improprio, furto, accesso/controllo non autorizzato come altre forme di software.
Quindi quali misure possiamo adottare per mitigare il numero di rischi per le nostre installazioni PostgreSQL?
Sento fortemente che promuovere la consapevolezza di quali sono le minacce conosciute là fuori sia un buon punto di partenza come qualsiasi altro. La conoscenza è potere e dovremmo usare tutto ciò che abbiamo a nostra disposizione. Inoltre, come possiamo sorvegliare ciò di cui non siamo nemmeno a conoscenza per rafforzare la sicurezza su quelle istanze PostgreSQL e proteggere i dati che risiedono lì?
Di recente ho cercato "preoccupazioni" e "minacce" di sicurezza note, mirate all'ambiente PostgreSQL. La mia ricerca comprendeva rapporti, articoli e post di blog recenti nel primo trimestre del 2018. Oltre a quel periodo di tempo specifico, ho esplorato noti problemi di lunga data che sono ancora minacce praticabili oggi (vale a dire SQL Injection), sebbene non rifiniti o marchiato come "scoperto di recente". '.
Un'opportunità fotografica
Un tuffo in profondità negli attacchi al database [Parte III]:perché la foto di Scarlett Johansson ha ottenuto il mio database Postgres per iniziare a estrarre Monero
La notizia di questo astuto attacco malware ha restituito il maggior numero di "hit" dai miei risultati di ricerca oggettivi.
Visiteremo uno dei tanti fantastici post del blog e una carrellata del suo contenuto. Ho anche incluso ulteriori post del blog verso la fine di questa sezione, quindi assicurati di visitare anche quelli che descrivono in dettaglio questa intrusione.
Osservazioni
Le informazioni di Imperva riportano che il loro database honeypot (StickyDB) ha scoperto un attacco malware su uno dei loro server PostgreSQL. Honeypot net, come Imperva chiama il sistema, è progettata per indurre gli aggressori ad attaccare il database in modo che loro (Imperva) possano conoscerlo e diventare più sicuri. In questo caso particolare, il payload è un malware che cripta Monero, incorporato in una foto di Scarlett Johansson.
Il carico utile viene scaricato su disco in fase di esecuzione con la funzione lo_export. Ma a quanto pare, questo accade perché lo_export è una voce in pg_proc rispetto alla normale chiamata diretta (lo_export).
Dettagli interessanti direttamente dal post del blog qui per estrema chiarezza (vedi articolo citato),
Ora l'attaccante è in grado di eseguire comandi di sistema locali utilizzando una semplice funzione:fun6440002537. Questa funzione SQL è un wrapper per chiamare una funzione del linguaggio C, "sys_eval", una piccola funzione esportata in "tmp406001440" (un binario basato su sqlmapproject), che fondamentalmente funge da proxy per invocare i comandi della shell dal client SQL.
Quindi quali saranno i prossimi passi dell'attacco? Qualche ricognizione. Quindi è iniziato con l'ottenere i dettagli della GPU eseguendo lshw -c video e ha continuato a cat /proc/cpuinfo per ottenere i dettagli della CPU (Figure 3-4). Anche se all'inizio sembra strano, ha perfettamente senso quando il tuo obiettivo finale è estrarre più della tua criptovaluta preferita, giusto?
Con una combinazione di accesso al database e la possibilità di eseguire codice in remoto, il tutto mentre "volando sotto il radar ' di soluzioni di monitoraggio, l'intruso scarica quindi il carico utile tramite una foto di Scarlett Johansson.
(Nota:da allora la foto è stata rimossa dalla sua posizione ospitata. Vedi l'articolo di collegamento per la menzione.)
Secondo il rapporto, il carico utile è in formato binario. Quel codice binario è stato aggiunto alla foto per passare per una foto reale durante il caricamento, consentendo un'immagine visualizzabile.
Vedere la Figura 6 del post per l'SQL responsabile dell'utilizzo di wget, dd e dell'esecuzione di chmod per i permessi sul file scaricato. Quel file scaricato crea quindi un altro eseguibile che è responsabile dell'estrazione di Monero. Naturalmente, dopo tutto questo lavoro nefasto sono necessarie pulizie e pulizie.
La figura 7 mostra l'esecuzione SQL.
Imperva consiglia di monitorare questo elenco di potenziali aree di violazione nella sezione di chiusura:
- Fai attenzione alle chiamate PostgreSQL dirette a lo_export o alle chiamate indirette tramite voci in pg_proc.
- Attenzione alle funzioni PostgreSQL che chiamano binari in linguaggio C.
- Utilizza un firewall per bloccare il traffico di rete in uscita dal tuo database a Internet.
- Assicurati che al tuo database non sia assegnato un indirizzo IP pubblico. In tal caso, limitare l'accesso solo agli host che interagiscono con esso (server delle applicazioni o client di proprietà dei DBA).
Imperva ha anche eseguito vari test antivirus insieme a dettagli su come gli aggressori possono potenzialmente individuare i server PostgreSQL vulnerabili. Sebbene non li abbia inclusi qui per brevità, consulta l'articolo per tutti i dettagli sui loro risultati.
Lettura consigliata
- Imperva ha 2 articoli precedenti che accompagnano la Parte 3 (quella discussa qui). Anche se quelli non prendono di mira PostgreSQL come quello che abbiamo appena sorvolato, sono letture altamente informative:
- Parte 1
- Parte 2
- L'attacco malware PostgreSQL di Scarlett Johansson
- Gli hacker prendono di mira i DB PostgreSQL con Coinminer nascosto nell'immagine di Scarlett Johannsson
- Un thread di Hacker News sull'exploit.
Dettagli CVE, report e vulnerabilità
Ho visitato questo sito, che pubblica le ultime minacce alla sicurezza in base al fornitore e ho scoperto 4 vulnerabilità nel primo trimestre del 2018. Anche la pagina delle informazioni sulla sicurezza di PostgreSQL le ha elencate, quindi non esitare a consultare quella risorsa.
Sebbene la maggior parte di essi sia stata affrontata, ho ritenuto importante includerli in questo post per sensibilizzare i lettori che potrebbero non conoscerli. Sento che possiamo imparare da tutti loro. Soprattutto nei diversi modi di scoprire le vulnerabilità.
Sono elencati di seguito in ordine di data di pubblicazione:
Io. CVE-2018-1052 data pubblicata 2018-02-09 :Data di aggiornamento 3/10/2018
Panoramica:
In PostgreSQL 10.x prima della 10.2 è stata rilevata una vulnerabilità di divulgazione della memoria nel partizionamento delle tabelle, consentendo a un utente malintenzionato autenticato di leggere byte arbitrari di memoria del server tramite un inserimento appositamente predisposto in una tabella partizionata.
Questa vulnerabilità è stata risolta con il rilascio di PostgreSQL 10.2 confermato qui. Sono menzionate anche le versioni precedenti 9.x corrette, quindi visita il link per verificare la tua versione specifica.
II. CVE-2018-1053 data pubblicata 2018-02-09 :Data di aggiornamento 15/03/2018
Panoramica:
In PostgreSQL 9.3.x prima della 9.3.21, 9.4.x prima della 9.4.16, 9.5.x prima della 9.5.11, 9.6.x prima della 9.6.7 e 10.x prima della 10.2, pg_upgrade crea il file nella directory di lavoro corrente contenente l'output di `pg_dumpall -g` sotto umask che era in vigore quando l'utente ha invocato pg_upgrade, e non sotto 0077 che è normalmente usato per altri file temporanei. Ciò può consentire a un utente malintenzionato autenticato di leggere o modificare un file, che può contenere password di database crittografate o non crittografate. L'attacco non è fattibile se una modalità directory blocca l'attaccante che cerca nella directory di lavoro corrente o se la umask prevalente blocca l'attaccante nell'apertura del file.
Come con il precedente CVE-2018-1052, PostgreSQL 10.2 ha corretto questa parte della vulnerabilità:
Assicurati che tutti i file temporanei creati con "pg_upgrade" non siano leggibili da tutti
Molte versioni precedenti di PostgreSQL sono interessate da questa vulnerabilità. Assicurati di visitare il link fornito per tutte le versioni elencate.
III. CVE-2017-14798 data di pubblicazione 2018-03-01 :Data di aggiornamento 26/03/2018
Panoramica:
Una race condition nello script di init di PostgreSQL potrebbe essere utilizzata dagli aggressori in grado di accedere all'account PostgreSQL per aumentare i propri privilegi a root.
Anche se non sono riuscito a trovare da nessuna parte nella pagina di collegamento in cui è stata menzionata la versione 10 di PostgreSQL, molte versioni precedenti lo sono, quindi visita quel collegamento se esegui versioni precedenti.
Gli utenti di Suse Linux Enterprise Server potrebbero essere interessati a 2 articoli collegati qui e qui in cui questa vulnerabilità è stata corretta per lo script di inizializzazione della versione 9.4.
IV. CVE-2018-1058 data di pubblicazione 2018-03-02 :Data di aggiornamento 22/03/2018
Panoramica:
È stato riscontrato un difetto nel modo in cui PostgreSQL consentiva a un utente di modificare il comportamento di una query per altri utenti. Un utente malintenzionato con un account utente potrebbe utilizzare questo difetto per eseguire codice con i permessi di superutente nel database. Le versioni da 9.3 a 10 sono interessate.
Questa versione di aggiornamento menziona questa vulnerabilità con un interessante documento collegato che tutti gli utenti dovrebbero visitare.
L'articolo fornisce una fantastica guida della community intitolata A Guide to CVE-2018-1058:Protect Your Search Path che contiene un'incredibile quantità di informazioni sulla vulnerabilità, i rischi e le migliori pratiche per combatterla.
Farò del mio meglio per riassumere, ma visita la guida a tuo vantaggio, comprensione e comprensione.
Panoramica:
Con l'avvento di PostgreSQL versione 7.3, gli schemi sono stati introdotti nell'ecosistema. Questo miglioramento consente agli utenti di creare oggetti in spazi dei nomi separati. Per impostazione predefinita, quando un utente crea un database, PostgreSQL crea anche uno schema pubblico in cui vengono creati tutti i nuovi oggetti. Gli utenti che possono connettersi a un database possono anche creare oggetti nello schema pubblico di quel database.
Questa sezione direttamente dalla guida è molto importante (vedi articolo citato):
Gli schemi consentono agli utenti di utilizzare lo spazio dei nomi per gli oggetti, quindi gli oggetti con lo stesso nome possono esistere in schemi diversi nello stesso database. Se sono presenti oggetti con lo stesso nome in schemi diversi e la coppia schema/oggetto specifica non è specificata (es. schema.object), PostgreSQL decide quale oggetto utilizzare in base all'impostazione del percorso_ricerca. L'impostazione search_path specifica l'ordine in cui gli schemi vengono cercati durante la ricerca di un oggetto. Il valore predefinito per percorso_ricerca è $utente,pubblico dove $utente fa riferimento al nome dell'utente connesso (che può essere determinato eseguendo SELECT SESSION_USER;).
Un altro punto chiave è qui:
Il problema descritto in CVE-2018-1058 è incentrato sullo schema "pubblico" predefinito e su come PostgreSQL utilizza l'impostazione search_path. La possibilità di creare oggetti con gli stessi nomi in schemi diversi, combinata con il modo in cui PostgreSQL cerca oggetti all'interno di schemi, offre all'utente l'opportunità di modificare il comportamento di una query per altri utenti.
Di seguito è riportato un elenco di alto livello in cui la guida consiglia l'applicazione di queste pratiche come stabilito per ridurre il rischio di questa vulnerabilità:
- Non consentire agli utenti di creare nuovi oggetti nello schema pubblico
- Imposta il percorso_ricerca predefinito per gli utenti del database
- Imposta il percorso_ricerca predefinito nel file di configurazione di PostgreSQL (postgresql.conf)
Iniezione SQL
Qualsiasi 'tema di sicurezza ' Il post o l'articolo del blog SQL non può etichettarsi come tale senza menzionare l'iniezione di SQL. Anche se questo metodo di attacco non è affatto 'il nuovo ragazzo sul blocco ', deve essere incluso.
SQL injection è sempre una minaccia e forse ancora di più nello spazio delle applicazioni web. Qualsiasi database SQL, incluso PostgreSQL, è potenzialmente vulnerabile ad esso.
Anche se non ho una profonda conoscenza di base su SQL Injection, noto anche come SQLi, farò del mio meglio per fornire un breve riepilogo, come può potenzialmente influenzare il tuo server PostgreSQL e, in definitiva, come ridurre i rischi di cadere preda ad esso.
Fare riferimento ai collegamenti forniti verso la fine di questa sezione, che contengono tutti una grande quantità di informazioni, spiegazioni ed esempi in quelle aree che non sono in grado di comunicare adeguatamente.
Sfortunatamente, esistono diversi tipi di iniezioni SQL e condividono tutti l'obiettivo comune di inserire SQL offensivo nelle query per l'esecuzione nel database, forse non originariamente previsto né progettato dallo sviluppatore.
L'input dell'utente non disinfettato, il controllo del tipo mal progettato o inesistente (convalida AKA), insieme all'input dell'utente senza escape, possono potenzialmente lasciare la porta spalancata per potenziali aggressori. Molte API di programmazione Web forniscono una certa protezione contro SQLi:ad esempio, ORM (Object Relational Mapper), query parametrizzate, controllo del tipo, ecc. Tuttavia, è responsabilità dello sviluppatore fare ogni sforzo e ridurre gli scenari principali per l'iniezione SQL implementando quelle deviazioni e meccanismi a loro disposizione.
Ecco alcuni suggerimenti degni di nota per ridurre il rischio di SQL injection dal Cheat Sheet di OWASP SQL Injection Prevention. Assicurati di visitarlo per i dettagli completi degli esempi di utilizzo nella pratica (vedi articolo citato).
Difese primarie:
- Opzione 1:utilizzo di istruzioni preparate (con query parametrizzate)
- Opzione 2:utilizzo di stored procedure
- Opzione 3:convalida dell'input della white list
- Opzione 4:sfuggire a tutti gli input forniti dall'utente
Difese aggiuntive:
- Inoltre:applicare il privilegio minimo
- Inoltre:esecuzione della convalida dell'input della white list come difesa secondaria
Lettura consigliata:
Ho incluso articoli aggiuntivi con un carico di informazioni per ulteriori studi e consapevolezza:
- Cos'è l'iniezione SQL? Questo vecchio ma buono può far male alle tue applicazioni web
- Iniezione SQL (Wikipedia)
- Iniezione SQL (CLOUDFLARE)
- Iniezione SQL (w3schools.com)
- Cheat sheet di SQL Injection Prevention
- Test per SQL injection
- Vulnerabilità di SQL Injection e come prevenirle
- Cheat Sheet di SQL injection
Privilegi ruolo Postgres
Abbiamo un detto per qualcosa sulla falsariga di "Siamo il nostro peggior nemico ."
Possiamo sicuramente applicarlo al lavoro all'interno dell'ambiente PostgreSQL. La negligenza, l'incomprensione o la mancanza di diligenza sono un'opportunità per attacchi e usi non autorizzati tanto quanto quelli lanciati di proposito.
Forse ancora di più, consentendo inavvertitamente accesso, percorsi e canali più facili a cui attingere le parti incriminate.
Citerò un'area che ha sempre bisogno di essere rivalutata o rivalutata di tanto in tanto.
Privilegi di ruolo non giustificati o estranei.
- SUPERUTENTE
- CREATROLO
- CREATOB
- CONCESSIONE
Vale sicuramente la pena dare un'occhiata a questa fusione di privilegi. SUPERUSER e CREATROLE sono comandi estremamente potenti e sarebbero meglio serviti nelle mani di un DBA piuttosto che di un analista o sviluppatore, non credi?
Il ruolo ha davvero bisogno dell'attributo CREATEDB? E GRANT? Tale attributo potrebbe essere utilizzato in modo improprio nelle mani sbagliate.
Valuta attentamente tutte le opzioni prima di consentire ruoli a questi attributi nel tuo ambiente.
Strategie, best practice e rafforzamento
Di seguito è riportato un elenco di utili post di blog, articoli, elenchi di controllo e guide che sono tornati per un "anno indietro" (al momento in cui scrivo) di risultati di ricerca. Non sono elencati in nessun ordine di importanza e ciascuno offre suggerimenti degni di nota.
- Modi semplici per proteggere i tuoi server Postgres da un vettore di attacco improbabile:un'immagine canaglia di Scarlett Johansson
- Aiutare a proteggere il tuo database PostgreSQL
- Non essere testardo... Rafforza il tuo database PostgreSQL per garantire la sicurezza
- Come proteggere il tuo database PostgreSQL:10 suggerimenti
- Protezione di PostgreSQL da attacchi esterni
- Privilegi e sicurezza PostgreSQL:blocco dello schema pubblico
Conclusione
In questo blog, abbiamo esaminato i problemi di sicurezza che riguardano gli amministratori di PostgreSQL in tutto il mondo:questi includono SQL injection, che è il Santo Graal di tutti gli incidenti di sicurezza, errori negli approcci di base alla gestione dati in modo sicuro, ad esempio il mancato rafforzamento delle autorizzazioni nell'infrastruttura e anche alcuni problemi di sicurezza meno noti che potrebbero essere trascurati. Quando si tratta della sicurezza dei nostri dati, è fondamentale che prendiamo e applichiamo i consigli di parti fidate come Imperva e simili che ci forniscono modi per proteggerci sia dagli attacchi di base che da 0-days (exploit che non sono ancora stati noto in precedenza) allo stesso modo, perché una consulenza affidabile significa un buon futuro per i nostri database e l'infrastruttura nel suo insieme.
Tieni presente che le misure di sicurezza che dobbiamo adottare dipenderanno fortemente dalle vulnerabilità che vogliamo respingere, ma in generale, conoscere tutte le difese necessarie per respingere l'iniezione SQL, utilizzando correttamente privilegi e cercare sempre di ridurre il nostro livello di rischio relativo alle vulnerabilità è fondamentale. Rimanere aggiornati su ciò che sta accadendo nello spazio di sicurezza di PostgreSQL farà miracoli anche per noi:possiamo difendere bene i nostri server (e, di conseguenza, i nostri dati) solo se sappiamo cosa potrebbero essere gli aggressori.
Se stai cercando altre best practice per migliorare la sicurezza o lo stato delle prestazioni delle tue installazioni PostgreSQL, rivolgiti a ClusterControl:poiché lo strumento è sviluppato da esperti di database di prim'ordine da tutto il mondo, farà cantare i tuoi database in pochissimo tempo. Il prodotto include anche una prova gratuita di 30 giorni, quindi assicurati di non perdere l'occasione di provare tutte le funzionalità che ClusterControl può offrire per la tua azienda e provalo oggi stesso.
Per ulteriori contenuti su come proteggere le istanze del database PostgreSQL, consulta il blog di Manynines per un consiglio:imparare ad automatizzare gli audit di sicurezza per PostgreSQL sarà sicuramente un passo nella giusta direzione. Assicurati di seguirci su Twitter, LinkedIn e iscriviti al nostro feed RSS per ulteriori aggiornamenti e ci vediamo al prossimo.
