Want to Read Your Parents' / Boss' / Coworkers' Files? Mozy Client Circumvents Windows File Access Permissions

Last fall I wrote about Mozy, a cloud-backup company (now owned by EMC), which had a severe bug: it didn't back up all the files it was scheduled to. What was most disturbing was not that they hadn't caught the bug ... it's that when I tried to work with them to resolve it, they blew me off. Apparently I wasn't the only one to have this problem either, as people from all over found my blog post and emailed me, saying they saw the same behavior and asking if I had a fix.

I still think that not backing up files is the biggest possible bug for a backup program.

But now there's competition: their latest client allows a non-privileged user on a Windows XP system (haven't tried it on Vista yet) to restore private files belonging to any other user ... including Administrators, and place the "restored" files into the non-privileged user's folders, with full access, and fully decrypted.

How does this work? Say Jim, the Admin on the box, installs Mozy in a default configuration. Mozy is backing up Jim's "My Documents" folder and subfolders, among various other things. Jim's son Lenny, who is a non-privileged XP user and who is not supposed to have access to Jim's private files logs on.

Lenny notices that "My Computer" contains a virtual drive corresponding to the Mozy backup set. In that virtual drive is ... a "C:" drive ... and a "Documents and Settings" folder ... and a "Jim" folder. Now in XP, "C:\Documents and Settings\Jim" is another name for Jim's "My Documents" folder. This particular instance though is not the actual "C:\Documents and Settings\Jim", which Lenny doesn't have any access rights to, but the backup image of the folder.

So Lenny browses through, finds something interesting, right clicks and chooses "Restore To," which lets him "restore" his dad's file to somewhere of his choosing. He browses to his Desktop, clicks ok, waits a few seconds, and now he has the file.

(Even if Jim has chosen to manage his own crypto key -- one of Mozy's coolest features -- the Mozy client keeps that key accessible so that it can perform automated backups. Unfortunately, it also uses the key for restore operations no matter who performs the restore ... so files restored in this way are decrypted.)

Ok, so there are no secrets on the family computer. Not the biggest surprise, since if junior really wants the data, there are tons of other ways to get it, from booting a Live CD and mounting the hard disk, to yanking the hard drive right out of the box.

But here's where it gets more interesting: In many (most? ... all that I've worked at anyway) corporate, Active Directory- / Domain Controller- managed XP Pro deployments, folks can log on to each others' workstations at will, provided they use their own credentials in the Domain. Their Domain profile updates to the local machine as necessary, and they can then work there. They may even be able to log in remotely via Remote Desktop.

So at work, I walk up to my co-worker's machine (or maybe RDP in) and log in as myself. I open the Mozy tray icon, and proceed to restore their files from the backup set to my own directory, or to an unprotected area like C:\Temp. From there I can open/read/copy these files however I like. Incidentally, if my boss' files weren't already scheduled to back up, I can add them to the backup set. Next time the backup runs, they'll show up in my view of the "Virtual/Restore Drive."

I haven't tested the Mozy "Pro" business client, but since the docs [PDF] look identical to the Home client (apart from a color accent) I suspect it behaves exactly the same way (see in particular sections 7.3 "Using the MozyPro Virtual Drive" and 7.4 "Right-Click Restores") Not to mention that if Mozy fixed this in the Pro edition I can't think of any reason they'd intentionally keep a broken code fork for the Home edition.

I think there are some other fun tricks one could play with this client too, but it all boils down to two things:

1. The underlying process is a privileged process, but it takes orders from a client run by any user.(I'm no security guru, but this sounds like a Confused Deputy problem to me.)
2. The full fidelity of the local file (including a way to associate ownership and permissions) is not being preserved through the backup round trip.

I'd have reported it to Mozy before writing about it here, but they made their lack of interest clear last time around.

Update: I forgot to mention, MozyPro offers "Network share and mapped drive support" ... combined with the bug described here, that's some serious potential risk to add to the mix.