Cracking & Defending a Terminal Server

This is a copy of a guide I posted to our local DEFCON group last week. Enjoy.

Cracking & Defending a Terminal Server

**** has been on my back about getting some content in here (and rightfully so), so I started pondering what type of content would be relevant to our members. My professional IT experience consists almost exclusively, and lamentably, to network administration in Windows environments. However, since I'm not the only one in this boat, I thought I would extend a collection of knowledge (read: no original thoughts here) on Terminal Services security to the group and allow for some constructive observations and reflections from others.

Trend Micro Ate My Virtual Machine

I had to run some routine security updates for a client yesterday on a host OS running Hyper-V. It was after hours, so I just shut down the two virtual machines and rebooted the physical server after the udpates. When it came back up, I went into Hyper-V Manager and tried to power on my VM's. Low and behold, where there were once two VM's, I now only saw one.

If you give a hacker a cookie, he'll ask for a session ID.

Most clients I talk to have a basic understanding that a wireless network should be "secure". They do what they can to make their home and office wireless networks have some semblence of security. However, no one seems to have an issue checking their Facebook account from the local bookstore or pulling up some sensitive company emails at the airport. People make the assumption that since they have no sensitive information on their hard drive and they are running a really good anti-whatever, safety is assured.

I can promise you, it is not. And seeing what you are searching for is not the worse thing that a hacker can do. Let me explain:

Google Launches Public DNS

Google may soon start wresting control of another important chunk of the internet. DNS (Domain Name Service) is a critical component of modern networks (including that really big one called the enter-something) and allows you to type in "www.paulhite.com" instead of the cryptic string of numbers that your computer actually uses. Now, having developed it's own presentation protocol (SPDY) and programming language (Go), Google would like to add another course to this meal: Google Public DNS.

Google's proposal is that you should use their shiny new service in place of the DNS servers commonly provided by an ISP. They currently have two IP addresses for you to use:

8.8.8.8
8.8.4.4

The benefit here is that each of these addresses could point to any number of servers, strategically placed throughout the world to give you a decent response time no matter where you are at (theoretically). And since Google already has a great resource from which to pull cached information, their DNS servers should not have to do a whole lot of searching to resolve your forward lookups. The benefit to Google is that they can use unresolved requests to display advertisements instead of traditional error messages. Google claims, however, that the primary concern is increasing the overall speed of the web.

It's all been done before though, the most popular existing service being OpenDNS at the moment. Early test results are showing little improvement with Google DNS over OpenDNS, but the tech-giant is bound to have something enticing planned to go with this service.