The RCS Texting Protocol Is Way Too Easy to Hack

Ask practically any phone carrier, and they’ll tell you that the future of smartphone features from texting to video calls is a protocol called Rich Communication Services. Think of RCS as the successor to SMS, an answer to iMessage that can also handle phone and video calls. Last month, Google announced it would begin rolling RCS out to its Messages app in all US Android phones. It’s easy to imagine a near-future where RCS is the default for a billion people or more. But when security researchers looked under the hood, they found the way carriers and Google have implemented the protocol creates a basket of worrisome vulnerabilities.

At the Black Hat security conference in London on Tuesday, German security consultancy SRLabs demonstrated a collection of problems in how RCS is implemented by both phone carriers and Google in modern Android phones. Those implementation flaws, the researchers say, could allow texts and calls to be intercepted, spoofed, or altered at will, in some cases by a hacker merely sitting on the same Wi-Fi network and using relatively simple tricks. SRLabs previously described those flaws at the DeepSec security conference in Vienna last week, and at Black Hat also showed how those RCS hijacking attacks would work in videos like the one below:

SRLabs founder Karsten Nohl, a researcher with a track record of exposing security flaws in telephony systems, argues that RCS is in many ways no better than SS7, the decades-old phone system carriers still used for calling and texting, which has long been known to be vulnerable to interception and spoofing attacks. While using end-to-end encrypted internet-based tools like iMessage and WhatsApp obviates many of those of SS7 issues, Nohl says that flawed implementations of RCS make it not much safer than the SMS system it hopes to replace.

“You’re going to be more vulnerable to hackers because your network decided to activate RCS,” says Nohl. “RCS gives us the capability to read your text messages and listen to your calls. That’s a capability that we had with SS7, but SS7 is a protocol from the ’80s. Now some of these issues are being reintroduced in a modern protocol, and with support from Google.”

The RCS rollout still has a ways to go, and will continue to be a patchwork even with Google’s backing. Some Android manufacturers use proprietary messaging apps as the default rather than the stock Messages app, and most carriers push their own versions as well. The iPhone doesn’t support it at all, and Apple has given no indication that it will. But as RCS rolls out more broadly, its security issues merit attention—especially since it’s those implementations that create the problems in the first place.

The SRLabs videos demonstrate a grab bag of different techniques to exploit RCS problems, all of which are caused by either Google’s or one of the phone carriers’ flawed implementations. The video above, for instance, shows that once a phone has authenticated itself to a carrier’s RCS server with its unique credentials, the server uses the phone’s IP address and phone number as a kind of identifier going forward. That means an attacker who knows the victim’s phone number and who is on the same Wi-Fi network—anyone from a coworker in the same corporate office to someone at the neighboring table at Starbucks—can potentially use that number and IP address to impersonate them.

Using a different technique, the researchers showed how an Android phone using RCS can be vulnerable to a man-in-the-middle attack. Whether it’s a hacker controlling a malicious Wi-Fi network or an ISP or nation-state spies with access to an ISP’s servers, an attacker can alter the domain name system request that the phone uses to find the RCS server that acts as the relay between senders and recipients of a message. SRLabs found that while Android’s RCS-enabled messaging app checks to see if the server the phone is connecting to has a valid TLS certificate—in the same way your browser checks the validity of an HTTPS website—it will accept any valid certificate, even for the attacker’s server.

It’s like a security guard who only checks if someone’s ID matches their face, rather than if their name is on the approved list in the first place. “It’s a really stupid mistake,” adds Nohl.

The result is that the man-in-the-middle can intercept and alter messages at will, as shown in this video:

Another attack takes advantage of a flaw in the initial setup for RCS devices. When a phone is first registered in the RCS system, it downloads a configuration file that contains the device’s credentials. But to identify itself to the server and download that configuration file, a device only needs to have the IP address the carrier believes is meant to be associated with that device’s phone number. Nohl points out, however, that any malicious app that ends up on a phone—even without special app permissions in Android—can reach out from the same IP address, steal the device’s unique RCS credentials, and start impersonating it, as shown in the video below. That configuration file attack can be used even against someone who has never enabled RCS on their phone, Nohl points out.

In some cases, carriers try to guard against that attack by sending a one-time code to the user’s device that they have to enter. But SRLabs found that some carriers failed to limit the number of tries at guessing that code; a hacker can try every possible number in just five minutes. “In five minutes we have your configuration file, and forever after we can listen to all your phone calls and read all your texts,” Nohl says.

All of these attacks become even more serious when RCS messaging is used as a second factor in two-factor authentication. In that case, RCS interception could allow hackers to steal one-time codes and gain access to other, even more sensitive accounts like email, as shown in this video:

When WIRED reached out to the GSM Association phone carrier industry group and Google, the company responded with a statement thanking the researchers but arguing that “many of these issues have already been addressed”—it declined to say which ones—”and as part of our close collaboration with the ecosystem, we’re actively advising partners as they resolve the remaining issues.” The GSMA claimed that it already knew of the issues SRLabs highlighted, and that “countermeasures and mitigation actions are available” for carriers to fix their RCS flaws. Nohl countered that those fixes haven’t been implemented yet for any of the issues SRLabs presented on at Black Hat.

The GSMA further argued that SRLabs had pointed out problems with the implementation of the RCS standard, rather than the standard itself. “The findings highlight issues with some RCS implementations but not every deployment, or the RCS specifications themselves, are impacted,” the GSMA statement reads.

Nohl argues, however, that the existence of so many flaws in the standard’s implementations is in fact a problem with the standard. “If you put out a new technology for a billion people, you should define the whole security concept. Instead RCS leaves a lot undefined, and telcos make a lot of individual mistakes when trying to implement this standard,” Nohl says. “This is a technology being introduced quietly to over a billion people already. And it exposes them to threats they didn’t have to worry about previously.”

More Great WIRED Stories

Read More