Header Ads Widget

Zoom App Hacked Via Remote SQL Injection

Patched Zoom Exploit: Altering Camera Settings via Remote SQL Injection

Older versions of Zoom software contain SQL injection vulnerability that allows remote attackers to change victim settings, including camera privacy options. This issue, which affected Mac and Linux clients, was quickly resolved, and Zoom users are no longer affected. I discovered this issue on April 7, shared it with Zoom on the same day, and fixed it on the April 12 MacOS release (4.6.11) and the Linux 14 April release (3.5.385850.0413). Now that this risk has been marked and all users need to upgrade to Zoom 5.0 or later, I wanted to provide a technical explanation of how I got this issue and look at some of the background scenes that went into finding Zoom.

The explosion of the Zoom explosion brought a unique challenge to outside security investigators like me. We anticipated that the attackers would spot a large pool of potential victims and point Zoom in all directions. One of our biggest concerns is the use of Zoom for desktop applications, which, unlike browser type, exists outside the browser’s security box. While attackers will be looking for practical security issues for desktop clients, we researchers can try to find them first and give Zoom a first chance to capture them before they are exploited. I chose to investigate the client on Linux, where I was very familiar with the testing tools, and then started looking for security issues that referred to the most popular platforms.

Don't MissHow to Open Somebody's Computer Without a Password (Setting Up the Payload)

Soon, the web browser is emerging as the most accessible attack of the Zoom desktop application. Visiting the Zoom meeting page in the browser can open a meeting in the app, so there should be a connection between the two. CSRF-style attacks from malicious web pages may be able to exploit the client. The source of the Zoom assembly page reveals that this browser-to-app connection occurs via the "zoommtg: //" custom URI program. These URIs contain a few parameters transferred to a blog installed with Base64, but it is not clear what all the parameters mean or how they can be exploited.

Instead of trying to understand all the parameters, I can go further by looking at the practical issues in the binary Zoom itself. This closed binary source has no bug fixes, and it can take a long time to undo large parts of the app. However, looking at binary strings provides useful information. In Binary Zoom, there are a number of SQL queries with detailed format specifications, indicating that SQL queries are created during operation instead of coded queries. This raises the potential risks of SQL injection, but it is far from over.

To investigate questions that are not part of SQL, it is helpful to identify what queries the application is making. This can be done by attaching the active Zoom client to the debugger and setting the crack location in the SQL query function. Without debugging, however, I have no indication of where that job is. Fortunately, one of the cables in binary revealed that SQLite version 3.27.2 is included in the application. The SQLite project source code is a public domain, so once I find a single SQLite function in Zoom binary, I can use it to quickly identify all related functions. This goes on until I get a "sqlite3LockAndPrepare" function that, as the name suggests, has prepared a SQL statement for action. I set up a debugging area here and watch when SQL's randomized questions are filled.

When I start the "zoommtg: //" URI in the browser, it hits the crack point not once but several times. One of these questions triggers the installation of a database with a long hexadecimal assembly code - the same hexadecimal code transmitted as a "tid" parameter to data recorded by the URI. This ensures that any website can use CSRF techniques to start a database call in Zoom, but to see if this leads to SQL injection, I should investigate further.

While any vulnerability to SQL injection can be problematic, I need to know what impact it can have on the privacy of the victim to know how urgent it can be. By changing the privacy settings in the application, I can use SQL Explorer to see which entries have been changed in the application database. Some settings appear to be particularly sensitive: automatically joining meetings without user's permission and joining meetings with a webcam and sound enabled. SQL Injury Attack can intentionally change these values ​​from their default, and, once Zoom is closed and reopened, Zoom will automatically share the camera and victim's sound at any meeting a malicious web page sends to it.

So far, all of this suggests a worrying risk to Zoom's elegance, but it's not complete without real benefit. I use a cleverly designed URI to send the app a simple load that is paid for in a single measure and then scan the database to get results, but the SQL test injection fails. In a successful attack, this single measure can be interpreted as part of the SQL command, and all data table entries will be restored to the same value, but that is not the case. It looks like the sanitization input function replaces all quotes with two quotes, to prevent attacks. Normal sewage passing, such as inserting a retrospective character, also fails.

While Zoom seems to be skipping normal SQL attacks well, it is probably possible to be secretly attacked. Many older web-application bugs exploit the differences in how the performance of sanitization and retrieval systems handles Unicode, and there are several Unicode edge cases to handle better. Perhaps the same exploitation process works here. After several failed attempts, I find a magical sequence that slides past the sanitization filter.

  • success \ xC2 'or 1 = 1;

The exciting material of the UTF-8 Unicode cables may explain what is happening here. In ASCII cables, each byte in a string has a value of less than 0x80 and represents a single character. In UTF-8 cables, multiple byte values ​​represent the same as ASCII, but values ​​greater than 0x80 represent the beginning of multiple byte characters. The sanitization function processes the loading and creates an ASCII thread with single-level characters that do not cause SQL injection. However, before these beats were transferred to the query function, they were interpreted as a UTF-8 series. Byte 0xC2 in the converted payload switch from representing a letter outside the ASCII range to represent the start of a two-byte letter UTF-8, which prevents the next byte from being translated as a single measurement. The UTF-8 definition contains only one residual value, and SQL injection attacks are effective.

As soon as I got enough to confirm the risk, I started writing a report to send to the Zoom security team. Evan Johnson, one of the security investigators who tested with Zoom, successfully repeated the issue on the Mac, confirming that the issue affected many users. We posted our findings, reproduction steps, and recommendations to Zoom on April 7 via HackerOne, and the issue was followed up with great difficulty the next day.

Zoom fixed the risk, released updated versions of the client, and gave us $ 2000 for reporting the problem. As this vulnerability was hard to exploit, and since Zoom now requires all users to upgrade to version 5.0 or later (containing the patch), we feel free to publish the risk information. Mandatory updates have closed the window for attackers who may want to exploit the issue, so there is no risk to users sharing the details of this exploitation.

Don't MissHack any Computer Over Wi-Fi with the WiFi Duck Payload Deliverer

Since the explosion of popularity, Zoom has taken many steps to improve the security of their product. They installed bugs, added privacy controls, and extended browser client support. The bug bounty system is just one element of strong defenses against attackers, but in this case, we have achieved a good result. All in all, I believe this shows that Zoom's security has been moving in the right direction and in the right hands as this change is in full swing. We took up the issue early, fixed it quickly, and as a result, Zoom users have become more secure.

Video Demonstration

Post a comment