bility.
Aleph One sums it up quite nicely in this excerpt from a Bugtraq post titled “Re: Reinventing the wheel (a.k.a. “Decoding Netscape Mail passwords”).”
This is a red herring. Local secure storage of secrets in PCs without another secret is not possible. We’ve had this discus- sion before on the list in reference with many client applica- tions (including Netscape). If you are using a known key, a better encryption algorithm is useless.
Regardless of the algorithm, it’s nothing more than obfuscation. For encryption to be of any use, you need to encrypt the infor- mation you want to maintain secret with yet another secret, but the user does not want to be bothered with remembering another password. That is the reason they ask the client application to remember their password in the first place.
Kindergarten Crypto
Let’s face it, the vast majority of you who are reading this book (myself included) will never be real cryptographers. I’m never going to come up with a novel attack against RC5, DES, or Twofish. Heck, I probably wouldn’t even have a chance against some algorithm that a real cryptographer could break in minutes. However, my personal experience has been that that doesn’t really matter.
So far, nearly every time I’ve looked at a product that has some sort of information-scrambling feature (often trying to obscure a password), and the product wasn’t primarily a security product, it used something really dumb to hide the information.
To some degree, this is to be expected. As other parts of this book point out, it’s not really possible to effectively hide secrets on a machine totally under an attacker’s control. If a program wants to obscure a password that
For IT Professionals
it stores, and it needs that password back, then it has to be able to decode it. If the program can do it, so can you.
For example, let’s say you’ve got an e-mail client that uses the standard pop/smtp/imap (Post Office Protocol/Simple Mail Transfer Protocol/Internet Message Access Protocol) protocols. Let’s also suppose that this program offers a feature that will let it remember your password for you, so you don’t have to type it all the time (bad idea, by the way). All of those protocols require the password in the clear on the client side at some point. Even if the version of the protocol you’re using (like APOP, Authenticated POP) doesn’t actually send the password across the wire in the clear, it needs it in cleartext to do the client-side calculations. If the program has stored your password, that means it can also retrieve it. A one-way hash cannot be used in this situation.
In the mail example, most of the time you can take the stolen scrambled password, plug it into your program, and have it spit out the cleartext on the wire when you instruct it to check “your” mail. A packet capture will get what you need. Still, there are cases like APOP where that won’t work. The password will exist in memory somewhere, but that may not be easy to get to either.
Besides, it’s just not as sexy. We want to try to determine the encoding algo- rithm so we can expose it to the world. Again, this is not some huge revelation, since we already know it can be done, but, hey, it’s fun. We also want to make sure that people don’t have a false sense of security.
So how do we go about decoding the password manually? First you find it, then you figure out the encoding algorithm. To track down where the password is, check out Chapter 5, “Diffing.” Once you have the string of characters, you need to determine what kind of scrambling might have been used.
The first step is to determine if the number of bytes in the ciphertext appears to be a function of the number of bytes in the password. For example, does the number of bytes in the scrambled password exactly match the clear- text password? If you double the length of the cleartext password, does the length of the scrambled password double as well?
Next, see if the ciphertext seems to follow the cleartext pretty closely. For example, set a password of aaaaa. Note the result. Change the password to aaaab. What changed in the ciphertext? If only one or two characters of the ciphertext changed, that gives you a big clue. If the first character of the cipher- text is the same whenever the password starts with an “a,” regardless of what the rest of the password is or how long, then you’ve got an extremely weak cipher, perhaps as simple as an XOR or ROT13.
Are there any particular characteristics of the ciphertext? For example, most Base64 encoded strings end in one or two = (equals signs). If you see some- thing like that, it’s a big clue that the ciphertext is Base64 encoded. For example, I stumbled onto the cipher for Netscape POP passwords stored in the prefs.js file. My ciphertext passwords ended in two equals signs. After Base64 decoding them, they were exactly the length of my cleartext password. A
couple of experiments revealed that XOR-ing them with the original password yielded the same set of bytes in each case. So, by the nature of XOR, XOR-ing the Base64 decoded passwords with this string of bytes revealed the cleartext password. I wrote up the whole story here:
www.thievco.com/advisories/nspreferences.html
In fact, XOR is terribly popular in dumb ciphers. For example, the password that is stored in the Registry for Microsoft Terminal Server clients is a simple XOR. So is the password stored in an .ini file in the Citrix client (which the MS Terminal Server is based on). The use of a stored password is based on a feature of both that allows you to create an icon for a terminal server with a username and password stored with it. To find out what the XOR string is, set a null pass- word. The resulting ciphertext is what you will use to XOR with other ciphertext passwords to recover the cleartext. It seems to vary with version and operating system (for example, it’s different on NT than Windows 9x), so perform the exercise on a matching platform and version.
ROT13 and variants pop up every once in a while (Caesar cipher variants, really). Here’s a nonpassword example from a Microsoft DLL file: Buried in a file named shdoclc.dll, which on my Windows 98 system is located in c:\win- dows\system, is an interesting bit of code. This filename sometimes shows up in the titlebar of Internet Explorer (IE) when particular errors occur. This file has also been found on WinNT 4 systems, and Windows 2000 systems, and it’s pre- sumably part of IE5.
Inside the view, which you can see by opening it in any text editor, is a bunch of HTML/script code. Here’s a sample of the interesting bit:
function LoadHashTable() {
g_HashTable = new Object();
g_HashTable[ 0]=”{{NAq ABJ {Jr CErFrAG{gur ZvpEBFBsG VAGrEArG RKCyBErE{cEBqHpG grnz{{{fCrpvny GunAxF GB{{QnIvq PByr{OEnq
fvyIrEorEt{cnHy ZnEvGM{Ovyy TnGrF{nAq{bHE OrGn grFGrEF{{{OEBHtuG GB LBH oL{{{furyy nAq PBEr QrIryBCzrAG{{{NqEvnnA PnAGrE{NynA
NHrEonpu{NynA fuv{NAqErJ THyrGFxL{NAqL cnqnJrE{NEGuHE OvrErE{NEHy XHznEnIry{NFuEns Zvpunvy{OnEEL XryznA{OunEnG fuLnz{OELnA
fGnEoHpx{Prz cnLn{Purr PurJ{PuEvF SEnAxyvA{PuEvF THMnx{PuEvF aLznAA{PuEvFGBCurE Q gHEArE{QnpuHnA munAt{QnA “;
g_HashTable[ 1]=”Yv{QnACB munAt{QnEErA ZvGpuryy{QnIvq
QfBHMn{QBAG FGBC JnGpuvAt LrG{RqJnEq cEnvGvF{REvp inAqrAorEt{REvx fAnCCrE{TnEL aryFBA{TErt WBArF{VAn grrtnA{WnL ZpYnvA{WBr