Problemi di sicurezza con PHP Sandbox

Question

Problemi di sicurezza con PHP Sandbox

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

11

Sto lavorando su una sandbox PHP per un Honeypot di applicazioni Web. La sandbox PHP analizzerà un file PHP che potrebbe essere stato iniettato come parte di un attacco RFI. Dovrebbe eseguire il file in un ambiente sicuro e restituire il risultato, incorporando l'output dello script PHP. Speriamo di ingannare l'attaccante facendogli credere che questa sia una risposta genuina e quindi continui con il prossimo passo del suo attacco.

Per costruire la sandbox, abbiamo usato l'Advance PHP Debugger (ADP). Utilizzando rename_function e override_function , le funzioni PHP vulnerabili sono state riscritte. Alcune funzioni come exec , disk_free_space sono state riscritte per inviare risposte false. Tutte le altre funzioni non restituiscono nulla. Ecco un elenco completo delle funzioni che sono state prese in considerazione.

Inoltre, lo script di input viene eseguito solo per un massimo di 10 secondi nella sandbox. Dopo di ciò, l'intero processo sandbox viene ucciso.

Questa lista è abbastanza buona? Questo rende la sandbox abbastanza sicura da far parte del honeypot dell'app web?
Oltre alle chiamate alla funzione di blocco come questa, ci sono più misure di sicurezza da adottare?
Alla fine, questo è un honeypot. Quindi, vorremmo che la nostra risposta fosse il più vicino possibile a una risposta reale. Quindi, bloccando le chiamate di funzioni DNS come dns_check_record e gethostbyname limitiamo l'ambito di esecuzione per lo script inutilmente. (Non sono sicuro del motivo per cui sono presenti in primo luogo)

In breve, vorrei sapere quali elementi dovrei aggiungere / eliminare dalla lista.
Qualsiasi altro suggerimento / consiglio su come procedere sarà molto apprezzato.

php source-code sandbox web-application appsec

posta Phani 25.03.2012 - 08:04

fonte

2 risposte

Leggi altre domande sui tag php source-code sandbox web-application appsec

Come testare DDoS in un ambiente controllato? L'immagine della firma è considerata PII?

score 7 · Answer 1

Sono lontano dall'essere un esperto di PHP, quindi i miei commenti sono più generali piuttosto che specifici.

Probabilmente non interamente, ma dipende. Non penso che l' qualsiasi elenco di whitelist / blacklist possa mai essere accurato al 100%. Ci sarà sempre un caso di falsi positivi o falsi negativi . Quindi stai sempre bilanciando tra hit (di uno script che è in grado di penetrare ancora attraverso le tue difese) e miss (cioè bloccando con successo lo script, ma in modo tale che non ti consente ulteriori analisi). PHP deve avere migliaia di chiamate e permutazioni diverse, quindi creare una lista impermeabile è molto difficile. Detto questo, l'elenco con una rapida occhiata sembra ok come punto di partenza. Ancora una volta, la mia esperienza di php è limitata.
Non sono sicuro di cosa intendessi quando hai detto "di far parte dell'app Web", ma preferirei strongmente sconsigliarne l'integrazione con qualsiasi cosa sia anche lontanamente connessa o in prossimità di dati reali o reali applicazione di produzione. Se questo è un honeypot , probabilmente dovrebbe essere conservato in il maggior isolamento possibile . Dovresti considerare cose come:
- Esecuzione su un computer hardware dedicato che viene regolarmente "aggiornato" (reimmaginato, creato da zero)
- Non lasciare che si connetta a qualcosa di diverso dal mondo esterno
- Non memorizzare dati sensibili (o anche non così sensibili) su di esso
- Registra tutti gli accessi e utilizza un firewall esterno con registrazione dettagliata
- Utilizza la registrazione del sistema operativo interno
- Monitora qualsiasi cosa anche lontanamente strana su uno dei tuoi log
- Considera la limitazione della velocità della connessione esterna
Se il sistema è isolato abbastanza bene, il principale rischio rimanente oltre a se stesso, è quello di altri sistemi. Supponendo che gli hacker abbiano superato con successo il tuo livello di protezione php, il tuo honeypot può essere usato per lanciare attacchi esterni su altri sistemi - spam, denial of service, agire come parte di una botnet ecc. Ecco perché tenerlo isolatamente, tenerlo d'occhio, oltre a cestinare e ricominciare da zero è una buona idea.
Purtroppo non posso rispondere più di quanto ho già spiegato in 1.
Vedi 2.

score 0 · Answer 2

Il tuo approccio non ha molto senso per me.

Dici di voler creare un honeypot (cioè un sistema che sembra essere insicuro) disabilitando i comuni vettori di attacco.

We hope to fool the attacker into believing that this is a genuine response

Ciò implica che sarai in grado di sostituire le risposte solo per gli attacchi che hai già caratterizzato. Inoltre, eseguirai uno stack software molto diverso dal sistema che stai cercando di modellare il comportamento di

Nel migliore dei casi, questo sarà un enorme sforzo. È più probabile che tu abbia qualcosa che è tutt'altro che rappresentativo, che non espone le vulnerabilità del sistema che stai modellando e che lo espone a qualsiasi aggressore. La tua lista è molto lontana dall'essere un elenco completo di cose da disabilitare / eseguire il wrapping per un'installazione PHP sicura, ma non è questo il punto.

Ti consiglio di tornare a una build PHP standard e pensare a come incapsulare e monitorare l'honeypot nel suo complesso. Sicuramente vuoi implementare l'honeypot in una macchina virtuale (che puoi copiare altrove per studiare / prendere offline velocemente / modificare la build) e proxy e registrare tutto il traffico del server da / a, con registrazione remota e (quasi) continuo controllo dell'integrità . Con tutti i mezzi, avvolgere le funzioni / costrutti PHP chiave con la registrazione, ma non disabilitarli.