From: 1 at malware.com (http-equiv@...ite.com)
Subject: 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

Powered by blists - more mailing lists