Come accostarti a escludere che i precedenti sviluppatori stiano facendo backdoor sul mio sito web?

Ci sono infiniti modi in cui uno sviluppatore può inserire backdoor intenzionali e non intenzionali nel codice. Quando lo sviluppatore è esperto, può nasconderlo bene e / o mascherarlo in un modo che sembra un errore non intenzionale. Una completa revisione del codice è l'unico modo per ottenere la ragionevole certezza che è improbabile che possano esistere ulteriori backdoor. Ma non c'è davvero un modo sicuro per escludere completamente l'esistenza delle backdoor.

Quando sei di fretta, potresti almeno provare a escludere le cose più ovvie prima di iniziare a esaminare il codice completo riga per riga:

• Dai un'occhiata al codice di accesso e di autenticazione: questo è il posto più ovvio dove disporre di un parametro magico, una password universale o credenziali codificate che consente di accedere senza un account valido.
• Controlla se ci sono degli script nella base di codice che non sembrano essere referenziati da nessuna parte - potrebbero essere un pannello di controllo nascosto o simile.
• Quando i messaggi di posta elettronica in particolare sono un problema, grep codebase dei siti Web per quelle funzioni che inviano email nel tuo linguaggio di programmazione. È inoltre possibile monitorare il traffico dei server Web per il traffico SMTP in uscita per rilevare eventuali e-mail che non corrispondono al formato solitamente inviato dall'applicazione (quando si suppone che invii messaggi di posta elettronica).

A proposito: questo potrebbe anche essere un argomento per il tuo dipartimento legale. Backdooring dell'applicazione è probabilmente una violazione del contratto e potrebbe anche essere un crimine nella tua giurisdizione.

Essendoci stati in passato con i clienti - ecco alcune misure pratiche per escludere che gli sviluppatori (dipendenti o appaltatori) abbiano lasciato back-door nel codice per accedere al sito.

1. Rimuovi tutte le credenziali per la persona che è uscita dal server Web (ad esempio le credenziali di autenticazione di base), gli utenti del sistema operativo, gli utenti del database, gli utenti del server di posta. Fallo adesso e rendilo un SOP quando le persone se ne vanno.
2. Controlla l'elenco degli utenti con privilegi SUDO (o amministratore se sei su Windows). Elimina tutti gli utenti sudo che non conosci o di cui ti fidi. Se qualcuno ha bisogno di sudo, lo chiederanno e chiederai una giustificazione
3. Svuota il registro di sicurezza per tentativi di interruzione e avvia il registro del server Web per individuare i nomi che sembrano lo sviluppatore che ha lasciato. Arresta i servizi FTP.
4. Se sei su Linux ed esegui Samba - controlla le autorizzazioni permesse - rimuovi gli utenti che non lavorano più per la compagnia Grep tutto il codice sorgente per il nome o l'e-mail della persona: se ottieni un hit, pulisci il codice
5. Supponendo che tu usi svn o git - esamina tutti i commit che lo sviluppatore ha eseguito 1 settimana prima di partire o è stato licenziato. La maggior parte delle cose nefaste accade vicino alla fine. Esamina il codice manualmente e con grep e cerca specificamente le eccezioni all'autenticazione basata su un nome utente, un parametro magico in una stringa di query, un'ora del giorno o un indirizzo IP. Qualsiasi codice che dice se qualcosa! l'autenticazione è sospetta.
6. Supponendo che tu usi un framework MVC come RoR o CakePHP - esamina le tue tabelle acl ed esamina il controller di autenticazione per le eccezioni come nel punto precedente
7. Post-exploit - implementa un SOP per spazzare periodicamente gli utenti delle applicazioni del sistema operativo e Web e rimuovere account / account inutilizzati delle persone che hanno lasciato / account con privilegi non necessari.

Dipende da quanto vuoi essere profondo. Ecco un elenco di luoghi da cui iniziare in ordine crescente di sforzo.

1. Sostituisci tutte le dipendenze binarie / javascript con nuove copie
2. Assicurarsi che il codice di autenticazione e autorizzazione sia centralizzato e il più semplice possibile, preferibilmente configurato centralmente. Se il codice di accesso o di autorizzazione è complesso, potrebbe valere la pena riscriverlo.
3. Pensa a tutte le azioni sensibili che il sito potrebbe intraprendere, ad es. inviare una e-mail, effettuare una connessione di rete. Trova tutte le occorrenze di queste azioni e controllale.
4. A seconda delle dimensioni del sito e del budget, è necessario eseguire una revisione dell'intera base di codice.
5. Se lo sviluppatore ha avuto accesso al server, re-image il server (Paranoia Level High)

Se non ti senti sicuro della tua capacità di fare questa revisione del codice, ci sono aziende specializzate in sicurezza che faranno una revisione per te.

Dipende dalla tua politica / sicurezza. Il problema principale con qualcosa di questo tipo è la dipendenza dal codice. Soprattutto su codici e librerie legacy. Le linee di codice rendono praticamente impossibile controllare ogni singola parte del codice. Ciò è particolarmente vero se lo sviluppatore sostituisce parti dello stack, motivo per cui le build riproducibili sono importanti, o almeno la capacità di diff tra le differenze. Questo potrebbe non essere possibile per le vecchie installazioni e la mancanza di proprietà.

L'accesso centralizzato o decentrato rappresenta un compromesso tra il carico di lavoro amministrativo e il processo di mitigazione in atto una volta che una parte del sistema è stata violata. Hai abbastanza persone per farlo? E può essere automatizzato?

In generale, i giorni di fine di ogni installazione e di non avere un processo di mitigazione coerente come parte dell'intero insieme, sono passati. E, non è possibile escludere in modo definitivo che il sito Web non sia stato in alcun modo compromesso.