Allowed abuse through messages with manipulated user handles

[gnh1201]

Summary

Recently, I discovered a strange issue occurring on one of the Misskey instances. Despite the author being different from the actual one, Misskey allowed the message to be received.

I suspect this issue might have been caused by a bug in the caching function of the CDN service I use. Additionally, I realized there was no verification process in place even when the author was manipulated. It became clear that relying solely on HTTP signatures, which are commonly used by ActivityPub applications, is insufficient to prevent this.

I believe there is a need for countermeasures to address this issue.

The issue is now resolved, so I can't reproduce it, but I have a screenshot as evidence.

Misskey version: 2024.3.1

The Misskey instance where the issue was confirmed is on a server managed by someone else beyond my authority. I have requested their cooperation to check this, but I have not received a response yet.

Purpose

This issue could potentially be exploited to forge messages. If further developed, it could become a security vulnerability.

Do you want to implement this feature yourself?

• Yes, I will implement this by myself and send a pull request

[gnh1201]

Here is the JSON view of a reply sent by someone from the Misskey instance (example.org). I can see that the link handle and the displayed handle are different here as well. The content has been redacted for privacy.

{
            "id": "112974808957671390",
            "created_at": "2024-08-17T01:39:38.195Z",
            "in_reply_to_id": "112972745950554176",
            "in_reply_to_account_id": "109419749463281498",
            "sensitive": false,
            "spoiler_text": "",
            "visibility": "unlisted",
            "language": null,
            "uri": "https://example.org/notes/[0-9a-z]",
            "url": "https://example.org/notes/[0-9a-z]",
            "replies_count": 1,
            "reblogs_count": 0,
            "favourites_count": 1,
            "edited_at": null,
            "favourited": true,
            "reblogged": false,
            "muted": false,
            "bookmarked": false,
            "content": "\u003cp\u003e\u003ca href=\"https://catswords.social/@something\" class=\"u-url mention\" rel=\"nofollow noopener noreferrer\" target=\"_blank\"\u003e@gnh1201@catswords.social\u003c/a\u003e Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer nisl arcu, varius eget mollis eget, venenatis id lorem. Phasellus vestibulum maximus mollis. Nullam diam nulla, sollicitudin a laoreet. ​:blobcatyes:​\u003c/p\u003e",
            "filtered": [],
            "reblog": null,
            "account": {  /*** account infomation ***/  },
}

[zyoshoka]

This is probably an exploit of an already known vulnerability—detailed in this advisory—which have been fixed in 2024.5.0, so the server administrator need to update their version, or as a workaround, you may be able to prevent the exploitation by enabling AUTHORIZED_FETCH, which stops generating LD-Signature, in your server. Perhaps my guess was wrong.

[gnh1201]

Before addressing the issue, I noticed that the Lookup was not working properly on my test Misskey instance. This led me to check if the webfinger response from the remote server was corrupted during the Lookup attempt.

It turned out that the response was indeed corrupted, and I believe this was likely the cause.

It seems that the validation of the transmitted message operates independently from retrieving user information from the remote server. As a result, Misskey appears to use the tampered webfinger response as user information without suspicion.

[gnh1201]

If someone swaps out a webfinger response with another user's, it could cause that user's avatar and nickname to appear as if they were the author.

[KisaragiEffective]

I can't determine why that was happened, but one possible situation is that fedrating updated information was delayed and someone had overlapped information on that.

[gnh1201]

@KisaragiEffective This is not just a delayed update. I have identified the cause and documented it in the security advisories.