Tenable Nessus XMPP Cleartext Authentication security issue - further details

Openfire Openfire Support
1

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:

  1. 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?

2 Likes
2

I assume this question is wrongly phrased: why would you disallow mechanisms like SCRAM-SHA1 after TLS has been established and just allow EXTERNAL? I think you actually wanted to ask if PLAIN should be allowed before TLS has been established. But then I don’t think this is right question to be asked.

Openfire probably should simply not announce SASL PLAIN on unsecured, as in “not-encrypted”, connections per default. Only if the user explicitly enables PLAIN over unsecured connections in the Openfire configuration, it should be announced (and that only after a big red disclaimer text about the implications).

3

Hi – I agree my phrasing could be better. But perhaps there are two questions here:

What mechanisms should be offered if STARTTLS is required but not yet negotiated on an unsecured connection?

This represents the test case above. My comment regarding EXTERNAL as the only mechanism to provide demonstrates the server’s configuration intent is to require TLS before further communication. Once TLS is negotiated any of the configured mechanisms can be offered.

What mechanisms should be discouraged from use over an unsecured connection?

I agree that PLAIN and LOGIN (at a minimum) should never be offered under an unsecured connection without additional warnings/confirmation.

4

I am confused: I expect EXTERNAL to be only announced after TLS has been established, as it is typically used with TLS. Hence I would consider servers announcing EXTERNAL, with the goal to authenticate the client using a TLS client certificate, before TLS has been established to be broken.

XMPP uses <required/> as child element of <starttls/> to announce that TLS is required.

5

OK, I see your point regarding EXTERNAL.

How do you recommend approaching the issue with nonsecure mechanisms (especially PLAIN and LOGIN, but possibly others?) being offered before TLS is negotiated? Should I follow up with opening an issue in the issue tracker?

6

You won’t be able to open a ticket. One of the developers would have to do this. That is, if they found this as an issue. @gdt, @guus?

7

I’ve raised https://issues.igniterealtime.org/browse/OF-1957 - though JIRA/I managed to break the formatting,

Greg

1 Like
8

Thank you!

9

I probably wouldn’t have gone so far and disallow all SASL mechanisms before TLS is established. But also if TLS is not required, but just optional, you may want to announce certain SASL mechanisms only after TLS has been established.

10

I think there’s certainly an argument to add an option to disable PLAIN auth with optional TLS prior to TLS negotiation.

However I can’t see any advantage to disabling only some auth prior to TLS negotiation if it’s required.

Greg

11

@t1m: Thanks for your publication! :slight_smile:

12

Just to confirm, now I’ve got a decent client to hand;