A Steganography sample malware
in [Anti-Virus]
|
Prev: c:\recycler\S-1-5-21-129_ ... Dc775.zip
Next: explorer.exe startet nicht richtig - HILFE bitte!!
From: Art on 26 Jun 2006 16:35 On Mon, 26 Jun 2006 22:12:45 +0200, "B. R. 'BeAr' Ederson" <br.ederson(a)expires-2006-06-30.arcornews.de> wrote: >On Mon, 26 Jun 2006 19:06:56 GMT, Art wrote: > >> I just noticed there's a "lossless" plugin for Irfan which I've yet to >> download. > >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... I made note of that. >> 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 > >You surely know that IrfanView can be scripted (via command line or ><Batch conversation/Rename>), too? I'd like to find a small stand-alone. Art http://home.epix.net/~artnpeg
From: kurt wismer on 26 Jun 2006 19:35 Art wrote: > On Sun, 25 Jun 2006 17:40:23 -0400, kurt wismer <kurtw(a)sympatico.ca> >> Art wrote: >> [snip] >>> I don't know what you mean by "least significant bit method". If we >>> can stick with the subject JPGs for the time being, clearly the >>> malware isn't hidden at all. >> also known as lsb steganography >> (http://en.wikipedia.org/wiki/Steganography#An_Example_from_Modern_Practice) >> >> [snip] >>>> Then it's not the jpg which gets executed. It's the "unknown" >>>> companion which just slipped past your av scanner. >>> Huh? They both execute. The companion causes the code in the >>> JPG to run. >> 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)... > > 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? 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?"
From: James Egan on 27 Jun 2006 00:22 On Mon, 26 Jun 2006 15:39:13 GMT, Art <null(a)zilch.com> wrote: >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. 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.
From: Art on 27 Jun 2006 07:14 On Tue, 27 Jun 2006 05:22:52 +0100, James Egan <jegan(a)jegan.com> wrote: >On Mon, 26 Jun 2006 15:39:13 GMT, Art <null(a)zilch.com> wrote: > >>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. > >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? 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
From: Art on 27 Jun 2006 08:45
On Tue, 27 Jun 2006 11:14:47 GMT, Art <null(a)zilch.com> wrote: >On Tue, 27 Jun 2006 05:22:52 +0100, James Egan <jegan(a)jegan.com> >wrote: > >>On Mon, 26 Jun 2006 15:39:13 GMT, Art <null(a)zilch.com> wrote: >> >>>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. >> >>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? > >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. 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 |