This week, we have news of two API-related data breaches: the first in Urlscan.io API, which was found to be leaking sensitive URLs and data, and the second a phishing attack on Dropbox, where private GitHub repositories were copied. We also have an article on the importance of contract testing for microservices, and finally, another contribution from Dana Epp on five mistakes that hackers make when attacking APIs.
Breach: Urlscan.io leaking sensitive URLs and data
First up is a report from PortSwigger on the recent vulnerability in the Urlscan.io website, which unwittingly leaked URLs and other sensitive data, including emails. Urlscan.io is a popular tool in the industry for automated scans on websites to assess if they contain malicious content. The Urlscan.io service provides an API that allows users to scan websites automatically as part of a defense strategy, for example, on all incoming emails.
The alarm was raised by GitHub earlier this year, when they discovered that certain GitHub Pages URLs had been accidentally leaked. Last week, Positive Security published a detailed blog on how they believe the sensitive information was leaked. Most worrying was the sheer volume of leaked sensitive information, including password reset links, meeting invitations, setup pages, DocuSign requests, package tracking links… This probably was helped by the search feature on Urlscan.io which allowed an adversary to search for common links using “Google dorks” โ for example, this query shows a large list of potential API keys in URLs.
The root cause was found to be a misconfigured API call within the API SDKs that Urlscan.io supplies (they call those packs in their terminology). When calling the Urlscan.io API, the calling client specifies the URL that is scanned and some other parameters, including the visibility of the scan results on the Urlscan.io platform โ unfortunately, it appears that public was chosen as the default value. While not strictly speaking a vulnerability in the API, this certainly illustrates the importance of sensible and secure defaults.
Unfortunately, removing sensitive URLs was a manual process that had to be initiated with the Urlscan.io support team โ it appears many large corporations, such as Apple, have had their URLs removed. If you believe your organization is affected, it might be a good idea to reach out to confirm.
Breach: Dropbox phishing attack leaks 130 code repositories
The second breach this week is the reported copying of 130 private GitHub repositories belonging to Dropbox in an apparent phishing attack. The Register provide their customary tongue-in-cheek analysis of the breach, which resulted in leaking many secret API tokens and necessitated a rotation of all developer API credentials accessed in the incident.
The breach followed a fairly familiar pattern of attacking a site through a 3rd party connected service. Dropbox reportedly uses the popular CI/CD platform CircleCI for internal builds, which is integrated with their private GitHub code repositories. In this instance, an attacker sent phishing emails to Dropbox developers, which tricked them into visiting a spoofed CircleCI login page where they entered their credentials (including an OTP). Using the leaked credentials, the attacker could access the connected GitHub organization, including access to the private repositories.
Dropbox was oblivious to this activity, and the breach only came to light after GitHub’s security monitoring team alerted them of suspicious activity on their repositories. In fact, GitHub had only just recently issued a security warning about this attack using CircleCI as the lure. Full marks to GitHub for both their proactive and reactive response on this one.
Obviously Dropbox was less stellar in its security process โ phishing is, unfortunately, an inevitability regardless of how much awareness training is offered; however, one would expect those fake CircleCI URLs to have been easily detected in an email filter. The more serious issue is the storage of API tokens in code repositories; at least in this case, there was a protocol to revoke the tokens. Remember to always use tokens with their scope and lifetime limited to the minimum necessary when connecting 3rd party services.
Article: Contract testing for microservices
This week, TechTarget featured an article on the importance of contract testing for microservices which is worth reading for anyone embracing a design-first approach to API design.
The author highlights some common challenges facing integrators and test teams building large-scale microservice-based systems, such as:
- Too many integrations to test: As microservices continue to grow (enabled by APIs), it becomes increasingly difficult to test individual microservices and testers become reliant on testing the end-to-end system, making it hard to identify points of failure.
- Mismatched microservice versions: As microservices are updated more frequently, it becomes difficult to manage their versions, meaning that often tests are being run against newer versions of an API which can result in a fragile system.
- Lack of clear testing requirements: Unless a tester is precisely clear about the expected behavior of a service, it is difficult to determine a pass or fail condition.
Contract testing offers several key benefits:
- Scale: Individual services can be tested locally at the point of development, without waiting for a complete end-to-end deployment.
- Manageable tests: If only two microservices change, it is not necessary to test the entire system; rather, the affected services can be tested in isolation against their contract.
- Scope: The contract defines precisely the expected behavior, removing doubt in the tester’s mind about the scope of what to test.
One obvious downside is the reliance on a contract to begin with. My opinion is that the time invested in getting the contract correct up-front is time well spent from several perspectives โ testing, documentation, and security.
Article: Five mistakes beginners make attacking APIs
This week, we have another great article on API security from Dana Epp where he takes a look at the top five mistakes that beginners make when attacking APIs.
One of the challenges facing a technology writer is to convey their depth of knowledge into a single blog post, but this particular article absolutely nails it. If you’re starting out with hacking or attacking APIs, I cannot recommend this highly enough.
To whet the appetite, here’s Dana’s top five rookie mistakes that attackers make:
- They donโt do enough reconnaissance.
- They donโt discover API documentation.
- They donโt use disposable IP addresses.
- They donโt log and document enough.
- They give up too early.
Another great article from Dana โ two more to go and he gets a free coffee on the house ๐
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
