Hi all. I realize that this issue has been posted multiple times with different potential solutions, but my security team has asked me to investigate further to see if this can be addressed by either the Openfire development or Nessus support channels.
Our Openfire server (4.4.4 and earlier) has been reported by Tenable Nessus as potentially vulnerable to XMPP Cleartext Authentication on port 5222. The server is configured to require STARTTLS on 5222 and offers the PLAIN SASL mechanism for user authentication passthrough to LDAP (AD).
Here is a sample (transcribed, reformatted) client-server initial communication to demonstrate what Nessus is attempting:
C: <?xml version='1.0' ?> <stream:stream to='localhost' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> S: <?xml version='1.0' encoding='UTF-8'?> <stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns="jabber:client" from="MY SERVER NAME" id="ID" xml:lang="en" version="1.0"> <stream:features> <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls> <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"> <mechanism>PLAIN</mechanism> </mechanisms> </stream:features>
The Nessus plugin is checking the offer of PLAIN or LOGIN SASL mechanisms during the initial communication and if offered determines that the service is potentially vulnerable. This is reasonable if STARTTLS is not required or optional.
However, RFC 3920 section 5.1 rule 4 says:
- If the initiating entity chooses to use TLS, TLS negotiation MUST
be completed before proceeding to SASL negotiation; this order of
negotiation is required to help safeguard authentication
information sent during SASL negotiation, as well as to make it
possible to base the use of the SASL EXTERNAL mechanism on a
certificate provided during prior TLS negotiation.
This is relying on the client to interpret the STARTTLS requirement and not to (potentially) attempt authentication in the clear if other mechanisms (e.g. PLAIN or LOGIN) are offered.
I have worked with other SASL authentication enabled services (e.g. POP & IMAP daemons) where the expected behavior is to only send mechanisms that are permissible at each step of the conversation.
The bottom line: should any SASL mechanisms other than EXTERNAL be offered if STARTTLS is required?