From: Thor (Hammer of God) (thor@hammerofgod.com)
Date: Fri Jul 01 2005 - 21:22:32 EDT
I've followed this thread a bit, and I think you (and possibly some others)
might be looking at this the wrong way... Remote Desktop accepts remote
client share offerings, so the whole ascii/text rdpclip point is moot. From
the server, you just hit \\tsclient\drive and copy whatever you want to (if
the client has shared the resource.)
This has nothing to do with Remote Desktop being "possible to configure
securely." It's more of what permissions you give the user you have allowed
to log into the server in the first place. To be pedantic, since you say
"Remote Desktop" rather than "Terminal Services" that assumes a Win2k3
machine that you have admin access to. *That's* the security issue. In
Win2k, you had 2 modes to TS-- "Remote Admin" and "Application Mode."
"Remote Admin" was admin user only, "Application Mode" giving concurrent
access to whatever userbase you allowed. In Win2k3, Remote Desktop is
installed by default (though not *enabled*) giving an admin access to the
box equivalent to "TS Remote Admin" mode in Win2k without the need to
install the "Terminal Services" bits (but still Admin)
What is the difference between the user pasting ascii text into notepad from
the client or just being able to run notepad in the remote session and
typing in whatever he wants? Or writing it in whatever compiler exists on
the server, or running DEBUG from cmd and entering and saving his own .com
file for that matter? Or whatever else the server allows you to do (Like
just browse the network and grab files off of a regular share from the
remote session?)
The real question here is not how to stop an admin from doing things on a
box that an admin can do, but rather, what the purpose of this "isolated"
network is, what resources are available to the "isolated" network, and why
they call it an "isolated" network in the first place if you can log in via
Remote Desktop from a client that is not on the "isolated" network.
What exactly are you trying to mitigate? A the actions of a malicious
admin?
t
------
*Secure your infrastructure*
Microsoft Ninjitsu: Securely Deploying MS Technologies
security training delivered by Timothy Mullen.
Registration now open for Blackhat Vegas 2005:
http://www.blackhat.com/html/bh-usa-05/train-bh-usa-05-tm.html
----- Original Message -----
From: <kuffya@gmail.com>
To: <pen-test@securityfocus.com>
Sent: Friday, July 01, 2005 7:41 AM
Subject: Remote Desktop/Term. Serv information leakage
> Hi list,
> One of our recent clients has a seperate 'isolated' network where they
> keep sensitive material. This network is not connected to the internet, is
> not physically accessible and you can only connect to it using remote
> desktop. They asked us to test if the isolated network was adequately
> protected.
> Here's what I discovered: When you start a Rem Desktop session from the
> main network to the isolated one you can actually copy and paste stuff
> across...this is only true for text not for complete files, and seems to
> be by design. What is more worrisome is that you can even copy across
> executables doing simple tricks such as
> 1)download an executable
> 2)change extension to .txt
> 3) copy (the text version) across to a notepad.
> 4)change it back to .exe
> So literally we have a significant leakage over here, introducing threats
> to the isolated network.
> I am posting this to ask your opinion on how this could be
> mitigated......I think that Remote Desktop is not possible to configure
> securely since it's not designed as such...and hence it transfers across
> anything it receives , be it mouse movements or copied & pasted text...
> So I was trying to think what would be the best solution, without spending
> a fortune on a 'secure' commercial solution, that is. Maybe something like
> SSH tunneling then Rem. Desktop or VNC or what?
> And do you think this 'bug' is something investigating any further? Is it
> something you people knew of?
>
> Thanks a lot.
>
>
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:54:31 EDT