In July, Microsoft disclosed that a Chinese hacker group was able to access the mailboxes of some organizations. The attack used stolen signing keys. Recently, Microsoft published a post-mortem analysis of the incident and its remediation.
The analysis is an interesting read. There are many lessons and best practices. The following are my preferred ones.
Our investigation found that a consumer signing system crash in April of 2021 resulted in a snapshot of the crashed process (“crash dump”). The crash dumps, which redact sensitive information, should not include the signing key. In this case, a race condition allowed the key to be present in the crash dump (this issue has been corrected). The key material’s presence in the crash dump was not detected by our systems (this issue has been corrected).
Memory dump is critical for security. An attacker may find a key within the memory. There are many techniques, such as entropy detection, brute force (This was the Muslix attack against AACS), pattern detection for PEM-encoded keys, etc.
Microsoft lists two impressive sets of security safeguards:
- Redact sensitive information from crash dumps before issuing them.
- Verification of the absence of key material (Like Github proposes when scanning code and binary)
Any secure software developer must know the risk associated with memory dump. Clear keys in memory should be limited to its strict necessary time. They should be erased or rewritten with nonce as soon as the code does not need them.