An API authorization-bypass flaw in the infrastructure of a leading US broadband provider exposed millions of business customer devices to attacks, giving threat actors access to permissions on the devices as if they were a member of an Internet service provider (ISP) support team.
Cox Communications fixed the flaw, identified by independent bug researcher Sam Curry, who released a blog post about the issue on June 3. If exploited, attackers not only could have gained access to business customers’ personally identifiable information (PII), but also Wi-Fi passwords and info on connected devices. They also could have executed arbitrary demands on the devices, updated them, or taken over customer accounts, he wrote.
Curry found the root of the vulnerability in 700 exposed APIs on Cox’s back-end infrastructure, “with many giving administrative functionality,” such as the ability to query the connected devices of a modem, he explained in the post.
“Each API suffered from the same permission issues, where replaying HTTP requests repeatedly would allow an attacker to run unauthorized commands,” Curry wrote. This issue ultimately resulted from an error in the Spring code used to proxy API requests to a dedicated Cox backend while serving front-end files in a different way. Spring is a widely used Java framework for simplifying the development of Web apps and services.
This series of vulnerabilities gave an external attacker with no prerequisites permission to execute commands, modify the settings of millions of modems, access any business customer’s PII, and gain “essentially the same permissions of an ISP support team,” he wrote.
Discovering the Cox Modem Attack Scenario
Cox is the largest private broadband provider and the third-largest cable TV provider in the US, with millions of customers, including Curry.
The researcher first noticed something was amiss several years ago while working on his home network to exploit a blind XML external entity injection (XXE) vulnerability that required an external HTTP server to exfiltrate files. In the course of his research, he ran a simple Python webserver to receive the traffic from the vulnerable server, then sent a cURL request from his home computer to make sure that it could receive external HTTP requests.
He found that he was able to receive network traffic on the box and then encountered “something very unexpected” when, 10 seconds later, an unknown IP address that Curry later discovered was linked to several domains used in phishing campaigns, 159.65.76.209, replayed the exact same HTTP request.
“Somewhere, between my home network and the AWS box, someone had intercepted and replayed my HTTP traffic,” he wrote. “This traffic should not be accessible. There is no intermediary between these two systems who should be seeing this.”
Curry immediately thought he had been hacked and went to Cox to switch out his modem to a new one, which worked without incident. Several years later, through collaboration with fellow security-researcher friends and an opportunity to help someone set up a new Cox modem, he went deeper with an investigation into his own personal incident. Along the way, he “accidentally” realized that there was an “authorization bypass on the Cox back-end API.”
Exploiting the Cable Box Bug
The flaw discovered by Curry allows an attacker to bypass authorization on vulnerable API endpoints by simply replaying an HTTP request multiple times, with “over 700 other API requests that we could hit,” he wrote.
To exploit the issue, an attacker could search for a Cox business target through any one of the hundreds of exposed APIs using their name, phone number, email address, or account number. The attacker then could retrieve the customer’s full account PII via querying the returned universally unique identifier (UUID) from the initial search, including device MAC addresses, email, phone number, and business address.
Next, an attacker could query the customer’s hardware MAC address to retrieve Wi-Fi passwords and info on other connected devices. Finally, this would allow the attacker to execute arbitrary commands, update any device property, and takeover victim accounts, Curry said.
Cox: A Prompt Response & Mitigation
Curry reported the vulnerability to Cox through its responsible disclosure program on March 4, and it was patched a day later. The broadband provider also informed him that there is no history of it being abused by attackers.
However, the story might have another chapter to come because, if true, this means that the original issue Curry experienced on his modem and which set him off on his investigation (as well as the involvement of the phishing-related IP address) had nothing to do with the vulnerability he eventually discovered, thus remaining a mystery, he noted.
“I’m still super-curious on the exact way in which my device was compromised, as I had never made my modem externally accessible nor even logged in to the device from my home network,” Curry wrote, adding that his research “aims to highlight vulnerabilities in the layer of trust between the ISP and customer devices.”
This post was originally published on the 3rd party site mentioned in the title of this this site