Hardening Time Machine Security

5

Ante la noticia de que ahora hay un ransomware para mac en la naturaleza pensé en la seguridad de mis copias de seguridad de la máquina del tiempo.

Permissions

Primero, eché un vistazo a los permisos de los archivos que residen en mi cápsula de tiempo, que son los siguientes:

Directorio de datos

  

Usuario (desconocido) Leer & Escribe

     

Grupo (todos) Leer & Escribe

Sparsebundles individuales por computadora respaldada dentro del Directorio de datos

  

Usuario (desconocido) Leer & Escribe

     

Grupo (personal) Leer & Escribe

     

Grupo (todos) Leer & Escribe

Parece que hay espacio para mejorar aquí. En primer lugar, no entiendo por qué se enumera un usuario desconocido. ¿Hay alguna razón para esto o puedo eliminar este elemento? En segundo lugar, ¿es necesario otorgar permisos de lectura y escritura a "todos" y "personal"?

Si entiendo correctamente, las copias de seguridad de Time Machine se ejecutan mediante el proceso backupd , que, en mi computadora, se ejecuta como usuario root . Parece que solo el usuario root debe tener Read & Acceso de escritura. ¿Es eso correcto? ¿Puedo eliminar los permisos existentes y agregar el usuario "root" con Read & Permisos de escritura?

Por último, ¿este cambio proporcionaría una línea de defensa adicional contra el ransomware? Si un ransomware se ejecuta como un usuario X normal y no obtiene root, podría cifrar todos los archivos a los que X tiene acceso de escritura, pero no podría cifrar las copias de seguridad de la máquina del tiempo, porque solo el root tiene acceso a ellas. ¿Es correcta esta línea o razonamiento?

Ejecutando OSX El Capitan, 10.11.3.

    
pregunta Philipp 07.03.2016 - 13:22

2 respuestas

2

Actualizar después de una discusión con bmike (ver más abajo)

Durante una copia de seguridad real de Time Machine, backupd monta dos recursos compartidos. / Volúmenes / Lo que sea y / Volúmenes / Copias de seguridad de Time Machine. Mientras que el primero no puede ser accedido por un usuario no root, este último puede. De hecho, es posible borrar las ACL de los archivos y sobrescribirlos posteriormente. Así que el problema de seguridad está muy abierto.

Respuesta original

Pensando un poco más sobre el sistema de montaje subyacente, llegué a la conclusión de que mi pregunta original contenía un supuesto erróneo, cuya eliminación tal vez hace que la pregunta sea obsoleta. Decidí escribir una respuesta en lugar de eliminar la pregunta en beneficio de los igualmente equivocados.

Cuando verifiqué los permisos de mis archivos dispersos, monté manualmente el disco de Time Capsule. Debido a que monté el disco como un usuario normal, este usuario se convirtió en el propietario del punto de montaje (verificando en el terminal, puedo ver que mi cuenta de usuario es el propietario del punto de montaje, siendo "staff" el grupo).

Ahora, mi suposición (que no era transparente para mí) era que si Time Machine monta el disco durante una sesión de respaldo, estaría presente en el sistema como si lo hubiera montado manualmente. Pero esto está mal. Ya que backupd se ejecuta como root, el punto de montaje pertenece a root (al registrar en el terminal, el propietario es "root", el grupo es "wheel", el grupo y el mundo no tienen derechos) y por lo tanto, un proceso que pertenezca a un usuario normal no podrá cifrar archivos en un Time Machine Disk montado por backupd .

Por lo tanto, en una configuración de Time Capsule no parece existir, por el momento, el peligro de que un ransomware cifre la copia de seguridad. Sin embargo, puede ser diferente con un disco duro externo conectado localmente. Recuerdo vagamente que cuando todavía usaba un disco duro externo, podía ver la partición de Time Machine montada en el Finder (algo que ahora no uso) y, por lo tanto, podría estar montada con derechos de usuario. No puedo probar esto, ya que no tengo un disco duro externo de la máquina del tiempo, pero tal vez alguien más pueda decir algo al respecto.

    
respondido por el Philipp 08.03.2016 - 18:08
2

Las copias de seguridad de Time Machine están protegidas principalmente por ACL que niega el permiso para que cualquiera pueda escribir en un archivo.

$ ls -le /Volumes/Whatever/Backups.backupdb/Mac/Latest/Macintosh\ HD/Users/me/Desktop/file.text 
-rw-r--r--@ 1 me    staff  - 14 Mar  8 11:54 /Volumes/Whatever/Backups.backupdb/Mac/Latest/Macintosh\ HD/Users/me/Desktop/file.text
0: group:everyone deny write,delete,append,writeattr,writeextattr,chown

Para que un programa malintencionado cambie un archivo en el subsistema de respaldo, primero deberá leer y eliminar cualquier ACL y luego podrá realizar un cambio en un archivo almacenado en el directorio de Time Machine.

$ chmod -a# 0 /Volumes/Whatever/Backups.backupdb/Mac/Latest/Macintosh\ HD/Users/me/Desktop/file.text 

Después del comando anterior, el archivo está abierto a modificaciones o eliminación total.

El código del programa no necesitaría ningún acceso de raíz especial, solo que se ejecutó bajo un usuario administrador normal para realizar este cambio y luego poder escribir en los archivos.

Ni el sandboxing ni la Protección de integridad del sistema detendrían cualquier proceso malicioso que se ejecute como administrador para encriptar / modificar / eliminar archivos de datos de usuario en una unidad de respaldo que se pueda montar (unidades de red) o que esté adjunta y ya montada.

Para fortalecer sus copias de seguridad, deberá tener una copia fuera de línea de alguna manera u otra, suponiendo que el mal actor sepa que debe verificar y modificar / eliminar la ACL antes de que se altere.

Revisaría las opciones de cifrado para proteger algunos archivos con los que no puede pagar un programa aleatorio y, opcionalmente, no almacenar su clave de cifrado para un segundo volumen de respaldo en su llavero.

De esa manera, el primer destino de copia de seguridad podría ejecutarse a menudo pero ser vulnerable al malware. El segundo destino le pedirá que, cada dos semanas o más, esté desactualizado si no lo monta y no inicia una copia de seguridad más manual.

No es lo ideal, pero presumiría que Apple podría volver a diseñar el sistema si este riesgo potencial se convierte en un riesgo real con el tiempo en OS X. El único problema con el guardián de puerta y el código firmado es que el malware más difundido es decir, es más probable que Apple lo impida para ejecutarse en máquinas que opten por la protección de Gatekeeper. En este caso, parece que se tardó menos de 48 horas desde el anuncio público de la amenaza al remedio para deshabilitarlo desde Apple.

    
respondido por el bmike 08.03.2016 - 19:33

Lea otras preguntas en las etiquetas