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

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?

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í.

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.

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.

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.

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.

¿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.

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.

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.