¿Por qué hay tantos servidores web que se explotan al generar archivos confusos?

Cuando hagas un poco más de atención en estos casos, notarás que estas víctimas casi siempre usan algún sistema de gestión de contenido de terceros escrito en PHP, como Wordpress o Joomla.

Hay algunos problemas con estos:

• Tenían muchas vulnerabilidades de seguridad en el pasado.
• Hay muchos complementos disponibles para ellos de calidad variable que también tienen vulnerabilidades.
• La carga de archivos es parte de la funcionalidad principal de un CMS, por lo que los errores relacionados con la seguridad que permiten abusar de esta funcionalidad no autenticada son, en realidad, bastante concebibles.
• Las personas tienden a no actualizar estos sistemas tan a menudo como deberían, por lo que las instalaciones con vulnerabilidades sin parches permanecen en línea.
• Hay una gran cantidad de instalaciones para estos, por lo que se pueden encontrar fácilmente a través de bots automatizados.

Podría preguntarse ¿por qué hay tantos problemas con las aplicaciones PHP ? PHP es un lenguaje con varios paradigmas que hacen que para un programador novato sea bastante fácil escribir aplicaciones inseguras llenas de inyecciones de XSS y SQL. Además, no es necesario compilar los archivos PHP y, por lo general, se puede acceder a ellos de forma inmediata a través de una URL. Un archivo .PHP en un servidor web puede ejecutarse simplemente solicitándolos con un navegador web, de modo que cuando el atacante logre subir uno, ya haya presionado el servidor.

Como programador de C, estos problemas le afectan menos, pero tiene todo un conjunto de problemas diferentes, como por ejemplo tener que pensar en desbordamientos de búfer cada vez que escribe datos en un char* u otro tipo de matriz.

  

¿Cómo se quejan los archivos confusos de muchos de los usuarios en este sitio de SE sobre sus sistemas?

Una mezcla de:

• el acceso al servidor está comprometido (generalmente cuentas de FTP; a menudo, credenciales extraídas de aplicaciones de FTP en equipos de escritorio infectados por malware)

• aplicaciones comúnmente instaladas vulnerables, a menudo muy desactualizadas y mal escritas que se ejecutan con permisos débiles

siendo aprovechado por scripts automatizados.

  

El demonio FCGI (bajo el cual se invoca el host web) está en un grupo de usuarios que tiene permisos especiales para leer / escribir en las rutas donde se almacenan los archivos

Bueno, ya lo estás haciendo mucho mejor que la mayoría.

En my-cheap-crap-shared-php-host.com es mucho más probable que vea a cada cliente que tiene una cuenta utilizada tanto para cargar el contenido del sitio (generalmente a través de FTP desprotegido, alegría) como para que el servidor web lo ejecute. O tal vez el servidor web sea un usuario sin privilegios, pero umask se asegura de que todo se pueda escribir en todo el mundo.

En consecuencia, cualquier vulnerabilidad que permita que un archivo se cargue en una ruta existente o un nombre de archivo sensible (y las aplicaciones típicas de PHP tienen una tonelada de estas) pueden escribir código PHP y, por lo tanto, escalar la escritura del archivo a una ejecución arbitraria vulnerabilidad del código.

Usted no tiene para implementar PHP de esta manera, pero muchos hosts lo hacen, porque la alternativa es que a sus clientes se les debe enseñar cómo funciona el sistema POSIX de usuarios / grupos / permisos, y ese tipo de costo de soporte consumirá su margen de ganancia bastante rápidamente cuando esté cobrando un cupón por mes.

La clave del éxito de PHP es que puede implementar fácilmente una aplicación al dejar caer una carga de archivos en un directorio sin tener que pensar demasiado en el entorno. Esta es también la clave para la caída de la seguridad de PHP.

  

No puedo imaginar ningún escenario en el que esto pueda suceder siempre y cuando me asegure de que no se almacenarán búferes

¡Asegurarte de que no tengas errores de manejo del búfer cuando escribes en C no es una tarea fácil! Las aplicaciones web hacen mucha manipulación de cadenas y las herramientas de cadenas estándar son bastante débiles ...

Si profundiza en estos, estoy bastante seguro de que encontrará un patrón: o están ejecutando software CMS obsoleto, o complementos obsoletos para el software CMS, y están en un alojamiento compartido, o han configurado hasta alojamiento compartido para ellos mismos.

Esta es una generalización masiva, pero el software CMS obsoleto generalmente puede escribir en casi cualquier carpeta dentro de webroot; a menudo tenía errores relacionados con las rutinas de instalación o generación de miniaturas, que tanto requerían la capacidad de escribir en el sistema de archivos, e intercambiaron seguridad de usar una conexión distinta para la comodidad de poder hacer actualizaciones desde dentro del software. No es imposible tener un sistema de instalación seguro basado en la web, pero la mayoría de los primeros no lo eran.

De forma similar, el alojamiento compartido puede ser perfectamente seguro, pero los hosts de gama baja a menudo parecen cortar esquinas. No segregan a los usuarios correctamente, por lo que una persona que ejecuta software obsoleto a menudo da como resultado que varios sitios se vean comprometidos. Naturalmente, los usuarios no pueden ver ninguna razón por la que esto haya sucedido: sus sitios son seguros, simplemente se ejecutan en servidores inseguros.

El motivo de muchos de estos scripts que usan PHP es un remanente de los dos factores anteriores: los hosts de gama baja tienden a ofrecer PHP en lugar de Python / Ruby / etc, por lo que puede estar bastante seguro de que el script se ejecutará, y genera menos sospechas cuando aparece un archivo PHP en un CMS basado en PHP; es bastante obvio en una carpeta llena de archivos .rb, por ejemplo.

La ofuscación es generalmente solo para evitar un monitoreo fácil. Es trivial buscar archivos que contengan eval , pero más difícil buscar archivos que contengan una cadena que esté codificada en base64 y que decodifique a lave , que luego se invierte y ejecuta usando otra función vulnerable. Sin embargo, algunos de los métodos de codificación son bastante ingeniosos.

Un análisis trivial de las estadísticas sugeriría que PHP es un desastre de seguridad. Sin embargo, profundiza un poco más y las razones se aclaran. Y la mayoría de ellos no son sobre PHP.

PHP es en todas partes . Es fácil configurar un entorno de alojamiento compartido de bajo costo que ejecute PHP. Configurar un entorno seguro es un poco más complejo. Y eso a menudo significa restringir lo que el usuario puede hacer. Y esas llamadas de soporte donde necesita explicar a sus clientes que, no, la política para evitar que PHP cargue archivos en cualquier lugar dentro de la raíz del documento está ahí por una muy buena razón, son muy caras. Y es probable que lleve a la mayoría de sus clientes a un proveedor competidor que no imponga una restricción de seguridad tan básica.

Otro problema es el crecimiento de las soluciones de paquetes, a menudo promovidas como una función por los proveedores: ¡Instalación con un solo clic! Asegurarse de que la biblioteca de paquetes en oferta esté actualizada (y que aún funcione con el instalador) requiere mucho tiempo. Tratar de asegurarse de que las aplicaciones implementadas estén actualizadas con parches es aún peor.

En el caso de software instalado por el usuario, la mayoría no se molesta en evaluar la calidad del producto más allá de descubrir con qué facilidad pueden lograr un objetivo muy específico.

Desde el punto de vista de los clientes, la implementación del código no es más difícil que la implementación de contenido estático.

Es fácil de desarrollar. Un programa de hello world es una línea de código. No hay una etapa de compilación separada, no hay configuración de su aplicación. Se ejecutará en plataformas de muchos proveedores diferentes.

Con una barrera de entrada tan baja, cualquier persona con una computadora puede ser un desarrollador de PHP. Pero hay mucho más en ingeniería de software que poder escribir líneas de código.

Por lo tanto, no es sorprendente que haya una gran cantidad de software de baja calidad escrito en PHP flotando.

PHP tiene pocos mecanismos inherentes para restringir la seguridad. Pero más que PERL o C. Java sale en una dirección completamente diferente en términos de seguridad.

Una comparación detallada de la seguridad intrínseca llevaría mucho más tiempo de lo que el espacio permite aquí. Basta con decir que cuando White hat Security intentó comparar la seguridad de las aplicaciones escritas en diferentes idiomas, las fallas que encontraron estaban en el código y no en la plataforma.