it-swarm.dev

Come è possibile "hacking" anche se "difendo" correttamente?

Su un server basato su Linux, seguo le pratiche di base come di seguito:

  1. Rendi la password dell'account amministratore abbastanza lunga e complicata (cioè teoricamente, la password non può essere decifrata entro un tempo ragionevole).
  2. Monitora tutto il traffico di rete in entrata verso i file amministrativi.
  3. Per estendere il livello di protezione dal n. 2 sopra, monitorare le modifiche ai file locali (in particolare quelli che hanno comandi che richiedono privilegi Sudo).
  4. Convalida tutto input dell'utente, in modo che tutti gli input dell'utente siano sicuri.

Come sviluppatore alle prime armi, non capisco come un hacking sia fattibile se l'amministratore del server pratica quanto sopra.

60
J. Berman

Non sei sicuro che tutti gli aggiornamenti di sicurezza siano applicati? Ricorda, come difensore, devi vincere 100% delle volte. Un hacker deve vincere solo una volta.

I passaggi che hai elencato sono anche molto più facili a dirsi che a farsi (tranne la cosa della password ... eppure le persone scelgono ancora password orribili!).

2) Inoltre, qual è una "fonte credibile" per un server Web pubblico? L'intera Internet? L'intera Internet, senza Cina/Russia (/ alcuni/altri/paesi)? I sistemi automatizzati sono in grado di rilevare molti tipi di attacchi, ma proprio come l'antivirus possono andare solo così lontano.

3) Il monitoraggio dei file locali è buono, ma, di nuovo, non è una panacea. Che cosa succede se l'attaccante riesce a iniettare codice nel server Web e quindi utilizza un bug del kernel per ottenere il codice nel kernel ... senza mai scrivere un file sul disco? A quel punto, potrebbero scrivono file sul disco e usano un root kit per impedire alla maggior parte (teoricamente tutti) delle scansioni online di notare eventuali modifiche al sistema.

E anche se riescono solo a sfruttare il web server, possono fare tutto ciò che il web server può fare (che potrebbe essere comunque tutto l'autore dell'attacco interessato).

4) È necessario convalidare sempre l'input dell'utente. La maggior parte degli sviluppatori lo sa (e molti cercano di farlo). Purtroppo, è molto più facile a dirsi che a farsi, motivo per cui continuiamo a vedere un problema dopo l'altro in cui l'input dell'utente non è adeguatamente convalidato. mai sarai in grado di garantire che qualsiasi vero software sia correttamente convalidando tutti gli input dell'utente. Leggi alcune domande PHP + MySQL su StackOverflow per vedere quante persone pensano che mysqli_real_escape_string() prevenga tutti gli attacchi di iniezione SQL ("where ID = " . $val è vulnerabile, anche quando $val è l'output di mysqli_real_escape_string!).

Anche se tu potessi (non puoi) assicurarti che ogni vettore di attacco noto fosse sorvegliato, non puoi fare altro che oscillare selvaggiamente nel buio e sconosciuto-sconosciuto (bene, educare continuamente te stesso aiuta).

Come esempio in cui le tue difese non avrebbero fatto nulla, stavo prendendo parte a un corso di sicurezza in cui stiamo facendo "giochi di guerra". Sono stato in grado di eseguire il root del server di una squadra avversaria riuscendo a ottenere una delle loro password utente n'altra macchina (una di esse ha rovinato e digitato in bash come comando per errore, e non hanno mai pensato per eliminarlo da .bash_history).

Da lì, ho falsificato l'IP della macchina da cui di solito hanno effettuato l'accesso e ho inserito SSH, inserendo il loro nome utente + password. Ho avuto un accesso limitato al sistema. Ho quindi eseguito Sudo vim, ha immesso di nuovo la stessa password e aveva generato una shell Shell. Tada! Accesso alla radice, da una fonte credibile, senza modificare i file locali in modo insolito, senza sfruttare una password debole (era male, ma nemmeno la migliore password del mondo non avrebbe aiutato), né fare affidamento su input dell'utente non convalidato.

A quel punto, essendo malizioso, ho modificato manualmente tutti i file di registro relativi al mio accesso legittimo e cancellato i loro ID (scommetto che non saranno abbastanza osservatori da notare che ho sostituito tutti i suoi file binari con copie di /bin/true!). Un hacker "reale" sarebbe probabilmente molto meglio equipaggiato per garantire che la sua attività non fosse rilevata da amministratori più vigili, ma avevo già raggiunto il mio obiettivo e una piccola parte di me voleva che scoprissero che qualcuno lo aveva ottenuto.

85
Kitsune

Se potessi manipolare la legge di Schneier:

Chiunque, dal dilettante più all'oscuro al miglior amministratore di sistema, può creare un sistema di sicurezza che lui stesso non può rompere.

67
Graham Hill

In breve, a difendi correttamente non è un compito facile perché ... enter image description here

Facendo una pugnalata ai tuoi input ->

Rendi la password dell'account amministratore lunga ...

La semplice spalla praticata sconfigge qualsiasi sforzo su password complesse.
Inoltre, se i meccanismi di archiviazione delle password sono deboli (inclini a iniezioni di SQL, o meccanismi di hash non sicuri o, peggio, archiviazione di password in testo semplice), rimani vulnerabile.

Monitora ogni traffico di rete in entrata

Monitorerai moltissimo traffico. Qual è la garanzia che non ti perderai alcune cose importanti? E che dire di zero-day ?
Che dire del traffico crittografato? Cosa monitorerai su questo?

... e consenti solo fonti credibili.

E se i tuoi fonti credibili venissero compromessi/compromessi? Quindi non sono più credibili ma tu, l'amministratore di sistema, non lo sai!

... monitora le modifiche ai file locali ... Convalida ogni input dell'utente ...

Ancora una volta, quanto puoi monitorare e quanti log puoi analizzare ...

Inoltre, supponendo che vi siano almeno alcuni servizi in esecuzione sulla macchina, le vulnerabilità nel servizio potrebbero diventare la causa della compromissione della macchina.

Spero di poterti dare un'idea di quanto sia fattibile l'hacking :)

Ack: immagine tratta da www.quotesparade.com

26
pnp

Se potessi difenderti "correttamente", gli hacker non potrebbero mai entrare. Il problema è cosa significa correttamente in questo tipo di situazione.

Potresti spegnere il server e sigillarlo in cemento mezzo miglio sotto terra ed è abbastanza sicuro, giusto? Ma è inutilizzabile. E se il valore di ciò che è su è abbastanza alto, un attaccante può provare a scavarlo. Quindi, da questo esempio estremo, puoi già vedere che la sicurezza è un equilibrio. Deve essere appropriato e consentire comunque l'utilizzo del server.

Stando così le cose, i problemi che troverai includono:

  • come si fa a garantire che tutti gli eseguibili siano sicuri? Ancora una volta, non puoi. Puoi decidere quanti sforzi vuoi spendere per controllarli ed eseguire vari test, ma le basi di codice sono abbastanza grandi per la maggior parte delle applicazioni in cui si verificano errori accidentali.
  • l'opzione di sicurezza proposta rende il server inutilizzabile per il suo pubblico di destinazione? Scollegarlo dalla rete aumenterà la sicurezza, ma non piacerà ai tuoi utenti.
  • conosci davvero tutti i possibili input che i tuoi utenti potrebbero voler usare? Se è così, brillante - lista bianca li. Ma ricorda di aggiornare ogni volta che l'applicazione viene aggiornata o ha nuove funzionalità. E controlla ogni volta che ottieni un nuovo utente. E prova che la white list funziona per interrompere tutti gli input non approvati. E così via...
  • gli attacchi potrebbero non dover modificare alcun file sul disco. Il monitoraggio dei file non raccoglie gli attacchi che indirizzano direttamente il codice in memoria, ad esempio.
  • l'aggiunta di controlli tecnici di sicurezza non tiene conto degli attacchi sociali o fisici. Se un utente malintenzionato desidera davvero l'accesso a un server ben protetto, potrebbe ritenerlo utile infastidirti, registrare i tasti premuti per ottenere password, ecc. O potrebbe essere più facile infastidire un utente, forse sono meno consapevoli della sicurezza.
  • ecc ecc

In poche parole, puoi assicurarti a un livello, a seconda del tuo budget. Decidi quanto sei disposto a spendere in base a ciò che vuoi proteggere. Accetta che ci sarà qualche rischio residuo.

E poi pianifica che qualcosa vada storto: a un certo punto la tua sicurezza verrà interrotta e dovrai sapere come rispondere. Per un semplice file server questo processo può essere semplicemente cancellato e reinstallato dal backup, ma per qualcosa di più complesso potrebbe essere necessario informare utenti, stakeholder, regolatori, ecc., Archiviare prove, fare copie forensi, ricostruire, riconfigurare o rimediare in qualche modo l'incidente ... e quindi sfruttare le esperienze di apprendimento per rivalutare il piano di sicurezza.

... e poi ... Ripeti tutto di nuovo. Rivaluta regolarmente la tua sicurezza e il tuo appetito di sicurezza, dato che è un mondo in rapida evoluzione là fuori!

16
Rory Alsop

Supponiamo che tu abbia un server web, che richiede un comando:

OTTIENI /helloworld.txt

E questo restituisce, molto semplicemente, "Ciao, mondo!"

Questa è la cosa più semplice al mondo da programmare, giusto? Supponendo di prendere l'input, verificare la stringa "GET /helloworld.txt" e fare la cosa giusta, quindi ignorare qualsiasi altra cosa, quali sono le possibilità per l'hacking? Nessuna?

OK. Qual è la dimensione del buffer dei comandi? 20 byte? Abbastanza a lungo da accettare quel comando? E se qualcuno dà un comando che è più lungo di due byte? E se danno un comando più lungo di 2000 byte? Come si riceve effettivamente il comando? Cosa parla con la scheda di rete? Cosa significa la decodifica dei pacchetti? Cosa succede se i caratteri vengono inviati in due pacchetti, senza terminazione NUL tra i byte?

In breve, anche questo "più semplice" dei programmi di rete, che non ha nemmeno bisogno dell'accesso con password, potrebbe avere MOLTI difetti di sicurezza.

Semplicemente, si tratta di complessità. Ogni volta che viene introdotta una variabile, il numero di POSSIBILI vettori di attacco aumenta esponenzialmente. Non tutti saranno vettori di attacco, ma POTREBBERO esserlo, quindi è necessario coprirli tutti, se si intende essere sicuri.

È praticamente impossibile, senza un sistema completamente controllato, completamente testato, progettato per contratto e forse persino matematicamente provato. Per quanto ne so, non esiste un tale sistema. OpenBSD potrebbe avvicinarsi, ma dubito che sia finita lì.

La risposta molto breve è: con la sicurezza, sempre assumere il peggio. È MOLTO più intelligente sapere che sei vulnerabile e agire in modo adeguatamente umile, rischiando il meno possibile, piuttosto che supporre di essere al sicuro semplicemente perché non riesci a pensare a un possibile vettore di attacco.

7
user24793

Se fai tutto e lo fai correttamente, puoi prevenire molti attacchi diversi. Sfortunatamente, l'hacking è molto più che attaccare direttamente login/accesso.

Una parte importante include l'esclusione della protezione, quindi un utente malintenzionato non deve conoscere la password. L'ingegneria sociale è un'altra grande parte. Le password non proteggono nulla, se sono conosciute dagli aggressori. Inoltre, ci sono attacchi e bersagli più dannosi del semplice accesso al pannello di amministrazione. Se qualcuno non vuole che tu gestisca un negozio online, perché ha i suoi e vuole mantenere i suoi clienti (e tu fuori dal mercato), come vuoi prevenire un attacco DDoS o semplicemente qualcuno che stacca la spina nel tuo server camera? (La donna delle pulizie, che voleva solo spolverare la scheda madre?;))

Inoltre, il monitoraggio non aiuta davvero a prevenire attacchi.

Esistono diversi tipi di sistemi di protezione, risposta alla manomissione, resistenza alla manomissione e manomissione. I sistemi anti-manomissione vogliono rallentare gli attacchi (ad es. Password lunghe). La risposta alla manomissione ti informa se si sta verificando un attacco (ad es. Un allarme che si spegne se il tuo IDS rileva alcune stringhe di iniezione SQL) e il sistema in grado di evidenziare eventuali manomissioni ti mostra come sono avvenuti gli attacchi reali (ad es. File di registro)

Gli hacker cercano di decifrare o evitare questa protezione ed è il tuo compito essere un passo avanti. Naturalmente questo è molto difficile, dato che a malapena si conoscono eventuali buchi di sicurezza nel software del server, che possono consentire a un utente malintenzionato di accedere alle informazioni di root senza una password. Di solito gli attaccanti trovano prima questo tipo di debolezza ed è tuo compito prendersi cura del tuo sistema e rallentare i loro attacchi fino a quando il problema non viene risolto.

4
user1451340

Rendi la password dell'account amministratore abbastanza lunga e complicata (cioè teoricamente, la password non può essere decifrata entro un tempo ragionevole).

Incrinato dalla forza bruta? No. Craccato dall'ingegneria sociale? Sì. Se molte persone conoscono la password, non è troppo difficile ottenerla tramite il social engineering. (ogni volta che più di una persona conosce la password, è possibile utilizzare la rappresentazione in modo efficace per ottenere la password). Se solo tu hai accesso, allora, l'accesso fisico può essere raggiunto tramite il social engineering. È più difficile gestirlo, però, e devi chiederti se vale davvero la pena.

Monitorare ogni traffico di rete in entrata verso i file amministrativi.

Questo non ti protegge da DDoS. E se vuoi proteggere da DDoS, ci saranno troppi falsi positivi di utenti che vengono ingiustamente bloccati.

Anche se la tua password è lunga, una botnet può entrare. Se hai una sorta di restrizione sul numero di volte in cui puoi fallire un tentativo di password, allora possono bloccare t.

Inoltre, i CAPTCHA non sono più così sicuri, ci sono molte entità che pagano soldi perché la gente si sieda tutto il giorno e risolva i captcha.

Per estendere il livello di protezione dal n. 2 in alto, monitorare le modifiche ai file locali (specialmente quelle che hanno comandi che richiedono i privilegi di Sudo.

Non è possibile monitorare completamente tutte le modifiche ai file. Ci sono troppe informazioni. La maggior parte dei programmi esegue molti problemi con i file durante l'esecuzione. Come distingueresti tra un aggiornamento del programma e un file dannoso?

Convalida ogni input dell'utente, in modo che tutti gli input dell'utente siano sicuri.

Assicurati di fare questo lato server.


Infine, gli exploit zero day sempre costituiranno un problema. Se qualcuno rileva una vulnerabilità di sicurezza nel framework in uso, viene affondato. Per evitare ciò, utilizzare framework ampiamente utilizzati e sperare per il meglio.

Proteggersi dagli hacker è come cercare di proteggere un bunker sottomarino pieno di sodio. Ci sono molti posti che ritieni debbano essere riparati. Puoi rattopparli tutti. Ma ciò non significa che tu sia al sicuro - tutto ciò che serve è una piccola perdita in un posto che non hai ispezionato per far crollare tutto.

3
Manishearth

"Difendere correttamente" significa: "il mio codice non ha bug, nessuno degli strumenti che uso". Ma il software ha dei bug; l'hardware ha dei bug; nessuno sa come garantire l'inesistenza di bug in un software o hardware non banale (chi afferma il contrario è delirante o bugiardo, o entrambi). Vedi questa domanda precedente per qualche discussione.

Il modo pratico in cui si verificano gli attacchi è quando un utente malintenzionato scopre o viene a conoscenza di un bug che può essere sfruttato a suo vantaggio e prima che il proprietario del sistema lo apprenda e lo risolva.

Dalla tua lista:

  • Una password amministratore grande, grossa, casuale, indiscutibile va bene, purché il computer su cui l'amministratore digita la sua password non sia infetto da alcuni malware keylogger.

  • Il monitoraggio aiuta principalmente per l'analisi post mortem; non impedisce l'attacco, ma ti aiuta a determinare cosa è successo, quale bug è stato sfruttato, in modo che possa essere risolto ... per la prossima volta.

  • Non esiste un "input sicuro dell'utente garantito". Esiste "l'input dell'utente che è stato verificato essere conforme a un insieme specifico di regole, il che dovrebbe significare che l'input dell'utente in questione può essere utilizzato in una data costruzione senza incontrare situazioni scomode". Ad esempio, un pezzo di testo può essere "sicuro per l'inclusione in un file HTML" (non contiene alcuni caratteri speciali HTML che attivano l'elaborazione avanzata, come '<' e '&'), ma non è affatto sicuro per inclusione in una query SQL (i caratteri HTML sicuri potrebbero codificare una query SQL totalmente non sicura).

3
Tom Leek

Sto cercando di costruire sistemi antiproiettile da quasi dieci anni. Ho dovuto imparare tecniche di progettazione ad alta sicurezza (ad es. EAL7), canali segreti, attacchi Subversion, ecc. Onestamente, la maggior parte dei progettisti o amministratori di sistema non ha né le conoscenze né le risorse per proteggere totalmente una macchina da attacchi noti. È quasi impossibile visti i vincoli aziendali. La maggior parte delle decisioni di sicurezza riflettono compromessi tra costi, funzionalità, usabilità, compatibilità legacy, probabili profili di aggressori, ecc.

Se vuoi sapere, ecco una delle mie analisi semplificate sui vari livelli e problemi di sicurezza. (E non ha le dimensioni di un libro 8). È stato indirizzato a un ragazzo che pensava che i programmatori di alto livello potessero creare programmi sicuri, ma è possibile subamministrare per il programmatore e comunque gli stessi risultati. Divertiti e impara le lezioni meno ripeti la storia come fa gran parte della comunità INFOSEC. ;)

http://www.schneier.com/blog/archives/2013/01/essay_on_fbi-ma.html#c1102869

Questo commento di follow-up contiene numerosi link che tracciano la storia, i fattori del governo, i requisiti di sviluppo, ecc. Elencherò anche un sacco di sistemi e processi esemplari. Ognuno potrebbe avere dei difetti in agguato ma ispira più fiducia rispetto al prodotto medio.

http://www.schneier.com/blog/archives/2013/01/essay_on_fbi-ma.html#c1105156

2
Nick P

Solo per aggiungere alcuni punti:

Rendi la password dell'account amministratore abbastanza lunga e complicata (cioè teoricamente, la password non può essere decifrata entro un tempo ragionevole).

Le password lunghe e complicate, seppure buone, aumentano la probabilità che vengano scritte. Lo stesso vale per le password che devono essere cambiate spesso. Soprattutto se più di una persona ha bisogno della password o è una password che non viene utilizzata spesso.

Monitorare tutto il traffico di rete in entrata verso i file amministrativi.

Gli attacchi di escalation di privilegi lo renderanno inutile, poiché i cambiamenti sembreranno provenire dal traffico locale, non dalla rete. E un monitoraggio eccessivo aprirà nuove problematiche. Overflow del buffer Gli exploit sono comuni. Diamine, alcuni router di consumo continuano a soffocare sui tentativi di traffico bloccato che intasano le sue tabelle di connessione.

Per estendere il livello di protezione dal n. 2 sopra, monitorare le modifiche ai file locali (in particolare quelli che hanno comandi che richiedono i privilegi di Sudo).

Meglio, ma gli attacchi all'escalation dei privilegi potrebbero consentire a qualcuno di caricare un file binario e aggiungere bit appiccicosi suid/sgid. Non sarà nel tuo elenco di file da controllare.

Convalida tutti gli input dell'utente, in modo che tutti gli input dell'utente siano sicuri.

Quanto impegno farai in questo? La sanificazione dell'input dell'utente non è mai efficace al 100%.

Fondamentalmente, il punto è che alcune cose che fai causeranno più problemi che non farle, ci sono sempre modi per aggirarlo, cerca solo di fare del tuo meglio e spero che tu non commetta un errore ossessionato. Sii come un disinfettante. Puoi uccidere solo il 99% del problema.

"È possibile non commettere errori e perdere ancora. Questa non è una debolezza, questa è la vita." - Picard

2
cde

Non hai definito cosa significhi hackerare il tuo server.

Il primo passo è definire qual è lo scopo dell'accesso legittimo al sistema. Chi sono gli utenti e cosa fornisce il sistema agli utenti che richiedono di essere protetti?

Se il sistema è dedicato a una funzione molto specifica e limitata (come servire una particolare applicazione distribuita) e gli aggressori possono accedere a quel sistema solo attraverso la rete, allora praticamente solo quell'applicazione deve essere sicura, oltre alle parti di rete esposte di il sistema: l'adattatore LAN, il suo driver e lo stack di rete.

La vera sfida in termini di sicurezza in un sistema operativo come Linux è come rendere il sistema operativo non integrabile in una situazione multiutente quando le persone hanno un uso quasi completo del sistema e possono accedere agli account del sistema operativo ed eseguire direttamente le applicazioni.

Un sistema può avere incidenti di sicurezza senza compromettere l'account del superutente. Supponiamo di avere un sistema Linux perfettamente indistruttibile. Tuttavia, l'utente joe installa un'applicazione non sicura /home/joe/bin. Tale applicazione apre un documento dannoso, che sfrutta un difetto nell'applicazione, mediante il quale il codice dannoso ottiene l'esecuzione di codice arbitrario nel contesto di sicurezza di joe. Il codice dannoso danneggia i dati di joe e ruba anche il tempo della CPU dalla macchina. (Provare come potrebbe, tuttavia, non può ottenere i privilegi di esecuzione del superutente, perché la macchina è "non bloccabile").

È hackerato? O non violato? Che ne dici dal punto di vista dell'utente joe. joe si preoccupa che root non sia mai stato compromesso nell'incidente?

2
Kaz

Se le persone (o almeno i tuoi amministratori) non hanno mai commesso errori e i programmi per computer sono sempre stati privi di errori al 100%, in teoria hai ragione. Sfortunatamente, nessuno di questi è mai vero ed è abbastanza facile per un attaccante attaccare in questi punti.

Anche perfettamente configurato, il software non è in grado di agire in quanto è configurato continuamente a causa di bug. Nelle giuste condizioni, potrebbe essere possibile far fare al software qualcosa che non dovrebbe.

Allo stesso modo, il social engineering è probabilmente la forma più comune di hacking. Non sono necessarie misure tecniche complesse quando puoi semplicemente ingannare il tuo avversario per darti quello che vuoi. Spostarsi a spalla navigando la password, ottenere un key-logger su un computer che l'amministratore utilizza o ingannare un amministratore che esegue il proprio software dannoso sono tutti modi possibili per sgattaiolare sotto il radar.

Puoi compensare molto di questo bloccando un server in una stanza senza connessione a Internet e consentendo solo agli amministratori di utilizzare il sistema mentre si trova nella stanza con una guardia alla porta, e infatti, questo è quante reti governative ad alta sicurezza operare, ma pone un enorme ostacolo all'usabilità.

In definitiva, la sicurezza consiste nel bilanciare usabilità e rischio. I passaggi che descrivi richiedono troppa riduzione dell'usabilità per essere implementati in modo sicuro e quindi non possono funzionare da soli in una situazione del mondo reale. La sicurezza è un campo complesso e in continua evoluzione che richiede di rimanere aggiornato sulle minacce, di controllare le difese contro le nuove minacce e di essere sicuro di monitorare i compromessi che possono verificarsi come problemi di 0 giorni.

2
AJ Henderson