Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am developing with an ASP.NET application that uses Windows Authentication. I have setup the web.config file to deny all unauthenticated users, and only allow users from a certain role.

Using Fiddler, I am able to fuzz my session ID, replay a request, and still get a 200 OK response... apparently without any renegotiation whatsoever.

I am under the impression that the credentials for NTLM based authentication are associated with the underlying TCP connection. Firstly, is this true? Is this a real security threat? If so, what steps would an individual have to take to hijack such a connection in order to assume another user's identity?

share|improve this question
up vote 1 down vote accepted

Internet Explorer can perform transparent NTLM authentication. I haven't used Fiddler significantly, and I don't know if it shows you that part of the conversation or not. My guess is that your browser is transparently authenticating you, but I can't say for sure.

You might try sniffing the browser / server traffic w/ Wireshark or such to see if that's happening. NTLM authentiation between the client and IIS is done in-band in the TCP connection, not as part of some out-of-band process associated with the start-up of the TCP connection. If it's there, you'll see it.

You're not seeing TCP hijacking. You're either seeing the result of a transparent authentication or your application isn't actually requiring authentication.

To speak directly to TCP hijacking (TCP sequencing, etc): To hijack a TCP connection an attacker must predict the sequence and acknowledgement numbers and forge traffic as a client. Typically this ends up being a blind attack because the replies from the server computer end up going back to the real client. (If you combine TCP sequencing with ARP cache poisoning you can get a two-way hijack going, but that typically limits the attack to an attacker on a machine on the same subnet as the client or server.) TCP sequencing of live connections between clients and servers over the Internet is difficult unless the attacker has compromised a choke point between the client and server.

Blind TCP sequencing attacks sourcing a connection to exploit trust in a protocol (Kevin Mitnick's attack against Shimomura's workstation to drop an .rhosts file on it) is made possible by guessable initial sequence numbers, and is a bit of a different animal than straight hijacking.

SSL, IPSEC, or other encrypted tunneling protocols are your friend for stopping TCP hijacking. In general, even if you're doing authentication with a non-cleartext challenge/response system (like NTLM, NTLMv2, etc), the TCP connection is still vulnerable to hijacking.

share|improve this answer
+1 - Fiddler is application level so I can only see HTTP requests, and the NTLM token is there on initial requests to a page which is why (in a "Keep-Alive" connection) I believe the credentials were somehow stored for each individual TCP connection to the server (as opposed to each HTTP request). On production, SSL is enabled so it helps to know that will help prevent hijacking. Looking at the TCP stream in Wireshark still doesn't appear to show any negotiation as far as I can tell, though. – John Rasch Jun 25 '09 at 20:16
There's your answer: You're using a keep-alive, and the authentication is being used for every request in that TCP connection. That's normal HTTP behaviour. I guess I misread you asking if the authentication was happening as part of the TCP connection setup. – Evan Anderson Jun 25 '09 at 22:05

To answer your last question, arp-poisoning with Cain is a relatively easy and trivial thing to accomplish. Having said that, it does require one of two things for that to happen, physical access to your network or wireless access to your network.

Once arp-poisoned and Cain has gathered sufficient data, NTLM hashes can be broken right inside Cain. Of course, the stronger the password, the longer it will take.

share|improve this answer
+1 - Thanks for the tool, when I can download it at home I will take a look at what it can do. – John Rasch Jun 25 '09 at 20:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.