Problemas de seguridad con PHP Sandbox

Question

Problemas de seguridad con PHP Sandbox

#1 de Yoav Aner (7 votos)
#2 de symcbean (0 votos)

11

Estoy trabajando en un sandbox de PHP para un Honeypot de aplicación web. El sandbox de PHP analizará un archivo PHP que puede haber sido inyectado como parte de un ataque RFI. Debe ejecutar el archivo en un entorno seguro y devolver el resultado, incrustando la salida del script PHP. Esperamos engañar al atacante para que crea que esta es una respuesta genuina y así continuar con el siguiente paso de su ataque.

Para construir el sandbox, usamos el Depurador de PHP Avanzado (ADP). Usando rename_function y override_function , las funciones de PHP vulnerables se han reescrito. Algunas funciones como exec , disk_free_space se han reescrito para enviar respuestas falsas. Todas las demás funciones simplemente devuelven nada. Aquí hay una lista completa de las funciones que se han considerado.

Además, la secuencia de comandos de entrada se ejecuta solo durante un máximo de 10 segundos en la zona de pruebas. Después de eso, todo el proceso de la caja de arena es asesinado.

¿Es esta lista lo suficientemente buena? ¿Esto hace que la caja de arena sea lo suficientemente segura como para ser parte del honeypot de la aplicación web?
Además de bloquear llamadas a funciones como esta, ¿hay más medidas de seguridad que deberían tomarse?
Al final, este es un honeypot. Por lo tanto, nos gustaría que nuestra respuesta sea lo más cercana posible a una respuesta real. Por lo tanto, al bloquear las llamadas a la función DNS como dns_check_record y gethostbyname estamos restringiendo el alcance de la ejecución de la secuencia de comandos innecesariamente. (No estoy seguro de por qué están presentes en primer lugar)

En resumen, me gustaría saber qué elementos debo agregar / eliminar de la lista.
Cualquier otra sugerencia / consejo sobre cómo hacerlo será altamente apreciado.

web-application source-code appsec php sandbox

pregunta Phani 25.03.2012 - 08:04

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application source-code appsec php sandbox

¿Se usan malas contraseñas para violar la seguridad en la vida real? ID de puerto de escaneo de Nessus asignada a explotaciones de vulnerabilidad Metasploit

score 7 · Answer 1

Estoy lejos de ser un experto en PHP, por lo que mis comentarios son más generales que específicos.

Probablemente no del todo, pero depende. No creo que el enfoque de la lista blanca / lista negra de ningún pueda ser 100% preciso. Siempre habrá un caso de falsos positivos o falsos negativos . Por lo tanto, siempre se está equilibrando entre los hits (de un script que aún puede penetrar a través de sus defensas) y falla (es decir, el bloqueo del script es exitoso, pero de tal manera que no le permite un mayor análisis). PHP debe tener miles de llamadas y permutaciones diferentes, por lo que crear una lista impermeable es muy difícil. Dicho esto, la lista en una mirada muy rápida se ve bien como punto de partida. Una vez más, mi experiencia con php es limitada.
No estoy seguro de lo que quiso decir cuando dijo que "se hizo parte de la aplicación web", pero le recomiendo encarecidamente que no incruste esto con cualquier cosa que esté conectada de forma remota o que se encuentre cerca de datos reales o cualquier otra información real. Aplicación de producción. Si se trata de un honeypot , probablemente debería mantenerse en el mayor aislamiento posible . Debes considerar cosas como:
- Ejecutando esto en una máquina de hardware dedicada que se 'actualiza' regularmente (se vuelve a crear una imagen, se construye desde cero)
- No permita que se conecte a otra cosa que no sea el mundo exterior
- No almacene ningún dato sensible (o incluso no tan sensible) en él
- Registre todos los accesos y use un firewall externo con un registro detallado
- Utilizar el registro interno del sistema operativo
- Monitoree cualquier cosa incluso remotamente extraña en cualquiera de sus registros
- Considere la posibilidad de limitar la velocidad de la conexión externa
Si el sistema está suficientemente aislado, el principal riesgo restante, aparte de sí mismo, es para otros sistemas. Asumiendo que los atacantes atravesaron su capa de protección php con éxito, su honeypot puede usarse para lanzar ataques externos en otros sistemas : spam, denegación de servicio, actuar como parte de una red de bots, etc. de forma aislada, es una buena idea mantenerlo de cerca, así como eliminar y comenzar desde cero.
Desafortunadamente, no puedo responder eso más de lo que ya he cubierto en 1.
Ver 2.

score 0 · Answer 2

Tu enfoque no tiene mucho sentido para mí.

Usted dice que desea crear un honeypot (es decir, un sistema que parece ser inseguro) al deshabilitar los vectores de ataque comunes.

Esperamos engañar al atacante para que crea que esta es una respuesta genuina

Eso implica que solo podrá sustituir respuestas por ataques que ya ha caracterizado. Y estará ejecutando una pila de software muy diferente al sistema que está intentando modelar el comportamiento de.

En el mejor de los casos, esto supondrá una gran cantidad de esfuerzo. Es más probable que tenga algo que esté lejos de ser representativo, que no exponga las vulnerabilidades del sistema que está modelando y que lo exponga a cualquier atacante. Su lista está muy lejos de ser una lista completa de cosas para deshabilitar / ajustar para una instalación segura de PHP, pero ese no es el punto.

Le recomiendo que vuelva a una compilación estándar de PHP y piense en cómo encapsular y monitorear el honeypot como un todo. Ciertamente desea implementar el honeypot en una máquina virtual (que puede copiar en otro lugar para estudiar / desconectarse rápidamente / modificar la compilación) y hacer proxy y registrar todo el tráfico del servidor a / desde, con registro remoto y (casi) verificación continua de integridad . Por supuesto, ajuste las funciones / construcciones de PHP con registro, pero no las desactive.