Introduction
While studying for Offensive Security’s Cracking the Perimeter last 2018, I encountered proof of concept exploits relating to recovery of sensitive information from memory. A popular tool that actually does this in Windows is mimikatz however, this article will be presenting more about vulnerabilities on 3rd party applications instead of the one intended for what mimikatz targets. This type of vulnerability is described more through CWE-316: Cleartext Storage of Sensitive Information in Memory and you’ll actually be surprised that a lot of applications are still vulnerable to this type of issue.
Looking more into the vulnerability
Before I even bothered to discover the same type of vulnerability from other applications, I tried to check out what programs were already discovered to be vulnerable from this type of issue. Interestingly, there were a lot and here are some examples:
1. (2016) MySQL 5.5.45 (x64) Local Credentials Disclosure by Yakir Wizman
2. (2016) Team Viewer 11.0.65452 (x64) Local Credentials Disclosure by Alexander Korznikov
3. (2017) Mikogo 5.4.1.160608 Local Credentials Disclosure by LiquidWorm
This vulnerability is definitely not new. Even the popular program “Putty” was vulnerable to this issue and had an assigned CVE to it (CVE-2011-4607). The requirements to exploit the vulnerability is quite obvious. First is the need to have local access to the machine where the application is running and the second requirement is a tool to read the memory of the target process. This means that when it comes to penetration testing, taking advantage of this vulnerability comes into the picture during post exploitation (The phase where the penetration tester already made his/her way into the machine).
Privileges on the other hand should also be accounted for especially for the second requirement because if the process is running with administrator privileges, then the tool should also run with administrator privileges to recover the sensitive information from memory. This is also the reason why this type of vulnerability has a low score when it comes to the severity rating and low scored vulnerabilities are usually frowned upon in bug bounty hunting because these are either ignored by vendors or accepted business risks.
Cause of the Vulnerability
This vulnerability is quite simple, if the application involved processes or stores sensitive information during run time, then these sensitive information could be in clear text form in memory since it’s easier to process data without encoding or encryption. It should be common to see this vulnerability in applications made through programming languages that need manual memory management like C/C++ especially if there’s no code that disposes the data after using it. Apart from C/C++, programming languages that manage memory automatically like C# or Java could also be vulnerable depending on the code implementation.
Discovering Vulnerable Programs
After understanding the vulnerability, I’ve tested around 10 desktop applications that required a user login to see if the issue existed. From the 10 desktop applications that I tested, I found that:
- 5 applications were vulnerable to sensitive information disclosure
- 3 out of 5 stored sensitive information in memory with an indicator (Avast Anti-Virus, <redacted>, <redacted>)
- 2 out of 5 stored sensitive information in memory without an indicator (OwnCloud and Discord)
- From the 3 exploitable programs (those with indicators), 2 were actually hard to exploit because they were only exploitable up until the program window was closed for the first time so if the program was minimized to the system tray and the user opened it again, the sensitive information got cleared from memory while 1 of the 3 was not clearing the information in the whole life cycle of the program’s run time.
Please note that I had to redact two exploitable programs because of the disclosure policy of the vendors involved. The one for Avast Anti-Virus was also a lucky finding because they paid me 400 USD as a reward for the responsible disclosure plus having it assigned CVE-2018-12572 while the other vendor sent me a small gift.
Case #1 (No indicators that the clear text data were the credentials): OwnCloud Desktop Application
The desktop application from OwnCloud stored the username and password as clear text in memory but there were no indicators. After dumping the process memory of OwnCloud, notice that the password in the dump can be found as clear text however, after multiple tests, there was no specific byte pattern that could indicate it as the password.
Here’s a demonstration through Python:
Case #2 (Has indicators that the clear text data were the credentials): <redacted program>
This redacted program was quite interesting because the sensitive information remained in memory even after the program window was closed (app went to system tray) and was reopened again. This means that while using the application, the sensitive information can be recovered any time. Notice the difference of the proof of concept from Case #1 based from the video. A dumper in this case will only need to find the indicator like “userId” to get the email and “pwd” to get the password.
Proof of concept:
Result:
Case #3 (Has indicators that the clear text data were the credentials): Avast Anti-Virus
I specifically found the issue on Avast Anti-Virus’ licensing system where if the user logs in to his/her Avast account for the free or premium license, the credentials got stored in memory as clear text however, after closing the application and opening it again through the system tray, the credentials got cleared so it’s not really easy to exploit.
Here’s a demonstration through Python:
I’ve also sent the proof of concept to the exploit database.
To summarize, this type of vulnerability is simple to find but based from my experience working with the vendors for responsible disclosure, patching the vulnerable program is not as easy as it sounds like. Avast was able to fix the issue after more or less 6 months. This was after a major update and they mentioned that the affected code was running JS which was the reason why the information remained in memory (No control over the garbage collector) while others didn’t really mind the issue because they accept it as a business risk. If ever you’ll be able to find similar issues after reading this article, please do let me know and I’ll add an entry with your name down below.