The Potential of Finding Privilege Escalation Vulnerabilities Through CWE-347

I found the concept of privilege escalation attacks quite interesting because in theory, it’s easy to understand the goal but it actually requires creativity to execute or even discover. While doing research, I came across CWE-347 that was assigned to “Improper Verification of Cryptographic Signature”. Its description follows as “The software does not verify, or incorrectly verifies, the cryptographic signature for data”. Having a thought about this, if we talk about verifying cryptographic signature for data, we point out the integrity of the data involved or simply, “is the data tampered or not?”

If you’ve seen the example code given in the CWE-347 page, you’ll notice that the verification of the cryptographic signature of data can be in the form of checking if a downloaded file was tampered with or not.

In the real world, a common scenario for software applications that should be doing verification checks would be the following:

  • Whenever a software application downloads and installs a package update for itself (Most software applications have this feature).
  • Whenever a software application downloads and installs 3rd party applications (Ex. driver managers, download managers).
  • Whenever a software application executes 3rd party programs.

If no signature verification happens, one can simply replace the downloaded package with a malicious one to have it executed by the program but that doesn’t make much sense because to replace a package, prior code execution is already required although if you think about it, if it’s a driver manager running administrator privileges, that might be a vector for privilege escalation.

After testing around 10 chosen software applications, I found that 3 were not really implementing functions for data integrity verification in modules related to their software updater or simply some functions that execute another file included in the software package. To list down a few cases from those 10 chosen software applications:

Case #1: Telegram Desktop (Software Updater) – Not Vulnerable

Since the desktop version of Telegram has its source code open for the public, a short code review was done to see if the vulnerability existed. The initial observation was that since the source code was written in C++, a common Win32 API that would run package files would be “ShellExecuteA”. Seeing that it existed on lines 469 and 487, I found that there was no code that verifies the hash of the executable file or the shortcut in place so I communicated with someone from Telegram through email and he replied with the specific lines of code that does the verification. Apparently, I was looking in the wrong place and wasn’t able to see that part.

If however those specific lines of code didn’t exist, the severity of the vulnerability is still somewhat negligible because of the following factors:

  • Telegram is installed in the following path: “C:\Users\<user>\AppData\Roaming\Telegram Desktop\”. This means that it was installed without administrator privileges.
  • Replacing the Telegram executable with a malicious one to be triggered when the update happens will initiate code execution but as mentioned earlier, that doesn’t make sense because replacing the executable already requires prior code execution so, we should narrow down our search to programs that take advantage of administrator privileges.

Case #2: <REDACTED> (Software Updater) – Vulnerable [CVE-2019-12162]

I had to redact this for now because the developers haven’t fixed the issue yet and I didn’t have permission to post for now. The application doesn’t verify the integrity of the package before running it and the reason why it was assigned with CVE-2019-12162 was because this had the potential to escalate privileges if a malicious user replaced the update package because it was saved in the AppData folder while the installation path was in the Program Files. It so happened that the application required confirmation from the user to install the downloaded package which left room for the package replacement to happen.

Case #3: Telerik Fiddler (Win8 Loopback Exemptions) – Vulnerable [CVE-2019-12097]

Telerik’s Fiddler has another case which isn’t from the update package but is specific to one of its features. Fiddler is by default installed in C:\Users\<user>\AppData\Local\Programs\Fiddler. Since the feature Win8 Loopback Exemptions required administrator privileges, if a malicious user was able to replace the EnableLoopback.exe file found in the same installation folder, a potential privilege escalation can happen mainly because Fiddler doesn’t check the integrity of the file before executing it.

The developers for Fiddler allowed me to release the details publicly even if the fix hasn’t been published yet because of the fact that the vulnerability is still a bit complex to execute.

Case #4: Dell Driver Update (Not Vulnerable)

I found the analysis for this application quite straightforward because it was written in a .NET programming language plus it didn’t have any obfuscation. This was one of the main targets because a driver updater should obviously run with administrator privileges to install the drivers in a machine however, it was downloading the packages on a path requiring administrator privileges to access so this was a dead end.

Some other programs like Discord, ShareIt, Signal, and other Dell programs were also secure from this vulnerability while another program assigned with CVE-2019-12096 was similar to Case #2. I’ll have to update the details here once the other two programs with assigned CVEs have been fixed.

Leave a Reply

Your email address will not be published. Required fields are marked *