This week, we have two API vulnerabilities: the first is a critical remote code execution (RCE) and API access flaw in the Open Automation Software (OAS) platform, the second a mass account takeover vulnerability in the Yunmai smart scale API. We also have an article on preventing API abuse, and a write-up on how to use pentesting methods to prevent API attacks on applications.
Vulnerability: OAS platform vulnerable to critical RCE and API access flaw
Bleeping Computer has featured news of a pair of vulnerabilities in the widely used Open Automation Software (OAS) platform. The OAS platform is a popular data connectivity platform used in industrial control systems, and it allows inter-operation between a wide range of devices and protocols.
The first vulnerability is a critical RCE flaw that could have potentially compromised the whole platform: an API endpoint allowed remote administration of the platform. The researchers discovered that they were able to access the endpoint in question with a blank username and password, allowing arbitrary remote access to the platform. The issue has a CVSS rating of 9.4 and is tracked as CVE-2022-26833. This is an example of API2:2019 โ Broken authentication.
The second vulnerability is due to lack of authentication at an API endpoint and relates to a file write vulnerability in the platform’s secure file transfer module. The researchers found that they could send specially crafted requests to an API endpoint that allowed to upload arbitrary files, including a new authorized_keys file in the root user’s SSH directory which in turn allowed full remote access. The issue has a CVSS rating of 9.1 and is tracked as CVE-2022-26082.
The vulnerabilities were disclosed responsibly and have been fixed in version 16.00.0.113, released on 22 May 2022. The researchers recommend either upgrading to the latest version of the platform, or explicitly deactivating the impacted service endpoints.
Vulnerability: Mass account takeover in Yunmai smart scale API
The second vulnerability this week comes from the security team at Fortbridge who discovered a range of vulnerabilities in the API of the Yunmai smart scale.
The researchers performed a penetration test on both Android and iOS versions of the smart scale app and discovered four vulnerabilities relating to the backend API. By combining these vulnerabilities, they successfully executed a mass account takeover. The vulnerabilities were responsibly disclosed to the vendor, but it is unclear if the issues have been resolved at the time of writing.
The first vulnerability allowed attackers to bypass the limit on the number of family members per account. The app only allows creating 16 accounts in a family, but using the API directly did not pose any number limit. The root cause is that the limit was enforced only client side, not in the backend API. This is a common application design flaw โ always ensure restrictions and limits are enforced in the backend API.
The second vulnerability allowed arbitrary enumeration of user IDs by guessing IDs using Burp Suite automation. The API did not adequately authorize access to the guessed ID, instead returning full user information, including sensitive PII. This is an example of API1:2019 โ Broken object-level authorization โ remember to always fully authorize access to objects against the object owner.
The third vulnerability is an example of API2:2019 โ Broken authentication, allowing the researchers to add and delete users from other people’s accounts using the ability to enumerate user IDs. Always ensure all API endpoints are authenticated.
The fourth vulnerability allowed the researchers to gain access to both the refresh token and access token when creating new users. By inspecting the response in Burp Suite, the researchers found that these tokens were accidentally leaked as shown:
Armed with this combination of tokens, attackers were effectively granted access to the platform for perpetuity. This is an example of API3:2019 โ Excessive data exposure โ always be wary of leaking information, particularly access tokens.
For the coup de grace, the researchers were able to combine three of the vulnerabilities to perform mass account takeover attacks using the forgotten password flow.
This is a really great write-up that demonstrates three of the API Security Top 10 in action and how easily vulnerabilities can be combined โ thanks to the author for contributing to our community!
Article: How to prevent API abuse
This week, our friends at Approov have discussed how to prevent API abuse. Increasingly, organizations are experiencing malicious use of their APIs in attempts to take advantage of them in unintended or unexpected ways. Typically, such abuse attacks can achieve excessive data exfiltration, data mining, or denial-of-service (DoS).ย API abuse is generally regarded as distinct from API attacks, which tend to focus on specific API vulnerabilities โ nonetheless, API builders should take steps to mitigate against abuse.
Common examples of API abuse include:
- Man-in-the-middle (MITM) attacks
- Repackaged or modified apps
- Scripts or bots
- Reverse engineered apps
Approov recommends the following mitigation tactics against API abuse:
- Monitoring and logging
- Rate limiting
- Authentication and authorization
- Certificate pinning
Anyone wanting to learn more on this topic can get a detailed look at API abuse protections in practice in a recent webinar with Approov and 42Crunch.
Article: Pentesting to prevent API attacks
We’re spoiled this week with another excellent write-up of a pentest, this time against a web application using Java-RMI services.
The article describes a variety of techniques used to exploit a web application and the underlying APIs without success. However, discovering that the backend used Java Remote Method Invocation (RMI) services opened the path to use a variety of techniques to exploit this Java platform, ultimately resulting in a proof-of-concept.
The researchers recommend the followingย best security practices for securing Java-RMI services:
- Run RMI services over SSL/TLS to prevent MITM attacks.
- Require authentication for both server and client.
- Run a security manager when using RMI.
- Ensure that the value of the property
java.rmi.server.useCodebaseOnlyis set totrue.
Again, thanks to the author for this detailed write-up.
Webinar: API Breaches from H1 2022
As APIs become the preferred attack vector for attackers, there has been an inevitable rise in the number of API-related breaches and vulnerabilities. I will outline the root causes of some recent API vulnerabilities that have been making the news.
This practical and interactive webinar will give an illuminating insight into how easily APIs can be compromised leading to a potentially devastating impact on organizations. The topics covered include:
- Understanding of how the vulnerability occurred, and the potential impact.
- A detailed look at the underlying OWASP API security Top 10 flaw.
- Practical demonstration of how 42Crunch can detect and protect from such vulnerabilities.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
