Application Impersonation using ASP.NET 4.5 Routing.

“I’ll handle it.” – Olivia Pope.

I was doing a development project recently, where I needed to impersonate a web service used by a device on my home network – allowing me to intercept/redirect the traffic from the home device. The device was attempting to connect to a web service to send and receive data and I naturally wanted to stop that – I’ll explain why in a separate post.

In order to redirect the web service requests from my home device, I needed to do three things:

  1. Create a new zone/record on my home DNS server so that the home device resolved the target web server hostname to the IP address of my internal web application server.
  2. Create a new web site on my internal Microsoft IIS web application server, and set the host header name to match the target web server hostname.
  3. Create an ASP.NET 4.5 application that used routing, to enable me to route many URLs to a small number of page handlers.

Here’s a diagram showing step 1 and 2. The local DNS server provides the IP address of my home web server to the home device, and the home device connects to my home web server with the original URL.

URL Interception Black

That’s the first problem solved. The home device is unaware that it’s actually sending web traffic to my home web server rather than the intended destination. Now we need to look at how IIS behaves when that traffic comes in.

I needed to ensure that an ASP.NET web form would execute for the requests coming in from the device, even though I had no control over the actual URL being requested by the device. This is where ASP.NET Routing comes in handy. I can configure the application to listen for specific URLs, and then redirect those to specific web forms for handling.

For example.

Let’s say that the home device was looking for http://www.targetwebserver.com/page.htm. I could create a routing rule that used WebForm1.aspx to process the request for /page.htm.

We can actually get even smarter than that. Imagine now that the device is actually sending relevant data in the URL itself – and therefore the URL is now semi-dynamic. In this example, the home device was looking for http://www.targetwebserver.com/v1/2304235523/data. I not only needed to intercept that request even though the number in the URL could change, but I also needed to capture that number as well.

The first thing to do was to create a Global.Asax global application class for my web application. Note, this application was actually created in the root directory of the web site (http://www.targetwebserver.com/).

    void Application_Start(object sender, EventArgs e)
    {
        RegisterRoutes(RouteTable.Routes);
    }

    public static void RegisterRoutes(RouteCollection routes)
    {
        routes.MapPageRoute("Command", "{version}/{thenumber}/data",
            "~/CommandHandler.Aspx");
    }

The MapPageRoute method allowed me to define the URL template I was looking to match, specify which were variable parameters – version and thenumber, and redirect requests that matched that URL to CommandHandler.aspx.

Now let’s look at CommandHandler.aspx.

    protected void Page_Load(object sender, EventArgs e)
    {
        string strVersion = Page.RouteData.Values["version"];
        string strTheNumber = Page.RouteData.Values["thenumber"];

        // Generate page/response.

        ...
    }

With that web form completed, any request to that URL was now handled by the CommandHandler.aspx file, which then extracted the required information from the URL.

If you’re wondering what that web form actually did, it took the info it needed, talked to a back-end service of mine, and then provided a response to the home device. Here’s an example of that.

    protected void Page_Load(object sender, EventArgs e)
    {
        ...

        // Generate page/response.

        // Send additional HTTP header in response.
        Response.AddHeader("Access-Control-Allow-Origin", "*");

        // Change the response content type to JSON.
        Response.ContentType = "application/json";

        // Send the data.
        Response.Write("{\"result\":\"ok\"}");
    }

The .aspx file itself didn’t have any content other than the Page directive (the first line). The rest of the content was generated in Page_Load as you can see in the example. I added an additional HTTP header to the response that I knew the home device was looking for, I changed the content type from html to JSON (as expected by the home device), and then finally I wrote the response.

Overall it was a fairly simple solution that let me build the infrastructure to impersonate a web service on the internet. Determining what actual application logic to put in was a bit more of a challenge, but that’s part of the fun of reverse engineering someone else’s application.

You can find more information from Microsoft’s site here. It’s a handy technique for normal web sites and for when you’re intercepting traffic for another application.

~ Mike

2 thoughts on “Application Impersonation using ASP.NET 4.5 Routing.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s