Un'analisi più approfondita dell'incidente di sicurezza di maggio 2019: feedback sul post del blog
Abbiamo appena pubblicato un aggiornamento dell'incidente di sicurezza accaduto a maggio 2019 con i dettagli tecnici di ciò che è accaduto, come è successo e le misure correttive che abbiamo applicato per evitare che un incidente simile si ripeta. Ecco un paio di estratti dal post, primo dall'introduzione:
Il 12 maggio 2019, intorno alle 00:00 UTC, siamo stati avvisati di un'escalation inaspettata dei privilegi per un nuovo account utente da parte di più membri della comunità. Un utente che nessuno ha riconosciuto ha ottenuto l'accesso a livello di moderatore e sviluppatore su tutti i siti della Stack Exchange Network. La nostra risposta immediata è stata revocare i privilegi e sospendere questo account, quindi avviare un processo per identificare e controllare le azioni che hanno portato all'evento.
Dopo la scoperta iniziale, abbiamo scoperto che l'escalation dei privilegi era solo la punta dell'iceberg e l'attacco aveva effettivamente provocato l'esfiltrazione del nostro codice sorgente e l'esposizione involontaria delle PII (e-mail, nome reale, indirizzi IP) di 184 utenti dello Stack Exchange Network (tutti notificati). Per fortuna, nessuno dei database, né pubblico (leggi: contenuto di Stack Exchange) né privato (Team, Talent o Enterprise), è stato esfiltrato. Inoltre, non è stato dimostrato alcun accesso diretto alla nostra infrastruttura di rete interna e in nessun momento l'attaccante ha mai avuto accesso ai dati nei prodotti Teams, Talent o Enterprise.
E dal paragrafo finale:
Questo incidente ci ha ricordato alcune pratiche di sicurezza fondamentali che tutti dovrebbero seguire:
- Registra tutto il tuo traffico in entrata. Conserviamo i log su tutte le connessioni in ingresso. Ciò ha consentito tutte le nostre indagini. Non puoi indagare su ciò che non registri.
- Usa 2FA. Quel sistema rimanente che utilizza ancora l'autenticazione legacy può essere la tua più grande vulnerabilità.
- Proteggi meglio i segreti. TeamCity ha un modo per proteggere i segreti, ma abbiamo scoperto che non lo stavamo usando in modo coerente. Insegna agli ingegneri che "i segreti non sono solo password". Proteggi anche le chiavi SSH e le stringhe di connessione del database. In caso di dubbi, proteggili. Se devi archiviare i segreti in un repository Git, proteggili con git-crypt o Blackbox .
- Convalida le richieste dei clienti. Quanto più insolita è una richiesta da parte di un cliente, tanto più importante è verificare se la richiesta è legittima o meno.
- Prendi sul serio i rapporti sulla sicurezza. Siamo grati che la nostra comunità abbia segnalato attività sospette così rapidamente. Grazie!
C'è molto di più nel post del blog: non esitare a porre domande o commenti relativi al post di seguito e faremo del nostro meglio per rispondere. Non siamo in grado di commentare altri dettagli relativi all'attacco oltre a quanto incluso nel post del blog, a causa delle indagini in corso.
Risposte
Puoi fare qualche commento sulle intenzioni degli aggressori?
Sembra che cercassero un determinato obiettivo / determinati dati (utente)?
O forse era più un "adolescente curioso" che frugava con i bastoni vedendo fino a dove potevano arrivare?
PS grazie per la disponibilità su questo argomento, è davvero apprezzato!
Questa linea:
Questo atto di cercare cose (domande in visita) attraverso lo Stack Exchange Network diventa un evento frequente e ci consente di anticipare e comprendere la metodologia dell'aggressore nei prossimi giorni. (enfasi mia)
fa sembrare che in tempo reale , mentre l'attacco stava avvenendo, potresti individuare ciò che l'attaccante avrebbe fatto in base a ciò che ha visitato su Stack Overflow, invece di ciò che ha fatto guardando forensicamente ciò che ha visto (dopo l'attacco). Quale intendevi?
Diverse domande relative principalmente all'aggressore:
- Cosa è successo all'aggressore?
- Hai sospeso il loro account?
- SE ha contattato l'attaccante in qualsiasi momento?
- Perché non esponi l'identità dell'aggressore?
- Qualcun altro ha provato a utilizzare lo stesso metodo di attacco in seguito?
C'è stato un ciclo del sonno rilevabile all'altra estremità degli eventi?
Modifica per chiarire:
Dopo essere venuto a conoscenza dell'aggressore e poiché hai seguito alcune delle sue azioni mentre si svolgevano, hai notato qualcosa che assomiglia a un ciclo biologico, sia quotidiano che retrospettivo? Ad esempio: mangiare (pause di 1-2 ore), dormire (pattern di inattività di 8 ore), "sonnellini energetici" (90 minuti), ecc ...?
Questo non è realmente parte dell'incidente, ma una preoccupazione più generale per le misure di sicurezza relative agli account dei dipendenti. Ci sono stati molti passaggi in questo incidente, ma l'ultimo è stato l'aumento dei privilegi di un account SE. Posso immaginare modi molto più semplici per tentare questo rispetto all'ottenimento dell'accesso di amministratore al server CI tramite l'istanza dev per eseguire SQL in produzione, e sono interessato a quali mitigazioni e pratiche di sicurezza SE ha implementato per difendersi da tentativi più semplici di guadagno accesso a un account dipendente.
Ovviamente non puoi mettere i principali siti SE dietro il firewall, quindi saranno sempre esposti. E il metodo di accesso interno SE non fornisce alcun metodo 2FA, che trovo un po 'preoccupante.
- gli account dei dipendenti sono protetti 2FA tramite altri mezzi (o altri provider di accesso)?
- esistono misure per garantire che nessun indirizzo e-mail privato o provider di accesso siano allegati agli account dei dipendenti che potrebbero essere meno sicuri e comunque essere utilizzati per ricevere e-mail di recupero per ottenere l'accesso all'account?
- esiste il monitoraggio dei tentativi di accesso da nuove fonti per gli account dei dipendenti?
- esistono protezioni aggiuntive per gli strumenti pericolosi dei dipendenti nel caso in cui qualcuno ottenga l'accesso a una sessione in esecuzione di un account dipendente (ad esempio, richiedere nuovamente la password e / o il token 2FA quando si accede a strumenti critici per la sicurezza)
Qualcosa come lo spear phishing è probabilmente ancora uno dei modi più probabili con cui qualcuno potrebbe tentare di accedere a un account dipendente.
Più o meno nello stesso periodo in cui si è verificato questo incidente di sicurezza, pochi giorni dopo, alcuni utenti hanno iniziato a notare che Twitter oneboxing in chat non funzionava più . Un dipendente ha successivamente confermato nel febbraio del prossimo anno di essere stato effettivamente disabilitato intenzionalmente a causa di "colmare alcune lacune" a seguito di questo incidente di sicurezza.
Possiamo ottenere una spiegazione completa del motivo per cui l'onebox di Twitter nella chat ha dovuto essere disabilitato a seguito di questo incidente di sicurezza? Il post sul blog pubblicato all'epoca affermava che "altri potenziali vettori" erano stati chiusi allora, e il messaggio dello staff di febbraio 2020 che ho collegato sopra affermava che la funzione di Twitter oneboxing "faceva uso di uno dei buchi che abbiamo chiuso". Cos'era quella cosa e quale rischio per la sicurezza ha creato?
Infine, esiste un modo per implementare nuovamente questa funzionalità, in modo sicuro? Nell'agosto 2020, pochi mesi dopo il messaggio dello staff sopra riportato, la segnalazione di bug presentata in quel momento è stata contrassegnata come status-bydesign da un altro dipendente. Verrà presa in considerazione una richiesta di funzionalità per modificare il design (in modo sicuro) o è impossibile farlo senza aprire un vettore di attacco?
Segnalerei che i tipi di parametri "password" in TeamCity non sono considerati così sicuri:
Il valore della password è memorizzato nei file di configurazione in TeamCity Data Directory. A seconda delle impostazioni di crittografia del server, il valore viene codificato o crittografato con una chiave personalizzata.
Il valore del registro di compilazione è nascosto con un semplice algoritmo di ricerca e sostituzione, quindi se hai una banale password di "123", tutte le occorrenze di "123" verranno sostituite, esponendo potenzialmente la password. L'impostazione del parametro sul tipo di password non garantisce che il valore non elaborato non possa essere recuperato. Qualsiasi amministratore del progetto può recuperarlo e qualsiasi sviluppatore in grado di modificare lo script di build potrebbe potenzialmente scrivere codice dannoso per ottenere la password.
Perché il collegamento magico in dev era visualizzabile dai CM (presumibilmente solo in dev) un vero collegamento magico?
Questo è davvero un fantastico rapporto sull'incidente! Uno dei migliori che abbia letto.
Grazie Stack per averlo reso pubblico e Dean per l'ottima scrittura!
Sono solo curioso di sapere poche cose:
- Qual è la dimensione del team di risposta agli incidenti?
- Sono stati seguiti protocolli specifici durante le indagini?
- Quale fattore chiave è stato coinvolto per coinvolgere il fornitore di sicurezza esterno? Quali sono stati i punti che sono stati considerati nella scelta di quel particolare fornitore?
- Quali lezioni sono state apprese dal fornitore di sicurezza esterno? Il loro processo di audit era diverso (efficace / inefficace) da quello già utilizzato dal team?
L'articolo offre una buona panoramica dell'intera architettura di Stack e dei processi di sviluppo. Una lettura più dettagliata o un collegamento se c'è già un articolo su di esso sarebbe fantastico.
In "Consigli ad altri":
Registra tutto il tuo traffico in entrata. Conserviamo i log su tutte le connessioni in ingresso. Ciò ha consentito tutte le nostre indagini. Non puoi indagare su ciò che non registri.
In che modo una rete occupata come Stack Exchange può registrare l'intero traffico in entrata? Questi log sono voci del server web, flussi IP o sessioni TCP complete?
Potrei registrare la maggior parte delle voci e dei tentativi di connessione sulla mia piccola rete, ma non ho idea di come lo faccia una rete così grande.
Puoi spiegare più chiaramente cosa significa "proprietà accessibili al pubblico" nella citazione sottostante?
abbiamo un database contenente un registro di tutto il traffico verso le nostre proprietà accessibili pubblicamente