A Quick Look at Windows 2008 Server Beta

I recently installed Windows 2008 Beta in a VMWare Machine to see what Microsoft have in store for us. Being a pentester, I mainly looked at the default security setting, so don’t go expecting a review of the shiney new GUI…

What was Tested?

I installed Windows 2008 Server RC0 Standard Edition (32-bit) Build 6001 in VMWare Server 1.0.4-56528. I configured VMWare to expect a Vista guest as there’s not explicit 2008 support just yet.

Once installed, I basically poked around a bit, looking at security-related settings that might be of interest to pentesters.

Installation Process

The install went pretty smoothly: next-next-install style. The only hicup was needing to install the VMWare Tools before the network connection would work.

You have to change your password before logging on for first time. I’d like to figure out what the password was before it was changed. Unfortuantely, as the network wasn’t configured I wasn’t able to log in remotely. My guess would be that the password is blank and that remote users can’t use blank passwords (making it secure by default). It’d be nice to verify this, though.

Network Footprint

How susceptible is this thing to remote attacks out-of-the-box? Well, not very…

After you’ve got the network working, it will automatically DHCP. Since production servers generally don’t DHCP, I didn’t dwell on this. Next you’ll notice that the host-based Firewall is on by default. No UDP, no TCP, no ICMP, nothing.

I fingerprinted it using ARP and the stack looks like Linux or Vista:

$ sudo arp-fingerprint -o '-I vmnet1' 10.0.0.0
10.0.01   01010100000     Linux 2.2, 2.4, 2.6, Vista

IPv6 is enabled by default. This might be an interesting area to investigate, but I haven’t done so yet. Presumably it will auto-configure and presumably the Firewall will protect it. It’s worth checking at some point, though.

Next, I disabled the Firewall to check what an unfiltered box would look like from a network perspective. I began by turning off the Firewall service in services.msc. This doesn’t work. You need to leave the service running and disable it from control panel – otherwise it fails safe and continues to filter traffic. Quite smart really – though not what I expected.

Here are the services bound to all interfaces (0.0.0.0):

ICMP: Echo,Timestamp

TCP ports (IPv4 and IPv6): 139, 445, 49152, 49153, 49154, 49155, 49156

UDP ports: 123, 500, 5355

These are bound to the LAN IP only: 137, 138

It’s interesting to note that UDP scan are very SLOOWWW against 2008. This is very different to 2000, 2003, XP where boxes were a dream to port scan if they weren’t running a host-based Firewall. Windows 2008 is rate-limiting its ICMP Port Unreachables. This is pretty normal among other OSs and make pentesters jobs harder. 🙁

The newer TCP and UDP services (5355, 49152-49156) will be important to understand as 2008 gets rolled out. Vista also has similar ports open. I’ve not looked at Vista much, but Symantac have written a very good paper on the Vista attack surface. They have a nice description of the additional ports.

Here’s the banner you get when you connect with smbclient:

$ smbclient //10.0.0.1/c$ -U%
Domain=[WORKGROUP] OS=[Windows Server (R) 2008 Standard 6001 Service Pack 1, v.275] Server=[Windows Server (R) 2008 Standard 6.0]

I’m not sure why “Service Pack 1” appears in the banner. Odd for an RC0 release.

Windows Services

45 Windows services are started by default. Note that this is for a server that isn’t running a Web server, FTP server, or any other kind of network service.

I wonder which ones are acutally needed. I guess most people will simply leave them all enabled.

Dumping Password Hashes

The good news (well bad news if you’re a pentester) is that use of LANMAN hashes is disabled by default: Windows will not store the LANMAN hash of your password. This is going to make cracking passwords much, much more difficult in future.

Don’t get me wrong, I’m not saying that NTLM password hashes are super-secure; I’m just saying that they’re much more secure than LANMAN hashes (they can be longer than 7 chars and are case sensitive for a start).

It’s probably worth getting a good set of rainbow tables if you haven’t already.

PwdumpX v1.0 worked well:

C:> pwdump 127.0.0.1 + +

Pwdump2 doesn’t work. This is not a great surprise since it no longer works on up-to-date XP and 2003. However, the good news is that it doesn’t crash 2008! Good news for pentesters and pentestees alike.

PwdumpX also dumps the LSA secrets. This showed something that looks vaguely interesting. I initially set my password to “root” after installation. I later found the string “ROOT#123” under DefaultPassword in the LSA secrets. Is this a coicidence, or is my password stored in the DefaultPassword field?:

2008-root

Upon changing my password the DefaultPassword did not change. This is good news as even if your initial password is saved (as it seems to be in my case), subsequent passwords are not saved in the same way. I came across this post talking about a more serious version of this problem on Windows XP.

User Accounts

Nothing interesting here:

Administrator
Guest (disabled)

Shares

The default shares are what you’d expect:

c$
admin$
ipc$

Default Tools
Some tools NOT installed by default:

tftp
rcp
telnet

This will make post-exploitation activity a bit more painful. ftp.exe is still present though and Read & Execute permissions are granted to the Users group.

Misc Security Settings

Password policy:
No password complexity
No password history
No account lockout

No auditing

Everyone can access from network

Optional Services
I haven’t looked much at IIS or any of the other services yet. One thing caught my eye about Terminal Services, though: It’s clearly explained at install time that two way of setting up Terminal Services authentication:

The old way which was vulnerable to Man In The Middle attacks (the attack that Cain implements)
The new way that authenticates using SSL certs before you log on with usernames or passwords.

I think I’m right in saying that the secure version is already available on earlier versions of Windows. However, it good see security information being made available at install time. Maybe future pentests will find less poorly configured Terminal Servers.