¿Qué puede hacer un atacante si conoce las credenciales de mi base de datos?

Suponiendo que

• Está 100% seguro de que su servidor de base de datos solo acepta conexiones locales.
• Estás 100% seguro de que el atacante no tiene acceso al entorno local desde el que se permiten las conexiones.
• Usted está 100% seguro de que la aplicación que usa la base de datos es segura.
• Estás 100% seguro de que esas credenciales no se usan para ninguna otra cosa relacionada directa o indirectamente con el sistema.

Entonces, no hay problema en que estén expuestos.

Por supuesto, como pueden ver, esas son suposiciones muy grandes. Si está dispuesto a aceptar la apuesta, siga adelante y permita que se expongan las credenciales. Si no (no lo haría), entonces funcionará lo mejor posible en su seguridad, y mantendrán esas credenciales en secreto.

Si él no puede acceder a la base de datos, las credenciales no tienen sentido. Es como tener una llave de una puerta que está dentro de un búnker militar vigilado escondido en una ubicación remota en el desierto de Gobi. La clave solo es útil si puedes llegar a la puerta.

Dicho esto, sería una muy mala práctica dejar que sus credenciales se filtren de esta manera. Si sospechas que están comprometidos, ve a cambiarlos.

Mientras el servidor DB esté bien protegido y las credenciales estén bien conectadas a direcciones IP a las que no tiene acceso, no puede hacer nada con ellas, pero elimina un nivel de protección y si Si encuentra una forma de acceder a la base de datos, entonces se le da una idea.

Esto se llama defensa en profundidad. Múltiples mecanismos previenen un compromiso, sin embargo, si se sospecha que un nivel está comprometido, estará menos seguro hasta que arregle el compromiso.

En la práctica, casi todas las bases de datos SQL (MsSql, MySql, Oracle, etc.) tienen capacidad para ejecutar comandos del sistema operativo. Entonces, si el atacante conoce su contraseña de DB, puede ejecutar comandos del sistema operativo en la máquina de DB. Si el proceso que ejecuta su motor de base de datos tiene altos privilegios, el atacante puede hacerse cargo de toda la máquina. Más allá de esto está limitado con tu imaginario. Por ejemplo:

• Él / ella puede atacar a otras computadoras en su red desde la máquina de la base de datos.
• Si está utilizando la virtualización, el ataque puede extenderse al motor de VM y otros sistemas operativos en el entorno virtual pueden verse comprometidos.
• Recopile datos sensuales muy importantes para futuros ataques de ingeniería social.
• Tome los nombres y contraseñas de las cuentas de usuario y pruébelos en otros sistemas de información de su organización. ¿La mayoría de las personas usan lo mismo fuerte? contraseña en múltiples sistemas.
• Escuche el tráfico en su red y huela datos importantes.
• Inserte un troyano o puerta trasera para accesos futuros, etc.

Qué puede hacer para protegerse, aunque el atacante conoce su contraseña de la base de datos:

• Puedes limitar los privilegios de la cuenta de usuario db. No olvide que el atacante a veces también puede aumentar sus privilegios en la máquina mediante explotaciones especiales que utilizan vulnerabilidades en su sistema operativo.
• Deshabilitar las capacidades de ejecución del shell del servidor de base de datos (pero la mayoría de las cuentas de usuario de la base de datos tienen privilegios para habilitarlo de nuevo)
• Limitar los privilegios de proceso del motor de base de datos. La mayoría de las veces, los ataques de inyección de SQL son exitosos debido a una instalación incorrecta de los servidores db. Especialmente la configuración de MsSql permite configurar fácilmente las cuentas de administrador como propietario del proceso db.
• Aísle su máquina de db de la red. Solo deja peticiones entrantes. Necesitas hacer esto con una máquina cortafuegos externa. Recuerde que el atacante tiene acceso al sistema operativo, por lo que puede habilitarlo si lo limita desde el Servidor DB.
• Proteja las cuentas de sus usuarios mediante hash (por supuesto, con sal) y si su recurso de CPU está disponible, proteja los datos confidenciales con cifrado simétrico a nivel de aplicación.

Esta no es una lista completa. Se puede crecer más grande.