Non possono esserne 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 c'è alcuna indicazione di un hack. Ciò non esclude la possibilità che siano stati hackerati e, esortando i propri utenti a modificare le password, lo ammettono implicitamente.

Per quanto riguarda GitHub, la formulazione è un po 'più categorica. Ma penso che forzare la reimpostazione della password dimostri che comprendono 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 utenti di terze parti abbiano mai avuto accesso a questo sistema. I sistemi di registrazione interni sono raramente esposti esternamente e vengono consultati internamente solo quando un sistema necessita di risoluzione dei problemi. Questo è probabilmente anche il motivo per cui questo bug è passato inosservato per mesi: singole voci di registro da qualche parte in quella che probabilmente è una quantità gigantesca di altre istruzioni di solito non vengono notate a meno che non si trovino proprio accanto o nel mezzo di istruzioni che sono necessarie per eseguire il debug di altre voci.

Anche Twitter solo di recente ha scoperto il bug stesso, il che significa che è improbabile che persone esterne all'azienda fossero a conoscenza di questo bug prima che Twitter fosse, figuriamoci se lo scoprisse ed eseguisse un attacco a recuperarli.

È difficile dimostrare un valore negativo.

Quindi come si dimostra positivo? In questo caso: come si dimostra 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 le informazioni preziose, è in qualche modo monitorata. Questi registri vengono analizzati regolarmente, a seconda della rete e delle politiche aziendali. I sistemi di analisi possono distinguere tra traffico o comportamento previsto e imprevisto. Il comportamento imprevisto è per l'accesso ai file di istanza.

I file di registro interni sono generalmente considerati dati riservati, quindi è probabile che anche l'accesso ai file venga monitorato. 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 fosse stato in grado di impersonare qualcuno con i diritti di accesso a questo file, anche questo sarebbe stato registrato, ma come previsto.

In teoria è possibile che un attaccante sia in grado di superare tutti i controlli di sicurezza, sfruttano le vulnerabilità di 0day, non lasciano traccia in ogni registro su ogni componente, IDS, SIEM e così via, copia il file di registro interno e contrabbandalo all'esterno, 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 dimostrare se c'è stato un attacco dall'esterno. Gli analisti non hanno riscontrato dati sospetti e hanno quindi concluso che con certezza quasi assoluta non vi era alcun attacco dall'esterno. E questo in realtà è quello 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ù rigoroso per fermare le speculazioni se ci fosse un hack. (Non ha funzionato davvero.;)

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

Presumo che abbiano registri di accesso per qualsiasi cosa accada sui loro server, possono verificare se qualcuno ha avuto accesso al file, quando è stato, quale alias ha effettuato l'accesso, il loro indirizzo IP di origine, ecc. stessi che tutti gli accessi sono stati effettuati da dipendenti legittimi che possono tranquillamente affermare di non essere stati violati. Nota che questo in realtà non garantisce che non vengano violati, ma solo che tutte le prove puntano in quella direzione.

La risposta è molto semplice: non dicono da nessuna parte di essere sicuri, anzi, ti dicono implicitamente che in realtà potrebbe esserci stata una violazione in due modi:

1. Dicono che lì è "nessun motivo per credere che ci fosse" o "nessuna prova di" una violazione. La mancanza di prove potrebbe semplicemente significare che gli intrusi hanno nascosto le loro tracce.
2. Ti implorano 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 più audace di GitHub, è 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 accidentalmente in produzione. Ciò è rilevante poiché un utente malintenzionato potrebbe aver introdotto questa funzionalità per raccogliere le password per acquisirle in seguito.

Non vi è alcuna garanzia che non siano mai state violate e non lo saranno mai, ma questo incidente è indipendente dai tentativi di hacking.

Le grandi aziende come questa dovrebbero avere molti server e quindi tutti gli accessi esterni vengono instradati attraverso un bastion host (al di fuori del significato non dall'interno della gabbia / stanza del server reale). Il bastione potrebbe dire che la registrazione è stata configurata in un modo poiché inoltra tutti i comandi dalla rete esterna ai server operativi. I comandi se loggati potrebbero essere facilmente usati per dire se qualcuno ha aperto un file con vim, per esempio, e questo risolverebbe il problema se un utente fosse stato violato. Anche l'accesso SSH viene registrato in modo che uno o più IP "buoni" noti possano essere filtrati per un utente e qualsiasi voce sospetta o strana potrebbe essere esaminata dall'IT e se una voce non è stata in grado di essere spiegata, ciò costituirebbe una violazione. Altrimenti il ​​server sarebbe "sicuro" e non ci sarebbe tanto bisogno di preoccuparsi per questo problema.

Quello che stanno effettivamente dicendo è che sono sicuri al 100% che ci sia stata effettivamente una violazione della sicurezza. Accidentalmente. Probabilmente. E da soli. Il resto è lucido.

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

Non dovrebbero mai avere accesso in testo semplice alle nostre password. Non è così che funziona l'accesso tramite password. Le implicazioni sono che ora spetta a te cambiare quella password ovunque tu la usi. Supponiamo che la password sia ora conosciuta da tutti.