In che modo Twitter e GitHub possono essere sicuri di non essere stati violati?

Non possono essere sicuri. In effetti, non puoi mai essere sicuro di non essere stato violato. Ma un esame approfondito può farti concludere che è più o meno probabile.

Le dichiarazioni di Twitter dicono solo che non vi è alcuna indicazione di un hack. Ciò non esclude la possibilità che siano stati hackerati e, sollecitando i propri utenti a cambiare le loro password, ammette implicitamente che.

Per quanto riguarda GitHub, la formulazione è un po 'più categorica. Ma penso che forzare una reimpostazione della password mostra che capiscono i rischi coinvolti.

Un'altra cosa da notare è che in entrambi i casi la perdita era in un sistema di registrazione puramente interno. Non vi è alcuna indicazione che gli utenti di terze parti abbiano mai avuto accesso a questo sistema. I sistemi di registrazione interni vengono raramente esposti esternamente e consultati internamente solo quando un sistema richiede la risoluzione dei problemi. Questo è probabilmente anche il motivo per cui questo bug è passato inosservato per mesi: voci di registro singolari da qualche parte in quella che probabilmente è una quantità enorme di altre affermazioni di solito non vengono notate a meno che non si trovino proprio accanto o nel mezzo delle dichiarazioni necessarie per effettua il debug di altre voci.

Twitter ha scoperto anche solo recentemente il bug, il che significa che è improbabile che le persone esterne all'azienda fossero a conoscenza di questo bug prima che Twitter fosse, figuriamoci e ha eseguito un attacco per recuperarli.

È difficile dimostrare un aspetto negativo.

Quindi come si dimostra un positivo? In questo caso: come provi un attacco dall'esterno? In genere esistono diversi sistemi per monitorare diverse forme di attacchi, violazioni o accessi. Questi possono essere firewall, sistemi di rilevamento delle intrusioni, SIEM e una varietà di sistemi di monitoraggio e registrazione. Nelle reti odierne ogni componente ha una qualche forma di monitoraggio o consente il monitoraggio tramite strumenti di terze parti come Check_MK.

Quindi ogni fase del percorso - dal confine della rete aziendale alla macchina che conteneva la preziosa informazione stessa - è in qualche forma o forma monitorata. Questi registri sono, a seconda della rete e delle politiche aziendali, regolarmente analizzati. I sistemi di analisi possono distinguere tra traffico o comportamento previsto e inaspettato. Un comportamento Un / Expected è per esempio l'accesso ai file.

I file di registro interni sono in genere considerati dati riservati, pertanto è probabile che venga monitorato anche l'accesso ai file. Se qualcuno che non fa parte di un determinato gruppo di utenti tenta di copiare / accedere a un file di registro interno, probabilmente sarebbe stato registrato come comportamento imprevisto o addirittura proibito. Se un possibile avversario era in grado di impersonare qualcuno con i diritti per accedere a questo file, sarebbe stato registrato anche come comportamento previsto.

In teoria è possibile che un utente malintenzionato sia in grado di superare tutti i controlli di sicurezza, sfruttare le vulnerabilità 0day, non lasciare traccia in ogni registro di ogni componente, IDS, SIEM e così via, copiare il file di registro interno e contraffarlo fuori, ma è molto improbabile.

La mia ipotesi è , che dopo che il file di log è stato scoperto, tutti questi log sono stati analizzati a fondo per provare a provare se c'è stato un attacco dall'esterno. Gli analisti non hanno trovato dati sospetti e quindi hanno concluso che con quasi assoluta certezza non ci sono stati attacchi dall'esterno. E questo è ciò che vedi nel comunicato stampa di Twitter (vedi il commento di Florin Coada). Di nuovo, la mia ipotesi: il comunicato stampa di GitHub aveva un linguaggio più stretto per fermare le speculazioni se c'era un trucco. (Non ha funzionato davvero.;)

^{Naturalmente è anche possibile che Twitter e GitHub non abbiano controlli di sicurezza del genere, ma spero davvero di no.}

Suppongo che abbiano registri di accesso per qualsiasi cosa succeda sui loro server, possono controllare se qualcuno ha avuto accesso al file, quando è stato, con quale alias hanno effettuato l'accesso, il loro indirizzo IP sorgente, ecc. Se possono provare a loro stessi che tutti gli accessi erano da parte di dipendenti legittimi possono dire con sicurezza di non essere stati hackerati. Nota che questo in realtà non garantisce che non vengano violati, solo che tutti i punti di prova in quella direzione.

La risposta è molto semplice. In nessun luogo affermano di essere sicuri. Infatti, implicitamente ti dicono che in realtà potrebbe esserci una violazione in due modi:

1. Dicono che non c'è "nessuna ragione per credere che ci siano" o "nessuna prova di" una violazione. La mancanza di prove potrebbe semplicemente significare che gli intrusi hanno coperto le loro tracce.
2. Ti imploro di cambiare la tua password, solo per essere al sicuro. Ciò implica che non possono garantire che non si sia verificata alcuna violazione.

La mia interpretazione, in particolare dell'affermazione GitHub più audace, è che vogliono dire che il fatto che le password siano state inserite nel file di log non è il risultato di un attacco di hacking, ma il risultato di uno sviluppatore che introduce il codice di debug per caso in produzione. Questo è rilevante dal momento che un utente malintenzionato potrebbe aver introdotto questa funzionalità al fine di raccogliere le password per accedervi in seguito.

Non c'è alcuna garanzia che non siano mai stati hackerati e che non lo saranno mai, ma questo incidente è indipendente dai tentativi di hacking.

Grandi aziende come questa dovrebbero avere molti server e quindi tutti gli accessi esterni sono instradati attraverso un host bastion (significato esterno non dall'interno della gabbia / stanza del server). Il bastione potrebbe dire che la registrazione è stata configurata in un modo poiché trasmette tutti i comandi dalla rete esterna ai server operativi. I comandi se registrati possono essere facilmente usati per dire se qualcuno ha aperto un file con Vim ad esempio e questo risolverebbe la domanda se un utente fosse stato violato. L'accesso SSH viene registrato anche in modo che un IP / s "buono" noto possa essere filtrato per un utente e qualsiasi voce sospetta o dispari possa essere esaminata dall'IT e se una voce non è stata spiegabile, ciò costituirebbe una violazione. Altrimenti il server sarebbe "sicuro" e non ci sarebbe più bisogno di preoccuparsi di questo argomento.

In realtà stanno dicendo che sono sicuri al 100% che c'è stata effettivamente una violazione della sicurezza. Accidentalmente. Probabilmente. E da soli. Il resto è lucido.

Possono vedere diversamente l'individuo, come dipendente, ma io no. Un buon hacker lavora dall'interno e guadagna fiducia. NSA? FSB?

Non dovrebbero mai avere un accesso semplice alle nostre password. Non è così che funziona l'accesso con password. Le implicazioni sono che ora spetta a te cambiare la password ovunque tu l'abbia mai usata. Supponiamo che la password sia ora nota a tutti.