Skip to content

CVE-2023-36266: Keeper Desktop - Cleartext Password Extraction from Process Memory

Field Value
CVE CVE-2023-36266
Affected Software Keeper Desktop for Windows, versions before 16.10.2
Vulnerability Type Sensitive Data Exposure in Process Memory (CWE-316)
CVSS 3.1 5.5 (Medium) - AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Vendor Keeper Security, Inc.
Status Fixed in Keeper Desktop 16.10.2

Summary

Keeper Desktop for Windows versions prior to 16.10.2 stored custom field values in process memory in cleartext. A local attacker with the ability to read the memory of the Keeper process - or with access to a process memory dump - could extract sensitive data stored in custom fields without knowing the user's master password. This applied even when the vault was in a locked state.

Background

Keeper is a widely used password management application that stores credentials, secure notes, and arbitrary custom fields within an encrypted vault. Users commonly store sensitive values in custom fields, including API keys, software license keys, security questions and answers, PINs, backup codes, and other secrets that do not fit neatly into the standard username/password structure.

The Keeper Desktop application for Windows is built on the Electron framework. When a user unlocks their vault, the application decrypts vault entries and loads them into application memory to facilitate the user interface. The security expectation is that when the vault is locked - either manually or through an inactivity timeout - decrypted secrets should be scrubbed from memory so that they cannot be recovered by another process or through a memory dump.

Vulnerability Details

Analysis of the Keeper Desktop process memory revealed that custom field values persisted in cleartext within the application's heap memory. This condition existed both while the vault was unlocked (expected, to some degree) and after the vault was locked (not expected).

When a user locked their Keeper vault, the application updated the user interface to require re-authentication, but the underlying process memory was not fully sanitized. Custom field values - the raw secret strings that users had stored - remained resident in the process address space in readable form.

Discovery Methodology

The vulnerability was identified through systematic process memory analysis on a Windows test system:

  1. Environment setup - A clean Windows installation with Keeper Desktop installed. A test vault was populated with entries containing custom fields holding known sentinel values (distinctive strings that would be easy to locate in a memory dump).

  2. Baseline capture - Before unlocking the vault, a memory dump of the Keeper process was captured using Process Hacker. The dump was searched for the sentinel values to confirm they were not present prior to vault unlock.

  3. Unlock and verify - The vault was unlocked with the master password. A second memory dump confirmed the sentinel values were now present in cleartext, as expected during an active session.

  4. Lock and test - The vault was locked via the application's lock function. A third memory dump was captured. The sentinel custom field values remained present in cleartext in the process memory despite the vault being in a locked state.

  5. Extended observation - Additional dumps were taken at intervals after locking (5 minutes, 15 minutes, 30 minutes). The values persisted throughout the observation period. Standard username and password fields appeared to be handled differently, with some evidence of scrubbing, but custom field values were consistently recoverable.

  6. Validation with WinDbg - The findings were confirmed using WinDbg to attach to the running Keeper process and search heap memory for the sentinel strings, ruling out any artifact of the dump tool.

The custom field values appeared as contiguous UTF-16 strings in the V8 JavaScript engine's heap (consistent with Electron's Chromium-based architecture), typically near JSON-structured data representing the vault record.

Affected Data

The vulnerability specifically affected custom field values. These are user-defined key-value pairs attached to vault records. In practice, users store a wide variety of sensitive data in custom fields:

  • API keys and access tokens
  • Software license keys
  • Security question answers
  • PINs and backup codes
  • SSH passphrases
  • Cryptocurrency wallet seeds
  • Two-factor recovery codes

Standard credential fields (username, password) appeared to receive different memory handling and were not consistently recoverable after vault lock in all tests, though the boundary was not entirely clean.

Impact

A local attacker who can read the Keeper process memory can extract custom field values without any knowledge of the master password. This requires local access to the machine and sufficient privileges to read another process's memory (typically, running as the same user or as an administrator).

Practical attack scenarios include:

  • Malware with memory-read capability - Many information-stealing trojans routinely dump process memory of high-value targets like password managers. This vulnerability would allow such malware to harvest secrets from Keeper even if the vault appeared locked.
  • Shared workstation access - On machines where multiple users share a login, or where an attacker gains temporary physical access, a quick memory dump captures the secrets.
  • Forensic recovery - Memory dumps taken for IT troubleshooting, crash dumps, or hibernation files could contain the cleartext custom field values.
  • Post-exploitation lateral movement - An attacker who has gained initial access to a system and is looking to escalate or move laterally could harvest API keys, infrastructure credentials, and other secrets from Keeper's memory.

The CVSS score of 5.5 reflects the local access requirement. The confidentiality impact is rated High because the exposed data includes secrets that the user explicitly chose to protect in a password manager vault.

Disclosure Timeline

Date Event
May 2023 Vulnerability discovered and validated across multiple Keeper Desktop versions
May 2023 Initial report submitted to Keeper Security's security team via their responsible disclosure process
May-June 2023 Keeper Security acknowledged the report and began working on a fix
June 2023 Keeper Desktop 16.10.2 released with the fix
June 2023 Public disclosure of CVE-2023-36266

Vendor Response

Keeper Security's response to this report was professional and timely. The security team acknowledged the vulnerability promptly, provided regular status updates during the remediation period, and delivered a fix within a reasonable timeframe. The patched version (16.10.2) was made available through the standard auto-update mechanism, ensuring broad deployment.

Keeper's handling of this disclosure serves as a positive example of vendor coordination. Their established bug bounty program and clear reporting channels facilitated efficient communication throughout the process.

Remediation

  • Update Keeper Desktop to version 16.10.2 or later. The application's auto-update mechanism should handle this automatically for most users.
  • Verify the installed version by checking Help > About within the Keeper Desktop application.
  • Rotate secrets stored in custom fields if you were running an affected version on a system where local access by untrusted parties was possible.
  • Enable endpoint protection with memory-scanning capabilities to detect processes that attempt to read password manager memory.
  • Consider OS-level protections such as Windows Credential Guard and Hypervisor-Protected Code Integrity (HVCI) to limit cross-process memory access.

References