A Steganography sample malware - Page 3

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

Threaded View

Re: A Steganography sample malware

On Sun, 25 Jun 2006 03:08:17 GMT, "Phil Weldon"

Quoted text here. Click to load it

I know, and most likely the data loss blows away one idea I had which
was was to attempt a reversal to a bitmap image which might be
analyzed for noisyness. Even then though, sig/noise ratios would be
prohibitively small with a smal number of  embedded bytes. Perhaps one
reason I thought of the idea is the fidelity enhancement that's been
done on audio recordings made many decades ago, where there is analog
data loss , so to speak, yet much "data" is recreated.

So I'm stumped right now on even the reduced problem of detecting that
something is amiss and then warning users.

Quoted text here. Click to load it

I hate to since I can't get past JPGs :)

Quoted text here. Click to load it

You and most everyone else, it seems. Clearly, you and others are way
ahead of me in giving thought to the problems. It's fine that people
have brought up the more general problems and issues in this thread.
Personally, I'm still wondering about what's going on with the av
vendors concerning the subject sample files. It strikes me as very
curious that only three vendors (as of last night) alert on the JPGs
and they each have their own unique kind of alert ... Symantec going
so far as to specify three different malwares in the three different
JPGs. It's also curious that neither David Lipman nor myself have
heard a peep back from Kaspersky concerning the JPG samples. It will
be interesting to see how this unfolds.  

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

Re: A Steganography sample malware

On Sun, 25 Jun 2006 01:25:38 GMT, Phil Weldon wrote:

Quoted text here. Click to load it

Not necessarily so. The reason for significant changes within the picture
would be the compression by another algorithm and/or another compression
factor rather than the overall brightness change.

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. It
doesn't need to depend on exact positions. If AV programs always used
brightness changes to "disinfect" *.jpg files, virus writers would just
place the code in the chrominance part of the data stream. (Luminance
and chrominance are compressed separately in *jpg files.)

Moreover, all JFIF (JPEG File Interchange Format) files comprise of
several data blocks/streams. Besides using IPTC/EXIF metadata fields
it may be not to hard a task to construct blocks neither visible nor
changed by usual picture handling. That's the kind of pictures Art
targets when he talks about heuristic detection of suspicious files.
(If I get him right.) I, too, would be glad, if AV programs would
issue a warning about data files containing seemingly executable
code within text header fields or additional data streams.

Btw.: There is currently some research on the topic, how data of
pictures has to be manufactured to survive lossy transformation:

  http://research.binghamton.edu/faculty/fridrich/fridrich.htm

Though the focus of the research of Jessica Fridrich is detecting
the original source (camera) of a picture (and the like), it
inevitably also shows, where to "best" hide information...

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

Re: A Steganography sample malware

'B. R. 'BeAr' Ederson' wrote, in part:
| Not necessarily so. The reason for significant changes within the picture
| would be the compression by another algorithm and/or another compression
| factor rather than the overall brightness change.
_____
The overall 'brightness' change propagates thru the recompression, even
reusing the same compression process with the same compression factor.

There are many filters that will do the same.

My suggestion is for a simple change to an image that would destroy
executable code, not a generalized method for defeating steganography.

You describe the beginning of an arms race, which I brought up my subsequent
reply to 'Art'.

Phil Weldon

| On Sun, 25 Jun 2006 01:25:38 GMT, Phil Weldon wrote:
|
| > Try an image editor and change the overall 'brightness by 1%.  That
should
| > destroy any executable hidden in a .jpg image.
|
| Not necessarily so. The reason for significant changes within the picture
| would be the compression by another algorithm and/or another compression
| factor rather than the overall brightness change.
|
| 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. It
| doesn't need to depend on exact positions. If AV programs always used
| brightness changes to "disinfect" *.jpg files, virus writers would just
| place the code in the chrominance part of the data stream. (Luminance
| and chrominance are compressed separately in *jpg files.)
|
| Moreover, all JFIF (JPEG File Interchange Format) files comprise of
| several data blocks/streams. Besides using IPTC/EXIF metadata fields
| it may be not to hard a task to construct blocks neither visible nor
| changed by usual picture handling. That's the kind of pictures Art
| targets when he talks about heuristic detection of suspicious files.
| (If I get him right.) I, too, would be glad, if AV programs would
| issue a warning about data files containing seemingly executable
| code within text header fields or additional data streams.
|
| Btw.: There is currently some research on the topic, how data of
| pictures has to be manufactured to survive lossy transformation:
|
|  http://research.binghamton.edu/faculty/fridrich/fridrich.htm
|
| Though the focus of the research of Jessica Fridrich is detecting
| the original source (camera) of a picture (and the like), it
| inevitably also shows, where to "best" hide information...
|
| BeAr
| --
|
===========================================================================
| = What do you mean with: "Perfection is always an illusion"?
=
|
===============================================================--(Oops!)===



Re: A Steganography sample malware



| _____
| The overall 'brightness' change propagates thru the recompression, even
| reusing the same compression process with the same compression factor.
|
| There are many filters that will do the same.
|
| My suggestion is for a simple change to an image that would destroy
| executable code, not a generalized method for defeating steganography.
|
| You describe the beginning of an arms race, which I brought up my subsequent
| reply to 'Art'.
|
| Phil Weldon
|
Since there is NO content worth saving, manual deletion or removal via AV
software is
warranted.  Modification with a Graphics manipulation application is just a
wasteful action.

--
Dave
http://www.claymania.com/removal-trojan-adware.html
http://www.ik-cs.com/got-a-virus.htm



Re: A Steganography sample malware

On Sun, 25 Jun 2006 17:00:45 GMT, "David H. Lipman"

Quoted text here. Click to load it

Not wasteful at all if something like that could be developed that
would do the job without signifcant loss of image quality. My idea
of it is as I said ... scrub all JPG images found (with user
permission). Period. That gets around the very difficult problems
inherent in attempting to detect embedded code reliably. Very
slick solution if it can be made to work well.

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

Re: A Steganography sample malware



|
| Not wasteful at all if something like that could be developed that
| would do the job without signifcant loss of image quality. My idea
| of it is as I said ... scrub all JPG images found (with user
| permission). Period. That gets around the very difficult problems
| inherent in attempting to detect embedded code reliably. Very
| slick solution if it can be made to work well.
|
| Art
| http://home.epix.net/~artnpeg

Come on.  Do you really need the Frog ?
None of teh JPEGs which contain the malware have content worth keeping.

--
Dave
http://www.claymania.com/removal-trojan-adware.html
http://www.ik-cs.com/got-a-virus.htm



Re: A Steganography sample malware

On Sun, 25 Jun 2006 18:28:49 GMT, "David H. Lipman"

Quoted text here. Click to load it

Needing the frog has absolutely nothing to do with it, David.  
  
Quoted text here. Click to load it

So what? That's completely beside the point and irrelevant.

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

Re: A Steganography sample malware


| On Sun, 25 Jun 2006 18:28:49 GMT, "David H. Lipman"
|
Quoted text here. Click to load it
|
| Needing the frog has absolutely nothing to do with it, David.
|
Quoted text here. Click to load it
|
| So what? That's completely beside the point and irrelevant.
|
| Art
| http://home.epix.net/~artnpeg

I don't think so.  These JPEGs are provided, not requested.  Therefore just
remove the
bloddy things.  I see no need for graphics manipulation to deal with this.  I
think it to be
wasteful endeavour.

--
Dave
http://www.claymania.com/removal-trojan-adware.html
http://www.ik-cs.com/got-a-virus.htm



Re: A Steganography sample malware

On Sun, 25 Jun 2006 21:55:24 GMT, "David H. Lipman"

Quoted text here. Click to load it

On what basis? How do users know which JPGs are infested and which
aren't?

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

Re: A Steganography sample malware



|
| On what basis? How do users know which JPGs are infested and which
| aren't?
|
| Art
| http://home.epix.net/~artnpeg

You're not going to be getting JPEGs from reputable companies that have a Trojan
embedded.
You'll be getting them at malicious locations.  That's why detection is
important.  If they
are found, the file should summarily be deleted.

--
Dave
http://www.claymania.com/removal-trojan-adware.html
http://www.ik-cs.com/got-a-virus.htm



Re: A Steganography sample malware

On Sun, 25 Jun 2006 22:46:43 GMT, "David H. Lipman"

Quoted text here. Click to load it

But detection of embedded malware is highly problematical and almost
non-existent at the present time. That's why I like the idea of
routinely scrubbing all JPGs.

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

Re: A Steganography sample malware

'Dave' wrote:
| Since there is NO content worth saving, manual deletion or removal via AV
software is
| warranted.  Modification with a Graphics manipulation application is just
a wasteful action.
_____

Ah, but to be removed, it must be detected.

Removal of an image known to have steganographic content is trivial.

Please read my second reply to 'Art' 6/25/2006 11:27 AM.

Phil Weldon

|
|
|| _____
|| The overall 'brightness' change propagates thru the recompression, even
|| reusing the same compression process with the same compression factor.
||
|| There are many filters that will do the same.
||
|| My suggestion is for a simple change to an image that would destroy
|| executable code, not a generalized method for defeating steganography.
||
|| You describe the beginning of an arms race, which I brought up my
subsequent
|| reply to 'Art'.
||
|| Phil Weldon
||
| Since there is NO content worth saving, manual deletion or removal via AV
software is
| warranted.  Modification with a Graphics manipulation application is just
a wasteful action.
|
| --
| Dave
| http://www.claymania.com/removal-trojan-adware.html
| http://www.ik-cs.com/got-a-virus.htm
|
|



Re: A Steganography sample malware

David H. Lipman wrote:
[snip]
Quoted text here. Click to load it

i believe the idea is to neuter all possible steganographic archives in
images without going to the trouble of locating/identifying them... in
the example in question it's easy enough to find out which image to get
rid of, but in general it may not be...

--
"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 Sun, 25 Jun 2006 15:27:46 GMT, Phil Weldon wrote:

Quoted text here. Click to load it

Again:
Quoted text here. Click to load it


I just tried to tell you that your suggested method isn't enough. You
may knew that much by yourself. But one cannot guess that from your
postings and others may think themselves safe, applying your suggestion.

Quoted text here. Click to load it

I describe 2 things: There are possibilities for general (heuristic)
detection of abnormal formed data file sections. And your described
method has to be refined to really be useful. And that's not just a
matter of including the chrominance part of the data stream - because
the compression algorithm may permit the construction of data which
survives several transformations (as seems to be the case with JPEG).

I surely *don't* propagate the inclusion of detection routines for
all steganographic methods ever detected to be used for malware.

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

Re: A Steganography sample malware

'BeAr' wrote, in part:

| I just tried to tell you that your suggested method isn't enough. You
| may knew that much by yourself. But one cannot guess that from your
| postings and others may think themselves safe, applying your suggestion.

I really don't think that is a problem.  And, I'd posit, the current samples
'Art' and 'Dave' have WOULD be rendered innocuous as executable code with a
simple manipulation.  But maybe not.  The proof is in the pudding, and I
don't have any pudding.

| I surely *don't* propagate the inclusion of detection routines for
| all steganographic methods ever detected to be used for malware.

That will ultimately fail.

| I describe 2 things: There are possibilities for general (heuristic)
| detection of abnormal formed data file sections.

What's the second?

| And your described
| method has to be refined to really be useful.

Of course.  That's why I suggested 'Art' 'try' raising the brightness by 1%.
The brightness change in image editing applications is done on the
decompressed image.

Why don't you experiment with your idea of steganographic content surviving
more than one compression?  And report the results here?  That would be a
real contribution.

How many bits must change to render a block of code unusable?
Multiple instances of the code block with CRC?

How many angels can dance on the head of a pin?  On one the pin head must be
large enough to be useful for dancing and on the other you  the angels must
be seen dancing.

Phil Weldon





| On Sun, 25 Jun 2006 15:27:46 GMT, Phil Weldon wrote:
|
| > The overall 'brightness' change propagates thru the recompression, even
| > reusing the same compression process with the same compression factor.
|
| Again:
| >| 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. It
| >| doesn't need to depend on exact positions. If AV programs always used
| >| brightness changes to "disinfect" *.jpg files, virus writers would just
| >| place the code in the chrominance part of the data stream. (Luminance
| >| and chrominance are compressed separately in *jpg files.)
|
| > My suggestion is for a simple change to an image that would destroy
| > executable code, not a generalized method for defeating steganography.
|
| I just tried to tell you that your suggested method isn't enough. You
| may knew that much by yourself. But one cannot guess that from your
| postings and others may think themselves safe, applying your suggestion.
|
| > You describe the beginning of an arms race, which I brought up my
subsequent
| > reply to 'Art'.
|
| I describe 2 things: There are possibilities for general (heuristic)
| detection of abnormal formed data file sections. And your described
| method has to be refined to really be useful. And that's not just a
| matter of including the chrominance part of the data stream - because
| the compression algorithm may permit the construction of data which
| survives several transformations (as seems to be the case with JPEG).
|
| I surely *don't* propagate the inclusion of detection routines for
| all steganographic methods ever detected to be used for malware.
|
| BeAr
| --
|
===========================================================================
| = What do you mean with: "Perfection is always an illusion"?
=
|
===============================================================--(Oops!)===



Re: A Steganography sample malware

On Sun, 25 Jun 2006 19:33:36 GMT, Phil Weldon wrote:

Quoted text here. Click to load it

That's the second. (And maybe the method isn't worth the effort of
refining, at all...)

Quoted text here. Click to load it

You don't get! I posted the results: The first picture I choose to
manipulate the way you suggested had barely half the data altered, if
you don't do a byte-by-byte comparison but allow realignment. The
streams of unaltered data comprise of several dozen to several hundred
bytes in a row. Enough to store code within. You can try by yourself.
But it isn't worth to further pursue this in such a trivial approach.

And I posted before, that outcome is supposed by design of the JPEG
compression algorithm. I could sit down and think of a method to alter
chrominance, too, using a method which doesn't render the picture
ugly/useless.

If you read (and understood) my first posting, you'd know by now, that
I regard the true and sustainable "disinfection" a non-trivial task.
Otherwise, similar topics wouldn't be military funded university
research themes. Whether this degree of knowledge is required for
dealing with that topic depends (of course) on the sophistication
used by manufacturing the malicious sample.

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

Re: A Steganography sample malware

'BeAr' wrote, in part:
| That's the second. (And maybe the method isn't worth the effort of
| refining, at all...)
_____

So much for a fruitful discussion.

What I don't get is why you are claiming the non-existent.

Did you post '| You don't get! I posted the results: The first picture I
choose to
| manipulate the way you suggested had barely half the data altered, if
| you don't do a byte-by-byte comparison but allow realignment.'
steganographically?

And I don't get why you treat a suggestion for an experiment as an excuse
for a polemic.

Phil Weldon

| On Sun, 25 Jun 2006 19:33:36 GMT, Phil Weldon wrote:
|
| >| I describe 2 things: There are possibilities for general (heuristic)
| >| detection of abnormal formed data file sections.
| >
| > What's the second?
| >
| >| And your described method has to be refined to really be useful.
|
| That's the second. (And maybe the method isn't worth the effort of
| refining, at all...)
|
| > Why don't you experiment with your idea of steganographic content
surviving
| > more than one compression?  And report the results here?  That would be
a
| > real contribution.
|
| You don't get! I posted the results: The first picture I choose to
| manipulate the way you suggested had barely half the data altered, if
| you don't do a byte-by-byte comparison but allow realignment. The
| streams of unaltered data comprise of several dozen to several hundred
| bytes in a row. Enough to store code within. You can try by yourself.
| But it isn't worth to further pursue this in such a trivial approach.
|
| And I posted before, that outcome is supposed by design of the JPEG
| compression algorithm. I could sit down and think of a method to alter
| chrominance, too, using a method which doesn't render the picture
| ugly/useless.
|
| If you read (and understood) my first posting, you'd know by now, that
| I regard the true and sustainable "disinfection" a non-trivial task.
| Otherwise, similar topics wouldn't be military funded university
| research themes. Whether this degree of knowledge is required for
| dealing with that topic depends (of course) on the sophistication
| used by manufacturing the malicious sample.
|
| BeAr
| --
|
===========================================================================
| = What do you mean with: "Perfection is always an illusion"?
=
|
===============================================================--(Oops!)===



Re: A Steganography sample malware

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

BTW, Phil, I did try a experiment altering the brightness slightly
and it did result in all three vendors that normally alert then not
alerting. I use IrfanView which might not be the best for the
purpose since when I Save the altered image it has a "Save
qaulity" slider which ranges from 0 to 100%. I'm concerned
that even with a 100% setting, there may be changes to
the original in addition to just brightness. Also, with just a simple
small cartoonish image as the Frog, any subjective judgements
as to discernable differences to my eye and brain betweeen
the original and the altered image are worthless in this case.
You can really make pretty drastic changes to brightness,
colors, contrast and gamma correction without noticeable
changes in to the eye in this particular case, or at least to
the subjective picture quality.

Loss of detection by av is one thing, and viability is another
matter. The proof of the pudding, as always, is whether or
not the embedded code has been rendered unworkable and
harmless. But it's pointless for me to try viability tests on a
goat machine without knowing _exactly_ how the image is
modified. I think for that, I would need far better tools and
preparation than I have.

I thought though that you might be interested in the result
of a sort of "quick and dirty" test anyway. I still think you have
a good idea ... at least until proven otherwise. I also think
quite a extensive develpment and testing project is required to
determine whether or not the idea is truly feasible.

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

Re: A Steganography sample malware

'Art' wrote, in part:
| BTW, Phil, I did try a experiment altering the brightness slightly
| and it did result in all three vendors that normally alert then not
| alerting.

Thanks for the reply Art.  Since I don't have a sample image, I can't try it
myself.  Applications like 'Photo Paint' in the Corel Draw suite and Adobe
PhotoShop offer a lot more choices, including customized plug-in filters.

Phil Weldon

| On Mon, 26 Jun 2006 00:12:26 GMT, "Phil Weldon"
|
| BTW, Phil, I did try a experiment altering the brightness slightly
| and it did result in all three vendors that normally alert then not
| alerting. I use IrfanView which might not be the best for the
| purpose since when I Save the altered image it has a "Save
| qaulity" slider which ranges from 0 to 100%. I'm concerned
| that even with a 100% setting, there may be changes to
| the original in addition to just brightness. Also, with just a simple
| small cartoonish image as the Frog, any subjective judgements
| as to discernable differences to my eye and brain betweeen
| the original and the altered image are worthless in this case.
| You can really make pretty drastic changes to brightness,
| colors, contrast and gamma correction without noticeable
| changes in to the eye in this particular case, or at least to
| the subjective picture quality.
|
| Loss of detection by av is one thing, and viability is another
| matter. The proof of the pudding, as always, is whether or
| not the embedded code has been rendered unworkable and
| harmless. But it's pointless for me to try viability tests on a
| goat machine without knowing _exactly_ how the image is
| modified. I think for that, I would need far better tools and
| preparation than I have.
|
| I thought though that you might be interested in the result
| of a sort of "quick and dirty" test anyway. I still think you have
| a good idea ... at least until proven otherwise. I also think
| quite a extensive develpment and testing project is required to
| determine whether or not the idea is truly feasible.
|
| Art
| http://home.epix.net/~artnpeg



Re: A Steganography sample malware

On Mon, 26 Jun 2006 01:12:26 GMT, Art wrote:

Quoted text here. Click to load it

Huh? If the former compression wasn't 100%, too, the images will have
*significantly* other data streams. Just save an *unchanged* image
with 100% to test. The JPEG algorithm changes quantisation step
width and the like according to the compression factor.

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

Site Timeline