Multi-tenancy e Heartbleed

Question

Multi-tenancy e Heartbleed

#1 da (2 voti)
#2 da (0 voti)
#3 da (0 voti)

1

Utilizziamo un noto fornitore di servizi / gateway di gestione API che si trova di fronte alle nostre API RESTful che forniscono funzionalità di gestione delle chiavi, ecc.

Il fornitore di servizi stava eseguendo la dubbia versione OpenSSL.

Nessuno dei nostri servizi web ha abilitato SSL, sebbene usiamo le chiavi API per limitare l'accesso alle API, misurare l'utilizzo.

Il traffico arriva ovviamente ai server web del fornitore di servizi che funge da proxy e parla ai nostri server web.

Se l'infrastruttura del fornitore di servizi è tale che molti clienti condividono un'istanza di server Web e almeno un cliente ha abilitato SSL, allora espone tutti i clienti, inclusi quelli che non usano SSL, alla minaccia?

Apparentemente, il bug non consentirà la lettura della memoria al di fuori dello spazio degli indirizzi del processo, quindi la risposta è incentrata su come il server web proxy esegue un processo per cliente.

Qualcuno ha coperto questo scenario?

Scenario ipotetico

Sono un programmatore che lavora per API-r-Us. Invece di eseguire un sito Web e un processo separati per ciascuna delle mie migliaia di clienti, in tutto e per tutto, scrivo il sistema proxy come un singolo servizio Web stateless in esecuzione in un'istanza del sito Web che gestisce tutte le richieste su apisrus.net

Il mio servizio gestisce sia il traffico SSL che non SSL.

Il mio servizio utilizza alcune regole basate sull'URL per instradare le richieste a diversi servizi web del cliente. I consumatori di API parlano del mio servizio e il mio servizio parla del servizio reale del cliente, i carichi utili possono persino essere convertiti o aumentati dal mio servizio prima di essere rispediti al consumatore dell'API.

Nella memoria del processo sono caricati i vari percorsi e le credenziali per accedere alle API del mio cliente, così come le chiavi e gli hash utilizzati per autenticare gli utenti.

Tutto il traffico passa attraverso un singolo processo, quindi se la memoria di questo processo è compromessa, tutti i clienti sono compromessi.

Suppongo che OpenSSL sia caricato nello spazio degli indirizzi del sito web (e non della pipeline del server).

openssl heartbleed

posta Luke Puplett 15.04.2014 - 12:17

fonte

3 risposte

Leggi altre domande sui tag openssl heartbleed

Rilevazione heartbleed [duplicato] È sicuro un adattatore solo per VirtualBox?

score 2 · Answer 1

La risposta al tuo scenario specifico è "dipende".

In particolare, dipende dai dettagli più fini di come funziona l'allocatore di memoria dell'applicazione, dal meccanismo di threading che utilizza e dalla struttura interna dell'applicazione. Ci sono alcuni scenari (ad esempio fork vecchio stile + threading exec con un nuovo thread per gestire ogni richiesta, o un allocatore di memoria che cancella sempre la memoria prima dell'uso più pool di memoria per-thread più thread dedicati SSL e non SSL) in cui i dati non SSL non possono diffondersi nello spazio di memoria accessibile con OpenSSL. Tuttavia, a meno che non si sappia che uno di questi è il caso, è necessario presumere che qualsiasi cosa nella memoria del server web potrebbe essere stata trapelata da Heartbleed.

score 0 · Answer 2

Se riprendo correttamente la tua situazione nel disegno sottostante (mi dispiace per la bruttezza):

Quindi non sei a rischio , come i dati tra i tuoi clienti - > il provider - > i tuoi server non vengono crittografati e quindi non passano attraverso la memoria del processo OpenSSL.

Il server vulnerabile può ancora essere sfruttato per scaricare le chiavi private / i dati dei clienti per altri utenti e altri servizi oltre al tuo, ma poiché l'attacco Heartbleed non può leggere la memoria di altri processi (per quanto conosci oggi), non sei interessato.

Da una nota a margine, come ha osservato Lucas Kauffman, il fatto che i tuoi dati non siano criptati tra i tuoi clienti e i tuoi server web è probabilmente un rischio più grave della vulnerabilità Heartbleed.

score 0 · Answer 3

Heartbleed è un bug di scraping della memoria. Non sono solo le chiavi che possono essere trovate, ma TUTTI i dati gestiti dalla macchina interessata. Nel caso di questo proxy, quindi, la vulnerabilita 'heartbleed potrebbe vedere la memoria in un altro processo, che e' successo essere la richiesta HTTP del tuo cliente al tuo server. A causa della natura di questo difetto, QUALSIASI informazione sensibile che è passata attraverso quella macchina dovrebbe essere considerata compromessa.