Avoid Manipulating Passwords In Memory - It Is Easy To Reveal
Revealing clear text passwords in memory seems to be a trivial task. This post describes how to reveal clear text passwords and what countermeasures to apply.
Summary of steps:
- Install WinDbg
- Attach to process or open dump file
- Load SOS .Net extensions for WinDbg
- Enumerate threads
- Enumerate objects in thread
- Dump object's values
- Countermeasures and guidelines
Install WinDbg
Download and install WinDbg as described in How to install Windbg and get your first memory dump.
Attach to process or open dump file
WinDbg can analyze both running processes and memory dumps which conveniently can be taken offsite for further investigation. I've created simple console application that accepts user name and password pair as its parameters and stores in local variables in memory:
static void Main(string[] args)
{
string userName = Console.ReadLine();
string password = Console.ReadLine();
Console.ReadLine();
}
Compile and run the application. I called it SecretsInMemory. This is how it looks when running:
Attach WinDbg to the running application by opening File->Attach to a Process:
and press Ok.
Alternatively, we can create dump file - for detailed how-to refer to How to install Windbg and get your first memory dump.
To Investigate resulting dump file in WinDbg open File->Open Crash Dump
Load SOS .Net extensions for WinDbg
To analyze .Net assemblies we need to load .Net extensions by typing .load sos and hitting Enter:
Enumerate threads
Run !threads command to enlist available threads:
and then choose specific thread - use left most column for thread identification as follows ~[thread number goes here]s:
Enumerate objects in thread
Use !dso command to dump all objects in the thread:
Dump object's values
Use !do <object address> to dump specific object's values. Object address is a second column in the list generated by !dso command, the column named "Object" - just copy and paste it:
The password is revealed either by attaching to the process or analyzing a crash file that was taken offsite.
Countermeasures and guidelines
As rule of thumb avoid using custom built identification and authentication mechanisms and leverage those that the infrastructure offers - preferably Windows Integrated authentication. In case where all options exhausted and there is no other way but accept end user credentials, refer to the following article - Using Credential Management in Windows XP and Windows Server 2003. Techniques described in the article allow to leverage built in mechanism of accepting credentials from end user in more secure manner. It also keeps common familiar look and feel across custom application and built in Windows mechanisms leaving less room for end user confusion.
My related posts:
Other resources: