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 24 Jun 2006 21:38 On 24 Jun 2006 18:19:39 -0700, "Dustin Cook" <bughunter.dustin(a)gmail.com> wrote: > >Art wrote: > >> Do av really have to determine that a "diddled with" JPG contains >> encrypted "information" and be able to deal with decrypting it? Or is >> it sufficient to recognize that something is definitely unusual for a >> otherwise recognizable JPG format? > >How would AV know if it's diddled or not? The whole point behind the >process is to alter only enough bits spread thruout the file to store >your data, for all intents and purposes, it's video data... Nothing but >a few bytes here and there altered... hardly noticable... A downloader Trojan (for example) in just a few bytes? I was thinking in terms of otherwise unused space and a fairly large # of bytes. I don't know if it's practical to alter the large # of bytes for complex Trojans in the actual image data without very noticeable picture distortions (noisy images). Guess it's time to really study the subject rather than just glossing over a article or two on picture image steganography :) Art http://home.epix.net/~artnpeg
From: Art on 24 Jun 2006 22:16 On Sun, 25 Jun 2006 01:25:38 GMT, "Phil Weldon" <notdiscosed(a)example.com> wrote: >'Art' wrote, in part: >| Well, I suppose I could modify the JPGs I have slightly and see if Bit >| Defender and Symantec quit alerting on them. >_____ > >Try an image editor and change the overall 'brightness by 1%. That should >destroy any executable hidden in a .jpg image. Now, there's some thinking outside the box! Let's say that such a minor and unobjectionable modification to color, brightness, contrast, etc., is a sure-fire way to destroy the code. Call your invention a "malware scrubber for JPGs" and peddle it :) Or maybe av products could incorportate a scrubber feature whereby with user permission all JPGs on all drives are found and scrubbed. Anyone with legit JPG steganogrphy files could keep them on removeable media for safety from the scrubbing operation. Art :) http://home.epix.net/~artnpeg
From: Phil Weldon on 24 Jun 2006 23:08 'Art' wrote, in part: | Now, there's some thinking outside the box! Let's say that such a | minor and unobjectionable modification to color, brightness, contrast, | etc., is a sure-fire way to destroy the code. _____ JPEG compression is 'lossy'; the image cannot be restored to the original quality, as are other compression standards, including MPEGx, MP3, and WMF. Think about the steganographic possibilities with MPG2 files! Ultimately, I think the cost of defense against steganographic content is not bearable for any but the most critical applications (and that is likely to be hidden data, not executables.) The defense will be blocking the decoder malware. Consider the possibilities of broadband MPG2 content distributed on the Internet. MPG2 compression has more dimensions than JPEG because time is involved. More than one 'frame' of information is necessary to reconstruct any one displayable frame. Steganography with MPEG2, for example, could include information from more than one frame that must be combined to retrieve the hidden message. At a certain level of complexity the processing power to even find a recognizable signature would be prohibitive, especially since it would have to be done in real time. Some frames could contain information that the decoder malware could use to find the real message. That could go to arbitrary levels - easy for the decoder malware, very difficult to defend against. This could lead to an arms race with offense being much cheaper than defense - a $50,000 anti-tank missile destroys a $3,000,000 tank; a $1,000,000 missile destroys a $1,000,000,000 ship. Analog broadcast television (and videotapes) have long had hidden information in the vertical blanking interval. NTSC television, for example, has 525 lines, but 42 lines are hidden, and have no picture content. A number of these lines are available for switching signals, test signals, closed captioning, auxiliary data services ( and other, covert uses I am sure.) Phil Weldon "Art" <null(a)zilch.com> wrote in message news:umrr92lt86ukpvlnugq30bg3t705bnese4(a)4ax.com... | On Sun, 25 Jun 2006 01:25:38 GMT, "Phil Weldon" | <notdiscosed(a)example.com> wrote: | | >'Art' wrote, in part: | >| Well, I suppose I could modify the JPGs I have slightly and see if Bit | >| Defender and Symantec quit alerting on them. | >_____ | > | >Try an image editor and change the overall 'brightness by 1%. That should | >destroy any executable hidden in a .jpg image. | | Now, there's some thinking outside the box! Let's say that such a | minor and unobjectionable modification to color, brightness, contrast, | etc., is a sure-fire way to destroy the code. Call your invention a | "malware scrubber for JPGs" and peddle it :) Or maybe av products | could incorportate a scrubber feature whereby with user permission | all JPGs on all drives are found and scrubbed. Anyone with legit | JPG steganogrphy files could keep them on removeable media for | safety from the scrubbing operation. | | Art :) | http://home.epix.net/~artnpeg | |
From: B. R. 'BeAr' Ederson on 25 Jun 2006 03:33 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!)===
From: James Egan on 25 Jun 2006 05:38
On Sun, 25 Jun 2006 00:37:15 GMT, Art <null(a)zilch.com> wrote: >Do av really have to determine that a "diddled with" JPG contains >encrypted "information" and be able to deal with decrypting it? I suppose not. It would certainly help to clean up the steganography market and "out" the plethora of crapware which claims to be undetectable but is just a con. Jim. |