Spoofing ​authenticat​ion

I've got an interesting question regarding integrated windows authentication.

 

I have a web based application that uses the auth_user http header variable to perform some lookups in a database – lookups that return information that only that user should use. (the sql pseudo code goes something to the effect of select * from tblName where uniqueNTLogon = auth_user)

 

The question I have is regarding spoofing.  I know HTTP headers are susceptible to having data in them spoofed – so the concern would be about someone passing in a different username in the auth_user variable, hence seeing data they shouldn’t.

 

HOWEVER, since we’re using Integrated Authentication – it’s my understanding that on each http requeset made of the server, the credentials of the requesting machine are re-authenticated based on some hashed data.  This leads me to believe that if someone change the auth_user variable, they would fail to authenticate.

 

So which is the case? Is spoofing possible?

 

Notes  1) I’m not (unfortunately) using .net for this specific app (cold fusion).

Can't speak to Cold Fusion, but from the dingy recesses of my web programming past, I seem to remember AUTH_USER being an ASP server variable, not an HTTP variable.

In ASP terms, AUTH_USER is the username of the context you're running in, and by the time you've seen it, authentication has already succeeded for that user.

When using NTLM/Integrated Windows, hash values are sent to the server, there's no cleartext username exchanged, so it's non-trivial to replace the Authorization header, which I think you're confusing with AUTH_USER.

Actually.. USER_AUTH is a Request header sent by the client... Usually it has to be accompianied by USER_PASS(WORD) too! .. which you technically SHOULD be able to spoof due to the way a browser works, even using SSL the browser still passes USER_AUTH, USER_PATH plain text.. and if a browser were to authenticate using Basic Authentication .. then it has to happen that way...

Each server (IIS, Apache, etc) holds user credentials differently.. for example, Forms Authentication in ASP.Net lets you use an encrypted client side cookie..

Sort of like email spoofing, its just the way it is..

Jake

Hmmm,  thanks for the clarification!

I think the key phrase here is "Authorization Header" as opposed to the HTTP header.

What was throwing me was a line from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iissdk/iis/servervariables.asp
where it says "Some server variables get their information from HTTP headers. It is recommended that you distrust..."  The emphasis should be on 'Some'.

Also, If i'm reading the documentation right, I should use the 'LOGON_USER' variable, because supposedly that will only be filled after authenticating - since its the 'mapped' username.

Thanks!

GooberDLX wrote:

Actually.. USER_AUTH is a Request header sent by the client... Usually it has to be accompianied by USER_PASS(WORD) too! .. which you technically SHOULD be able to spoof due to the way a browser works, even using SSL the browser still passes USER_AUTH, USER_PATH plain text.. and if a browser were to authenticate using Basic Authentication .. then it has to happen that way...

I'm curious where you are getting this from.  Neither USER_AUTH nor USER_PATH are part of the HTTP protocol.  Perhaps you don't mean request header in the HTTP sense, but something that is part of a Windows toolkit?

Check out Achilles and Fiddler (http://www.fiddlertool.com/fiddler/version.asp).

I have Achilles at home, but I tried going to their site this morning and it seems to be down. www.insecure.com has a good listing of utilities you can check out.

Lowrez wrote:

GooberDLX wrote: Actually.. USER_AUTH is a Request header sent by the client... Usually it has to be accompianied by USER_PASS(WORD) too! .. which you technically SHOULD be able to spoof due to the way a browser works, even using SSL the browser still passes USER_AUTH, USER_PATH plain text.. and if a browser were to authenticate using Basic Authentication .. then it has to happen that way...

I'm curious where you are getting this from.  Neither USER_AUTH nor USER_PATH are part of the HTTP protocol.  Perhaps you don't mean request header in the HTTP sense, but something that is part of a Windows toolkit?

I was always under the impression that it was a request header that sends the authentication information. How else would a server ask for a user name and password?

Jake

Integrated Windows authentication is the most secure way of authenticating users, and uses NTLM or Kerberos, depending on which version of Windows you are running and which mode your Windows domain is running in. As such, Integrated Windows authentication can only be used by domain users, and is typically used for securely accessing corporate intranets.

NTLM or Nt Lan manager, is implementet over the lm authentication protocol.
THe os stores ntlm passwords using ntlm owf, (md4 hash function)
NTLM from nt 4.0 with sp4 --> requires that the clocks of client/server is within 30 minutes of each other. v2 also uses keyspace for password derived 128 bits keys, and enhanced session secuirty can be used.

Kerberos is compliant with rfc 1510 and have several benefits ( mutual authentication and secure transmission)
and also...if the url contains a period, IIS assumes u are not on the internal network, and presents the user with a logon box.

prog_dotnet wrote:

if the url contains a period, IIS assumes u are not on the internal network, and presents the user with a logon box.

For clarification, IE would determine if and when a logon box is presented to the user.  IIS has no concept of what the URL was as entered in the user's browser.  However, I haven't found what you've said to be true.  From my field research, IE always calls the authentication routines with NULL/NULL for username and password once before prompting the user.  What versions of IE have you seen different behavior with?

GooberDLX wrote:

I was always under the impression that it was a request header that sends the authentication information. How else would a server ask for a user name and password?
Jake

Ok, that explains where the miscommunication came from.  I was thinking strickly about the HTTP protocol which doesn't define anything about usernames or passwords.  It only defines header types like 'WWW-Authenticate' and 'Proxy-Authenticate', but makes little mention of what they should contain.  Basic and digest authentication are defined in their own RFCs and constain rules for usernames and passwords, but NTLM isn't in any RFC I'm aware of.  From my analysis, it contains the client computer name, the user, the challenge hash, but nothing else.  Things like USER_PATH have to come from the authenticating server.

I'm not a 'web developer' in the sense of making server applications, I'm a 'web developer' in that I write implementations of HTTP and related protocols in order to test the system.  Different perspective, different terminology.

Jake

I have noticed this in IE 6.0. I actually think we are both right...

(ntlm)

When multiple authentication schemes are in use, IIS and the client’s browser will prefer certain authentication schemes over others. It attempts to use the authentication schemes in the following order:

• If Anonymous authentication is enabled, it is always attempted first. If Anonymous authentication fails or is disabled, one of the authenticated access methods is used.

• First, Integrated Windows authentication is tried if enabled and supported by the browser.

• If Integrated Windows authentication is not available, Digest or Advanced Digest authentication is used if enabled and supported.

• Finally, Basic authentication is used as a last resort.

You may have noticed that .NET Passport authentication is not listed. That’s the odd member of the bunch. If .NET Passport authentication is enabled, it disables all other forms of authenticated access (although Anonymous is still available).

Source:
II6 The Complete Reference
McGraw-Hill/Osborne
ISBN:0072224959

Here is what I think:
you enable integrated security and diables anonymous access. 
You then hit the site outside the network...

The first metod..anonymous access wil fail since one has disabled it

Second; integrated security is tried, but you are outside the domain bounderies, and it will fail

Third: as for the same reacon as above, digest and advanced authentiation will also fail. 

Forth: basic authentication kics in and transmitts the username and password in in clear text...

Basic authentication is built into the HTTP specification (lame security) but you can solve the problem by using SSL to encrypt all the traffic..

prog_dotnet,

What you've written/quoted is pretty much what I've seen.  When I said NULL/NULL for username and password, I should have made it clear that is only what gets passed into the client's auth routine.  That's the handle for "current security context".  Not only does it work if you've logged into the domain, but if you are outside of a domain, but you've mapped a drive against a domain server with another username/password it will try that as well.

I haven't tried to implement the .NET passport authentication yet.  I suspect the sales force will start pushing for it in about six months.