Introduction to application reverse engineering : The CWA (Communicator Web Access) R2 case.

[アーティクル]
08/01/2009

By Lucimara Desiderá (MS Consultant, São Paulo) & Frédéric ESNOUF (MS Pre-sales IDA, Paris)

Introduction

Intelligent Application Gateway is a very powerful remote access solution which provides a wide range of technologies such as VPN, VPN/SSL, Port forwarding and Reverse Proxy for application publishing. It also provides endpoint access controls including mechanisms for client authentication, single-sign-on and a myriad of access policies. Next Generation, named Forefront Unified Access Gateway (UAG), will offer even more technologies, including Windows 7 SSTP and Windows 2008 R2 Direct Access.

With IAG, all the Web Applications are published via the reverse proxy mechanism. This makes the platform able to see what data is transported and take “actions” when needed, for example, rewrite HTML links in the page transforming internal names, such as https://finance.internal.private/logo.Gif, into internet names such as https://finance.mypublicname.com/logo.Gif)

However, “Web Applications” have evolved and are not composed of simply static “HTML” pages anymore. Most of the Web applications contain executable code which produces changes on content/behavior at execution time. Therefore, publishing such web applications could fail when using a reverse proxy (whatever kind of type/brand). Reverse proxies can successfully rewrite HTML links in a page, but what if links come on non-expected places (code)?

What is the technical problem here? Well, if in this page you have a piece of code, this means that the “rendering” of this page, done by the browser on the client-side, will be partially generated by this code, and this code could in fact contain hard coded variables that refer to the internal names. The result is that once the page is rendered by the browser (remember, user is connected on the internet, out of the company network) some of the links remain “internal links”, causing the browser to fail to connect. Sometimes, errors will appear when the user will click a link. But most of the time, it will generate random errors depending on the framework used by the developer.

What can be done to fix that? Most of the reverse proxies do not have advanced mechanism to fix that. Their “engine” is coded to change only HTML code, and extending that is usually proposed via the SDK and requires C++ advanced skills. With IAG, the “engine” to do this job is already available for IT Pros, and it is called “ApplicationWrapping/SRA”. With this, you can pretty much change everything in the flow of data: header, HTML, javascript, java, etc. Anything can be “changed” for any kind of reason. This engine just ask a configuration file, based on XML, and using a macro language described in the IAG advanced admin guide.

Recently, Microsoft released the Office Communicator Web Access R2 (CWA). Unfortunately, publishing this application causes the behavior we presented above. For a reason we don’t know (but we will know why in this post), CWA R2 was not working through IAG.

Lucimara and Frédéric had the opportunity to collaborate on this case, and fix the problem. This article is base on this experience and course we will explain how to fix this problem. Additionally, we want to share with you the methodology we used, and the actions taken in IAG.

The symptom

When we started testing the CWA application published through IAG we noticed the strange behavior shown below: first some missing pictures on the login page and then, an error code 1-0-400:

The methodology

The methodology to analyze and fix this kind of behavior is in fact simple. We need to capture the HTTP traffic and look at the transaction. By looking at the HTTP traffic we need to identify:

· what the problem is and where it occurs,

· the reason why it is breaking,

· and then, how to fix that using IAG “Appwrap/SRA” engines.

The role of IAG here will be to change “things” causing the problem, but our role (IT Pros) is to tell IAG what to change, and that is the “human” job in this problem.

We definitely advise you to use HTTP analyzers (rather than network analyzers such as Wireshark or Netmon) to capture such traffic. Tools such as “HttpWatch” or Fiddler are excellent.

So now that we know what to do, let’s reproduce the problem, and capture the traffic.

The problem

In this example, we used HttpWatch to capture the HTTP traffic. By looking at the capture, we can quickly identify a problem:

On this screenshot, you can see that the first five HTTP requests (in the yellow square numbered “1”) worked fine. We can verify that because in the result column, those GET requests generated HTTP status code “200”, which means success.

At a certain moment (request 6) we can see that the requests resulted in error (in this case it is a message regarding name resolution problems).If you look at the HTTP requests that fails (in red square numbered “2”), you can see that the URL requested by IE is not the “internet” name anymore (the one used to reach IAG), but the “internal” application URL. So now that we know the problem, let’s try to understand exactly why it happens.

Searching for the cause

The first error occurs when IE tries to download a file called “detailbar_up_hover.gif”. We can clearly see that in the URL.

So what we tried to do to identify the source of the problem is to locate the “thing” that previously told IE to download this file, which could be in Web either an HTML tag (but we know that reverse proxy can correctly re-write such link) or a piece of code downloaded previously.

What we do here is just search (using the HttpWatch “find” tool) the word “detailbar_up_hover.gif“, from the failing request in the upward direction.

With this approach, we can find a request and a response containing such “string”. Here is what we get :

Request :

GET /whalecom754aec20c6043b78fe481a84322ae50e153495e7/whalecom1/cwa/client/Resource.aspx?param=1-2-13825|2-2-5|4-2-17409 HTTP/1.1

If we look this time at the response to this request (which is pretty much “give me the content of resource.aspx file”), we can find some javascript code containing variables that contains strings to internal names. This is not good!

Why reverse proxy don’t change that? Just because they are programmed to analyze HTML code only, and look only for “HREF” Tags. It is quite impossible to “extend” a reverse proxy to do better than this (it usually requires C++ code, and a lot of work).

Here is an extract of the “resource.aspx” page, with the code causing our problem :

var L_Menu_UpArrow = "https://ocs-cwa.fabrikam.com/cwa/Client/3.5.6907.0000/Loc/Image/detailbar_up_hover.gif";var L_Menu_DownArrow = "https://ocs-cwa.fabrikam.com/cwa/Client/3.5.6907.0000/Loc/Image/detailbar_down_hover.gif";var L_Presence_FreeImg = "https://ocs-cwa.fabrikam.com/cwa/Client/3.5.6907.0000/Loc/Image/presence_icons/online.png";var L_Presence_IdleFreeImg = "https://ocs-cwa.fabrikam.com/cwa/Client/3.5.6907.0000/Loc/Image/presence_icons/idle.png";var L_Presence_BusyImg = "https://ocs-cwa.fabrikam.com/cwa/Client/3.5.6907.0000/Loc/Image/presence_icons/busy.png";var L_Presence_IdleBusyImg = "https://ocs-cwa.fabrikam.com/cwa/Client/3.5.6907.0000/Loc/Image/presence_icons/idlebusy.png" <END EXTRACT>

So now we know the cause of the problem: CWA R2 is using javascript that generates HTTP GET to the application, and IAG does not re-write these links by default. And then, what we need to do is to instruct IAG to correctly replace these strings, which will generate correct links after javascript execution on the client-side.

How to fix that

We are now entering the final step of the solution. As we said before, IAG contains an “engine” capable of modifying anything. We just need to tell it what to do, by means of his language.

In this CWA R2 scenario we will ask to do a basic “search and replace” of the HTML code when the request is “ GET Resource.aspx “.

To do so, we need to create a configuration file for the IAG portal in the TRUNK publishing CWA R2. If you are not familiar with such config, it may seem a bit complex at the first time, but as soon as you do it once, then later is easier.

Here is the step by step procedure to configure IAG:

1) Go to C:\Whale-Com\e-Gap\von\conf\WebSites\<Portal>\Conf directory

2) Create a “CustomUpdate” directory. We will place our configuration file here.

3) Create a file named “WhlFiltAppWrap_HTTPS.xml” (this names means that we configure the ApplicationWraping Engine, for HTTPs (client/Portal) connections).

4) Copy the text below in this file :

<APP_WRAP ver="3.0" id="RemoteAccess_HTTPS.xml">

<DATA_CHANGE>

<URL case_sensitive="false">.*/Resource\.aspx.*</URL>

<SAR>

<SEARCH encoding="base64">BASE64 ENCONDING for the internal name</SEARCH>

<REPLACE encoding="base64" using_variables="false">BASE64 ENCONDING for the external name </REPLACE>

</SAR>

</DATA_CHANGE>

</MANIPULATION>

</APP_WRAP>

IMPORTANT: Here there are a few things that you have to update:

· Put your URL for the internal name in the “Search”

· Put your URL for the internet name in the “Replace”. This URL has to contain the external FQDN, including the “HOST ADDRESS TRANSLATION (HAT)” of the CWA R2 application (ex: whalecom754ae…).

· Once these values are ok, you need to encode them in “BASE64” (you can use an online tool like https://webnet77.com/cgi-bin/helpers/base-64.pl to proceed that)

After the appropriate substitutions, your code will look like this:

Now you can save the file. A good tip would be to double click this XML file. Internet explorer will “render” it and validate if the file is correct (from a pure XML point of view). Otherwise, IAG will not use it, and will not warn you. It will just not work.

Once the file is good and on place, you need to activate the IAG configuration. Don’t forget to mark the checkbox “Apply changes made to external configuration settings” otherwise IAG will not treat the customization.

As you can see, the structure of the configuration is based on XML. Tags such as “App_wrap”,”Manipulation”, etc… are in fact the IAG/ApplicationWrapping macro language and is described in detailed in the IAG advanced administration guide.

Note: here we used appwrap technology. Another one called SRA could be also used since it has a specific function called ADD_SIGNATURE that can add the HAT part of the application in the URL (Versus hard coded one with appwrap), making the solution more generic. We wanted to make this article simple, so we will investigate SRA in another article.

Conclusion

By publishing a Web Application via a reverse proxy approach (versus network/tunneling approach), we can provide a lot of security features. It is especially important when we publish applications that contain very valuable data that we want to protect (against cyber criminals)

IAG provide all the reverse proxy features, and also a strong re-writing engine called AppWrap that can change everything in the HTTP traffic. This makes sure that applications breaking in reverse proxy will work as expected.

CWA R2 was a very nice example, because it was easy to fix. Some application can be more complex to fix, but the basic methodology remains the same.

Comments

Anonymous
January 01, 2003
Ping me offline : fesnouf@microsoft.com
Anonymous
August 24, 2009
Hi ! Thank you for your post. I've followed your step but I still have an error : 1‑0‑488. Do you know something about it? Thanks :)

次の方法で共有