The next wave of wireless security worries: API-driven IoT devices
LAS VEGAS – Wireless carriers may be the next cast of characters to learn the hard way about the security risks created by IoT devices. This warning came in a recent briefing at the Black Hat information-security conference here by Altaf Shaik, a senior security researcher at Technische Universität Berlin.
"There is increased threat when it comes to 5G, and the impact is also quite bigger because here the hacker gets to target the industry and not just a single user," Shaik said at the start of this 40-minute presentation.
The core issue here is 5G's utility in connecting not just people (who stand to get notable privacy upgrades with 5G, as Shaik explored in a presentation at last year's Black Hat conference) but machines. Carriers are now moving to turn that latter feature into new lines of business by offering IoT services to businesses that these customers can manage directly through new APIs.
"For the first time, 4G and 5G networks are trying to bring this network exposure," Shaik said. "The proprietary interfaces are now changing and slowly moving to generalized or commoditized technologies like APIs."
"So now any external entity can actually control their smart devices by using the service APIs and going through the 4G or 5G core network," Shaik said, citing a Vodafone test of drones in Germany. "This exposure layer provides APIs and shares information for the drone control center."
Carriers sell these IoT services to businesses (as verified with a tax ID) willing to buy IoT SIMs in bulk purchases of a thousand or more. These business customers, in turn, can manage these SIMs through an IoT connectivity management web interface, with an IoT service platform web interface providing account-wide controls.
"You can do plenty of stuff, provided you have access to these APIs," summed up Shaik.
Open to compromise
However, poorly configured or administered APIs can open the IoT devices of other customers and even perhaps a carrier's core network to compromise. For example, an attacker could start by exploiting vulnerabilities "to gain data of arbitrary users hosted on the same platform," then attempt to compromise a carrier's application server – and then possibly "penetrate from there into the mobile core network, because they are connected," Shaik continued.
He and fellow researchers Shinjo Park, also with Technische Universität Berlin, and Matteo Strada, with NetStudio Spa, tested this by purchasing IoT SIM cards from nine services and then testing them for possible weaknesses.
(Shaik did not name them, but a slide characterized three of them as network operators and listed six as MVNOs. He said later in the talk that most were in Europe, two "maybe" in the US and one in Asia.)
His top-level conclusion: "There is still a lot of things missing."
The researchers had no trouble getting business IoT accounts, which Shaik said reflected poor know-your-customer compliance: "There was very relaxed customer verification with many providers, and when we tried to argue this with the providers, we really didn't have a good response."
They also found basic account security lacking, with "a lot of dictionary passwords being accepted" – both at account creation and when updating them afterwards.
The researchers then found that four of these nine companies used static tokens for service-platform authorization that were valid for anywhere from 24 hours to a week, a violation of GSMA guidelines that call for OAuth logins. Three of the nine did not fully encrypt web portal access with HSTS (HTTP Strict Transport Security), a key defense against man-in-the-middle attacks.
A dynamic analysis of IoT APIs found further inattention to security, starting with cases of carriers exposing even "sensitive functions" to demo users. Shaik said when asked, these services said this was a customer-acquisition strategy: "They would really like to market their platform and attract as many customers as possible."
Seven of these nine services had not even tried to enforce rate limits on API access, he continued: "We couldn't really find rate limiting issues, and only two of them actually had rate limits in place."
Failure to obscure customer identities by assigning random identifiers to devices increased the risk of an attacker being able to target a particular company.
Vectors for intursion
Shaik outlined a few possible attacks. For example, an adversary could send malware via SMS to IoT devices (he noted that some carriers told his team that national laws prohibited scanning SMS traffic for malware) or employ broadcast downlink messages to conduct a denial-of-service attack (such as ordering IoT devices to increase their data consumption or stay awake until they run out of battery).
The researchers further found that webhooks provided for customer access were often not secured with standard HTTPS encryption, allowing a variety of customer data to leak.
Finally, they observed that most of these carriers had not secured their IoT APIs to refuse malicious input strings, which an attacker could exploit to run arbitrary code on their platform. Said Shaik: "At least six of them don't really have protection against code injection."
Just two of these services passed the researchers' tests: "Only two of them are not affected with the vulnerabilities, the design risks we saw," Shaik said, adding that none were aware of these problems before his team disclosed them privately to these firms.
Shaik urged IoT-minded providers to follow existing GSMA security guidance and then adopt such proven security practices as reducing attack surfaces by only providing APIs needed for specified use cases, randomizing user identifiers, rate-limiting access, enforcing strict input validation, and monitoring and logging network traffic.
"It's important to have additional security practices that are commonly recommended in the industry," he said. "I know it's difficult, but it's the only approach."
— Rob Pegoraro, special to Light Reading. Follow him @robpegoraro.