Tech Off Thread

15 posts

Spoofing authentication

Back to Forum: Tech Off
  • User profile image
    themaffeo

    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).

  • User profile image
    TristanK

    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.

  • User profile image
    GooberDLX

    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

  • User profile image
    themaffeo

    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!

  • User profile image
    TristanK

    Looking at the docs on that page for AUTH_USER:

    "
    The name of the user as it is derived from the authorization header sent by the client, before the user name is mapped to a Windows account. This variable is no different from REMOTE_USER. If you have an authentication filter installed on your Web server that maps incoming users to accounts, use LOGON_USER to view the mapped user name.
    "

    If Cold Fusion is running as an IIS filter, then it's reasonable to assume that LOGON_USER might be available. I'm not sure how different LOGON_USER could be from AUTH_USER (sorry, this is a really dingy past here), so ignore what I said and rely on the docs! Sorry for any confusion.

  • User profile image
    Lowrez

    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?

  • User profile image
    gmiley

    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.

  • User profile image
    GooberDLX

    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

  • User profile image
    prog_dotnet

    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.

  • User profile image
    Lowrez

    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?

  • User profile image
    Lowrez

    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. Smiley

  • User profile image
    GooberDLX

    Smiley

    Jake

  • User profile image
    prog_dotnet

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

    (ntlm)

    1. The user types in a username, password, and a domain name when logging in to the client machine.

    2. The client creates a hash of this password and discards the original.

    3. The client sends the server the plaintext username.

    4. The server sends a 16-bit nonce to the client.

    5. The client encrypts this nonce along with the hash of the user's password and sends it to the server.

    6. The server then sends the username, the nonce, and the client's response to a domain controller.

    7. The domain controller encrypts the nonce along with its own hash of the user's password, and it compares the value to the one sent by the server.

    8. If the values match, the domain controller notifies the server that authentication is successful.

    9. If the values do not match or no username matches, the domain controller notifies the server, which then sends that message to the client. The client's browser then prompts the user for login information.



    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

  • User profile image
    prog_dotnet

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


  • User profile image
    Lowrez

    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. Tongue Out

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.