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: B. R. 'BeAr' Ederson on 16 Jul 2006 19:10 On Sun, 16 Jul 2006 17:36:57 -0400, edgewalker wrote: > I can see only rare instances where the companion executable wouldn't be able to > just carry any 'other' malicious code within itself rather than to store that code in > some companion data filetype. Any pictures off websites you visit automatically get stored inside temp internet folders. Most people don't do automatic deletion of all temp files on browser shutdown. So it is easy to embed code into innocent looking pictures (be that steganographic or just by appending the code) and spread that. (Just post interesting information on your website and announce the news.) Soon afterwards you can safely assume that a whole bunch of computers has your code on disk. Now submit a trojan, which only needs very small and simple additional functionality. No real bad looking code. Just locate and load a picture into memory and a seemingly erroneous buffer overflow to unsuspiciously run the code. If that trojan will be detected by AV, submit the next. It only needs very small (nearly undetectable by heuristics) code. The real malicious part is still there and waits for reactivation. And bear in mind, that pictures can be spread by other means, too. Near Christmas a funny Santa Claus picture will soon get onto half of the western private and business PC because of a snowball-system spreading. > Couple that with the fact that "any" filetype can contain data that will > later represent malicious code when read by a companion executable > programmed for that purpose. Known entry gates for malware have to be closed. The frogs currently on the net use very simple techniques. Real steganography will be much harder to detect. But it is, too, much harder to implement. You can't rely on existing "unpack" code on the target machine. So the igniter program has to be bigger. (I.e.: Needs a larger component of activation code.) Which - by the law of diminishing returns - gets ineffective before long. > What about an batch that changes your very own batch files to malware > by changing paths from your cleanup.bat (deletes temp files) to delete files > in directories you wanted preserved? Gee, now you'll have to detect your > very own batch files as malicious because of some future malware that may > use some code from them to do bad things. Malicious batch files have been detected in past. Especially [Prompt] reformatting (to execute code) and certain [Doskey] redefinitions caused the AV programs to issue a warning. As batch files seem not a common way of infection, any more, some previously reported batches in my test directory pass through the AV scanning now. I can't say that I'm too happy about that... BeAr -- =========================================================================== = What do you mean with: "Perfection is always an illusion"? = ===============================================================--(Oops!)===
From: Art on 17 Jul 2006 08:41 On Sun, 16 Jul 2006 17:48:03 GMT, Christopher P. Winter <chrisw20(a)chrisw20.best.vwh.net> wrote: >>>Aside from just a mental exercise, and in the process learning more about >>>the jpeg specs - I think you're wasting time. Any data filetype can contain >>>data destined to be used as code by a nefarious trojan. >> >>That why container scanning is important. In practicing safe hex, I >>don't rely on some single realtime av. That's far too risky, and in >>this particular case it's exceptionally risky for reasons I've pointed >>out. I want my scanners to detect malicious code during on-demand >>scans of various containers, and in compressed and packed files. >> > >I'm an infrequent visitor here. Let me see if I understand your concern. >You're saying that the malicious code could "lie doggo" in JPEG image files >on someone's machine until an apparently innocuous .exe was inadvertently >downloaded and executed? (By "apparently innocuous" I mean one that >anti-malware programs don't detect.) Thar's one concern. >It may be that the action of automatically opening the JPEG is something that >can be consistently detected and blocked, in which case malicious code in >JPEGs (or any other data files) might become moot. By "opening the JPEG" I presume you mean a heuristic that triggers on suspicious companion activity .... extracting, decripting and attempting to execute the embedded code. I've thought of that and I've wondered if that approach is perhaps a technique that some av vendors might be considering or implementing. Are there any legit apps that do extract, decrypt and attempt to execute code in a different file? I dunno. Even if there are, it wouldn't be a crime if a av alerted that "suspicious activity" is detected, providing the heuristic is a user option. But insofar as av recognizing the particular malware extracted from the JPGs when a companion runs the code, don't bet on it. As I've already mentioned in this thread, I've run tests after extracting and decrypting down to a EXE file, and the Virus Total results were pretty sad. So I have reason to not have any confidence in realtime av (generally speaking) identifying the embedded malware. >I say "might be" because of watermarks. Now, I don't know much about how >watermarks work, but I do know they are supposed to be immune to image >manipulation. If they can be, so can the malware code. Also, the action of a >legitimate watermark reader might be hard to distinguish from that of a >malware activator. > >Bottom line: I think your concern is valid, but I also think that coning up >with a real-world solution will be a very thorny problem. I'd like to know what approach the major av vendors are taking since they are still avoiding detection of the Trojanized JPGs, for the most part. It figures that they have a srategy of one kind or another palnned for or implemented in their realtime detection modules. But the fact that many fail to alert on the extracted embedded Trojans isn't encouraging to me. And the idea of relying _alone_ on detecting new companions as they are created, released and distributed doesn't strike me as a very intelligent or wise policy. I certainly hope that isn't the policy adopted by the major vendors. Art http://home.epix.net/~artnpeg
From: edgewalker on 17 Jul 2006 14:57 "B. R. 'BeAr' Ederson" <br.ederson(a)expires-2006-07-31.arcornews.de> wrote in message news:1e1uu5sb8ls22.dlg(a)br.ederson.news.arcor.de... > On Sun, 16 Jul 2006 17:36:57 -0400, edgewalker wrote: > > > I can see only rare instances where the companion executable wouldn't be able to > > just carry any 'other' malicious code within itself rather than to store that code in > > some companion data filetype. > > Any pictures off websites you visit automatically get stored inside temp > internet folders. So do cookies and any number of other types of data files. The companion data (to be used as code) could be anywhere on the net once you have the malware executable running. For those without application control for internet access, this is like trying to combat all possible malware data stores by enumerating the whole internet address space looking for malicious code instead of just trying to detect the downloader.small's as they appear. > Most people don't do automatic deletion of all temp > files on browser shutdown. So it is easy to embed code into innocent > looking pictures (be that steganographic or just by appending the code) > and spread that. My batfile example shows that the code to be used maliciously could already exist on the machine, negating any reason to look for anything except the malware that does the retrieving of, or manipulation of, addititional data stores such as data type files with embedded malicious code. > (Just post interesting information on your website and > announce the news.) Soon afterwards you can safely assume that a whole > bunch of computers has your code on disk. Indeed, just a compromised adserver will help you distribute widely. The point is that once you require a malware executable be already running to make the code embedded as data in jpegs translate into runnable code - all bets are off. You want to detect the malware executable, and not any and all data stores that may contain data to be translated into code by said executable. > Now submit a trojan, which only needs very small and simple additional > functionality. No real bad looking code. Just locate and load a picture > into memory and a seemingly erroneous buffer overflow to unsuspiciously > run the code. If that trojan will be detected by AV, submit the next. Such trojans are already out there. There is no reason they can't themselves carry the additional code you would have embedded in jpegs for distribution. You "still" have to distribute the new trojan to make those jpegs useful. ....so ... detect the trojans as they appear. It's not so very different than small downloader trojans except that application control policies can thwart them. > It only needs very small (nearly undetectable by heuristics) code. The > real malicious part is still there and waits for reactivation. The "real" malicious part "is" the small translator that makes the embedded code executable. > And bear in mind, that pictures can be spread by other means, too. Near > Christmas a funny Santa Claus picture will soon get onto half of the > western private and business PC because of a snowball-system spreading. > > > Couple that with the fact that "any" filetype can contain data that will > > later represent malicious code when read by a companion executable > > programmed for that purpose. > > Known entry gates for malware have to be closed. Right, and the only time data is malware is when it leverages a vulnerability in software to make it itself executable. Otherwise, only executables can be considered malware. Don't execute malware, and you needen't worry about jpegs having hidden code in them. > The frogs currently > on the net use very simple techniques. Real steganography will be > much harder to detect. Doesn't matter as it need not be looked for. It could just as easily be an encrypted text file with alphanumeric code placed as a cookie. The malware is that which makes the translation to runnable code and runs it. > But it is, too, much harder to implement. You > can't rely on existing "unpack" code on the target machine. So the > igniter program has to be bigger. (I.e.: Needs a larger component of > activation code.) Which - by the law of diminishing returns - gets > ineffective before long. Now you touch on one of the rare instances I alluded to. The size restrictions forced upon some buffer overrun attacks may make the placement of jpeg embedded code a worthy part of an attack scenario. The exploit gets your foot in the door and then you can use preplaced embedded code to do the payload portion of the attack. But then again - it is best to address the vulnerability itself than it is to attempt to detect embedded and possibly encrypted code inside data filetypes. > > What about an batch that changes your very own batch files to malware > > by changing paths from your cleanup.bat (deletes temp files) to delete files > > in directories you wanted preserved? Gee, now you'll have to detect your > > very own batch files as malicious because of some future malware that may > > use some code from them to do bad things. > > Malicious batch files have been detected in past. Especially [Prompt] > reformatting (to execute code) and certain [Doskey] redefinitions > caused the AV programs to issue a warning. As batch files seem not a > common way of infection, any more, some previously reported batches > in my test directory pass through the AV scanning now. I can't say > that I'm too happy about that... My point was that code already on the machine can be used maliciously if you have a prerequisite of having malware already running as this scenario suggests you must.
From: B. R. 'BeAr' Ederson on 17 Jul 2006 18:37 On Mon, 17 Jul 2006 14:57:03 -0400, edgewalker wrote: > it is best to address the vulnerability itself than it is to attempt to > detect embedded and possibly encrypted code inside data filetypes. The vulnerability in this case is the misusage of a container file format. The moment, additional data streams get used to propagate part of the malware, these ways are to be detected and closed. In case of *.jpg, AV vendors should warn of additional data streams when they have certain characteristics. (Seemingly executable code has no place inside *.jpg) The moment, cookies carry such code-data, heuristic warning *should* occur, too. It is a gatekeepers job. Any kind of passing data has to be examined whether it is part of a fishy project going on. Maybe, it is too much vor AV companies to deal with. Then its a market for a new product, which scans file types for validity: - "This *.txt you downloaded is in fact a *.doc." - "Your *.doc files in dir XY contain (autostart) macros." - "Your *.pdf file Z carries internet access functions." - "These *.jpg files have additional data streams with code characteristics." - "You have a cookie with embedded executable code." - ... [Malicious batch files] > My point was that code already on the machine can be used maliciously if you > have a prerequisite of having malware already running as this scenario suggests > you must. I wrote that in this very thread just a few days ago. But I don't get to the conclusion that I don't care about momentarily not used depots of entirely malicious code. BeAr -- =========================================================================== = What do you mean with: "Perfection is always an illusion"? = ===============================================================--(Oops!)===
From: GEO on 17 Jul 2006 19:52
On Mon, 17 Jul 2006 14:57:03 -0400, "edgewalker" <null(a)null.invalid> wrote: >You want to detect the malware executable, and not any and all data stores that >may contain data to be translated into code by said executable. The latest version of Bagle had a companion DLL that was made up of letters. For all I know it might be information that was used by the executable. >Such trojans are already out there. There is no reason they can't themselves >carry the additional code you would have embedded in jpegs for distribution. >You "still" have to distribute the new trojan to make those jpegs useful. Some worms have been very small. Do you recall which one was the smallest? >The "real" malicious part "is" the small translator that makes the embedded >code executable. >...Otherwise, only executables can be considered malware. >Don't execute malware, and you needen't worry >about jpegs having hidden code in them. >....The size restrictions >forced upon some buffer overrun attacks may make the placement of jpeg >embedded code a worthy part of an attack scenario. What other formats could hide this extra code? Should the AV examine every file for extra code? Geo |