Vulnerabilità legata all'attacco e alla sessione di CSRF


12

Dalle note di rilascio della 1.8CE Alpha:

Il Web store Magento ha protezioni aggiuntive contro i falsi (CSRF), il che significa che un impostore non può più impersonare un cliente appena registrato ed eseguire azioni per conto del cliente.

e:

Nelle versioni precedenti, Magento era vulnerabile a un attacco di fissazione della sessione durante il processo di registrazione. Dopo aver effettuato l'accesso al proprio account, l'ID sessione di un utente registrato non è cambiato. Pertanto, se un utente malintenzionato era a conoscenza di un ID sessione non autorizzato e se l'utente si registra correttamente, l'utente malintenzionato è in grado di rilevare l'account appena registrato. Ora, l'ID della sessione cambia dopo la corretta registrazione, rendendo impossibile l'uso non autorizzato di un account.

Se questo è nelle note di rilascio e non vedo un rilascio puntuale su versioni precedenti che si rivolgono a questo (sto cercando nel posto sbagliato?), Allora ciò significa che gli attuali negozi pre-1.8 sono potenzialmente aperti a questi attacchi vettori ?

Fonte: http://www.magentocommerce.com/knowledge-base/entry/ce-18-later-release-notes


Ho appena aggiornato la mia risposta di seguito con i dettagli su come ottenere una patch per queste vulnerabilità.
davidalger,

Risposte:


9

Insomma sì. CE 1.7 è ancora vulnerabile a quegli attacchi specifici perché non è stata rilasciata alcuna versione di sicurezza che contiene una patch.

Nel caso di quest'ultimo, un attacco di fissazione della sessione, la modifica è un aggiornamento delle pratiche di sicurezza che Magento già utilizzava per rimanere in linea con le attuali migliori pratiche di sicurezza. Non è probabile che venga rilasciato a CE 1.7 se rilasciano una patch con le correzioni CSRF.

La vera domanda è: quali erano esattamente queste vulnerabilità CSRF che sono state risolte? Senza dubbio una cosa buona che non includevano dettagli nelle note di rilascio, compromettendo così ulteriormente tutte le versioni precedenti, ma sarebbe bello sapere per motivi di patch di vecchie implementazioni.

AGGIORNAMENTO N. 1: Dopo aver contattato Magento per scoprire quando emetteranno le patch per le vulnerabilità di cui sopra, ho ricevuto la seguente risposta:

Concedimi un po 'di tempo per approfondire le ricerche. Non sono sicuro se ci sono patch disponibili per questi due elementi, poiché sono elencati nel nostro sistema come miglioramenti del prodotto e non come bug. Ti aggiornerò quando avrò maggiori informazioni.

Pubblicherò ulteriori dettagli qui quando li avrò e farò del mio meglio per ottenere le patch emesse poiché sembra che al momento non ci siano patch esistenti.

AGGIORNAMENTO # 2: Dopo aver fatto avanti e indietro con il team di supporto, sono stato in grado di ottenere una patch corretta per Magento EE 1.12.0.2. Non è stata emessa alcuna patch per Magento CE 1.7.0.2 e, per quanto mi sa il tecnico che lo ha esaminato internamente, non è previsto il rilascio di una patch ufficiale per CE 1.7.x, invece di risolvere i problemi solo nel prossimo CE 1.8 rilascio stabile.

Per quanto riguarda il file di patch specifico di EE, non posso pubblicarlo qui (o lo strumento per l'applicazione di patch) qui direttamente poiché sarebbe senza dubbio una violazione dell'NDA tra Magento e me personalmente e la società per la quale lavoro. Il nome della patch pertinente è: "PATCH_SUPEE-1513_EE_1.12.0.2_v1.sh" - Se hai Enterprise Edition o un client che la utilizza, dovresti essere in grado di richiedere questa patch al team di supporto Magento insieme a una nota su le vulnerabilità di CSRF che dovrebbe risolvere.

Per gli utenti di CE 1.7.0.2, ho preso la libertà di generare un file di patch (basato sulla patch fornita da Magento) che include solo gli hunk di codice che alterano i file di codice core di Magento CE 1.7.0.2. In modo normale, include frammenti irrilevanti di commenti aggiunti e formattazione adattata insieme alle relative modifiche al codice. La creazione di questo ha richiesto la modifica manuale della patch originale per applicarla utilizzando lo strumento di applicazione della patch fornito, quindi utilizzando git per generare una patch in base alle modifiche applicate.

Il file patch che ho creato può essere scaricato da questa sintesi: https://gist.github.com/davidalger/5938568

Per applicare la patch, prima cd nella root dell'installazione di Magento ed eseguire il comando seguente: patch -p1 -i ./Magento_CE_1.7.0.2_v1-CSRF_Patch.diff

La patch specifica di EE includeva controlli di convalida della chiave del modulo per controller specifici dell'azienda, modifiche ai file modello enterprise / default e enterprise / iphone per includere le chiavi del modulo nei moduli utilizzati per le azioni del controller della patch e funzionalità aggiuntive della cache a pagina intera per tenere correttamente conto di passando le chiavi del modulo avanti e indietro sulle pagine memorizzate nella cache.

NOTA BENE: NON HO TESTATO né la patch EE fornita da Magento né la patch che ho caricato nella sostanza collegata. La patch fornita nell'articolo referenziato non è FORNITA DA GARANZIA e può o meno risolvere completamente le vulnerabilità indicate nelle note di rilascio CE 1.8. Come patch non testata, non vi è alcuna garanzia che funzioni in tutto o in parte. Vale a dire a tuo rischio e pericolo e esegui la dovuta diligenza per testarlo prima di distribuirlo in un ambiente di produzione. Se riscontri problemi con la patch, fammi sapere e lo aggiornerò.


1
La sicurezza attraverso l'oscurità non è una buona idea. Dovrebbero renderlo pubblico in modo che tutti possano patchare la sua installazione. Inoltre, una semplice differenza tra le due versioni dovrebbe darti una buona impressione su come funziona l'attacco e su come patchare le installazioni precedenti. Pertanto le informazioni sono comunque disponibili.
Darokthar,

1
D'accordo, l'oscurità non è affatto una buona sicurezza, e di certo non stavo cercando di indicarlo. Tuttavia, la divulgazione responsabile è qualcosa che deve essere considerato. Per quanto ne sappiamo, le vulnerabilità avrebbero potuto essere inviate a Magento settimane prima del rilascio pubblico di EE 1.13 e CE 1.8a1. FWIW, contatterò alcune persone a Magento per scoprire se hanno ancora patch per EE 1.12 e quali piani sono per le installazioni 1.7; specificamente per le vulnerabilità di CSRF.
davidalger,

Cerchiamo un aggiornamento e modifichiamo la domanda / risposta di conseguenza se viene rilasciata una patch. Grazie.
Filwinkle,

Ho appena pubblicato un aggiornamento con una risposta preliminare che ho ricevuto da Magento. Sembra che al momento non ci siano patch, quindi vedrò cosa posso fare al riguardo. Vi terrò sicuramente aggiornati ... qui e possibilmente anche sul mio twitter.
davidalger,

2

Non sono sicuro al 100% perché non sono stato in grado di riprodurre il problema, ma

ciò significa che un impostore non può più impersonare un cliente appena registrato

significa che finora un "impostore" potrebbe impersonare un nuovo cliente registrato.
Spero sia solo una "semantica", ma penso che significhi ciò che temi.


fino ad ora, significa fisso in 1.8 - o cosa vuoi dire?
Fabian Blechschmidt,

sì ... questo è ciò che intendo.
Marius
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.