Iis – Avoiding 401 response for each request using NTLM

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.

This appears to be a duplicate of https://stackoverflow.com/questions/434272/iis7-overrides-customerrors-when-setting-response-statuscode , but I'm too new on Server Fault to flag this.

My take: I had a similar problem when using Mediawiki on an IIS server box.

When you browse to a non-existing page in Mediawiki. It sends back a special wiki page that says that the page doesn't exist and allows you to create it. However this page is sent with a status of 404.

On a standard IIS server IIS will automatically overwrite this with a custom error page to users NOT on the local host, but sends detailed error messages to those that are. In practice "detailed error messages" means letting through the original error page, whether it be custom in your application or generated by ASP.NET because of a coding error.

My method was to enable detailed error messages for both local and remote users in the Error Pages > Feature settings. However this will also allow remote users to see detailed ASP error messages should they occur, which may help a malicious user compromise your security.

Other options are given as answers to the linked question, including better ones that may not have a security implication. Another option in this case is to not return a 401 status code, but just a normal 200 code with your custom page. This sacrifices REST principles for ease of development.

Note that the fact that detailed error messages are shown for the local user, but not remote users, may explain why your solutions works during local testing but not when deployed.