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?