È possibile sfruttare una vulnerabilità in un'applicazione per attaccare un'altra applicazione sullo stesso server?

Se la vulnerabilità di Magento portava a una shell, allora quella shell poteva essere utilizzata per ottenere l'accesso come root da una vulnerabilità di escalation dei privilegi. Quando ciò accade, l'attaccante ha il controllo completo sul sistema.

La risposta breve è un qualificato "Sì". Soprattutto se i sistemi software sono in esecuzione nello stesso spazio del file system e spazio di memoria. Se un utente malintenzionato viene root, il sistema viene bloccato. Detto questo, ci sono un paio di configurazioni che renderebbero la pwnage molto più difficile e il HIDS dovrebbe avere tempo per aumentare gli allarmi sull'attività.

Il più comune è far funzionare ciascuna applicazione nella sua prigione di chroot . Dovrebbe essere possibile bloccare le cose abbastanza strettamente con qualcosa come SELinux o RBAC su Windows o Solaris. Non sono a tenuta stagna, l'intruso farebbe così tanto rumore cercando di capire come sono configurati e come concedere a se stesso i privilegi necessari per continuare l'attacco, di nuovo, a quest'ora gli HIDS avrebbero dato via il gioco.

Una configurazione ancora più sicura consiste nel far eseguire ciascuna applicazione sulla propria macchina virtuale. Se le macchine virtuali sono in esecuzione su un sistema operativo, l'utente malintenzionato dovrebbe uscire completamente dalla macchina virtuale su cui era in esecuzione l'applicazione vulnerabile e penetrare nell'altra. Supponendo che le macchine virtuali e la macchina host stiano eseguendo il proprio HIDS, l'allarme / i si spengono prima che l'attacco sulla seconda macchina sia completato. Se stanno funzionando su bare metal, penso che sia sicuro dire che chiunque voglia attaccare quel sistema non ha le risorse per completare l'attacco.

IMHO, avere ogni applicazione eseguita nella propria macchina virtuale è comunque una buona idea. Dovrebbe fare il lavoro e l'implementazione è di gran lunga la più facile da implementare e gestire. . .

Sì, di solito funziona al contrario. Wordpress ha installato un plug-in non sicuro che consente di caricare ed eseguire uno script php. Questo può essere usato per attaccare il lato Magento delle cose, tra cui il download delle credenziali del database Magento, l'iniezione di account amministratore personalizzati nel database Magento, l'installazione del modulo di amministrazione file Magepleasure e degli script di raccolta delle informazioni sulle carte.

Ovviamente questa è una strada a doppio senso, se Magento è, per esempio, senza patch per il bug del shoplift, l'attaccante può usare una transazione POST per iniettare direttamente un account amministratore nel database Magento senza avere le credenziali Magento, accendere il Magento downloader, quindi installa il modulo di amministrazione file Magepleasure e, ancora una volta, esegui tutto ciò che desiderano sull'account utente.

Dipende totalmente da ciò che l'hacker vuole fare, l'infezione del computer probabilmente si ottiene meglio attraverso un blog popolare, anche se l'ultimo colpo su Magento è stato l'utilizzo di un account shopper SUPEE-5344 creato per gli account admin o le installazioni di Magento non sono state ancora correttamente riparate per le varie vulnerabilità per iniettare il pacchetto di infezione GuruIncSite nel footer di Magento. Magento è ovviamente di interesse diretto per il semplice vecchio cliente e il furto di informazioni sulle carte di credito.

Per reiterare, se un modulo di plugin per EITHER Wordpress o Magento è vulnerabile agli attacchi, allora entrambe le applicazioni possono essere compromesse.

O se usi semplicemente OpenSSL prima di perdere il cuore, saresti stato vulnerabile, è importante che l'intero stack sia protetto, qualsiasi componente libero possa dare l'opportunità a un hacker di attaccare l'intero sistema.

Riferimento link

Penso che le migliori soluzioni implichino alti livelli di isolamento (virtualizzazione, spazi di memoria privati, macchine separate?)