Reverse engineering a 'secure' system data collection tool

Awhile ago at a previous employer I worked with a VAR to do a system and software inventory of our workstations. They had written a custom application in C#.NET (for windows systems) and a bash script (for Mac OS) that captured the inventory data and encrypted it for us to email back to them. Sounds pretty straight forward, right?

I asked them about how the data would be protected on collection and being transmitted to them and surprisingly heard back from the VAR that their encryption mechanism 'cannot be disclosed publicly'. Hmm.... Before agreeing to run the programs and send back results, I performed a secure code review and found some interesting things about their collection tools.

A Note

I have simplified the code examples here down to their essence and in some cases have renamed or obfuscated classes, methods and other identifiers. This is done with the intent to illustrate my findings while attempting to protect other companies or individuals who have used the inventory tools analyzed here.

The bash script

Let's start with the bash script targeted for use on Mac OS X. Upon examination I discovered a problem that is, unfortunately, more common than I would like to see in software that purports to 'encrypt' data:

#!/bin/bash

#
# Logic to capture inventory and security state information about the system
#

# Archive the files collected during the system scan
tar cf filez.tar tmpdir/*

# Encrypt the archive
cat filez.tar | openssl enc -base64 > filez.tar.secure

# Remove temporary files
rm -rf tmpdir

As you can see above, there was no encryption employed and the data collected about each workstation is 'protected' by Base64 encoding a tar file. I was not impressed.

The C# executable

For the C# code I used JustDecompile to get access the source code and take a closer look. In sifting through the source I stumbled on their encyption class which had some features I was less than pleased by:

static AESEncrypt()
{
    AESEncrypt.password = "...";
    AESEncrypt.salt = ...";
    AESEncrypt.hashAlgorithm = "SHA1";
    AESEncrypt.passwordIterations = 2;
    AESEncrypt.initialVector = "...";
    AESEncrypt.keySize = 256;
}

For all customers receiving a copy of this inventory tool, the password, salt and initialization vector for the AES encryption are static (which is why I've redacted those out with periods). You'll also note that SHA1 is employed as a default hashing algorithm instead of something more secure from the SHA-2 family. Moreover, in tracing the program code I found that this weak encryptor is bypassed when the program is writing out its 'secured' files:

.
.
.
system_data = (!Collect.b64Only ? EncryptUtil.AESEncryptThis(stringBuilder.ToString()) : stringBuilder.ToString();
b64Encoded = Base64Encode(stringBuilder.ToString());
WriteSecureFile(b64Encoded);
.
.
.

If you look carefully above, you can see there is a ternary which appears to use the AES encryptor if the 'b64Only' flag is not set. What I find interesting is that the next couple of lines perform a base-64 encoding on the string and write that out as a 'secure file'.

Talking With the Vendor

I took my findings to the vendor who listened to what I had to say. They promised to make changes to their collection tools. To keep the project moving (we were on a deadline, as usual) we encrypted & sent the inventory using a secure file transfer tool we already had on hand.