Slashdot Mirror
Frankenstein Code Stitches Code Bodies Together To Hide Malware
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.
One of these days you'll just write the malware, and it'll figure out the infection vectors.
This was done way back in windoze 95 days.
And it worked then too.
It amazes me that companies continue to operate when they do everything in there power to create insecure and unsafe environments for users. It's too bad there isn't worse dammage from malware. Maybe the risk of death or something similar would make people think twice.
With normal malware your antivirus would search for code that performs, say, XORing.
With Frankenstein Code malware, wouldn't your antivirus software simply search for the code that *searches* for XORing code?
And now you know why The Blight's archive, from A Fire Upon The Deep, who can effortlessly simulate a hundred trillion galactic-sized civilizations a second, was so far beyond any other conceivable bad guy. Brings new meaning to the statement in Contact, "That's the way it's been done for billions of years"...hacking out all conceivable methods of fail.
There's a theory that sufficiently clever people, or aliens, could construct a data stream to take over a receiving computer on any listening planet. Technologically this might not be possible without an embedded social engineering assist, but that's trivial manipulation, too.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
What knockers!
Oh... Thank you, doctor
“He’s not deformed, he’s just drunk!”
Except for the malware part, this has a certain familiar ring.
So when some asshole kludges together horrific scripts that are deliberately obfuscated to ensure years of billable hours, how is that not malware?
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.
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
Muchas Gracias, Señor Edward Snowden !
Seriously, I would expect the pieces of the Frankenstein code to be fairly readily identifiable and
Erectile Dysfunction? Need to please more than one woman. Have we got the pills for you - legal and over the counter just click here: getitup.com
highly unlikely that a well protected system like mine would EVER have to worry about it.
myke
Mimetics Inc. Twitter
Perhaps someone was pulling my leg at the time, but I remember back in the mid-nineties hearing about a project where dozens (soon to be hundreds) of self-modifying/evolving viruses were turned loose on a host machine to compete, with one of the most successful being a tiny bit of "parasite" code that had offloaded virtually all of it's functionality to other viruses in the ecosystem.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
There is a similar thing called "return oriented computing". I don't know to what extent is this used in practice, but this idea isn't completely new.
Quoting a portion of http://news.slashdot.org/story/01/01/25/1343218/directvs-secret-war-on-hackers
Posted by michael on Thursday January 25 2001
"...It was apparent that DirecTV had lost this battle, relegating DirecTV to hunting down Web sites that discussed
their product and using their legal team to sue and intimidate them into submission.
"Four months ago, however, DirecTV began sending several updates at a time, breaking their pattern. While the
hacking community was able to bypass these batches, they did not understand the reasoning behind them. Never before
had DirecTV sent 4 and 5 updates at a time, yet alone send these batches every week. Many postulated they were
simply trying to annoy the community into submission. The updates contained useless pieces of computer code that
were then required to be present on the card in order to receive the transmission. The hacking community
accommodated this in their software, applying these updates in their hacking software. Not until the final batch of
updates were sent through the stream did the hacking community understand DirecTV. Like a final piece of a puzzle
allowing the entire picture, the final updates made all the useless bits of computer code join into a dynamic
program, existing on the card itself. This dynamic program changed the entire way the older technology worked. In a
masterful, planned, and orchestrated manner, DirecTV had updated the old and ailing technology. The hacking
community responded, but cautiously, understanding that this new ability for DirecTV to apply more advanced logic
in the receiver was a dangerous new weapon. It was still possible to bypass the protections and receive the
programming, but DirecTV had not pulled the trigger of this new weapon.
"Last Sunday night, at 8:30 pm est, DirecTV fired their new gun. One week before the Super Bowl, DirecTV launched a
series of attacks against the hackers of their product. DirecTV sent programmatic code in the stream, using their
new dynamic code ally, that hunted down hacked smart cards and destroyed them. The IRC DirecTV channels overflowed
with thousands of people who had lost the ability to watch their stolen TV. The hacking community by and large lost
not only their ability to watch TV, but the cards themselves were likely permanently destroyed. Some estimate that
in one evening, 100,000 smart cards were destroyed, removing 98% of the hacking communities' ability to steal their
signal. To add a little pizzazz to the operation, DirecTV personally "signed" the anti-hacker attack. The first 8
computer bytes of all hacked cards were rewritten to read "GAME OVER"..."
end quote
This sounds like Return Oriented Programming, used in some exploits to thwart countermeasures. But it is a long way from stitching together code to do trivial things all the way to making code which replicates, has a payload, AND can stitch together code to do all Of this. The Halting Problem makes me wonder if it is even theoretically possible.
Sounds like Windows to me.
I mean code is code so the same tactics could be used to make an artificial virus evade the immune system right?
Would it work? Probably not.
Would it be plausible enough to write a sci/fI book or movie? Maybe.
"...gadgets, that do simple standard tasks..." Well, I don't want to bash the authors, but what they describe is exactly what a script would do on a Linux system. I suppose they come from a pure Windows environment, where a script is an unheard of, super guru thing...
Excuse me, but please get off my Pennisetum Clandestinum, eh!
You still need code for Dr. Frankenstein that creates this monster, right? Surely that can be detected?
As for the link to unix philosophy, I am sure that certain unities have malware, especially the ones I can't ever remember how to use, or what on earth the switches all mean, like find, or man.
In this example, they're saying that detecting the "body parts" would be too difficult because they'd be legit apps. And they're correct.
So the idea would be to look for the "Frankenstein" code which uses those "body parts". Because THAT is the malware code.
So I'm not seeing where the problem is.
Seriously... the ability to stitch together a thousand different versions of "the same" virus using pieces of code commonly available on every system would be overwhelming and devastating to a target.
No, you don't send the generator in the payload (unless you have it generate itself first), as it would be easily detected and reverse engineered. You send a thousand viruses at a set of targets and there will be no virus scanner able to handle 100% of them without dynamic analysis. With a zero day exploit and root kit implementation this is potentially devastating. With some careful engineering you could sometimes defeat dynamic analysis as well.
What makes current viruses largely ineffective is that you can only make a few effective ones in a limited time period. You need a large team of experienced developers to be able to build such a critter. Iterating new payloads takes lots of testing and QA. With this sort of tech you build one good virus blueprint and out comes thousands of different little beasties with a good probability of success. Each one is different!
This stuff is dangerous - atomic bomb dangerous if it gets a proper engineering.
I said no... but I missed and it came out yes.
This sounds like a progression from Viral coding techniques to Parasitical... even Reverse Transcriptase like.. infecting the normal operations of the organism to coopt their function and realign their purpose so they serve different ends.
Anti-Mallware may just have to become more sophisticated.. more like traffic cops and begin to "interpret" the letter of the law as "acceptable conduct" or behavior as opposed to a well defined misbehavior
NBAR deep packet inspection has similar problems at the transport layer.. how do you interpret apparently normal behavior as undesirable, without looking further into the content of the objectives of the data.. or its actions. There's plenty of room at the "bottom" as well as at the "top" in which ot hide, to paraphrase Richard Feynman.
is this an old story or have I seen it somewhere else?
There was an unknown error in the submission.
every piece of malware is going to make OS and library calls which constitute 'stiching together standard pieces of code'.
the code that does the stiching itself is going to have its own signature which can be searched for. DUH.
While I agree that there's a big threat, I don't see the sky falling yet. But I guess some AV companies that got complacent and retreated to creating automated pattern based signatures will have to invest in Analysis again (allow me to use this moment to greet a former employer of mine, guess you might soon regret axing the Analysis team in favor of that autosig tool, huh?).
It will likely be impossible to use standard pattern signatures anymore. Ok. Behaviour analysis will most likely be very difficult as well, since it doesn't "behave" the same way in every iteration of the virus, at least not fully. And that "not fully" is where I'd put the lever.
I haven't met a single piece of "morphing" malware, be it self modifying or, like in this case, created in different ways with each and every single infector that didn't have a flaw. There is always one where you can put your lever and pry it apart. I had my share of morphers on my desk back in the good ol' days of my time in analysis, and they eventually succumbed. Although what I can well see is that you might need a pretty large sample set of the malware to find the common link. This time, it will likely be very difficult to find a behaviour pattern that doesn't clash with the whitelist.
What I predict is less a flood of infections. I guess we'll see much more damage done by AV kits that kill critical system tasks they falsely identify as malware because their whitelist lacks the most recent update of said benign files.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
A lot of the time the users are the holes. You can use the most secure software in the world, but it's not going to do you a lot of good if Mr Smith in accounting decides that he simply must run that program from a dubious website that sends a cartoon cat to crawl around the screen to make his job less depressing.
There are much easier ways to defeat virus signature searches.
Consider the assembly code of a virus. Between every opcode, insert an explicit jump to the next instruction. This bloats the program to circa twice the size and half the speed.
Then, add a routine that randomize the order of instructions, but updating the jumps to keep the code doing the same as before. You might need two of this routine, so one can be running and rearrange the other. We don't want a constant signature on the rearranging part either.
Now you have a virus that mutates all over, with no signature - but it keeps working. And if people start looking for code with too much jumps, make blocks with jumps every sixth instruction or so instead. Still reorganizable, but no longer much more jumps than normal. You may also do equivalency transforms - i.e. make the code change itself to do the same but using different registers/memory for the job . . .
It may sound old-fashioned to reiterate, but this stuff is only dangerous for operating systems that don't properly separate privileges and don't properly isolate and contain processes/tasks.
cpghost at Cordula's Web.
Isn't this just one of the features of "return oriented programming," wherein the stack is manipulated to point to a set of addresses containing a sequence of instructions already in the binary (whether in executable code, or in data structures), that combined forms malicious code?
Carol vs. Ghost
This is not ordinary code where doing these small things is a relatively good indicator you can do larger things. The scanner itself cannot be done this way, was it needs to know what it is scanning for. While an interesting idea, this approach has nowhere near the power claimed.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
You miss one critical thing. Admittedly the story also glosses over this fundamental limitation: You cannot send any virus! You need the scanner/stitcher present on the target system and running as root in order to do its job. And it needs to be propagated along with any virus. Obviously that invalidates that whole thing.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
it's not about using the libraries. that is not the point. the point is to just take random code from a random file that happens to for example move data from register x to register y, and then use that code instead of simple register move command when recompiling the malwares code, that way the entire malware can be ran through the obfuscator, including the obfuscation code, so the entire malware is polymorphed(and bloated by ~50%). it's an obfuscation method. it's NOT about using system libraries since that would be ancient dos age stuff(bios is an os library).
and it's pretty hard for av to not have to access os filesystem routines, your blackbox av idea isn't exactly solid.
world was created 5 seconds before this post as it is.
Computer "viruses" as we know them are really more like computer "bacteria", whereas this concept is a bit more like a real virus.
Instead of all the unnecessary complexity of making Frankenstein code, why not just borrow an idea from the biological world? Write your malware/virus/whatever as an RNA strand that is transcribed into runnable code. Each base pair is translated, at random, to a small set of synonymous functional code. Finally, the transcoder itself (also coded in RNA) is included. The interesting bit then is, when it comes time to do a duplication, the code does reverse transcription back into RNA (a non-trivial but not impossible task) and re transcribes itself again. The real difficultly, of course, is then anti-virus/malware could simply do the reverse transcription themselves and do RNA matching. But given how trivial it would be to randomize the base -> code translation at each step... :/ The only other thing would be to try to signature match for all possible permutations of the transcoder/reverse transcoder.
Eurohacker European paranoia, gun rights, and h
You need the scanner/stitcher present on the target system and running as root in order to do its job. And it needs to be propagated along with any virus. Obviously that invalidates that whole thing.
Yes, the scanner/stitcher would be no different than a LZH compressor or any other pre-processor of code. It would be a quite suspicious looking piece of code that malware scanners could identify and block.
This stuff is dangerous - atomic bomb dangerous if it gets a proper engineering.
We can hope it is that dangerous. For it could wipe out windows, again showing how weak that platform is. And again, not a problem for those of us not vulnerable to viruses. The fast-mutating virus is not "more dangerous". It can defeat virus scanners, that's all. No problem if a scanner isn't needed in the first place.