Symantec (formerly Veritas) Backup Exec is one of my all-time favorites in pentest projects: it has a very nice list of vulnerabilities ranging form basic stack overflows through a hardcoded password to arbitrary file reads. Although most of these vulnerabilities aren’t new, some users tend to accept the risk of running unsupported versions because purchasing the new releases isn’t cheap. But this is not the best part from an attackers perspective.

Backup Exec is a backup software (surprise!) that by definition needs access to the most important parts of the domain (why would you backup something you don’t care about?), so as you get access to a Backup Exec instance theoretically you also get access to the most important data on the network. In practice all Backup Exec installations I encountered had domain administrative access granted.

But how exactly can we escalate our privileges from a single Backup Exec instance?

My most recent “date” with Backup Exec turned out a bit unusual. The software itself was the most recent version with all publicliy known bugs patched, but on the same host there was another “enterprice level” application that granted me limited file read rights through a pretty dumb vulnerability.

Since I didn’t have broad permissions and I didn’t know anything about the filesystem, I couldn’t access any interesting configuration files, password dumps or other precious loot. But I knew, my old lady is listening at port 10000, so I started to enumerate the default files of Backup Exec.

This software uses MS SQL Server to store all the information required to perform backup and restore, but unfortunately the database files were inaccessible by my user. However the database backup located at <BackupExec Dir>\data\bedb.bak was readable!

So I grabbed the file and read Symantec’s documentation about the DB recovery process. After incrementing the infamous Lamer Counter a couple of times (#ProTip: if you use cURL to download something, don’t forget to remove the HTTP response headers from the output) I realized that this .bak file is just a standard MS SQL backup that you can parse with any SQL Server instance.

In the recovered database you will find a table called LoginAccounts that contains all the domain usernames and passwords that were configured by the administrators of the system, to let BE access different hosts on the network. The trick is that the passwords are in some custom weird form that you can’t easily decipher.

Reversing the custom encryption

When you encounter a similar situation, you first have to figure out if the algorithm that produced the weird ciphertext depends on some configurable key. If it does, you’re probably out of luck, but if it doesn’t, your chances are good to recover some meaningful data in finite amount of time.

I installed two separate instances of Backup Exec and configured two accounts with the same password. Then I queried the password on both instances to see if they are the same. Since the passwords are stored in an NVARCHAR (multibyte) field but the actual value is simple printable ASCII as the result of a simple SELECT you’ll get a bunch of not printable/alien characters which are hard to handle so you better cast to varbinary. But beware, the encrypted passwords are several hundred bytes long, and MSSQL truncates them by default so you have to use a query like this:

SELECT cast(AccountPassword as varbinary(1024)) FROM LoginAccounts;

Sample result after unhexlify:

ANdnf5Q7WkiWnRE8fB6mN3@ije2kL?LcG<B?IZ7M329neVU:QIBN>3lP<H_JF\PMYk[0KXZe4kVggR<HV@VB]BS64:_V<PlQQdR[TbcV^>\RN7@H]=THYc?`i:g4022kW1o[klm7D7T:ZnjOnUjbRon0aO;c6L61B5_3:Gh6j6[[D\j_Xe8ZiElZ0l][g0OGI3Rb=<7N;NV^>Ni?8<7_2`ENB^IHnMmhJXANfbo3gWeQK:_3bH`7A1l\L_j\eYEMkf_^`N0H7bm9U4bjW_BmaHVPB;1W1be5\No8nj>mlALn]=74Y`8X67^F;HSQefCeOH@GTQ7ABDSkE1AF<X:B=Y@3Dg_Ol9cjh>SFJ3d^gc;1]Ea6^S:TC^MC36XSc<HoPll9[j^2`S>iIjlU]Be\7]a2<HNK@U`f@FAE2ZBXPBONebD5Y;mG^G@b2ZZJXd3:AB@JQhM[0=Fg59=j7@NZe<Mcc?aIg[ld@37`\lU?Ca\TTn6DGE\8TP@2FB1l<W6<@:6PI1]?]oSVgMK7hkBmhD0]ZFWL<\OPdG?HoK52f7_A_1X]<K7C\NQJI\G?jG7YW4aN>Qj;hWRQ`AS4aSaB;?Y13a\18j@f:M`CQ>[i]XkaYTVF[d_j1K0R_m>U5AmdYL0gPc4DSJ=ND3M;dlHZ:WP0YoIC>4[IE:dMB<BQC34

The ciphertexts were same which meant that there was no installation specific secret in my way. Great!

Backup Exec needs to access the plaintext data, so there has to be a decryption function somewhere. Since there are tons of executables and libraries included with the software, first I ran a fast script hoping I can find some helpful exports:

find . -name '*.dll' -exec strings -f {} \; | fgrep -i decrypt

The developers were kind enough with me, the output showed that bemsdk.dll exports a lot of interesting methods:

?Decrypt@CBemDataEncryptionKeyX@@QAEHXZ
?Decrypt@CBemLoginAccountX@@QAEHXZ
?Decrypt@CBemScriptDetail@@QAEXXZ
?Decrypt@CEncrypt@@QAEHPAEF0AAF@Z
?Decrypt@CEncrypt@@QAEHPA_W0@Z
?Decrypt@CEncrypt@@QAEH_NPA_W1@Z
?DecryptDataEncryptionKeyMap@CBemJobOptionsDeleteFromArchive@@QAEXXZ
?DecryptDataEncryptionKeyMap@CBemJobOptionsRestore@@QAEXXZ
?DecryptDataEncryptionKeyMap@CBemJobOptionsRestoreArchive@@QAEXXZ
?DecryptInPlace@CEncrypt@@QAEHPADH@Z
?DecryptInPlace@CEncrypt@@QAEHPAEAAF@Z
?GetDecryptedValue@CBemConfigParam@@QBE?AVmstring@@XZ
?GetDecryptedValue@CBemStructBase@@QBE?BVmstring@@PB_W@Z
?Decrypt@CBemDataEncryptionKeyX@@QAEHXZ
?Decrypt@CBemLoginAccountX@@QAEHXZ
?Decrypt@CBemScriptDetail@@QAEXXZ
?Decrypt@CEncrypt@@QAEHPAEF0AAF@Z
?Decrypt@CEncrypt@@QAEHPA_W0@Z
?Decrypt@CEncrypt@@QAEH_NPA_W1@Z
?DecryptDataEncryptionKeyMap@CBemJobOptionsDeleteFromArchive@@QAEXXZ
?DecryptDataEncryptionKeyMap@CBemJobOptionsRestore@@QAEXXZ
?DecryptDataEncryptionKeyMap@CBemJobOptionsRestoreArchive@@QAEXXZ
?DecryptInPlace@CEncrypt@@QAEHPADH@Z
?DecryptInPlace@CEncrypt@@QAEHPAEAAF@Z
?GetDecryptedValue@CBemConfigParam@@QBE?AVmstring@@XZ
?GetDecryptedValue@CBemStructBase@@QBE?BVmstring@@PB_W@Z

CBemLoginAccountX::Decrypt seems particularly interesting, let’s take a look at it in IDA:

As you can see, this method calls CEncrypt::Decrypt(wchar_t,wchar_t). It looks straightforward to LoadLibrary() this DLL in a small wrapper program and call CEncrypt::Decrypt() with the parameters dumped from the DB. But if you take a closer look, you can also see that depending on the object state the encrypted data may first run though a simple loop that uses a possibly dynamically constructed memory reqion (dirty_bastard on the pic) to transform the ciphertext before the actual encryption happens. I can reuse the Decrypt methods, but only after this region is constructed, so I turned to dynamic analysis.

My first night with Frida

I tried to attach a debugger to the management application (BkupExec.exe). First time I failed because the process was protected by a service called bedbg.exe, but killing it made it possible to attach with a debugger. But BkupExec.exe is a .NET application that uses bemsdk.dll thourh a wrapper assembly (bemsdkwrapper.dll) and my debugger became useless, because of all the dynamic memory magic performed by the process.

Luckily, at this time I’ve already took a look at Frida.RE, and although I’ve never used it before, it seemed like a good fit for this job. The concept was simple: hook CDecrypt::Decrypt(), replace its first argument with the ciphertext to be decrypted, wait for the method to finish and read the output buffer (second argument). Here’s the final code:

Interceptor.attach(ptr("0xdeadbeef"), { // address of CEncrypt::Decrypt()
    x:0,
    onEnter: function(args) {
        send("Decrypt (Before): ",Memory.readByteArray(args[0],697));
        a=Memory.readByteArray(args[0],128);
        args[0]=Memory.allocAnsiString("ciphertext"); // Your ciphertext here
        send("Decrypt (After): ",Memory.readByteArray(args[0],697));
        this.x=args[1]; 
    },
    onLeave:function(retval){send("Leave: "+Memory.readUtf16String(this.x));}
    });

But the road that led me here wasn’t exactly straight.

First of all, I needed a way to trigger the password decryption somehow. I could theoretically fire a call to the decryption function myself but I couldn’t figure out a way to get the address of the newly created LoginAccountX instances (the question is still open at StackExchange). Luckily I found a way to trigger this action from the GUI: when creating new backup jobs, the management application checks if it can access the resource to be backed up using the default Login Account.

But my original script didn’t work.

The first problem was with character encodings (there is always a problem with the character encodings): the implementation of wchar_t is platform dependent; in my case, the output buffer turned out to be readable as a UTF-16 string, which was the last thing for me to try out. Also, I had to realize that although the API defines the ciphertext parameter as a wchar_t string, it has to be provided in simple ASCII. The lesson is when experimenting with Frida, always use Memory.readByteArray() first, implicit conversations of the V8 engine and your API (Python in my case) can mess things up badly.

Second, I used the create_script() method of the Python API to provide a JavaScript script as a string to Frida to run. This wasn’t the best idea, since my ciphertext contained backslashes, which need to be double-escaped in order to pass through both the Python and the JavaScript interpreters. I spent hours on figuring this out, LC++;

But finally my hook script was able extract the plaintext passwords for the Domain Administrator account (and several others).

Exploitation in Practice

Repeating the process is a bit time consuming:

1. Grab a copy of bedb.bak
2. Import the DB backup to an MS SQL database
3. Copy the encrypted passwords
4. Install Backup Exec (trial is available from Symantec)
5. Install Frida.RE
6. Get the address of the Decrypt() export
7. Replace the appropriate parameters and attach to the BkupExec process with the above script
8. Trigger decryption by adding a new backup job

But it’s totally worth it: with read-only access on a BackupExec server (e.g. CVE-2005-2611) you can get plain text user accounts (probably with high privileges).

The dynamic analysis revealed, that you can also simply build a wrapper program around bemsdk.dll, since the problematic section of code is not called during the standard execution. I still find the Frida.RE way more convenient though.

I have to emphasize that this is not a vulnerability in Symantec’s product, but administrators should keep in mind that their passwords for backup accounts are stored in fully reversible form (equivalent to plaintext).