Difference between revisions of "IQ Reply Spoofing"

From XMPP WIKI
Jump to navigation Jump to search
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
== Information ==
== Information ==


Most XMPP stacks provide a convenience method to send an IQ request that returns the IQ response (or e.g. throw an exception on timeout). To collect the response the incoming IQ stanzas are matched against a filter. Often the filter looks like
=== The Situation ===
 
Most XMPP stacks provide a convenience method to send an IQ request that returns the IQ response (or e.g. throws an exception on timeout). To collect the response the incoming IQ stanzas are matched against a filter. Unfortunately the filter often looks like


<code>
<code>
Line 7: Line 9:
</code>
</code>


Such a filter would therefore match every IQ stanza with the same ID as the request. But this is not enough. A malicious attacker that is able to guess the IQ ID is able to send a spoofed IQ response, which causes the malicious response to be evaluated by the XMPP stack. This gives the attacker the ability to trigger code parts (usually parsing related code) he normally wouldn't have access to. For example, he could able to add contacts to the victims rooster.
Such a filter would therefore match every IQ stanza with the same ID as the request. But this is not enough. A malicious attacker that is able to guess the request IQ's ID is able to send a spoofed IQ response, which causes the malicious response to be evaluated by the XMPP stack. This gives the attacker the ability to trigger code parts (usually parsing related code) and logic he normally wouldn't have access to. For example, he could able to add contacts to the victims rooster.


The solution is to additionally verify the from attribute of the result IQ, since its value can not be spoofed:
The solution is to additionally verify the from attribute of the result IQ, since its value can not be spoofed:
Line 15: Line 17:
</code>
</code>


Now the devil is in the details: It's valid to send an stanza, and this includes an IQ request, without a to attribute (RFC 6120 § 8.1.1.1). Furthermore some servers may reply with the users full JID if the request was send to the bare JID. <code>IQFromFilter</code> must therefore, besides matching stanzas that have exactly the same 'from' value as the requests 'to' attribute, follow those rules:
Now the devil is in the details: It is valid to send an stanza, and this includes an IQ request, without a to attribute (RFC 6120 § 8.1.1.1). Furthermore some servers may reply with the users full JID if the request was send to the bare JID. <code>IQFromFilter</code> must therefore, besides matching stanzas that have exactly the same 'from' value as the requests 'to' attribute, follow those rules:


If 'to' is not set, match stanzas where 'from' is
If 'to' is not set, match stanzas where 'from' is
Line 24: Line 26:
If 'to' is the sending entity's bare JID, the it must also match stanzas where 'to' is not set.
If 'to' is the sending entity's bare JID, the it must also match stanzas where 'to' is not set.


=== Links with more information ===


More information can be found at:
* http://tools.ietf.org/html/draft-alkemade-xmpp-iq-validation-00
 
* http://www.ietf.org/proceedings/89/slides/slides-89-xmpp-3.pdf
http://tools.ietf.org/html/draft-alkemade-xmpp-iq-validation-00
* http://mailman.jabber.org/pipermail/jdev/2014-March/089892.html
 
http://www.ietf.org/proceedings/89/slides/slides-89-xmpp-3.pdf
 
http://mailman.jabber.org/pipermail/jdev/2014-March/089892.html
 


== Software Components ==
== Software Components ==
Line 46: Line 44:


* '''Smack''', fixed with 4.0 ([https://igniterealtime.org/issues/browse/SMACK-533 SMACK-533], [https://igniterealtime.org/issues/browse/SMACK-538 SMACK-538], [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0364 CVE-2014-0364])
* '''Smack''', fixed with 4.0 ([https://igniterealtime.org/issues/browse/SMACK-533 SMACK-533], [https://igniterealtime.org/issues/browse/SMACK-538 SMACK-538], [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0364 CVE-2014-0364])
* '''libpurple/Pidgin, fixed with https://pidgin.im/pipermail/commits/2014-January/024231.html
* '''libpurple/Pidgin''', fixed with https://pidgin.im/pipermail/commits/2014-January/024231.html
* '''Go XMPP''' https://github.com/agl/xmpp/issues/13
* '''Go XMPP''' https://github.com/agl/xmpp/issues/13
* '''SleekXMPP''' https://github.com/fritzy/SleekXMPP/issues/278
* '''SleekXMPP''' https://github.com/fritzy/SleekXMPP/issues/278
* '''XMPPFramework''' https://github.com/robbiehanson/XMPPFramework/issues/300
* '''XMPPFramework''' https://github.com/robbiehanson/XMPPFramework/issues/300

Latest revision as of 13:28, 30 December 2014

Information

The Situation

Most XMPP stacks provide a convenience method to send an IQ request that returns the IQ response (or e.g. throws an exception on timeout). To collect the response the incoming IQ stanzas are matched against a filter. Unfortunately the filter often looks like

StanzaFilter badFilter = AndFilter(StanzaTypeFilter(IQ), StanzaIdFilter(iqrequest.id))

Such a filter would therefore match every IQ stanza with the same ID as the request. But this is not enough. A malicious attacker that is able to guess the request IQ's ID is able to send a spoofed IQ response, which causes the malicious response to be evaluated by the XMPP stack. This gives the attacker the ability to trigger code parts (usually parsing related code) and logic he normally wouldn't have access to. For example, he could able to add contacts to the victims rooster.

The solution is to additionally verify the from attribute of the result IQ, since its value can not be spoofed:

StanzaFilter iqResponseFilter = AndFilter(badFilter, IQFromFilter(iqrequest.to))

Now the devil is in the details: It is valid to send an stanza, and this includes an IQ request, without a to attribute (RFC 6120 § 8.1.1.1). Furthermore some servers may reply with the users full JID if the request was send to the bare JID. IQFromFilter must therefore, besides matching stanzas that have exactly the same 'from' value as the requests 'to' attribute, follow those rules:

If 'to' is not set, match stanzas where 'from' is

  • not set
  • the sending entity's bare JID, when the resource part is stripped
  • the XMPP service JID

If 'to' is the sending entity's bare JID, the it must also match stanzas where 'to' is not set.

Links with more information

Software Components

Vulnerable

Not Vulnerable / Fixed