EMBEDDED MALWARE

  • Thread starter Thread starter schmegly
  • Start date Start date
S

schmegly

Outlook has an outstanding feature that enables a user to view an email's
source code.

There are two formats for emails in outlook 1)plaintext 2)richtext. its in
the richtext where the problems arise.

after several emails with this problem I am asking if I am the only person
on the planet that knows about this issue (yeah right, knock knock, hello
microsoft??)

if you right click on an email in your inbox you can do a properties search
on it just like a regular file on your hdd. so following this pathway

"properties|details|message source|scroll to bottom",

I found all this gobbledee gook alphanu code that is like, way long and way
huge embedded in a *.jpg file added to the body of the subject email.

what is this? I think its a virus because it has the potential of
causing all kinds of problems.

I questioned the senders of this type of email and they assure me they are
more than adequately protected for malware so "it couldn't possibly be them"
with a virus infection.

well I check all "richtext" emails this way anymore to make sure there isn't
this "piggybacked" gobbledeegooked code in the email body before doing
anything else with it until I get some kind of explanation about this
anomoly,


help......
 
1. The path you specify, "properties|details|message source|scroll to
bottom" does not exist in any version of Microsoft Outlook. It DOES exist
in Outlook Express, so I assume that's what you're using.

2. That "gobbledee gook alphanu code" IS the attached .JPG file encoded so
it will pass through the email server system. Email servers can only pass
pure text, what's known as "Printable Characters". Binary files like
pictures and executables contain both printable and non-printable characters
and, without some kind of modification, cannot be sent through an email
server. Enter attachment encoding to solve the problem. Binary data is
converted to pure text by one of several encoding methods - BinHex,
UUEncode, and, with most email clients, MIME. What you're seeing at the
bottom of the message source is the encoded (pure text) data that represents
the attachment(s). When you open the message, this data is un-encoded back
into a binary picture, program, what have you.

Hal
--
Hal Hostetler, CPBE -- (e-mail address removed)
Senior Engineer/MIS -- MS MVP-Print/Imaging -- WA7BGX
http://www.kvoa.com -- "When News breaks, we fix it!"
KVOA Television, Tucson, AZ. NBC Channel 4
Still Cadillacin' - www.badnewsbluesband.com
 
Hal Hostetler said:
1. The path you specify, "properties|details|message source|scroll to
bottom" does not exist in any version of Microsoft Outlook. It DOES exist
in Outlook Express, so I assume that's what you're using.

2. That "gobbledee gook alphanu code" IS the attached .JPG file encoded so
it will pass through the email server system. Email servers can only pass
pure text, what's known as "Printable Characters". Binary files like
pictures and executables contain both printable and non-printable characters
and, without some kind of modification, cannot be sent through an email
server. Enter attachment encoding to solve the problem. Binary data is
converted to pure text by one of several encoding methods - BinHex,
UUEncode, and, with most email clients, MIME. What you're seeing at the
bottom of the message source is the encoded (pure text) data that represents
the attachment(s). When you open the message, this data is un-encoded back
into a binary picture, program, what have you.

Hal
--
Hal Hostetler, CPBE -- (e-mail address removed)
Senior Engineer/MIS -- MS MVP-Print/Imaging -- WA7BGX
http://www.kvoa.com -- "When News breaks, we fix it!"
KVOA Television, Tucson, AZ. NBC Channel 4
Still Cadillacin' - www.badnewsbluesband.com



OK, yes you are right I shorthanded OE to O which I shouldn't do. Its interesting that "Outlook" doesn't have this feature because it has helped me discover that malware can be hidden this way. Thanks Hal for further clarification of how this works, however and perhaps its my fault, the real question here is about malware. If this "pure text" encoding represents a jpg in the body of the email, why is it that not all richtext emails have the "printable characters" at the end of the "message source" only those that seem to be infected? There does however seem to be a representative scaling that perhaps those emails that contain malware pure text are very very long and those that don't are shortened somewhat. This is something I noticed.

SEMI CONCLUSION: so I should expect any richtext email to have this "pure
text" coding visible when I do a "message source" search of individual emails?

and second, you refer to the jpg coding as "attached" which confuses me
because I consider the act of "attaching" something to an email anethema, and
I don't practice it because its a known malware vector that's why I used the
term "embedded". I realize this comes with its own "programmers parameters"
as "Object Linked Embedded" type coding for example, I think. So maybe I
need a third description of what happens in richtext emails when the fonts
are changable and pictures can be "inserted" into the body of an email ah
ha! "inserted" lol. hmmm.....

third, why is malware in jpgs that are inserted in the body of a richtext
email eluding antivirus scanning on individual PCs? I used AVG/Grisoft, even
sent them a zipped copy using notepad text editor and Winzip and they replied
with various form letters resulting in we can't help you, etc..

So for now I am deleting any emails I receive that have very long "pure
text" in them. Until I can find a way to distinguish which "pure text" is
good "pure text"and which is not. So far the only measure is the length,
like I said there are some very long ones. When I copied an example and
pasted it into a *.txt file I could then see how big the file actually was.
So there is some masking in this process with outlook express it would seem;
improper size reporting.
 
Basic wrong assumption - Outlook Rich Text Format can only be read by
Outlook, not Outlook Express, nor any other mail client except Eudora.

--
Milly Staples [MVP - Outlook]

Post all replies to the group to keep the discussion intact.
How to ask a question: http://support.microsoft.com/KB/555375
 
OK, yes you are right I shorthanded OE to O which I shouldn't do.

Indeed. MS Outlook is a completely different program than MS Outlook
Express.
Its interesting that "Outlook" doesn't have this feature because it has helped
me discover that malware can be hidden this way.

I believe that MS Outlook has a different means of looking at the "raw code"
of an email message. Not sure, though, not having a copy to play with.
Thanks Hal for further clarification of how this works, however and perhaps
its my fault, the real question here is about malware. If this "pure text"
encoding represents a jpg in the body of the email, why is it that not all
richtext emails have the "printable characters" at the end of the "message
source" only those that seem to be infected? There does however seem to be
a representative scaling that perhaps those emails that contain malware pure
text are very very long and those that don't are shortened somewhat. This is
something I noticed.
SEMI CONCLUSION: so I should expect any richtext email to have this "pure
text" coding visible when I do a "message source" search of individual emails?

Not necessarily. "Rich text" email should have a "Content Type" header line,
thus:

| Content-Type: multipart/alternative;
| boundary="----=_NextPart_2168_2A20_0F386196.01C9192F"

Within the email should be "NextPart" lines, thus:

| ------=_NextPart_2168_2A20_0F386196.01C9192F
| Content-Type: text/plain; charset=ISO-8859-1
| Content-Transfer-Encoding: 7bit

Unless the body of the message contains binary data, there is no need to
encoded the data. HTML data is not binary.

"Rich text" is used to preserve special encoding characters in Word
documents, and similar. While those will be encoded, they won't,
necessarily, be .jpg file types. I've received encoded attachments of .doc,
and .pps (MS Power Point) file types.
and second, you refer to the jpg coding as "attached" which confuses me
because I consider the act of "attaching" something to an email anethema, and
I don't practice it because its a known malware vector that's why I used the
term "embedded".

The terms "attached", and "embedded" reflect the difference of how the
client displays the data. Embedded images are, generally, displayed inline,
as a background, while attached images have to be loaded in an image display
program. Malware can be embedded as easily as it can be attached.

Actuall, embedding is more likely to be dangerous than attaching.
Attachments are generally only executed by a file handler. Embedded code
will be rendered by the client, unless the client has been configured not to
render content.
I realize this comes with its own "programmers parameters" as "Object Linked
Embedded" type coding for example, I think. So maybe I need a third description
of what happens in richtext emails when the fonts are changable and pictures can
be "inserted" into the body of an email ah ha! "inserted" lol. hmmm.....

Most email clients always send email using MIME. See:

http://en.wikipedia.org/wiki/MIME
third, why is malware in jpgs that are inserted in the body of a richtext
email eluding antivirus scanning on individual PCs? I used AVG/Grisoft, even
sent them a zipped copy using notepad text editor and Winzip and they replied
with various form letters resulting in we can't help you, etc..

I've only seen malware evade AV scanning when it was too new for the
definitions of the scanner. I received a suspicious email with an attachment
which passed the AV scanners. No, I did not invoke a file handler to run it.
I zipped it, per the instructions on the Symantec site, and submitted it to
them for analysis. Within 15 minutes, Symantec responded with a link to a
new set of definitions for the AV scanner, which then detected the attached
file as malware.

While I have heard of malware piggybacking in .jpg images, it seems unlikely
that your AV would fail to find it, unless it was a zero-day virus, as the
one I received.
So for now I am deleting any emails I receive that have very long "pure
text" in them. Until I can find a way to distinguish which "pure text" is
good "pure text"and which is not. So far the only measure is the length,
like I said there are some very long ones. When I copied an example and
pasted it into a *.txt file I could then see how big the file actually was.
So there is some masking in this process with outlook express it would seem;
improper size reporting.

No. Depending in the coding used, image files are expanded beyond their
original file size; as much as 30% larger. A very short .exe file, as in a
virus, would appear to be much smaller than a 1280x1024 .jpg image file. So
you could be keeping viruses, while discarding very safe images, if you are
relying on file length. Since the goal of AV vendors is to get definitions
for new malware pushed out within twelve hours of its appearance, you are
better of holding your attachments in quarantine for two, or three days,
then scanning with the latest definition file.

Best is to discard email from unrecognized sources. If your friends sent you
a picture of the family party, and tell you that is what was in the email
you are asking about, the odds are pretty good that it is nothing more than
a picture of the family party.

In its default configuration, MS Outlook Express will not render remote
images (URLs in HTML mail fetching .gif, .jpg, etc. from remote servers),
nor will it execute attached code:

Tools | Options | Security:

"Block images and other external content in HTML" is checked.

"Do not allow attachments to be saved or opened that could potentially be a
virus" is checked.

Also, MS Outlook Express, by default, uses the Internet Explorer "Restricted
Sites zone".

All of the above can be seen on that same Security tab in the path I
outlined.

From your last article:
I am using OE 6.0 and here is an example of the "gobbledeegook" pure text I
am finding using the properties|details|message source|scroll to bottom
method to view the seemingly hidden viruses in these emails...

And I used a very nifty utility I found, called, "UUDeview 1.3" to decode
that base64 encoded file. It opened in another nifty utility, "Irfanview
4.10", as an animated image (you failed to include the filetype, so
Irfanview complained about the .001 extension I retained from the decoding).
A 36x42x8 BPP image of a rose opening up. Avast did not find an infection.
Being animated, I assume .gif, and renamed the decoded image from
'unknown.001' to 'rose.gif', and now Irfanview just opens it up.

It is well to be suspicious, and I don't wish to discourage that. So I will
reiterate: Don't be trusting of attached files from any unknown, or strange
source; just dump those right away.

And, if you don't trust your friends, quarantine their email attachments for
a couple of days, then scan with the latest AV definitions. If they confirm
that they sent the attached file, and that they have their own, current AV
(ask them which they have), and your AV doesn't find anything malicious,
then it is probably okay to view a .jpg, or .gif, or other image filetype in
an image viewer, or to open a .doc with Wordpad, or, if you have the MS
Works suite, or MS Office suite, in Word.

It is better to keep asking them, and bugging them. If they get tired of it,
who knows? They may stop sending you stuff like that!
 
schmegly said:
I am using OE 6.0 and here is an example of the "gobbledeegook" pure text I
am finding using the properties|details|message source|scroll to bottom
method to view the seemingly hidden viruses in these emails:

Content-Transfer-Encoding: base64
Content-ID: <00ff01c925a1$ea4d0bd0$0200a8c0@ownernedxpyfdy>

R0lGODlhMgA0APcAAPfv7+7u/+7v7/Hm5ubp5u/e3t7i3ube3tfe1ufW1tbW/9rW1s3WzunOztzO
<snip - rest of encoded attachment>

By Googling for Base64 decoders and trying a couple of them, that code
represents a .gif file. It looks like an unfolding red flower with the
word "Buzz" beside it. For example, go to
http://www.toastedspam.com/decode64 and copy the encoded text (no
headers before or after) into the form. You'll see "GIF" at the start
of the decoded text along with the animated GIF picture. It would've
been a lot easier to decipher the base64 part if you hadn't omitted the
MIME headers within the message body or the Content type header.

At what point did you have proof that this e-mail was infected with a
virus? Just making up stuff because you don't understand how all
attachments (whether disposition is inline or attached) are encoded in
e-mails which are always sent as all plain text characters? All
"attachments" are inside the body of the e-mail. They are
disposition=inline or disposition=attached. That merely indicates how
an e-mail client should handle that attachment, whether to show it
inline the display of the message or to show separately from the
message, like some paperclip icon or a field that lists the attachments.

A lot of spammers use .gif files to hide their content from spam
filters. You think those spammers never screw up building their spam
mails? Presumably you didn't see the image otherwise you wouldn't have
asked about the gobblety-gook inside the e-mail.

Rich-Text Format (RTF) is Microsoft's proprietary encoding used to add
styling to a document, like bolding, italics, spacing, tables, etc; see
http://en.wikipedia.org/wiki/Rich_text_format. Outlook Express doesn't
understand RTF (TNEF). You should've seen the RTF styling info attached
as a winmail.dat file in OE. You will need something else to see the
e-mail as it was originally written, like the WinMail Opener
(http://www.eolsoft.com/freeware/winmail_opener/). One of the reasons
for not using RTF format is that it can get mangled during transport.
RTF should only be used between sender and recipient that are known to
both use Outlook and with the same Exchange server organization.

However, it wasn't an RTF e-mail that you got (you never mentioned
seeing a winmail.dat attachment). You got an e-mail with a .gif file
attached to it. When you attach a binary file's content (not the file
itself) into an e-mail, it has to get encoded into all that text-only
gobblety-gook. All e-mail is transported as plain text. That encoding
will bloat the size of the content. The bytes to hold the binary
content within a file is smaller than after it has been converted to a
series of text characters using a known encoding scheme. Figure the
size will increase anywhere from 2 to 3 times. If someone sends a 50KB
image file, figure it will bloat up to 150KB.
 
Back
Top