Quali registri cercare su Ubuntu quando Postgres DB viene violato! [chiuso]

Question

Quali registri cercare su Ubuntu quando Postgres DB viene violato! [chiuso]

#1 da (2 voti)
#2 da (1 voti)

-3

Aggiornato il titolo della domanda per chiarire che questo post non chiede alla comunità di rispondere "come siamo stati violati" ma "quali log cercare o puntatori che possono aiutare la nostra indagine". Riteniamo che questa domanda sia stata messa sottosopra perché è stata fraintesa.

Il nostro DB Postgres è stato violato e trattenuto per ottenere un riscatto. Hacker cancellò tutte le tabelle nel DB e creò una singola tabella chiamata "warning" con una singola riga che chiedeva 0.5 BTC per restituire una copia del nostro DB.

Non abbiamo alcun esperto di sicurezza residente né alcuno Ops o esperto di Linux o DBA.

Qualcuno potrebbe suggerire da dove iniziare la nostra indagine? Quali file di registro cercare Postgres o Ubuntu o Rete?

Fortunatamente abbiamo avuto un backup in modo da poter ripristinare il nostro sistema, ma non riuscivamo ancora a capire come ci siamo fatti hackerare.

Riga dalla tabella "warning". column: warning_text: invia 0.5 BTC a questo indirizzo e vai a questo sito link per recuperare il tuo database! Il dump SQL sarà disponibile dopo il pagamento!

Aggiornamento: ulteriori informazioni Qualche informazione in più: SSH stava solo per accedere a questa istanza. Tuttavia, avevamo tutte le porte aperte, il che era un errore, ma eravamo un po 'incuranti perché era il nostro ambiente di test. La nostra prima ipotesi è che la password predefinita di account db postgres sia stata hackerata attraverso la forza bruta, ma non sappiamo dove cercare di rintracciarlo.

I file di registro di Postgres hanno registri come quello sotto che mostra che alcuni script sh stavano caricando il DB. Ma non sappiamo quali registri cercare per tracciare come hanno violato la password e come / quando hanno cancellato le tabelle nel DB e creato la tabella degli avvisi.

- 29/12/2016 01: 01: 25-- link Connessione a 173.199.124.112:8090 ... connessa. Richiesta HTTP inviata, in attesa di risposta ... 200 OK Lunghezza: 1061 (1.0K) [applicazione / x-sh] Salvataggio in: '/tmp/mpool.sh'

 0K .                                                     100%  249M=0s

2016-12-29 01:01:25 (249 MB / s) - "/tmp/mpool.sh" salvato [1061/1061]

% Totale% Ricevuto% Xferd Velocità media Tempo Tempo Tempo Corrente Dload Upload Total Spent Left Speed ^ M 0 0 0 0 0 0 0 0 -: -: - -: -: - -: -: - 0 ^ M100 1061 100 1061 0 0 6567 0 -: -: - -: -: - -: -: - 6590

ubuntu postgresql

posta Sudeep Kaushik 02.03.2017 - 20:24

fonte

2 risposte

Leggi altre domande sui tag ubuntu postgresql

Come eseguire il file PHP dopo averlo caricato? [chiuso] Qualsiasi honeypot disponibile per eseguire webservice

score 2 · Answer 1

Questo avviso è irrilevante -

L'attacco stesso avrebbe potuto attraversare la qualsiasi debolezza che hai sulla tua rete, o attraverso un phish, o un servizio web o altro.

Devi estrarre tutti i tuoi log da:

firewall
router
piattaforme host
sistemi utente finale
database
sistemi di gestione utenti / ID ecc.

Quindi analizzali insieme per capire la timeline.

Questo è davvero un lavoro forense specializzato, se vuoi essere sicuro di come sia successo.

Potresti preferire lavorare su ogni dispositivo, pulire e indurire (ad esempio, rimuovere le password predefinite, aggiustare le todate, aggiungere configurazioni di sicurezza ecc.)

score 1 · Answer 2

Oltre a ciò che dice Rory, questi attacchi sono molto comuni con i database non protetti esposti a Internet. So che stanno accadendo con MongoDB, ma qualsiasi piattaforma di database è possibile supponendo che sia esposta a Internet e abbia un'autenticazione debole.

Per un riscatto di 0,5 BTC immagino che il vettore di attacco non sia sofisticato. È improbabile che abbiano dedicato troppo tempo e sforzi a questo, ed è stato probabilmente automatizzato in qualche modo.

Detto questo:

Fai l'inventario del tuo ambiente. Quale versione OS / Frameworks / languages / Web server / PostgreSQL stavi eseguendo? Ci sono degli exploit noti per loro? Controlla expoit-db.com
Quali porte erano aperte sul firewall? TCP 5432 è stato esposto a Internet?
Le connessioni remote erano consentite nel database? In tal caso, quali utenti sono stati in grado di accedere?
Come sono le tue password? Erano complessi?
Come è stato concesso l'accesso SSH? L'accesso SSH remoto consentito dalla root era consentito?

Dovrei concludere dicendo che non ho esperienza formale in DFIR, tuttavia penso che si possa tranquillamente ritenere che non si trattasse di un attacco troppo sofisticato, quindi partire dalle basi sarebbe il punto in cui iniziare.