Security analysis

The proposed architecture comes with a set of drawbacks that can be generalised to any other static software attestation system. Considering the MATE scenario, where the end-user and the attacker have the same privileges on the delivered application, it is possible to underline the vulnerabilities that one have to take into account when static software attestation is deployed. An attacker has to interrupt the Attester’s tasks or to fake its behaviour to prevent the protection to work correctly.

Attestation operations prevention

Hereafter are presented a set of possible threats that are introduced by im-plementation choices made for the Attester. It generally means that most of the presented issues may be overcome with enough engineering effort and do not require any further research.

Preventing the Attester to start, the most trivial attack consists in avoiding the execution of the Attester. Indeed, if the Attester does not run at all, it cannot start any communication with the server; thus, the Manager would not be aware whether the target application is running or not. This kind of attack is possible, for the presented system, because the Attester run in a thread that is parallel to the target application’s main process. An attacker that can identify the point in which the Attester thread is spawned can bypass it as well, e.g. by statically removing the system call to thread spawn of dynamically bypassing it.

Countermeasure: engineering is needed to make the Attester routine integrated into the target business logic, thus to be not distinguishable from the regular ap-plication tasks. Additional instrumentation operations should be introduced to rewrite the target’s code so that it includes commands to start communications with the server and reaction to incoming requests.

Requests Stop, another attack that can be mounted is to stop incoming re-quests. Only by monitoring the system calls that receive data from the network, an attacker can catch the communication and drop it before it reaches the Attester logic. It is noticeable that it is not equivalent to disconnect all the application from the network. Indeed, a full disconnection would prevent network business logic operations as well. For instance, for a real-time streaming application network dis-connection would cause the playback to stop as the stream is not reachable any more.

Data Collection Inhibition, even if the attestation request reaches the at-tester routine, it is possible from an attacker’s point of view, to avoid the execution of attestation collection procedure. Indeed, once the attestation request is received, the Attester thread calls the data preparation routine that is a function. Hence, an attacker may identify the function call and, statically or utilising a debugger,

3 – Detection

she can force the execution to pass over that code, thus not running it at all. This way, the attestation response is not computed and not sent to the Verifier.

Attestation Response Send Stop, an attacker can tackle the attestation process even after the attestation data is computed and response is produced. It is possible to prevent the Attester from sending responses back to the server both from within the Attester process and from an operating system perspective. In the first case, the attacker identifies the invocation to the network send system call and bypasses it, e.g. by using a debugger. In the second case, the attacker captures the traffic from the target to the server and drops packets from outside the application, e.g. by using a packet filter, a firewall or a network traffic monitoring tool.

Countermeasures: the way to face all the previous three vulnerabilities strictly depends on the kind of reaction that is put in place. If reactions are only local, which means that the server does not trigger faults in the application, the threat is more significant. That is, local reactions are usually based on events that can be observed locally, e.g. timers that are reset by a positive event. Hence, an attacker that can prevent requests to reach the Attester should be able to bypass this kind of reactions as well. On the other hand, if reactions are server-based, the vulnerability is much more negligible. The server-side mechanism can notice that no responses are received against sent requests. In this case, an attacker cannot do anything to block the reaction as the server can, for instance, stop to serve the application with the requested contents. Consequently, countermeasures are more straightforward if reaction enforcement is performed remotely, by the server, and they become more laborious if the reaction enforces locally.

Cloning attacks

The vulnerability presented here affects any static attestation (both hardware and software). Hence, it affects the delivered system as well. Van Oorschot et al.

presented this kind of attacks and demonstrated that it is possible to circumvent self-hashing-based techniques for integrity protection in a subtle way [51]. The pre-sented attack exploits on operating system modifications; it exploits the difference between memory accesses to data and code.

The attacker clones the untampered target program, tampers with one copy, and let the other one intact. Given that data memory accesses can be easily told from code-fetch memory accesses, the attacker can modify the operating system kernel so that it redirects all the data accesses (including those to code portions performed by an Attester) arbitrarily. Then, the attacker runs both application copies and let the patched kernel redirect all the data reads to the genuine copy in memory while letting the instructions to be fetched from the tampered program.

Hence, when a self-hashing mechanism tries to read from the application code, just like the Attester does, it gives valid data even if the running application is corrupted.

Finally, the attack is enabled by the MATE scenario and fully privileged access to the execution environment. The attacker can perform any tampering on the target structure, which is the kind of attacks that static software attestation aims at detecting. Moreover, the attacker must not reverse engineer the application to spot protection mechanisms such as software attestation; he can approach the application as a black-box and concentrate on the sensitive parts to modify on his needs.

Countermeasures: unfortunately, Cloning Attack is a severe issue for static soft-ware attestation in general and the mechanism presented in this Chapter. There is no remediation to this kind of attack, as it is still an open issue in literature as well.

The attack cannot be spotted from within the application because it is performed at a higher level, that is, at the operating system level. Then, there is no chance to block Cloning Attacks by using a technique that is entirely based on target embed-ded components. The proposed architecture for static software attestation offers possible mitigation to the cloning issue. Diversification and runtime renewability may be exploited to replace the embedded Attester(s) periodically. Consequently, it would periodically replace hard-coded procedures that extract evidence as well.

It would cause computed attestation evidence to differ from the ones obtained by the original Attester even if the attacker redirected memory accesses. Nonethe-less, run-time renewability techniques are out of the scope of this work; hence, this document will not discuss them.

Non structural modification

Another class of vulnerabilities is represented by tampering modifications that do not alter the application structure, those modifications that alter the program behaviour without tampering with its binary code, e.g. Debugging Attacks. An attacker can use whichever external tool to stop, restart and redirect the application execution, as well as to modify the content of data locations (memory, registers, data segments). In practice, these kinds of attack dynamically alter the target’s execution while letting the software structure intact.

Countermeasure: this kind of attack cannot be detected by static software attes-tation by definition. Indeed, static software attesattes-tation aims at discovering struc-tural modifications to the original program and is not conceived to protect from this kind of threats. To this purpose, it is worth to evaluate the possibility to com-bine static software attestation with additional protections, e.g. dynamic software attestation.

In conclusion, the static software attestation system presented in this chapter is in line with most of the others found in the literature. For instance, it checksums code portions to attest the structural integrity of the target and exploits random nonce-based transactions. On the other hand, here it has been presented a static

3 – Detection

tamper detection system that can be extended, customised and diversified to ex-ploit different procedures and assets kinds, as opposed to many works in literature.

Indeed, immutable structures and procedures represented a vulnerability for many static attestation systems, as reported in [51]. Hence, flexibility features allow the proposed mechanism to be tailored to resist to attacks that defeat the delivered Attesters by offering the chance to vary the Attesters themselves. In particular, it enables diversification as each fundamental part of the system can be extended and rewritten. Finally, it enables composability with other protections to enhance the security level of the resulting system and to protect the detection mechanism itself.