Comparison with Previous Works

Table8.5presents a comparison between the proposed solution and popular previous solutions, described in Section2.5.2. A short description and explanation is provided below:

Most of the previous works rely on the detection being performed on the applica-tion store side (criterion 1). It has been noticed that many third-party markets do not remove malicious applications, and in many occasions the distribution of malicious applications and adware is being done intentionally [103]. Since anyone with the required technical knowledge can potentially create an application market, it is unsafe to rely on them for the detection and removal of potentially harmful applications.

Many application markets are not likely to scan for repackaged applications due to the computational cost and/or the lack of technical expertise. Finally, there are dedicated websites and forums that distribute Android applications. Scanning application market servers for malicious and repackaged applications does not protect against applications that have been downloaded from such sources. The proposed solution was designed to be able to initiate the detection process from the client side, making it application download source agnostic (criterion 2), and notifying the user in order to prevent the installation of a potentially repackaged application (criterion 3).

Another shortcoming of the previous techniques is that they are mostly based on code analysis, or use features that are strongly linked with the application’s code. Therefore, they would not be capable of detecting applications that claim to be legitimate by just imitating their name and application icon, but using a completely different code-base (criterion 4), or when advanced obfuscation techniques have been

Table 8.5: Comparison with Previous Works

Criteria DNADroid DroidMOSS AppInk Proposed

1. App store centric 3 3 7 3*

2. Download source agnostic 7 7 3 3

3. Client notification 7 7 3 3

4. Detects stolen branding 7 7 7 3

5. Detects stolen source code 3 3 7 7

6. Resilient to code obfuscation 7 7 3 3

7. Requires trusted sample 3 3 3 3

*Although the current implementation focuses on the client side, there are no restrictions for scanning an application store using the proposed solution

8.5. Summary 153

applied (criterion 6). Solely in 2014, at least two samples were detected, claiming to be the Google Play Store application, none of which was using the original application’s source code [13,165]. Such solutions, however, may be able to detect whether an application has stolen parts of the source code of another application (criterion 5).

Finally, most proposed solutions have to maintain samples of trusted applications (or some other trusted derivative), against which a tested application is compared (criterion 7). A repackaged application cannot be detected by any method, unless that method maintains the necessary information of the authentic corresponding application.

8.5 Summary

In this chapter, a repackaging detection method was proposed, that takes advantage of the attacker’s inability to significantly modify the application’s name and icon, while maintaining the same attack vector. Therefore, an attacker is not likely to perform such modifications. The experimental results showed that the initial argument was valid.

Through a prototype that was built, it was possible to detect the original applications with high confidence, given a repackaged application as an input.

Compared to previous works, the proposed solution was found to be about as accurate as many application market level detection techniques, but capable of initialising the detection process from the client side, allowing for source-independent detection. Only a few kilobytes of data is required for the detection, which adds a slight overhead only on the application installation process. This feature is very important, as many application stores may not use repackaging detection techniques.

Google has started providing to users client-based detection of malicious applications through Google Play Protect [64], even though in the past it used to mainly rely on the server-based Bouncer [96,105]. Moreover, no special actions are required on the developer’s side. Finally, it is capable of detecting a variation of repackaged applications that only share the same name and icon with the original. Since repackaged applications are responsible for approximately 86% of the malware distribution on the Android platform, protecting against them can protect against various types of attacks, including the variation of relay attacks described previously in this chapter.

155

Chapter 9

Conclusion and Future Work

Relay attacks pose a serious threat towards the entities involved in a transaction.

The victims of such attacks may include not only the users who are performing a transaction, but also banks (e.g. in the case of financial transactions), transport operators (e.g. in the case of attacks on ticketing systems), and corporations (e.g. in the case of relay attacks on access control systems), among others. This may result in financial loss or loss of reputation, identity theft, and more.

Relay attacks are difficult to be detected by authorities beyond the victim user.

In the field of smart cards, distance bounding protocols have demonstrated high effectiveness in relay attack detection. However, in the field of smartphones, distance bounding protocols might not be effective, as discussed in previous chapters. One alternative PRAD solution that has been proposed suggests the collection of mea-surements from the immediate ambient environment of the transaction devices (the natural ambient environment). The measurements are subsequently compared for similarity, in order to establish proximity evidence. The data should be collected during the course of a transaction, using some ambient sensor(s). For example, in the case of a payment transaction, when the user taps the transaction instrument on the transaction terminal, both devices should collect data during the course of the transaction. One of the devices or a TTP (e.g. the bank) is then responsible for the PRAD process, through comparison of the collected data.

In this thesis, the effectiveness of the natural ambient environment was initially assessed. The evaluation focused on time-restricted mobile contactless transactions, taking into account industry requirements, such as the ones imposed by EMV.

Previous work did not take into account such restrictions, which nonetheless apply on a large number of security-critical mobile contactless transactions, such as mobile payments and transportation-related transactions.

The initial evaluation of the natural ambient environment as a PRAD mechanism demonstrated results that may be inadequate in respect to PRAD for security-critical applications. Subsequently, different approaches were proposed in order to improve the accuracy of PRAD for such transactions.

First, the generation of an AAE was proposed. For this approach, the devices that communicate during a transaction are responsible for generating and/or measuring the AAE that is produced through some of their peripherals (e.g. vibration). The

156 Chapter 9. Conclusion and Future Work

generation of an AAE should be based on a random stream or sequence and be easy for the genuine transaction devices to establish PRAD-related information, while being difficult for an attacker to relay at a remote location. Similar to natural ambient environment sensing, the data collected by the transaction devices are compared for similarity and a transaction is approved if the similarity exceeds some certain threshold.

From a list of proposed peripherals that can potentially be used as AAE actuators, infrared light and vibration were evaluated, both of which demonstrated positive results (∼98% TAR, and 0% FAR on infrared, and near perfect classification of genuine and relayed transactions on vibration). The applicability of infrared in real-world scenarios was also evaluated, showing that there is potential for the proposed solution to be integrated to commercial applications/products.

Moreover, two approaches that do not rely on sensing of the ambient environment were proposed. The first of them suggested the use of a random sequence of virtual buttons that are presented on predefined locations of the display of the transaction instrument (smartphone). The transaction instrument is placed on a special ‘plate’, operated by the transaction terminal, capable of detecting the approximate location of where force is being applied on the device which is placed on it. The genuine user of the smartphone is called to touch the buttons that are displayed at random predefined locations of the screen. The transaction terminal is capable of detecting which button was pressed on the mobile device, based on the capabilities of the sensing ‘plate’.

Both transaction devices record the pressed button sequence, the duration of button presses, as well as the duration between subsequent button presses. The timings and the sequence recorded by the two devices are then compared for similarity in order to determine whether the devices are in proximity. The solution demonstrated high effectiveness as a PRAD mechanism. A set of ten attackers tried to attack the proposed system, however all of the attempts (200 in total) were successfully detected, both using threshold- and machine learning-based analysis techniques.

Finally, a method to detect repackaged applications was proposed. Repackaged applications have been found in the past responsible for the distribution of approx-imately 86% of all Android malware. Moreover, relay attacks that use a malicious application installed on a genuine user’s device, instead of relying on masqueraded devices, have been demonstrated. Since repackaged applications are a major source of malware distribution, detecting such applications prior to their installation is crucial for protecting against a large variety of attacks, including relay attacks. The proposed solution suggested that looking at the features that characterise the application prior to its installation, i.e. its name and icon, in case it is not found to be genuine, can assist towards detecting whether the application might be potentially repackaged. An evaluation of the proposed solution revealed high accuracy in detecting repackaged applications. Moreover, the detection process is initiated from the client side, which makes the solution application source agnostic. This is a major advantage over other proposed solutions that rely on application markets to run the repackaging detection,