Add Security Consideration highlighting the risk of SSRF Attacks

[ThisIsMissEm]

@thisismissem on FediDevs Matrix:

The number of decentralised projects for javascript runtimes that I see that are susceptible to SSRF attacks through naive usage of fetch() are growing significantly — remember: fetch() can fetch resources internal to your network; When making a request with arbitrary user input as the URL, you need use something other than bare fetch() as you need to resolve DNS first and assert that the resolved IP addresses are non-private IP addresses.

I currently know of at least 4 very large projects that are or have been susceptible to SSRF attacks through their usage of fetch()

This also affects other platforms that just use their native HTTP Client without checking resolved IP addresses for hostnames.

We do currently have a security consideration for localhost resolution, however, we do not have a more general SSRF Attack security consideration.

I was sure there was a Primer page for this, but I cannot find one now. There is also nothing noted in the Erratum right now for this.

[jernst]

Can you provide an example for such an attack in the Fediverse?

[ThisIsMissEm]

In OAuth Client ID Metadata Documents, the language we currently have is:

Authorization servers fetching the client metadata document and resolving URLs located in the metadata document should be aware of possible SSRF attacks. Authorization servers SHOULD avoid fetching any URLs using private or loopback addresses and consider network policies or other measures to prevent making requests to these addresses. Authorization servers SHOULD also be aware of the possibility that URLs might be non-http-based URI schemes which can lead to other possible SSRF attack vectors.

[ThisIsMissEm]

Can you provide an example for such an attack in the Fediverse?

Whilst I'm not certain if we've seen this attack vector actively used in practice, it is still a security risk. For example there are services setup to give a public domain name that actually resolves to 127.0.0.1 or similar. Additionally you could target other network infrastructure by resolving to 172.17.0.0/16 which is used by Docker for internal networking.

Mastodon has had a mitigation in place for this for a number of years. Maybe they know of someone exploiting this?

[ThisIsMissEm]

We'd probably need guidance that this applies not just to Activities and Objects, and fetching said resources from remote servers, but also to media files from Image / Video / etc.

[nightpool]

the biggest threat for current Fediverse deployments is Elasticsearch, which has an internal HTTP API that isn't always secured well. I think modern ES deployments have made this much less of a risk though

On Fri, Jul 26, 2024, 11:16 AM Emelia Smith @.***> wrote:

We'd probably need guidance that this applies not just to Activities and Objects, and fetching said resources from remote servers, but also to media files from Image / Video / etc.

— Reply to this email directly, view it on GitHub https://github.com/w3c/activitypub/issues/451#issuecomment-2253252557, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABZCV5WJCAWVKRIFL7IRFTZOKHATAVCNFSM6AAAAABLQ6BQ5KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJTGI2TENJVG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[ThisIsMissEm]

the biggest threat for current Fediverse deployments is Elasticsearch, which has an internal HTTP API that isn't always secured well. I think modern ES deployments have made this much less of a risk though

On Fri, Jul 26, 2024, 11:16 AM @ThisIsMissEm wrote: We'd probably need guidance that this applies not just to Activities and Objects, and fetching said resources from remote servers, but also to media files from Image / Video / etc.

@nightpool this is completely unrelated. Securely operating software + it's dependencies is a totally different topic, arguably out of scope of ActivityPub as a specification and protocol.

This issue is about during the processing of ActivityPub as a protocol, requests to external untrusted URLs happens, and as such a malicious actor could send you an activity that hits IP addresses internal to your network after DNS resolution.

[ThisIsMissEm]

We'd probably need guidance that this applies not just to Activities and Objects, and fetching said resources from remote servers, but also to media files from Image / Video / etc.

To clarify this, I meant: when an ActivityPub server wishes to fetch media attachments from remote servers, e.g., to store them in a cache or process them, those requests should be verified as not targeting internal network resources.

[nightpool]

Sure, I don't disagree with that. I was just saying to your question of "Do mastodon developers know of people currently/in the past exploiting this", the biggest vulnerability in most deployments for SSRF is that many Mastodon servers had internal, unsecured ES deployments

[ThisIsMissEm]

@nightpool right, I'm saying, I know mastodon has a mitigation for SSRF in their code; I'm not sure if there was an incident that lead to this being added, or if they added it just to follow security best practices, since that was in the context of being asked in there's any examples of such an SSRF attack on the fediverse.

But also, insecure ES deployments are not SSRF attacks. See CWE-918. An insecure ES or database would be something like CWE-200: "Exposure of Sensitive Information to an Unauthorized Actor"

[ThisIsMissEm]

Here's a longer write up of this vulnerability for Fedify: https://github.com/dahlia/fedify/security/advisories/GHSA-p9cg-vqcc-grcx

[ThisIsMissEm]

Might be a dupe of #433

[ThisIsMissEm]

@jernst Claire from the Mastodon team linked me to this security advisory: https://github.com/mastodon/mastodon/security/advisories/GHSA-hcqf-fw2r-52g4 stating,

the proof of concept for the vulnerability above basically used HTTP request smuggling to target redis; required a specific configuration, and was only possible due to a vulnerability in Mastodon, but that's one thing the SSRF protection did defend against

basically if an attacker can make requests outbound from your software target arbitrary network addresses, then all sorts of attacks can be possible.

[evanp]

I agree that this is a very interesting problem for ActivityPub implementers. I think that it does not reach the level of an since it was not included in the first version of the specification or security considerations. Cover a lot of topics. This was not one of them, even though the local host question is similar.

I think the next step would be to prepare a primer page with guidance on how to implement this safely and then consider it for addition to a future version of activity pub as a non-normative security consideration.