From: Simon (simos74gmx.net)
Date: Tue Oct 05 2004 - 14:03:16 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

miguel.dilajpharma.novartis.com wrote:

>Hi Tony,
>
>I used a similar trick in the past to deactivate McAffee 4.x (needed to
>use some xploits like Debploit and runasx in WinNT4, at that time the only
>protection was the antivirus, now we migrated to XP).
>The configuration GUI was password protected, and even when the passwords
>were show as asterisks tools to reveal passwords hidden by asterisks only
>show a dummy string ('12345678').
>But tools to activate greyed controls worked like a charm, so in fact it
>was possible to activate them and change the settings, deactivate the AV,
>etc.
>The tool I used for the trick was VeoVeo, a Spanish tool available at
>www.hackindex.org (that has functionalities to reveal passwords hidden by
>asterisks, activate greyed controls, activate greyed menu items, and a
>simple keylogger that doesn't need administrative privileges to be
>installed/used).
>The point for me is that, even when NAI commit a mistake by providing the
>configuration GUI to be available for control activation, the real problem
>is Windows (IMHO) that allows that, not the antivirus itself. With the
>same kind of "tricks" you can go activating controls all along your
>Windoze applications, with more than unpredictable results ;-)
>
>
Looks like a usability versus security issue, where usability takes
priority.

In Windows you can programmatically list (enumerate) all available
windows and retrieve their window handles.
 From this window handle, you can obtain attribute information such as
caption name, location, parent/children, etc.
You can also use it to send your own window events, even custom ones.
In essense, you can use events as an additional "input" to attack an
application, along with the inputs described
in the excellent Secure Programming for Linux and Unix HOWTO
(http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/input.html)

Microsoft seems to have realised that trying to write "privileged"
programs that take care of events
and make sure that, let's say, a trojan does not shutdown your
firewall/antivirus, is not practical (it's like
trying to remove buffer overflows? :), so they advice developers to use
"window stations" instead.

"Window stations" is a functionality found in Windows 2k/XP/etc that
creates separate event queues within
the same session; an application from one session cannot enumerate or
send events to a window in another
window station. In the same concept are "desktop windows"; A window
station can contain several desktop windows.

Using window station, you can separate much of the functionality of your
AV/firewall/etc and let it run
in a different window station. However, for usability purposes you still
need the user to be able to control
the service, so I believe it has to run in the current window station.
Tough problem.

More on this at http://www.isg.rhul.ac.uk/~simos/HITB/

Simos
http://simos.info/

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]