Other issues in this category (26)
Many people are aware of the fact that the term “firewall” was initially related to fire safety. But there exists yet another security component whose name is associated with fire safety, but few people make the connection.
A sand bucket, a fire safe, or… just a sandbox. A place into which something that’s caught fire can be thrown and then examined to try to figure out what happened.
That's what the trendy security feature called a sandbox is for. An application is placed into a safe environment where it manifests its malicious properties (or doesn't). On paper, the environment is designed in such a way that the application can't affect anything outside the box.
Sandboxes can be used to examine files or launch applications in an isolated environment. The second option is often implemented in secure browsers that, among other things, enable users to safely carry out online transactions.
Naturally, sandbox designers strive to completely isolate every executable file so that the latter thinks that it has gotten full access to all user data. But a sandbox consumes system resources too. That's why there exists quite a variety of sandbox designs that differ in their system footprint and in how well they isolate programs.
The most reliable ones use virtualisation. Ideally, each file is opened in a separate virtual machine that has been launched specifically for this purpose. These are analogous to last containment vessels.
But in this case, an individual virtual machine must be run for each file. Otherwise, files must be transmitted between the test environment and another computer.
Furthermore, the file system and registry in the sandbox must be rolled back to the original state over and over again to rid it of infection. Otherwise, spam bots will remain operational inside the sandbox. The virtual machine has no other means to deal with them. In addition, removable media and games downloaded from the Internet must also be dealt with to see whether they contain nefarious backdoors.
And a significant portion of a system’s resources must be allocated for virtual machines. And to test malware in a virtual environment, the latter must at least have Microsoft Office installed in it. Meanwhile, commercial licenses cost money.
Another approach is based on the assumption that most Trojans need files to operate. So whenever they try to access a file, let's give them a copy of it!
Sandboxes restricting access to the file system and registry. Programs are granted access to file and registry copies in the sandbox, while the real data remains intact.
Control over access permissions prevents programs from mounting an attack from the sandbox via the operating system's interfaces.
But as in the previous case, here resources must also be allocated to copy the data required by the application being tested. Of course, nowadays hard drives have almost unlimited storage capacity, but should an application try to search through an entire disk and encrypt all the data, all the files will have to be replicated. And, in this case, you may run out of disk space.
After all, multiple files can be tested in their separate sandboxes concurrently.
And the chief problem is that the isolation is never complete. So if malware needs to access other system components or uses special hacking techniques, it may be able to reach outside the boundaries of the sandbox.
And how about just observing an application's behaviour without isolating it at all?
Here we're talking about rule-based execution. All attempts to alter the file system and registry are controlled using a set of security rules. The more thorough the rule set is, the better the security it will provide. This approach strikes a good balance between having the ability to freely transmit data to a desired destination and keeping system components protected from malicious modifications. Control over access permissions prevents programs from mounting an attack from the sandbox via the operating system's interfaces.
Well, this looks like Dr.Web's preventive protection.
But the risk of malware potentially breaking out of a sandbox is not the only problem. How many files need to be downloaded in order for a webpage to be loaded? What data gets written to a hard drive automatically?
The files that a user downloads are only the tip of the iceberg. Meanwhile, Trojans are known to download an additional payload. So how can we keep track of the files whose modification we need to control? Should we monitor ALL of them? We'd never have enough resources to accomplish this, and it would take a lot of time too. Can we create a filter that will automatically pick the files that need to be placed in a sandbox?
Solutions of this kind are never perfect. They may fail to recognise a malicious executable and can do nothing about malicious scripts. Besides, they can't prevent exploits from installing malicious browser extensions.
And there’s another problem—perhaps, the most significant one. All the sandboxes readily available on the market are well known. So attackers can easily provide their malware with the ability to determine whether it is being run in a sandbox.
The Trojan's installer can detect that the Trojan has been launched under a debugger or on a virtual machine, which impedes its analysis. It also checks whether the Trojan is being run under Sandboxie.
The Trojan remains idle for a specific period of time, without manifesting its malicious intent, and springs into action only after it has been set free.
To tell you the truth, we never expected the third type of sandbox to be so similar to our preventive protection feature. And, by the way, we have a sandbox of our own: Dr.Web vxCube. But, we do not hand it out on a plate, free for anyone's picking, which means that malicious programs can never know when they are being examined.