Domanda:
Esporre l'ora del server è un rischio per la sicurezza?
Manny
2018-06-08 14:15:12 UTC
view on stackexchange narkive permalink

Se creo un servlet che restituisca l'ora del server pubblicamente (senza bisogno di autenticazione), sarebbe un problema di sicurezza? Non riuscivo a pensare a nessun problema con questo, ma in qualche modo qualcosa mi dice che potrei sbagliarmi.

Per spiegare di più, questo endpoint verrà utilizzato dalle app mobili per migliorare la loro sicurezza (per evitare di barare regolando la data del dispositivo).

Quello che avresti dovuto chiedere era "Qual è il rischio per la sicurezza che espone pubblicamente il tempo del mio server?"Esporre ** qualsiasi cosa ** sul tuo sistema è un rischio potenziale, sebbene il tempo (supponendo che sia accurato) è all'estremità più bassa dello spettro delle minacce.
A proposito, l '"ora del server" dovrebbe essere UTC e impostata tramite NTP, il che significa che è comunque un'informazione pubblica.(Oh, e se stai scrivendo servlet direttamente invece di utilizzare un framework come Spring o Dropwizard, è molto più probabile che l'implementazione manuale causi vulnerabilità di sicurezza piuttosto che esporre il tempo.)
Dovresti presumere che possano cambiare qualsiasi cosa.Se sono disposti a cambiare la data sul loro telefono, chi può dire che non intercetteranno la risposta dal server al firewall e cambieranno la data anche lì?L'unica cosa su cui puoi fare affidamento su un cliente per dirti è ciò che il cliente vorrebbe fare.Qualsiasi altra convalida, non importa quanto banale, deve essere considerata compromessa e verificata da qualche parte di cui ci si può fidare.
Sette risposte:
#1
+87
forest
2018-06-08 14:22:40 UTC
view on stackexchange narkive permalink

L'ora del server è di scarsa utilità per un utente malintenzionato, in genere, purché sia ​​accurata. In effetti, ciò che viene rivelato non è il tempo attuale (dopotutto, a parte la fisica relativistica, il tempo è coerente ovunque) quanto la differenza di tempo. Si noti che, anche se non si rivela esplicitamente l'ora, spesso ci sono molti modi per ottenere comunque l'ora del server locale. Ad esempio, TLS fino alla versione 1.2 incorpora l'ora corrente nell'handshake, le pagine web possono mostrare le date dell'ultima modifica delle pagine dinamiche, le risposte HTTP stesse possono includere l'ora e la data correnti nelle intestazioni delle risposte, ecc.

Conoscere l'esatto disallineamento dell'orologio di un server è un problema solo in modelli di minacce molto specifici:

  • L'inclinazione dell'orologio può essere utilizzata negli attacchi per rendere anonimi i servizi nascosti di Tor.

  • Le applicazioni scritte male possono utilizzare l'ora del server per generare valori segreti.

  • Le condizioni ambientali dell'RTC possono essere rivelate in situazioni artificiose.

[L'ora corrente deve essere inviata anche in qualsiasi risposta HTTP] (https://tools.ietf.org/html/rfc7231#section-7.1.1.2).
Diventa un problema quando l'ora del server non è precisa?
@ToddSewell Se l'ora del server non è precisa, un utente malintenzionato può abusarne in vari modi.TLS e i certificati in generale si basano sull'orario di sistema preciso.
In relazione, ho scritto una guida a una serie di [diversi modi in cui è possibile determinare l'ora su un server remoto] (https://github.com/gsuberland/infosec-tricks/blob/master/remote_server_time.md).
_ "fintanto che è accurato" _ Questo sembra implicare che il tempo del server * in * accurato sarebbe un problema di sicurezza.È?Se é cosi, come?
Un altro paio di punti relativi alla sicurezza;Il tempo sincronizzato è a volte una dipendenza incorporata per la correttezza di alcuni sistemi distribuiti, come Cockroach DB che utilizza timestamp per risolvere conflitti di transazione o per proteggere dagli attacchi di riproduzione, come nel protocollo di autenticazione a pacchetto singolo utilizzato dallo strumento di riconfigurazione del firewall remoto dinamico"fwknop".Non escluderei la possibilità che qualche attaccante intelligente e determinato possa trovare un modo per sfruttare la conoscenza dello skew dell'orologio (specialmente i cambiamenti nello skew dell'orologio * nel tempo *) e alcuni protocolli simili per la corruzione dei dati o DoS.
"dopotutto, salvo la fisica relativistica, il tempo è coerente ovunque" Ma i dati che passano attraverso un cavo in fibra ottica si muovono a circa 2 / 3c.(Raggiungere la destinazione potrebbe essere più lento poiché la luce rimbalza molto, ma si sta ancora muovendo * dang * velocemente.)
@jpmc26 Ma i dati sono luce che non ha massa, quindi la loro velocità non causa effetti di dilatazione temporale (semplificando un po 'qui, poiché i fotoni tecnicamente sono "congelati" nel tempo dalla loro creazione al loro assorbimento).
@ray Un orologio impreciso è un problema di sicurezza.Come ho accennato brevemente sopra, TLS richiede un tempo preciso per essere sicuro.Lo stesso vale per molte altre attività relative ai certificati come la verifica crittografica eseguita dal gestore dei pacchetti.
@forest quindi sarebbe un attacco, se il server richiede certificati client e sai che il suo orologio è indietro di sei mesi, puoi invece dargli un certificato scaduto?Tuttavia, non è necessario avere il tempo a disposizione per effettuare un attacco del genere: puoi comunque provarlo.
@OrangeDog Esatto.Non volevo dire che un orologio storto è un problema solo se sai che è inclinato.
#2
+11
Marcus Müller
2018-06-08 14:24:02 UTC
view on stackexchange narkive permalink

"Servlet" sembra che tu stia già eseguendo un server complesso.

Ci sono molti modi in cui i protocolli perdono l'ora del server. Ad esempio, HTTP ha un campo di intestazione popolare per l'ora di creazione / modifica e i dati generati dinamicamente avrebbero sempre l'ora di sistema corrente, se usati correttamente.

Per motivi di autenticazione TLS, puoi anche cercare binarie per trovare la data e l'ora di un endpoint utilizzando i certificati client in scadenza.

Questo è un male necessario: se stai facendo TLS, il tuo server deve avere un'idea del tempo per sapere cos'è una chiave / certificato valido e cosa no . Se è così, molto probabilmente sarà un momento coordinato dall'NTP. Quindi, non puoi davvero dire nulla sul server che un utente malintenzionato non saprebbe già: c'è davvero solo un momento "corretto".

Se non stai facendo TLS: l'ora di sistema che perde è probabilmente non è la prima cosa da sistemare.

Per quanto riguarda la sicurezza: Non sono proprio sicuro che dovresti esporre ancora un altro servlet solo per i dispositivi per capire l'ora mondiale.

Per spiegare di più, questo endpoint verrà utilizzato dalle app mobili per migliorare la loro sicurezza (per evitare barare modificando la data del dispositivo).

Bandiera rossa . Dipende dalla mancanza di modifiche del tuo cliente per la sicurezza. Non farlo mai. Semplicemente non puoi fidarti di tutto ciò che accade sui dispositivi dei tuoi utenti. Questi non sono i tuoi dispositivi. Possono semplicemente collegare un debugger e modificare le nozioni di tempo in memoria del processo, indipendentemente dal fatto che sia mantenuto dal sistema operativo del telefono o dall'applicazione.

Penso che tu abbia frainteso la parte "Spiegare di più ..".Al contrario, presumo già che gli utenti di app mobili abbiano maggiori probabilità di modificare l'ora del dispositivo per imbrogliare, ecco perché ho bisogno del tempo del server per il controcontrollo.Se c'è un modo più corretto per farlo, sono tutt'orecchi.Ma grazie anche per il tuo contributo.
@Manny: invia ogni comando al server.Chiedi al server di verificare ogni azione.Si può presumere nel codice client che il server approverà ed eseguirà le conseguenze.Se risulta che il server rifiuta un'azione (un secondo dopo, ad esempio,), ripristina il client.In questo modo, il tuo server è l'autorità.Il tuo server è (dovrebbe essere) al 100% sotto il tuo controllo e lì puoi fidarti di cose come l'ora del sistema.
L'ora di sistema "che perde" non dovrebbe mai essere corretta.È necessario che sia rivelato per il corretto funzionamento di TLS e HTTP.
@OrangeDog esattamente quello che ho detto nella mia risposta.
#3
+2
pjc50
2018-06-08 20:30:15 UTC
view on stackexchange narkive permalink

L'unica cosa che potrebbe davvero esporre un rischio per la sicurezza sono i timer ad alta precisione e i contatori delle prestazioni. Questi potrebbero essere usati per calcolare con precisione quanto tempo un processo crittografico impiega sul server e da lì dedurre dati segreti.

È improbabile che i dati temporali al millisecondo o alla normale frequenza di "tick" lo rivelino. p>

#4
+2
Tom
2018-07-06 15:06:46 UTC
view on stackexchange narkive permalink

L'ora del server non è un segreto . Al contrario, sei fortemente incoraggiato a sincronizzare il tuo tempo con una fonte di tempo oggettiva esterna (come un orologio atomico esposto attraverso un server orario).

Non essere un segreto ha due conseguenze:

  1. non è necessario proteggerlo o nasconderlo. Puoi tranquillamente presumere che l'attaccante sia in grado di capire qual è l'ora corrente.
  2. non dovrebbe avere una funzione su tutto ciò che desideri proteggere o nascondere. Ad esempio, non dovresti derivare chiavi o segreti dall'ora. Tutte le funzioni casuali che stai utilizzando dovrebbero essere inizializzate non con l'ora corrente (ancora un valore predefinito pigro in molti), ma con una migliore fonte seed.
#5
+1
Serge Ballesta
2018-06-08 17:44:49 UTC
view on stackexchange narkive permalink

Conoscere l'ora del server è di scarsa utilità per un utente malintenzionato. Quindi qui dovresti trovare i possibili effetti collaterali.

  • La protezione per quel servlet è più debole (in qualche modo) di quella degli altri servlet? Quali sono le possibili implicazioni della non necessità di autenticazione in termini di attacchi DOS / DDOS. Potrebbe essere importante se l'autenticazione fosse elaborata in altri server più protetti. C'è qualche differenza per il proxy inverso?
  • quali sono i rischi di falle di sicurezza in quel servlet? Ha seguito gli stessi controlli assicurativi di qualità degli altri servlet? E il suo ciclo di manutenzione?
  • e il suo contenitore servlet?
#6
+1
Javatasse
2018-06-09 03:44:07 UTC
view on stackexchange narkive permalink

Vorrei rispondere sottolineando ciò che deriverebbe dal presupposto che l'esposizione dell'ora del server sarebbe di fatto un rischio, significherebbe che gli amministratori di sistema dovrebbero impostare orari casuali sui loro sistemi, perché qualsiasi il server impostato sull'ora corretta sarebbe vulnerabile, poiché l'ora del server corretta o quasi corretta è solo facile da indovinare. Significherebbe anche uno sforzo di sviluppo estremo per tradurre un'impostazione falsa in un'ora corretta da utilizzare in ogni applicazione correlata al tempo. Ogni singolo file sul sistema avrebbe un timestamp errato.

In base alla mia esperienza, si creano molti più problemi impostando orari del server sbagliati, di quanto ci si possa aspettare con l'impostazione corretta. Alcuni esempi sono menzionati in altre risposte, ma devi anche considerare applicazioni o cluster distribuiti, dove le impostazioni corrette dell'ora sono generalmente essenziali. Fondamentalmente, qualsiasi informazione relativa al tempo che memorizzi sarebbe difettosa.

Quindi, se esporre il tuo tempo di sistema fosse il tuo rischio più grande, sei stato fortunato. Ma molto probabilmente ci sono molte altre preoccupazioni a cui non hai prestato abbastanza attenzione. Vedi https://www.owasp.org/index.php/Main_Page per problemi e best practice relativi alla sicurezza.

#7
+1
user195233
2018-12-24 12:15:12 UTC
view on stackexchange narkive permalink

L'unica cosa a cui posso pensare è se hai esposto il tempo di "uptime" del server - questo potrebbe fornire un'indicazione delle ultime patch installate; tuttavia, credo che di solito questo non sia esposto pubblicamente, ma non l'ho verificato, quindi potrebbe valere la pena confermarlo se sei interessato.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...