Plumbing New Depths with CIFS Authentication

Andrew Bartlett

Samba Team

Welcome to the Sewer...

Agenda

Assumed knowledge

Understanding authentication

Challenges in CIFS authentication

CIFS authentication technologies:

NTLM

NLTMSSP

Kerberos

SPNEGO

Attacks and defenses in CIFS Auth

Assumed Knowledge

Basics of:

Computer Networks

Workgroups, NT and Win2000 Domains

Survey:

How many engineers?

How many managers?

Developing own CIFS implementation?

Running Samba?

Running Windows?

Lost?

Authentication - What is it?

Proving identity.

Something you are

(Biometrics)

Something you have

(Tokens)

Something you know

(Passwords)

Authorization

Not who you are, but what you are allowed to do

Not everybody is allowed to sit in the CEO's chair...

Group membership

Impersonation

CIFS Authentication provides the gateway

But does not decide the result

Data Integrity

Has this data been modified in transit?

Also known as:

Signing

Can also be used for authentication

Data Encryption

Can this data be viewed while in transit?

Also known as:

Sealing

Privacy

Confidentiality

Authentication Components

Clients

Desktops

Servers

accessing other servers

PDAs?

Web clients?

Clients typically initiate connections

Typically need to prove who there are

Authentication Components

Servers

Logon Servers

KDC, PDC etc

File Servers

Print Servers

Web Servers

Servers typically do not prove who they are

HTTPS for web is the exception

Perhaps we should not have that exception

Workstation Logon

'First Screen' logon

Checks password

Grants access to the machine

not to the network

Sets profiles, groups for local access

Credentials

Kerberos

NTLM cached password

Challenge-Response Auth

Never reveals original password

The value on the wire is 'useless' to an attacker.

Client is returned token / OK

VUID in CIFS

Challenge

Connect

Response

Token

Challenge-Response cont.

Server does password lookup

Makes same calculation user made

Authentication is memcmp() on result.

Password

Challenge

Response

Password

Challenge

Response

Client

Server

Comparison

Session Integrity – The Problem

'Pass through' authentication

Man in the Middle Attack

Trying to stop this happening:

Challenge

Connect

Response

Token #1

BAD GUY

Server

Connect

Token #1

Challenge

Response

Evil Intent

Innocent Response

Session Integrity – The Solution

Challenge

Connect

Response

Token

Request + Signature

Response + Signature

Proves that the client is still the client

Proves that the server is 'trusted'

Relies on some shared secret

Session Key

Session Keys

Not long term password

Basic security principles, don't expose passwords more than you have to.

Should be random

Must be kept private...

Challenges in CIFS Authentication

History

Supporting old password schemes

Supporting a domain logon to NT4

Negotiation

Compatibility over security

Figure out what the remote server can do

Lack of information

Does this server even know what it supports?

A History of Login Types

Plaintext logins

LM

NT Password hash:

NTLM

NTLMv2

Kerberos rc4-hmac-md5

Other passwords:

DES krb5

AES krb5

HTTP Digest

Making it Always Work

Fallback over security

If Kerberos isn't working, try NTLM

Ship weaker LM passwords by default

SMB signing fallback

Negotiation

Extended security is a protocol bit

Positive steps

Microsoft makes it hard to send plaintext

But Samba makes it easy...

Single Sign On

At almost any cost

Automatic login first...

... ask questions later

Defining the boundaries is tricky:

What is 'intranet'?

What is 'internet'?

Expected that the server will cooperate

Domain login support early on NAS boxes

Patch Up Job

The authentication problems:

Client Authentication

Server Authentication

Data Integrity

Data Privacy

Patches up some of these problems

SMB Signing

Mutual authentication (but only in krb5)

Ignores others

No bulk data encryption (Data Privacy)

NTLM Authentication

Challenge

Connect

Response

Token

Server

PDC

BDC

Trusted DC

Chal+Resp

Chal+Resp

Chal+Resp

Chal+Resp

ACK

ACK

ACK

ACK

Many Ways to do it

Local Password Storage

LDAP Passwords (Samba's pdb_ldap)

Challenge

Connect

Response

Token

Server

Disk

Username

NT Hash

Challenge

Connect

Response

Token

Server

LDAP

Username

NT Hash

Many Ways to do it

'Pass through' authentication

Man in the Middle Attack

Challenge

Connect

Response

Token #2

Server

DC

Connect

Token #1

Challenge

Response

NT Domain Authentication

Achieves 'Single Sign on'

DC provides authentication

Separates file-server from the passwords

Presents challenges for security

Server must authenticate itself to the DC

Session key must be returned – securely

Groups etc must not be modified in transit

Uses DCE-RPC Named Pipes

Effectively a sub-protocol in this context

Many Ways to do it

NT Domains

Challenge

Connect

Response

Token

Server

PDC

Chal+Resp

ACK

+ Session Key

+ Full Name

+ Groups

+ ....

Connect

Open Netlogon

Req Chal

Auth2

Many Ways to do it

Challenge

Connect

Response

Token

Server

DC

Trusted DC

Chal+Resp

Chal+Resp

ACK

ACK

Trusted Domains

Never talk to a trusted DC directly

Kerberos 5 Authentication – Part 1 TGT and Server Ticket

Please send me a ticket-granting-ticket for

user “foo”(with proof I know foo's password)

Ok, here is a TGT for user “foo”

(encrypted with foo's password)

Please send me a service ticket for server “BAR”. Here's my TGT as proof I can ask this

Ok, here is a ticket for server “BAR”, with an authenticator encrypted in BAR's password

Kerberos KDC

Client

Contains master passwords for all users and servers (services).

Kerberos 5 Authentication -
Using the Server ticket

Request to logon to server “BAR” as user “foo”.

Here is the kerberos server ticket.

Server

“BAR”

Client

Logon successful or error.

More secure than the Microsoft proprietary NTLM and NTLMv2 protocols.

Depends on synchronised clocks.

Kerberos

Connect

Service Ticket

Mutual Auth

Server

KDC

Server never talks to a KDC directly

Far more efficient authentication

Pre Auth

TGT Request

Request Service Ticket

Kerberos and CIFS

Kerberos as per normal

GSSAPI layer

Tickets as per normal

May perform mutual authentication

Session Key:

Krb5 layer session key, despite GSSAPI

Generic Authentication

Authentication Problems:

Client Authentication

Server Authentication

Message Integrity (Signing)

Message Encryption (Sealing)

Session Key

Solve these problems once, and once only

Generic Authentication Layer

Common interface

Blob-based Authentication

Separation between application and authentication

Flexibility in underlying implementation

Generic Security APIs

GSSAPI

SPNEGO is a GSSAPI mech

SASL

SSPI (Microsoft's)

GENSEC (Samba4's)

There is nothing like building one to understand what it's really about :-)

SPNEGO

Simple and Protected NEGOtiation

Not actually protected...

Selects authentication scheme

Generic, but these are the mechs so far:

NTLMSSP

Kerberos

ASN.1

Generic APIs

Typical functions:

start_context(CTX **)

update(CTX *, BLOB *in, BLOB *out)

sign(CTX *, BLOB *in, BLOB *sig)

checksig(CTX *, BLOB *in, BLOB *sig)

crypt(CTX *, BLOB *in, BLOB *sig)

The exception:

session_key(CTX *, KEY *)

SSPI Generic Layer

Microsoft's Generic layer

Single place for

Export restrictions

Security Audits

Microsoft has private hooks

The protocol that SSPI produces does not match that the we get in CIFS or DCE-RPC exactly

GENSEC - Samba4

Provides:

GSSAPI (Krb5)

NTLMSSP

SCHANNEL

SPENGO (backed by recursion on GENSEC)

Start mech by:

OID

SASL Name

DCERPC Auth Type

Session keys

Breaking the Abstraction

You should not use nor need the session key

But in CIFS, you do!

History

Before NTLMSSP

No generic layer

Session key defined by NTLM

Now

Still have LSA, SAMR, SMB signing that need a known 'key' quantity.

SMB Signing

Used to prevent TCP session hijacking

Uses:

Session key

Incrementing Sequence number

MD5

Protects against:

Non-member servers pretending to be a member sever

But all member servers can impersonate each other

CIFS Session Keys

Kerberos:

KDC generates and supplies the key

NTLMSSP/NTLM:

derived from the hashes in the authentication protocol (bad)

client can propose a session key (better maybe ?)

Variable Length

SMB Signing

Uses MD5 for signature

Often the 'confounder' doesn't exist...

Password

Confounder

Session Key

Password

Confounder

Session Key

Client

Server

Comparison

Signature

SMB Packet

Signature

Sequence Number

SMB Signing – Packet

SMB Packet

Sig

SMB Packet

SN

Session Key

MD5

The MD5 signature replaces the sequence number in the packet sent on the wire.

SMB Signing in Reality

Isn't enabled is default

Win2003 seems to have changed this

Nobody uses it (at least not until now)

Performance hit

Published Spec

Typical – leaves out the corner cases

NTLMSSP implementation lacks 'entropy'

Key Exchange and NTLM2 help

Replay attacks possible

DCE-RPC and CIFS

Remote Procedure Calls

Make function calls over the network

Parameters become wire data, and then parameters again

Named Pipes

CIFS provides a transport

Authentication

CIFS-level authentication re-used

Used to validate CIFS-level Authentication

Secure Channel

Typically a single 'secure channel' between the member server and DC.

Challenge

Connect

Response

Token

Server

PDC

Chal+Resp

ACK

+ Session Key

+ Full Name

+ Groups

+ ....

Connect

Open Netlogon

Req Chal

Auth2

This data needs

to be secured

DCE-RPC Layers

DCE-RPC 'PDU's

Treated as a file stream in CIFS

Separate Authentication

(optional)

Secured

Optional sign/sign+seal

CIFS Packet

SMB Headers

Named Pipe Data

DCE-RPC

Header

Auth

Verifier

(Possibly Encrypted)
DCE-RPC Data

Secure Channel Operation

Opens Netlogon twice

Second Open uses NETSEC

64/128 bit sealing

RC4

64/128 bit checksum

MD5 + RC4

Checksum and
sequence
number is
encrypted

Server

PDC

Chal+Resp

ACK

+ Session Key

+ Full Name

+ Groups

+ ....

Open Netlogon

Req Chal

Auth3

Secured

Pipe

Open NL

NETSEC Encryption

Available as

'sign and seal'

'sign only'

Session Key

Machine Password

Server Challenge

Client Challenge

Clear Packet

Encrypted Packet

Sequence Number

NETSEC

Auth Verifier

Packet Digest

NTLMSSP

Generalized authentication

Same crypto, different wrappings

3 stage handshake

Many protocols:

CIFS

DCE-RPC

HTTP

IMAP

LDAP

...

Algorithms (NTLMSSP)

NDR

NTLMSSP is in 'Network Data Representation'

Authentication Algorithms

CRC32

Used in NLTMSSP signing

RC4

Used to verify the NTLMSSP signature

Used to seal packets

Original CIFS Authentication

Many varients:

Share/User Level security

LM

NTLM

NTLMv2

CIFS Clients to Servers

Never quite as simple...

Negprot

Server decides if it wants encrypted passwords

Session Setup

But only for LANMAN1 and above

Actual contents ignored if in 'share' level security.

No way to tell if you need a password at all

Not normally plaintext...

What About the Packets?

Negprot

Reply includes challenge

Session Setup

Request inclues password response(s)

Reply is error or includes VUID

Tree Connect

Needs VUID

Permits access

Protocol Level Oddities

CORE/COREPLUS

Plaintext only

Share-level only

LANMAN

Session setup

'Users' – access is no longer per-share

Encrypted passwords

CIFS NT1 Protocol Level

NT response

MD4 based

International

Case Sensitive

But Win9X doesn't use it

Allows NTLMv2

But its use is not negotiated...

Clients must still send NT and LM passwords

Questions?

Pluming New Depths with CIFS Authentication

CIFS Authentication, the good, the bad and the ugly

CIFS 2004 Conference Authenticatoin

2002-11-27T21:47:47