¿Podría un pirata informático piratear el back-end de Dropbox o un servicio en la nube similar y robar los archivos privados que se supone que no deben compartirse?

Seguro. Esto es casi siempre posible con cualquier servicio de red, aunque puede ser muy difícil y, por lo tanto, muy improbable.

Echemos un vistazo a por qué:

En sus sistemas, habrá procesos “de fondo”, “internos” o “locales” que “hacen cosas” con los datos. Estos procesos hacen cosas útiles y necesarias como: respaldarlo, moverlo, monitorearlo, indexarlo, etc.

Algunos archivos en los servidores son accesibles desde redes externas (como Internet) pero tienen listas de control de acceso (ACL) que restringen quién puede acceder a ese archivo. Por lo general, el propietario (nuevamente, generalmente el propietario es el creador del archivo) tiene la capacidad de otorgar a otros usuarios acceso al archivo, o de otorgar acceso a “todos”.
Pero vea, los procesos del servidor también necesitan acceso al archivo, como vimos anteriormente. Algún proceso necesita hacer todo el trabajo que hace que el archivo esté disponible en primer lugar. Un proceso consiste en verificar que el usuario que intentó iniciar sesión existe, un proceso implica hacer que el archivo esté disponible a través de la interfaz web, y hay esos procesos de back-end molestos que se ocupan de cosas como configurar esas ACL, hacer copias de seguridad los archivos, etc.

Para un poco más de contexto, en un sistema basado en Linux o Unix, esos procesos generalmente se ejecutan todo el tiempo y se llaman demonios. En un servidor de Windows se llaman “servicios”. Los demonios y servicios también se ejecutan como si un “usuario” los estuviera ejecutando. Ese usuario tiene permisos al igual que usted u otro cliente. Son (generalmente) miembros de ACL “grupales” para simplificar el proceso de permisos.

Como puede ver, si pudiera obtener acceso al sistema como una de esas cuentas, ¡podría hacer lo que quisiera si los derechos y permisos de la ACL fueran lo suficientemente buenos!

El nivel más alto de permiso en un sistema Linux / Unix es “root”, una cuenta de usuario que se utiliza para hacer cosas muy importantes como iniciar (iniciar) todo el sistema operativo, iniciar procesos que tienen que iniciar otros procesos, etc. . En los sistemas Windows se llama “sistema” pero la cuenta “Administrador” puede hacer casi todo. Los otros demonios o servicios que mencionamos a veces comienzan con la ayuda de la cuenta raíz y luego son “degradados” a otra cuenta de usuario. Si las personas que ejecutan el sistema no son cuidadosas o no son conscientes de la seguridad, pueden dejar un proceso ejecutándose como usuario root o ejecutarlo como Administrador en Windows. En realidad, este es un problema común: tiene prisa y sabe que tener derechos de “Administrador” le permite al servicio hacer lo que desea, por lo que lo ejecuta así, en lugar de averiguar el nivel mínimo de permisos necesarios y una cuenta de usuario con esos permisos.

Una forma de proteger esas cuentas de los ataques es establecer políticas como “esta cuenta no puede acceder al sistema desde la red” o “esta cuenta no puede iniciar sesión y obtener un mensaje interactivo,” shell “o GUI.

Por lo tanto, si puede obtener acceso al sistema con una cuenta que tenga permisos suficientes, puede mover, copiar, eliminar o cambiar la mayoría de los archivos que estén allí. Algunos archivos no se pueden cambiar ni eliminar mientras están en uso; están “bloqueados”, pero eso no importa para nuestros propósitos.

Bien, entonces lo que queremos hacer es descubrir si hay alguna forma de acceder al sistema y luego “cambiar” nuestro “contexto” de usuario a un usuario más privilegiado, disfrazado como un usuario más poderoso o encontrando una forma de obtener un servicio que se ejecuta como un usuario diferente para hacer lo que queremos.

Eso puede implicar varios pasos, y la dificultad depende de cómo Dropbox tenga configurada su “arquitectura”. Tenga en cuenta que no he dado detalles sobre eso. No me he tomado el tiempo en este momento para ir a investigarlo, porque en un nivel abstracto, no importa . Para todos nuestros sistemas de servidores informáticos modernos de uso común, están configurados con usuarios, grupos, roles (a veces) y recursos. Los recursos de los que estamos hablando que necesitamos acceder desde Dropbox para obtener los datos que queremos pueden ser archivos en un sistema de archivos, blobs binarios de datos en una base de datos, blobs binarios de datos en alguna otra estructura de datos, lo que sea. El problema central es el mismo.

Hay cuentas que:

  • ejecutar el proceso del servidor web “front end”,
  • ejecutar un proceso de aplicación con el que el proceso del servidor web habla,
  • ejecutar una base de datos o directorio que contenga información sobre su cuenta de usuario y probablemente los permisos del archivo,
  • ejecutar procesos del sistema de archivos como copias de seguridad,
  • y que ejecuta el sistema central (el “núcleo”).

Si encuentra una manera de suplantar o cambiar su “contexto de usuario” a una de esas cuentas, o acceder al sistema y controlar uno de esos procesos, puede hacer lo que quiera. Acceda a los datos, cambie los permisos de los datos para que su propia cuenta pueda acceder a ellos, etc.

Si Dropbox ha hecho esto más fácil o más difícil, y si lo ha hecho más fácil o más difícil desde el lado del servicio “orientado a Internet” es lo que lo hace posible, probable o muy poco probable. Ciertamente es posible porque de lo contrario los servicios y sistemas como este ni siquiera pueden funcionar en absoluto.

La respuesta a esto es casi siempre “sí”. “Ellos podrian.”

Al final del día, los grandes proveedores de servicios son atacados y comprometidos como todos los demás (y como todos los demás, son administrados por personas que son tan vulnerables como los demás).

Equipos brillantes con equipos de seguridad impresionantes (como Google) prueban esto con compromisos históricos.

Con el tiempo, algunos proveedores de servicios construirán una reputación de colocar la seguridad sobre las características (o sobre el marketing), pero el historial muestra que la mayoría de los clientes no necesariamente recompensan esta compensación, y esos proveedores siguen siendo jugadores de nicho o desaparecen. (Ver openbsd o tarsnap)

En última instancia, la única forma en que puede garantizar que sus datos estén seguros cuando se cargan es si primero se cifran en su extremo (lado del cliente).