

RDP and the Critical Server Attack Surface - dfc
http://dankaminsky.com/2012/03/18/rdp/

======
cek
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.

~~~
InclinedPlane
On a side note, home server has seemed like an excellent project with huge
potential that MS as a whole has basically shunned and abandoned.

------
dhx
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?"_

[1] <http://www.citi.umich.edu/u/provos/papers/privsep.pdf>

[2] [http://www.openbsd.org/cgi-
bin/cvsweb/src/usr.bin/ssh/sshd.c...](http://www.openbsd.org/cgi-
bin/cvsweb/src/usr.bin/ssh/sshd.c?annotate=1.388)

[3] [http://msdn.microsoft.com/en-
us/library/cc240452%28v=prot.10...](http://msdn.microsoft.com/en-
us/library/cc240452%28v=prot.10%29.aspx)

[4] <http://aluigi.org/adv/termdd_1-adv.txt>

[5] [http://msdn.microsoft.com/en-
us/library/cc240836%28v=prot.10...](http://msdn.microsoft.com/en-
us/library/cc240836%28v=prot.10%29.aspx)

~~~
matwood
_"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.

~~~
sixcorners
We shouldn't expose sshd to the open internet? Should I be wary of services
that do?

~~~
adestefan
I'd argue that the audited security of OpenSSH is better than most VPN
solutions.

~~~
StavrosK
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.

------
stevear
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.

------
csaeyjohnellis
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

~~~
chime
I have RDP open on a different port. Could you give me an option to enter the
port#?

------
16s
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.

