¿Cómo almacenar un archivo de forma segura en el sistema de archivos de Windows?

3

Problema: tengo un servicio de Windows ejecutándose bajo la cuenta del sistema local. Tengo un blob de datos que quiero almacenar de forma segura y persistente entre reinicios. He decidido almacenarlo como un archivo (en lugar de una clave de blob binario en el registro de Windows?). Ya que estoy ejecutando un servicio, no puedo tener la interacción del usuario para obtener una contraseña y usar algo como pbkdf2, etc. para obtener una clave de cifrado para cifrar el archivo que contiene el blob de datos. Estoy buscando la mejor manera posible de almacenar el archivo de forma segura en el sistema de archivos de Windows. A continuación se muestra el conjunto de suposiciones que he hecho sobre lo que confío y en qué escenarios de ataque es importante seguir una implementación propuesta. Será fantástico si alguien puede abrir agujeros y también sugerir mejores alternativas.

Supuestos y escenarios de ataque: asumo que el sistema operativo es decir, las ventanas son confiables y seguras. Si se encuentra una falla de seguridad en Windows y mi archivo secreto / cifrado está comprometido, está bien. Si la cuenta de administrador está comprometida y el archivo se elimina, está bien. Sin embargo, otros usuarios sin acceso a decir windows \ system32 (que parece ser uno de los directorios más bloqueados) no deberían poder acceder o eliminar este archivo a través del código o la IU. Sería preferible que el archivo se pueda almacenar en una ubicación donde incluso los usuarios administradores no tengan acceso, pero mi servicio sí, pero no conozco esa ubicación. Los usuarios de administradores tontos que eliminan los archivos del sistema no son una amenaza / problema. El objetivo principal es proteger contra la eliminación trivial y la modificación del archivo a través de la interfaz de usuario y el código de usuario.

Implementación: planeo usar Windows DPAPI sin usar las credenciales de usuario (porque no puedo en el servicio de cuenta del sistema local) para bloquearlo a un usuario en particular. Planeo cifrar el archivo en el sistema local y también proporcionar alguna clave específica de entropía / servicio para cifrar y descifrar el archivo. La entropía específica de la aplicación será una guía más información que es específica del hardware (como la revisión de firmware u otros datos que pueden leerse en registros de hardware codificados) y solo mi servicio tiene acceso y ningún otro software puede acceder a esta información . Me doy cuenta de que si la actualización del firmware se actualiza o si se cambia el hardware, el descifrado no funcionará, pero esto debería ser una situación rara. Un atacante puede volcar / analizar el binario de mi servicio y descubrir la guía, pero es de esperar que la información específica del hardware sea difícil de encontrar. Si hago esto, y coloco el blob encriptado en un archivo en windows \ system32, solo los usuarios con privilegios de administrador / superiores que tengan acceso a este a través del sistema de archivos API / UI podrán descifrarlo utilizando DPAPI (si obtienen la guía y el hardware La información específica a la que nadie debería poder acceder o la lectura / escritura elimina el archivo mediante el código o la interfaz de usuario. Almacenar el blob sin cifrar en el registro debería ofrecer casi la misma protección contra la mayoría de los ataques, excepto que un usuario administrador puede modificar los datos binarios / blob y puede causar un mal comportamiento del software. DPAPI ofrece protección de integridad, así que elegí esto simplemente escribiendo en una ubicación segura en el registro al que nadie más que administradores pueden acceder.

¿Se ve bien o hay mejores maneras de lograrlo? ¿Algún otro agujero de seguridad para vigilar o pensar? Este es un problema bastante simple, así que me gustaría implementar la solución más simple.

    
pregunta Raghu 29.08.2015 - 14:36
fuente

1 respuesta

1

El escenario más común para servicios que se ejecutan independientemente de los usuarios que han iniciado sesión es utilizar la protección del sistema de archivos que proporciona el sistema operativo.

Aquí, eso significa que el servicio debe ejecutarse bajo una cuenta confiable. Una cuenta de confianza es algo que solo los usuarios de confianza (y los administradores) pueden acceder. Por cierto, como usted dice en los comentarios que no le importa tratar de defenderse contra el administrador local, eso debería ser suficiente. El SISTEMA puede ser una cuenta aceptable pero (quizás porque uso Unix y Windows) creo que una cuenta dedicada puede aclarar las cosas. Cuando un administrador ve una carpeta que es propiedad de SYSTEM y que solo es accesible a ella, podrían preguntarse qué servicio del sistema la usa, pero cuando es propiedad de una cuenta explícita, la pregunta desaparece.

Una vez que haya elegido la cuenta (local o AD), solo tiene que dar acceso solo a esa cuenta (y a la cuenta de administrador que usa para configurarlo), eliminar todos los demás permisos, opcionalmente, otorgar la propiedad a la cuenta específica, y deje que el sistema Windows proteja la carpeta.

    
respondido por el Serge Ballesta 11.12.2018 - 20:17
fuente

Lea otras preguntas en las etiquetas