[Question] Regarding Akkoma's behavior after receiving a corrupted WebFinger response #833
Labels
No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#833
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
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.
(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.
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
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?
|> 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
I’m not sure what specific issue you’re hinting at; can you elaborate?
As mentioned before, it would be good to know:
Or framed from the view of the querying server:
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.