I'm not sure where to start...
First off, this is neither a "vulnerability" in RDP nor have you
illustrated any "privilege escalation."
If there is an "issue" here, it is that the admin for the company
published an RDP file to the internet that had stored credentials to
access a publically assessable RDP host. That is clearly insane.
Speaking of the company, it is apparent by your language ("the company
that the system I was auditing was owned by", etc) that you were hired
by this company to do the "audit." So I have to ask: is it standard
practice for your company to do audits for companies and then publically
post the "vulnerability" information you found? I mean, when you find
an .rdp file via a google dork that has stored credentials in it and
then post that to a public forum, it doesn't seem like you are working
in the best interest of your client. That being said, dorking for
"password" and filetype:RDP is obviously a trivial task that any script
kiddie can perform, but *you* being the one to publish it seems to put
your client at risk. If you were not getting paid for the audit, then
of course the actions you outlined on your blog are (probably) illegal.
I'm just wondering which of the above it is...
Regarding the "vulnerability," all you've illustrated is typical (and by
design) behavior of RDP options -- that being the option of specifying a
program to run upon connection. That doesn't "lock down" anything -- if
that is the way the admin decided to deploy the remote XP desktop, then
that is her problem. You merely have a remote desktop that you've run
explorer on -- this doesn't mean that you have any "magic powers" on the
operating system or that you can immediately escalate privilege. Your
example shows a "dir /s." Just because the default "bypass traverse
checking" option was not changed by the admin does not mean that you've
performed some "privileged escalation." By default, EVERYONE can bypass
traverse checking.
When you say this is a "Windows XP Sp2 System in which the administrator
had disabled pretty much everything....command prompt, right clicking,
execution of any program besides a few that he/she had given the rights
to," that is obviously iconrrect. If you got a cmd shell, then she
didn't disable cmd shell. If you executed other programs, then she
didn't restrict the access via permissions, SAFER configurations, or
anything else. How do you know these options were "disabled?" Exactly
how were they disabled? Was the user an admin already? I'm just
wondering how much we should assume that the system was properly locked
down when a stored credential RDP file was published to the internet by
the admin in the first place.
So I think we can summarize your "discovery" as such:
"You can run programs on hosts via RDP. Make sure you secure the host.
Don't publish RDP files with stored credentials." Isn't that really
about it?
RDP can be a fantastic way to securely administer systems and provide
remote applications to users. In my Microsoft Ninjitsu Blackhat
training course, we cover the secure publication of RDP hosts, Terminal
Services gateway, and RemoteApp. There are many, many options one has
to properly secure access. I think that you presenting this as any type
of "vulnerability" is irresponsible and wrong -- particularly when you
don't offer any sort of remediation advice like "don't publish stored
credentials on the internet" to those going to your website looking for
any valuable information.
t
_________________
http://www.blackhat.com/html/bh-usa-08/train-bh-usa-08-tm-ms-bbe.html
-----Original Message-----
From: listbounce@securityfocus.com
[mailto:listbounce@securityfocus.com] On Behalf Of Yousif@Vapt-Sec.com
Sent: Friday, April 04, 2008 6:57 PM
To: pen-test@securityfocus.com
Subject: Microsoft RDP Priv. Escalation
A friend of mine and I found a certain vulnerability within the RDP
allowing for further escalation to administrative access. Check it out
here: http://yousifyalda.blogspot.com/2008/04/microsoft-rdp-priv-
escalation.html
-----------------------------------------------------------------------
-
This list is sponsored by: Cenzic
Need to secure your web apps NOW?
Cenzic finds more, "real" vulnerabilities fast.
Click to try it, buy it or download a solution FREE today!
http://www.cenzic.com/downloads
-----------------------------------------------------------------------
-
------------------------------------------------------------------------
This list is sponsored by: Cenzic
Need to secure your web apps NOW?
Cenzic finds more, "real" vulnerabilities fast.
Click to try it, buy it or download a solution FREE today!
http://www.cenzic.com/downloads
------------------------------------------------------------------------
