VSJ | Articles | Road to recovery

Road to recovery

You’ve just realised that you don’t know what your email password is. What do you do? Admit to the system administrator that a programmer is fallible? No, of course not – you write a program to recover it!

By Gary Short

Published: 28 May 2004

When I came to work for Scotland On Line, they set me up with email. I set up my account in Outlook and everything was rosy. After a couple of months I wanted to pick my emails up from home, the trouble was I couldn’t remember my password. In this article I’ll show you how I overcame that problem, and as a side effect, show you that when you’re designing a cryptosystem, you have to take a holistic approach.

Now, back to the original problem. I wanted to set up my work account on my home computer. Unfortunately, I couldn’t remember my password. Okay, I know I could have just exported the account onto a floppy disk and then imported from the floppy to my Outlook at home. The thing is, I never trust that to work properly, and if it doesn’t then you’re back to where you started. Besides, if you don’t have a back-up plan then you’ve got no plan at all. I also know I could have just admitted that I’d forgotten my password and asked the administrator to reset it. Once I’d got a new password, I could have changed it at work and set up the account at home, but no software engineer’s going to admit to an admin that he’s forgotten his password!

The reason I couldn’t remember my password was that I checked the box that says, “remember password”, so I don’t have to type it in every time. The (fairly predictable) result of this is that, because I don’t ever type it in, I’ve forgotten it. However, that means that my password must be stored somewhere on my machine and my guess was the registry. I searched the registry for my Scotland On Line account name and found the following key:

HKEY_CURRENT_USER\Software\Microsoft\
	Office\Outlook\OMI Account
	Manager\Accounts

Under that key there is a value called “Pop3 Password2”. Eureka, less than a minute into the problem and it’s solved already! Today was going to be a good day.

Not so fast though. On closer examination I noticed that although that value probably does hold the password, it’s encrypted in some way so I still don’t know what my password is. A quick search on Google showed that the encryption algorithm used was not publicly known so it looked like I was stuck. What’s worse it looked like I’d have to go to the admin and own up to having forgotten my password.

Happily though in this case, like so many others, the weakest part of the cryptosystem is rarely the encryption itself. To break the system, you just have to determine where the weakest point is and attack it. In this case, the weakest point is the fact that the POP 3 protocol is a plain text protocol. Meaning that, although Outlook encrypts the password for storage, when it connects to the POP 3 server, and is asked for the password, Outlook will decrypt it and send it in plain text. All I have to do is write a little piece of software that pretends to be a POP 3 server, point Outlook at it, and let the protocol do the rest. Notice also that this technique should work with any POP 3 client and not just Outlook.

Building the server

The first thing we want to do is to set up a server on our machine that will pretend to be a POP3 server when Outlook tries to connect to it. To do that we need to use the classes defined within the System.Net.Sockets namespace to create an ipEndPoint, have a TCP server listen on that end point and then accept client connections like so:

//Create a new TCP server on the
// loopback address and listen in on
// port 110
IPEndPoint ipEndPoint = new
	iPEndPoint(IPAddress.Parse(
	"127.0.0.1"),110);
TcpListener tcpServer = new
	TcpListener(ipEndPoint);
tcpServer.Start();

//Wait for a POP3 client to connect.
TcpClient tcpClient =
	tcpServer.AcceptTcpClient();

When a POP3 client, Outlook in the case, connects to our server, it must behave as expected by the client. This behaviour is defined in RFC 1939. The first thing our server should do is to return a welcome message like so:

// Give proper welcome to client
NetworkStream ns =
	tcpClient.GetStream();
byte[] outbytes =
	Encoding.ASCII.GetBytes("+OK
	Welcome to my server" +
	Environment.NewLine);
ns.Write(outbytes,0,outbytes.Length);

Once the client receives the welcome message it should send the user id. We should record this in a buffer for later reference, using the following code:

//Accept user id
byte[] userBytes = new byte[255];
ns.Read(userBytes,0,userBytes.Length);

We now tell the client that the user id was okay. When the client receives this information it will send the password. We need to record the password for future reference. We achieve this with the following lines of code:

//Tell the client the user id is ok
outbytes = Encoding.ASCII.GetBytes(
	"+OK" + Environment.NewLine);
ns.Write(outbytes,0,outbytes.Length);

//Accept pwd
byte[] pwdBytes = new byte[255];
ns.Read(pwdBytes,0,pwdBytes.Length);

Now, all we have to do is to take the byte array buffers that we have, containing both the user id and the password, and translate them into strings. Having done that we can write them out to the console, like so:

//Write out uid and pwd
Console.WriteLine("UID = " +
	Encoding.ASCII.GetString(
	userBytes));
Console.WriteLine("PWD = " +
	Encoding.ASCII.GetString(
	pwdBytes));

Having persuaded Outlook to give up the user id and password of the mail account, we can now close down our server, this will cause an error to be displayed in the client application but, for this purpose, it can be ignored. To close down the server we use the following lines of code:

//Shut down the server
ns.Close();
tcpClient.Close();
tcpServer.Stop();

The full source code for this article is available for download.

Running the server

Now that we’ve created our proxy POP 3 server, let’s see it in action. The first thing we do is to change the POP3 server value, in the properties page of the account in Outlook, to localhost, so that Outlook will look on the local machine for our POP server (see Figure 1).

Figure 1: The POP 3 server is changed to Localhost

Next, we start our server application and simply ask Outlook to retrieve email on the account we want to get the password for. As you can see from Figure 2, Outlook will complain that our server closed down unexpectedly, but we can safely ignore this error.

Figure 2: An error to be ignored

The user id and password have been recorded and displayed by our server as shown in Figure 3.

Figure 3: Displaying the data

And that was how I was able to retrieve my password without having to admit to anyone that I had forgotten it. I’m sure I don’t have to remind you that, depending on where you are in the world when you read this, you may be committing an offence if you use this software or this technique to retrieve a password that does not belong to you. For this reason you should only use this technique or software for instructional or demonstrational purposes using a test account belonging to you.

In this article I’ve shown that in any cryptosystem the encryption is rarely the weakest link. In this case, although Outlook encrypted the password for local storage, we were still able to retrieve it due to the fact that POP3 is a plain text protocol and Outlook was forced to decrypt the password for onward transmission to the server. If you design cryptosystems for a living, you must take a holistic approach to your work, and not merely obsess about how strong the encryption you’re using is.

Gary Short is a software engineer for Scotland On Line, Scotland’s premier ISP. He welcomes any feedback via gshort@scotlandonline.co.uk, and has more material at www.garyshort.org.

Return to Articles