Sunday, November 2, 2014

Security Analysis of a Glacier Backup tool for Windows

Ok, so my career has shifted more to mobile app development and security. I've been looking into ways to backup personal stuff on my personal, non-work laptop, and I like the idea of using Amazon Glacier. It's cheap, and reasonably available (if you can wait half a day while they fetch your archives, that is). No problem. Just what I was looking for!

I found a great Windows client for Amazon Glacier. It has all the features I need, but in this day and age, one has to be increasingly suspicious of apps that might also contain malware. So, in this post, I want to talk about some skills I've picked up in the last 10 years at my previous job that are paying dividends in checking software to determine whether I trust it or not.

Note that this is fairly high level, except for the parts pertaining to reverse engineering .NET code.

First step in malware analysis. Search online! Has anyone already done this? No? Ok, step 2...

Download the app. You need to setup a virtual machine to run it in so that you can isolate your "real" computer from any potential malware infection. There are numerous ways to do this, and I'll mention a few and let you research what works for you. If you can install a copy of Windows inside a virtual machine, then you can play with it there (using Hyper-V, VMWare, VirtualBox, etc). You can also spin up a Windows copy in the cloud (using Windows Azure, Amazon AWS, Rackspace, etc). That will cost some money, but is a simple way to get Windows if you don't have a license to activate a local copy in a VM. If you work for a software engineering firm, you can almost certainly get a Windows key through your MSDN subscription. Ask around in your IT department. Students, same goes for you at many universities. Also, look into the DreamSpark program.

Now, install the app on your isolated environment. If it's an MSI file, you can open that and inspect the various tables of custom actions, install files, registry changes, etc using a tool called "Orca" from Microsoft. If you have Visual Studio and/or the Windows SDK installed, you can probably find an MSI file for Orca already on your hard drive.

If the installer is not MSI based (or even if it is and you want to be paranoid or don't know enough about MSI technologies to benefit from pre-install static analysis), then fire up SysInternals' ProcMon. You can log all registry, file, and TCP/IP activity for any process on your system. If you run that while the installer does its work, you'll have a good idea of whether it's REALLY doing what it says it is doing. Plus, you'll know where on the system to find the installed app (it may not just be in Program Files, for example) to begin studying further.

At this point, my particular app was discovered to be a .NET windows desktop application (get a good PE information utility to look at your file, and you can tell that way...or also if you open ILDASM and attempt to disassemble the code, it will inform you when it is not a .NET DLL/EXE file). So, I immediately opened ILDASM and tried to convert it from a binary to MSIL source code. I got this cryptic message saying "Protected module -- cannot disassemble". What?!? That was a new one to me. After some googling, I discovered you can set an attribute in your .NET assemblies that tells ILDASM not to disassemble it. Well...that keeps away the newbs, but all you have to do is undo that attribute and you'll be able to disassemble. Use some kind of PE file editor to zero out the attribute as described here.

With the disassembly, you'll likely notice that the code was obfuscated. This means that, during the build process, a tool was used to take the nice meaningful names that classes, methods, fields etc have in .NET and mangle them into 1 and 2 letter long cryptic names. In other words, the .NET metadata is obscured so as not to let you infer meaning from a class named "InstallMalwareOnBackGroundThread". :) Instead it will be named "nca" or "pbe2" or something!

In addition to this, many obfuscation tools screw up the MSIL sequence so that instead of just loading a string on the stack, you load an int, call an obscure method that returns a string, and then call the actual method of interest. Plus dozens of other annoying things...

But for us, that's no problem. Although seeing the code would be nice, my main focus is to know what .NET base class libraries the tool interacts with. This is often enough to infer whether you can reasonably trust a program or not.

So, I searched the IL code for "call" and "callvirt" to make a list of functions called within the program. I then further narrowed that list down to things that started with "System." to know what base class libraries are used. I came away with this list:

System.Management (WMI)
System.Net (probably HTTP/TCP stuff mostly, plus transparent SSL support by .NET)
System.IO (file/disk)
Microsoft.Win32 (registry access)
System.Security.Cryptography (encryption used by the app)

Ok, those are all somewhat reasonable things for my Glacier app to do in certain cases. Let's make sure they're being used properly.

So, I launched Sysinternals' ProcMon and began monitoring file/registry/networking for my program (filtering to include processes that start with the program's name). I also opened SysInternals' DebugMon tool in Administrator mode, and listened for Global Win32 messages. I opened the app, and gave code execution control to this new acquaintance of a tool! Shudder...

I then studied what happened at startup before I ever clicked around in the tool. A roaming profile was created, a log file was created, some non-threatening things were stored in the registry, and some polling thread kept looking for a queue.xml file on disk. Ok, whatever. I then attached to the process with WinDbg and ran the command ".dump /ma C:\Dumps\myfile.dmp". Then I shut the tool down, and shut down my monitoring tools.

The app's own log file had some nice helper debug messages for what it was up to, but of course those shouldn't be 100% trusted. I also looked in the queue file, but nothing interesting was there (presumably because I wasn't trying to download or upload to glacier).

Next, I decided a good old fashioned string search on the file might be handy. But this one is obfuscated, so I decided to search the dump file instead. Dump files are disk copies of exactly how memory was in the process at the moment you executed the dump. So, I loaded the dump file in WinDbg, loaded SOS (I knew the app was 64 bit, because it was in Program Files and not Program Files (x86), and I knew it was .NET 2.0 from ILDASM's output) from Framework64\v2.xxxxx\sos.dll. Then, I ran "!DumpHeap -strings". That produces an output of about 2-3 thousand strings, truncated after the first 100 characters of each line or so. Perusing through these led to some interesting insights.

For example:
"Unable to decrypt your Access Keys (wrong password?)"
Hmm...apparently my credentials are protected by password using symmetric cryptography on disk somewhere.

Perhaps these algorithms are used to store the Amazon credentials? Kind of funny, because elsewhere in the tool is an options screen where you can encrypt the files going to Glacier as AES 256, which is the best choice. Why use Triple DES I wonder? Or freaking RC2? Really?

"SELECT * From Win32_OperatingSystem"
Obviously a WMI query for what version of Windows you're on...

"SELECT * From Win32_processor"
A WMI query for processor info (maybe used to properly thread and throttle your Glacier access?)

May use WCF services...

What the heck? This is nowhere in the UI.

Perhaps uses a local SQL DB? Hmm...

I decided that SSL might get in the way of good information gathering, so I opted for making a new file named "myapp.exe.config" that contained the tracing found on this website. This let me log to a file on disk, BEFORE SSL kicks in! Sweet! I could see everything going to/from Glacier and validate it was what I wanted going across the wire.

At this point, I knew what kinds of things I wanted to look for, so I continued to fine tune my ProcMon filters for file/registry/network activity to alert me of unusual things and filter out expected things. Continuing to click throughout the app, I came to the conclusion I could trust this one. Here are my general findings.

The only web URLs it used were directed to Amazon AWS IP's or DNS names.
The log file only sent data I told it to over to Amazon.
My credentials were stored with...adequate, TripleDES crypto.
WMI was used appropriately, changing behavior based on Windows 8 vs 7, or single/multi core.
The local SQL usage was never found. Maybe the app doesn't use a SQL DB? This was a risk point, but one I decided was worth taking.
The app never contacted Dropbox. I have no idea why that string is in the code. I'm sufficiently convinced the app won't upload my keys to his dropbox, so I'm going to let this one go.

So in all, the app passes! And I have some peace of mind now about using it. At least far more than I originally did. I hope this is helpful to you. What RE tools do you use to measure whether you trust an app or not? I'd love to hear your thoughts in the comments!

No comments:

Post a Comment