RE: HijackClick 3
Thor Larholm ha scritto nel messaggio:
> From: Drew Copley
> > In fact, I don't think there has been a bug in about ten
> > months (coincidentally) that does not rely on either
Jelmer's
> > adodb bug or your shell.application bug.
> I'm sorry, but did everybody suddenly forget about codeBase
command
> execution? Use a non-existent GUID for your OBJECT's classid
and point
> the codeBase attribute to the executable you want launched.
The codebase has been out of use since May 2003 at which time I
noted it had been patched:
http://cert.uni-
stuttgart.de/archive/ntbugtraq/2003/05/msg00005.html
Up until yesterday it still did not work, however after
Microsoft's series of patches it seems
to be back with mixed results.
> Well technically, you also posted about it in 200 and gave
proper credit
> to Dildog.
Technically I found and used the concept in June of 2000 at
which time everyone got it wrong. It was the runner window
object a piece of code designed to do just that, which allowed
for a file in the same directory to execute without having to
point to it.
http://www.securityfocus.com/archive/1/66678
The entire concept of little 'Zones' was so alien to everyone
back then that CERT even missed the point until I explained and
demo'd it to them:
http://www.cert.org/advisories/CA-2000-14.html
I don't recall seeing your name around back in those 'good old
days'.
> codeBase has been the basis of most IE exploits before we
started using
> AD+ODB or Sh+ell
No it hasn't. While the executing of files already on the
machine proved to be nothing more than 'parlor tricks' the
real 'trick' was to introduce arbitrary code to run. That was
achieved only by encoding the executable in base64 and
extracting it using mthml and referencing to the embedded
executable that way. This is note the same as the code base
pointing to a 'compiled' arbitrary executable introduced onto
the machine which is next to impossible except for some rare
bypassing of the Temporary Internet File. All methods via MHTML
or CHM files are closed as well. The introduction or the ability
to 'run' adobd in the Local Zone itself is sufficient to use any
other measure to then execute the file it has written. No need
to use codebase [which in that 'era' didn't work anyway] to run
it. Shell has never been used with any measure of success 'in
the wild' owing to its limited [at the time] capabilities. Only
very recently was it demonstrated to enjoy even more powerful
capabilities by combining a number of different techniques:
http://msgs.securepoint.com/cgi-bin/get/bugtraq0407/32.html
But this is a complete waste of time. It has been patched, as
has the adobd.stream. Both of which do not work on Windows 95 or
Windows 98 as they are not installed.
> The codeBase attribute allows command execution from the My
Computer
> zone and you can mitigate against it by either completely
disabling
> ActiveX in that zone or setting it to only allow administrator
approved
> ActiveX controls.
You don't need to do either. It has been sufficiently patched
all this time except by all indications as of yesterday with the
introduction of the 'mega patch' series from Microsoft. In any
event to introduce the executable you intend to run is next to
impossible and only digitally signed files can bypass whatever
warnings or prompts remain today [as noted above in May 2003]
>The latter will solve the functionality regression
> problem that e.g. MMC and Norton Antivirus will have since
both of these
> rely on executional privileges given by the My Computer zone.
This is
> also the approach we took in Qwik-Fix ( http://qwik-
fix.net/ ).
Regrettably I cannot find any validity to this. For all the
reasons already stated. By the way despite 'hiding' the download
url of your little 'gimmick' a quick Google shows where it can
be downloaded. Having now 'played' with it for a number of weeks
I could not in good faith recommend it to anyone. Unraveling its
code reveals nothing more than a series of registry entries that
are freely available from Microsoft directly plus all the so-
called 'killbit' registry entries everyone else has been
recommending from day one. With a difference of a 'little'
on/off switch. The entire thing can be accomplished with a .vbs
file or any other number of scriptings. That plus an elaborate
[and in my opinion unnecessary 'updating' scheme. The 'scheme'
itself comprises the whole gadget]. While it certainly
does 'killbit' what everyone has been discussing and how to do
it for what seems like ages now, I am unable to see any effect
whatsoever in regards to the 'import win32api, win32con name
= "Zones fix" ' -- it simply does not work on my stock, fully
patched test machine XP home. The little 'log file' you provides
confirms it is enabled, but it does absolutely nothing here. All
scripting works in the Local Zone, Jelmers very last demo with
the Java .tmp file my demo of Paul's favorites tricked worked
until shell and its path [which can still be defeated] was
patched yesterday:
- Info: IeZoneFix: Unable to query registry value "{F6406E36-
812A-4501-8C0C-3A6CAEF6DB84}"
- Info: IeZoneFix: Unable to query registry value "{FD0AE533-
61C2-11D2-B980-00805FCDA1A3}"
- Info: IeZoneFix: Enabled.
Furthermore I caught it autoupdating without permission the
other day as well. Despite there being no little 'checkmark' in
that 'feature'. However despite it not working as advertised
[which in itself is quite dangerous creating a complete false
sense of security to the truly 'naive' as it were], the fact
that it overwrites or deletes access to the 'My Computer'
setting in Internet Explorer [having manually applied it] is
simply not acceptable. That is Trojan type behavior. It does not
have permission to effectively 'monkey about' with the computer
owners private / custom settings.
Finally a generous free 'tip' would to not have the
entire 'thing' install in a predictable location particularly as
you have a series text based files in there that may very well
be leveraged down the road [since operations in the My Computer
zone still function].
> You can circumvent the initial restrictions on codebase
through a series
> of Refresh's.
By all accounts the latest patches from Microsoft have an effect
on codebase which appear to allow it to work as before without
any need of anything else. Though thorough testing at this time
is incomplete.
> Microsoft could blacklist the Sh+ell.App+lication object and
still be no
> better off. They could fix codeBase and I am sure we would
find new
> vulnerabilities in IE.
This is all dated now as it is all fixed. As one who is 'in the
trenches' I must admit that I am impressed with this
comprehensive patching to date. Certainly has killed of many
many possibilities [yet some still remain]. But overall I would
give them 3 Gold Stars.
Internet Explorer and its associated or embedded applications
are only getting 'tougher' to defeat. Without a doubt in the
very near future [certainly before the end of this year] it
along with the Operating System should be sufficiently 'locked
down' that all need for third-party gadgetry will be unnecessary
and a waste of time and money.
> Any privileges that you could ever need in the My Computer
zone
> can safely be used from an HTML Application by embedding MSHTA
instead
> of IEXPLORE.
That is the only thing that is correct. We all await XP SP 2 and
will certainly put it through its paces. But you should
understand that all of these 'fun and game' vulnerability
findings in IE are nothing more than a moment in time. So short
a time it would be considered an utter gamble to invest time and
money in such a fleeting moment.
--
http://www.malware.com