[Question] Regarding Akkoma's behavior after receiving a corrupted WebFinger response #833

New issue

Open

opened 2024-09-05 08:48:23 +00:00 by gnh1201 · 3 comments

gnh1201 commented

2024-09-05 08:48:23 +00:00

Allowed abuse through messages with manipulated user handles #14419 (misskey-dev/misskey) https://github.com/misskey-dev/misskey/issues/14419
Potential for User Impersonation Due to Insufficient WebFinger Response Validation (misskey-dev/misskey) GHSA-46c8-wcw3-5gcj
Allows the injection of hidden user handles into a message written by a forged user (mastodon/mastodon) GHSA-64vm-mc82-985g
Security alert for Fedify users. Versions prior to 0.13.1 and 0.12.3 are affected. (dahlia/fedify) https://hollo.social/@fedify/01916542-34a7-74d6-b185-7c87d89a6d08

Recently, I was informed that there is a minor issue related to this matter in Akkoma, though it is not considered serious. After the incident, I fixed the problem on my server, but in Akkoma, my server's handle appears in the format [Unique ID].[ActivityPub user handle]. I would like to understand what this means.

Thank you.

Some time ago, due to a misconfiguration in the CDN settings on my server, manipulated WebFinger responses were being sent out for three days. This incident revealed the potential to spoof or hijack user handles on known ActivityPub implementations such as Misskey and Mastodon. Currently, a review is underway to determine if this issue can be considered a security vulnerability. Additionally, some ActivityPub implementations have released security patches. * Allowed abuse through messages with manipulated user handles #14419 (misskey-dev/misskey) https://github.com/misskey-dev/misskey/issues/14419 * Potential for User Impersonation Due to Insufficient WebFinger Response Validation (misskey-dev/misskey) GHSA-46c8-wcw3-5gcj * Allows the injection of hidden user handles into a message written by a forged user (mastodon/mastodon) GHSA-64vm-mc82-985g * Security alert for Fedify users. Versions prior to 0.13.1 and 0.12.3 are affected. (dahlia/fedify) https://hollo.social/@fedify/01916542-34a7-74d6-b185-7c87d89a6d08 Recently, I was informed that there is a minor issue related to this matter in Akkoma, though it is not considered serious. After the incident, I fixed the problem on my server, but in Akkoma, my server's handle appears in the format `[Unique ID].[ActivityPub user handle]`. I would like to understand what this means. Thank you.

Oneric commented

2024-09-05 18:40:26 +00:00

Member

(Pler/Akk)oma fixed a WebFinger spoofing vulnerability about 4 months ago; see: here. Is this what you’re talking about or something different. Half of the referenced trackers aren’t public and the public ones sparse in details (whose CDN was misconfigured and how? How, if at all possible, can/should remote servers detect this?)

If there are further serious issues on Akkoma’s side, SECURITY.md details how to privately report security issues. If you aren’t sure whether it’s serious first discussing more details in private might be preferable.
If details are already out somewhere public anyway though, there’s not much point in keeping only the Akkoma tracker private.

After the incident, I fixed the problem on my server, but in Akkoma, my server's handle appears in the format [Unique ID].[ActivityPub user handle]. I would like to understand what this means.

This can happen if the authorative WebFinger server reassigns the handle (e.g. if it allows handle renames, the old user was deleted and a new one with the same name created or a prior instance died and a new one created on the same domain).
In such cases the old AP account’s nickname is tenatively renamed to avoid overlap (depending on Pleroma.Web.Finger, :update_nickname_on_user_fetch configuration the nickname can later be updated again by the remote server). See:

   def maybe_handle_clashing_nickname(data) do
     with nickname when is_binary(nickname) <- data[:nickname],
          %User{} = old_user <- User.get_by_nickname(nickname),
          {_, false} <- {:ap_id_comparison, data[:ap_id] == old_user.ap_id} do
       Logger.info(
         "Found an old user for #{nickname}, the old ap id is #{old_user.ap_id}, new one is #{data[:ap_id]}, renaming."
       )
       old_user
       |> User.remote_user_changeset(%{nickname: "#{old_user.id}.#{old_user.nickname}"})
       |> User.update_and_set_cache()
     else
       {:ap_id_comparison, true} ->
         Logger.info(
           "Found an old user for #{data[:nickname]}, but the ap id #{data[:ap_id]} is the same as the new user. Race condition? Not changing anything."
         )
       _ ->
         nil
     end
   end

(Pler/Akk)oma fixed a WebFinger spoofing vulnerability about 4 months ago; see: [here](https://akkoma.dev/AkkomaGang/akkoma/compare/4457928e325cf370a0d2e028232dbd0a542547e0...3e1f5e5372e6c74589dad9f952015e317911b57e). Is this what you’re talking about or something different. Half of the referenced trackers aren’t public and the public ones sparse in details *(whose CDN was misconfigured and how? How, if at all possible, can/should remote servers detect this?)* If there are further serious issues on Akkoma’s side, [SECURITY.md](https://akkoma.dev/AkkomaGang/akkoma/src/branch/develop/SECURITY.md) details how to privately report security issues. If you aren’t sure whether it’s serious first discussing more details in private might be preferable. If details are already out somewhere public anyway though, there’s not much point in keeping only the Akkoma tracker private. > After the incident, I fixed the problem on my server, but in Akkoma, my server's handle appears in the format [Unique ID].[ActivityPub user handle]. I would like to understand what this means. This can happen if the authorative WebFinger server reassigns the handle *(e.g. if it allows handle renames, the old user was deleted and a new one with the same name created or a prior instance died and a new one created on the same domain)*. In such cases the old AP account’s nickname is tenatively renamed to avoid overlap *(depending on `Pleroma.Web.Finger, :update_nickname_on_user_fetch` configuration the nickname can later be updated again by the remote server)*. See: https://akkoma.dev/AkkomaGang/akkoma/src/commit/3bb31117e65079d710e5129eb70c946d4ffe99ff/lib/pleroma/web/activity_pub/activity_pub.ex#L1753-L1773

gnh1201 commented

2024-09-06 06:12:36 +00:00

Author

According to recent cases in other ActivityPub-based applications, user spoofing is possible even within the same domain.

Could you please check if there is any change regarding this issue?

       |> case do
         {:ok, data} -> validate_webfinger(address, data)
         error -> error
       end
     else
       error ->
         Logger.debug("Couldn't finger #{account}: #{inspect(error)}")
         error
     end
   end
   defp validate_webfinger(url, %{"subject" => "acct:" <> acct} = data) do
     with %URI{host: request_host} <- URI.parse(url),
          [_name, acct_host] <- String.split(acct, "@"),
          {_, true} <- {:hosts_match, acct_host == request_host} do
       {:ok, data}
     else
       _ -> {:error, {:webfinger_invalid, url, data}}
     end
   end

Thank you. It seems to be what I was looking for. However, after reviewing the commit details, I noticed that while domain spoofing is mentioned, there doesn't seem to be any mention of user spoofing. According to recent cases in other ActivityPub-based applications, user spoofing is possible even within the same domain. Could you please check if there is any change regarding this issue? https://akkoma.dev/AkkomaGang/akkoma/src/commit/a953b1d9279a4c87d0a26885477a65f939892df9/lib/pleroma/web/web_finger.ex#L220-L240

Oneric commented

2024-09-07 17:55:42 +00:00

Member

According to recent cases in other ActivityPub-based applications, user spoofing is possible even within the same domain.

I’m not sure what specific issue you’re hinting at; can you elaborate?
As mentioned before, it would be good to know:

whose CDN was misconfigured and how?
Or framed from the view of the querying server:
- what URL got queried for webfinger; does it differ from the "correct" URL? If it differs, why?
- how does the received response differ from the correct response
How, if at all possible, can/should remote servers detect this?

Especially the latter point seems tricky. The only robust way i can think of to properly verify WebFinger address to AP object matches is if the queried server implements FEP-2c59, but this FEP is not implemented for gnh1201@catsword.social (nor does Akkoma implement it atm).
Other heuristics may be possible but are likely more brittle.

> According to recent cases in other ActivityPub-based applications, user spoofing is possible even within the same domain. I’m not sure what specific issue you’re hinting at; can you elaborate? As mentioned before, it would be good to know: - whose CDN was misconfigured and how? Or framed from the view of the querying server: - what URL got queried for webfinger; does it differ from the "correct" URL? If it differs, why? - how does the received response differ from the correct response - How, if at all possible, can/should remote servers detect this? Especially the latter point seems tricky. The only _robust_ way i can think of to properly verify WebFinger address to AP object matches is if the queried server implements [FEP-2c59](https://codeberg.org/fediverse/fep/src/branch/main/fep/2c59/fep-2c59.md), but this FEP is not implemented for `gnh1201@catsword.social` *(nor does Akkoma implement it atm)*. Other heuristics may be possible but are likely more brittle.

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: AkkomaGang/akkoma#833

No description provided.