Mailing List Archive

UPDATE: Re: REFRESH: EUDORA MAIL 5.1.1
Doug Monroe <monwel@interhack.net> said:

> "http-equiv@excite.com" wrote:
> >
> > Tuesday, July 23, 2002
> > Trivial silent delivery and installation of an executable on a
target
> > computer. This can be accomplished with the default installation
of
> > the mail client Eudora 5.1.1:
> > 'allow executables in HTML content' DISABLED
> > 'use Microsoft viewer' ENABLED
> [snip]
> > Working Example:
> [snip]
> > http://www.malware.com/boodora.txt
> >
> > Notes: disable 'use Microsoft viewer'
>
> A Eudora expert I am not, but I suppose one could also change
> HKCU/software/qualcomm/eudora/launchmanager/path#2
> from
> "c:\windows\application data\qualcomm\eudora\embedded"
> or
> "c:\program files\qualcomm\eudora pro\embedded"
> to some other, non-default folder name.
> New folder must exist before running eudora again.
>
> And... add mhtml to "WarnExtentions#X" key values?

Doug, excellent point.

1. Yes, if you can relocate the embedded folder. Better.

2. No. adding warnings to extensions appears to be useless:

Just tested something here. Typically IE can or will open files
depending what the contents are regardless of the extension that it
is: <html> tag in a gif or some other file type should or can be
rendered by IE for what the contents are, not the extension.

New Note 25.7.02: trying that with the above demo, creating &
depositing only malware.exe and malware [no file exetension] yielded
some very interesting results.

<META http-equiv=refresh
content="1; &#13;&#10;url=file://C:\WINDOWS\Application
Data\Qualcomm\Eudora\Embedded\malware">

Expecting IE to spring open with the non-extension'd mhtml file fully
functional, we find that in fact it does not. We find that the
malware.exe is immediately executed.

Removing the mhtml file from the embedded folder and leaving only
malware.exe in there, the meta refresh pointing to 'malware' only [no
extension at all] appears to execute the *.exe directly -- no need
for the mhtml file at all.

Could be an anomaly with this machine, but simply send yourself the
meta refresh pointing to malware minus extension, place an executable
with the same name in the embedded folder and see if it executes.

No time right now to grind it into powder.

--
http://www.malware.com
Re: UPDATE: Re: REFRESH: EUDORA MAIL 5.1.1 [ In reply to ]
"http-equiv@excite.com" wrote:

> Just tested something here. Typically IE can or will open files
> depending what the contents are regardless of the extension that it
> is: <html> tag in a gif or some other file type should or can be
> rendered by IE for what the contents are, not the extension.

The Windows run function (IE viewer) ignores the extension (sort of) if
the file is in a portable OLE-type format. For example, go in Word and
create "foo.doc". Exit and rename "foo.doc" to "foo.fubar". Double
click "foo.fubar" and Word opens up. Same for Excel and other things.

If the extension is known, it appears to try and use it. If not, it
will look for OLE-extensions and launch what matches.

Jeff
Re: UPDATE: Re: REFRESH: EUDORA MAIL 5.1.1 [ In reply to ]
Jeff Kell <jeff-kell@utc.edu> replied to http-equiv@malware.com:

[.I thought I replied to "http-equiv"'s message earlier, but on
checking I sent it direct, not to the lists...]

> > Just tested something here. Typically IE can or will open files
> > depending what the contents are regardless of the extension that it
> > is: <html> tag in a gif or some other file type should or can be
> > rendered by IE for what the contents are, not the extension.
>
> The Windows run function (IE viewer) ignores the extension (sort of) if
> the file is in a portable OLE-type format. For example, go in Word and
> create "foo.doc". Exit and rename "foo.doc" to "foo.fubar". Double
> click "foo.fubar" and Word opens up. Same for Excel and other things.
>
> If the extension is known, it appears to try and use it. If not, it
> will look for OLE-extensions and launch what matches.

It's the other way around -- if a file's extension is not registered
on the system trying to "run" (or "open") the file, depending on how
it is being "opened", some further checks than just "what is
registered to handle this extension" are made. One of those checks
determines whether the file is apparently internally an OLE2 file,
and if so the application registered to handle the CLSID of the root
directory entry in the OLE2 file is directed to open the file. If
that CLSID is also not registered then the usual "Open With..."
dialog appears. Another file type tested for in this process is the
DOS ("MZ") EXE format, which can be run "as normal", depending on the
"open" method used, depsite having been renamed to a non-EXE
extension.

Thus, "http-equiv"'s discovery that a non-extensioned EXE could be
launched through one of these code execution holes is not all that
surprising...


--
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854
Re: Re: UPDATE: Re: REFRESH: EUDORA MAIL 5.1.1 [ In reply to ]
Nick FitzGerald <nick@virus-l.demon.co.uk> said:

> Jeff Kell <jeff-kell@utc.edu> replied to http-equiv@malware.com:
>
> [.I thought I replied to "http-equiv"'s message earlier, but on
> checking I sent it direct, not to the lists...]
>
> > > Just tested something here. Typically IE can or will open files
> > > depending what the contents are regardless of the extension
that it
> > > is: <html> tag in a gif or some other file type should or can be
> > > rendered by IE for what the contents are, not the extension.
> >
> > The Windows run function (IE viewer) ignores the extension (sort
of) if
> > the file is in a portable OLE-type format. For example, go in
Word and
> > create "foo.doc". Exit and rename "foo.doc" to "foo.fubar".
Double
> > click "foo.fubar" and Word opens up. Same for Excel and other
things.
> >
> > If the extension is known, it appears to try and use it. If not,
it
> > will look for OLE-extensions and launch what matches.
>
> It's the other way around -- if a file's extension is not registered
> on the system trying to "run" (or "open") the file, depending on
how
> it is being "opened", some further checks than just "what is
> registered to handle this extension" are made. One of those checks
> determines whether the file is apparently internally an OLE2 file,
> and if so the application registered to handle the CLSID of the
root
> directory entry in the OLE2 file is directed to open the file. If
> that CLSID is also not registered then the usual "Open With..."
> dialog appears. Another file type tested for in this process is
the
> DOS ("MZ") EXE format, which can be run "as normal", depending on
the
> "open" method used, depsite having been renamed to a non-EXE
> extension.
>
> Thus, "http-equiv"'s discovery that a non-extensioned EXE could be
> launched through one of these code execution holes is not all that
> surprising...

For clarity's sake, in this particular instance it was only the meta
refresh that was non-extensioned.

In the embedded folder we had / have:

malware.exe
malware [the mhtml file -- no extension]

<META http-equiv=refresh content="1;
&#13;&#10;url=file://C:\WINDOWS\Application
Data\Qualcomm\Eudora\Embedded\malware">

The refresh tag is pointing to malware -- what it does is skip over
the non-extensioned mhtml file, and instead, open malware.exe
directly.

--
http://www.malware.com
Re: REFRESH: EUDORA MAIL 5.1.1 [ In reply to ]
Just a note for those using Eudora or other email system that puts mail
attachments in a known folder that WinXP/2k/NT with NTFS file system can be
used to mark the whole folder non-executable, thus preventing problems from
most of these vulnerabilities.