Are Your Desk Phones Listening In On You?

Yealink vulnerabilities show how that in UCC, security matters

Yealink vulnerabilities show how that in UCC, security matters

For better or for worse, data collection is something many of us have become accustomed to. From cookies on webpages to search terms being tracked, our activity over the internet is normally monitored to some degree, even to the point of general acceptance.

That said, as much as we’re used to that level of web tracking, we would be shocked to learn of similar tracking happening over business telephone systems. After all, it’s highly unusual for office phones to be actively gathering data on us, in particular because for most businesses, voice calls are where highly confidential knowledge is exchanged.

So, what happens if it becomes clear your phone system has the capability of actively listening in on you?

Worse, what if you can’t even know for sure who’s on the other end of the line?

Security Concerns from Yealink

These questions are especially relevant for business owners now in the wake of a troubling report regarding phones by the Chinese-based vendor Yealink, especially their T54W devices, which raised concerns about the privacy and security of the company’s hardware.

On September 28 of last year, US Senator Chris Van Hollen (D-Md) filed a letter to the US Department of Commerce referring to a report conducted by the consulting firm Chain Security. In that referenced report, Chain Security noted numerous security flaws in Yealink devices, along with numerous functionalities that appear to intentionally gather customer data.

More worrying still, Chain Security’s report concluded it is “highly likely” that Yealink is sharing customer information directly with the Chinese government, especially through its hardware.

This data gathering appears to occur primarily through how Yealink phones interface with company networks and PCs. Namely, Yealink devices make use of a device management platform (DMP) to connect to programs running on the PC. In most circumstances, this would be perfectly normal for the vast majority of VoIP hardware that connects to a PC-based system.

What’s far less normal, and even outright alarming, is the fact that the Yealink DMP is then capable of recording voice calls and even tracking web history on that connected PC — both without the end-user’s knowledge.

Potential Tracking Components

According to the Chain Security report, the Yealink DMP “collects and retains the WAN IP” of the end-user’s device, and can log any web traffic from devices connected to it. This is in addition to how the DMP collects call records conducted either on the phone or any devices connected to it.

All this is worth noting in particular because the Yealink DMP can be operated by a remote Yealink employee, who can use the platform to access any collected data, be that IP addresses, web traffic or entire call recordings.

More concerning still, using the Yealink DMP, remote Yealink employees can at will enable recording on an active call and retain the recording afterwards

This access doesn’t appear to be used by Yealink on an occasional basis, either. Chain Security also notes that during “normal operations” Yealink phones communicate with Chinese-controlled AliCloud servers, suggesting potential control and interception of the exact kind described above.

Metaphorically speaking, none of this may be an actual fire, but the monitoring activity combined with the server contact certainly make for a lot of smoke. (Things get even more suspicious as we consider Yealink’s direct and long-established ties to the Chinese government and their continued data sharing with them, Chain Security likewise reports.)

Broader Security Concerns

Beyond these problems, Yealink devices in question appear to have just plain obvious security flaws — ones which may compromise an entire company server.

Chain Security points out that Yealink phones are “pre-configured to accept credentials for connection and access to the device from 187 ‘trusted’ digital certificate authorities.” In other words, entirely unknown to the end-user, Yealink devices may be accessed by an incredible amount of additional entities, meaning if any such users are compromised they’ll have easy access to Yealink end-users’ networks.

But hackers may not even need to be a “trusted” authority anyway. Unknown entry to the device is further blown open by its inability to protect against brute force login attempts, meaning hackers are fully capable of accessing it simply by guessing username/password combinations.

As if these factors weren’t bad enough, the Yealink devices lack industry-standard digital signatures to authenticate valid changes to firmware. As a result, if external actors gain access to the phones, they can instantly overwrite current software on them so long as the new firmware is compatible with the hardware.

This easily means a hacker can install firmware that surveys not just what’s recorded on the Yealink phone (using the aforementioned data collection it performs), but even activity across the entire company network.

The Bottom Line on Yealink Devices

What this leaves us with is a phone that can record calls, IP address and web activity — all at any time and without the end-user’s knowledge — and communicate that data elsewhere.

While it’s easy or even proactive to assume the data will end up at Yealink or even the Chinese government, it’s just as possible that entirely unknown agents can exploit the vulnerabilities in these phones for their own ends. Either way, the result is far less than desirable for any business.

By all accounts, even in an age where data collection is to be expected, the security architecture in Yealink phones allows for far more surveillance than any business should feel comfortable with.

Bigger Takeaways

While this should certainly serve as a warning for anyone interested in Yealink phones in particular, we can also draw larger security takeaways here.

It should be first noted that using this example to cast doubt on all Chinese-produced hardware would be ridiculous; after all, an enormous number of devices are produced in China and have nowhere near these issues.

The actual bigger questions are those over security and trust in general. As this example shows, communications hardware has incredible potential to intrude upon your privacy, even to the point of acting as a covert surveillance device right on your desk.

To keep yourself secure, it’s vital that you be able to trust the manufacturer of VoIP devices. The vendor needs to be able to demonstrate not just effective security measures, but a willingness to give up their own control of devices outside applying necessary software updates.

When considering a new vendor, then, there are plenty of important questions to ask: for example, how much is your vendor telling you about the security parameters in their hardware? What role does the vendor play in managing the device after it’s sold? What ties does your vendor have to other entities that might want your business’s information?

Above all, if a vendor is holding onto things like permanent DMP access, it should instantly raise a red flag. Capabilities for remote control in this manner are all but certainly going to be either poor security design at best, or active attempts at datamining at worst.

To keep your business fully secure, it’s crucial to weigh these factors such as much as any other security points. If you can’t trust your vendor to protect your own privacy, after all, what good are they as a technology partner? And if they’re clearly sharing data with a government involved in information warfare, the situation only becomes more problematic.

When you weigh your options for hardware, then, don’t just consider security in broad terms. Just as vital is to consider how much trust you can put in the vendor to keep you safe — or, more important still, whether the vendor itself is a potential security threat.

To see how Wildix designs security in our UCC systems, check out our free white paper.

For more updates on security in the UCC industry, subscribe to receive our magazine for free!

E911 Regulations: What MSPs Need to Know

Explaining the US emergency service laws your phone systems must follow

Adhering to regulations is crucial for any business, and telephony providers are no different. PBX installations in particular, on top of adhering to customer expectations, must also follow legal standards in order to steer clear of fines, litigation and other significant penalties.

In the US, some of the most important telephony regulations are those around Enhanced 911, or E911. These are crucial to know about because they don’t simply regulate how you sell PBXs or how they may be used — instead, they specify exactly how dialing emergency numbers must work for a multi-line telephone system (MLTS).

If you plan at any point on selling an MLTS in the United States, these are the main points of E911 regulations you need to know.

What Are E911 regulations?

Like the name implies, E911 regulations require that any time 911 is dialed, the call itself communicates additional information to emergency dispatchers.

In short, E911 laws require that every 911 call must also convey:

    • A callback number for emergency services (either for the device placing the call or a central agent on the site of the MLTS)
    • The location of the device that called 911

These requirements were put in place by two federal US laws: Kari’s Law and Ray Baum’s Act.

Let’s dive into both of them now for more detail on the technical requirements behind E911.

The E911 Laws

1. Kari’s Law

Adopted by the Federal Communications Committee in 2019, Kari’s Law establishes two main requirements for 911 calls.

The first requires that emergency services are immediately contacted when “911” is dialed on an MLTS device, without having to dial for an external call. In other words, the dialer must not have to take an additional step before sending the emergency alert: simply entering “911” on the device must be enough to contact emergency dispatchers.

The second part of this law is more complex. This section specifies that any time a 911 call is dialed through an MLTS, a notification is simultaneously sent to a “central operator” who is on the same premises as the MLTS.

This “operator” can be most anything: a front desk, a security office, the IT department or similar. The agent just has to be a person who’s on premises and will actually see the alert.

Likewise, there’s room for you to decide what the notification is. To meet legal requirements, the alert can be an email, a text message, a screen alert or any other electronic message. It simply has to be sent right as the PBX issues a 911 call, and it must be prominent enough that the operator on the premises is unlikely to miss it.

So, what exactly should this notification say? Here, requirements become stricter.

Per Kari’s Law, this notification must convey, at a minimum, the following information:

    • The fact that a 911 call has been made
    • A valid callback number for emergency services
    • Details on the caller’s location, which the MLTS also sends to the public safety answering point (PSAP) as part of the 911 call

It’s worth noting that points 2 and 3 can, in some instances, be waived. According to the law, if it is “technically infeasible” to add this information to the notification, it isn’t required to provide it.

However, if you can’t provide that info, you will have to prove that it’s “infeasible” for the system to provide it, which of course will be a complicated process. All in all, it’s best to simply include that information from the start to make things move most smoothly.

2. Ray Baum’s Act

While not entirely about 911 calls, Ray Baum’s Act features a portion that applies to E911 considerations.

According to Section 506 of this act, all 911 calls must include a “dispatchable location” embedded in the call (regardless of what device they originate from).

“Dispatchable location” here means a specific street address, plus any additional information required to pinpoint the exact calling location, like apartment number or suite number. In short, the call must also carry data specifying exactly where emergency dispatchers should go.

This ties into point 3 from the second part of Kari’s Law mentioned above, and the good news is by covering this requirement from Ray Baum’s Act, your phone system will fulfill that part of Kari’s Law as well. It’s simply worth mentioning because by not having it, you run the risk of violating two regulations.

It’s also important to note that all devices, both fixed and unfixed, must be in compliance with Ray Baum’s Act by January 6th, 2022. So if by early 2022, your unfixed devices can’t report a dispatchable location to 911 operators, you will be considered in violation of this law.

So in brief …

Here’s a quick overview of what your phone system needs to meet E911 regulations:

  1. If you’ve installed an MLTS, each phone on the PBX must reach emergency services immediately just by dialing “911” (not requiring the dialer first push a key to make an outbound call).
  2. Any time 911 is dialed, the MLTS must also send a prominent notification to a central operator on site, and the notification must include:
    • The fact that a 911 call has been made
    • A callback number that emergency services can reach
    • Information on the 911 caller’s location
  3. Any system must also tell emergency services the street address (and, if necessary, apartment or room number) from which the call was made.

What happens if you’re not compliant?

If you install an MLTS without meeting the three requirements above (or a phone system that doesn’t fulfill point number 3), your business will become liable under federal law. (It should go without saying this isn’t a preferred state to be in.)

Specifically, businesses that don’t adhere to these laws face fines of up to $10,000, with a further fine of $500 each additional day that you are not in compliance.

For US telephony providers, staying in business all but requires fulfilling these federal regulations.

How do you ensure compliance?

Obviously, there are two ways to stay in compliance with these laws: either have a system that’s compliant from the beginning or alter a noncompliant PBX to become compliant.

If you’re taking that latter option, the good news is that creating compliance with Kari’s Law is fairly straightforward. As any technician can tell you, removing external dialing requirements from 911 calls is not a hard exception to add to a dialplan. Likewise, it’s not much of a hassle to make an MLTS send the required notification any time 911 is dialed from it.

However, the bad news is that guaranteeing compliance with Ray Baum’s Act is nearly impossible without support from your vendor.

If your devices don’t already have capabilities for location reporting (or else don’t communicate this), adding in locations threatens to become a taxing process. Obviously, it will mean you’ll need to input the information yourself — but depending on your PBX’s setup and your vendor’s degree of involvement, this may turn into hours of manually adding the locations for each device into your system.

Consider also that this process is only for fixed devices. For unfixed devices, manually inputting locations will be outright unachievable — since, of course, users might move the devices from where you said they were.

Ideally, if your devices can’t provide location details upfront, your vendor will give you some easier way of adding in this info or even help with the process. If not, you’ll be stuck singlehandedly putting additional work into a system you no doubt already went through a lot of hassle to simply sell.

The easier alternative, of course, is to just use a system that’s compliant with these regulations to begin with and is supported by its vendor when it comes to inputting additional information.

What’s a good compliant system?

For a PBX that’s capable of acting as an MLTS and more — all while being fully in line with Kari’s Law, Ray Baum’s Act and other E911 regulations — an excellent choice is Wildix.

For starters, every Wildix system is ready-made to easily comply with Kari’s Law. By default, Wildix PBXs do not require a prefix to dial an external line.

So long as “Prefix for external line” is empty, your Wildix PBX will comply with the first part of Kari’s Law.

So long as “Prefix for external line” is empty, your Wildix PBX will comply with the first part of Kari’s Law.

The Wildix system can also be set up to send the required emergency notification to any call group the end-user requests, as outlined in Wildix technical documentation.

So, what about the more difficult part, conveying a dispatchable location? Here too, the Wildix system features full compliance with little difficulty on the MSP’s part.

With the use of CLASSOUND, Wildix’s premier voice system for cloud-based international calls, specific geographic locations can be bound directly to fixed phones, not simply to the devices’ DIDs. For unfixed devices, Wildix Collaboration, Wildix’s main calling app, automatically tracks location through a built-in geolocation feature.

How E911 reporting is conveyed through the Wildix system

How E911 reporting is conveyed through the Wildix system

As important as it is to be in compliance with federal law, getting there shouldn’t have to be a painstaking process. With Wildix, MSPs have full legal compliance as the factory default on their systems and the full backing of their vendor in achieving compliance on any installation.

For more tips on managing your PBX, subscribe to receive our magazine for free!

TLS 1.2 and You: Why You NEED to Upgrade Your Security

If you’re using devices that run TLS 1.0 or 1.1, it’s imperative you change them.

TLS 1.2 and You: Why You NEED to Upgrade Your Security

With hacking techniques constantly growing more effective, it’s crucial that your UCC security is constantly updated to keep up. This also applies when it comes to one of the most long standing systems protecting communication networks: TLS.

Short for “Transport Layer Security,” TLS is a security protocol that keeps communications unreadable to eavesdroppers — but only if it’s a version that’s up to date. This is crucial to note because, due to improved code-cracking from hackers, the oldest versions of TLS, 1.0 and 1.1, are now vulnerable to attacks.

Unfortunately, this means that any devices that still use TLS 1.0 or 1.1 jeopardize the security of your entire network. Because many devices using these versions cannot be upgraded, you should immediately replace any hardware using TLS 1.0 or 1.1 with models that use a more reliable version, TLS 1.2.

You can find Wildix devices that are end-of-life due to TLS issues here.

To explain why it’s so crucial to upgrade any hardware running TLS 1.0/1.1, let’s discuss the topic in more detail.

What is TLS?

TLS is a security procedure used between two parties — a client and a server — when exchanging information over the internet.

This procedure begins with the client and the server identifying themselves, then agreeing on both a private and shared code to use in a process known as a “handshake.” After this, the connection is secure because both the client and the server are communicating through advanced cryptographic techniques, meaning only they can understand it.

In short, TLS encodes online data in such a way that even if a hacker broke into your network to listen in, they can neither understand nor decode your information. 

What’s Different About TLS 1.2?

An inherent weakness in TLS is that the security it offers boils down to secure ciphers. By design, TLS is only secure so long as its codes cannot be cracked by an outsider.

Unfortunately, this is exactly the issue with TLS 1.0 and 1.1: the ciphers these protocols create can be decoded by an outside party.

The problem here comes down to the methods of encryption that TLS 1.0 and 1.1 use, in particular a means of encoding (called a “hashing algorithm”) known as SHA-1. By now, the codes that SHA-1 generates can be cracked with fairly rudimentary tools, meaning hackers can potentially listen in on conversations encrypted with TLS 1.0 or 1.1.

This kind of flaw in cryptography is what TLS 1.2 was designed to fix. Rather than use SHA-1, TLS 1.2 uses the updated hashing algorithm SHA-256, which is still complex enough and secure enough to remain uncracked. 

As far as security goes, the difference is black and white: TLS 1.2 uses encryption that can’t be broken, while TLS 1.0 and 1.1 will always be at risk of exposure. As a result, Google Chrome and other major browsers suspended their support for TLS 1.0/1.1 in early 2020, meaning accessing them through outdated TLS devices may cause compatibility issues.

What Could Happen If I Don’t Switch?

There are two worst-case scenarios of leaving TLS 1.0/1.1 UCC devices on your network.

First, hackers or other intruders will have an easier time intruding on any communications you send over the internet. Practically speaking, this means attackers can intercept and decrypt phone calls, videoconferences or text messages, or pose as a genuine user on your network and receive communications from you directly.

Obviously, either scenario can easily result in confidential information — including corporate intel, passwords or even financial details — being leaked. Furthermore, if either happens, you won’t even know your messages are being intercepted, as if TLS is decrypted it can’t safeguard your system any further.

Second, using TLS 1.0/1.1, entities from outside your organization can register themselves on your UCC devices by obtaining a device’s credentials. The fallout of this security breach can be immediate. Once on your network, hackers can use your devices to place phone calls, which in a worst-case scenario can rack up thousands of dollars in international dialing expenses after only a few days.

Again, it cannot be overemphasized that both these outcomes are entirely possible so long as TLS 1.0/1.1 devices remain on your network. The only way to safeguard yourself from financial loss and identity exposure in this manner is to make the switch to TLS 1.2.

For added security on your network, consider making use of Wildix, the only platform on the market that’s 100% secure by design for safe communications without external SBCs or VPNs. Read the full details on how Wildix achieves that security in our security white paper.

To get more tips over digital security, subscribe to receive our magazine for free!

An Intro to React and React Native

React Logo

Outlining the Tech Behind WMS 5

One of the big names in tech nowadays is React, as well as its mobile offshoot, React Native. In fact, both these technologies were unveiled as part of the recent Wildix upgrade, WMS 5.

Although it’s been promised that React will improve Wildix software, many may be wondering how exactly that will happen.

To answer that and other questions, let’s discuss what exactly React and its uses are.

Continue reading “An Intro to React and React Native”

What Does It Take to Activate Smart Working in a Company, from a Technical Standpoint?

Smartworking Wildix
Activating smart working in a company in just one working day — is it technically possible, or it is just another marketing trick?

In the recent weeks and months, due to the COVID-19 outbreak, many companies around the world have been struggling to provide their employees with tools that can enable them to work from home while maintaining the same level of productivity and availability.

This is especially true for those companies who never had the practice of remote working in place before the outbreak. Just a few months ago, smart working was simply “nice to have”, and was used only by a small percentage of companies. Today, it is no longer optional; it has become a must-have capability for every business as a means of survival.

In this blog post we will analyze, from a technical perspective, whether it is possible to quickly and seamlessly activate smart working in a small to medium scale company and how much time it will take.

Continue reading “What Does It Take to Activate Smart Working in a Company, from a Technical Standpoint?”