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.