A Steganography sample malware - Page 7

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

Threaded View

Re: A Steganography sample malware


Quoted text here. Click to load it

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.)

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.

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.

Re: A Steganography sample malware



Quoted text here. Click to load it

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. 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. The companion executable could even
be the decryptor of encrypted data leaving you no way to detect the data
companion
as having malicious content.

I came to the conclusion that Art wants to detect this "on-demand" just for the
sake of completeness when scanning incoming data filetypes. That's okay with
me, but there are so many ways that malware writers can get around detectability
in data filetypes that I think it is not worthwhile.

Quoted text here. Click to load it

You hit that grey area like is it a remote administration tool or a remote access
trojan. The same exact program could be either, depending on circumstances.
Detection for some kinds of trojans are on a first come first served basis. Any
application that executes on your machine and gets data to be interpreted and
executed as code (like Java) cannot be judged as malware on that basis alone.
(maybe they should be though).

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.




Re: A Steganography sample malware

On Sun, 16 Jul 2006 17:36:57 -0400, edgewalker wrote:

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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!)===

Re: A Steganography sample malware


message
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

The "real" malicious part "is" the small translator that makes the embedded
code executable.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.



Re: A Steganography sample malware

On Mon, 17 Jul 2006 14:57:03 -0400, edgewalker wrote:

Quoted text here. Click to load it

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]
Quoted text here. Click to load it

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!)===

Re: A Steganography sample malware

wrote:

Quoted text here. Click to load it

  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.


Quoted text here. Click to load it

  Some worms have been very small. Do you recall which one was the
smallest?

Quoted text here. Click to load it





   What other formats could hide this extra code? Should the AV
examine every file for extra code?


  Geo


Re: A Steganography sample malware

On Mon, 17 Jul 2006 23:52:53 GMT, GEO wrote:

Quoted text here. Click to load it

Your question targets, whether no-code parts of malware should be
detected. I'd say that depends. If generic heuristic detection is
possible (data on positions, where usually no data should be and
the like - as is the case with the additional non-pictorial data
at the end of *.jpg): yes. If malware is widespread and special
detection is included, anyway: also yes. In all other cases: not
necessarily required.

Quoted text here. Click to load it

Not a worm, but a successful program for Core Wars has been "The dwarf",
a single <Move> command.

Quoted text here. Click to load it

At least in manually <Scan all> mode definitely yes. And embedded
complete executable files should be detected even when a simple
XOR and the like is applied.

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

Re: A Steganography sample malware

On Tue, 18 Jul 2006 19:57:04 +0200, "B. R. 'BeAr' Ederson"

Quoted text here. Click to load it

I very rarely post to say nothing other than "I agree" but in this
case I feel so strongly about the on-demand scanning issue that
it's _really_ nice to see someone post a opinion I agree with. It's
a good thing that I'm not in charge of a av scanner comparative
test agency since I'd be flunking products left and right for not
alerting on the froggies :)

Art

Re: A Steganography sample malware


Quoted text here. Click to load it

This is why AV gets so bloated with superflouos features. I'm sure e-mail
scanning (coming and going) was adopted because users actually wanted
AV to do this and would gravitate to those offerings that do and the ones
that don't will lose marketshare.

That doesn't make that feature any less useless.

Scan all files for simple (and not so simple) encryption techniques,with
and without steganographic embedding, on demand if you want to. But
don't you think people will complain about how long it takes to thoroughly
check all files this way?

Why not just look for the malware, and if found look for the data store it
attempts to fetch from. Why waste time with non-threats?



Re: A Steganography sample malware

wrote:

Quoted text here. Click to load it

Too risky, that's why. Day Zero malware. It's dumb to not detect known
and simple-to-detect froggies so users can get them off their
machines. You claim they aren't a risk but that's just plain false.
They're a risk as long as they're stored on drives.

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

Re: A Steganography sample malware


Quoted text here. Click to load it

Since dlls can be executable code, I would expect them to be scanned. I don't
however expect that code hidden in there will always be recognizeable. It is
trivial to have it encrypted (and thus non-executable without a helper program).

Quoted text here. Click to load it

I'm guessing Sapphire - a single packet connectionless (two way) worm.

Quoted text here. Click to load it

Too many too list here for sure.

Quoted text here. Click to load it

No, that's what I'm saying - they should concern themselves with the executable
malware
only and not with how or from where it fetches more code to execute. For
instance, you
want to detect a batch file that calls format.com while not detecting format.com
itself. The
malware itself, not the code it calls upon from elsewhere.

You start detecting code in data files, then they go steganographic. They devise
a way to
detect the code even if steganographic techniques are used, so the malware
writers will
encrypt it also. At that point the "code" will be virtually undetectable - only
there may be
some clues that point to the fact that steganography was used. There may be no
way at
all for them to determine that encrypted and steganographically embedded code is
not a
legitimate part of the host data itself if it is done right.



Re: A Steganography sample malware

On Mon, 17 Jul 2006 01:10:38 +0200, "B. R. 'BeAr' Ederson"

Quoted text here. Click to load it

  Entry gates? The internet? The programs? The operating system?

Quoted text here. Click to load it

  So did the viruses/worms that came in e-mails as sexy images. :)


  Geo


Re: A Steganography sample malware

On Mon, 17 Jul 2006 23:52:55 GMT, GEO wrote:

Quoted text here. Click to load it

Transmission (protocol based exchange), programs, container files,...
Close -> Check -> Allow valid/suppress all other.

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

Re: A Steganography sample malware

On Sun, 16 Jul 2006 17:48:03 GMT, Christopher P. Winter

Quoted text here. Click to load it

Thar's one concern.

Quoted text here. Click to load it

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.    

Quoted text here. Click to load it

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

Site Timeline