> Windows Update site or if there is a bug in IE that
> allows to trick the URL,
then the attacker can use Windows Update ActiveX to:
reboot your machine;
get detailed information on computer - computer name, hardware, isAdmin, etc.
BUT it's hard for the attacker to execute his EXE. i've traced into the module("IUENGINE.TEXT").
they first create the directory(API:"CreateDirectoryW")
then they download the EXE file to the newly created directory. soon after that, they verify its digest (API:"LSTRCMPIW"). at last they verify it with "WinTrust.TEXT" - which i am unable to bypass. if any of the check fails, they delete the file(API:"DeleteFileW").
assuming we already got WINDOWSUPDATE.MICROSOFT.COM( then we easily got MYCOMPUTER):
the only chance is:
"DeleteFileW" fails.
but chances are very very slim.
so generally speaking(generally speaking, we can't break WinTrust), the maximum risk is "RebootMachine" - nothing more.
just as a reminder
best wishes
die
-----------------------
umbrella.mx.tc - http://umbrella.mx.tc
safecenter - http://www.safecenter.net
make notes easily - http://domex.int.tc
----- Original Message -----
From:Cesar <cesarc56 (at) yahoo (dot) com [email concealed]>
To:bugtraq (at) securityfocus (dot) com [email concealed]
Subject:Re: FW: Windows Update - Unsafe ActiveX control (fwd)
Date:Sat, 19 Jul 2003 01:15:06 +0800
> Hi.
>
> I wouldn't consider Windows Update ActiveX as safe,
> the ActiveX has dangerous methods, for example it can
> reboot the computer. Of course the ActiveX checks for
> the current site and if it's not Windows Update site
> it won't work, but if there is some XSS hole in
> Windows Update site or if there is a bug in IE that
> allows to trick the URL, then the ActiveX becomes very
> dangerous. In my opinion restricting an ActiveX to a
> specific site only reduce the attack surface but it
> doesn't make an ActiveX safe.
>
> Cesar.
> --- Dave Ahmad <da (at) securityfocus (dot) com [email concealed]> wrote:
> >
> > ---------- Forwarded message ----------
> > Date: Thu, 17 Jul 2003 XX:XX:XX
> > To: Dave Ahmad <da (at) securityfocus (dot) com [email concealed]>
> > Subject: FW: Windows Update - Unsafe ActiveX control
> >
> > Hi,
> >
> > I would prefer not to reply to this post directly,
> > but if possible can
> > you please mention the following (anonymously):
> >
> > ----------
> > "Safe for Scripting" simply means that the control
> > is safe to be used
> > from untrusted callers. SFS controls can access
> > files and other
> > resources if it is in a controlled way (eg, with the
> > consent of the
> > user). Windows Update is safe because it only allows
> > itself to be hosted
> > from the Windows Update site. If you try and host
> > the control from
> > another domain, the control will not work. Since the
> > Windows Update site
> > only ever uses the control for "good" purposes, and
> > requires the user's
> > consent to install patches, etc. it is considered
> > "Safe for Scripting".
> > _All_ ActiveX controls can access memory and
> > registers directly, whether
> > they are marked as safe or not, since they typically
> > are implemented in
> > native code ;-)
> >
> > Windows Update does not require you to run "unsafe"
> > controls;
> > unfortunately the generic error that appears when
> > you disable scripting
> > of _safe_ controls makes it sound like there are
> > _unsafe_ controls. If
> > you enable scripting of "safe" controls then the
> > site should work fine.
> > If you are concerned about securing the browser, I
> > recommend that you
> > place Windows Update in the "Trusted Sites" zone and
> > run that in the
> > "Medium" security mode, and run the rest of the
> > "Internet Zone" in
> > "High" mode, although this will break a lot of
> Windows Update site or if there is a bug in IE that
> allows to trick the URL,
then the attacker can use Windows Update ActiveX to:
reboot your machine;
get detailed information on computer - computer name, hardware, isAdmin, etc.
BUT it's hard for the attacker to execute his EXE. i've traced into the module("IUENGINE.TEXT").
they first create the directory(API:"CreateDirectoryW")
then they download the EXE file to the newly created directory. soon after that, they verify its digest (API:"LSTRCMPIW"). at last they verify it with "WinTrust.TEXT" - which i am unable to bypass. if any of the check fails, they delete the file(API:"DeleteFileW").
assuming we already got WINDOWSUPDATE.MICROSOFT.COM( then we easily got MYCOMPUTER):
the only chance is:
"DeleteFileW" fails.
but chances are very very slim.
so generally speaking(generally speaking, we can't break WinTrust), the maximum risk is "RebootMachine" - nothing more.
just as a reminder
best wishes
die
-----------------------
umbrella.mx.tc - http://umbrella.mx.tc
safecenter - http://www.safecenter.net
make notes easily - http://domex.int.tc
----- Original Message -----
From:Cesar <cesarc56 (at) yahoo (dot) com [email concealed]>
To:bugtraq (at) securityfocus (dot) com [email concealed]
Subject:Re: FW: Windows Update - Unsafe ActiveX control (fwd)
Date:Sat, 19 Jul 2003 01:15:06 +0800
> Hi.
>
> I wouldn't consider Windows Update ActiveX as safe,
> the ActiveX has dangerous methods, for example it can
> reboot the computer. Of course the ActiveX checks for
> the current site and if it's not Windows Update site
> it won't work, but if there is some XSS hole in
> Windows Update site or if there is a bug in IE that
> allows to trick the URL, then the ActiveX becomes very
> dangerous. In my opinion restricting an ActiveX to a
> specific site only reduce the attack surface but it
> doesn't make an ActiveX safe.
>
> Cesar.
> --- Dave Ahmad <da (at) securityfocus (dot) com [email concealed]> wrote:
> >
> > ---------- Forwarded message ----------
> > Date: Thu, 17 Jul 2003 XX:XX:XX
> > To: Dave Ahmad <da (at) securityfocus (dot) com [email concealed]>
> > Subject: FW: Windows Update - Unsafe ActiveX control
> >
> > Hi,
> >
> > I would prefer not to reply to this post directly,
> > but if possible can
> > you please mention the following (anonymously):
> >
> > ----------
> > "Safe for Scripting" simply means that the control
> > is safe to be used
> > from untrusted callers. SFS controls can access
> > files and other
> > resources if it is in a controlled way (eg, with the
> > consent of the
> > user). Windows Update is safe because it only allows
> > itself to be hosted
> > from the Windows Update site. If you try and host
> > the control from
> > another domain, the control will not work. Since the
> > Windows Update site
> > only ever uses the control for "good" purposes, and
> > requires the user's
> > consent to install patches, etc. it is considered
> > "Safe for Scripting".
> > _All_ ActiveX controls can access memory and
> > registers directly, whether
> > they are marked as safe or not, since they typically
> > are implemented in
> > native code ;-)
> >
> > Windows Update does not require you to run "unsafe"
> > controls;
> > unfortunately the generic error that appears when
> > you disable scripting
> > of _safe_ controls makes it sound like there are
> > _unsafe_ controls. If
> > you enable scripting of "safe" controls then the
> > site should work fine.
> > If you are concerned about securing the browser, I
> > recommend that you
> > place Windows Update in the "Trusted Sites" zone and
> > run that in the
> > "Medium" security mode, and run the rest of the
> > "Internet Zone" in
> > "High" mode, although this will break a lot of
> > sites.
> >
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
>
______________________________________
===================================================================
[ reply ]