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

[Asaf Mesika]

There's supposed to be two level of authentication:
Communication security - encrypting the content of http. For example: https.
Application security - NTLM, Kerberos.

Used together they should get your app quite secured, and prevent from
attacks you've described (sniffing and spoofing).

Asaf


On Wed, Apr 9, 2008 at 2:30 AM, Giampaolo Tomassoni <Giampaolo at tomassoni.biz>
wrote:

> 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
>
>
-------------- next part --------------
HTML attachment scrubbed and removed