¿Cómo proteger los inicios de sesión no autorizados en caso de que el servidor de DB se vea comprometido?

Efectivamente, todo lo que el atacante está haciendo es cambiar las contraseñas de los usuarios. Esto permitiría al atacante iniciar sesión en las cuentas de esos usuarios. En cuanto a cómo protegerse contra esto, no estoy seguro de que deba molestarse. Si alguien tiene acceso de lectura / escritura a tu base de datos, estás bastante hundido. En primer lugar, debe protegerse de que alguien obtenga acceso de lectura / escritura a la base de datos, no intente impedir que alguien que tiene acceso de escritura simplemente cambie la contraseña de alguien.

Esto es como preguntarse, si alguien irrumpe en tu hogar, ¿cómo podrías evitar que abran la nevera y te roben la cerveza?

Su pregunta se puede parafrasear como:

¿Cómo impide que alguien con acceso para cambiar los datos cambie los datos?

El primer paso es garantizar que solo las personas que se espera que tengan acceso tengan acceso. Se trata de buenas prácticas de administración de contraseñas y auditoría de cuentas (para aquellos que se espera que en algún momento tengan acceso), mientras que para evitar que las personas que nunca tienen la intención de tener acceso, parches regulares, inspecciones de código y pruebas de pluma.

Pero no puede evitar que su administrador de sistemas se vuelva loco (aparte de los buenos salarios y las condiciones de trabajo, etc.) y nunca puede probar que su sistema es completamente seguro. Pero todavía hay cosas que puede hacer para prevenir o contener dicha actividad.

La aplicación web clásica de 3 niveles tiene una cuenta de servicio en el nivel de aplicación que se conecta a la base de datos. He visto con frecuencia (y en el pasado, aplicaciones) en las que esta cuenta tiene acceso de lectura / escritura a todas las tablas que contienen los datos que se deben manipular. La restricción de las operaciones de lectura y escritura a registros específicos mediante el uso de procedimientos almacenados proporciona cierta mitigación.

Un enfoque complementario es hacer que la autenticación desde el nivel de la aplicación a la base de datos dependa de las credenciales proporcionadas por el usuario final en lugar de simplemente tratar la validación de las credenciales del usuario como una prueba de acceso. En su forma más simple, los usuarios finales se crearían como usuarios de la base de datos y la aplicación almacenaría sus credenciales cada vez que necesite conectarse. Sin embargo, este enfoque tiene problemas de escalabilidad, especialmente con Oracle, que tiene un proceso de autenticación bastante parejo que hace que la mayoría de las aplicaciones en Oracle reutilicen las conexiones persistentes. En ausencia de controles adicionales, también significa que las contraseñas del usuario final se almacenan en texto sin cifrar en lugar de solo la contraseña del servicio en texto sin cifrar (pero hay soluciones para esto).

La otra pieza importante del rompecabezas, después de haber hecho todo lo posible para evitar un incidente, es la detección: Captura de identificadores del cliente (dirección IP) cuando se modifican datos importantes: captura las consultas y el DML que se envía a esa base de datos y auditarla: desplegando datos de honeypot / canary

Creo que no puedes, si tienen el control del servidor de la aplicación, pueden parchearlo para omitir la comprobación de contraseña por completo.

El objetivo del hash es hacer que sea más difícil pasar de una base de datos filtrada al acceso a las cuentas en línea. Además, las contraseñas que los usuarios han compartido entre servicios son más difíciles de extraer.

Si tienen la capacidad de alterar solo la base de datos en vivo (y no el servidor de la aplicación), un 'pepper' agregado al hash podría evitar que reemplacen el hash con el suyo.

El escenario que describe es mucho peor que el atacante, ya que simplemente puede reemplazar las contraseñas de los usuarios por las propias. Si pueden modificar el código de su aplicación, pueden hacer lo que quieran. Con la reutilización de la contraseña, también me preocuparía que las contraseñas de texto sin formato estén expuestas.

Si ya no puedes confiar en el código de tu aplicación, entonces ya has perdido por completo. Lo único que queda por hacer es bombéelo desde órbita .

Editar: Dado que resulta que el atacante no puede cambiar el código de la aplicación, no podrá robar contraseñas de texto simple, pero dado que probablemente pueden hacer la mayoría de las cosas que la aplicación permite mediante la edición directa La base de datos no parece que valga la pena para evitar que reemplacen las contraseñas, incluso si fuera posible.

Supervisión de seguridad

Puede implementar herramientas que pueden monitorear todo lo que se encuentra dentro de una base de datos y crear advertencias cuando un usuario modifica información o ejecuta scripts dentro de la base de datos; la mayoría de estas herramientas informarán al instante que un usuario inicia sesión en la base de datos, y cada script y procedimiento. modificar / ejecutar durante su tiempo dentro.

Recuerde que su administrador de base de datos puede acceder a la base de datos, pero la información / tablas / scripts debe estar completamente restringida.

¿Cómo se puede proteger?

Usted implementa diferentes enfoques o procedimientos para el acceso de cualquier empleado a su base de datos y la ejecución de scripts y procedimientos.

Su administrador de base de datos tiene acceso a su base de datos, pero el acceso que otorga no es para la base de datos completa, solo para fines específicos enfocados principalmente en el mantenimiento.

Puede solicitar a Seguridad de la información las credenciales de otro usuario dentro de la base de datos con incluso más opciones disponibles, pero dependiendo de la importancia de esas opciones, podría definir más procesos.

• Muchas aprobaciones de diferentes personas para permitirle ese acceso.
• Alguien de Seguridad se quedará contigo mientras haces tu tarea.
• Puntos de restauración desde el punto en que comienza a trabajar con el superusuario.
• Las contraseñas son de un solo uso y se descartan una vez utilizadas

Las respuestas anteriores son correctas: si tienen acceso al servidor de base de datos y al servidor de aplicaciones, en gran parte se acabó el juego.

Sin embargo, en términos de la cuestión muy específica de cambiar una contraseña de usuario, @TTT la resumió bien:

  

Efectivamente, todo lo que el atacante está haciendo es cambiar las contraseñas de los usuarios.   Esto permitiría al atacante iniciar sesión en las cuentas de esos usuarios.

Esto es muy cierto

  

En cuanto a cómo protegerse contra esto, no estoy seguro de que deba molestarse.

Aquí hay una posible protección: ¡implementas la autenticación de dos factores! No está protegiendo a la base de datos de ninguna manera, pero significa que simplemente cambiando la contraseña no es suficiente para poder iniciar sesión como ese usuario.

Ahora, probablemente no ayudaría en esta situación: si tuvieran acceso completo al servidor de aplicaciones y al servidor DB, probablemente podrían desactivar el 2FA, o cambiarlo a algo que el atacante controlara. Pero en términos de protegerse contra alguien que cambia los hashes de contraseña (la lectura más restringida de la pregunta original) esto lo protegerá hasta cierto punto. Tenga en cuenta que tanto el atacante como el usuario real terminarían bloqueados (uno conocía la contraseña, el otro podría responder al desafío de dos factores), por lo que aún sería perjudicial.

Por supuesto, hay otras, mejores razones para la implementación de 2FA ("mejor" en el sentido de que protegen contra los vectores de ataque más probables, que no son ya "game over")

No entendí exactamente cuál es tu intención detrás de lanzar un hash nuevo en el campo apropiado. Y tampoco puedo decirle cómo es en general, ya que hay muchos sistemas db que manejan contraseñas, datos de usuario o cifrado de manera diferente. Las siguientes opciones están disponibles para el sistema db con el que trabajo (postgresql):

• la contraseña está del lado del cliente con hash y no estará sencilla en el servidor
• la contraseña obtiene un salt para cada conexión para evitar la captura del hash y su uso para más sesiones
• cifrado basado en certificados
• el cifrado de datos habitual a nivel de columna o sistema de archivos
• el cifrado del lado del cliente evita que los datos lleguen al servidor sin cifrar

Con estas precauciones debe estar bien protegido. Pero eso depende de la base de datos y del cliente (la aplicación web) que no especificó.