Ethical Hacks: How to find the site admin password for Mercury Interactive's TestDirector v7.6

IMPORTANT NOTE:The information presented here is to be used only for legitimate cases of access loss. Using these instructions to gain access to a system without permission is a violation of both state and Federal law.

At one of my old jobs as a security engineer, I was asked to find the admin password for an application (seems the company had managed to lay off everyone who actually knew it). This is an example of an "ethical hack", where techniques used by malicious people have legitimate application in the real world

TestDirector 7.6 stores all it's usernames, passwords, groups, and other metadata in MS Access databases. Now the standard database for the users is usually something like "Testdir.mdb" somewhere in the directory tree of the application suite. However, the admin password is usually stored in a database called "doms.mdb" which you should find in "c:program filescommon filesmercury interactiveDomsinfo".

Load the doms.mdb up into MS Access. You'll be prompted for a password. Try using "tdtdtd", but if that doesn't work all you need is tool for cracking MS Office passwords. Passware works great, though it's not free.

Once you have the database open, look in the ADMIN table. You'll see a field called "ADMIN_PSWD", and at least one record with a value for that field. The value will be six-digit number like "459999". That's the checksum value of the password that's been set. Yes, this is a crummy scheme and has a lot of password space collision. Luck for us!

[Note: This next step is deliberately obsfucated. If you understand this article you'll know how to decode it.]
Arkg, lbh arrq gb frghc Rgurerny (be fbzr bgure favssre) ba lbhe ybpny CP.
Pbasvther vg gb bayl favss genssvp gb/sebz gur VC bs lbhe GrfgQverpgbe
freire. Tb gb gur fvgr nqzva jrocntr ba lbhe GrfgQverpgbe freire (hfhnyyl
fbzrguvat yvxr uggc://freire/gqova/FvgrNqzva.ugz) naq gel ybttvat va. Bapr
lbh trg na hanhgubevmrq ybtva zrffntr, tb gb lbhe favssre naq purpx gur
erfhygf. Lbh fubhyq frr fbzr UGGC genssvp onpx naq sbegu orgjrra lbhe
pyvrag naq gur freire. Lbh'er ybbxvat sbe gur UGGC Cbfg sebz lbhe CP gb
gur freire gung vapyhqrf gur fgevat "cnffjbeq : ". Gur CBFG jvyy or gb
"/gqova/jqbzfei.qyy/GQNCV_TrarenyJroGerngzrag". Vzzrqvngryl nsgre gur
"cnffjbeq : " lbh fubhyq frr n fvk qvtvg ahzore. Gung jvyy or gur
purpxfhzzrq inyhr bs gur cnffjbeq lbh gevrq gb ybtva nf.

So now you know what value the server is expecting and what value your password generates. A bit of trial and error should allow you to find a password that will result in the same checksum and grant you access. For example, I found that incrementing or decrementing the first character in the password (i.e. a to b, or c to b) would increment/decrement the checksum value by 4. I didn't bother to do a lengthy analysis and determine the exact checksum method, but it's pretty simple, not utilizing any time elements. It does seem to vary depending on total password length.

Of course, this will be much more difficult if your access to the server is via https instead of http.

Originally Written June 29th, 2005 - Cleaned Up August 17th, 2006
Revised August 18th, 2006 to reflect CISSP Ethics Guidelines