Discussion on:

Is the death knell sounding for traditional antivirus?

to teach users to pay attention when they are loading software and stop blindly clicking OK.

And further justification for privilege separation, sandboxing, virtual machines, and, in general, every other security method known to man.

.

I don't understand how it encrypts itself, it has to run to encrypt itself, so can't antivirus programs just get the signature of the first program?


Perhaps the next step is for antivirus programs to automatically sandbox all programs that aren't whitelisted so that if one does become a virus, the antivirus can just delete the sandbox.

then they can encrypt it server-side. Ever go to one of those "How unique is your machine" sites? How much of the info do you need to feed it? How many times did you need to click OK to make your computer allow the site to gather the info?

If I understand correctly, the code does not encrypt itself, it encrypts the malware payload. As to the details of how it executes, I suspect that depends on the vulnerability the malware loader is trying to exploit.

I'll pass your questions along to the researchers. Hopefully they will have the time to answer.

On the same Make & Model system that's an Off the Shelf bog standard Home system?

Even the best Random Number Generators are not really all that Random so with the bulk of the Consumer Systems bought as an Appliance from the different OEM Vendors the Key is very likely to be repeated quite often.

Might be different in a Work Environment with Static Addressing or something along those lines but with the multitude of Domestic units being connected to Domestic Internet from a limited number of ISP's there is going to be a lot of very similar Encryption Keys used by this type of attack.

What I mean is lots of Computer Model whatever connected to the same Modem supplied by their ISP as most ISP's only have 1 or 2 Modem Types there would be a lot of duplication of data when the system searches for the associated Hardware wouldn't there?

I'm just wondering how it gets Encrypted in the first place though wouldn't that process be what any AV company would be blocking? Not the Payload but the process.

Col

If I understand correctly, several factors are used to determine the key. I would think that would complicate the matter and more than likely make each key unique. I might suggest reading the paper by Daryl I mentioned in the article about how Flashback gets installed. It goes into intricate detail:

http://security.utexas.edu/consensus/20120424_FlashbackObfuscation.pdf

I read that lot on the screen and an observation or two before I print it out and reread.

The weak point of this Problem Child is it needs to be installed or at least accepted as needed by the user. That is it's weakness because once it's on the system in it's encrypted state it's going to be very difficult to find let alone actually catch and kill. It also leaves next to no traces of itself on the system in any manner that is easy to track.

It's Strength is that it needs to be installed by the user most of which are click happy and will do anything asked of them when they see something wants to be installed, they just figure that they need to give the installer Added Privileges so they enter their Root Password and then they infect their own systems. Very Clever.

After posting above I thought about the uniqueness of the Encryption Key and I suppose if the CPU's Serial Number was part of the Hardware Looked at that would truly generate a Unique Key that would be next to impossible to find let alone crack. Though personally I would be setting any AV product to stop any Encryption to begin with and hence ask for user input before anything could be decrypted/encrypted though to be perfectly honest with most users that would only add an extra layer where Privilege Escalation would be required and most likely most would just click away to their hearts content.

The problem here isn't so much finding the Malware but stopping Users from clicking away to their hearts content to begin with and the Social Engineering involved here to get this installed is really the weakest point in every system. Apples BSD is fairly secure and this is what is being played on here the users thinking that they are safe so that they continue to click away thinking anything that they do can not hurt the OS and the writers are playing on that False Sense of Security.

Now I'll have to go and have a long think on this one after printing it out and highlighting what I want to better understand, but it's most defiantly not something that I like very much. Though I may of completely misunderstood the article and be completely wrong.

Col

You are usually spot on. I have heard about malware that is able to change the UAC and or install without needing user permission. I know no further about it though. Will check into it.

So that's a good thing.

I can't imagine how bad it would be without UAC.

Even a measly 90% uniqueness will cut the AV companies signature collection rate to 10% for each "instance", making them slower to update, and will make each signature only one tenth as effective as now... meaning that signature files would need to grow to ten times the size if all the bad stuff used that. Economics can break the back of the AV solutions, even if each single instance is still "breakable".

I also understand that this technique eliminates automated analysis. That in of itself will increase costs significantly.

I'm not sure how you could trap "encryption" with a virus scanner or any other software. It's not a special system call or a built in cpu instruction that can be identified. There are a vast array of possible encryption algorithms and an infinite number of ways of coding each one. I suspect this would be as hard as finding virus code the usual way.

can one detect if a website or app is gathering this information?

There is an id number on every cpu that is unique and unchangeable making it a perfect key.

Is that ID readily accessible to queries from any source?

What about having antivirus software to target the loaders themselves? Maybe hooking into decryption functions to intercept the decrypted malware before it executes?

Also an execve (or similar call) after some decryption call occurred should be closely monitored and detectable as suspicious, shouldn't it?

My five cents.
Alan

I'm no expert but what you say makes sense to me. My suggestion is to see what you can find in the paper written by Daryl I mentioned in the article about how Flashback gets installed:

http://security.utexas.edu/consensus/20120424_FlashbackObfuscation.pdf

Would one hook into decryption functions when they are not OS components or any other identifiable object?

How many encrypted files does a system normally have? Could you just scan for encrypted files and then you would have a list of files to analyze. You could even quarantine them and make a decision later. This should at least help control the use of them in an attack. Ultimately it seems we need the OS core to be either invulernable or replaceable, so that attacks to it can be stopped or a simply reboot press F4 reinstalls the core from a read only device. Basically sandboxing the core, so it can come up clean and allow tools to clean any applications or data. Do we need a hypervisor that runs multiple componets one focused just on security for example?

I'm rereading the Flashback paper to see how it accomplishes the install.

The other concern I was trying to address is that no matter what we come up with the nefarious types are able to circumvent or are already onto something bigger and badder.

The real Host UUID should always be hidden on the Internet and should remain closed and secret within that host, accessible only to the OS kernel and not to application programs (so that downloaded malwares won't have access to it to generate the decryption key).

But this host UUID can be leaked easily, by the OS itself, or using another software which has previously collected that local UUID and transmitted it to a third party (on my opinion, it should only be transmissible by the OS itself, not even by one of its hardware drivers, unless the driver is provided by the OS itself and signed by its manufacturer ; this is hard to ensure : lots of things will allow the user to know that UUID, and the user could be requested to provide this UUID, only to provide a security identity to a licence provider).

We could think about something else : using the global UUID provided by the network provider: this UUID should be inaccessible from the local host. But here again, the host may use a third party online service to have the global network UUID returned by its online query.

So what is the problem ? It is the host UUID. It should not have a long lifetime. It should expire very soon and should be renewed, discarding the old one completely. The remote malware that would have collected that UUID would only collect an expired UUID that souls no longer be usable to generate an encryption key that the malware running on the attacked host would be able to use.

Let's ban the permanent UUIDs from out computers : this includes the hardware MAC address of hardware network interfaces, which should be replaced by a software MAC address; it also includes the UUID stored in processors : accessible only by the BIOS, but NOT when the OS is running : the OS should generate its own local UUIDs with a short lifetime.

But now comes the challenge : permanent UUIDs are used to validate licences of media contents. What would happen if there was no permanent way to revalidate that licence ?

Let's say that the host is now storing a licence owned by a online user account : nothing limits the user from using the same licence on multiple host installations, unless there are some checks made online to make sure that multiple hosts are reusing the same licence, when they attempt to revalidate them in alternating times. But online licence validation has a severe impact on content usability: those revalidation cannot occur too often, not more than once each month. This would mean that the local host UUID associated to that licence would have to be kept valid for one month : much enough time for allowing a malware to transmiit that UUID to some location online, then waiting for a new malware being downloaded encypted with that UUID.

What is the best solution ? Simply drop completely the local host UUID as a secure identification mechanism for validating every software/media licences. Licences per hosts are the problem. What users want is licences per user. Licences that are valid and can be reused when the user changes or repairs his device.

Let's ban the permanent UUIDs from all hardwares/softwares/medias and licencing mechanisms.

Makes me want to run from a live CD only, never update, never install.

Maybe even make my own ISO, and use that.

I used Slax on a mini CD with a USB stick for data, settings and extra apps. Any computer could be my totally customized system (eg with email client set up) in a matter of a couple of minutes. All unique settings are stored in a single file at shut down, easy to confirm nothing untoward has happened to it.

Forgive me if this is way off base but is the key the malware generates based on unique IDs of components on the motherboard? (an on buses thereupon?) Sorry, been bat-s#!t busy and can't dig into your links atm...

If that's the case, then maybe the fix is to make something simple like a south bridge chip easily replaceable. Remember the 'peel-n-eat' BIOS chips of yore? Maybe even have a programmable/replaceable component that is part of the overall UUID of the system readily available to the admin.

Of course this would only make sense with high end, high availability servers. Rather than have to reinstall NOW, just change the hash so the malware can't decode. You could take care of the software problem at your leisure.

Some day we will have some sort of device that contains our personal systems, that can make any hardware available "your personal computer," your phone, whatever. It's be platform agnostic, and easily rolled back if something goes awry. I'll go so far as to announce my trademark of such a system: "me." (and contextual derivatives such "mine," "my" etc)

Meaning, I believe it's up to the developer or malware cryptor developer as to what is used for key stock.

Wouldn't that be something, the computer hiding from the software it runs.
Sadly, that might be only a temporary reprieve.

Would it be possible to make heuristics look for "asks too many questions"? Computing Noir.

Not good for the work environment.

Tme to run obscure hardware for connectivity at home, and isolate the productivity PC from it. sick.

I wasn't able to get a good idea as to how complicated this process is. If it's simple, then it's going to get popular real quick.

I'm surprised the black hackers didn't think of this before. It's conceptually easy idea. I wonder how much is going on they they havn't detected yet.

All my sources say the nefarious types are way ahead.

To infect XP was almost effortless by comparison. The hackers may have already had the means, but it may not have been needed at the time.

Even Win7 can be easily hacked, just think about the backdoor that is used by applications like Symantec to "push" themselves onto workstations. I tested this once on a machine that was not part of the domain, had the firewall on and was logged in as a limited user, Symantec still managed to install itself over the network, that's clearly exploiting a vulnerably that has been deliberately added by Microsoft. Belarc is another one that can install itself.

Just think, all of the places Windows can be adjusted to add a new startup application. Pretty much all viruses need to add themselves to one of these places, otherwise the infection would stop when you restart your computer.

I was curious if the computers were on an AD network? If so then Symantec had admin rights which override local rights. If not, then Symantec has something sneaky going on.

Belarc managed to install as well, though Spybots Teatimer threw a fit.

if BLADE ever escapes the test lab. http://www.blade-defender.org/

However, I'm getting noncommittal replies from Dr. Wenke Lee of Georgia Tech, and the U.S. Army Research Office. Despite direct contact from me, and a forward from Dr. Lee to Phil Porras at SRI, I have yet to hear from him, or the Office of Naval Research.

I'm much more interested in what Phil Porras and SRI have to say, particularly because Dr. Lee has indicated that "I will let Phil address you since SRI owns the IP."

I've been anxiously awaiting word of progress toward a release, ever since February 2010 and I notice that someone named Michael wrote on this topic here at TR in October of that year.

- Imagine telling your children or grandchildren some day, about the Internet, a massive network that could potentially make all knowledge instantly available to everybody ... and then having to tell them that criminals destroyed it for a few measly bucks.

Sounds like the start of a religion, doesn't it? Which sort of adds insult to injury.

After reading this... My next computer will be and Etch-a-sketch.

I loved mine. So did my parents, as it kept me occupied for hours.