Penetration Testing mailing list archives
RE: Remote Desktop/Term. Serv information leakage
From: <Salvador.Manaois () infineon com>
Date: Mon, 4 Jul 2005 14:32:08 +0800
How about creating a VPN tunnel to the "isolated" network and connecting via RDP through this tunnel (an overkill? =))? How about totally dissing the remote connection capabilities to the "isolated" network? ...badz... http://rancidroot.blogspot.com -----Original Message----- From: Thor (Hammer of God) [mailto:thor () hammerofgod com] Sent: Saturday, July 02, 2005 9:23 AM To: kuffya () gmail com; pen-test () securityfocus com Subject: Re: Remote Desktop/Term. Serv information leakage 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.
Current thread:
- Re: Remote Desktop/Term. Serv information leakage, (continued)
- Re: Remote Desktop/Term. Serv information leakage Eric Smith (Jul 01)
- Re: Remote Desktop/Term. Serv information leakage Kyle Maxwell (Jul 01)
- Re: Remote Desktop/Term. Serv information leakage Terry Vernon (Jul 01)
- Re: Remote Desktop/Term. Serv information leakage Joachim Schipper (Jul 01)
- RE: Remote Desktop/Term. Serv information leakage Paul Fields (Jul 01)
- Re: Remote Desktop/Term. Serv information leakage Thor (Hammer of God) (Jul 01)
- RE: Remote Desktop/Term. Serv information leakage Andre Protas (Jul 01)
- RE: Remote Desktop/Term. Serv information leakage Ha, Jason (Jul 02)
- Re: Remote Desktop/Term. Serv Information leakage kuffya (Jul 02)
- RE: Remote Desktop/Term. Serv Information leakage Paul Fields (Jul 05)
- RE: Remote Desktop/Term. Serv information leakage Salvador.Manaois (Jul 04)
- Providers blocking portscans - bad news for pentest? Petr . Kazil (Jul 04)
- RE: Providers blocking portscans - bad news for pentest? Erin Carroll (Jul 04)
- RE: Providers blocking portscans - bad news for pentest? Alexander Klimov (Jul 05)
- Re: Providers blocking portscans - bad news for pentest? RCS (Jul 05)
- Providers blocking portscans - bad news for pentest? Petr . Kazil (Jul 04)
- Re: Providers blocking portscans - bad news for pentest? Chris Brenton (Jul 04)
- Re: Providers blocking portscans - bad news for pentest? Robert BARABAS (Jul 05)
- Re: Providers blocking portscans - bad news for pentest? Maarten Hartsuijker (Jul 06)
- Message not available
- Re: Providers blocking portscans - bad news for pentest? Christoph Puppe (Jul 07)