bugtraq - RE: [Full-disclosure] Remote Desktop Command Fixation Attacks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 11 Oct 2007 10:12:15 -0400
From: "Paul Melson" <pmelson@...il.com>
To: <gjgowey@....blackberry.net>
Cc: <full-disclosure@...ts.grok.org.uk>, <bugtraq@...urityfocus.com>
Subject: RE: [Full-disclosure] Remote Desktop Command Fixation Attacks

> Not to step in to the middle of this, but I once worked for an employer
with what I 
> considered the best way of stopping attacks cold: a proxy server that
prompted you for your 
> credentials when you went to an external web site and gp settings that
disabled the ability 
> to save your username/password locally as well as tight settings on the
systems to prevent 
> pretty much anything from being installed or modified.  So everytime you
opened up a brand 
> new session of ie and tried to access an external site you were prompted
for your 
> username/password.  Somehow I doubt there's any malware around that is
designed to survive 
> in that type of an environment.

(This is far enough afield that I'm not cc'ing pdp or Thor or anyone else,
just the lists).

Actually, it's trivial for malware to survive in this kind of environment.
If the proxy is HTTP-only and requires a cached http-auth header from the
browser, then the malware just has to use any port that is allowed through
the firewall directly that's not 80.

If the proxy is used to perform client authentication (Cisco, Check Point,
and other firewalls do this as well) where a browser authenticates a user
and then the proxy allows other traffic from that client IP address for
until the session expires or there is an idle time limit reached, the
malware need only persist on whatever C&C channel it uses until a user
authenticates to the proxy/firewall.  Then the traffic will still be
allowed.

In many cases, the malware will be dropped and activated *during* one of
these sessions and, at least for a short period of time, will function
unhindered.  Unless a network can authenticate clients on a per-session on
each protocol, there is still plenty of opportunity for malware to thrive.

<soapbox> This is why monitoring and detection are key elements of Defense
In Depth, whose death has been prematurely reported a lot this
year.</soapbox>

PaulM