An incorrect implementation of XEP-0280: Message Carbons[0] in multiple
XMPP clients allows a remote attacker to impersonate any user, including
contacts, in the vulnerable application's display. This allows for
various kinds of social engineering attacks.
Classification
CWE-304: Missing Critical Step in Authentication
CWE-940: Improper Verification of Source of a Communication Channel
The XMPP protocol extension "XEP-0280: Message Carbons"[0] allows
a user to run multiple clients on their XMPP account by sending "carbon
copies" of outgoing and incoming messages to the user's other devices
(besides the one that directly sent or received the original message).
This feature must be supported by the user's server and must be
explicitly enabled by the client. Carbon copies are always generated by
the user's server and originate from the user's bare JID (their account
address).
For example, the following is message "Hi!", sent by Alice
(alice@xmpp.example) to Bob's client 1 (bob@xmpp.example/client1):
Now, client 2 can extract the original message from the carbon copy and
display it accordingly. The "Security Considerations" section of
XEP-0280 explicitly states that:
| Any forwarded copies received by a Carbons-enabled client MUST be from
| that user's bare JID; any copies that do not meet this requirement
| MUST be ignored.
The Carbons implementation in the affected clients was lacking this
test. It simply checked all incoming messages for presence of a Carbon
element (<received/> or <sent/>), extracted and parsed it like a
regular message.
Therefore, it was possible for Mallory to send the following specially
crafted message to Bob:
This would appear as an authentic message from Alice, including Alice'
proper screen name, allowing Mallory to perform social engineering
attacks on Bob.
Mitigation
While the attacker can send messages in the name of somebody else, they
can not see your responses. Therefore, if you receive a phony message
while using an affected client, reinsure with the message sender by
either challenging them with a question that can not be guessed by the
attacker, or by using out-of-band means.
Xabber: disable the experimental Carbons feature in the app settings.
yaxim: Disabling Message Carbons under "Settings" / "Edit account" /
"Message Carbons (XEP-0280)" will not solve the problem, as the
malicious messages still will be interpreted.
Ref: http://seclists.org/oss-sec/2017/q1/373
Summary
An incorrect implementation of XEP-0280: Message Carbons[0] in multiple XMPP clients allows a remote attacker to impersonate any user, including contacts, in the vulnerable application's display. This allows for various kinds of social engineering attacks.
Classification
Affected Applications
Affected Libraries
Details
The XMPP protocol extension "XEP-0280: Message Carbons"[0] allows a user to run multiple clients on their XMPP account by sending "carbon copies" of outgoing and incoming messages to the user's other devices (besides the one that directly sent or received the original message).
This feature must be supported by the user's server and must be explicitly enabled by the client. Carbon copies are always generated by the user's server and originate from the user's bare JID (their account address).
For example, the following is message "Hi!", sent by Alice (
alice@xmpp.example
) to Bob's client 1 (bob@xmpp.example/client1
):Bob is also logged in with carbons-enabled client 2, which receives the following carbon-copy of the message:
xmlns='urn:xmpp:forward:0'> <message from="alice@xmpp.example" to="bob@xmpp.example/client1">
Hi!Now, client 2 can extract the original message from the carbon copy and display it accordingly. The "Security Considerations" section of XEP-0280 explicitly states that:
| Any forwarded copies received by a Carbons-enabled client MUST be from | that user's bare JID; any copies that do not meet this requirement | MUST be ignored.
The Carbons implementation in the affected clients was lacking this test. It simply checked all incoming messages for presence of a Carbon element (
<received/>
or<sent/>
), extracted and parsed it like a regular message.Therefore, it was possible for Mallory to send the following specially crafted message to Bob:
xmlns='urn:xmpp:forward:0'> <message from="alice@xmpp.example" to="bob@xmpp.example/client1">
Please come to Creepy Valley tonight, alone!This would appear as an authentic message from Alice, including Alice' proper screen name, allowing Mallory to perform social engineering attacks on Bob.
Mitigation
While the attacker can send messages in the name of somebody else, they can not see your responses. Therefore, if you receive a phony message while using an affected client, reinsure with the message sender by either challenging them with a question that can not be guessed by the attacker, or by using out-of-band means.
Xabber: disable the experimental Carbons feature in the app settings.
yaxim: Disabling Message Carbons under "Settings" / "Edit account" / "Message Carbons (XEP-0280)" will not solve the problem, as the malicious messages still will be interpreted.
++++++++++++++++++++++++++++++++++++++