B. R. 'BeAr' Ederson said:
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.
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.
