Virtualization/Rollback software test

[Buster_BSA]

Hi.

I would like to make a test of virtualization/rollback software but first I´ld have a list of software to test.

My initial list is this:

Deep Freeze 7.00.020.3172 - SafeSys = Fails to restore the system | TDSS = Fails to restore the system

Shadow Defender 1.1.0.325 - SafeSys = Passes the test | TDSS = Passes the test

Returnil 2010 3.1.8774.5254-REL - SafeSys = Fails to restore the system | TDSS = Fails to restore the system

Wondershare Time Freeze 1.0.0 & 2.0.0 - SafeSys = Fails to restore the system | TDSS = Fails to restore the system

Windows SteadyState 2.5 - SafeSys = Fails to restore the system | TDSS = Fails to restore the system

Comodo Time Machine 2.6.138262.166 - SafeSys = Fails to restore the system | TDSS = Fails to restore the system

Eax-Fix / Rollback Rx 9.1 build 2695223310 - SafeSys = Fails to restore the system | TDSS = Fails to restore the system

HDGuard 8 - SafeSys = Fails to restore the system | TDSS = Fails to restore the system

Drive Vaccine PC Restore Plus 9.0 - SafeSys = Fails to restore the system | TDSS = Fails to restore the system

PowerShadow 2.6 - SafeSys = Fails to restore the system | TDSS = Fails to restore the system

Custodius 5.61 - SafeSys = Fails to restore the system | TDSS = Fails to restore the system

SnapShot 7.03.1 - SafeSys = Fails to restore the system | TDSS will not be active after rebooting


Any other name that should be included?

The test will be performed against SafeSys and TDSS malwares on a Windows XP SP3 running with admin rights under VirtualPC.

SafeSys is known as "Trojan-Downloader.Win32.Agent.bjlw" by Kaspersky.

Sample details are:

CRC32 = cc9c1408
MD5 = 2f32ed489a0d73e7587b4c8777a45bce
SHA-1 = ae1df59775479394f9edd967fef1db2094098fb1
SHA-256 = 8ae30b001ed9d55cd098505ee8049c5fa64d632e68ed236504bc0972c3e0bbd2

TDSS is not detected by Kaspersky. F-Secure detects the sample as "Trojan.Generic.KD.18037".

Sample details are:

CRC32 = 3ad2f342
MD5 = 55a16db3018a69a7d27f0deaf632273f
SHA-1 = 1b1b5af63cb048fcf47bdce96ccfea1301034137
SHA-256 = e362d030645e0db0719bde1895a5c4c7df48eca8f0127e43b8ac5f02b6ea806e

[cruchot]

Hi Buster, thanks for your time!

You already included the one I'm most interested in, Returnil (RVS 2010).

[CloneRanger]

@Buster_BSA

This should be Very interesting Can't wait

Thanks

[Rmus]

Sounds like a good test!

However, if the product has execution protection or something similar -- as I think Returnil does -- that should be disabled, since the malware should be allowed to execute and write to disk to see if the rollback product indeed does what it purports to do.

----
rich

[cruchot]

@Rmus: good note.

[Coldmoon]

Originally Posted by Rmus

Sounds like a good test!

However, if the product has execution protection or something similar -- as I think Returnil does -- that should be disabled, since the malware should be allowed to execute and write to disk to see if the rollback product indeed does what it purports to do.

----
rich

Hi Rich,
Yes, for an initial test of the ISR functionality. But it is also Important to follow up that test with a further test to see if the available features adequately address the problem.

There are a small number of malware families that can bypass ISR that can only be addressed by targeted features designed to defeat that type of malicious content and part of that is AE/AM functionality. So to test only one aspect of a layered security approach only serves to highlight a weakness of the specific component's technology and not whether the user would actually be protected when all components are brought to bare...

Mike

[Rmus]

Hi Mike,

I would like to follow up your excellent comments with these observations:

As we await these test results, it might be instructive for users to consider in the real world, how your rollback product fits into your security scheme.

Taking the TDSS/TDL3 rootkits: how are they used in exploits? How would a user encounter them? Like all malware, there two basic attack vectors: the drive-by exploit, and the social engineering one.

Let's take the drive-by exploit first.

White Paper:TDL3-Analysis.pdf
TDL3: The Rootkit of All Evil?

by:

Aleksandr Matrosov, senior virus researcher
Eugene Rodionov, rootkit analyst

The Pay‐Per‐Install scheme is widely used by maintainers of resources used to store pirated
content. For instance, web sites where users can watch popular video serials use this technique and
offer malware for download masquerading as antivirus program.

When you visit the web resource you are shown a banner that refuses to be closed. When you
click on it, you are redirected to a malicious web‐page that performs an attack by using an exploit,

If a user's only security is a rollback product like Deep Freeze, and the exploit finds a vulnerability on the system, she/he is in deep water indeed.

First, it's just too dangerous today not to have Default-Deny, white listing, aka execution protection, in place. Who would want to let malware intrude, even knowing it would later be removed on reboot? Meanwhile, before the reboot, the malware can do all sorts of things, depending on the user's operating system configuration. It's just silly to use such a product as one's sole security, notwithstanding the claims of Faronics about Deep Freeze.

Second, security-minded people who follow these things have known for 2-1/2 years that Deep Freeze was bypassed by the chinese robot dog. One was quick to assume that other reboot-to-restore products could likely be bypassed at some point -- just a matter of time. Returnil has solved that problem by including execution protection.

Now, the social engineering attack vector, which is the most common, evidently.

Tdss rootkit silently owns the net
http://www.prevx.com/blog/139/Tdss-r...s-the-net.html

The infection comes from the usual dropper spread by peer to peer networks or by crack and keygen websites, and it needs administrator privileges to run its payload. If UAC is disabled or the user voluntarily gives admin permissions, this infection can run even on Windows Vista and Windows 7.

This is likely to be the usual scenario, where a user looks for specific cracks and don't mind if UAC warnings him, he gives admin privileges to the wanted crack.

Again, from the above White Paper:

...you receive an alert claiming that your system is infected by a virus, and you are invited to
download antivirus software program.


If the dropper fails to adjust SE_LOAD_DRIVER_PRIVILEGE, it creates a manifest file with the
same name as the dropper, and in the same directory,

That implies the rootkit has detected non-Administrator privileges, and continues thus:

Then it runs another instance of the dropper by calling the ShellExecute API function, which
causes the Operating System (we are speaking about Windows Vista and Windows 7 operating systems)
to display a dialog box prompting a user to type the administrator password, as shown in Figure 11. If a
user types the password the dropper is re‐started but this time with administrative privileges including
SE_LOAD_DRIVER_PRIVILEGE.

At this point, a user with Deep Freeze, if having taken the bait, will thaw the partition and grant Administrator privileges and that is that. Similar with other products, if changes to disk are committed.

Another scenario is if a legitimate software is booby trapped. I've not heard of this recently, but as above, the user will grant Administrative privileges and the infection is complete.

So, while your tests will execute the malware to see how the rollback software performs, this isn't so relevant to the way things happen in the real world, since people don't let known malware execute!

In the case of the drive-by exploit, the average user won't know anything is wrong, since the sophisticated malware these days works so silently in the background. Depending on a rollback product only, even if it discarded the malware on reboot, is not much comfort if, pending the reboot, the malware has stolen data, passwords. As Mike wrote, another layer of protection is needed along side the rollback product.

In the case of a social engineering trick, the rollback software is taken out of the picture if the user unwittingly permits the installation of the malware and commits the changes to disk.

Just a few things to think about...

----
rich

[Buster_BSA]

Originally Posted by Rmus

Sounds like a good test!

However, if the product has execution protection or something similar -- as I think Returnil does -- that should be disabled, since the malware should be allowed to execute and write to disk to see if the rollback product indeed does what it purports to do.

Yes, I pretend to test products disabling everything except rollback functions.

As you say, malwares must be able to be executed in order to know if the product is able to restore the system to its previous state.

[Buster_BSA]

Originally Posted by Rmus

Second, security-minded people who follow these things have known for 2-1/2 years that Deep Freeze was bypassed by the chinese robot dog. One was quick to assume that other reboot-to-restore products could likely be bypassed at some point -- just a matter of time. Returnil has solved that problem by including execution protection.

Execution protection can not be an excuse for rollback software which fails protecting users from permanent changes on disk.

Let´s say a friend sends us an executable. We want to try the software he sends to us, so execution protection is useless because we will accept anything the software wants to install because:

1) We don´t know the software so we don´t know if it´s correct if it installs a driver or not, or whatever.

2) We trust the rollback software because it promises to restore the system after reboot

So blaming a rollback software user because he didn´t use a execution protection layer is pointless.

My point is that the rollback software alone must be able to restore the system whatever you run while the system is being protected. If you run something and the system is not restored then the rollback software is vulnerable and fails to pass the test.

[Rmus]

Originally Posted by Buster_BSA

Let´s say a friend sends us an executable. We want to try the software he sends to us, so execution protection is useless because we will accept anything the software wants to install because:

1) We don´t know the software so we don´t know if it´s correct if it installs a driver or not, or whatever.

I will concede that point, but I referred to the average user, who, in my view, would not be able to make a correct determination as to how the software should function.

Your scenario would violate my policy of checking other sources for the reliability of the executable you received. Again, I'm thinking of average home users I work with.

Nonetheless, I understand your point, which is,

My point is that the rollback software alone must be able to restore the system whatever you run while the system is being protected.

I just think it's dangerous to work under that assumption today.

----
rich

[Coldmoon]

Hi rich,

First, it's just too dangerous today not to have Default-Deny, white listing, aka execution protection, in place. Who would want to let malware intrude, even knowing it would later be removed on reboot? Meanwhile, before the reboot, the malware can do all sorts of things, depending on the user's operating system configuration. It's just silly to use such a product as one's sole security, notwithstanding the claims of Faronics about Deep Freeze.

Emphasis mine

I couldn't agree with you more and it is something I have tried to to emphasize throughout the history of RVS. While there is an inherent level of protection the user can realize by using an ISR-only approach, it is not bullet proof and further, the strategy provides NO feedback on its own efficacy. Also, and this is extremely important for all readers to understand is the fact that ISR alone will not detect, block, or even warn the user of malicious content!

If you do not see the truck coming down the road before you cross the street, you can't avoid getting hit...

As we await these test results, it might be instructive for users to consider in the real world, how your rollback product fits into your security scheme.

RVS is designed from a holistic approach where each component part is integrated and altered in a way that it will cover any weaknesses in the other components.

For example:

1. The virtualization works with the other components to ensure that undetected malware is lost at restart if the VG and AE fail to alert or block

2. The ISR serves as the removal technology for the Antimalware which results in seamless removal in the virtual system (malware detected? restart the computer).

3. The AE and AM work to ensure that ISR circumventing malware or potentially unwanted programs do not get a chance to bypass the ISR.

So the whole depends on the parts to make it a true security solution. The design itself came out of our frustration with the lack of results or long-term protection capabilities of existing approaches and the realization by many of us that traditional approaches were going nowhere except in a circle (infect -detect -clean -infect -Ad nauseam)

Taking the TDSS/TDL3 rootkits: how are they used in exploits? How would a user encounter them? Like all malware, there two basic attack vectors: the drive-by exploit, and the social engineering one.

It is impossible to deal with either one without some form of feedback in the strategy; especially the second one where the user is actively involved in infecting themselves. In a public access environment, the goal is simply do not allow the malware and don't bother me unless there is something that needs my attention.

Mike

[Coldmoon]

Let´s say a friend sends us an executable. We want to try the software he sends to us, so execution protection is useless because we will accept anything the software wants to install because:

1) We don´t know the software so we don´t know if it´s correct if it installs a driver or not, or whatever.

We are working on that one. The best advice is to ensure you can restore to a time before you installed that new game your friends sent you. The key is effective snapshots and/or imaging so you can roll it all back.

We plan to introduce our new multi-state restore engine in our 3.2 series so keep an eye out for it. Should anything get past the three component parts of RVS as it is now, then snapshot restore will get the user back to a clean system which is the real goal of any security strategy (or should be)...

Mike

[pandlouk]

I'm with Buster on this one. An ISR should restore successfully no matter what.

Having said that 99,99% of the users will manage to infect their system no matter the protection used.

Initially the frase I heard very often was: "I am protected. My x antivirus, catches everything".
Nowadays it sounds like: "I am protected. If my antivirus,my Hips and my Firewall miss something, I 'll simple reboot the system".
or:
"I have nothing important on the pc, what will they steal?"

And for MAC users:
"MACs do not have viruses". or "The others on the forum or blog said that it was virus free".



Panagiotis

[Rmus]

Originally Posted by Buster_BSA

2) We trust the rollback software because it promises to restore the system after reboot

There is another possible dangerous scenario in this "trusting" and it depends on how you define "system."

In the case of Deep Freeze, only the frozen partitions are protected. Home users will need at least one thawed partition to store data, so the "system" that is restored is usually just the system partition.

In my early years using Deep Freeze, I often let malware exploits run to see what they would do. One variant of the Sober worm installed 105 video files on each of my 4 thawed data partitions. That was easy to clean up, but I never again let malware run.

Now, file infectors that read across all partitions are common, so one can never be sure that unwanted stuff will remain on the other partitions following a reboot. The only sure solution here is a re-image of the entire HD.

That incident changed drastically my view of security and layers, as I mentioned in the other ongoing thread on Deep Freeze.

As Mike points out, without any feedback (which a rollback product by itself cannot provide), the user really has no way of knowing what has happened when an untrusted file executes.

----
rich

[huntnyc]

Mike,
Don't want to take this thread off a great topic but you have got me curious about snapshots with RVS - how will you address the interaction between retaining RVS snapshots when creating an image of the system - will it be possible to image and retain them and thanks.

Gary

[Serapis]

Thank you Buster for your willingness to test! If I may add to your list:

Clean Slate 6.5 from fortres grand

and if possible if not so much trouble;
Sandboxie x64

[Peter2150]

Originally Posted by huntnyc

Mike,
Don't want to take this thread off a great topic but you have got me curious about snapshots with RVS - how will you address the interaction between retaining RVS snapshots when creating an image of the system - will it be possible to image and retain them and thanks.

Gary

Lets take this question to another thread and not derail this one.

Pete

[huntnyc]

Sorry about that got a little excited and did open a new thread per Mike's and now your direction. Thanks.

Gary

[Peter2150]

Hi Buster

On thing to keep in mind is what the software was defined for, and also it's availablitly

For example several product were designed for protecting the mbr on the reboot. FDISR was never intended to provide that protection and it doesn't.

Also FDISR is no longer available.

Pete

[CloneRanger]

@Buster_BSA

Might be useful to test these with/out MBRguard

[Buster_BSA]

Originally Posted by Serapis

Thank you Buster for your willingness to test! If I may add to your list:

Clean Slate 6.5 from fortres grand

and if possible if not so much trouble;
Sandboxie x64

Clean Slate, Ok!

Sandboxie is not a rollback software. It will not restore the system after rebooting.

Anyway Sandboxie will pass the test because it will not allow the installation of any driver.

[Buster_BSA]

Originally Posted by Peter2150

Hi Buster

On thing to keep in mind is what the software was defined for, and also it's availablitly

For example several product were designed for protecting the mbr on the reboot. FDISR was never intended to provide that protection and it doesn't.

Also FDISR is no longer available.

Pete

I made the list on the fly, checking a web I found googling. Obviously the products no longer available will not be tested, but even if the product is discontinued (as it could be the case of Shadow Defender) if it´s available to download will be tested because maybe there are users still using last available version.

[Buster_BSA]

Originally Posted by CloneRanger

@Buster_BSA

Might be useful to test these with/out MBRguard

I will make the test using SafeSys and TDSSS samples. These malwares afaik don´t infect the MBR so MBRguard will not be needed for testing.

[dax123]

Thanks

you can compare your results with mine.
https://forums.comodo.com/news-annou...1638#msg411638

[Buster_BSA]

Originally Posted by dax123

Thanks

you can compare your results with mine.
https://forums.comodo.com/news-annou...1638#msg411638

Cool, thanks!

btw... you commented "maybe my sample is not powerful enough, comparing with another test" in reference to Shadow Defender and the not infection.

On my test Shadow Defender also was able to contain SafeSys infection, so your test is ok.