Jump to content

How to steal a VM in three easy steps


klag
 Share

Recommended Posts

Μην εμπιστεύεστε κανέναν από http://community.spiceworks.com/topic/152734-how-to-steal-a-vm-in-three-easy-steps

A little background


Once upon a time, there was and still is a beautiful development company that specialized in the development of software critical to the upkeep and smooth operation of our nation(s) power systems. It used to be a small mom and pop outfit, but had merged with a larger company. Unfortunately, they hadn’t gotten out of the mom and pop thinking.

A not so young man was in charge of the upkeep of the virtual servers. He’d gotten into the habit of always checking his machines simply because he knew management was playing with fire, but wouldn’t let him do anything about it.

And one day he noticed something disturbing. Disk space on the virtual server had dropped dramatically. And like any good system admin, he went looking. What he began to find were snapshots of several of the Virtual Machines. Thinking they were leftovers he’d simply forgotten about, he deleted them, and all was well.

The following week, the pattern repeated itself. This time, he began to suspect that maybe the backup software wasn’t cleaning up after itself like it should. But after lengthy analysis and a lot of midnight calls and work, it became clear that wasn’t the problem. The following week, the same thing happened.

Slowly, it began to dawn on him that the problem had two legs, but what exactly was going on and why was still a mystery. So, he did what anyone would do. He went hunting.

Deploying a Snort IDS, he began watching. And one morning while going through logs, he saw an internal connection to the machine that looked routine but matched the time of a snapshot on one of the VMware servers. The connection was made using the vSphere Client, and no one from that IP address should have had it. The rest was simple track down and confront, but the answer for what was going on was one that was totally unexpected and just a bit frightening.

The answer to this mystery boiled down to one thing, and that’s trust. You’re supposed to trust the people you work with, but does that mean everyone and to what point. The individual behind the snapshots was one of the more respected developers, very smart, very good at what he did, and since he was a very innovative chap, of course he was trusted. And as bad luck would have it, the man wasn’t a half bad cracker. He managed to figure out the root account password (I still think one of the legit admins had written it down someplace and he went snooping). Since the powers to be hadn’t wanted to implement user accounts on the ESX server, root was all anyone was using, making it all but impossible to figure out whom was doing what.

How the scheme worked


What he was doing was this. First of all, he’d log in, and take a snapshot of the machine. When you take a snapshot of a VM, you start up what you call a “Delta”. At this point, all the changes get made to that Delta, leaving the original literally frozen in time. A clever person can take advantage of this. Here’s what he was doing.

This is step one. First he would of course, login, and make a snapshot of a VM.

Step two was almost too simple. He’d then browse to that datastore of that machine and highlight to original vmdk file as well as the vmx file, and then download it to his system (actually an external hard drive).

Step three is the scary part. He’d then take the machine home, and run it using VMplayer.

When asked why he was doing this, he said it was because VPN was too slow, and he needed to work on his projects on weekends and nights (understandable, but still . . .). Turns out, he’d taken it a step or two further. He’d taken to making the VMs available to friends by posting them to an FTP server he had at home (which incidentally was a long ways from being locked down and when examined by forensic experts it was determined that a lot more folks than his friends had been through it downloading VMs that incidentally had development software and in some case databases you don’t want out in the wild).

While the owners were willing to overlook the first part of his sins, the second was too much. After making sure he had none of our VMs left to him, he was fired, and escorted off site.

So, what’s the lesson learned? 


Lesson one: change management is a good thing. There has to be a way of tracking changes, everyone needs to be in the loop on it, and when it comes to security, there is no just flying by the seat of your pants.

Lesson two: trust no one. Even saints make stupid mistakes. An old adage goes that “Common sense ain’t so Common”. Especially true of people who think they’re justified in what they’re doing. There’s absolutely nothing wrong with questioning someone’s motives or reasoning.

Lesson three: is one a lot of folks have an issue with, and that question everything. Find something you don’t understand, question it. This is also a place where a work log comes in handy because it helps you remember what you’ve done from day to day.

Lesson four: The boss might be a nice guy but chances are he knows beans about security. Don’t trust the boss to cover his own backside, make sure you’ve got it covered.

Lesson five: Yes, be concerned about the enemy outside the gate. But be more concerned with the one inside the walls. You need to police inside the network so you know what’s going on.

Lesson six: This is a simple one. Anytime any change is made, no matter if physical, virtual, or what, you need to know about it somehow. Tickets are a great way of tracking changes, but tickets keep honest people honest and validate that change management works. What you need to implement is a way to police the fools who aren’t so honest.

Lesson seven: Probably the single most important lesson is this - - the procedures we used to have and so forth may not work anymore. When your technology changes, make sure your policies change to cover it.

With more and more SMBs adopting virtualization - are there any other lessons you live by to keep your virtual network secure?

Link to comment
Share on other sites

  • 2 weeks later...
 Share

×
×
  • Create New...