Team82 and Check Point Research (CPR) collaborated to look at the security of the popular QuickBlox software development kit (SDK) and application programming interface (API).
QuickBlox’s development framework runs under the hood of popular chat and video applications in critical industries such as finance and telemedicine.
Together, we uncovered critical vulnerabilities that could put the personal information of millions of users at risk.
Team82 and CPR also demonstrate proof-of-concept exploits against applications running the QuickBlox SDK and API.
We explain a number of unique attacks that could allow a threat actor to, for example, access smart intercoms and remotely open doors, or leak patient data from telemedicine applications.
QuickBlox worked closely with Team82 and CPR to address our disclosure, and has fixed the vulnerabilities via a new secure architecture design and new API.
Real-time chat and video services available within telemedicine, finance, and smart IoT device applications used by millions of people, rely on the popular QuickBlox framework. QuickBlox supplies mobile and web application developers with a SDK and APIs to deliver not only user management, real-time public and private chat features, for example, but also security features that ensure compliance with HIPAA and GDPR.
Claroty Team82, in collaboration with Check Point Research (CPR), conducted a joint research project to look at the security of the QuickBlox SDK. Together, we uncovered a few major security vulnerabilities in the QuickBlox platform architecture that, if exploited, could allow threat actors to access tens of thousands of applications’ user databases and put millions of user records at risk.
In this report, we will demonstrate exploits against multiple applications running the QuickBlox SDK under the hood, specifically against smart intercom and telemedicine applications. By chaining the vulnerabilities we identified with other flaws in the targeted applications, we found unique ways to carry out attacks that enabled us to remotely open doors via intercom applications, and also leak patient information from a major telemedicine platform.
Team82 and CPR worked closely with QuickBlox to resolve all of the uncovered vulnerabilities. QuickBlox committed to the fix by designing a new, secure architecture and API, and urging its customers to migrate to the latest version. We would like to express our gratitude and appreciation.
QuickBlox is a chat and video calling platform for developing iOS, Android, and web applications. It provides an API for authentication, user management, chat, and messaging, file management, etc, and an easy-to-use SDK that enables voice and video features. Therefore, it’s no surprise we first encountered QuickBlox while researching a particular intercom mobile application that would rely on such a framework. This led us down the research rabbit hole into both the QuickBlox framework and various applications that use it.
Before we understand the vulnerabilities we uncovered in QuickBlox, we must understand how a developer integrates the framework into their application. First, developers must create a QuickBlox account. A new application is then created using the QuickBlox dashboard that will generate the following credentials for the application:
Application ID
Authorization Key
Authorization Secret
Account Key
With these pieces of information, the application can request a QB-Token that will be used in further API requests. The given token is an application-level token that has limited functionality.
Once the application retrieves the QB-Token, it enables users to log in on top of this session so the session will have the context of the logged-in user. This is done by providing both the application session and the user credentials. Now the session is fully authenticated and authorized with the user permissions.
However, this way of authentication exposes a major flaw: an application session is required to create a user session. This means that each user must obtain an application session, which requires knowledge of the application’s secrets, specifically the Application ID, Authorization Key, Authorization Secret, and Account Key. In order to make it technologically applicable, app developers had to make sure these secret keys are accessible to all users. When looking at applications using QuickBlox, we noticed that most of them chose to simply insert the application secrets into the application.
When we first noticed that the official documentation guides customers to add secrets (AUTH_KEY, AUTH_SECRET) to their applications, we felt uneasy. It’s never a good idea to hide secret authentication tokens in applications because they are considered public information and can be easily extracted using various methods, from reverse engineering to dynamic analysis with Frida.
Once we understood the QuickBlox architecture, we decided to look into the QuickBlox API and examine what we can access using “public” information: application secret keys. We discovered a few critical vulnerabilities in the QuickBlox API that could allow attackers to leak the user database from many popular applications.
By default, QuickBlox settings allow anyone with an application-level session to retrieve sensitive information such as:
Get a full list of all users using the /users.json API route
Get PII user information by ID using the /ID.json API route - including name, email, phone, etc
Create new users using the /users.json
This means that anyone who is able to extract the static QuickBlox settings from the application will be able to retrieve personal user information, below, of all application users, and also be able to create multiple attacker-controlled accounts.
Although the default API settings do allow all of the above (get the full list of users, retrieve user information, and create new users), application owners can limit the application-level API access using an inner-settings menu.
While this does offer some mitigation to the vulnerabilities we discovered, we discovered another way of leaking the entire application database. By creating a rogue user account, it is possible for attackers to leak specific user information by accessing the /ID.json, where ID is the sequential user ID. Since QuickBlox uses sequential IDs, by simply brute-forcing a limited range, it is possible to leak all of an application’s user information. However, from a check we performed regarding this privacy setting on all of the applications we researched and retrieved the keys for, we discovered that only a handful chose to disable this API.
To understand the full scope of the issue, we decided to explore what types of applications are using QuickBlox SDK and what would be the potential risk if attackers were to extract the secret tokens. Using various methods such as Google dorking, searches in BeVigil, and other search engines we were able to find and extract QB tokens from dozens of different applications. Here’s a partial list:
Extracting keys was not as simple as looking in the code. In some instances, the keys were encrypted, while in others, the code was heavily obfuscated. In some extreme cases they were dynamically received encrypted from a remote server. However, regardless of the application, any app would require the secret key and somehow use it with a QuickBlox server. Developers can only put in obstacles to complicate recovering the application key; which will always be accessible to attackers, whether it takes five minutes to extract or two hours.
After extracting the tokens from each application we tried to understand how attackers could leverage their attack based on the application’s capabilities and/or further vulnerabilities in the application platform. We found many interesting attack vectors; here we will explain two scenarios - Cloud-based Intercom solution and a Telemedicine app.
The first attack vector we’ll explore involves finding and exploiting vulnerabilities in a cloud-based IoT platform used to manage smart intercoms sold by Rozcom, an Israel-based vendor that sells intercoms for residential and commercial use cases.
The company’s solutions include video intercoms that allow users to see who’s attempting to access a building or apartment that connects to Rozcom’s cloud-based management system via the QuickBlox platform. All of these connections and features can be accessed via Rozcom’s mobile application.
We found multiple vulnerabilities in the Rozcom architecture that enabled us to download all user databases and perform full account takeover attacks. As a result, we were able to take over all Rozcom intercom devices, giving us full control and allowing us us to access device cameras and microphones, wiretap into its feed, open doors managed by the devices, and more.
Rozcom, for a year-and-a-half, ignored our attempts to privately disclose our findings with the Israel National Cyber Directorate (INCD) acting as coordinator. INCD on May 4 allocated and published CVE-2023-31184, CVE-2023-31185 for the two vulnerabilities we uncovered.
Rozcom uses many identifiers for its assets. First, each building has a unique 10-digit identification number (for example: 171XXXX708), used to differentiate between different buildings on the platform. Unlike build IDs, which are constructed from “random” numbers, users are identified using the following structure: BUILDING ID + PHONE NUMBER (for example: 171XXXX708 0501234567). This means that the user ID is actually constructed from two different identifiers that should be kept a secret.
Users can use the Rozcom mobile application, below, to manage their personal intercom devices. Using the app they can open a door/gate, initiate a multimedia session with the device (stream video/audio, and do push-to-talk communication).
Behind the scenes, Rozcom is using the QuickBlox platform to handle multimedia sessions, transferring video/audio between the mobile app and the device.
As it turns out, Rozcom chose to use the user ID shown above as the user identifier in QuickBlox. And since we could leak the user database from QuickBlox we could get access to all of Rozcom users including Building IDs as well as the correlating users’ phone numbers.
Our next step was to look at Rozcom’s applications and cloud APIs in order to better understand the possible attack vector using the identifiers we leaked.
The first API we discovered allowed us to retrieve information about a building managed by Rozcom, by supplying the Building ID. By accessing the following API: getbuildingdetailpublic?buildingId=BUILDING_ID, we could return each building’s full address as well as the number of apartments in that building, below.
Next, we wanted to see if we could impersonate a user. By using the application, we noticed that users can access their account by entering their phone number and receiving a one-time password as an SMS message as an authenticator.
However, we discovered that this so-called OTP is actually not so one-time. Instead the same OTP token is maintained throughout every session. Users don’t usually notice this because they are only required to enter it during initial login, and the application saves the token behind the scenes. Then, using the user ID and the OTP, users authenticate to the application.
Furthermore, by reverse engineering the mobile application, we discovered another API route that could be used by attackers to leak the OTP token. By calling Rozcom’s API with the following function: gettenantauth?cellular=PHONE_NUMBER, the backend server returns the user’s OTP token.
This means that the only requirement to retrieve a user’s credentials is their phone number, which we managed to leak using the QuickBlox vulnerability. Moreover, the authentication code is static. Therefore, attackers can easily login on behalf of any user and use the application’s functionality to its extent. This allows them to open the door/gate, open video streams and more; they now fully control the intercom device remotely.
Telemedicine is the distribution of health-related services and information via electronic information and telecommunication technologies. It allows long-distance patient and clinician contact, care, advice, reminders, education, intervention, monitoring, and remote admissions.
We chose to look at a popular telemedicine application integrated with the QuickBlox SDK, in order to explore its attack surface by abusing the QuickBlox vulnerabilities described above. We are not disclosing the name of the app because it has yet to update to the new QuickBlox API and remains vulnerable at the time of publication.
This particular telemedicine platform provides chat and video services enabling patients to communicate with doctors. By combining the QuickBlox vulnerabilities alongside the specific telemedicine app vulnerabilities, we were able to leak all of its user database, along with related medical records and history stored in the application.
While researching the affected Android application, we were able to extract the embedded QuickBlox application keys. We could then authenticate to the QuickBlox API server, get an authentication token and obtain a user database for the application. These steps are not different from any other application that uses QuickBlox. However, here we are talking about patient and physician information, below.
In this telemedicine app, each user chooses their UserID and Password credentials used by the application. However, we discovered through reverse-engineering that the [REDACTED] application creates a new QuickBlox user with their UserID as login and a hard-coded static password ([REDACTED] for patients, and [REDACTED] for doctors).
This makes it possible to login in QuickBlox on behalf of any user—doctor or patient—and view all of their data. This includes:
Personal information
Medical history
Chat history
Medical record files
Furthermore, because full impersonation is possible by this attack, anyone can impersonate a doctor and modify information or even communicate in real time via chat and video with real patients on the platform on behalf of an actual physician. This is a very scary scenario.
Team82 and Check Point Research collaborated on this extensive look at the QuickBlox API, which is prominent in many chat and video applications used by millions of people across different industries. Together, we were able to uncover vulnerabilities in the QuickBlox platform architecture that could be exploited to allow attackers access to applications’ user databases. Millions of user records were at risk because of these vulnerabilities.
Our joint research led to a number of proof-of-concept exploits against applications running the affected API. We demonstrated how the combination of secret tokens and passwords embedded in the application and usage of an insecure QuickBlox API design could allow attackers to obtain a great amount of information about the end-users.
We worked closely with QuickBlox to remediate the issues. QuickBlox responded to our disclosure by designing a new secure architecture for its platform, and a new API. Its customers have been urged to migrate to the latest versions of both. Again, we thank QuickBlox for its cooperation and quick response to ensure these vulnerabilities were addressed and its users privacy and security ensured.
Research Lead
Check Point Research (CPR)
Security researcher
Check Point Research (CPR)
