April 14, 2013

Are systems protected from memory scraping?

Lately I see a raise of memory scraping malwares that search sensitive data patterns, e.g. passwords, connection strings, SSNs and other secrets. As result, I have been looking for mitigation against this threat in .NET environment but didn't find anything. The main solutions that come along with threats are described below:

First solution: Encrypt configurations using DPAPI.
Result:  Bad solution.
Threat: Work only on configuration files, and still, the data stored in cleartext in the memory.

Second solution: Encrypt object using CryptoServiceProvider, e.g. AESCryptoServiceProvider
Result: Bad solution.
Threat: The sensitive cleartext data (prior encryption) can be inspected in the heap.

Third solution: Use .NET SecureString Class.
Result: Intermediate solution.
Threat: SecureString cannot be inspected in heap, however, it is possible to inject DLL into the process or replace another DLL of the application (easier). As result, the SecureString can be decrypted to cleartext.
For example, the following application should do something (we don't care what) with SecureString:

    class Program
        static void Main(string[] args)
            var secureString = new SecureString();
        private static void AppendChars(SecureString secureString)
The replaced DLL should look as follows:

    class MyApplicationHandler
        public static void DoSomething(SecureString value)
            var bitStr = Marshal.SecureStringToBSTR(value);
                var stringInHeap = Marshal.PtrToStringBSTR(bitStr);
The result of heap inspection can be seen below:

Forth solution: Use .NET SecureString Class AND sign application files.
Result: Intermediate solution.
Threat: Again, In normal state, SecureString cannot be inspected in the the memory. Moreover, DLLs cannot be replaced if application's files has been signed by trusted certificate (that not installed on the target machine). Bummer... another program still might be able to read the whole memory of the operating system.

Fifth solution: Use .NET SecureString AND sign application files AND harden operating system.
Result: Pretty secure.
Threats: Since no one can prohibit from hacker to inject DLL into process or even run side-channel attack by scraping all operating system's memory, it is required to combine software solution with infrastructure.  Therefore, by hardening the operating system, the hacker/malware might not have sufficient permissions to scrape the whole memory.

Sixth solution: Use point-2-point-encryption (P2PE), using hardware encryption.
Result: Great protection against memory scraping of credit cards. What about other sensitive data?
Threats: Mmmm... not in public :-)

In conclusion, there is no bulletproof countermeasure for memory scraping, but we can implement pretty good security solution by combining both software and infrastructure actions.