¿Implicaciones de seguridad de restaurar una copia de seguridad de una fuente desconocida?


31

Escenario : se le entrega una copia de seguridad de la base de datos y se le pide que la restaure en un servidor (que ya aloja otras bases de datos), pero no se le proporciona información útil sobre qué contiene la copia de seguridad o si se debe confiar en la fuente.

Pregunta 1 : ¿Cuáles son las posibles implicaciones de restaurar una copia de seguridad que bien podría ser maliciosa?

Pregunta 2 : ¿Qué puede hacer para proteger su servidor / los datos en otras bases de datos del impacto de restaurar una copia de seguridad potencialmente maliciosa? RESTORE VERIFYONLYParecería ser un buen primer paso. La respuesta final es probablemente 'restaurar la base de datos en una máquina virtual de sandbox sin acceso al mundo exterior', pero supongamos que esa opción está fuera de la mesa. ¿Qué más se debe hacer en esta situación?


1
Incluso suponiendo que la restauración sea solo de datos (sin procedimientos almacenados, o algo así), puede ocurrir mucha malicia. Supongamos que la copia de seguridad es para una aplicación web que contiene una tabla de usuarios, con sus respectivos niveles de permiso, una copia de seguridad maliciosa podría otorgar acceso a usuarios que no deberían tenerlos, y quién sabe qué podrían hacer con eso.
Lie Ryan

Muy extraño, nadie mencionó el riesgo potencial de los procedimientos o funciones de CLR. (ya no está deshabilitado de forma predeterminada)
ALZDBA

Respuestas:


21

Una base de datos puede contener código malicioso, posiblemente un procedimiento que va a cambiar una contraseña para el inicio de sesión "sa" o eliminar todas las bases de datos. Sin embargo, la única forma en que puedo ver que causa un problema es que un individuo restaure la base de datos y luego ejecute manualmente cualquier código dentro de esa base de datos. No se ejecutaría de manera automatizada.

No hay una configuración que se pueda aplicar dentro de una base de datos para que SQL Server ejecute automáticamente algunos bits de código dentro de la base de datos al restaurarlo en un servidor. Si lo hiciera, esperaría que Microsoft perdiera la certificación Common Criteria para el producto. Eso es un gran error haber permitido en un DBMS para mí.


Si Service Broker se vuelve a habilitar como parte de la restauración (usando WITH ENABLE_BROKERet al), el código puede ejecutarse "automáticamente". Obviamente, el restaurador no querría usar ninguna de esas opciones si la seguridad es una preocupación, pero podría estar enterrada dentro de una aplicación de un proveedor externo donde el usuario podría no verla.
Jon Seigel

¿Qué tipo de código se puede ejecutar a través de Service Broker? Nunca lo uso ni lo configuro.
Shawn Melton

Activación de procedimientos almacenados. technet.microsoft.com/en-us/library/…
Jon Seigel

2
Quizás también haga un RESTORE HEADERONLY para ver si la base de datos tiene habilitada la contención. Si es así, y la contención está habilitada en el servidor, los usuarios podrán acceder a ella sin que usted les dé acceso al servidor. Esto es para SQL 2012 o posterior, por supuesto. Si la contención no está habilitada en el servidor, y la base de datos en la copia de seguridad la tiene habilitada, la restauración fallará, por lo que solo es una preocupación si está habilitada en el servidor.
Robert L Davis

1
@ JonSeigel No creo que se disparen automáticamente. ALGO tiene que poner un mensaje en una cola enviándolo a un servicio, por lo que debe haber alguna interacción dentro de esa base de datos para insertar un registro o disparar un procedimiento o algo. Las colas de intermediario no solo siguen disparando sus procedimientos de activación sin ninguna interacción, sino que también buscan mensajes para mostrar en la cola.
JNK

11

Hay algunos pasos de prevención que puede hacer.

  1. Asegúrese de que nadie más que un administrador del sistema tenga acceso a la base de datos restaurada.
  2. Ponga el db en modo de usuario único después de que se complete la restauración.
  3. Verifique el código dentro de todos los procedimientos y funciones almacenados y los disparadores dentro de esta base de datos.
  4. Realice un dbcc checkdb para asegurarse de que no haya problemas de integridad.
  5. Verifique los usuarios que solían tener acceso a la base de datos y elimínelos a todos.
  6. Comience a permitir el acceso, muy restringido a objetos específicos controlados por usted.

Como dijo Shawn, el código no se ejecutará solo a menos que algún procedimiento almacenado que parezca vbalid tenga un archivo ejecutable de otro código malicioso. Esta es la razón de verificar el código dentro de cada uno de ellos antes de ponerlo en modo multiusuario.


10

Estoy llegando aquí, pero puedo pensar en al menos un escenario peligroso: si restaura una base de datos que tiene una tabla de archivos, esos archivos ahora están en su red de forma predeterminada (y específicamente, en su SQL Server). Podrías restaurar un virus.

Eso por sí solo no hará nada, por supuesto, el virus no se vuelve repentinamente sensible, pero si los usuarios intentan acceder al archivo, podrían infectarse. (Hola, dije que estaba llegando). Estoy imaginando un escenario en el que un hacker externo quiere recibir malware en la puerta, y luego envía un correo electrónico a Bob diciendo: "Aquí está el archivo: \ sqlserver \ filetableshare \ myvirus.exe ": en ese momento ya no se detectan los firewalls, y ahora nos quedamos con sus herramientas antivirus y antimalware internas.


2
También podría expresar esto como "la base de datos contiene instrucciones prácticas para nuestro personal que deben leerse y aplicarse". Si siguen el instructivo malicioso, lanzarán los cohetes sobre Moscú. Sería una varchar ordinaria en una tabla ... Lo mismo ocurre si restaura los archivos binarios e invita a los empleados a ejecutarlo sin validar el origen, lo tenía en camino.
Remus Rusanu

@RemusRusanu lanza los cohetes en Moscú, jajaja, ¡qué bien!
Brent Ozar

Me encanta la perspectiva de la ingeniería social. Un correo electrónico dirigido con un archivo .bak podría ser muy atractivo dependiendo del objetivo.
Max Vernon

7

RESTORE VERIFYONLY parece ser un buen primer paso. La respuesta final es probablemente 'restaurar la base de datos en una máquina virtual de sandbox sin acceso al mundo exterior', pero supongamos que esa opción está fuera de la mesa. ¿Qué más se debe hacer en esta situación?

La verificación de restauración solo verifica la integridad de la base de datos, NO le dirá si la copia de seguridad incluye un código malicioso o no. RESTAURAR VERIFICA SOLAMENTE no intenta verificar la estructura de los datos contenidos en los volúmenes de copia de seguridad. Es muy poco probable que si la copia de seguridad proviene del interior de la empresa donde trabaja podría ser maliciosa, pero si proviene de un tercero, debe tener cuidado, como señaló Shawn.

La documentación en línea de Microsoft dice que

• Por razones de seguridad, le recomendamos que no adjunte ni restaure bases de datos de fuentes desconocidas o no confiables. Dichas bases de datos podrían contener código malicioso que podría ejecutar código Transact-SQL no deseado o causar errores al modificar el esquema o la estructura física de la base de datos. Antes de usar una base de datos de una fuente desconocida o no confiable, ejecute DBCC CHECKDB en la base de datos en un servidor que no sea de producción y también examine el código, como los procedimientos almacenados u otro código definido por el usuario, en la base de datos.


7

La pregunta se centra principalmente en una copia de seguridad que contiene malware, pero también es posible obtener un comportamiento no deseado y potencialmente malicioso de la operación de restauración en sí.

En el pasado, accidentalmente descubrí que es posible bloquear SQL Server al intentar restaurar un archivo de copia de seguridad corrupto que hace que SQL Server intente leer más allá del final del archivo de copia de seguridad y bloquearse. No estoy seguro de qué versiones son susceptibles o exactamente qué se requiere para reproducir el problema. Documenté algunos detalles limitados aquí cuando me encontré con este problema hace unos años.


Buen punto. No quise necesariamente centrarme en "una copia de seguridad válida que contenga malware", bloquear el servidor SQL por medio de una copia de seguridad no válida también es una respuesta perfectamente relevante a "¿qué podría salir mal?"
Simon Righarts

5

¿Qué riesgo existe al restaurar una base de datos desconocida de una fuente desconocida? Ninguna.

¿Qué riesgo existe al permitir que una aplicación desconocida se conecte utilizando una cuenta sysadmin para conectarse a esa base de datos y comenzar a ejecutar el código? ¡UN MONTÓN! Si la cuenta de la aplicación solo tiene derechos dentro de la base de datos y no tiene acceso a nivel de servidor, entonces no hay nada que realmente pueda hacer fuera de la base de datos. Esto básicamente se reduce a tener una configuración de marco de seguridad adecuada en el servidor para empezar.


2

Se le entrega una copia de seguridad de la base de datos y se le dice que la restaure en un servidor (que ya aloja otras bases de datos), pero no se le proporciona información útil sobre qué contiene la copia de seguridad o si se debe confiar en la fuente.

Agradable. Usted exige una declaración firmada por escrito de quien le está diciendo que haga esto, y acepta que es totalmente responsable de las consecuencias. Si no están dispuestos a hacerlo, debe probar la instalación en una caja de arena después de examinar el archivo de copia de seguridad (si es posible) y examinar a fondo todas las tablas, procedimientos, etc. Si algo huele raro en algún momento, no lo ponga El sistema de producción. Incluso entonces, debe dejar en claro (a su jefe y sus superiores) que nunca confió en la copia de seguridad y que lo hace solo bajo órdenes directas.

Si no firman dicha declaración, alerta a sus superiores antes de hacer nada. Como profesional, es su deber proteger su sistema tanto como sea posible, sin importar lo que un superior tonto le ordene hacer. Puede que te despidan, pero puedes mantener la cabeza en alto y saber que hiciste lo correcto.


2

No hay muchos peligros por decir, aparte de algunos de largo alcance sugeridos aquí. Como se mencionó, es difícil tener cosas de ejecución automática en una copia de seguridad de la base de datos. Necesita algún tipo de mecanismo de activación exterior.

Obtenga una computadora portátil / de escritorio antigua y una versión de evaluación de su software de base de datos (SQLExpress) si las licencias son un problema. Copie el archivo de copia de seguridad en la máquina, desconecte la red / inalámbrica y realice la restauración. Entonces comienza a cavar. Tómate todo el tiempo que necesites, porque hay muchos lugares donde se pueden esconder cosas, la mayoría de ellas ya cubiertas por otras publicaciones en este hilo.

Su integridad de DBA y el buen estado de su entorno de producción es más importante que cualquier orden dada por un superior.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.