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