[jcifs] jCifs' NTLMSSP: is it secure and sound?

[Giampaolo Tomassoni]

Dears,

I would like to rise some objections about possible security issues which
may arise from the current jCif's implementation of the NTLMSSP protocol.

I see that the NTLMSSP protocol is meant to "wrap" an authentication mean
around an unauthenticated channel. Thereby, well-behaved implementers do
authenticate every connection they open, irrespective of any "session
semantic" which may be eventually embedded in the payload.

The jCifs' implementation, instead, requires authentication of the first
connection a client establishes, then relies on the http session (i.e.: on
the JSESSION cookie) to authenticate any further connection.

This implies that a third party with basic sniffing capability can very
easily impersonate a user by inspecting his/her traffic and "stealing" the
session cookie. The problem is worsted by the fact that the NTLMSSP protocol
is mostly used in intranet/extranet contexts, which are more sensible to
sniffing dangers and also more prone to switch to non-basic,
non-cookie-based authentication methods for security reasons.

Thereby, to be at least as secure as other implementations, an NTLMSSP
authentication should be started at each connection, not just the first one,
in order to forward authenticated data only to upper, session-aware layers.

It is a matter of fact that a connection-oriented authentication can't be
easily implemented through a servlet or filter, because these objects are
meant to act like a Service Provider and an SP wrapper, not like connection
wrappers. Connection semantics are buried in the so-called servlet Connector
and, possibly, even farther: in an Apache httpd socket manager, in example.

One can object that an NTLMSSP authentication filter could eventually just
force every and each request to be authenticated, but this seems not work
well with at least IE7 and keep-alive http connections. In fact, when IE is
asked to re-authenticate on the second request issued over an
already-authenticated channel, it understands this as a "previous auth data
was wrong", then issuing a login dialog irrespective of any previous
authentication principal and impairing SSO benefits.

I think that a good trade-off between security and portability could
eventually be some kind of connection-tracking. Instead of saving the
NTLMSSP challenge and authenticated data into the HttpSession object,
NtlmHttpFilter should construct a map keyed on expireable
<LocalAddress,LocalPort,RemoteAddress,RemotePort> quads, saving there any
NTLMSSP state data needed by the connection. 

An IP connection is univocally identified by these quads. The connection
state (SYN, SYN_ACK, CONNECTED, CLOSED etc) is not, of course, thereby a
third-party could eventually send packets miming a closed connection in
order to take control over an authenticated channel. However, this is quite
more difficult than just "sniffing the wire", it is easily detectable by the
legit user or the legit workstation will eventually interfere with the
attempt. Also, the chances that a third-party could profitably use a closed
connection are further reduced by expiring a quad after an inactivity
timeout close enough to the one from the keep-alive timer of the http
server.

What are your thoughts about this?

Regards,

-------------------------------------
Giampaolo Tomassoni - I.T. Consultant
Piazza VIII Aprile 1948, 4
I-53043 Chiusi (SI) - Italy
Tel/Ph: +39-0578-21100

MAI mandare un messaggio a:
NEVER send an e-mail to:

 rainbowl at tomassoni.biz