A Steganography sample malware - Page 4

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Re: A Steganography sample malware

On Mon, 26 Jun 2006 09:36:31 +0200, B. R. 'BeAr' Ederson wrote:

Quoted text here. Click to load it

To try this, save the original image and the one compressed afterwards
with 100% into a lossless, non-compressing image format.

Remind: The JPEG format is lossy even at 100%. Only JPEG2000 introduces
lossless compression.

BeAr
--
===========================================================================
= What do you mean with: "Perfection is always an illusion"?              =
===============================================================--(Oops!)===

Re: A Steganography sample malware

On Mon, 26 Jun 2006 09:56:47 +0200, "B. R. 'BeAr' Ederson"

Quoted text here. Click to load it

Well, BeAr, while I'm enthused about the idea, I would have to do a
lot of "boning up" work before pursuing any more tests. I lack the
requisite expertise and the tools in several areas. I've never even
studied the various image formats in detail.

Your suggestion of making sure the Saved image is lossless and
non-compressed interests me though. I might give that a try just
to see if the three av products still fail to alert on the result.
Doing a viability test though will be difficult, I would think. I
would have to allow the companion to run and then check to
see if it was succussful in running the embedded code under
both conditions .... unmodified JPG and modified JPG. Makes
me wonder if there's a much easier way to determine that
the JPG has been rendered harmless. There again, I lack the
analysis tools and expertise.

Art
http://home.epix.net/~artnpeg

Re: A Steganography sample malware

On Mon, 26 Jun 2006 13:17:42 GMT, Art wrote:

Quoted text here. Click to load it

I made this suggestion for comparing equivalents of the memory imprint
of different versions of a picture. It removes the necessity of direct
memory access.

Quoted text here. Click to load it

IMHO, the testbed needed is the first question, which is difficult to
answer. Let's have a look a different possibilities of storing code
inside a *.jpg picture: (Not all qualify as steganography, but could
be efficient, nevertheless.)

- Usage (abuse) of standard header fields: Would show up garbage with
  dedicated tools; usually unaffected by image manipulation; only
  few transformations to different image file formats will retain this
  data; can be deleted using standard tools
- Creation of hidden data streams: persistence depends on algorithm
  for saving used by the image manipulation program; should not
  survive format changes
- Embedding into the memory imprint of the picture: Image manipulation
  may or may not successfully destroy the data; changed compression
  factor will probably have the largest impact (as long as the visual
  appearance of the image shall not be altered, noticeably); code may
  be activated even within the other file format (that format can be
  compressed or not compressed, when extraction is done from memory)
- Embedding in an intermediary result of decompression (for instance
  luminance or chrominance data or the result of a predefined step of
  decompression): Consequences of image manipulation and format
  changes aren't predictable, as long as the storage algorithm of the
  code is unknown; compression changes may show the best effect in
  destroying the code, but may be non-effective for special crafted
  data
- Embedding into the data stream of the image *file* (on disk): Could
  survive image manipulation methods, as long as no compression
  change is involved; usually destroyed by saving with another
  compression factor; may survive lossless back-and-forth format
  changes as long as the last saving as *.jpg is done with original
  compression
- Core information storage: the code is embedded within the data
  which endures the most radical image manipulation (transformation
  to black and white and the like): needs huge image sizes for
  moderate code amounts; probably combined with checksums and
  autocorrection; will probably survive any non-destructive image
  manipulation, format change,...
- Specially crafted noise data with redundance for checksums and
  auto-correction: dto.

Quoted text here. Click to load it

This would need knowledge about the algorithm used by the malware
and about the code inside the picture, IMHO. And even if the code
seems defunct: If the next version of the trigger program includes
some "parity" bytes, it may repair the whole thing, nevertheless.

Just a few thoughts. And not meant to be complete in any way.

BeAr
--
===========================================================================
= What do you mean with: "Perfection is always an illusion"?              =
===============================================================--(Oops!)===

Re: A Steganography sample malware

On Mon, 26 Jun 2006 16:45:34 +0200, "B. R. 'BeAr' Ederson"

Quoted text here. Click to load it

BTW, I haven't yet located a suitable image manipulator that will Save
as lossless. I did a experiment this morning still using IrfanView and
I found that simply Saving the image as JPG at 100% quality is
sufficient to detroy detection by the three vendors. IOW, using
IrfanView, there's no need to change brightness or anything. I was
surprised at this result of checking file sizes:

NT1.JPG Original   25,277 bytes
NT1.JPG Saved by Irfan  1,643 bytes

NT2.JPG Original   36,214 bytes
NT2.JPG Saved by Irfan  1,634 bytes

Maybe that info will give you a clue on the method used by the
bad guys in this case of embedding the code. I'd guess that
the embedded code was completely clobbered by whatever
IrfanVeiw does when it Saves the JPG at 100% quality without
any attempt at image manipulation by the user in any way.

Art
http://home.epix.net/~artnpeg

Re: A Steganography sample malware

On Mon, 26 Jun 2006 15:39:13 GMT, Art wrote:

Quoted text here. Click to load it

IrfanView writes "Windows Bitmap" as uncompressed. This way you should
get an exact representation of the memory imprint of the currently
opened *.jpg file.

Quoted text here. Click to load it

Interesting. Looks like the malware code is stored as "hidden data
stream". (As I called it in my last posting.) You may experiment with
advanced options (keep original EXIF/IPTC/Comments) to see, whether
the code is located in such fields. And you may test the structure
using this (or a similar) tool:

  www.picturel.com/utils.html  (JPEGInfo)

Quoted text here. Click to load it

Sounds reasonable. But to be sure...  ;-)

BeAr
--
===========================================================================
= What do you mean with: "Perfection is always an illusion"?              =
===============================================================--(Oops!)===

Re: A Steganography sample malware

On Mon, 26 Jun 2006 19:50:07 +0200, "B. R. 'BeAr' Ederson"

Quoted text here. Click to load it

I just noticed there's a "lossless" plugin for Irfan which I've yet to
download.

Quoted text here. Click to load it

I've been leaving those checked.

Quoted text here. Click to load it

Got and tried it out, thanks.

Quoted text here. Click to load it

I did some searching for a (preferably) freeware image converter, and
so far one freeware and one payware app seem to do a similar thing in
that they cut the file size down to about 1.5 KB. The freeware 2JPEG
is a command line converter that makes it convenient to write programs
or batch programs to find all JPGs and filter out the embedded code,
though I realize I'm getting ahead of myself here in saying that :)
But most likely it seems that such a simple scheme will work for the
particular method of embedding used in the subject JPG files. That IMO
would be cool. At least it seems quite promising at this point.

Art
http://home.epix.net/~artnpeg

Re: A Steganography sample malware

On Mon, 26 Jun 2006 19:06:56 GMT, Art wrote:

Quoted text here. Click to load it

It is for some standard operations which can be done lossless (like
basic rotation and scrubbing of EXIF data). It would be interesting,
whether <Optimize JPG file> or <*don't* keep other APP markers>
results in any significant size changes on your pictures...

Quoted text here. Click to load it

You surely know that IrfanView can be scripted (via command line or
<Batch conversation/Rename>), too?

BeAr
--
===========================================================================
= What do you mean with: "Perfection is always an illusion"?              =
===============================================================--(Oops!)===

Re: A Steganography sample malware

On Mon, 26 Jun 2006 22:12:45 +0200, "B. R. 'BeAr' Ederson"

Quoted text here. Click to load it

I made note of that.

Quoted text here. Click to load it
 
I'd like to find a small stand-alone.

Art
http://home.epix.net/~artnpeg

Re: A Steganography sample malware


Quoted text here. Click to load it

Irfanview will automatically zap anything in the file after the FF D9
end of image marker. I just tested it to see.

What does your hex editor say? Is it that simple?


Jim.


Re: A Steganography sample malware

wrote:

Quoted text here. Click to load it

Not quite :) I took NT1.JPG and found several occurances of FF D9.
If I blindly truncate everything after the first occurance, I do wind
up with a seemingly normal froggie image with a file length of 886
bytes. If I use the Irfan Save method I get a file length of 1,634
bytes.

It's interesting that when I use the Irfan Save method on the 886
byte file,  the result is a 1,634 byte file ... the same length
resulting from using the Irfan Save method on the original.

Art
http://home.epix.net/~artnpeg
 

Re: A Steganography sample malware


Quoted text here. Click to load it

To add a little more info, I found that all four files have the same
identical characteristic in that truncating them just after the first
occurance of FF D9 results in a 886 byte froggie which Irfan "thinks"
is a legit JPG file. By four files, I mean in addition to NT1, 2, 3
I'm including WINLOGON.JPG. In this latter file I found only one
occurance of FF D9 and that's probably the file Jim was looking
at.

I looked at a few ordinary or normal JPG files and they have
FF D9 at the actual EOF while none of the Trojaned files do,
so that suggests a simple heuristic for sorting and continuing to
look further only if no FF D9 exists at the actual EOF. Thus a
scrubber specifically aimed at these types of Trojaned files wouldn't
have to touch normal files at all. I too now wonder if it might turn
out to be very simple. What would be the danger in using a
simple agorithm that sorts JPGs on the basis of requiring FF D9 at
actual EOF and if not, truncate everything after the first
occurance of FF D9? Or maybe just delete all such files
and not bother to truncate them at all? Or leave the decision
up to the user?

Makes me wonder why more av aren't using a such a simple heuristic
to at least flag these files as suspicious.

Art
http://home.epix.net/~artnpeg
  

Re: A Steganography sample malware


Quoted text here. Click to load it

I haven't got any of the files. I just added some plaintext onto the
end of a smallish jpg on my machine here to see if Irfanview left it
in after "saving as" another jpg. It didn't, of course, because it was
only interested in the stuff up to the first (and only in this case)
end of image marker and used that for creating its new file. The fact
that the image is a bit bigger than the original is one of the quirks
of jpeg when saving a low grade image at a higher percentage.

This appending at the end of the file is a common technique in some of
the not very good steganography products which guillermito reversed a
few years back. A good read if you're interested.
http://www.guillermito2.net/stegano /


Jim.


Re: A Steganography sample malware

wrote:

Quoted text here. Click to load it

Yep. It's nice that a method like that isn't required at all.  

Quoted text here. Click to load it

Yes it is indeed a good read. Your inputs have been helpful. Thanks.

Art
http://home.epix.net/~artnpeg

Re: A Steganography sample malware

On Mon, 26 Jun 2006 00:12:26 GMT, Phil Weldon wrote:

---------- restored snipped text --------------------------
Quoted text here. Click to load it
-----------------------------------------------------------
Quoted text here. Click to load it

I don't think, whether it is wise to answer, at all. But I'd like to
assure you, that you still walk another path in this discussion as
I do. The sentence in parenthesis doesn't mean that I consider your
approach wrong. Quite the opposite. It just says, that it *may*
prove unusable. And to sort that out isn't a task for *testing* a
couple of images, but for *research*.

Quoted text here. Click to load it

My first post on that subject:


is already based on testing images and clearly states:

| If you try your suggestion on an image twice in a row to ensure the same
| compression settings, you'll find large portions of the images 2 and 3
| unchanged. Most of the data may shift position. But a trigger program
| can look for code snippets to get the offset of the malicious code.

After that, I explained the most likely reason. - Without going into the
depth, because I still think the more subtle details have to be sorted
out by specialists. Cryptography, steganography and compression can't
be dealt with in an amateur fashion. OTOH, showing that an approach is
*not* sufficient only needs one sample out of the line. And that's, what
I posted about.

Quoted text here. Click to load it

No polemic on my side. Did your try your suggestion yourself? Under
the additional condition of unchanging compression method and strength?
(Which is necessary to rule out other influences when testing the effect
of brightness changes.)

BeAr
--
===========================================================================
= What do you mean with: "Perfection is always an illusion"?              =
===============================================================--(Oops!)===

Re: A Steganography sample malware


message
Quoted text here. Click to load it

What about rotating 90 degrees...or interleaving the bitmapped image
data and resaving?

...of course, all could be gotten around with newer malware versions.



Re: A Steganography sample malware

On Sun, 25 Jun 2006 17:15:53 -0400, edgewalker wrote:

Quoted text here. Click to load it

IMHO, saving the file with another compression method or compression
level shows better results than most (any?) global operations. (That's
my - subjective - impression of comparing nearly related files.)
 
Quoted text here. Click to load it

Yes. Sad but true. (At least to a degree which can not be foreseen
at the moment.)

BeAr
--
===========================================================================
= What do you mean with: "Perfection is always an illusion"?              =
===============================================================--(Oops!)===

Re: A Steganography sample malware

Art wrote:
[snip]
Quoted text here. Click to load it

also known as lsb steganography
(http://en.wikipedia.org/wiki/Steganography#An_Example_from_Modern_Practice )

[snip]
Quoted text here. Click to load it

if i'm not mistaken, the companion *extracts* the code from the jpg and
then runs it... the jpg itself is never actually run... that's how
steganography generally works anyways (the stego app extracts the hidden
information for subsequent use)...

--
"it's not the right time to be sober
now the idiots have taken over
spreading like a social cancer,
is there an answer?"

Re: A Steganography sample malware

wrote:

Quoted text here. Click to load it

That's what I ASSumed when I fearlessly Opened the little froggies
in IrfanView. I don't know how to Run JPGs anyway :) Maybe you were
thinking of the possibility of disguised executeables that might Run
in Windows in spite of the file extension?

Art
http://home.epix.net/~artnpeg

Re: A Steganography sample malware

Art wrote:
Quoted text here. Click to load it

actually, for a deviation from the steganography norm, i was thinking of
something a little more like the eicar standard anti-virus test file...
if something can be a *.com file and plain ascii text at the same time
it stands to reason that *.com/jpg combinations might be possible too...

but i suspect that's rather difficult to implement...

--
"it's not the right time to be sober
now the idiots have taken over
spreading like a social cancer,
is there an answer?"

Re: A Steganography sample malware

On Sat, 24 Jun 2006 12:19:06 GMT, Art wrote:

Quoted text here. Click to load it

If known malicious code is deliberately excluded from detection when
placed within non-executable data, the release of trigger programs
will become some kind of sport, the AV vendors will lose every now
and then. Moreover, if "appropriate" pictures are selected for the
code injection, they will spread like fire and last forever.  :-(

Therefore, I generally agree with you. To limit the necessary sigs
and detection algorithms, spreading and dangerousness should be
taken into account. As every computer already contains a lot of
code which *can* be exploited for malicious actions, the specifics
of the steganographic hidden code are decisive, IMHO.

BeAr
--
===========================================================================
= What do you mean with: "Perfection is always an illusion"?              =
===============================================================--(Oops!)===

Site Timeline