Re: [Full-disclosure] Paypal XSS Vulnerability - Resolved

[Randal T. Rioux]

I find it humorous that an organization that pretends to be a bank and
regularly steals money from its members has the balls to distribute a
"PayPal Responsible Disclosure Policy."

Good luck with that.

Randy


On Fri, March 26, 2010 10:49 pm, Orbeton, Jon wrote:
> All:
>
> The XSS vulnerability reported below was addressed at approximately 17:45
> PDT today.
>
> For information about how to report security issues to PayPal, please
> refer to the PayPal Responsible Disclosure Policy documented here:
> https://www.paypal.com/cgi-bin/webscr?cmd=xpt/cps/securitycenter/general/ReportingSecurityIssues-outside
>
> Site security issues should be reported to:
>   sitesecur...@paypal.com
>
> All reports will be handled professionally and quickly. A PGP key is
> available at the URL above.
>
>
> Thanks,
> Jon Orbeton
>
> PayPal, an eBay Company
>
> 
>
> From: Wesley Kerfoot 
> Date: Fri, 26 Mar 2010 15:46:09 -0400
>
> Paypal is affected by an XSS vulnerability where it fails to validate
> input for the following url:
>
> https://www.paypal.com/xclick/business=
>
> One can add arbitrary javascript with no need for any filter evasion.
>
> https://www.paypal.com/xclick/business= alert("xss");
> 
>
>
> As far as I know only the above url is affected. All of the usual XSS
> attacks will work with this.
>
> Cheers.
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>


___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Security system

[Oscar Bacelar]

Try arduino + internet.

2010/3/27 

> Any one got any ides how I would program a system to call me from a
> voip network to alert me of a home security breach.
>
> Sent from my iPhone
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Security system

[Junk Meat]

Is there any movement in your home when you are not there (i.e. pets, 
etc.)?  You may be able to use a web cam to alert you of any movement in 
the house if it picks up anything other then the initial background when 
you start the recording process.  There are a lot of web cams that will 
only record when movement is detected, I'm sure by now the software that 
some of these vendors have may have an alerting mechanism in there by 
now as well.

-Shawn

On 3/27/2010 1:08 PM, ja...@smithwaysecurity.com wrote:
> Any one got any ides how I would program a system to call me from a
> voip network to alert me of a home security breach.
>
> Sent from my iPhone
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>
>

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Full-disclosure] Security system

[james]

Any one got any ides how I would program a system to call me from a  
voip network to alert me of a home security breach.

Sent from my iPhone

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Possible RDP vulnerability

[Thor (Hammer of God)]

That's funny - it was kind of a "trick answer" too. ;)

You can indeed "do that" with Vista (kind of) and Windows 7 (definitely) in 
combination with Server 2008.  I haven't messed with Server 2003 in years, and 
have no plans to. 

Here's how you do that, but before I go there, let's point out the "spirit" of 
the "trick question" so those playing along at home understand the real 
ramifications of what you are talking about, and then I'll detail the "right" 
answer (you can do whatever you want in regard to blogging, of course ;).

In general, you don't control the base connection methods a user wants to use.  
This is because, again in general, you don't tell the user what to do or how to 
do it on their own system.  However, with group policy and RDP settings, you 
can indeed maneuver the user into "submission."  I say maneuver because if the 
user is a local admin, then most bets are off.  My initial answer was correct, 
however, only with the following blanks filled in (thus the "trick" part).  

With GP you can control the behavior of what happens if the client cannot 
validate the identity of the server.   Thus, you can say "if you don't trust 
the server, you don't connect."  Further, you can control what certificate 
chains are being trusted; ie, only corp resources.  Therefore, you can (for the 
most part) keep the users from establishing connections to "rogue" servers, or 
at least, make it obvious to them.  The video you showed failed to take into 
account that the "rogue" server in question had to already have an account 
created for the user, which kind of is a "show stopper."  I mean, if you 
already have their username and password to create the account for them to log 
into, then all bets are off.   Continuing, given the fact you can (again, for 
the most part) control what RDP hosts a user can connect to, you then leverage 
host-based GPO that prevents the user from sharing clipboard, disks, printers, 
etc upon connection.  That setting is enforced by the server. 

So, in combination, you can indeed use Group Policy to prevent users from 
sharing their disks.  I will call that an "I win" and request some other prize 
other than your blogging about dude. :D

Let's take things one step further for those who are interested in this.  
Before allowing people to just connect to your server, I would suggest that the 
connect is based on gateway services that require a certificate to connect up 
to in the first place.  Then, all the hubbub about Dorphly Diprod user 
connecting up and "bypassing security" and all that other crap is obviated.  
Further, simply deploy the connectoid via a signed RDP file.  Done.  If they 
try to change the file, it won't work anymore.  Super easy stuff, and it goes a 
long way toward helping to secure one's RDP access environment.

But as a "Big Time Security Professional" you probably knew that :)  I guess I 
should now go read your blog to see if my prize would be a good thing or a bad 
thing :-p

t





-Original Message-
From: full-disclosure-boun...@lists.grok.org.uk 
[mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of Mr. Hinky Dink
Sent: Saturday, March 27, 2010 11:48 AM
To: Full-Disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Possible RDP vulnerability

In your case, had you answered the question correctly I would have promised to 
never (again) blog about you arguing with Craig S. Wright.

However, it was a trick question.  There is no way to do it with Group Policy 
(at least not with XP and Server 2003... maybe they changed that in Windows 
Vis7a and Server 2008, but I really haven't kept up with the tech).

- Original Message -
From: "Thor (Hammer of God)" 
To: "Mr. Hinky Dink" ; 
Sent: Saturday, March 27, 2010 12:09 PM
Subject: RE: [Full-disclosure] Possible RDP vulnerability


Oh, sorry I read the question wrong.  Just don't allow them to "attach" 
their local drives.  Simple.

Still, what do I win?

t


___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Possible RDP vulnerability

[Benji]

>>However, it was a trick question.

ZZINGG

On Sat, Mar 27, 2010 at 6:48 PM, Mr. Hinky Dink wrote:

> In your case, had you answered the question correctly I would have promised
> to never (again) blog about you arguing with Craig S. Wright.
>
> However, it was a trick question.  There is no way to do it with Group
> Policy (at least not with XP and Server 2003... maybe they changed that in
> Windows Vis7a and Server 2008, but I really haven't kept up with the tech).
>
> - Original Message -
> From: "Thor (Hammer of God)" 
> To: "Mr. Hinky Dink" ;
> 
> Sent: Saturday, March 27, 2010 12:09 PM
> Subject: RE: [Full-disclosure] Possible RDP vulnerability
>
>
> Oh, sorry I read the question wrong.  Just don't allow them to "attach"
> their local drives.  Simple.
>
> Still, what do I win?
>
> t
>
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Possible RDP vulnerability

[Mr. Hinky Dink]

In your case, had you answered the question correctly I would have promised 
to never (again) blog about you arguing with Craig S. Wright.

However, it was a trick question.  There is no way to do it with Group 
Policy (at least not with XP and Server 2003... maybe they changed that in 
Windows Vis7a and Server 2008, but I really haven't kept up with the tech).

- Original Message - 
From: "Thor (Hammer of God)" 
To: "Mr. Hinky Dink" ; 

Sent: Saturday, March 27, 2010 12:09 PM
Subject: RE: [Full-disclosure] Possible RDP vulnerability


Oh, sorry I read the question wrong.  Just don't allow them to "attach" 
their local drives.  Simple.

Still, what do I win?

t


___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Possible RDP vulnerability

[Thor (Hammer of God)]

I’m not sure what you are referring to.  I never made any recommendation to 
‘sidestep’ desktop restrictions at all.   Rather, I indicated that “desktop 
restrictions” (and thank you for the use of that far more appropriate term) 
were not actual security access controls, but rather UI access mechanisms, and 
that they should not be relied upon to enforce security policy and/or access 
authorization.

I actually recommend deploying UI restrictions in RDP environments where you 
must give the user direct control of the desktop.  To be sure, prior to 
deploying such solutions, I recommend that RemoteApp or similar types of 
application-specific publishing scenarios are considered first (though they 
also carry risks to be aware of).  So while not specific security controls, I 
do put them under the Security in Depth umbrella and recommend that due 
diligence in planning and execution of RDP access models is exercised, which 
would include such additional restriction mechanisms.  I apologize if my 
statements were interpreted as “don’t use desktop restrictions.”

The initial recommendation was to treat the security of an RDP session as one 
would local desktop access; that being consideration of overall permissions, 
SAFER/AppLocker application, and other desktop-based host security measures.

t

From: Dan Kaminsky [mailto:d...@doxpara.com]
Sent: Saturday, March 27, 2010 9:28 AM
To: Thor (Hammer of God)
Cc: wicked clown; Full-Disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Possible RDP vulnerability

You say this, but I note with interest and approval that your recommendation 
was to sidestep desktop 'restrictions' entirely in favor of certificate based 
access control.

Quantization of security and all that.

On Mar 27, 2010, at 11:56 AM, "Thor (Hammer of God)" 
mailto:t...@hammerofgod.com>> wrote:

No, they don’t “always” win.  Maybe back with windows 2000, or XP, but not with 
Windows 7 anyway.  Of course, none of this does anything to stop them from 
booting off a CD and owning the box that way.

However, I do agree that people need to fully understand exactly what they are, 
and more importantly, are NOT doing insofar as security is concerned when it 
comes to access to local assets.

t

From: Dan Kaminsky [mailto:d...@doxpara.com]
Sent: Saturday, March 27, 2010 7:37 AM
To: wicked clown
Cc: Thor (Hammer of God); 
Full-Disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Possible RDP vulnerability

So it's a super common thing for schools to have 'locked down' Windows 
desktops, and even more common for even slightly nerdy kids to take the 
lockdown as a challenge to be  defeated.

The point of course is that the kids always win:  At the point somebody has the 
set of privileges exposed by any amount of desktop access, constraining 
execution for them is similar to getting the idea that, perhaps, it would be 
the responsible thing to open discussions around managing the open state of the 
barn door.



On Mar 27, 2010, at 7:39 AM, wicked clown 
mailto:wickedclow...@googlemail.com>> wrote:
I think we are two different pages :)

what I was trying to show if you have a group policy that will only run a 
certain applications for example notepad.exe, the user is unable to access my 
computer, run or the start button or any other application. There would be a 
shortcut on the desktop for just notepad.exe for the user to execute.

The user use RDP to connect to the terminal server so they can access 
notepad.exe but if you change the application in the programs tab under the RDP 
client the user is now able to run any application on the terminal server, the 
user then execute internet explorer and download a modified cmd.exe and save it 
in the c:\windows\temp (even if you denied access to the hard drive users can 
still write to the temp folder) now I log off the rdp client change the program 
to point to c:\windows\temp\cmd.exe, I how have access to the command prompt 
with access to the command prompt I can run any other application or access 
other parts of the server they are not allowed to access.

That is what my video was try to demostrate that even denying access to 
applications on the server you can still execute applications from that server.

But as been mention if you put that single click in the RDP-tcp on the server 
then the user is unable to execute other applications.

I have been doing some further checks and I can confirm I have seen this affect 
about 90% of so called secure systems with group policy, but will execute 
normally block applications. I have even found systems on the Internet that are 
vulnerable to this.

I think we may have to agree to disagree on this subject. But thank you for you 
views and comments.
On Fri, Mar 26, 2010 at 9:29 PM, Thor (Hammer of God) 
mailto:t...@hammerofgod.com>> wrote:
I think you still misunderstand.

The option you refer to has nothing to do with “locking down” the server.  When 
you say t

Re: [Full-disclosure] Possible RDP vulnerability

[Dan Kaminsky]

You say this, but I note with interest and approval that your  
recommendation was to sidestep desktop 'restrictions' entirely in  
favor of certificate based access control.


Quantization of security and all that.

On Mar 27, 2010, at 11:56 AM, "Thor (Hammer of God)" > wrote:


No, they don’t “always” win.  Maybe back with windows 2000, or  
XP, but not with Windows 7 anyway.  Of course, none of this does any 
thing to stop them from booting off a CD and owning the box that way.




However, I do agree that people need to fully understand exactly  
what they are, and more importantly, are NOT doing insofar as  
security is concerned when it comes to access to local assets.




t



From: Dan Kaminsky [mailto:d...@doxpara.com]
Sent: Saturday, March 27, 2010 7:37 AM
To: wicked clown
Cc: Thor (Hammer of God); Full-Disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Possible RDP vulnerability



So it's a super common thing for schools to have 'locked down'  
Windows desktops, and even more common for even slightly nerdy kids  
to take the lockdown as a challenge to be  defeated.




The point of course is that the kids always win:  At the point  
somebody has the set of privileges exposed by any amount of desktop  
access, constraining execution for them is similar to getting the  
idea that, perhaps, it would be the responsible thing to open  
discussions around managing the open state of the barn door.








On Mar 27, 2010, at 7:39 AM, wicked clown > wrote:


I think we are two different pages :)

what I was trying to show if you have a group policy that will only  
run a certain applications for example notepad.exe, the user is  
unable to access my computer, run or the start button or any other  
application. There would be a shortcut on the desktop for just  
notepad.exe for the user to execute.


The user use RDP to connect to the terminal server so they can  
access notepad.exe but if you change the application in the programs  
tab under the RDP client the user is now able to run any application  
on the terminal server, the user then execute internet explorer and  
download a modified cmd.exe and save it in the c:\windows\temp (even  
if you denied access to the hard drive users can still write to the  
temp folder) now I log off the rdp client change the program to  
point to c:\windows\temp\cmd.exe, I how have access to the command  
prompt with access to the command prompt I can run any other  
application or access other parts of the server they are not allowed  
to access.


That is what my video was try to demostrate that even denying access  
to applications on the server you can still execute applications  
from that server.


But as been mention if you put that single click in the RDP-tcp on  
the server then the user is unable to execute other applications.


I have been doing some further checks and I can confirm I have seen  
this affect about 90% of so called secure systems with group policy,  
but will execute normally block applications. I have even found  
systems on the Internet that are vulnerable to this.


I think we may have to agree to disagree on this subject. But thank  
you for you views and comments.


On Fri, Mar 26, 2010 at 9:29 PM, Thor (Hammer of God) > wrote:


I think you still misunderstand.



The option you refer to has nothing to do with “locking down” the  
server.  When you say things like “a locked down group policy that i 
s tighter than a ducks bum” what exactly are you talking about?




Selecting “don’t allow a startup program to be run” simply  
forces the desktop to be shown as opposed to an application one may  
specify.  If I initiate a session and tell it to run calc.exe, then  
calc.exe is what it presented upon connection.  It’s a shortcut for  
the user.  If at the server I don’t allow applications to be specifi 
ed, then it won’t run them and will default to the desktop.  But I c 
an still go “start, run, calc” and it will run fine if I have  
permissions to run it.  AppLocker is a great way to lock down the ho 
st environment, whether RDP or not.




And you are quite incorrect about “no user based control”  
stopping you.  As mentioned, AppLocker could have prevented it had i 
t been deployed “properly.”  Well, it would help, anyway.
Depends on the manner in which the attack was carried out, of course 
, but that has nothing whatsoever to do with the setting in RDP.  De 
ploying RDP to untrusted users or malicious users is not good policy 
; as such, you need to take extra care in securing RDP hosts by usin 
g permissions and other restrictions.




I think you need to relax a little and think about what you post – s 
aying things like “a GPO tighter to a ducks bum” and “open to  
total pwnage” and “nothing would stop me” sounds a bit  
hyperbolic (in addition to being incorrect).




To summarize, your concerns have nothing to do with RDP security  
settings as you have presented them.  MS10-015 is certainly an  
important issue 

Re: [Full-disclosure] Possible RDP vulnerability

[Thor (Hammer of God)]

Oh, sorry I read the question wrong.  Just don't allow them to "attach" their 
local drives.  Simple.

Still, what do I win?

t

-Original Message-
From: full-disclosure-boun...@lists.grok.org.uk 
[mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of Mr. Hinky Dink
Sent: Saturday, March 27, 2010 8:51 AM
To: Full-Disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Possible RDP vulnerability

As far as RDP is concerned, it's much simpler (and more fun!) to host an Evil 
RDP Server than it is to hack into one.  There is no end to the shenanigans you 
can create or the havoc you can wreak, if you're into that kind of thing (just 
sayin'... as a Big Time Security Professional(tm), I'm not).

For instance, this low quailty, seldom seen, crappy video (barely) shows how 
you can get a virus/Trojan/worm/etc. if you are insane enough to attach your 
local drives to an untrusted RDP server (the popup at the end is the AV going 
off).

http://www.youtube.com/watch?v=UwhqJSmYm_4

EXTRA CREDIT: devise a Group Policy that will prevent users from attaching 
their local drives to a remote RDP server.

- Original Message -
From: wicked clown
To: Thor (Hammer of God)
Cc: Full-Disclosure@lists.grok.org.uk
Sent: Saturday, March 27, 2010 7:39 AM
Subject: Re: [Full-disclosure] Possible RDP vulnerability


I think we are two different pages :)

what I was trying to show if you have a group policy that will only run a 
certain applications for example notepad.exe, the user is unable to access 
my computer, run or the start button or any other application. There would 
be a shortcut on the desktop for just notepad.exe for the user to execute.

/ 

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Possible RDP vulnerability

[Thor (Hammer of God)]

Simple.  Just require TLS with a corp cert to connect at the server and don't 
allow clients to connect to hosts without trusting the cert.

What do I win?

t

-Original Message-
From: full-disclosure-boun...@lists.grok.org.uk 
[mailto:full-disclosure-boun...@lists.grok.org.uk] On Behalf Of Mr. Hinky Dink
Sent: Saturday, March 27, 2010 8:51 AM
To: Full-Disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Possible RDP vulnerability

As far as RDP is concerned, it's much simpler (and more fun!) to host an Evil 
RDP Server than it is to hack into one.  There is no end to the shenanigans you 
can create or the havoc you can wreak, if you're into that kind of thing (just 
sayin'... as a Big Time Security Professional(tm), I'm not).

For instance, this low quailty, seldom seen, crappy video (barely) shows how 
you can get a virus/Trojan/worm/etc. if you are insane enough to attach your 
local drives to an untrusted RDP server (the popup at the end is the AV going 
off).

http://www.youtube.com/watch?v=UwhqJSmYm_4

EXTRA CREDIT: devise a Group Policy that will prevent users from attaching 
their local drives to a remote RDP server.

- Original Message -
From: wicked clown
To: Thor (Hammer of God)
Cc: Full-Disclosure@lists.grok.org.uk
Sent: Saturday, March 27, 2010 7:39 AM
Subject: Re: [Full-disclosure] Possible RDP vulnerability


I think we are two different pages :)

what I was trying to show if you have a group policy that will only run a 
certain applications for example notepad.exe, the user is unable to access 
my computer, run or the start button or any other application. There would 
be a shortcut on the desktop for just notepad.exe for the user to execute.

/ 

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Possible RDP vulnerability

[Mr. Hinky Dink]

As far as RDP is concerned, it's much simpler (and more fun!) to host an 
Evil RDP Server than it is to hack into one.  There is no end to the 
shenanigans you can create or the havoc you can wreak, if you're into that 
kind of thing (just sayin'... as a Big Time Security Professional™, I'm 
not).

For instance, this low quailty, seldom seen, crappy video (barely) shows how 
you can get a virus/Trojan/worm/etc. if you are insane enough to attach your 
local drives to an untrusted RDP server (the popup at the end is the AV 
going off).

http://www.youtube.com/watch?v=UwhqJSmYm_4

EXTRA CREDIT: devise a Group Policy that will prevent users from attaching 
their local drives to a remote RDP server.

- Original Message - 
From: wicked clown
To: Thor (Hammer of God)
Cc: Full-Disclosure@lists.grok.org.uk
Sent: Saturday, March 27, 2010 7:39 AM
Subject: Re: [Full-disclosure] Possible RDP vulnerability


I think we are two different pages :)

what I was trying to show if you have a group policy that will only run a 
certain applications for example notepad.exe, the user is unable to access 
my computer, run or the start button or any other application. There would 
be a shortcut on the desktop for just notepad.exe for the user to execute.

/ 

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Possible RDP vulnerability

[Thor (Hammer of God)]

No, they don’t “always” win.  Maybe back with windows 2000, or XP, but not with 
Windows 7 anyway.  Of course, none of this does anything to stop them from 
booting off a CD and owning the box that way.

However, I do agree that people need to fully understand exactly what they are, 
and more importantly, are NOT doing insofar as security is concerned when it 
comes to access to local assets.

t

From: Dan Kaminsky [mailto:d...@doxpara.com]
Sent: Saturday, March 27, 2010 7:37 AM
To: wicked clown
Cc: Thor (Hammer of God); Full-Disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Possible RDP vulnerability

So it's a super common thing for schools to have 'locked down' Windows 
desktops, and even more common for even slightly nerdy kids to take the 
lockdown as a challenge to be  defeated.

The point of course is that the kids always win:  At the point somebody has the 
set of privileges exposed by any amount of desktop access, constraining 
execution for them is similar to getting the idea that, perhaps, it would be 
the responsible thing to open discussions around managing the open state of the 
barn door.



On Mar 27, 2010, at 7:39 AM, wicked clown 
mailto:wickedclow...@googlemail.com>> wrote:
I think we are two different pages :)

what I was trying to show if you have a group policy that will only run a 
certain applications for example notepad.exe, the user is unable to access my 
computer, run or the start button or any other application. There would be a 
shortcut on the desktop for just notepad.exe for the user to execute.

The user use RDP to connect to the terminal server so they can access 
notepad.exe but if you change the application in the programs tab under the RDP 
client the user is now able to run any application on the terminal server, the 
user then execute internet explorer and download a modified cmd.exe and save it 
in the c:\windows\temp (even if you denied access to the hard drive users can 
still write to the temp folder) now I log off the rdp client change the program 
to point to c:\windows\temp\cmd.exe, I how have access to the command prompt 
with access to the command prompt I can run any other application or access 
other parts of the server they are not allowed to access.

That is what my video was try to demostrate that even denying access to 
applications on the server you can still execute applications from that server.

But as been mention if you put that single click in the RDP-tcp on the server 
then the user is unable to execute other applications.

I have been doing some further checks and I can confirm I have seen this affect 
about 90% of so called secure systems with group policy, but will execute 
normally block applications. I have even found systems on the Internet that are 
vulnerable to this.

I think we may have to agree to disagree on this subject. But thank you for you 
views and comments.
On Fri, Mar 26, 2010 at 9:29 PM, Thor (Hammer of God) 
mailto:t...@hammerofgod.com>> wrote:
I think you still misunderstand.

The option you refer to has nothing to do with “locking down” the server.  When 
you say things like “a locked down group policy that is tighter than a ducks 
bum” what exactly are you talking about?

Selecting “don’t allow a startup program to be run” simply forces the desktop 
to be shown as opposed to an application one may specify.  If I initiate a 
session and tell it to run calc.exe, then calc.exe is what it presented upon 
connection.  It’s a shortcut for the user.  If at the server I don’t allow 
applications to be specified, then it won’t run them and will default to the 
desktop.  But I can still go “start, run, calc” and it will run fine if I have 
permissions to run it.  AppLocker is a great way to lock down the host 
environment, whether RDP or not.

And you are quite incorrect about “no user based control” stopping you.  As 
mentioned, AppLocker could have prevented it had it been deployed “properly.”  
Well, it would help, anyway.   Depends on the manner in which the attack was 
carried out, of course, but that has nothing whatsoever to do with the setting 
in RDP.  Deploying RDP to untrusted users or malicious users is not good 
policy; as such, you need to take extra care in securing RDP hosts by using 
permissions and other restrictions.

I think you need to relax a little and think about what you post – saying 
things like “a GPO tighter to a ducks bum” and “open to total pwnage” and 
“nothing would stop me” sounds a bit hyperbolic (in addition to being 
incorrect).

To summarize, your concerns have nothing to do with RDP security settings as 
you have presented them.  MS10-015 is certainly an important issue for 
local-host based attacks, of which RDP is one.  One’s mitigation efforts should 
indeed include RDP hosts.  The takeaway from that is to apply more due 
diligence to securing RDP deployments as one would with any asset you give 
users local access to.   RDP should not be viewed as a security mechanism, but 
rath

Re: [Full-disclosure] Possible RDP vulnerability

[Thor (Hammer of God)]

Well, it's not really an "agree to disagree" thing.  You are technically 
incorrect in your dissertation, whether we both agree or not.  We can agree not 
to care what each other's opinions are, but the tech is the tech.

Many people have misconceptions of how RDP "security" works and what it is; 
when I see posts like this, I think it is important to use these types of 
misunderstandings as "learning opportunities."

I've asked a couple of times now, but you've not given any details on what 
"group policy" object you are using to ensure that "only a certain application 
will run" in your "so called secure systems with group policy."

You are clearly confusing authorization to execute a program with a "start 
menu" item.   You say "the user is unable to access my computer, run or the 
start button or any other application" but you have "a shortcut to notepad."  
You are simply describing a menu system for the user to execute notepad.exe, 
and NOT anything that enforces that only certain programs run.

You are not "denying access" to any programs here.  You are just taking away 
the default menu system for the user to get to the program.  Even in this case, 
if you took notepad.exe off the desktop, all I have to do in my RDP session is 
hit CTRL+ALT+END and run Task Manager.  I can the go File, New Task, and run 
whatever I want.  You are further incorrect about "if you put a single click in 
the RDP-tcp on the server then the user is unable to execute other 
applications."  I can still EXECUTE whatever I have permissions to EXECUTE.

You really need to understand that what you are doing is just playing around 
with the windows/menu systems that the users "sees."  You are doing NOTHING to 
"secure" the box in these cases.   You keep using the words "only run certain 
programs" and "have access to other parts of the server they are not allowed 
access" and "execute normally blocked programs."  If this is the case, then you 
are obviously logging onto the box as an administrator, and/or you simply don't 
have basic security policies in place, and/or running on a FAT drive or 
something.

If you don't want them to run "notepad.exe" then deny access permissions to 
"notepad.exe" and they can't execute it.  Period.  If you allow them to write 
to windows\temp, then they can write to windows\temp; as such, you have clearly 
"allowed" that.  You somehow think that accessing the box via RDP "magically" 
protects you from what the user could do if they were sitting at the console.   
If I didn't want you to run your "altered cmd.exe" then I would use Applocker 
to only let you run the "real" cmd.exe via hash or certificate (not that 
cmd.exe has a cert ) but my point is that you have a tremendous number of ways 
to secure your installation that you are not using - instead you think that 
removing a menu items that points to the .exe someone sets security on the .exe 
itself.  It doesn't.

Menu item restriction and custom interfaces and simply user experience/ UI 
changes to make it "easy" for the user.  Do not mistake them for security 
access controls.  They are not (as you have seen).  Stop running around showing 
videos of the obvious when you COULD be actually securing the system.  You have 
to GRANT access to your RDP server. It's not by default.  You have to ALLOW 
users to do the things you want them to do.  You seem surprised that since you 
have given remote access to a computer to someone who has permissions to run 
programs that they can actually do that.  If you only wanted to allow them to 
run notepad, then giving them RDP access to that box without actually imposing 
security access controls on what they can do was, well, not really smart.

I understand the fact that you WANT there to be a vulnerability here. You want 
to be able to post videos of how you found some "hole."  Even when you said 
"looks like this might not be a vulnerability" you followed up with a frown.   
Thing is, there just isn't.  You can make it seem like there is, but there's 
not.   I suggest that you spend your time actually learning how to secure RDP 
and not looking for ways to make menu items seem like security issues.

t

From: wicked clown [mailto:wickedclow...@googlemail.com]
Sent: Saturday, March 27, 2010 4:39 AM
To: Thor (Hammer of God)
Cc: Full-Disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Possible RDP vulnerability

I think we are two different pages :)

what I was trying to show if you have a group policy that will only run a 
certain applications for example notepad.exe, the user is unable to access my 
computer, run or the start button or any other application. There would be a 
shortcut on the desktop for just notepad.exe for the user to execute.

The user use RDP to connect to the terminal server so they can access 
notepad.exe but if you change the application in the programs tab under the RDP 
client the user is now able to run any application on the terminal server, the 
user then execute intern

Re: [Full-disclosure] Possible RDP vulnerability

[Dan Kaminsky]

So it's a super common thing for schools to have 'locked down' Windows  
desktops, and even more common for even slightly nerdy kids to take  
the lockdown as a challenge to be  defeated.


The point of course is that the kids always win:  At the point  
somebody has the set of privileges exposed by any amount of desktop  
access, constraining execution for them is similar to getting the idea  
that, perhaps, it would be the responsible thing to open discussions  
around managing the open state of the barn door.




On Mar 27, 2010, at 7:39 AM, wicked clown  
 wrote:



I think we are two different pages :)

what I was trying to show if you have a group policy that will only  
run a certain applications for example notepad.exe, the user is  
unable to access my computer, run or the start button or any other  
application. There would be a shortcut on the desktop for just  
notepad.exe for the user to execute.


The user use RDP to connect to the terminal server so they can  
access notepad.exe but if you change the application in the programs  
tab under the RDP client the user is now able to run any application  
on the terminal server, the user then execute internet explorer and  
download a modified cmd.exe and save it in the c:\windows\temp (even  
if you denied access to the hard drive users can still write to the  
temp folder) now I log off the rdp client change the program to  
point to c:\windows\temp\cmd.exe, I how have access to the command  
prompt with access to the command prompt I can run any other  
application or access other parts of the server they are not allowed  
to access.


That is what my video was try to demostrate that even denying access  
to applications on the server you can still execute applications  
from that server.


But as been mention if you put that single click in the RDP-tcp on  
the server then the user is unable to execute other applications.


I have been doing some further checks and I can confirm I have seen  
this affect about 90% of so called secure systems with group policy,  
but will execute normally block applications. I have even found  
systems on the Internet that are vulnerable to this.


I think we may have to agree to disagree on this subject. But thank  
you for you views and comments.


On Fri, Mar 26, 2010 at 9:29 PM, Thor (Hammer of God) > wrote:

I think you still misunderstand.



The option you refer to has nothing to do with “locking down” the  
server.  When you say things like “a locked down group policy that i 
s tighter than a ducks bum” what exactly are you talking about?




Selecting “don’t allow a startup program to be run” simply  
forces the desktop to be shown as opposed to an application one may  
specify.  If I initiate a session and tell it to run calc.exe, then  
calc.exe is what it presented upon connection.  It’s a shortcut for  
the user.  If at the server I don’t allow applications to be specifi 
ed, then it won’t run them and will default to the desktop.  But I c 
an still go “start, run, calc” and it will run fine if I have  
permissions to run it.  AppLocker is a great way to lock down the ho 
st environment, whether RDP or not.




And you are quite incorrect about “no user based control”  
stopping you.  As mentioned, AppLocker could have prevented it had i 
t been deployed “properly.”  Well, it would help, anyway.
Depends on the manner in which the attack was carried out, of course 
, but that has nothing whatsoever to do with the setting in RDP.  De 
ploying RDP to untrusted users or malicious users is not good policy 
; as such, you need to take extra care in securing RDP hosts by usin 
g permissions and other restrictions.




I think you need to relax a little and think about what you post – s 
aying things like “a GPO tighter to a ducks bum” and “open to  
total pwnage” and “nothing would stop me” sounds a bit  
hyperbolic (in addition to being incorrect).




To summarize, your concerns have nothing to do with RDP security  
settings as you have presented them.  MS10-015 is certainly an  
important issue for local-host based attacks, of which RDP is one.   
One’s mitigation efforts should indeed include RDP hosts.  The takea 
way from that is to apply more due diligence to securing RDP deploym 
ents as one would with any asset you give users local access to.   R 
DP should not be viewed as a security mechanism, but rather, an acce 
ss mechanism.  There are MANY ways to secure RDP, limit access, publ 
ish applications in singularity, create remote workspaces, etc, but  
you need to educate yourself on these solutions.




The behavior you describe is expected, by design behavior.



t



From: full-disclosure-boun...@lists.grok.org.uk [mailto:full- 
disclosure-boun...@lists.grok.org.uk] On Behalf Of wicked clown

Sent: Friday, March 26, 2010 8:31 AM


To: Full-Disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Possible RDP vulnerability


Thank you for your comment.

What I was referring to it being

Re: [Full-disclosure] Possible RDP vulnerability

[wicked clown]

I think we are two different pages :)

what I was trying to show if you have a group policy that will only run a
certain applications for example notepad.exe, the user is unable to access
my computer, run or the start button or any other application. There would
be a shortcut on the desktop for just notepad.exe for the user to execute.

The user use RDP to connect to the terminal server so they can access
notepad.exe but if you change the application in the programs tab under the
RDP client the user is now able to run any application on the terminal
server, the user then execute internet explorer and download a modified
cmd.exe and save it in the c:\windows\temp (even if you denied access to the
hard drive users can still write to the temp folder) now I log off the rdp
client change the program to point to c:\windows\temp\cmd.exe, I how have
access to the command prompt with access to the command prompt I can run any
other application or access other parts of the server they are not allowed
to access.

That is what my video was try to demostrate that even denying access to
applications on the server you can still execute applications from that
server.

But as been mention if you put that single click in the RDP-tcp on the
server then the user is unable to execute other applications.

I have been doing some further checks and I can confirm I have seen this
affect about 90% of so called secure systems with group policy, but will
execute normally block applications. I have even found systems on the
Internet that are vulnerable to this.

I think we may have to agree to disagree on this subject. But thank you for
you views and comments.

On Fri, Mar 26, 2010 at 9:29 PM, Thor (Hammer of God)
wrote:

> I think you still misunderstand.
>
>
>
> The option you refer to has nothing to do with “locking down” the server.
> When you say things like “a locked down group policy that is tighter than a
> ducks bum” what exactly are you talking about?
>
>
>
> Selecting “don’t allow a startup program to be run” simply forces the
> desktop to be shown as opposed to an application one may specify.  If I
> initiate a session and tell it to run calc.exe, then calc.exe is what it
> presented upon connection.  It’s a shortcut for the user.  If at the server
> I don’t allow applications to be specified, then it won’t run them and will
> default to the desktop.  But I can still go “start, run, calc” and it will
> run fine if I have permissions to run it.  AppLocker is a great way to lock
> down the host environment, whether RDP or not.
>
>
>
> And you are quite incorrect about “no user based control” stopping you.  As
> mentioned, AppLocker could have prevented it had it been deployed
> “properly.”  Well, it would help, anyway.   Depends on the manner in which
> the attack was carried out, of course, but that has nothing whatsoever to do
> with the setting in RDP.  Deploying RDP to untrusted users or malicious
> users is not good policy; as such, you need to take extra care in securing
> RDP hosts by using permissions and other restrictions.
>
>
>
> I think you need to relax a little and think about what you post – saying
> things like “a GPO tighter to a ducks bum” and “open to total pwnage” and
> “nothing would stop me” sounds a bit hyperbolic (in addition to being
> incorrect).
>
>
>
> To summarize, your concerns have nothing to do with RDP security settings
> as you have presented them.  MS10-015 is certainly an important issue for
> local-host based attacks, of which RDP is one.  One’s mitigation efforts
> should indeed include RDP hosts.  The takeaway from that is to apply more
> due diligence to securing RDP deployments as one would with any asset you
> give users local access to.   RDP should not be viewed as a security
> mechanism, but rather, an access mechanism.  There are MANY ways to secure
> RDP, limit access, publish applications in singularity, create remote
> workspaces, etc, but you need to educate yourself on these solutions.
>
>
>
> The behavior you describe is expected, by design behavior.
>
>
>
> t
>
>
>
> *From:* full-disclosure-boun...@lists.grok.org.uk [mailto:
> full-disclosure-boun...@lists.grok.org.uk] *On Behalf Of *wicked clown
> *Sent:* Friday, March 26, 2010 8:31 AM
>
> *To:* Full-Disclosure@lists.grok.org.uk
> *Subject:* Re: [Full-disclosure] Possible RDP vulnerability
>
>
>
> Thank you for your comment.
>
> What I was referring to it being scary is that if you create a locked down
> group policy that is tighter than a ducks bum and you forget that single
> tick (I admit I didn't knew of that option and I bet lots of other people
> didn't know about it) you leave your system to total pwnage!! It's simple
> mistakes like that which compromises systems.
>
> If I found this before MS10-015 patch was released I could of download that
> exploit and gain system level permission, so no user based permission or
> access control would of stopped me.
>
>
> On Fri, Mar 26, 2010 at 2:13 PM, Thor (Hammer of God) <

Re: [Full-disclosure] Paypal XSS Vulnerability - Resolved

[Orbeton, Jon]

All:

The XSS vulnerability reported below was addressed at approximately 17:45 PDT 
today. 

For information about how to report security issues to PayPal, please refer to 
the PayPal Responsible Disclosure Policy documented here:
https://www.paypal.com/cgi-bin/webscr?cmd=xpt/cps/securitycenter/general/ReportingSecurityIssues-outside

Site security issues should be reported to:
  sitesecur...@paypal.com

All reports will be handled professionally and quickly. A PGP key is available 
at the URL above.


Thanks,
Jon Orbeton

PayPal, an eBay Company



From: Wesley Kerfoot 
Date: Fri, 26 Mar 2010 15:46:09 -0400

Paypal is affected by an XSS vulnerability where it fails to validate
input for the following url:

https://www.paypal.com/xclick/business=

One can add arbitrary javascript with no need for any filter evasion.

https://www.paypal.com/xclick/business= alert("xss"); 


As far as I know only the above url is affected. All of the usual XSS
attacks will work with this.

Cheers.

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/