Eventuali crash dump (ad esempio da Breakpad, Windows) devono essere crittografati e firmati?

Dumps give too much info for hackers to reverse engineer or hack the software, say to enable features or licenses?

Le discariche devono, a un certo punto, esistere in forma non criptata. Un utente malintenzionato con pieno controllo locale può afferrare le discariche in quell'istante o semplicemente ignorarle e osservare a piacimento la memoria dell'applicazione in esecuzione.

Alcuni programmi, come spotify, provano a rilevare se sono in esecuzione in un ambiente di debug e utilizzano vari schemi di offuscamento per rallentare il reverse engineering. Ciò potrebbe vanificare gli attaccanti non esperti o rallentare quelli esperti. Ma probabilmente non fermerà un attaccante. Questo è fondamentalmente il motivo per cui aziende come Microsoft optano per la convalida della licenza online.

Tuttavia, la crittografia in transito è una questione completamente diversa. Proteggere le risorse dei clienti che possono essere disponibili in un dump, o anche le licenze installate su un computer dei clienti, rende questa una buona proposta - assicurando che nessun terzo possa accedere al dump.

È anche facile da implementare; invia il dump over ad esempio https. Mentre il guadagno da questo può essere piccolo, a seconda del contenuto delle discariche, è anche molto economico da implementare e riduce i rischi sia per i tuoi dati che per quelli dei clienti. Ricorda che i tuoi clienti probabilmente valorizzano i loro dati più di quanto apprezzino il tuo prodotto.

A user could return us a maliciously malformed dump, which causes havoc when we try to decipher the dump on our machines. If our application signs the dump, at least we can confidently open the file.

Per firmare i file, l'applicazione ha per accedere a una chiave privata. La chiave privata deve essere presente in memoria sulla macchina eseguendo la firma ad un certo punto. Deve essere distribuito con ogni istanza del software.

Un utente malintenzionato può accedere alla chiave e firmare il suo file di dettagli dannosi.

Non aiuterà a usare i dump come vettore di attacco.

[...] should my crash dumps [...] be encrypted and signed?

Qualcuno può creare un numero qualsiasi di crash dump con vari strumenti come Task Manager, Process Explorer, ProcDump, WinDbg, Visual Studio, DebugDiag, WER, AdPlus (e potenzialmente più) e non si ha alcuna possibilità di intercettarli. Un utente malintenzionato non utilizzerà il dump del crash di Breakpad crittografato, ma crea i propri dump di arresto anomalo regolari.

Tuttavia, è necessario assicurarsi di rispettare le normative sulla privacy e assicurarsi che solo il personale autorizzato possa accedere ai crash dump. In tal caso, la crittografia potrebbe essere d'aiuto, ma anche qualsiasi altro controllo di accesso va bene.

Dumps give too much info for hackers to reverse engineer or hack the software, say to enable features or licenses?

Un'istanza live dell'applicazione fornisce ancora più informazioni. Pensa in questo modo: puoi creare molti crash dump, quindi hai più informazioni da analizzare.

Inoltre: lo sapevi che puoi influenzare la dimensione del dump dello schianto? A seconda delle MINIDUMP_TYPE opzioni, il dump dello schianto contiene più o meno informazioni.

A user could return us a maliciously malformed dump, which causes havoc when we try to decipher the dump on our machines.

Di tuo possibile, ma improbabile. Sarebbe un bug relativo alla sicurezza nel debugger il più possibile in qualsiasi altra applicazione. Il debugger leggerà semplicemente le informazioni dal crash dump, non lo eseguirà.

In che modo l'attaccante ti invia un crash dump senza identificarsi?

La mia opinione personale dipenderà dal costo / beneficio per te.

Firma digitale i file sì. Ridurrà il lavoro e ti permetterà di ricevere discariche dai tuoi veri clienti. Per il trasporto di informazioni si. È necessario utilizzare un canale crittografato e, se non è possibile, crittografare i dati. Credo che sia più facile consegnarlo utilizzando https , ad esempio, anziché tentare di implementare un metodo di crittografia sui dati che può fallire.

Localmente dipenderà dal paesaggio.

Normalmente i dump non dovrebbero essere consentiti per impostazione predefinita e dovrebbero essere abilitati solo per la risoluzione di problemi specifici sui server di produzione.

Se abilitato, è consigliabile configurare una partizione specifica per i dump e consentire a quella partizione di accedere agli utenti con privilegi e non lasciare mai i dati di dump in riposo nel sistema, non appena viene generato deve essere spostato da ambiente di produzione per l'analisi.

In questa situazione è una cosa controllata e l'implementazione della crittografia qui non aggiungerà alcun beneficio reale.

Se hai qualche tipo di automazione che genera dump e li consegna alla tua organizzazione allora direi di sì DEVI implementare la crittografia ovunque specialmente se il dump potrebbe avere dati PII ... I dump a riposo che non sono stati cancellati o sovrascritti sono una buona fonte di informazioni su ciò che è in esecuzione sul server.

Questa non è una buona pratica dato che i server di produzione dovrebbero avere DUMPS disabilitato e DEBUG disabilitato. Questo dovrebbe essere abilitato solo quando richiesto e con alcuni sysadmin che lo monitorano dal vivo.

La crittografia porterà alcune sfide che ti costeranno dei soldi.

Infra PKI: Se possiedi la chiave privata, nessuno dei tuoi clienti sarà autorizzato ad accedere ai dati a meno che tu non condivida la chiave.

Se desideri consentire ai tuoi clienti di avere la chiave privata per accedere al loro dump locale, allora entrerai in un problema di gestione delle chiavi che può richiedere molto tempo in quanto dovrai generare una chiave privata per cliente.

La revoca di una chiave richiede l'aggiornamento dell'applicazione in tutti i tuoi clienti ...

Chiave sincrona: Non ha molto senso in quanto la chiave dovrà esistere da qualche parte nel sistema per consentire la crittografia dei dati.

Cambiare chiave sarà anche una sfida e richiede tempo.