Recientemente, hemos tenido dos informes de sitios de Discourse que fueron comprometidos, probablemente debido a contraseñas débiles de las cuentas de administrador. Por lo tanto, nos gustaría documentar:
- qué hacer cuando ocurre una compromiso
- qué podemos hacer para prevenir mejor esto en el futuro
La Base de Datos
Tenga en cuenta que Discourse, desde hace varios años, tiene las siguientes protecciones implementadas en torno a la base de datos del sitio:
-
Los enlaces de descarga de copias de seguridad completas de la base de datos solo se enviarán por correo electrónico válido de un administrador del sitio, por lo que no solo puede iniciar sesión (mediante el descubrimiento de contraseñas o al olvidar cerrar la sesión), sino que también debe controlar la dirección de correo electrónico de un administrador del sitio. Y ¿ya configuró la autenticación de dos factores (2FA) para su correo electrónico?, ¿verdad?
-
Para cambiar el correo electrónico del personal, debe verificar el control de tanto las direcciones de correo electrónico antiguas como las nuevas; mientras que un usuario normal solo necesita verificar el control de la dirección de correo electrónico nueva. Esto hace que sea mucho más difícil cambiar la dirección de correo electrónico de un miembro del personal.
-
Suponiendo que haya configurado la clave API de la base de datos de geolocalización (es gratis, requiere registro), recibirá una advertencia activa cuando los miembros del personal inicien sesión desde ubicaciones físicamente lejanas a donde iniciaron sesión por última vez.
-
Se requiere que los administradores que no hayan iniciado sesión durante más de un año revaliden su dirección de correo electrónico, para reducir la superficie de ataque. La configuración del sitio para esto es
invalidate inactive admin email after days(invalidar correo electrónico de administrador inactivo después de días) y su valor predeterminado es 365.
Aun así, en caso de compromiso, siempre debe asumir que una cuenta de administrador maliciosa ha descargado una copia completa de la base de datos/copia de seguridad del sitio.
Por lo tanto, debe restablecer INMEDIATAMENTE todas las contraseñas de cuenta usando el siguiente comando:
./launcher enter app
rails r 'UserPassword.update_all(password_hash: SecureRandom.hex * 2)'
Además, debe cerrar la sesión de todos los usuarios
./launcher enter app
rails r 'UserAuthToken.destroy_all'
Finalmente, debe eliminar todas las claves API
./launcher enter app
rails r 'UserApiKey.destroy_all'
rails r 'ApiKey.destroy_all'
Contraseñas de Cuenta en la Base de Datos
Según nuestra documentación de seguridad, Discourse utiliza hashes muy fuertes y lentos de atacar en las contraseñas almacenadas en la base de datos:
Discourse utiliza el algoritmo PBKDF2 para cifrar contraseñas con sal. Este algoritmo está bendecido por NIST. Los expertos en seguridad en la web tienden a estar de acuerdo en que PBKDF2 es una opción segura.
Y la longitud mínima predeterminada de la contraseña es 10 para usuarios y 15 para administradores, por lo que esto dificulta la fuerza bruta para revertir los hashes de contraseñas y obtener el hash. Pero eso no evita que los usuarios establezcan una contraseña como password1password1 o algo más que sea trivial de revertir, incluso con un hash fuerte.
Correos Electrónicos en la Base de Datos
El atacante puede ver todas las direcciones de correo electrónico de todos los usuarios de su sitio. Esta es normalmente información privilegiada que incluso los moderadores tienen que hacer clic en un botón para revelarla.
Contenido de Mensajes en la Base de Datos
Dado que el atacante tiene una copia de la base de datos, puede ver toda la información almacenada en todas las publicaciones.
-
Si tiene contraseñas o información de cuenta externas transmitidas en sus respuestas, privadas o públicas, debe cambiar esas contraseñas inmediatamente.
-
Si tiene información confidencial en sus respuestas, privadas o públicas, tenga en cuenta que el atacante puede ver esa información.
Mensajes Cifrados
Si está utilizando el complemento Discourse Encrypt, los mensajes cifrados estarán cifrados de extremo a extremo. Esto significa que si se filtra una base de datos, el atacante no podrá obtener acceso al contenido de los mensajes cifrados.
Regulaciones
Asegúrese de buscar asesoramiento legal profesional con respecto a su requisito legal. Ciertas regulaciones como el GDPR y CCPA pueden exigir la divulgación.
En el Futuro
Es posible que desee exigir la autenticación de dos factores para los usuarios del personal si tiene motivos para creer que su sitio estará bajo ataque. La configuración del sitio que desea es “enforce second factor” (forzar segundo factor).
enforce second factor
Obliga a los usuarios a habilitar la autenticación de dos factores. Seleccione ‘all’ (todos) para forzarla a todos los usuarios. Seleccione ‘staff’ (personal) para forzarla solo a los usuarios del personal.