[jdev] Fwd: [Security] Vulnerability in XMPP Server Dialback Implementations

[Peter Saint-Andre]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI.


- -------- Original Message --------
Subject: [Security] Vulnerability in XMPP Server Dialback Implementations
Date: Tue, 21 Aug 2012 10:03:45 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
Reply-To: XMPP Security <security at xmpp.org>
To: security at xmpp.org

As posted at
http://xmpp.org/resources/security-notices/server-dialback/ ...

###

Vulnerability in XMPP Server Dialback Implementations

Original Release Date: 2012-08-21
Last Updated: 2012-08-21

Overview

Some implementations of the XMPP Server Dialback protocol (RFC 3920 /
XEP-0220) have not been checking dialback responses to ensure that
validated results are correlated with requests.

Description

The Server Dialback protocol is a proof-of-possession technology used
between XMPP servers to provide identity verification based on the
Domain Name System (DNS); the basic approach is that when a receiving
server accepts a server-to-server connection from an initiating
server, it does not process traffic over the connection until it has
verified the initiating server’s key with an authoritative DNS entry
for the initiating server. Additionally, the protocol is used to
negotiate whether the receiving server is accepting stanzas for the
target domain. The goal of the protocol is to help prevent address
spoofing on the XMPP network, which it has effectively done since
deployed on the XMPP network in October 2000.

There are four steps to the protocol:

1.    Authorization Request: The initiating server sends a dialback
key to the receiving server for a given domain pair consisting of a
source domain and a target domain.
2.    Verify Request: the receiving server forwards the key to the
authoritative server for the domain asserted by the initiating server.
3.    Verify Response: the authoritative server informs the receiving
server whether the key is valid or invalid.
4.    Authorization Response: the receiving server reports the result
of the negotiation to the initiating server.

Some XMPP server implementations have not been checking the Verify
Response to ensure that the receiving server previously received an
Authorization Request for the domain pair included in the Verify
Response. Thus an attacking server has been able to send a Verify
Response for domains that were never asserted by an initiating server,
and some receiving servers would accept such domain pairs as validated.

In addition, some XMPP server implementations have not been checking
the Authorization Response to ensure that the initiating server
previously sent an Authorization Request for the domain pair included
in the Authorization Response. Thus an attacking server has been able
to send an Authorization Response for domains that were never asserted
by an initiating server, and some initiating servers would accept such
domain pairs as validated.

Impact

An attacking server could spoof one or more domains in communicating
with a vulnerable server implementation, thereby avoiding the
protections built into the Server Dialback protocol.

Solution

Upgrade to corrected server code.

Vendor Information

Please see http://xmpp.org/resources/security-notices/server-dialback/

References

    https://datatracker.ietf.org/doc/rfc3920/
    http://xmpp.org/extensions/xep-0220.html

Credits

The vulnerability has been separately discovered by multiple teams in
the past. Thanks to Philipp Hancke for recently reporting it in a more
public fashion. Thanks also to Dave Cridland, Tomasz Sterna, and
Matthew Wild for their feedback. This report was written by Peter
Saint-Andre.

Feedback

If you have feedback, comments, or additional information about this
vulnerability, please send email to the security at xmpp.org discussion list.

###

Peter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAzsXkACgkQNL8k5A2w/vz1XACgv/Fj+bnX4ChSvlAEawyNHJe7
wI8AnjAp6Ihrq1veM8VEfqYkbbUSdd+F
=5G3s
-----END PGP SIGNATURE-----