FooBar: Untangling the DB Role Password

Security by Obscurity Series

December 16, 2019 by Matt in /Programming with No Comments

My day-to-day work forces me to work with one of those "enterprise" applications for Windows -- we'll call it FooBar from here on out -- that leaves you feeling like you've had an ice pick driven into the more intelligent areas of your brain. Since I'm often out and about I'd prefer to have a copy of certain records with me to refer to in the field; I don't need everything with me to do my job, but being able to cart around the history of a specific location would be very helpful. FooBar isn't accessible in the field without going through an authentication process that involves a goat and a few uncouth contortions so I have little desire to try using it as designed unless seated firmly before my desk.

FooBar defines the connections to databases in an XML file stored on the desktop computer and we "login" to the application using our Microsoft domain username and password (this happens to be the same as our desktop login). Having obtained the database server and connection name from the XML file I proceeded to login to the database and have a look-see.

It turns out that there isn't much to peruse as FooBar uses a second form of authentication for access through what is known as an Application Role. The password for this particular role is helpfully recorded in another XML file however it is stored as a Base64 encoded string which, when decoded to UTF-8, returns a set of the most unholy characters you've ever laid your eyes on: the decoded string is encrypted.

Taking a peek at the DLL files that make up FooBar, I noticed that the program database files were distributed with the libraries. Guessing that FooBar might have been written in .NET, I fired up ILSpy, a .NET decompiler and began sifting through the more likely DLLs. Fortunately the authors were kind enough to give their files readable names so it didn't take long to hone in on the correct files; as luck would have it, the decompiled code responsible for parsing the role XML file referred to an encryption helper routine that identified the algorithm (AES), encryption key and initialization vector.

From this it took me all of the following five lines of Tcl to decrypt and return the password (the actual password, key and IV have been changed, of course, and the example below won't work as the key and IV sizes are incompatible with the AES algorithm).

package require aes
set _password "cGFzc3dvcmQ="
set _key {1 2 3 4 5}
set _iv {6 7 8 9 10}
puts [aes::aes -mode cbc -dir decrypt -key [binary format c* ] -iv [binary format c* ] [binary decode base64 ]]

This fun little exercise served as a good reminder as to why it's a bad idea to encode encryption keys in application code. It doesn't provide any greater security to local applications and in most cases, is a poor second cousin to properly designed authenticaton channels.