This week, we have two API vulnerabilities: the first in the VeryFitPro app allowed attackers access to a backend API, while in the other LemonDuck botnet attacked exposed Docker APIs. On more positive side, we also have a new version of TruffleHog detecting of stored API credentials, as well as views on how to securely scale APIs in real-world backend platforms.
Vulnerability: API vulnerability in VeryFitPro app
Security researcher Martin Francois recently disclosed a vulnerability in the VeryFitPro fitness tracking app (versions 3.3.7 and lower).
The vulnerability potentially allows attackers to access the backend API without the original credentials. Francois disclosed the details in GitHub after two unsuccessful attempts to contact the vendor. At the time of writing, the vulnerability had not been addressed, and version 3.3.7 was still the most recent version of the app available on the Google Play store, with over 100k installations.
The vulnerability originates from the decision to store a password hash in a device database: if attackers get access to the database, they can reuse the hash to access the account of a targeted user. This method is known as the Pass-the-Hash attack. Francois describes a relatively simple proof of concept for the exploit, and suggests mitigating this by transmitting the user password in the body of the POST request over HTTPS.
Vulnerability: Exposed Docker APIs targeted by botnets
Crowdstrike provides coverage of ongoing attempts by the LemonDuck crypto mining botnet to target exposed Docker APIs on Linux systems. The attacks are anonymized using proxy tools and evade detection because they do not show in Alibaba Cloud’s monitoring services. According to the article, crypto mining is becoming increasingly prevalent, with the majority of compromised Google Cloud Platform instances being used for mining.
Docker executes with elevated privileges so it can spin up containers and use OS resources. The Docker daemon also has the option to expose the management API through a port, typically 2375. If this port is inadvertently exposed to the internet or unsecured, attackers may exploit it to execute arbitrary workloads on the host through Docker. Attacker can point the API to use a customer Docker ENTRYPOINT to execute a malicious core.png file which is actually a shell script:
This script creates a cron job and downloads the active payload, which then performs the following operations:
- Kills processes based on names (competitor applications)
- Kills known daemons, such as
sshd,syslog - Deletes know Indicators of Compromise file paths to evade detection
- Kills know network connections (to competitor websites)
The script then evades Alibaba Cloud’s protection services, and finally downloads the crypto mining payload which then begins mining. Finally, a proxy disguises the recipient crypto wallet to avoid identification.
The key takeaway is to be very careful if exposing the Docker API port, particularly if connected to a public network.
Tools: TruffleHog v3 detects stored API credentials
Leaked API credentials (keys, passwords, and tokens) is one of the most prevalent challenges in security API deployments, and we have frequently featured articles such as this one about bad practices in storing credentials. One of the stalwart tools of the trade for detecting leaked credentials is TruffleHog. This week, PortSwigger has featured details of the newly released TruffleHog version 3, with improved capabilities for API key detection.
TruffleHog can detect credentials leaked through JavaScript or overly permissive CORS settings in APIs. Importantly, TruffleHog can also scan GitHub repositories to discover exposed credentials. The new version supports up to 639 new key types, including AWS, Azure, Confluent, Facebook, and GitHub.
A key new feature in this release is verifying if a suspected leaked credential is still valid by testing access against the affected backend service. This powerful feature should be a great boon to security teams for reducing the false positives from expired or invalidated credentials.
TruffleHog comes highly recommended in my experience, and anyone wishing to actively monitor credential leaks should check it out.
Article: Scaling APIs in real-world backend platforms
This week, our final article is courtesy of Gary Archer at Curity who discusses the security challenges of scaling APIs in real-world backend platforms. Although there are numerous well-written articles about the handling and validating JSON web tokens (JWTs), the articles often lack the depth of coverage on how to scale the use of JWTs to large systems, with multiple APIs and clients.
This article is an excellent discussion on the challenges for the handling of JWTs in complex topologies, and it makes a number of recommendations on topics, such as:
- Use reverse proxies to return opaque tokens rather than raw JWTs.
- Use standard security libraries for JWT validation, and include security parameters in the claims section rather than in headers or URL paths.
- For multiple APIs, use a so-called entrypoint API to federate access to internal APIs based on the calling client.
- Extend JWTs to allow the initial authorizing server to add additional claims to them to be consumed downstream.
- Use a separate short-lived token in callbacks to avoid the challenge that asynchronous methods pose for maintaining the state and identity of the original requester.
- Be aware of the additional challenges regarding authorization and identity posed by partner APIs.
- Design clients to be reliable and resilient to mitigate complexities of microservices with multiple components that present more points of failure.
Great food for thought in this article, thanks for the author for the contribution.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
