3CX data exposed, third-party to blame

A third-party vendor of 3CX, a popular Voice over Internet Protocol (VoIP) comms provider, left an open server and exposed sensitive 3CX data. The issue went under the company’s radar, even though it was recently targeted by North Korean hackers.

While victims of cyberattacks should not be ridiculed, there’s a reason that sayings like “fool me once, shame on you; fool me twice, shame on me” resonate so well.

Earlier this year, suspected North Korean hackers exploited 3CX for supply-chain attacks, spreading malware to devices using the company’s software.

Despite this prior experience with data breaches, the Cybernews research team recently discovered open Elasticsearch (distributed search and analytics engine) and Kibana (data visualization and exploration tool) instances belonging to a third-party vendor of 3CX. The instances, containing sensitive 3CX data, were discovered on May 15th, nearly two months after the initial attacks became public knowledge.

“The finding suggests that the way 3CX deals with cyberattacks is insufficient since exposed instances were not detected. Meanwhile, skilled attackers could use the data to get back into 3CX networks,” Cybernews researchers said.

After we published the article, the company reached out to Cybernews and distanced itself from the affected third-party vendor. According to 3CX’s representative, “the only party involved in the case [...] with whom we maintain a relationship with is our 3CX Distributor who had purchased the license keys of the affected servers.”

“3CX distributors sell 3CX subscriptions and 3CX Hosting. 3CX distributors do not offer us any hosting services. The hosting provider used in this case was a third party vendor used by the 3CX distributor in question. We have no relationship with their third-party hosting provider. 3CX offers hosting via Digital Ocean, which was not used in this case,” the company’s representative said.

“The finding suggests that the way 3CX deals with cyberattacks is insufficient since exposed instances were not detected. Meanwhile, skilled attackers could use the data to get back into 3CX networks.”

Cybernews researchers said.

What 3CX data was exposed?

The exposed instances, which the company closed after we contacted them, contained information attackers could have used to spy on 3CX clients or make preparations for larger, more sophisticated attacks. The open instances exposed:

• Call metadata, including time, state, duration, phone number, and email
• License keys
• Encoded database strings

Attackers can leverage call metadata to develop an intimate picture of the callers’ behavior, deducing who called who and for how long. Additional information could allow them to conclude what was discussed during the calls.

“Moreover, the call metadata can reveal internal company information or even the health of an organization. For example, if there are many sporadic calls, that could signify panic,” Cybernews researchers said.

Meanwhile, exposing software license keys presents a different set of problems. Since they ensure that software is obtained legitimately, attackers can use exposed keys to use 3CX software without paying for it.

In some cases, activating software allows the user to sync data between devices. That way, attackers could access user data simply by installing the software and using a legitimate license key.

However, according to the team, exposing database connection strings poses the biggest danger. Connection strings serve as a set of directions for a program to find the database. Typically, they tell the program where the database is, its type, and how to access it.

“Exposed database connection strings can be exploited in several ways. For example, attackers could use the leaked data to connect to the resource without permission and proceed to read, copy, modify, or delete data stored within that resource,” the team said.

3CX’s safety measures

3CX was recently the victim of a cascading supply chain attack. Researchers at cybersecurity company Mandiant concluded that attackers first distributed malware via software from Trading Technologies, which then affected 3CX software.

Even though the company had to evaluate its security posture, the exposed Kibana and Elasticsearch instances went under the radar. According to the team, the exposed data was accessible since March 30th, 2022, months before the supply chain attack occurred.

Interestingly, after 3CX dealt with the cascading supply chain attack, it released a seven-step security action plan that discussed crucial steps to avoid similar leaks, such as a need to harden its network security, perform pen testing, and set up a new department for network operations and security.

“While taking these steps would contribute to enhanced security, they are either not yet effective or were not followed thoroughly, leaving the company vulnerable,” the team said.

Rocky disclosure process

After the team reported its findings to 3CX, the company explained that a third-party vendor hosted and managed the leaking instances. 3CX informed the third-party vendor, which contacted the team, saying it could not confirm if it owned the exposed instances.

Several days later, the team noticed somebody had set up authentication on the previously exposed instances. The team proceeded to inform 3CX’s third-party vendor, which revealed there was another party involved.

“The third party figured out that the exposed instances belonged to another third party, one that facilitated the connection between 3CX machines and its Customer Relationship Management platform. It turned out that the second third-party vendor set up authentication on the now-closed instances,” researchers said.

The team believes that if the two third-party vendors are not associated, 3CX should have informed the actual owner of the exposed instances first. The issue was resolved in less than a week despite the back and forth between third-party vendors.

Updated on June 27 [09:20 AM GMT] with a statement from 3CX.