CWE-316: Sensitive Information Stored in Memory

In this section, we will understand how an attacker can extract sensitive data if application stores sensitive information in clear-text in memory.

TL;DR

As per CWE-316, The sensitive memory might be saved to disk, stored in a core dump, or remain uncleared if the application crashes, or if the programmer does not properly clear the memory before freeing it.

It could be argued that such problems are usually only exploitable by those with administrator privileges. However, swapping could cause the memory to be written to disk and leave it accessible to physical attack afterwards. Core dump files might have insecure permissions or be stored in archive files that are accessible to non authorized people. Or, uncleared sensitive memory might be inadvertently exposed to attackers due to another weakness.

Overview

Impact

Successful attack can lead to leakage of sensitive information such as login credentials, card data information, keys etc.

Requirements

1. Process Hacker (https://github.com/processhacker/processhacker)

2. Drltrace (https://github.com/mxmssh/drltrace)

Risk Assessment

Impact	Likelihood	Severity	Remediation Cost
Medium	Medium	High	Medium

Exploitation

For demonstration, I am going to use Damn Vulnerable Thick client Application

Firstly, we are going to install Process Hacker in our machine and check the properties of our running application as below:

Viewing properties of Application

Now we have to go to the memory tab and click on strings and then minimum length will be the length of string. Here, I chose 10 as below:

Searching strings

Now we got all the data which is currently stored in memory as strings. You can save it to a text file and use any text editor for nicer view and quick search. After searching for a while. I have found the below sensitive information:

DB Credentials along with Decryption Key is visible

As we can see that we have got the following information which can be used to login into the DB by an attacker:

• DB Server IP

• DB Encrypted Password

• DB Username

• Decryption AES Key

• Decryption IV

Note: We have to decrypt the password using extracted AES Key and IV which we will cover in upcoming section.

Remediation

Few Simple steps to mitigate this attack:

1. Prefer the system's authentication dialog (or any other mechanism provided by the OS) for authentication to privileged services.

2. Do not hard code sensitive data in programs.

3. Disable memory dumps.

4. Do not store sensitive data beyond its time of use in a program.

5. Do not store sensitive data in plaintext (either on disk or in memory).

6. Securely erase sensitive data from disk and memory.

7. If you must store sensitive data, encrypt it first.

Reference(s) and Guidelines

MSC18-C. Be careful while handling sensitive data, such as passwords, in program code - SEI CERT C Coding Standard - Confluence

MSC03-J. Never hard code sensitive information - SEI CERT Oracle Coding Standard for Java - Confluence

MSC41-C. Never hard code sensitive information - SEI CERT C Coding Standard - Confluence

Name	Link(s)
MITRE CWE	CWE-259, Use of Hard-coded Password CWE-261, Weak Cryptography for Passwords CWE-311, Missing encryption of sensitive data CWE-319, Cleartext Transmission of Sensitive Information CWE-321, Use of Hard-coded Cryptographic Key CWE-326, Inadequate encryption strength CWE-798, Use of hard-coded credentials

Conclusion

So in this part we have learned how an attacker can extract sensitive information with few basic steps.

I hope you enjoyed reading and in case, you have any questions or feedback, feel free to reach me out. :)