Terminal Server Security

I am working with an organization that is setting up remote user access
to a 2003 Server system. They expect only one to two users
simultaneously, but need a reasonable level of security. My original
designs include the use of a VPN in front of the connection. I read a
few articles that claim the encryption and security of the terminal
services on 2003 are such that you don't need a VPN.

For arguments sake, I will suspend my prejudicial judgement about
letting any Microsoft service support Internet services :) Can anyone
make a case for why setting the client encryption setting to "High" (or
is there something better) is as good as using a VPN. Assume for
arguments sake that I would authenticate both RSA tokens. Likewise,
what are the arguments against hanging a terminal server out on the Net?
Again, assume I use the available security options to configure it.

Todd H. wrote:
<CUT>
> Isn't terminal server also vulnerable to man in the middle?
>
I would think that 128 bit RC4 would alleviate this, but I need to do
more research to be sure.

dMn

dMn <daMian@nospam.net> writes:

> I am working with an organization that is setting up remote user
> access to a 2003 Server system. They expect only one to two users
> simultaneously, but need a reasonable level of security. My original
> designs include the use of a VPN in front of the connection. I read a
> few articles that claim the encryption and security of the terminal
> services on 2003 are such that you don't need a VPN.
>
> For arguments sake, I will suspend my prejudicial judgement about
> letting any Microsoft service support Internet services :) Can anyone
> make a case for why setting the client encryption setting to "High"
> (or is there something better) is as good as using a VPN. Assume for
> arguments sake that I would authenticate both RSA tokens. Likewise,
> what are the arguments against hanging a terminal server out on the
> Net? Again, assume I use the available security options to configure
> it.

Not sure of the specifics, but I'd be hesitant too. here's a place to
wittle from:

http://search.securityfocus.com/swse...shlastmodified

Isn't terminal server also vulnerable to man in the middle?

--
Todd H.
http://www.toddh.net/

Sebastian Gottschalk <seppi@seppig.de> writes:

> Todd H. wrote:
>
> > Not sure of the specifics, but I'd be hesitant too. here's a place to
> > wittle from:
> >
> > http://search.securityfocus.com/swse...shlastmodified
> >
> > Isn't terminal server also vulnerable to man in the middle?
>
> Only if the server itself is malicious. This is about the only known
> vulnerability that remained since RDP 5.1.

FWIW, this paper from May of 05 indicates that invisible mitm of rdp
are still possible as of then at least, and was using RDP 5.2. They
claim the patch that Micrsoft issued actually didn't fix the problem:

http://www.oxid.it/downloads/rdp-gbu.pdf

Cain and Abel supposedly implements the attack, but I've not
personally tried it.


Best Regards,
--
Todd H.
http://www.toddh.net/

Todd H. wrote:
> Sebastian Gottschalk <seppi@seppig.de> writes:
>
>> Todd H. wrote:
>>
>>> Not sure of the specifics, but I'd be hesitant too. here's a place to
>>> wittle from:
>>>
>>> http://search.securityfocus.com/swse...shlastmodified
>>>
>>> Isn't terminal server also vulnerable to man in the middle?
>> Only if the server itself is malicious. This is about the only known
>> vulnerability that remained since RDP 5.1.
>
> FWIW, this paper from May of 05 indicates that invisible mitm of rdp
> are still possible as of then at least, and was using RDP 5.2. They
> claim the patch that Micrsoft issued actually didn't fix the problem:
>
> http://www.oxid.it/downloads/rdp-gbu.pdf
>
> Cain and Abel supposedly implements the attack, but I've not
> personally tried it.
>
>
> Best Regards,

Great, thanks for the references. It seems from all the information I
read, that the servicing application is as vulnerable as any other
network service, and MS will respond to security issues about the same
rate that they respond to issues with IIS. They had a good run of DoS
vuls to the server.

As for the protocol, the session setup leaves much to be desired and the
handling of keys for encryption definitely gets a D- (If I'm being
generous). Man in the Middle attacks are a result of the failure of the
client to adequately cryptographically authenticate the server. So, the
MITM is effective if the attacker can get in the middle of session setup
and set itself up to proxy the communications.

There were some discussions in 2002 about improper use of entropy data
allowing replay attacks to succeed. But I can't find anything reporting
injection of custom data, or decryption of the cipher stream.

Please let me know if my conclusions are wrong.

So, my gut tells me that using RDP with encryption across a somewhat
trusted network, like across a corporate enterprise to access a higher
security network or system is probably acceptable without a VPN. But
I'm not comfortable exposing the service to the Internet without someway
to legitimately authenticate that the client and server are talking to
each other, therefore, a VPN connection is a must.

dMn

dMn <daMian@nospam.net> writes:
> So, my gut tells me that using RDP with encryption across a somewhat
> trusted network, like across a corporate enterprise to access a higher
> security network or system is probably acceptable without a VPN.

Many Large Companies would agree with you.

> But I'm not comfortable exposing the service to the Internet without
> someway to legitimately authenticate that the client and server are
> talking to each other, therefore, a VPN connection is a must.

Many Large Companies would also agree with that.


Best Regards,
--
Todd H.
http://www.toddh.net/