Defeating Encryption in Some Thick Clients

balaji
By balaji

October 15, 2008

While testing thick client applications we sometimes encounter the client encrypting pieces of the request. At such times, many of our variable manipulation attacks are foiled. To overcome this barrier, there are several techniques. Here's one of the methods we tried for a recent thick client application test.

While testing thick client applications we sometimes encounter the client encrypting pieces of the request. At such times, many of our variable manipulation attacks are foiled. To overcome this barrier, there are several techniques. Here's one of the methods we tried for a recent thick client application test.

Usually such applications call functions in DLLs to implement the encryption. This application used java classes. We first found a config file having information about the main class, the jar files used etc. We couldn't locate the main class, but we found there were quite a few jar files in the application.

We extracted all the files inside all the jar files and decompiled the class files to see their code. We looked around and found the classes that implemented the encryption. As a quick and dirty hack, we simply removed them. Then we recompiled the rest of the classes into jar files and ran the application like usual.

As a side note, here's how to create a jar file:

  1. Put all the sub-directories and classes in a folder [say abc] which you want to convert into a jar file.
  2. Add the path of jar.exe in environment variables.
  3. Navigate to the location where your folder abc is placed.
  4. Run this command " jar cvf abc.jar abc/ "

The name of the jar file should be kept as the original jar file name. So remember copy the original jar file somewhere safe to retrieve it back later, before you actually start making changes.

For jar cmd help type jar --help at cmd prompt.

For adding the path of jar.exe in environment variables, go to my computer> properties> advanced> environment variables> path> edit Add the path after a semicolon at the right most end of the variable value field.

However the application didn't respond. It was checking the size of the jar file. But the size of the jar file had reduced since we deleted some of the class files.

So we tried something else.

We just added some text files into the jar files to make its size back to the original. [Yes we again had to compile all the files into the jar file].

When we got the size of the jar file as desired the application was rerun to see if there was a response. This time the server response was received, however we were not able to login even using the valid credentials.

That's to be expected. After all, the server is expecting the incoming data to be encrypted and we have sent the data unencrypted.

So we wrote a simple program that called the encryption logic. We reused the same classes the thick client originally used for the encryption. We could now get the cipher text for the request we chose.

Then we started again. With the neutered thick client we sent a request to the server; we intercepted this plain text request with Echo Mirage, modified parts of the request and then re-encrypted it with our simple encryption program. We then fed the new (encrypted) values into the request and forwarded it to the server. And, the server accepted our request! :)

This is a fairly simple technique, so let's review it once more:

  1. Strip off the encryption classes (we were lucky, sometimes, you might have to comment out the calls to the encryption logic)
  2. Pad the jar file if the size of the jar is being checked
  3. Write a simple encryption program that invokes the encryption logic - we will later use this to encrypt the data we tamper
  4. With the neutered client, connect to the server
  5. Intercept the request and replace parts of the original data, with an encrypted version of the modified request
  6. Forward the tampered request to the server

Tags: Technical

About

balaji