Virtualization/Rollback software test

Discussion in 'sandboxing & virtualization' started by Buster_BSA, Jul 1, 2010.

Thread Status:
Not open for further replies.
  1. Buster_BSA

    Buster_BSA Registered Member


    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 - SafeSys = Fails to restore the system | TDSS = Fails to restore the system

    Shadow Defender - 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
    Last edited: Jul 5, 2010
  2. cruchot

    cruchot Registered Member

    Hi Buster, thanks for your time!

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

    CloneRanger Registered Member


    This should be Very interesting :thumb: Can't wait ;)

    Thanks :)
  4. Rmus

    Rmus Exploit Analyst

    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.

  5. cruchot

    cruchot Registered Member

    @Rmus: good note.
  6. Coldmoon

    Coldmoon Returnil Moderator

    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...

  7. Rmus

    Rmus Exploit Analyst

    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?


    Aleksandr Matrosov, senior virus researcher
    Eugene Rodionov, rootkit analyst

    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

    Again, from the above White Paper:
    That implies the rootkit has detected non-Administrator privileges, and continues thus:

    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...

    Last edited: Jul 1, 2010
  8. Buster_BSA

    Buster_BSA Registered Member

    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.
  9. Buster_BSA

    Buster_BSA Registered Member

    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.
  10. Rmus

    Rmus Exploit Analyst

    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,

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

  11. Coldmoon

    Coldmoon Returnil Moderator

    Hi rich,
    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...

    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)

    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.

  12. Coldmoon

    Coldmoon Returnil Moderator

    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)...

  13. pandlouk

    pandlouk Registered Member

    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".
    "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".


  14. Rmus

    Rmus Exploit Analyst

    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.

  15. huntnyc

    huntnyc Registered Member

    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.

  16. Serapis

    Serapis Registered Member

    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
  17. Peter2150

    Peter2150 Global Moderator

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

  18. huntnyc

    huntnyc Registered Member

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

  19. Peter2150

    Peter2150 Global Moderator

    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.

  20. CloneRanger

    CloneRanger Registered Member


    Might be useful to test these with/out MBRguard ;)
  21. Buster_BSA

    Buster_BSA Registered Member

    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.
  22. Buster_BSA

    Buster_BSA Registered Member

    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.
  23. Buster_BSA

    Buster_BSA Registered Member

    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.
  24. dax123

    dax123 Registered Member

  25. Buster_BSA

    Buster_BSA Registered Member

    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.
Thread Status:
Not open for further replies.