Fake users in database per il rilevamento di compromessi

30

Ho letto di siti * aggiungendo utenti falsi ai loro database e monitorandone l'utilizzo. Uno di questi utenti falsi viene utilizzato o addirittura tentato l'accesso può significare compromissione del database ecc.

Sembra una buona idea per rilevare i problemi dopo che si sono verificati e ho intenzione di farlo da solo. È in realtà una buona idea?

Sarebbe utile eseguire la scansione del web, utilizzando gli avvisi di google, ecc. per gli utenti falsi, gli hash delle password e gli indirizzi email e, eventualmente, le stringhe univoche all'interno della codebase?

* Scusa, non ricordo dove. Linodo forse.

modifica: per chiarezza, gli "utenti" sono quelli che accedono a un sito Web. Potrei aggiungere utenti simili a [email protected] con una password di tipo dizionario. Se l'utente ha effettuato il login, quindi controlla e reimposta tutte le password degli utenti, ecc. Se si tratta solo di un tentativo di accesso, allora è una bandiera di qualcosa da indagare ulteriormente, ma forse solo un colpo fortunato.

Per quanto riguarda il monitoraggio del web, ho potuto monitorare pastebin ecc. e cercare l'hash della password per quegli utenti o stringhe univoche trovate altrove nel mio codice / db. Questo potrebbe essere indipendente dall'idea di un falso utente, poiché potrei semplicemente monitorare gli hash reali (ad esempio un account amministratore di basso livello).

    
posta Paul 17.01.2016 - 21:04
fonte

4 risposte

13

La creazione di un honeypot è una tecnica usata comunemente nella sicurezza delle informazioni, anche se probabilmente non è la migliore delle idee per un ambiente di produzione. A parte il fatto che si aggiungono rischi potenzialmente nuovi alla propria applicazione, potrebbe non esserci molto bisogno di tale trappola.

Gli accessi non riusciti possono essere monitorati dalla maggior parte delle applicazioni (e / o daemon del server) che dovrebbero fornire più informazioni sufficienti senza mettere a rischio l'applicazione.

Per dichiarare l'ovvio; gli attacchi di forza bruta sono (sfortunatamente) un fenomeno comune ed è probabile che colpiscano comunque la tua applicazione.

    
risposta data 17.01.2016 - 23:41
fonte
4

Sono un po 'in ritardo rispetto alla domanda, ma dato che per la maggior parte non sono d'accordo con le altre risposte finora, ne sto presentando una nuova.

Le principali cose che non sono d'accordo con le altre risposte sono:

  1. L'aggiunta di utenti al DB non è la stessa cosa della creazione di un honeypot. (Probabilmente è possibile prendere una definizione di honeypot e interpretarla in modo tale che questo possa essere considerato un honeypot, ma penso che sia un tratto.) Supponiamo di aggiungere 10 utenti solo per il tuo team di QA da utilizzare per i test. Se noti che qualcuno di questi utenti ha effettuato l'accesso al di fuori dei normali orari di test, o da IP che non sono previsti, realizzerai la stessa cosa, e sicuramente non chiameresti honeypot a quegli utenti del QA.

  2. L'aggiunta di ulteriori utenti al sistema non rende il sistema più vulnerabile. Se ciò fosse vero, ogni volta che un nuovo utente crea un account, il sistema diventerebbe più vulnerabile. Sarebbe abbastanza triste se fosse vero!

Per quanto riguarda l'eventuale aggiunta di utenti al sistema, la risposta dipende da cosa effettivamente fa la tua applicazione. Se il tuo database utente è compromesso, quale sarebbe invece l'attaccante: le informazioni contenute nel database (come nomi utente / password / indirizzi email) o preferirebbero avere accesso al sito web? Prendere in considerazione:

  • Se il sito gestisce i servizi bancari, probabilmente un utente malintenzionato tenterà di accedere con molti account e spostare denaro o raccogliere informazioni sull'account. (In questo caso, gli utenti "extra" potrebbero avere dei tentativi di accesso.)
  • Se il sito è solo un forum gratuito, l'utente malintenzionato probabilmente non si preoccuperà dell'accesso e considererà invece la vendita degli indirizzi email o tenterà di forzare l'hash della password per indovinare le password su siti bancari o di e-commerce. ( Questo potrebbe essere lo scenario più probabile. )
  • Se il sito presenta interessanti contenuti a pagamento che l'utente malintenzionato desidera, potrebbero scegliere un singolo utente e accedere con esso. (Che è improbabile che sia uno degli utenti "extra".)

Quindi, nel primo caso, il monitoraggio degli utenti "extra" potrebbe essere un po 'utile, ma nella maggior parte dei casi probabilmente non lo sarebbe.

Detto questo, se vuoi ancora provarlo, forse l'approccio più efficace è questo:

  1. Crea due nuovi account e-mail con indirizzi molto difficili da indovinare, password estremamente difficili, quindi configurali per l'inoltro al tuo account e-mail principale che controlli frequentemente.
  2. Sul tuo sito, crea un nuovo utente con ciascuno di questi indirizzi email, entrambi con molto difficile da indovinare nomi utente .
  3. Dai agli utenti una password molto difficile e concedi all'utente una password facile.

Ora hai compiuto due cose: se uno di questi utenti ha effettuato l'accesso (probabilmente sarà quello con la password facile), allora il tuo DB è probabilmente compromesso. Oppure, se ricevi mai un'email a uno degli indirizzi email di questo account, è probabile che il tuo DB sia stato compromesso e gli indirizzi email siano stati probabilmente venduti.

Pensiero finale: sopra di cui ho menzionato lo scenario più probabile (l'utente malintenzionato tenta di raccogliere utenti / email / password per l'utilizzo su altri siti), in tal caso non possono mai accedere o vendere / spamare gli indirizzi email, e in tal caso , sfortunatamente sarà piuttosto difficile rilevarlo al di fuori del monitoraggio di tutti gli accessi al server DB.

    
risposta data 11.02.2016 - 17:07
fonte
3

Potrebbe essere utile per la valutazione delle vulnerabilità credenziali, ma dal punto di vista della produzione, stai mettendo a rischio l'applicazione. Questo potrebbe essere un possibile vettore di attacco per un aggressore.

L'attaccante può accedere a questi account e può trovare modi per sfruttare e ottenere diritti amministrativi o escalation di privilegi.

Il concetto che stavi cercando di dire è un Honeypot (monitorare cosa potrebbe fare l'attaccante), ma gli honeypot sono progettati per essere compromessi. Credo che tu non voglia che la tua applicazione sia compromessa.

1 regola in Application Hardening è disabilitare account non necessari / account predefiniti / account guest / account condivisi.

    
risposta data 17.01.2016 - 22:40
fonte
3

Mi sembra una buona idea, ma con un avvertimento: è necessario assicurarsi che non renda il sistema più vulnerabile. Mi rendo conto che ciò è tecnicamente impossibile in quanto un altro account utente è un altro modo, ma ecco cosa suggerisco se decidi di implementarlo:

  • Non utilizzare un nome utente comune, come ad esempio l'amministratore. Questo è probabile che venga colpito da attacchi passivi multi-host che effettuano solo la scansione.
  • Rendi la password follemente, anche se in modo non pratico e complesso visto che non c'è intenzione di utilizzare l'account.
  • Monitora gli tentativi di accessi così come i successi, anche se hai problemi più grandi in caso di successo.
  • Infine, uno di questi problemi più grandi: ASSICURI DI AVER CREATO LE PASSWORD !!! Questo dovrebbe essere il buonsenso, ma sarai sorpreso. Se le tue password non sono hash, un compromesso del database POTREBBE consentire l'accesso a tutti gli account.

Nota finale: il motivo per cui è così importante tentare un tentativo piuttosto che un accesso riuscito è stato menzionato da altri utenti: l'escalation dei privilegi è probabile quasi certamente possibile se possono entrare.

    
risposta data 18.01.2016 - 02:08
fonte

Leggi altre domande sui tag