Other issues in this category (26)
Invisible armour against exploits
To inflict damage, virus makers need to do more than just come up with new malware—they also have to make some manipulations to whatever machine they are targeting.
The program they deploy doesn’t have to be a malicious one at all. For example, to steal money from a company, it can be enough to install a key logger—a legitimate program used to register the activities of certain employees. Or they can install a remote administration program which is also entirely legal and often used by system administrators. There are legitimate programs that lock screens, encrypt data (this feature can be part of an operating system), mine bitcoins, and perform many other tasks.
But what can an attacker do if the system settings do not permit users to install new programs? It turns out that there is a solution. Attackers can use return-oriented programming (ROP).
With this technique, they don't need to deploy any malware at all—everything they need is already present in the target system. An attacker only needs to know that certain pieces of code are present in a program or in the library that program uses and to make sure that the pieces of code are executed in a specific order.
Return-oriented programming is an improved version of a buffer overflowattack. This attack exploits a vulnerability in an application when a certain routine fails to verify that the data the application receives can be stored within a designated boundary. As a result, an assailant can transmit more data than the application expects, and the data will be written outside the buffer's boundaries. This may enable the intruder to alter the function's return address and later execute arbitrary code.
Attacks of this type are well known, and operating systems are equipped with ways to thwart them. For example, code execution can be prevented in memory areas that are known to store only non-executable data.
Few people know that this security countermeasure can interfere with the operation of anti-viruses which need to use the virus databases within them. The first anti-viruses contained all their code in a single file together with the engine and virus definitions. But because databases are large, it’s not very practical to download the entire database whenever it needs to be updated. That's why nowadays virus databases are stored as separate files. When an anti-virus starts, the databases are loaded into the application's data area in the memory. But since databases contain executable code, as well as signatures, additional efforts are required to circumvent the restrictions.
Preventing code execution in data areas offers protection against buffer overflow attacks. But why inject new code if all the necessary routines are already available in an application or a library? An attacker only needs to overwrite the return addresses of certain functions for the application to gain new features.
Protecting a system from attacks of this kind is much more difficult. Return-oriented programming attacks do not exploit program features, just some of their instructions including the return instruction. Such instructions are called “gadgets”. Picking out gadgets is easier if the code an attacker needs is located at the end of a function. That's why, in order to prevent such attacks, all instances of control transfer should be monitored. And if any of those appears to be suspicious, it should be interrupted. Also, if any "dangerous" routines are detected, all external calls to them should be controlled too.
These countermeasures can be implemented, but, alas, they require a high level of IT proficiency and, therefore, can't be adopted by most users.#Dr.Web_ShellGuard #DDoS-attack #security #hack #terminology #vulnerability
Can an anti-virus—often the only protection at a user's disposal—protect against attacks of this sort?
The attacker modifies a program that’s already running—the process's data area in the memory. That's why a conventional signature-based anti-virus can fail to detect the threat because no new files appear in the system. Security is assured only when changes made to processes are controlled internally In Dr.Web, the anti-exploit technologies of Dr.Web ShellGuard (available in Dr.Web Security Space 11.0) perform this task.