Bitwarden Heist – Cómo entrar en bóvedas de contraseñas sin usar contraseñas

Alcance del problema de Bitwarden

• La vulnerabilidad es solo para Windows, vinculada al desbloqueo biométrico de Bitwarden en Windows.
• Falla original: cualquier proceso ejecutándose como el mismo usuario con pocos privilegios podía leer un archivo JSON y pedirle a DPAPI la “clave biométrica” para descifrar la bóveda, sin solicitud de Windows Hello ni privilegios adicionales.
• En algunos escenarios de pentest, se usó acceso de administrador de dominio para extraer claves de respaldo de DPAPI desde Active Directory y descifrar bóvedas sin conexión; en otros, solo se necesitó acceso local de usuario.
• Según informes, Bitwarden corrigió el diseño en v2023.4.0 y cambió los valores predeterminados para que la contraseña maestra deba introducirse al menos una vez al iniciar cuando se usa Windows Hello.

Debate: ¿Vulnerabilidad grave o exagerada?

• Algunos ven el blog y el título como clickbait, señalando que:
  • Requiere acceso local (y a veces compromiso del dominio), lo que a menudo ya es “game over”.
  • El ataque es especializado y ya está parcheado.
• Otros argumentan que sigue siendo destacable porque:
  • Evita técnicas más ruidosas (keyloggers, volcado de memoria) y puede eludir algunas defensas del endpoint.
  • El acceso local puede venir de compañeros comprometidos o software no confiable, no solo de un obvio “ataque físico”.

Biometría, DPAPI y diferencias de plataforma

• Crítica: Bitwarden usaba inicialmente Windows Hello solo para confirmar que “el usuario está presente”, y luego almacenaba una clave simétrica de la bóveda en DPAPI, que cualquier proceso del mismo usuario (o un administrador de dominio mediante claves de respaldo de AD) podía recuperar.
• Patrón correcto sugerido: Windows Hello debería mantener una clave asimétrica; su clave privada (protegida por biometría) cifraría la clave de la bóveda antes de que esta vaya a DPAPI.
• Android/iOS se consideran más fáciles de asegurar por el aislamiento de apps y los modelos de llavero; en el hilo no se conoce un problema similar allí.
• Se menciona el comportamiento de la versión de macOS/App Store en torno a biometría y Keychain, pero los detalles siguen sin estar claros.

AppData de Windows, sandboxing y modelo de seguridad

• Fuerte crítica a %AppData% y al modelo general de “cualquier proceso como el usuario puede leer todos los datos de app del usuario”.
• Otros responden que esto está diseñado así: AppData nunca se pensó como un almacén seguro; si puedes ejecutar código como un usuario, puedes exfiltrar sus secretos.
• Amplia discusión sobre:
  • Falta de un aislamiento fuerte predeterminado de apps en Windows frente a los sistemas operativos móviles.
  • Intentos como UWP, AppContainer, MSIX y el aislamiento basado en el sistema de archivos que está por llegar, frenados por la compatibilidad hacia atrás y la resistencia de los desarrolladores.

Los gestores de contraseñas como punto único de fallo

• Algunos desconfían de las bóvedas de contraseñas como SPOF obvios que guardan “todos tus secretos”.
• Muchos responden que:
  • Sin ellos, los usuarios reutilizan contraseñas débiles, lo cual en la práctica es peor.
  • Una bóveda con una contraseña maestra fuerte y 2FA/MFA es un buen compromiso.
  • El compromiso de una bóveda ya desbloqueada es grave, pero el malware local a menudo podría robar sesiones activas o registrar pulsaciones de teclado de todos modos.
• Mitigaciones discutidas:
  • Guardar de memoria unas pocas contraseñas críticas y no incluirlas en la bóveda.
  • Usar tokens de hardware (por ejemplo, claves de seguridad) y almacenamiento separado para 2FA.