In Windows Vista and Windows 7, the ability to have a PC act as a RDP server (host) is limited to the server SKUs and Ultimate. Windows Starter, Windows Home, and Windows Home Premium do not have this feature (it's actually there, but requires a hack to enable).
This was a business policy to help differentiate the Pro & Ultimate versions from the cheaper Home versions.
When we were building Windows Home Server, I fought hard to get the policy of not supporting Remote Desktop (host) in Windows Vista/7 Home and Home Premium changed.
We wanted to make it so that WHS could more easily enable people to connect into their home computers remotely via WHS, but the policy meant that only Windows Vista/7 Ultimate and Pro could act as a RDP host which severely limited the reach of this feature.
It is probably a good thing (for MS) that I failed to convince the Windows business leaders to change this policy; imagine how many PCs there'd be out there if in 2003 I had gotten this policy changed and had been successful in making RDP popular amongst non-power users...
As an aside, I bet sizable # of those RDP end points Dan found are actually running Windows Home Server. WHS (which is really a version of Windows Server 2003) enabled the RDP host by default because that's what the Windows Home Server console uses. It also used UPnP to enable port forwarding for remote access to the server. Users' have to opt into this feature, but many do...
The good news (for WHS users) is by default WHS automatically takes Windows updates; users have to explicitly opt-out and we intentionally tried to push them away from opting-out of updates. So almost all WHS boxes probably got the patch on Tuesday. I know mine did.
I run a Windows shop and for the longest time we used a third party product called Radmin for our remote administration. Finally, after some time we switched over to RDP for a number of reasons... but one of the top ones is simply that is has such massive adoption. Any vulnerability that bubbles to the surface will be announced from the highest mountains as is the case here. When I was using a third-party product there could have been a critical update released and I don't feel I would have heard through the grapevine for quite some time.
In my opinion, having a vanilla Microsoft stack is useful in a lot ways, one of them being that news travels fast within the Microsoft ecosystem.
I agree with the author though, nothing is more eye roll inducing then when some unhelpful fellow chimes in with "Why are you doing it that way?" and 'that way' is the way million and millions of people are doing it.
A mate and I have set up a free web-based tool to help folk check their exposure to this bug. it's at http://rdpcheck.com. i encourage you to tell those who should know
We limit RDP access via Cisco ACLs at our border routers. So that only the vendor IPs that require RDP access may get to those machines. And, we turn it on when they call opening a ticket for access. We don't leave it open to them all the time.
Is anyone familiar with the RDP implementation on Windows and how it handles privilege separation pre and post authentication?
Niels Provos, Markus Friedl, Peter Honeyman released a paper in 2003 that analysed the number of privileged (8,391) vs. unprivileged (17,589) lines of code that are executed by OpenSSH [1]. These figures included calls to libraries such as OpenSSL and zlib. A key point from the paper: "Privilege separation prevents known security vulnerabilities in prior OpenSSH versions including some that were unknown at the time of its implementation."
OpenSSH has changed significantly over the past decade and I haven't been able to locate more recent analysis of the privileged:unprivileged LoC ratio in OpenSSH. For the brave, the source code provides a good indication of the current state of OpenSSH[2] and the amount and type of code executed in privileged and unprivileged modes.
Privileged mode is needed to open low numbered ports (<1024), read/process the private host key and fork new processes post authentication assuming the identity of another user. A great deal of effort and research has been put into ensuring that only the minimal amount of privileged code is executed. Where OpenSSH code can be executed within an unprivileged process, it is.
RDP appears to have a much longer and significantly more complex session initiation process [3]. MS12-020[4] indicates the vulnerability occurs during the pre-authentication stage (Client MCS Connect Initial PDU with GCC Conference Create Request [5]). Thus it appears the RDP implementation on Windows doesn't utilise granular privilege separation pre-authentication? How about post-authentication privilege separation?
Privilege separation is very important.
I rephrase the question (assuming Microsoft's implementation doesn't utilise granular privilege separation by default):
"Who could possibly be so stupid as to recommend or use RDP on the open internet knowing the implementation doesn't have granular and well designed privilege separation?"
"Who could possibly be so stupid as to recommend or use RDP on the open internet knowing the implementation doesn't have granular and well designed privilege separation?"
The bigger question in my mind is why put anything on the open internet unless you have to? RDP is great, but put it behind some sort of VPN solution or tunnel it over ssh. This goes for any service that should be private use.
The name of the game in security is shrinking the potential attack surface area to as small as possible, and having multiple layers of checks.
Sure, but there are still configuration problems. I remember having once set the root password to "", thinking it will lock everything out. Turns out that it only locks it for login, but not email server authentication. Someone managed to send emails as root@mybox, logging in with a blank password.
I realize this isn't OpenSSH, but there will always be stupid users. Exposing as little as you can is a good idea.
It varies depends on whether Network Level Authenication (NLA) is used. When NLA is not used, the Terminal Server has to open up a session to display the Winlogon window for authentication and the user types the username/password through this session. When NLA is used, the RDP client displays this window and then the session is started after the username/password is validated which reduces the pre-authentication attack surface drastically (indeed requiring NLA is listed as a workaround).
"Who could possibly be so stupid as to recommend or use RDP on the open internet ..."
Are stats posted of who is included in the scan?
I can't imagine any pro putting RDP outside a firewall, but I can easily see Henry Homeowner with his PC attached directly to his cable modem, accessing his PC remotely.
> "Who could possibly be so stupid as to recommend or use RDP on the open internet knowing the implementation doesn't have granular and well designed privilege separation?"
This was a business policy to help differentiate the Pro & Ultimate versions from the cheaper Home versions.
When we were building Windows Home Server, I fought hard to get the policy of not supporting Remote Desktop (host) in Windows Vista/7 Home and Home Premium changed.
We wanted to make it so that WHS could more easily enable people to connect into their home computers remotely via WHS, but the policy meant that only Windows Vista/7 Ultimate and Pro could act as a RDP host which severely limited the reach of this feature.
It is probably a good thing (for MS) that I failed to convince the Windows business leaders to change this policy; imagine how many PCs there'd be out there if in 2003 I had gotten this policy changed and had been successful in making RDP popular amongst non-power users...
As an aside, I bet sizable # of those RDP end points Dan found are actually running Windows Home Server. WHS (which is really a version of Windows Server 2003) enabled the RDP host by default because that's what the Windows Home Server console uses. It also used UPnP to enable port forwarding for remote access to the server. Users' have to opt into this feature, but many do...
The good news (for WHS users) is by default WHS automatically takes Windows updates; users have to explicitly opt-out and we intentionally tried to push them away from opting-out of updates. So almost all WHS boxes probably got the patch on Tuesday. I know mine did.