Dumpster diving application memory
4 min read
Penetration testers hunt for weak spots in applications so vulnerabilities can be fixed before bad actors find them. One way to find those weak spots is to inspect application memory to see if sensitive data is being stored in a way that hackers can access. In this article, we’ll explain how pen testers use the memory inspection process to strengthen app security.
What is memory inspection?
Applications have memories — data that is generated from application processes is then stored within the app’s files, either on a device or in the cloud. If an app hasn’t been set up securely, a hacker could dive into those files and retrieve sensitive data.
White hat hackers — the people who hunt for vulnerabilities so they can be patched — can also use these same methods for good. By searching through the memories of mobile and desktop apps, as well as inspecting the installer file contents, they can unearth potential risks and keep users safe.
Dumping the memory
The first step in the inspection process is extracting the memory from an application. This is easily done on a Windows OS — we just open the task manager and create a dump file.
MacOS, on the other hand, requires us to boot into recovery mode and disable System Integrity Protection. This feature protects processes from being modified or tampered with. Having done this, we can then make a process dump.
Memory dumping gets a bit trickier when we approach mobile applications. Mobile devices usually require root privileges in order to extract the contents from an app’s memory with the help of the Frida tool.
After this step, we should be left with a .txt or a .dmp file which contains the extracted memory. It is a good idea to run this file through the “strings” utility to filter human-readable strings of a particular length because the dump might contain non-ASCII characters.
Searching for secrets
Once we have dumped the memory, we can start working with what we have. Primarily, we are now searching for information that reveals the following:
- Session identification values
- Access tokens
- Service account credentials
- Personally identifiable information
- Authentication passwords
- Database connection strings
- Encryption keys and other master secrets
- Data of a higher security classification than the logging system is allowed to store
- Commercially sensitive information
- Information that is illegal to collect in the relevant jurisdictions
- Information a user has opted out of collection, or not consented to
The sensitive information listed above could be used by malicious actors for their own benefit. If this information is available through memory inspection, that’s a problem that needs to be fixed.
It would also be a good idea to use automated scripts that are able to pick out various access tokens, API keys, and other values. For example, the following regex rule can be used to find AWS keys:
((‘|\”)((?:ASIA|AKIA|AROA|AIDA)([A-Z0-7]16))(‘|\”).*?(\n^.*?)4((‘|\”)[a-zA-Z0-9+/]40(‘|\”))+|(‘|\”)[a-zA-Z0-9+/]40(‘|\”).*?(\n^.*?)3(‘|\”)((?:ASIA|AKIA|AROA|AIDA)([A-Z0-7]16))(‘|\”))+
Source: I scanned every package on PyPi and found 57 live AWS keys | Tom Forbes
Understanding the risks
With many applications now storing data and running processes in the cloud, the risks posed by hackers who dumpster dive app memory are even greater. If bad actors can find service account credentials, Google API keys, and Firebase URLs in the dump, they could use these to their advantage.
Usually, service account credentials are used to retrieve an application’s remote configuration. If an attacker gets hold of valid credentials to access cloud systems that are improperly configured, no amount of firewalls can keep them from accessing the computing, network, and storage assets in that cloud environment.
It should be noted, however, that leaving account keys in the memory is not a problem as long as the IAM is configured correctly and the principle of least privilege is applied.
A penetration tester should pay close attention to the scope of tokens left in app memory as well as privileges to service accounts, both of which can be as dangerous as the exposed service account credentials.
Even if we do not find any security vulnerabilities, memory inspection is still worthwhile. We might discover unused tokens or accounts that are no longer needed, and deleting these can cut costs in addition to reducing security risks.
Fixing the vulnerabilities
The purpose of memory inspection is to find possible vulnerabilities and sensitive data that might be exposed. Afterwards, such vulnerabilities have to be fixed.
The principle of least privilege should be applied when resolving memory issues. Keep only absolutely necessary data and throw out everything else. This is a simple concept that will limit the potential for you to disclose sensitive information.
Checking application memory may be considered low-hanging fruit in the cybersecurity world. However, information stored or processed in a client’s memory is available to administrators and should be regularly checked from the vendor’s side.
We all make mistakes, and it is useful to carry out an inspection periodically. Doing so not only helps us to find and fix the errors but also deepens our understanding of the application’s inner workings.
