El peor escenario de tener la capacidad de escribir archivos en el disco de forma remota como administrador

6

Estoy trabajando en la creación de un programa ("Mi programa") que se comunicará con otro programa ("Su programa") a través de comandos XML a través de una conexión TCP / IP sin formato. Su programa permite que los archivos se escriban en el disco de forma remota con privilegios de administrador. Esta interfaz está habilitada por defecto (gran defecto de seguridad, lo sé), y estoy tratando de darle a la otra empresa la peor situación de lo que podría suceder si un pirata informático fuera consciente de esta vulnerabilidad y la explotara en una empresa. ordenador conectado a la intranet.

  1. ¿Qué tan localizada está la amenaza a la seguridad?
  2. ¿Puede el atacante comprometer la seguridad de la red / servidor usando solo este exploit (posiblemente para explotar otras vulnerabilidades)? El usuario es un administrador local pero un usuario de red estándar.
  3. ¿Qué otras posibles amenazas podrían explotarse debido a esta "característica" que quizás haya pasado por alto?
  4. ¿Cuál sería la mejor manera de protegerse contra esto, mientras se mantiene la funcionalidad requerida? ¿Hay alguna manera de aislar artificialmente el programa, o verificar si los archivos escritos en el disco no están en un lugar sensible?
pregunta Matt 24.08.2012 - 11:36
fuente

4 respuestas

10

Ok, este es un defecto bastante desagradable. Si es posible atravesar el directorio, el atacante podría sobrescribir los ejecutables de uso frecuente para infectar la caja con malware. Desde allí, el resto de la red podría infectarse a través de una amplia gama de diferentes mecanismos: difusión de USB, vulnerabilidades de ejecución remota de código, phishing de lanza, etc.

Peor aún, podrían usar la infección de malware para robar las credenciales almacenadas en la máquina (si es Windows, hay cachés de Active Directory cifrados en la memoria) e iniciar sesión en otros sistemas.

Si está ejecutando servidores públicos que ofrecen archivos (por ejemplo, HTTP, FTP, SharePoint, etc.), el atacante podría sobrescribir esos archivos con información falsa o malware.

Como mínimo, estás viendo una vulnerabilidad de DoS, donde el atacante llena tu sistema con archivos grandes hasta que el disco está lleno.

    
respondido por el Polynomial 24.08.2012 - 11:50
fuente
8

Si el atacante elige los archivos que puede sobrescribir, entonces solo tiene que reemplazar algunos archivos del sistema operativo para ser dueño de la máquina por completo (por ejemplo, reemplazar el kernel y esperar el siguiente reinicio).

Si los nombres de los archivos están "contenidos" (es decir, los archivos escritos por el atacante aparecerán necesariamente en un directorio específico o en un subdirectorio del mismo, sin posibilidad de sobrescribir los archivos del sistema), la mayoría de los problemas se pueden evitar, pero todavía permite que el atacante cargue "cosas desagradables", del tipo que preferimos nunca ver en nuestros servidores (por ejemplo, virus y otro malware). Como una línea de base, la "función de archivo de carga" permite que un atacante llene el servidor con pornografía pedófila, lo cual es una responsabilidad (solo este argumento debería ser suficiente para convencer a cualquier empresario sano de que esta función es una mala idea).

    
respondido por el Thomas Pornin 24.08.2012 - 15:26
fuente
6

Solo para agregar algún punto de vista: ¿Ha escuchado acerca de 10 Leyes de Seguridad Inmutables ? Es un poco viejo, simple, etc., pero va al grano.

Dentro de él encontrarás algunas reglas:

  

Ley # 1: si un malvado puede persuadirte de que ejecutes su programa en tu computadora, ya no es tu computadora

     

Ley n. ° 2: si un malvado puede alterar el sistema operativo de su computadora, ya no es su computadora

     

Ley n. ° 4: si permites que un tipo malo cargue programas en tu sitio web, ya no es tu sitio web

Si alguien puede cargar archivos en un servidor, guárdelos en cualquier lugar, con cualquier nombre, con privilegios de administrador, básicamente es el propietario de la computadora. Si la interfaz está habilitada de forma predeterminada, ¡ni siquiera tiene que engañar a alguien para que cargue esos archivos!

Lo que él puede hacer:

  • DoS llenando todo el espacio
  • Utilice el servidor para almacenar información como un repositorio, sea esa información: piratería, pornografía, información de tarjetas de crédito robadas ...
  • Sobrescriba los archivos del sistema y obtenga acceso ilimitado al sistema operativo, y luego haga lo que quiera
  • Difunda los archivos contaminados sobrescribiendo los archivos que otros usuarios descargarían
  • Acceda a cualquier información almacenada en la computadora, incluidos los archivos de seguridad
  • Spread worms (¿recuerdas el Nimda worm ?
  • ¿Ser la fuente de ataques de cualquier otra computadora / sistema en la red / internet?
  • Si se tiene contenido seguro que se sirve a través de HTTPS, la gente podría acceder a él pensando que es seguro, pero no sería ...
respondido por el woliveirajr 24.08.2012 - 19:37
fuente
2

Estoy de acuerdo con todos los demás que dicen que esto es malo.

Lo que quiero agregar es responder tu pregunta sobre cómo mitigar la amenaza. La respuesta dependerá de la funcionalidad exacta de "Su programa" y de los recursos a los que necesita poder acceder como parte de su funcionalidad normal y legítima.

La primera y más natural sugerencia para probar: ejecutar "Su Programa" en una máquina virtual, por lo que no puede acceder al sistema de archivos real. De esta manera, puede escribir en el sistema de archivos de la máquina virtual, pero no se hace daño; en el peor de los casos, la máquina virtual se ve comprometida, pero no la máquina física subyacente. Si esto funcionará depende de qué tipo de acceso necesita legítimamente su "Programa".

Si esto es demasiado restrictivo, también puede considerar la tecnología de sandboxing, como SELinux, AppArmor, Systrace, seccomp y más. (Si se ejecuta en Windows, estoy perplejo. No conozco un buen programa de sandbox para Windows. Eso no significa que no exista, por supuesto).

    
respondido por el D.W. 29.08.2012 - 09:58
fuente

Lea otras preguntas en las etiquetas