Home page logo
/

bugtraq logo Bugtraq mailing list archives

RE: Remote Desktop Command Fixation Attacks
From: Jim Harrison <Jim () isatools org>
Date: Thu, 11 Oct 2007 14:26:15 -0700

"..I am not planning to support my argument in any way.."
That's a shame.
If you can prove your hypothesis, it lends credibility to your claims.
A refusal to do so only weakens your position.

As others have pointed out, your attack only works if security in depth has been blatantly, intentionally ignored.
I'll grant that it's an interesting methodology, but it assumes too much and ultimately fails to prove your claims.

You're absolutely correct; "Security in depth" is a process; no one has argued this.
What no one has stated is that security in depth has an endpoint.
Not only does it require proper analysis, planning and deployment, it's greatly weakened without constant monitoring 
and adjustment to meet new threats.
That said, nothing you have proposed in your attack methodology changes those statements.

Jim

-----Original Message-----
From: pdp (architect) [mailto:pdp.gnucitizen () googlemail com]
Sent: Wednesday, October 10, 2007 5:17 PM
To: Thor (Hammer of God)
Cc: full-disclosure () lists grok org uk; bugtraq () securityfocus com
Subject: Re: Remote Desktop Command Fixation Attacks

Thor, with no disrespect but you are wrong. Security in depth does not
work and I am not planning to support my argument in any way. This is
just my personal humble opinion. I've seen only failure of the
principles you mentioned. Security in depth works only in a perfect
world. The truth is that you cannot implement true security mainly
because you will hit on the accessibility side. It is all about
achieving the balance between security and accessibility. Moreover,
you cannot implement security in depth mainly because you cannot
predict the future. Therefore, you don't know what kinds of attack
will surface next.

Security is not a destination, it is a process. Security in depth
sounds like a destination to me.

However, for the record, this is not an "attack."  You might as well
just email the target and ask for their password.  Or if you can get
them to open files, just send off a rootkit.  But let's ignore that for
now- let's pretend that somehow this is a magic attack--  This is where
security-in-depth comes in, and where the overall context of your post
is incorrect:

It is not the same. We educate users not to open .exe files but RDP
and ICA are just pure business tools. Users are familiar with them and
their purpose. Therefore, they are more trusted. And what happens when
the tools that you trust turn against you?

And how come it is OK for a simple text file be able to ride your
session and execute commands on behalf of you? I think that this is a
problem. CSRF is a well known, widely acknowledged problem. The client
should at least warn you that you are about to start an alternative
shell. That's not the case though.

BTW, I am not sure if you stumbled across the other post I released on
FD and BUGTRAQ which is closely related to this one. Well, here is the
situation: if you visit a remote page that happens to be malicious,
attackers can inject any commands they wish into your remote desktop
without any visible notice. No interaction is required. And the attack
is super generic btw, and probably 100% wormable.

So, I believe it is an attack. Yes, it is not stack, heap overflow, or
some null pointer dereference issue, but it is an attack that we
cannot simply ignore it, mainly because it is a problem with a feature
rather then a bug. Features cannot be easily eliminated. Bugs will be
fixed!

One thing that I am always trying to do with the GNUCITIZEN sessions
is to educate developers as well system administrators that attacks
succeed when they are unexpected. At the end of the day, the trick is
simple.

On 10/10/07, Thor (Hammer of God) <thor () hammerofgod com> wrote:
Security in depth is alive and well, thank you.  In fact, it is security
in depth that allows administrators to prevent this type of "attack" (if
we can actually make the stretch to call it that).

However, for the record, this is not an "attack."  You might as well
just email the target and ask for their password.  Or if you can get
them to open files, just send off a rootkit.  But let's ignore that for
now- let's pretend that somehow this is a magic attack--  This is where
security-in-depth comes in, and where the overall context of your post
is incorrect:

First off, you block .rdp files at the SMTP gateway (that by itself is
security in depth). Secondly, normal domain users don't RDP to external
hosts, so there would never be an allow rule for outbound RDP.  Even if
there was some need for off-lan RDP traffic from users, it would be on a
host-by-host basis and managed by the firewalls.  That, again, is
security in depth.

If your users are running XP, then the admin would prevent them from
updating to the 6.0 client anyway.  All you have to do in this case is
configure your RDP hosts to require TLS encryption based on a
certificate, and the client will not be able to connect at all if the
certificate is not in the trusted root certificates store.  Done.  If
you've got advanced users or have allowed 6.0 clients, then you ensure
that the client is set not to connect if authentication fails against
TLS secured hosts - of course, these people would be educated against
lame attacks anyway, so, done.  If you are running Win2k8, then you use
group policy to disable clients opening un-signed RDP files in the first
place, and again, be done.  Or just use TSGateway and require
certificates to log on - heck, they'd never make it past the gateway if
you didn't allow them.  Done part IV.  If you've got Vista clients, then
you'd also be using egress firewall rules in the "public" network
context blocking the outbound traffic, all configured with a single GPO.
I could go on, and on.

The point is that just because you have (amazingly enough) qualified
this attack as "highly successful" and "vicious" does not, in any way,
degrade the value of security in depth.  In fact, it is a perfect
example *for* security in depth in that regard:  if this "attack"
succeeds against anyone, it is not because security in depth does not
exist, it is because security in depth was not practiced.

t





-----Original Message-----
From: pdp (architect) [mailto:pdp.gnucitizen () googlemail com]
Sent: Wednesday, October 10, 2007 4:15 AM
To: full-disclosure () lists grok org uk; bugtraq () securityfocus com
Subject: Remote Desktop Command Fixation Attacks

http://www.gnucitizen.org/blog/remote-desktop-command-fixation-attacks

Security in depth does not exist! No matter what you do, dedicated
attackers will always be able to penetrate your network. Seriously!
Information security is mostly about risk assessment and crisis
management.

When it comes to exploitative penetration testing, I relay on tactics
rather then exploits. I've already talked about how insecure Remote
Desktop service could be. In this post I will show you how easy it is
to compromise a well protected Windows Terminal or CITRIX server with
a simple social engineering attack and some knowledge about the
platform we are about to exploit.

The attack is rather simple. All the bad guys have to do is to compose
a malicious RDP (for Windows Terminal Services) or ICA (for CITRIX)
file and send it to the victim. The victim is persuaded to open the
file by double clicking on it. When the connection is established, the
user will enter their credentials to login and as such let the hackers
in. Vicious!

I have a more detailed explanation about the tactics behind this
attack. Because I don't want to spam people with tones of text, I just
included a link which you can follow. Hope that this is useful and at
the same time eye opening, not that it is something completely
amazing. But it does work and it works well.

cheers.

--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org



--
pdp (architect) | petko d. petkov
http://www.gnucitizen.org


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]