I am the author of the advisory below. As of publication, no CVE number has been issued. This post will be updated when a CVE number is issued.
This advisory describes a class of security vulnerabilities which can manifest due to choices made during HTTP API design and implementation. These vulnerabilities may be used to bypass network security policies and enable data exflitration or unauthorized API use.
Due to it’s reliance on the Google Cloud Storage SDK, users of the current version of rclone are at risk of being impacted by this attack. If a user uses the
rclone sync command to migrate data between different Google Cloud Storage buckets, a situation is created where the full contents of any arbitrary URL chosen by the Google Cloud Storage API server will be silently sent to Google.
Implementation choices made by users of vulnerable API designs may exacerbate or mitigate these weaknesses. As this vulnerability represents a specific instance of the generalized confused deputy problem, environments relying on ambient authority for access control will be especially impacted.
Application developers building non-browser applications do not benefit from the security domain isolation frameworks provided by modern web browsers; developers remain responsible for considering and mitigating the opportunities for unintended interaction across trust boundaries.
- API clients which perform actions on URLs chosen by an API server
- API clients that follow URL redirects provided by an API server
API clients using network transports that are vulnerable to man-in-the-middle attacks will be vulnerable to attack not just by attackers who have gained control over the API server, but also by attackers capable of performing man-in-the-middle attacks.
Known Affected APIs
Software implementing unmitigated approaches to using the following APIs:
Both the Python & Go SDKs provided by Google Cloud are vulnerable to variant 1 of this attack.
This advisory may also apply to other cloud storage APIs.
The Azure Blob Storage SDK examined by the author of this advisory uses a design which mitigates variant 1 of this attack.
Example Attack Scenarios
In the context of a RESTful API implementation, an attacker with control of the API server returns to the client a URL from which they want the client to push or pull data. Alternatively, the API server uses an HTTP redirect to cause the client to interact with a URL of the API server’s choosing.
This allows the attacker to cause the client to request data from a URL of the attacker’s choosing, creating opportunities for data exflitration when that data is later made available to a different trust domain. In clients that PUT or POST data to arbitrary URLs, it allows the attacker to cause PUT or POST requests to be sent to URLs which system designers may assume are inaccessible.
Clients frequently have access to URLs which must remain private. Some software uses the ‘file://’ syntax to allow access to arbitrary system files. URLs hosted on local or private IP addresses are frequently accessible without authentication. In cloud environments, data available at 169.254.169.254 sometimes includes credentials which create significant privilege escalation opportunities. Any data that is authenticated through ambient authority is exposed.
The following system design choices will help mitigate the concerns described by this advisory:
- Create a whitelist of URLs or URL patterns which are safe to access
- Implement a ‘same-origin’ policy at the appropriate level of abstraction for the application. Choosing appropriate trust boundaries may require awareness of the application domain.
- Avoid following URL redirects. If choosing to follow URL redirects, carefully consider the implications of allowing redirects to cross trust boundaries.
- Do not accept any arbitrary URLs from remote servers. Generate all URLs on the client side. Use URL naming strategies which help clarify when a trust boundary is being crossed.
- Use only configurations which are not vulnerable to man-in-the-middle attacks. If using HTTPS, ensure that appropriate certificate verification occurs.
- Give special consideration to DNS rebinding attacks. Blacklist connections to IP space intended for internal use. Be mindful of IPv6, IPv4, and IPv6 mappings of IPv4 IP space.
Google has declined to fix the above vulnerability through their security vulnerability reporting program. As of publication, no expected fix date is available.