Dissecting the GoDaddy email notifier - Part 3

It’s been sometime since I made a post and that kinda sucks. I’ve been a bit swamped with work and have not had any real time to do my own stuff. Presently out in Cairo. Pyramids are phun.

You must be wondering why the hell I chose OllyDbg to make a simple hex edit in the previous post. The truth is, I was using it to try and study at exactly what point the SSL protocol is chosen and I found it at 0×414356.



By changing the CMP operation as in the picture above with 0×2E instead of 0×00, I can get the client to select plain old HTTP to speak to the main server. This is good, because I can now look at all the Web Service calls it makes and hopefully try to write a Linux version.
One other reason I chose OllyDbg is to study what the client actually does. My next quest is to study where my credentials are stored. Since this is Windows, I figure the first place to look would be the registry. By sniffing around the “string references” of the client, I did notice a specific registry key which is referenced: “HKEY_CURRENT_USER\Software\Starfield\WBEN\Settings”
 
Examining this registry key with regedit, I see the following:



That looks interesting. If I count the characters, it equates to the exact number for both my email address and password*. This means that their encryption algorithm generates fixed length cipher text. This most likely means that they’re using a substitution algorithm. Tsk, tsk, tsk. Substitution algorithms rely on some form of calculation (if any) and lookup in order to generate cipher text. Again, by looking at the encrypted strings, it is possible to determine the fact that a calculation involving the string length is also done. How do I deduce this? By looking at the last two characters in my email address (d1). They are both “qq” for “om” the last two letters in “.com”. This means that both “o” and “m” are equal to “q”. Not possible in direct lookups with calculation.

Another good thing is the fact that I know the credentials are stored in the registry. This shortens my hunt significantly because I only have to trace any specific registry calls to find out where the Encryption/Decryption algorithms are lurking. If I trace any references or calls to the specific registry key, then I will most likely find where the algorithms exist.

Using the “search for all string references” in Olly, I try to pull up all the calls to “HKEY_CURRENT_USER\Software\Starfield\WBEN\Settings”. I end up with this list:



The column “Called from” is what I’m interested in. This list contains all the addresses where the call to this registry key is made. I now have to follow each one and see if there is a “RegistrySetValue” call made. I look through each call one by one until I stumble upon this one:



It’s interesting because of the entry I have highlighted. This Unicode “d1” that’s on the stack is the registry entry for my email address. I follow this one to see where it goes and wind up discovering both the encryption and decryption algorithm. I will list them in the next part of this series. I think this post is dragging on long enough and I think it is about time I wrap it up. I will do just that in the next post and save everyone a lot of misery. I have successfully reversed the encryption/decryption algorithm and will post the python source code in my next post.

Dissecting the GoDaddy email notifier - Part 2

Welcome back. In our last installment, we had just figured out that the GoDaddy Email notifier uses SSL to communicate with the server. Today, I will look at ways of trying to bypass this and sniff traffic in order to figure out how the client communicates with the server.

Like I described in my previous post, I hooked up an stunnel/replug proxy chain to try and decrypt traffic, sniff it, and encrypt the traffic back on its way to the server. I first setup stunnel in both daemon and client modes. Here is a description of each:

Daemon mode. This instance of stunnel will listen on localhost:443 and forward traffic to localhost:8888 all over SSL.

sheran@azazel:~$ sudo stunnel -d 443 -r localhost:8888

Client mode. This instance will listen in non-SSL mode on port 8889 and re-establish the connection in SSL mode to the server. (When sniffing traffic, the DNS lookup for the notifier was noted. It looks up email.secureserver.net)

sheran@azazel:~$ sudo stunnel -c -d 8889 -r email.secureserver.net:443

How do we plug the hole in the middle? Simple, use replug found in BlackBag. Here's how:

sheran@azazel:~$ bkb replug localhost:8889@8888

This will start replug and listen on localhost:8888. Whatever it listens to on this port it will forward down to localhost:8889. The way traffic flows will be similar to this:

Client ---> localhost:443 (stunnel) ---> localhost:8888 (replug) ---> localhost:8889 (stunnel) ---> email.secureserver.net:443

Now for the client to think it's talking to an authentic server, I need to replicate the server certificate as well. This is not going to be an easy task since I don't own a CA; especially not the one that issues GoDaddy's certificates. So I do the next best thing and create a self-signed certificate almost identical to the GoDaddy certificate (weirder things have worked for me in the past). No dice. The client notifier program refuses to negotiate SSL with my first instance of stunnel. Shit.

Since this is not going to be as simple as I thought, I will have to resort to the next best thing: disassemble the notifier executable and try to patch it to talk non-SSL. So I fire up my favorite disassembler OllyDbg and try to locate any strings in the executable to give me a clue as to where the connection is made.

Well, here's something. Looking through strings (Right-click->Search for->All Referenced Strings) gives me several entries to a string reference called "http://" and "https://". I wonder if changing "https://" to "http://" will have any effect. Let's see:



In the "Strings window", right click and do a "Follow in Disassembler"; then when you're in the disassembler window, right click on the line with the "https://" and do a "Follow in Dump"->"Immediate Constant"



This should then bring the string up on the lower left window where you can change the "https://" entry to "http://". Then, right-click, choose "Copy to Executable", right-click on the window that opens up and select "Save File". Save it as another name and try it out for yourself. Now you can see all the traffic flowing between the client and server on Wireshark.

At this point, you will notice that GoDaddy's email notifier uses SOAP to transfer XML messages to and from the server. The URL is https://email.secureserver.net/soap/public.php and a listing of available operations and WSDL file.



I personally felt that it was easier to get the client to do various operations and sniff the traffic to get an idea of how things are implemented. I think I'm well on my way to writing my linux variant of the notifier.

Next time, I'll look into how the credentials are stored and if they are encrypted and if this is a trivial encryption to break.

Dissecting the GoDaddy email notifier - Part 1

I host at GoDaddy. Yes, yes, I know there have been horror stories and there is even a site that lists incidents involving the shutting down of some sites with little or no warning; but they're dirt cheap and I'm poor so...

Anyway, GoDaddy has this email notifier which will check your mailbox to see if you've got new mail without logging into the horribly slow Web Based email client. It's fairly convenient, but only installs on Windows. I wanted to do two things with this notifier:

1.See how safely it actually kept my credentials.
2. See how it communicated with the server and if it was secure as well.

I then wanted to see how easy it was to have a version written for Linux so that I can use it on my Ubuntu box.

I don't know how many of you have nodded off by now and how many of you wondering why I even bother. The truth is, its important to me, its my blog and it will also hopefully enlighten you on how you can go about conducting an analysis on a network application. In this regard, this is what I will be doing with this application:

1. Examining the communication between notifier and server
2. Identifying how the credentials are stored and if they are encrypted
3. Attempting to decrypt the credentials if it proves easy to do so
4. Writing my own Linux version of the tool. Either a Gnome Applet or Firefox Extension (whichever is easier)

Since this will be an ongoing saga of sorts, I will break it down into several posts for managability's sake. It also gives me time to conduct my research and publish the findings without waiting till the end.

Right, let's begin...

As with all applications, I downloaded and installed the tool. The notifier is in the form of a small envelope that sits in your taskbar . You can configure it to check up to 5 email addresses and specify such settings as duration between email checks, how long to display messages for and how many new messages to display in a small popup window. All fairly simple.

My first order of business is to check how the tool communicates with the server. So I fire up Wireshark and sniff a few packets. Immediately, it is apparent that the tool uses SSL. Points for GoDaddy. No casual sniffing can be done. This puts a dent in my plans of attempting to write a Linux version. How can I write one, when I don't know what it says to the server? I can always try an MITM SSL sniffing exercise. The idea for this one is as simple as this:



This can all be achieved by using stunnel and the replug tool found in Matasano's BlackBag. As a matter of fact, Dave Goldsmith has an article on the Matasano Blog about how he did this for a Java Application. In his case, it was a fairly easy workaround to bypass the certificate validation. I don't know how easy it will be for this specific application. But I'm getting ahead of myself. Join me for the next post where I setup the stunnel/replug proxy chain, discover if proper certificate validation is done and look for a way around the SSL communication.