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 08:19 On Sat, 24 Jun 2006 07:52:45 +0100, James Egan <jegan(a)jegan.com> wrote: >On Thu, 22 Jun 2006 22:51:00 GMT, Art <null(a)zilch.com> wrote: > >>I'm puzzled that only two products alert on the JPEGS >>even though many alert on the (apparently) >>companion malware. I would think it important to >>alert on the JPEGS as a warning to users to get rid >>of them. > >Seems like a lot of effort for very little gain to me. There are too >many proprietary steganography techniques to cover to make it a >worthwhile venture given that the likelihood of the hidden malware >ever being executed is close to zero. 1. "Too many" or "potentially endless" considerations haven't prevented vendors from doing a partial job at least of handling various runtime packers and file compression (archiving) methods when scanning on-demand. New packers are created specially to confuse av, yet vendors like Kaspersky have clearly attempted to keep up with them. Kaspersky and some others have also pursued extraction and "scanning within" installation and setup .EXE files even though that puts them in the position of having to keep up with new installers as time goes on. Now, if you want to argue that all of the above is unnecessary because realtime scanning will/should eventually catch the malware when run, that's a different matter and a different argument. But I see no difference between making on-demand scanning attempts at some of the JPG (and other) files in circulation and making attempts at other "containers". 2. Your statement that the probability of the malware being executed is zero is nonsense no matter how you look at it. Even without the presence of a current companion, a new and currently "unknown" companion could cnceivably get past av scanners and run the code embedded in the JPGs. The JPGs are a threat as long as they are on a PC. In fact, this sort of thing may well be a part of the plan of the bad guys. Now, it may be that realtime scanners will be smart enough to figure out which file contains the embedded code that a day zero companion runs, but I doubt it. So the damn JPGs could just sit there undetected forever, endlessly used by new and "unknown" companions. Some will argue that this boils down to nothing more or less than _any_ day zero problem and av only need be concerned with detecting companion malware which they view as the _real_ and _only_ culprits. I would argue as (1.) (above) and say that it's worthwhile IMO to make attempts at alerting on files containing embedded malicious code if it's feasible to do so, in as many cases as possible. And if JPG embedded code is completely ignored by analysts, that begs the question of whether or not realtime scanners will catch the "unknown" code when it _ is_ run by a companion. There's no way around analyzing the embedded code and providing at least realtime detection in all cases when it's feasible to do so in a scanner. That's why I'm so interested in hearing back from Kaspersky, though I'm not optimistic about receiving a "policy statement" from most of their analysts or even from Eugene :) I'm just hoping that I can "read between the lines" and deduce a current policy on detecting embedded malicous code in such files as I submitted. Based on their past history of not shying away from "container" challenges, it will be interesting to find out what they, in particular, plan to do. It's going on two days now, and I've not yet heard back. Art http://home.epix.net/~artnpeg
From: David H. Lipman on 24 Jun 2006 08:23 From: "Art" <null(a)zilch.com> | On Sat, 24 Jun 2006 07:52:45 +0100, James Egan <jegan(a)jegan.com> | wrote: >>On Thu, 22 Jun 2006 22:51:00 GMT, Art <null(a)zilch.com> wrote: >>>I'm puzzled that only two products alert on the JPEGS >>>even though many alert on the (apparently) >>>companion malware. I would think it important to >>>alert on the JPEGS as a warning to users to get rid >>>of them. >>Seems like a lot of effort for very little gain to me. There are too >>many proprietary steganography techniques to cover to make it a >>worthwhile venture given that the likelihood of the hidden malware >>ever being executed is close to zero. | 1. "Too many" or "potentially endless" considerations haven't | prevented vendors from doing a partial job at least of handling | various runtime packers and file compression (archiving) methods | when scanning on-demand. New packers are created | specially to confuse av, yet vendors like Kaspersky have clearly | attempted to keep up with them. Kaspersky and some others | have also pursued extraction and "scanning within" installation | and setup .EXE files even though that puts them in the position | of having to keep up with new installers as time goes on. | Now, if you want to argue that all of the above is unnecessary | because realtime scanning will/should eventually catch the | malware when run, that's a different matter and a different | argument. But I see no difference between making on-demand | scanning attempts at some of the JPG (and other) files in | circulation and making attempts at other "containers". | 2. Your statement that the probability of the malware being | executed is zero is nonsense no matter how you look at it. Even | without the presence of a current companion, a new and | currently "unknown" companion could cnceivably get past av | scanners and run the code embedded in the JPGs. The JPGs | are a threat as long as they are on a PC. In fact, this sort of | thing may well be a part of the plan of the bad guys. Now, | it may be that realtime scanners will be smart enough to figure out | which file contains the embedded code that a day zero companion | runs, but I doubt it. So the damn JPGs could just sit there | undetected forever, endlessly used by new and "unknown" | companions. Some will argue that this boils down to nothing | more or less than _any_ day zero problem and av only need | be concerned with detecting companion malware which they | view as the _real_ and _only_ culprits. I would argue as (1.) | (above) and say that it's worthwhile IMO to make attempts | at alerting on files containing embedded malicious code if it's | feasible to do so, in as many cases as possible. And if JPG | embedded code is completely ignored by analysts, that begs | the question of whether or not realtime scanners will catch | the "unknown" code when it _ is_ run by a companion. | There's no way around analyzing the embedded code and | providing at least realtime detection in all cases when it's | feasible to do so in a scanner. | That's why I'm so interested in hearing back from Kaspersky, | though I'm not optimistic about receiving a "policy statement" | from most of their analysts or even from Eugene :) I'm just | hoping that I can "read between the lines" and deduce a | current policy on detecting embedded malicous code in | such files as I submitted. Based on their past history of not | shying away from "container" challenges, it will be interesting | to find out what they, in particular, plan to do. It's going on | two days now, and I've not yet heard back. | Art | http://home.epix.net/~artnpeg I haven't heard back from Kaspersky as well and I submitted the samples before you did. -- Dave http://www.claymania.com/removal-trojan-adware.html http://www.ik-cs.com/got-a-virus.htm
From: James Egan on 24 Jun 2006 14:13 On Sat, 24 Jun 2006 12:19:06 GMT, Art <null(a)zilch.com> wrote: > >1. "Too many" or "potentially endless" considerations haven't >prevented vendors from doing a partial job at least of handling >various runtime packers and file compression (archiving) methods >when scanning on-demand. New packers are created >specially to confuse av, yet vendors like Kaspersky have clearly >attempted to keep up with them. Kaspersky and some others >have also pursued extraction and "scanning within" installation >and setup .EXE files even though that puts them in the position >of having to keep up with new installers as time goes on. That's not the same though. If (say) a least significant bit method is used to hide the malware, any detection would be dependent on the image containing the malware and not just the malware itself. So if someone got a (separate) infection which wrote a malware program to the least significant bits of all the jpg's (over a minimum size to suit the malware) on a particular machine then by the same reasoning, all the av vendors would have to add detection for all these images to their list since they are infected and already in the wild. There could be gazillions of detections needed for one piece of malware. >2. Your statement that the probability of the malware being >executed is zero is nonsense no matter how you look at it. Even >without the presence of a current companion, a new and >currently "unknown" companion could cnceivably get past av >scanners and run the code embedded in the JPGs. Then it's not the jpg which gets executed. It's the "unknown" companion which just slipped past your av scanner. That's what needs to be detected and stopped. <snip> >view as the _real_ and _only_ culprits. I would argue as (1.) >(above) and say that it's worthwhile IMO to make attempts >at alerting on files containing embedded malicious code if it's >feasible to do so, in as many cases as possible. And if JPG >embedded code is completely ignored by analysts, that begs >the question of whether or not realtime scanners will catch >the "unknown" code when it _ is_ run by a companion. >There's no way around analyzing the embedded code and >providing at least realtime detection in all cases when it's >feasible to do so in a scanner. > Unless a joke program like Data Stash that I mentioned earlier is used, then it's not going to be feasible. Jim.
From: Art on 24 Jun 2006 15:36 On Sat, 24 Jun 2006 19:13:20 +0100, James Egan <jegan(a)jegan.com> wrote: >On Sat, 24 Jun 2006 12:19:06 GMT, Art <null(a)zilch.com> wrote: > >> >>1. "Too many" or "potentially endless" considerations haven't >>prevented vendors from doing a partial job at least of handling >>various runtime packers and file compression (archiving) methods >>when scanning on-demand. New packers are created >>specially to confuse av, yet vendors like Kaspersky have clearly >>attempted to keep up with them. Kaspersky and some others >>have also pursued extraction and "scanning within" installation >>and setup .EXE files even though that puts them in the position >>of having to keep up with new installers as time goes on. > >That's not the same though. If (say) a least significant bit method is >used to hide the malware, 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. >any detection would be dependent on the >image containing the malware and not just the malware itself. Well, I suppose I could modify the JPGs I have slightly and see if Bit Defender and Symantec quit alerting on them. >>2. Your statement that the probability of the malware being >>executed is zero is nonsense no matter how you look at it. Even >>without the presence of a current companion, a new and >>currently "unknown" companion could cnceivably get past av >>scanners and run the code embedded in the JPGs. >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. >That's what needs >to be detected and stopped. I've already addresed and answered that. Sure the companions must be stopped and that's what the vendors are addressing. But day zero companions will/may run the code in the JPGs so the JPGs must be detected as well. ><snip> >>view as the _real_ and _only_ culprits. I would argue as (1.) >>(above) and say that it's worthwhile IMO to make attempts >>at alerting on files containing embedded malicious code if it's >>feasible to do so, in as many cases as possible. And if JPG >>embedded code is completely ignored by analysts, that begs >>the question of whether or not realtime scanners will catch >>the "unknown" code when it _ is_ run by a companion. >>There's no way around analyzing the embedded code and >>providing at least realtime detection in all cases when it's >>feasible to do so in a scanner. >> > >Unless a joke program like Data Stash that I mentioned earlier is >used, then it's not going to be feasible. If it's not feasible, how do you explain the detections by Bit Defender and Symantec? Art http://home.epix.net/~artnpeg
From: Art on 24 Jun 2006 18:36
Now Fortinet can be added to the short list of vendors alerting on the JPG files: NT1.JPG Possible Tjreat (05993) NT2.JPG Possibe Threat (05994) NT3.JPG Possible Threat (05995) Art http://home.epix.net/~artnpeg |