what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

Tigase XMPP Server Stanza Smuggling

Tigase XMPP Server Stanza Smuggling
Posted May 26, 2022
Authored by Ivan Fratric, Google Security Research

Tigase XMPP server suffers from a security vulnerability due to not escaping double quote character when serializing parsed XML. This can be used to smuggle (or, if you prefer, inject) an arbitrary attacker-controlled stanza in the XMPP server's output stream. A malicious client can abuse this vulnerability to send arbitrary XMPP stanzas to another client (including the control stanzas that are only meant to be sent by the server).

tags | exploit, arbitrary
SHA-256 | 80c339179764f04e39876070e482957638cbcf822ccdb04b5cc72ea035585e1e

Tigase XMPP Server Stanza Smuggling

Change Mirror Download
Tigase XMPP server: XMPP stanza smuggling via unescaped qutes

Tigase XMPP server suffers from a security vulnerability due to not escaping double quote character when serializing parsed XML. This can be used to \"smuggle\" (or, if you prefer, inject) arbitrary attacker-controlled stanza in the XMPP server's output stream. A malicious client can abuse this vulnerability to send arbitrary XMPP stanzas to another client (including the control stanzas that are only meant to be sent by the server).

Consider for example the following XML tag

<foo attr='aaa\"bbb' />

which contains a single attribute enclosed in *single* quotes.

When Tigase parses and then serializes the element, it will convert single quotes to double quotes, however it will not escape the double quote. Thus the output becomes

<foo attr=\"aaa\"bbb\" />

Which is invalid XML. The corresponding code for serializing attributes can be seen in https://github.com/tigase/tigase-xmltools/blob/b0c64df99f62b88bec7c152d52027369b6415ada/src/main/java/tigase/xml/Element.java#L845

To see how this issue can be used to smuggle arbitrary stanzas through the server, consider for example the following incoming stanza

<message ...>
<body>
<body a='a\"/>' >text</body>
<message a='a\"/>' >text</message>
<iq>...</iq>
<message a='a\">' />
<body a='a\">' />
</body>
</message>

When this stanza gets parsed by the server, the corresponding tree is

-message
--body
---body with attribute name=a value=a\"/>
----cdata=text
---message with attribute name=a value=a\"/>
----cdata=text
---iq
---message with attribute name=a value=a\">
---body with attribute name=a value=a\">

However, when such a stanza gets serialized and forwarded to the recipient client (or another XMPP server) it becomes

<message ...><body><body a=\"a\"/>\" >text</body><message a=\"a\"/>\" >text</message><iq>...</iq><message a=\"a\">\" /><body a=\"a\">\" /></body></message>

(single quoted attributes became double quoted)
When the receiving client parses it, the corresponding tree is seen as

-message
--body
---body with attribute name=a value=a
---cdata=\" >text
--message with attribute name=a value=a
--cdata=\" >text
-iq
-message with attribute name=a value=a
--cdata=>\" />
--body with attribute name=a value=a
---cdata=>\" />

This works because, after the quote, we used '/>' instead of '>' and vice-versa to change the semantics of the closing tags.

As can be seen in the tree above, the receiving client will consider the iq tag (that was originally a part of the message body tree) as a new stanza at the same \"depth\" in the XML tree as the message stanza.

As mentioned above, this can be used to \"smuggle\" arbitrary stanzas through the XMPP server to the victim client. This can be used for message spoofing (making it appear a message was sent by a different sender), but also, depending on the XMPP extensions the client implements and what data is sent over XMPP, it can have impact beyond that (e.g. potentially redirecting the connection through a malicious XMPP server, code execution).

This bug is subject to a 90-day disclosure deadline. If a fix for this
issue is made available to users before the end of the 90-day deadline,
this bug report will become public 30 days after the fix was made
available. Otherwise, this bug report will become public at the deadline.
The scheduled deadline is 2022-06-12.




Found by: ifratric@google.com

Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close