Response to Datto Exploits From a User

EDIT:  Datto’s official response here: http://www.datto.com/sbsresponse

I don’t work for Datto, but I have a large enough fleet of devices that there’s probably a ‘Most Wanted’ poster in their office with my name on it.  I know a lot of people in the support department and there’s likely a collective “Oh no, him again!” when a new ticket comes in from my email address.

This morning, I saw a post come up on /r/netsec about  security issues on Datto appliances.  Reading this, I wanted to make a post about my take on these from an MSP’s perspective.  I’ll write my thoughts on each subsection of the post by Silent Break Security, available here: http://silentbreaksecurity.com/tearing-apart-a-datto/

Initial Access:

The VNC password is absolutely well documented, it’s known all over the place.  That being said, how are people getting access to the VNC server in the first place?  Unless you forward a port or put a public IP on one of these devices, nobody can get into them without already being connected to you internal network.

To be fair, this doesn’t apply to internal power users who might want to snoop, but for as long as I can remember there has been the option to change the VNC password.  To my knowledge, this will not impact support’s ability to work on the device, so this should be changed and documented for all of the devices in your fleet.  It’s rare that I need to VNC in anyway and it always means that something else isn’t working (usually because a client’s firewall is blocking remote web, and even then I’ll usually just use the web UI from a server).

backup-admin is the account that you need to use to SSH into the appliance as it can su to root via sudo.  Of course, this does require having a portal login to find out backup-admin’s password in the first place.  I will say that I’ve never seen a backup-admin password change, which wouldn’t be a bad idea.

aurorauser’s password is also pretty well known, but Datto isn’t as forthcoming about it as the VNC password.  I’m not really sure why this account exists, to be honest.  I always just assumed that it was so the console could be logged in already when an end customer connected a monitor.  I’d like to see this account disabled (depending on how that would impact other functions) and be presented with a login prompt (either a text based one or a graphical display manager) and do away with the automatic login of aurorauser.

Pulling out the root:

Nothing to say here.  Time to update your fleet, Datto users.

Building a backdoor

This is bad-ish IMO.  At this point you’re already root, so I’m not surprised that there’s a way to add users to the web UI.  I’m not sure it matters though as pretty much everything can be done with snapctl/speedsync and the normal Linux commands (especially related to zfs) anyway.

Finding the keys:

I’m combining this and the next section into one paragraph.  This is bad, but not as bad as it may seem. I didn’t know that snapctl had the addAgentPassphrase option.  The problem I have with it is that Datto’s marketing makes the point that nobody, not even Datto, can help you if you forget your password.  Here’s the thing, though.  This is all only going to work if the agent is already unlocked.  Meaning, after a reboot, *somebody* needed to know the correct passphrase before unlocking it, so presumably you need to have already unlocked the agent (it’s probably already unlocked to be fair), have root (not too hard if you’ve not upgraded to Ubuntu 12 yet) and that’s about it.  This is a risk for sure, but closing the aurorauser hole will fix it.

The obfuscated source is annoying, though and.  My first thought is ‘why bother’?  You’re likely not going to be able to see these without root and it doesn’t buy you much aside from needing to remember to run it through the obfuscater when making changes.

This doesn’t take into account the possibility of support adding one surreptitiously, but I don’t think it’s fair to expect Datto to be able to mitigate the possibility of a rogue support agent.

I don’t really consider sending commands to the agent and the other things you can do with snapctl to be a major security risk.  I know that these are used for troubleshooting.

Summary:

I think a lot of good can be done by the following:

1.  Updating all appliances to Ubuntu 12 (and staying on top of patches as they are released)
2. Changing the VNC password regularly, just like backup-admin
3. Putting a login screen on the console, rather than automatically logging in aurorauser
4. Clarifying what is and isn’t possible regarding encryption agents (the logging in after reboot is too much of a hassle for me to bother most of the time.  That’s not Datto’s fault, i just don’t want to do it)

Sage 50 P2V Woes

This weekend, I virtualized an existing physical server that happens to have Sage 50 Accounting 2014 installed.  I don’t have screenshots of this one because I didn’t start thinking it would be an interesting issue until the very last moment.

This went well, except that I noticed the Sage 50 SmartPosting 2014 was not started.  When trying to start it, I received the generic “Service has started and then stopped again” error message.

Wondering if this client even uses SmartPosting, I opened the sage icon on the server and saw the following message:

Error: “The activation key for Sage 50 is invalid or could not be read. Would you like to reactivate now?”

Thinking that this was just some issue related to the P2V and a license deactivating, I clicked Activate and nothing happened.

Oh boy.

There are a few articles on this on the Sage support sites, but surprisingly, “then nothing happens when you click Activate is not in them.  However, this article did point me in the direction of SageReg.exe.  I found this program in the same directory as the rest of the sage install.

Running it, I noticed that there is a tab for checking the activation status and a button to check.  I checked and Pervasive was in the state Failed Validation.  Some searching through Pervasive documentation indicates that this happens during hardware changes.  A P2V would definitely fit that description.  The bad news is that all of the documentation indicated that I should call Pervasive with my key to resolve this.

Because the version of Pervasive that comes with Peachtree is bundled, rather than a separate purchase, the key gets installed as part of the install.  An article on Sage’s website outlines the procedure for reinstalling Pervasive manually, rather than through the Peachtree installer (linked here), but the installer clearly states that this will not impact the license.

It doesn’t, so without any other valuable information in the documentation, I turned to Process Monitor to see what was happening when I clicked on the Activate button.

Here’s the screenshot (I applied a filter after the fact to make this obvious):

The issue should hit you pretty quickly at this point.  When clicking activate, the installer is iterating through every directory in the current user’s PATH to try to find the SageReg program.  It can’t, which is why nothing happens when clicking the button.  I added the correct directory to the user’s path and ran through the process again.

Success!  The program went through its activation routine.  I can only assume that clicking that button passes some command line switches to the registration program that are required to work again.  Pervasive is also showing as licensed again in SageReg.

More importantly, the original two problems are resolved:  The SmartPosting service starts and the program opens as normal.