API Insecurity: Lessons from the Cox Modem Breech

More and more gadgets we bring into our homes are of the "smart" variety. Once connected to our Wi-Fi, they chat away via APIs of all types. But how secure are these APIs, and what dangers lurk if they are compromised?

Sam Curry is a cybersecurity professional and Staff Security Engineer at Yuga Labs. Recently, he shared his detailed discovery of an API vulnerability that potentially put millions of COX internet modems at risk. 

Curry responsibly disclosed the vulnerability, and Cox subsequently closed the loophole before publication. If you are a Cox customer, you should not be able to replay the steps to pwn your box (or the modem of others). However, the saga does raise failure conditions that may continue to lurk in your API. In this newsletter, I'll tease out some broad generalities from Curry's steps, highlighting four API security lessons we can all apply. 

That and more in this, the 240th edition of Net API Notes. 

Problem #1: Broken Authentication Enabling Authorization Bypass

In 2023, Broken Authentication was listed as one of the top OWASP API Security Risks. Reading the events as they transpired, Curry discovered that he could bypass authorization mechanisms by replaying HTTP requests multiple times. Which, I mean, come on. It is arguable that had authentication worked as intended, on every request, we wouldn't have an article to reference, and the rest of the problems that follow wouldn't have been discoverable.

The client ID taken from the consumer portal SPA, references to a "Cb_session" header variable, and an Authorization bearer token all suggest a mix of security precautions in addition to the APIkey was applied somewhere. 

GET /api/cbma/profile/services/profile/profilesearch/ HTTP/1.1
Host: myaccount-business.cox.com
Clientid: cbmauser
Apikey: 5d228662-aaa1-4a18-be1c-fb84db78cf13
Cb_session: unauthenticateduser
Authorization: Bearer undefined

How often are you performing basic audits on your authentication? Do those include replay attacks?

I am still trying to figure out why replaying the same HTTP requests resulted in different authentication behavior. Very odd. However, once that happened, the next problem poured fuel on the fire.

Problem #2: Information Leakage

So you can call an API without authenticating - now what? 

Curry's goal was to see if he could use the API functionality to overwrite the settings on his own hardware device. To do that, he needed to know what endpoints were at his disposal. Thankfully, Cox's API provided the answers Curry sought. 

Curry was able to deduce that he was interacting with a Spring Boot API based on the returned error structure. Using this knowledge, he began making GET requests to default locations where Swagger Docs often reside. 

❌ GET /api/cbma/userauthorization/services/profile/validate/v1/swagger-ui/index.html
❌ GET /api/cbma/userauthorization/services/profile/validate/swagger-ui/index.html
❌ GET /api/cbma/userauthorization/services/profile/swagger-ui/index.html
❌ GET /api/cbma/userauthorization/services/swagger-ui/index.html
✅ GET /api/cbma/userauthorization/swagger-ui/index.html

At this point, serving static assets through the reverse API proxy presented a challenge. However, after a brief detour, Curry had full interactive documentation detailing the operation of more than 700 different endpoints. 

As security researcher Alissa Knight said in a 2019 APIDays presentation, there's a difference between making a mistake and making things easy. If you run an external, publicly facing service like Twilio, then comprehensive API documentation available to all is a must. But, in this case, it seems as though developer niceties for local or lower-level environments ended up in production. 

A server should not return API documentation to an unauthorized request for an internal API tool - it exposes details that could aid an attacker in identifying and exploiting other vulnerabilities. Proper access controls and obscuring documentation endpoints are essential measures to prevent this.

Do you regularly test whether API documentation for administrative systems is available via the world-wide web? Preferably in an automated fashion?

In Curry's case, reading the documentation to identify the calls necessary to achieve his goals saved untold amounts of time and effort. And having the documentation in hand exposed the next problem. 

Problem #3: Unrestricted Resource Consumption

With the Swagger Docs in hand, Curry could write an "intruder script". The intention with this automation was to hit every single GET endpoint and determine if there were any additional unauthenticated API endpoints - additional vulnerabilities that could be exploited and used for additional privilege escalation. 

While Curry doesn't mention it, this type of scripting may also be accompanied by "fuzzing", or providing invalid, unexpected, or random data to learn additional information about how the system behaves (and breaks) when stressed. 

It may be evident in hindsight, but calling every endpoint in order from a single client - in what I'd assume is a rapid fire manner in a limited amount of time - is not an everyday use case. While it may not be a default behavior out of the box, I'd expect an API Gateway protecting sensitive administrative functionality to exhibit some intrusion detection monitoring - something operating at a higher level than your average rate-limiting and throttling. 

I know several "AI" branded products promise this kind of functionality, but I have not had any first-hand experience with any of them. If you do, I'd love to hear more about your experiences. 

Can you detect anomalous behavior in an API? Who gets notified? And what actions are available to them when an event does occur?

Problem #4: Cryptographic Secret Exposure

That brings us to our final problem. 

Updating a device remotely is kinda a big deal. To their credit, Cox did appear to impose an additional security measure. For requests that might modify hardware settings, like updating a device password, the API required an additional parameter called "encryptedValue". The documentation implied that the hardware device's MAC address was somehow involved. However, it was not immediately obvious to Curry how to generate one of these strings for his own purpose. 

Looking carefully at Cox's business portal, a single-page application, eventually provided the answer. The JS that loaded with the webpage contained two functions, "encryptWithSaltandPadding" and "decryptWithSaltandPadding". Within the site, Curry identified that these functions were being used when setting a four-digit pin. By setting a breakpoint at this spot within the code, he was able to confirm that the functions were working as expected. 

By using the decrypt function, he was able to determine that the string was made up of several fields concatenated together; while it contained a MAC address, it also appeared to have a Cox account number. If validation was in place that checked whether the MAC address being changed belonged to a given account, then exploiting others' devices would be difficult. 

However, it didn't appear that such validation existed. Curry filled an "encryptedValue" string with entirely junk data -except for the MAC address- and it worked. With this information, Curry was now able to:

1. Query a customer name
2. Fetch their account UUID
3. Fetch a list of all their connected devices' MAC addresses associated with their UUID
4. Update the settings on those devices

Yikes!

Consider a situation where a malicious actor knew the means to encrypt sensitive information; what actions would they be able to perform? How might you detect encrypted values being rolled "outside the building"? 

Hardware updates should be limited to authorized account users. When a customer service representative performs actions on behalf of someone else, there should be some API session, key, or unique token requirement for the endpoint.

Conclusion

As I mentioned, after discovering this exploit, Curry reported the vulnerability via their responsible disclosure program. Cox hot-patched soon after and a day later, Curry emailed Cox letting them know he could no longer reproduce the vulnerability. A day after that, Cox emailed Curry to let him know they were beginning a comprehensive security review. 

The purpose of this post isn't to point fingers at any person or team. The team (or teams) responsible for the API are all hard-working folks doing the best they can with the available time and resources. If I had to guess, the flaws found do not have a single, obvious root cause but emerge from the complex system of competing incentives, threat models, and skill sets. While Cox ended up being the subject of the write-up, I'm willing to bet there are a lot more shops that have similar issues that are waiting to be discovered. 

Milestones

• Are you looking for some foundational API training? James Higginbotham has launched his new online education series, https://apicoach.io/. Sign up, watch at your leisure, and get certified.
• Two high school teens raised $500k to create APIs with GenAI, which, I mean, good for them, I guess? I'll withhold my rant that programming an API is neither the difficult nor time-consuming part, so automating that is of limited use. However, these announcements are starting to feel very '99 bubblicious - an event I lived through that occurred (*does the math*) before these founders were born. <sigh>. Now excuse me while I yell at some kids about my lawn. 

Wrapping Up

Thank you for reading! If you like what you see there are a variety of ways of supporting this newsletter. The first way is forwarding an issue of Net API Notes to someone you think might find it valuable. If you aren't already signed-up for email updates, a quick 30 seconds and an email address letter shows me what you're interested in hearing more about. Finally, if you're in a good position, you can upgrade your signup to a paid subscription for as little as $8 a month (or $80 a year). Paid subscribers also ensure that Net API Notes remain ad- and information-selling-free. Check out the complete list of benefits available to paid subscribers, and consider subscribing today. 

That's all for the moment. Till next time,

Matthew [@matthew (Fediverse) and matthewreinbold.com (Website)]