FromTheRafters said:
My best guess at this time ~
I think that the issue with mimail is that an HTML e-mail (MIME encoded
executable embedded within) can be crafted and an exploit used to cause
that file to be saved in a known location on the target computer (as an error
404 text). ...
Close, but no cigar...
... Furthermore another exploit is used to pass that file to OE for
processing as a MIME encoded e-mail message (MHTML). A CODEBASE
exploit within that file (the HTML e-mail text file) is used to execute the
embedded attachment in the local (My Computer) security zone.
Yes, kinda. There are several ways to describe this and that is not really
incorrect, but I think it can be done more clearly...
The whole set of tricks works like this:
1. A "bad file" (in this case foo.exe which is an instance of the Mimail
mass-mailer executable) is encoded into a very crude MHTML form (arguably an
"imporoper" MHTML under thr RFCs covering construction of such files --
RFC 2389 and RFC 2557 in particular).
2. This MHTML file also contains some HTML and script code and has a .HTML
extension.
3. This .HTML file is put into a .ZIP archive which is mass-mailed to
initially spread the virus.
4. A recipient of such an Email message and with a suitably vulnerable web
browser (i.e. IE) associated with .HTML files receives and opens the message.
S/he reads the message and double-clicks the .ZIP attachment (.ZIP files are
basically "safe", right?) and sees the .HTML file within.
5. Recipient thinks (??? OK, so I'm being generous -- perhaps it is not your
"typical user") ".HTML files are basically safe right? I mean, that is what
the WWW is made up of..." so double-clicks the .HTML file (from 2.) in the
..ZIP file's contents listing.
6. Problem. No (?) typical zip programs know (or care!) about the niceties
of IE's security zones. None know (or care!) that the ZIP file thay have just
been asked to open has been delivered via the web browser or as an attachment
to an Email message. Result? Although the mail client may have extracted the
temporary copy of the .ZIP attachment to IE's TIF (OE should), the .ZIP file
handling program will (almost certainly in almost all cases) extract its
temporary copies of .ZIP file contents (such as the .HTML file double-clicked
in 5.) to the system temporary files directory (i.e. %temp%).
7. The .ZIP handler (WinZip, PowerZip, WinRAR, WZip, etc, etc, etc, etc, etc)
then calls the OS to "open" the .HTML it has just dropped into %temp%. On a
typical Windows machine IE will be called, and as the .HTML file it has been
asked to display is outside the TIF none of the usual security restrictions
will apply and code in the .HTML file will be able to do (almost) anything
unprompted. (In fact, such .HTML files have almost all the power of .HTA
"applications" apart from the .HTA-specific window controls that allow .HTAs
to hide their windows, change their window titles and a few other largely
cosmetic things.)
8. IE parses the odd .HTML file (there's a great deal of "useless junk" at
the top of the file) but eventually sees the script and HTML code from 2. near
the end of the file. This code refers back to the encoded foo.exe inside this
same HTML file (the "great deal of 'useless junk' at the top of the file") via
an MHTML: protocol reference inside an exploit of an old object codebase
vulnerability, which executes the extracted foo.exe file.
The codebase exploit mentioned in step 8. was actually fixed quite some time
back -- MS02-014:
http://www.microsoft.com/technet/security/bulletin/MS02-014.asp
_EXCEPT_ in the "My Computer" security zone. It has been known since at least
February this year that the "My Computer" zone was still vulnerable to this
exploit, as two PoC exploits -- showing how to use it in just the way MindJail
(aka Mijail) did a few weeks ago, the way several "manual" mass mailouts of
some RATs/IRC bots have in the last couple of weeks and, of course, the way
Mimail did -- were released that month. I've been told (but have not tested
it myself) that this "My Computer" codebase flaw was _silently_ fixed in the
latest IE cumulative patch (i.e. there is no reference to it in the official
Security Bulletin describing the cumulative patch):
http://www.microsoft.com/technet/security/bulletin/MS03-015.asp
Hopefully that all helps soemwhat...
I'm not too sure about this as I have just started to try and
figure this thing out (it's kinda twisted).
....it certainly is and you did a good job as far as it went (as I said, not
really wrong, but not quite oriented to cover all the angles and twists).
The security zone setup of Windows makes it so you can
easily control some aspects of all zones except the local
"My Computer" zone. This thing uses an exploit to "jump
the fence" so to speak into the local zone where things
are usually more lenient..
But that is incorrect.
There is _no_ exploit invloved in the fence jumping _in this case_. There
certainly have been some trivial hole punches to get through that fence in
the past, but this one simply depends on the fact that users can easily be
their own worst enemies. The security zone fencing flaw here is more that
unless _every_ piece of code honours security zone information and "real"
security zone ring-fencing around "possibly restricted" "data" is enforced
by the security zone system, then it can never be more than a toy (have I
ever told you that, from observing how their software is designed, it is
abundantly clear MS programmers do not understand security?).
The big flaw in the process outlined above happens at step 4. -- the user
chooses to introduce an application that is "outside" the security zone
"model". True, most users do not have the savvy to realize that using a
..ZIP handling program may be introducing a serious security threat, but we
all know users in general cannot be trusted to care particularly for
security. This type of ambiguity is one of the reasons why I so strongly
disagree with the MS approach of making "the desktop" and "the Internet"
seamless. To do so _vaguely safely_ requires a fundamentally different
security model from any in any MS code ever produced. Given MS's abundant
security failures to date, the likelihood of it getting even 10% of the
design of such a system right seems a distant hope...
The "My Computer" zone can be adjusted via the registry.
But I'm not sure yet what exactly needs doing.
Simply set another zone to the settings you want for "My Computer", export
that zone's key to a .REG, edit the .REG to change the key name from "1"
through "4" (depending on which zone you modified) to "0", then import the
..REG back into the registry (if doing this "very tidily" you would also
delete the Description, Display Name, Icon, MinLevel, RecomendedLevel and
maybe Flags values -- I'd have to look more closely at Flags to see what
causes it to change...).
Alternately -- and much nicer -- enable display of the "My Computer"
security zone on IE's Security tab, and thus enable standard point and
click editing of its settings. To do this, simply find the current value
in the registry:
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\0\Flags
and _subtract_ 32 decimal (20 hex) from that value. By default I think it
will normally be 33 decimal (21 hex) so you'd change it to 1. You may
prefer to change this for all (new) users of the machine by setting the
same value under the HKU\.Default and HKLM trees.
BUT, that wouldn't help much here. I think you'd have to make some very
restrictive settings to prevent the local exploit from inside the MHTML
file Mimail uses -- perhaps so restrictive as to make viewing of locally
saved HTML files all but useless (unless they only contained very simple
HTML). Again, the "proper" fix is to have already had the MS patch in
place (and better still, for MS to have fixed the flaw in all affected
security zones when it was first made aware of the flaw, even if its staff
could not see a likely means of exploitation -- after all, they are drawn
from the same bunch of rocket scientists as designed the broken model and
wrote the partial implementation of it in the first place...).
)