This week, we share reports on the API exploits of two enterprising students and their takedown of “big laundry”. We take a revealing look at API vulnerabilities exposing millions of modems to remote takeover. We also have two insightful articles on API security in the supply chain and automotive industries, and ask the question what next for GraphQL.
Before we dive in, I’d like to introduce myself, Anthony Lonergan Developer Relations Lead with 42Crunch and the new Editor of your APIsecurity newsletter. I’d like to thank my colleague Colin Domoney for his great work over the past few years curating and editing the newsletter and wish him every success with his new book, Defending APIs. I will strive to maintain the editorial quality and adhere to the principles you’ve come to expect from one of the API security industry’s leading sources of relevant news.
Breach: UC Santa Cruz students use vulnerable APIs to penetrate the largest laundry network in the US
First, this Techcrunch article about two UC Santa Cruz students who discovered API vulnerabilities that allowed them to remotely control washing machines for free, and add millions of dollars in credit to their laundry accounts (non redeemable, unfortunately for the students).
The APIs in question lacked proper authorization controls. The important checks that should have been performed at the API, such as checking if the user has enough credit before starting a laundry service, were instead assumed to be performed by the client-side app.
This is an all-too-common mistake when teams move from MVC to SPA. You cannot continue to rely on the client to put in place the necessary security checks, since a hacker can simply go directly to the APIs and by-pass the client.
When it comes to designing, implementing and testing APIs, careful consideration should be given to the function or service provided via the API, and whether or not authorization controls need to be applied. This calls to mind the OWASP Top 10 API Security vulnerability: Unrestricted Access to Sensitive Business Flows.
OWASP recommends a two-tiered approach to mitigating your risks from this API vulnerability:
- Identify the business flows to protect
- Select the appropriate protection mechanism
I would also include adding authentication and authorization tests to your API test suites, to verify that those controls are implemented correctly and consistently.
Notably, the students in this case made numerous attempts to ethically report the vulnerabilities to the vendor. For more technical details, I also recommend this blog post which explains the step by step process for uncovering and verifying the API vulnerabilities.
Breach: API vulnerabilities exposed millions of Cox modems to remote hacking
Securityweek recently reported a case of API vulnerabilities discovered in Wi-Fi modems of American telecommunications giant Cox Communications. The vulnerabilities, ethically reported by researcher Sam Curry, allow an unauthenticated user to send commands to the Wi-Fi modems of millions of residential and business customers, to extract PII data and change modem settings.
One of the key revelations that opened the door to the whole system was that the API response went from unauthorized to authorized, simply by making the exact same API request over and over again. This appears to be an unusual case of broken authorization.
“Insanity is doing the same thing over and over again and expecting different results”… except for hacking APIs apparently.
Although the underlying cause of the vulnerability is unclear, the example presented in this article once again raises the importance of testing APIs for authorization vulnerabilities such as BOLA and BFLA. They occupy the top spots in the OWASP Top 10 lists due to their prevalence and potential impact.
Curry was also able to identify information about the API server infrastructure based on the structure and format of the APIs error response. This type of security misconfiguration vulnerability can unintentionally help hackers (ethical or otherwise) strategically probe an API for other vulnerabilities.
If you’re interested in a technical deep dive I highly recommend this blog post from Sam Curry.
Article: Why, after 6 years, I’m over GraphQL
The pros and cons of GraphQL will no doubt continue to be discussed and debated over water coolers and in Slack channels for some time to come. We’ve certainly covered the topic from a security perspective several times in this newsletter.
However, this recent article by Matt Bessey, a self-described former GraphQL champion, has certainly generated some more discussion and debate.
The takeaway is that for projects where greater emphasis is placed on non-functional factors, such as security, performance, and maintainability, the perceived merits of GraphQL are quickly outweighed by the difficulties.
You can read more in the followup online discussions here.
Article: The vital role of APIs in modern supply chain logistics
Modern supply chains demonstrate both the opportunities and risks associated with integrating complex systems via APIs.
APIs facilitate essential automation of data flows and coordination of processes across disparate technology platforms that modern supply chains depend on. However, this Forbes article highlights some of the security risks that should be considered before adding third-party APIs to a supply chain.
In the event of excessive data exposure, it is the responsibility of the API producer to ensure that only necessary and permitted data is returned in any API response. If too much data is returned by the API, and especially when that data is sensitive in nature, it can cause security incidents and undermine trust in the supply chain system.
The other vulnerability discussed in the Forbes article concerns unsafe consumption of APIs. Here, the onus is on the API consumer to securely integrate any external API into the supply chain and not automatically trust third party data, even if it comes from a trusted partner or a reputable organization.
OWASP recommends the following steps to help create secure API integrations:
- When evaluating service providers, assess their API security posture.
- Ensure all API interactions happen over a secure communication channel (TLS).
- Always validate and properly sanitize data received from integrated APIs before using it.
- Maintain an allowlist of well-known locations integrated APIs may redirect yours to: do not blindly follow redirects.
Article: API security for the connected vehicle
Best practices in software development are a key requirement in producing reliable software in the automotive industry, codified in industry standards such as Automotive Spice and ISO-26262.
Many of these same rigorous practices also apply to API development. Security requirements must be carefully captured, implemented, tested, and verified to ensure that running APIs are secure by design.
As the requirements of modern vehicles evolve towards more complex functionality, as well as more sophisticated connectivity to external clouds, applications and backend systems, APIs are increasingly leveraged to power these connections.
And it is in this digital evolution towards increasing adoption of APIs that the automotive industry has recognized and responded to the growing cybersecurity risk on automotive software.
This month, Trend Micro subsidiary VicOne announced a new partnership with 42Crunch to address growing API cybersecurity challenges for the automotive industry, together offering a comprehensive solution to help automakers comply with new regulations and standards for API protection.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
