Three Major API Vulnerabilities Disclosed by Hackers in 2023

Security incidents are common (unfortunately). But before they become security incidents, they lead a different life. They’re bugs, flaws, and vulnerabilities. Just existing, undiscovered, undetected, probably lonely, sitting in the corner.

Vulnerabilities are never a good thing. But it’s much better when a white hat hacker finds them first before a black hat hacker abuses them. When white hat hackers find a vulnerability in someone’s system, they tell them about it.

White hat hackers can take different forms. Often, they’re security researchers. In this article, you’ll learn about three important cases of API-related vulnerabilities discovered by security researchers and disclosed in 2023. You’ll learn what happened, how to spot traces of vulnerabilities in your system, and how to prevent or remediate them.

Honda

Eaton Zveare is a security researcher who publishes his findings on the website Eaton Works. In June, he disclosed two security bugs he discovered in:

• Honda’s e-commerce platform called Honda Dealer Sites
• Honda’s website, Power Equipment Tech Express (PETE)

Honda Dealer Sites lived on www.hondadealersites.com, but the domain was deactivated due to the discovered vulnerabilities.

Before the reported bugs, Honda Dealer Sites functioned as any other no-code online store builder. It allowed users—in this case, Honda product dealers—to build a website that sold power equipment, such as generators and pumps, and handled orders.

Every dealer who built a Honda website through the online store builder had access to an admin dashboard. A valid user needed a username and password to log in to the admin dashboard.

Since Zveare didn’t have valid credentials nor a way to reset a password for an already existing account without access to a registered email, he took another route.

The security researcher analyzed other Honda websites and discovered that a Power Equipment Tech Express (PETE) account could also work to log in to the dealer admin dashboard. That was possible because the Power Equipment Tech Express and the admin login web app belonged to the same Honda e-commerce network.

The PETE website was vital to the white hacker’s successful hack into Honda’s e-commerce network. Unlike the admin login functionality, the PETE website included an API (possibly an older API) that allowed him to make a password reset call.

This password reset API was instrumental to Zveare gaining unauthorized access to volumes of dealer and dealer’s customer information, more precisely:

• 1,090 dealer emails
• 1,570 dealer websites
• 3,588 dealer accounts
• 11,034 customer emails
• 21,393 customer orders

This vulnerability would’ve allowed Zveare to access any dealer account because the password reset process required only a registered email address or username, not a token from a password reset email or an old password. So, the only thing Zveare needed was a registered email/username, which he found in a YouTube video teaching dealers how to use the e-commerce platform.

Unfortunately for Zveare, the registered email was for a test account, which didn’t give access to valuable information. It goes without saying that he could try to find other registered emails and usernames. However, accessing user dashboards through password reset could disrupt the everyday work of the affected dealers, and white hackers such as Zveare don’t want that to happen.

Upon further analysis, the security researcher discovered that the user ID shown in the URL was incremental. He tried to add +1 to the existing identifier—2 if the previous ID was 1—and discovered that API calls with incremented IDs gave him admin access to other dealer dashboards. That was another bug in the system that didn’t even require you to reset passwords to access Honda dealer accounts.

The problem soon went from bad to worse when the researcher found out that he could also access the Honda admin dashboard for all the dealer e-commerce accounts.

By analyzing the JavaScript (JS) code of the dealer admin dashboard, changing the “isadmin” field of the login response to “true,” and sending a new request, Zveare accessed the Honda admin dashboard. There, he could see an overview of the entire e-commerce network, meaning the exact number of dealers, their subscription plans, and Honda’s revenue from the dealer subscriptions.

In addition, the Honda admin dashboard allowed the researcher to see customer emails, financial reports and analytics, and dealer emails. There was also a user management section that let him assign different user roles and permissions.

The researcher discovered that he might have also been able to see API keys in API responses and try to abuse them. However, he didn’t attempt to explore this issue further since this realization came after he had already reported the other bugs to Honda.

Zveare reported his findings in March. Honda replied as early as April, remediating the bugs promptly.

The Honda API bugs are clear examples of authentication and authorization flaws. Had they been discovered by malicious actors, they could’ve led to:

• Sensitive data exposure being used in targeted phishing campaigns
• Black hat hackers planting malicious JavaScript skimmers on dealer websites to steal payment information

To prevent security risks like these, you must:

• Implement a robust password reset mechanism
• Enforce strong authentication and authorization measures
• Restrict what users see in your application code (for example, do not include comments, especially verbose comments)

QuickBlox

In July, Team82 and Check Point Research published a joint report on critical security flaws in QuickBlox. QuickBlox is the company behind the popular backend communication platform of the same name.

The security researchers discovered fatal flaws in the QuickBlox API and helped the company remediate the bugs upon disclosure.

Software developers can use QuickBlox as a backend for building applications with chat, voice, and video features.

The researchers found that when a developer created a new application, QuickBlox generated four application secret keys: application ID, authorization key, authorization secret, and account key. These credentials were necessary for the application to receive an access token that enabled it to make QuickBlox API calls.

However, since QuickBlox implied an authentication flow such that an application session was requisite for creating a user session, these four credentials were also required for user authentication (in addition to distinct user credentials). For this reason, developers often hard-coded them into their apps to simplify the authentication process. And that is where researchers located the problem.

With the hard-coded four secret keys—say, extracted through reverse engineering or discovered through Google dorking—threat actors could access complete databases of applications using QuickBlox. That was possible because an application-level session alone, i.e., an authenticated and authorized client, was sufficient to use the QuickBlox API to:

• Retrieve a complete list of application users and create new user accounts (controlled by the attackers) by exploiting the “/users.json” API route.
• Obtain private user information such as emails and phone numbers using the “/ID.json” API route, where ID stands for the incremental user identifier.

QuickBlox included user privacy settings that allowed application owners to restrict application/client-level access. However, the researchers discovered that only a fraction used this option in their applications. But even with restricted access, a threat actor could still retrieve user information by abusing the QuickBlox sequential user ID system (similar to what we saw in the Honda case).

The researchers demonstrated their findings through two concrete examples.

The first one was Rozcom. It’s an intercom and access control company that uses QuickBlox on the backend.

By exploiting the QuickBlox API bugs and Rozcom’s own application flaws, the security researchers managed to:

• Download databases of Rozcom customers
• Perform successful account takeover attacks

That allowed them to access intercom device cameras and microphones, open doors remotely, stream videos at will, and perform other nefarious privacy-threatening activities.

The other example was a telemedicine application developed by a company whose identity the researchers didn’t reveal for security reasons.

Since the application relied on the QuickBlox API, the security researchers abused the bugs described above to access patient data, including personal information, medical history and records, and chat history. They could even impersonate physicians to change data, communicate with patients for manipulative purposes, and simply wreak havoc on their lives.

The best prevention measures for avoiding security risks like those in QuickBlox are the following:

• Do not hard-code secret keys into your application code
• Do not use sequential (incremental), that is, predictable user IDs
• Do not make user session and authentication hinge on application session and authentication

Booking.com

The third discovery was published in March by the Salt Security researcher Aviad Carmel. His report explained the results of the analysis of bugs found in the OAuth implementation in Booking.com, one of the most popular and profitable travel services.

As a reminder, OAuth (open authorization) is a popular authorization protocol increasingly used for authentication. Though it’s considered secure, security experts often warn that:

• It’s not an authentication mechanism and shouldn’t be used as such
• It’s complex, and minor oversights and mistakes in its implementation can have significant consequences (as you’ll see very soon)

The whole point of OAuth is for users to access an application through their credentials from another application or service, that is, without setting up a new account from scratch each time they want to use a new web or mobile app.

Typically, the tech giants Google, Microsoft, and Facebook play the role of identity providers or better attestants in an OAuth flow. They also act as API providers in the process: the entire communication between them and the other app/service is possible through API functionality.

Carmel used a victim Booking.com account and decided to dissect the OAuth flow between Booking.com and Facebook.

When you use Facebook to log in to Booking.com, Facebook first responds with a single-use authorization code instead of a token. The code is passed in the URL as a query parameter. Booking.com exchanges the code for a token that gives access to the Facebook API; it relies on the API to receive essential information about user identity, such as an email address. This process is called authorization code flow.

If threat actors targeted this process, they would go after the authorization code. And that’s what the Salt Security researcher did, too.

A critical element in the authorization code flow plays a parameter called redirect_uri. It’s the URL to which Facebook redirects the user wanting to log in to Booking.com, meaning it must lead to an appropriate Booking.com page.

However, the researcher found that Facebook knows only the origin of the redirect URL, account.booking.com, but not the precise path. That left room for manipulation: He could try to manipulate the path to send the code to an external domain controlled by him. This security flaw is known as open redirection.

Carmel found a way to redirect to an external domain by changing the value of the redirect URL’s state variable to lead to the domain he controlled. In addition, he changed the response type in the redirect URL from “code” to “code, token.” That way, he ensured that Facebook sent the code and token to his domain in a hash fragment (the values that follow “#” in a URL).

After successfully stealing the victim’s code, the researcher attempted to log in to Booking.com by replacing his code with the victim’s code. He expected to see an exchange of the code for a token and access the victim’s Booking.com account. However, he only received an “invalid code” response.

His attempt failed because Facebook required the same redirect URL throughout the OAuth flow, but since the researcher changed it, Facebook replied with an error message.

Things changed when the white hat hacker tried to log in from a mobile phone. He noticed that the OAuth flow on the mobile app was different. It allowed him to circumvent the Facebook validation check of the redirect URL, which meant he could replace his code with the stolen victim’s code and change the redirect URL without Facebook throwing an error.

Carmel achieved a complete account takeover by manipulating the OAuth flow between Booking.com and Facebook. His method could allow him take over any Booking.com account that used Facebook for identification and authorization.

In addition, he could also access the victim’s account in Kayak, a sister company of Booking.com, since users can log in to Kayak using their Booking.com account. Even though the problem was how Facebook was integrated with Booking.com, the security researcher found that he could successfully perform the same attack even for a Booking.com account authenticated with Google.

The consequences of this vulnerability can range from unauthorized requests from someone else’s account to canceling reservations to accessing and taking advantage of sensitive information.

Like the other two companies we discussed, Booking.com reacted promptly and resolved the security issues quickly after Carmel informed them about the vulnerability.

To eliminate the possibility of this attack, you must:

• Hard-code paths in the redirect URLs
• Not allow user input, that is, users to be able to add values to the redirect URL

Conclusion

API-related vulnerabilities are a widespread phenomenon. Here, we explored only three of the many major cases disclosed in 2023. You learned how security researchers discovered them and what went south in the way three different companies used APIs.

Don’t wait for vulnerabilities to become API security incidents. Integrate security into SDLC, don’t trust third-party APIs by default, and test your APIs frequently.

Contact us at Equixly to discover the benefits of machine learning and continuous security testing for your APIs and API-reliant applications. We would be thrilled to help.

Carlo De Micheli

Director of Product Marketing

Carlo is a versatile professional with extensive international experience. His enthusiasm for innovation extends across cybersecurity, automotive, and aerospace, where he actively engages in pioneering projects. Holding a technical background in aerospace engineering and supplementing it with independent studies in programming and security, Carlo has organized and presented at international conferences and established tech startups related to the sharing economy and fashion before embracing marketing and sales.

Zoran Gorgiev

Technical Content Specialist

Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing.