Zoom Endpoint-Security Considerations

Who put the "Zoo" in "Zoom"?

What I keep hearing these days is:

"We/I do not use Zoom for confidential conversations."

But what if someone does not only care about the confidentiality of a Zoom-session but also about the integrity of his or her own endpoint device? It’s not only the spoken word of a group within a Zoom session that is at stake – it is also the integrity and confidentiality of everything a conference participant has stored on their computer.

Thus, I spent two evenings (I think around 5-6h in total), looking at Zoom for Windows. Statically only – I did not perform a runtime analysis. In this report I summarize what I have seen. I’m pretty confident that this is only the tip of the iceberg. Just imagine what could be possible for a security analyst with time and a budget… I explicitly did not look for everything that is related to the disclosure of sensitive information to 3rd-party (e. g. leaking information to Facebook ).

This report is very superficial and does not go into detail. This is because I did this in my spare-time and I do not intend to spend more time on this. My goal is to point out the overall code quality and secure programming guidelines, as well as existing or missing software maintenance (which is necessary especially when using lots of 3rd-party libraries).

*

Ancient 32-Bit application

Seriously? Why?! Windows is shipped with 64-Bit support and various security enhancements for 64-Bit CPUs since Windows 7. That was 2009, eleven years ago. These days, even Windows 7 is End-of-Life. 2020 Zoom still ships (only) 32-Bit applications on Windows.

zData.dll

Usage of components with known vulnerabilities: OpenSSL

zData.dll uses an outdated OpenSSL library: OpenSSL 1.0.2o 27 Mar 2018

OpenSSL 1.0.2 is EOL (End Of Life) since December 2019. There are known vulnerabilities that won’t get fixed anymore.

Current project status:

or

Concatenation of SQL Statements

• CWE-89: Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)

In zData.dll, an SQLite backend is used to store various session data and configuration into an encrypted SQLite database. At several occasions in the code, SQL-statements are apparently simply concatenated, as illustrated below:

Example 1:

Example 2:

Depending on the implementation of the += operator, zData.dll potentially abets SQL injection vulnerabilities that can lead to information disclosure or execution of arbitrary code on Zoom-endpoints.

Ah, well, and… is this, by any chance, a z oom c ryptographic d ecryption k ey for the encrypted SQLite database?

I really don’t know. :-) However, encrypting the SQL database does not prevent someone from getting access to sensitive data that is stored in these databases. It seems like Zoom uses SQLite database for storing history-records, logs and probably also sensitive data such as passwords and/or cryptographic keys. I did not dive deeper into the usage of SQLite as a data-container, but it’s probably worth an exercise for the curious reader.

Zzhost.dll

Potential buffer overflow

While looking at the import tables of the binary, I stumbled across an sprintf() call… sprintf() is a potentially dangerous function and compilers issue warnings if a function like sprintf is used. It seems like such warnings are not bothering the Zoom developers.

• CWE-120: Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’) in logging function
• CWE-676: Use of Potentially Dangerous Function (sprintf)

To successfully exploit a vulnerability like this, it is necessary to control the contents of the source-buffer. I did not verify if malicious users can take control over the contents of this buffer. As this is a logging function, it might be possible for arbitrary attackers to influence the contents of the source buffer. Yet again, it may not be possible. Nonetheless, even opening this opportunity is very bad coding practice.

zCrashReport.exe

Windows Registry dump

Windows Registry contains quite some sensitive information, especially when accessed via a process running under privileged rights.

I found these strings:

"Dumping registry keys" sounds like a malicious function to me, so I tried to figure out if it is actually enumerating Windows registry keys and values. Indeed, this led me to Windows registry enumeration functions, e. g.:

Screen Capture Function in Crash Reporter

zCrashReport.dll exposes the following functions:

In crashReport.exe, operating system’s APIs that are relevant for capturing whole screens and windows are used.

Does Zoom submit screen-captures to their servers? This would be close about to be classified as malware.

Airhost.exe

Usage of components with known vulnerabilities

Airhost.exe uses libcurl Version 7.36.0. This version has known vulnerabilities.

curl depends on libssh. The libssh2 library that is present in airhost.exe has known vulnerabilities as well:

These vulnerabilities may not be exposed or exploitable in the context of the zoom app. Nonetheless, why would you use outdated and vulnerable libraries if you cared about your code at all? It’s easier to use the latest version than to assess whether the vuln affects your app.

Airhost encryption/decryption with hardcoded passphrase

airhost.exe uses a constant value as key for symmetric encryption: The SHA256 output of string “0123425234234fsdfsdr3242” is used to initialize an OpenSSL EVP AES 256 CBC context for encryption and decryption of data. To initialize the AES context, the string “3423423432325249” is used as constant IV.

Airhost AES256 CBC encryption with constant IV

zWebService.dll and tp.dll

Usage of components with known vulnerabilities

zWebService.dll & tp.dll use libcurl 7.55.1.

Even though this libcurl library is not as old as the one linked into airhost.exe, it is still pretty outdated. If you care about endpoint-security, here’s a list of the vulnerabilities:

turbojpeg.dll

Usage of components with known vulnerabilities

Turbojpeg.dll uses libjpeg-turbo version 2.0.0 (build 20190715)

Remote Code Execution vulnerabilities in turbojpeg/libjpeg-turbo

T.B.C.?

At this point in time I realized that I have to stop my excursion into the code base. You’re welcome.