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

Vendor Product Status Contacted Updated
Apache Vysper Unaffected 2012-08-02 2012-08-14
Apple Inc. iChat Server Affected 2012-08-07 2012-08-09
Cisco Systems, Inc. Jabber XCP Unaffected 2012-08-02 2012-08-02
Citadel Citadel Unaffected 2012-08-02 2012-08-02
CommuniGate CommuniGate Pro Unaffected 2012-08-02 2012-08-14
Coversant SoapBox Server Unaffected 2012-08-02 2012-08-09
djabberd djabberd Unaffected 2012-08-02 2012-08-12
Google Google Talk Unaffected 2012-08-02 2012-08-03
IBM Lotus Sametime Gateway Unaffected 2012-08-09 2012-08-09
IceWarp IceWarp Instant Messaging Server Unknown 2012-08-02 2012-08-02
igniterealtime.org Openfire Unaffected 2012-08-02 2012-08-02
inetdextra in.jabberd Unaffected 2012-08-02 2012-08-02
Isode Ltd. M-Link Fixed 2012-08-02 2012-08-07
jabberd 1.x jabberd 1.x Unaffected 2012-08-02 2012-08-07
jabberd 2.x jabberd 2.x Fixed 2012-08-02 2012-08-08
j-livesupport Jerry Messenger Unknown 2012-08-02 2012-08-02
Kwickserver Kwickserver Unknown 2012-08-02 2012-08-02
ProcessOne ejabberd Unaffected 2012-08-02 2012-08-14
Prosody Prosody Unaffected 2012-08-02 2012-08-02
psyced psyced Fixed 2012-08-02 2012-08-02
Siemens Siemens OpenScape Unknown 2012-08-02 2012-08-02
Tigase Tigase Fixed 2012-08-02 2012-08-02
Vines Vines Unaffected 2012-08-02 2012-08-02
Wokkel Wokkel Unaffected 2012-08-02 2012-08-15

References

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@xmpp.org discussion list.