Frankenstein Code Stitches Code Bodies Together To Hide Malware 111
mikejuk writes "A recent research technique manages to hide malware by stitching together bits of program that are already installed in the system to create the functionality required. Although the Frankenstein system is only a proof of concept, and the code created just did some simple tasks, sorting and XORing, without having the ability to replicate, computer scientists from University of Texas, Dallas, have proved that the method is viable. What it does is to scan the machine's disk for fragments of code, gadgets, that do simple standard tasks. Each task can have multiple gadgets that can be used to implement it and each gadget does a lot of irrelevant things as well as the main task. The code that you get when you stitch a collection of gadgets together is never the same and this makes it difficult to detect the malware using a signature. Compared to the existing techniques of hiding malware the Frankenstein approach has lots of advantages — the question is, is it already in use?" Except for the malware part, this has a certain familiar ring.
Fun but not interesting (Score:5, Informative)
The concept of malware using existing code, libraries even...let's see what's on every system in existance:
1. zlib
2. libpng
3. c runtime (albeit different forms)
4. BSD-compatible TCP/IP stack
Yup all the right elements needed to create malware, better go remove all those stat!
All joking aside, The Unix programming model is more or less the "right" way to program things except in two cases:
- Threading, which the unix model does horrible horribly. Many applications still are designed like there is only one CPU in the system, and the worst offenders (eg google chrome) try to solve it by wasting more memory on a broken sandbox model. It doesn't help when the parent process is the one locking up.
- Library dependency hell. Linux specifically has a "NOT INVENTED HERE" problem, where everyone violates the Rule of Diversity. Perl is the worst victim of this in action. Various C libraries also fall into this problem. What happens is that over time, shared libraries change their API, or start requiring yet-more dependancies. The end result is that binary programs on Linux are poorly cobbled-together, and highly dependant on upstream developers to get their ass in gear to fix bugs. As opposed to the FreeBSD/gentoo model where compiling everything solves the library hell and replaces it instead with versioning hell. What I mean is that if you don't constantly update everything every time a new point release is made, eventually the ports library will remove the port (eg php5,52,53,54) and break everything.
In some cases some really stupid crap is a dependency and takes forever (why must all graphics-related ports want to compile the complete X11 system for example)
The Windows model is somewhat better, albeit has it's own problems. Most windows applications, even when they have shared libraries, distribute the shared libraries they use and keep them in their own directories. If you remove these, the system library is then used. It's also possible to just replace a library. However some applications are really bad... and I mean broken-by-design if you use any shared libraries at all...
The current way many MMO games prevent hacking, is by monitoring for injected processes or regular processes on a blacklist. However the more creative hacks actually patch the C runtime itself and patch-over the anti-hacking code. It was kinda fun watching this progress with one specific game, as months would go by and the hackers would have their way with the MMO, and then suddenly the anti-hacking software would come back to life and they'd all panic and stop playing for a few hours as they try to figure out what changed. But the way they do it is by using a benign shared library (zlib or jpeg for example) that is loaded before the anti-hacking library, having all imports passed-thru it to the real library renamed to something else. The payload of the dll file however is when it's loaded.
So it's entirely possible for antivirus software to be neutered by the same process. Antivirus software should be staticly compiled and not relying on any shared files, not even the c-runtime.
In the wild ... (Score:2, Informative)
From TFA:
Although the Frankenstein system is only a proof of concept, and the code created just did some simple tasks, sorting and XORing, without having the ability to replicate, computer scientists from University of Texas, Dallas, have certainly proved that the method is viable.
And who knows, it might even be out there in the wild. After all, one of the main advantages of the method is that it hides malware more effectively.
While I have to profess that I do not know of any existing Frankenstein-code in operation, I can't discount the possibility that, buried in thousands and thousands closed-source software fragments there are things that we have absolutely no idea what they are
Even in a totally open source environment, hiding code fragments isn't that hard to accomplish either
And who knows? Maybe TPTB already got the Frankenstein codes installed in all our machines