Information leakage is the most trivial mistake to make, but also to exploit. Let's see some examples for it in Zoom.

In this last article in our series dealing with Zoom vulnerabilities, we will take a look at information leakage. From a secure coding perspective, these issues are much more simple than injection or cryptography. But that is also the reason why it is easier for these kinds of bugs to slip through. We tend to think that vulnerabilities are complex things. In reality, sometimes a vulnerability like this is just a small mistake in a common module doing nothing special – but that module is still handling sensitive information. And leaking such information will always have disastrous consequences.

Exposing sensitive data can be intentional or unintentional. In the first case, the system designers or developers may have been simply unaware of the sensitive nature of the piece of data. Unintentional information leakage is usually a consequence of a design or implementation mistake.

The leaked data can either be sensitive user data handled by the application (for instance, patient data in case of a healthcare system, or a salary of an employee), or “just” sensitive with respect to the system’s operation (such as an internal ID, an IP address or a password). The latter may help the attacker in crafting an attack.

Specifically, in case of video conferencing systems, a meeting ID is obviously sensitive information. When the organizer does not put any other restrictions on participant admission, knowledge of the meeting ID is the only protection against anyone being able to join an ongoing conference. This trick has become so common that has got a specific name. Zoombombing describes a situation when an “intruder” pops up uninvited in an online video conference. Note that the even though the term has been named after Zoom, it has been used to describe attacks against any online video conferencing service.

Zoombombing

We all know what photobombing is: when somebody purposefully puts themselves into the photograph. To put it another way, when somebody appears in a photo intentionally, typically in the background, and thus hijacking the focus of the photo. Often done just for fun or as a practical joke.

Now we have the 2020 version of this: Zoombombing. One can use Zoombombing for many malicious purposes, from eavesdropping on confidential information (spying on the participants, or even downloading documents shared in the meeting) to a form of hacktivism, pushing a political agenda – or just trolling. In the first case, the perpetrator needs to stay unnoticed. However, for the latter, it is the other way around: one’s goal is to attract attention in the meeting.

Even trolling can serve a purpose (can be done for the “profit” part in “fun and profit”): since zoombombed sessions are usually terminated by the host due to the offending nature of the intruder, just think about disrupting a virtual class or an online exam this way. But we do not want to give anyone any ideas…

OK, but how can the attacker learn a meeting ID of an ongoing or scheduled meeting? The simplest way is to just use Google. A long-standing hacking trick exploiting information leakage is called Google Hacking is simply about using a search engine (typically advanced search operators and parameters) to find sensitive information of a certain kind on the Internet based on some common patterns.

Specifically, in case of Zoom, this means searching for leaked Zoom one-click join links (that were made public) containing the “zoom.us” domain name, and then learning possible meeting IDs from the URL. Of course, one can abuse such an ID and join a meeting only if the organizer did not restrict admission of participants – and there are several ways to accomplish that.

One of them is to set up a meeting password. On the positive side, since last year all meetings are set up with passwords by default, unless the account owner changed the setting. However, you should keep in mind that – again, by default – Zoom sends invite links with passwords embedded in them. This is nice from the UX point of view, but as always, it raises security concerns. So, ultimately, the best practice is to set up meetings with waiting rooms (and then let in participants one by one) and/or lock a meeting once everyone has joined. And then again, a waiting room is clearly good against Zoombombing, but it still exposes some meeting details when used without a password.

One additional weakness making the situation worse was the fact that Zoom indicated the meeting ID in the window title. This meant that any published screenshot of an ongoing call would allow Zoombombing.

The meeting was password protected, but still… (Source: twitter.com)

Here, the best practice is obvious: never post a screenshot of an ongoing Zoom meeting. It’s worth noting that Zoom has already fixed this issue by now and does not indicate the meeting ID in the title bar anymore. Along with some other meeting-related data, like the password and the full URL, Zoom shows the ID only in an information dialog after clicking a button.

Carpet bombing

But as always, the story does not stop at information leakage.

Without passwords and waiting rooms, the meeting ID is the only secret to prevent Zoombombing. Google hacking or learning these IDs from published screenshots are both low hanging fruit. However, these things are rarely published by meeting participants, so the risk is relatively low (definitely not zero, though).

Still, the meeting ID itself is 9-11 digits long, which leaves a fair chance of hitting a valid meeting ID out there – systematically trying out some values, either on a probabilistic basis, or even via brute forcing.

Last year researchers have notified Zoom about a possible weakness related to the automation of joining random meetings through generating one-click URLs with a script and then sending those requests. They’ve reported a success rate of 4% in hitting valid IDs when using pure random values. Automated detection was easy, as the Zoom server responded with “Invalid meeting ID.” in case of failure, and with some other response otherwise. As a mitigation, Zoom had set password protection on by default, stopped indicating invalid meeting IDs in an easily detectable way, and introduced a device lock-out for a period of time if several attempts were made by the same client to join an invalid meeting ID.

Which is good.

However, according to a blog article by KrebsOnSecurity, earlier this year another set of researchers demonstrated how one can evade all this – a practice that probably added to the increased number of Zoombombing incidents lately. SecKC, a security community from Kansas City, created zWarDial. The term Wardialing originates from the 1983 movie War Games, where a computer dialed all possible phone numbers in a given region to detect which of them had a modem attached.

zWarDial scans valid Zoom meeting IDs (not protected by a password) by using multiple Tor network proxies. This way the tool could make requests anonymously and Zoom servers could not trigger the aforementioned lock-out. It could detect around a hundred valid meeting IDs per hour, and they claimed that the chance of hitting a valid ID was 14% with one instance of the tool running. Obviously, running several instances in parallel could easily detect all possible meetings over a given period of time.

And that’s bad.

Information leakage best practices

To start with the most important thing: Zoombombing is illegal in many countries and states. The FBI has released an advisory earlier this year on the best practices to follow to prevent information leakage when setting up a Zoom meeting, and Zoom itself has released a set of best practices against Zoombombing.

Information leakage is one of those trivial mistakes that are easy to make and easy to exploit – but also easy to fix once you know what you have to fix. The A3 element on the OWASP Top Ten is Sensitive Data Exposure. This element is not about a specific weakness (like for instance Cross site scripting), but more of an umbrella category dealing with the consequences of various issues. Therefore, it is also rather tricky to formulate the best practices against mistakes in this domain. The only thing you can definitely state is: don’t commit those mistakes.

Another set of issues is related to the principle of fail-safe defaults. This principle states that the default behavior should always be to deny – or rather, the default behavior of a system should always be the one that supports security in the best possible way. Of course, the way to accomplish this is not always obvious, so one should continuously reconsider the system’s default behavior – and this is exactly what Zoom has been doing recently.

Finally, the usual note: as already mentioned, Zoom has patched some of the trivial weaknesses related to the meeting ID handling and checking in January this year. Also, they have dismissed the meeting ID from the title bar. Many things done, many still to go. The question is, as always, if they can save their reputation after all the negative news related to the security of their products and services following their sudden rise in popularity during the lockdown.

The future will tell.

Our training courses put a heavy focus on the principles of secure software design and implementation, and the many practical aspects of it (such as defensive programming, and adhering to the principle of fail-safe defaults). To avoid such potentially embarrassing (and dangerous!) situations, check out our list of training courses, and choose the one most relevant for your needs. After all, the principles of secure coding don’t change whether you’re working on an embedded system, a desktop application, a web application, or a cloud service.