The Anti-virus Times

Friday, September 21, 2018

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.

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!

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?

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?

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 remains idle for a specific period of time, without manifesting its malicious intent, and springs into action only after it has been set free.

#Dr.Web_vxCube #technologies #anti-virus