Detect MITM attacks and Secure your clients
The following code demonstrates a dynamic URL generator written in C# for use in ASP.NET, implemented as a static class method, and its corresponding parser module that singles out MITM attackers by detecting multiple IP address mismatches originating from the same IP address. To keep the code simple so that it makes sense easily, the dynamic URL is constructed by appending the client’s IP address to ‘http://FQDN/dynamic/’ exclusive of the dots (periods) in the dotted quad IP address and giving the resulting URL a .jpg file extension. Replace FQDN with a fully qualified domain name by which your IIS box is also accessible, but be sure to use a domain other than the one that serves the Web application. Do the same thing in reverse to deploy this same countermeasure as part of a Web application served from the FQDN so that the two domains depend on each other for DNS hijacking MITM automated detection.
This design variation is only the simplest of the potential embodiments of this automated DNS hijacking MITM countermeasure. It doesn’t provide a defense against a MITM that serves requests for .jpg files out of cache instead of relaying them on to the authentic HTTP server, but it demonstrates the countermeasure concept so that you can enhance the defense with your own server-side security policy. This minimal countermeasure design, as shown, does provide a defense against a MITM attack that has not itself been designed to detect and circumvent this variation of the countermeasure by selectively relaying requests from the client to the authentic server and cleansing client requests of any identifying dynamic elements. To eliminate all possible attacker circumvention of this automated DNS hijacking countermeasure requires a more complex server-side awareness of the countermeasure and its role in securing client sessions, including a security policy that says the server will not allow a client session to proceed until the dynamic URL issued to the client gets requested. In this case the only way for the attacker to circumvent this countermeasure is to hide, which means the attacker is forced to attack by hijack rather than MITM.
using System;
using System.Web;
using System.Security.Cryptography;
using System.IO;
using System.Collections;
namespace MITMCounterMeasure {
public class MITMCounterMeasureModule : System.Web.IHttpModule {
SortedList KnownClients = new SortedList(131072);
SortedList MITMSuspects = new SortedList(10240);
public void Init(HttpApplication context) {
context.AuthorizeRequest += new EventHandler(this.MITMDetect); }
public void Dispose() {}
public static String GenerateDynamicURL(String ClientIPAddress) {
String sURL = "http://FQDN/dynamic/";
sURL = sURL + ClientIPAddress.Replace(".",null) + ".jpg";
return(sURL); }
public void MITMDetect(object sender,EventArgs e) {
HttpApplication app = (HttpApplication)sender;
try { String addr = app.Request.UserHostAddress;
addr = addr.Replace(".",null);
if(MITMSuspects.Contains(addr)) {
throw(new Exception("MITM Suspect: Request Denied")); }
String urlpath = app.Request.Url.AbsolutePath;
int i = urlpath.IndexOf("/dynamic/");
if(i > -1) {
i = i + 9;
String s = urlpath.Substring(i,urlpath.IndexOf(".")-i);
String v = null;
if(!s.Equals(addr)) {
if(KnownClients.Contains(addr)) {
v = (String)KnownClients.GetByIndex(KnownClients.IndexOfKey(addr));
if(!v.Equals(s)) {
SortedList.Synchronized(MITMSuspects).Add(addr,DateTime.Now);
throw(new Exception("Second IP address mismatch different from first
mismatch: MITM suspect identified"));
}}
else {
SortedList.Synchronized(KnownClients).Add(addr,s);
}}
// send data to client; in this example the response is a JPEG image
app.Response.WriteFile("\\inetpub\\wwwroot\\image.jpg");
app.CompleteRequest();
}}
catch(Exception ex) {
app.Response.Write("<html><body><h1>Error Processing
Request</h1></body></html>");
app.CompleteRequest(); }
}}}
This code verifies that the client IP address matches the address encoded in the URL as an unauthorized proxy server detection countermeasure. This is the simplest of the possible multiple-domain anti-DNS-poisoning countermeasures enabled by virtue of the fact that changes to DNS cache always propagate unevenly from different authoritative DNS servers for different domains. Even if a DNS hijacker takes over the authoritative DNS servers for each domain used to accomplish this countermeasure, the attacker is unable to guarantee that the DNS poisoning will spread evenly throughout the network of subordinate DNS servers. That is, there will always be a period of time during which certain DNS servers on the network contain a mix of authentic DNS information for one or more of the hijacked domains and poisoned information for one or more of the hijacked domains. This time window represents an opportunity to detect the DNS hijacking and defend IIS against it. The amount of time in this window can be influenced, though not controlled precisely, through the Time To Live (TTL) setting in each domain’s authoritative DNS server.
ASP.NET provides an improved architecture for layering-in IIS code modules that participate in HTTP request processing. ASP.NET layered code modules are meant to replace the legacy ISAPI architecture, rescue IIS developers and IIS administrators from DLL Hell, and provide a solution that eliminates the difficulty of writing secure code in C/C++. The C# code shown in this section to implement the simplest potential DNS hijacking MITM countermeasure relies on the ASP.NET IHttpModule interface. It only works if you set up a file mapping for .jpg files in the web site application configuration that instructs IIS to use the ASP.NET script engine to process requests for all JPEG image files. When you build the code using the C# compiler, you will typically assign the code a strong name using the .NET Strong Name Utility (SN.EXE) and Assembly Linker (AL.EXE) and you must also deploy the IHttpModule to an ASP.NET-enabled server by modifying the machine.config file in the Microsoft.NET CONFIGURATION directory. Add the namespace and class name for the MITMCounterMeasureModule to the list of HttpModules as shown:
< httpModules> < add name="MITMCounterMeasure"
type="MITMCounterMeasure.MITMCounterMeasureModule,
MITMCounterMeasure"/>
< /httpModules>
A single IP address mismatch may be caused by an end user with a dynamic IP address whose IP address changes, but more than one mismatch relayed to IIS from the same IP address indicates, as shown in the parser source code, the presence of an unauthorized MITM. This means that the malicious MITM can hijack one client undetected but the second hijacking triggers detection and the automated countermeasure. If you’re worried about dialup users who use the same DHCP address pool ending up with the same IP address one after another in sequence, such that this source code would trigger a MITM defense against the second innocent end user whose dynamic IP address changed while using your server, you can increase the number of hijackings permitted per IP address. Alternately, you could implement a more comprehensive variation of this MITM countermeasure that keeps track of client sessions and authentication events in addition to IP addresses and uses extra information gathered about the context of the client request to avoid locking out any end users inappropriately.
About Author
Uma Mahesh
Author is working as an Architect in a reputed software company. He is having nearly 17+ Years of experience in web development using Microsoft Technologies.