Attacking Secret Data

Attacking Secret Data

Secret data is susceptible to two main threats: information disclosure and tampering. Other threats become apparent depending on the nature of the compromised data. For example, if Blake's password is disclosed to a malicious user, the password could be replayed by the attacker to spoof Blake's identity. Therefore, in this example, an information disclosure threat becomes a spoofing threat.

An attacker can access private information held in software in many ways, some obvious and others not so obvious, depending on how the data is stored and how it's protected. One method is simply to read the unencrypted data from the source, such as the registry or a file. You can mitigate this method by using encryption, but where do you store the encryption key? In the registry? How do you store and protect that key? It's a difficult problem to solve.

Let's imagine you decide to store the data by using some new, previously undiscovered, revolutionary way. (Sounds like snake oil, doesn't it?) For example, your application is well written and builds up a secret from multiple locations, hashing them together to yield the final secret. At some point, your application requires the private data. All an attacker need do is hook up a debugger to your process using the secret, set a breakpoint at the location where your code gathers the information together, and then read the data in the debugger. Now the attacker has the data. One way to mitigate this threat on Microsoft Windows NT and later is to limit which accounts have the Debug privilege referred to as SeDebugPrivilege or SE_DEBUG_NAME in the Microsoft Platform SDK because this privilege is required to debug a process running under a different account. By default, only members of the local administrator's group have this privilege.

Another danger is an asynchronous event, such as the memory holding the secret becoming paged to the page file. If an attacker has access to the Pagefile.sys file, he might be able to access secret data. Perhaps the computer is put into hibernation so that it can be started up rapidly, in which case all the contents of the computer's memory are written to the Hiberfil.sys file. Another, perhaps less obvious, issue is your application faulting and a diagnostic application such as Dr. Watson writing a process's memory to disk. If you have the secret data held in plaintext in the application's memory, it too will be written to the disk.

Remember that the bad guys are always administrators on their own machines. They can install your software on those machines and crack it there.

Now that we've seen how a secret can be leaked out, let's focus on ways to hide the data.