International Journal of Distributed Sensor Networks 2016, Vol. 12(8) Ó The Author(s) 2016 DOI: 10.1177/1550147716662947 ijdsn.sagepub.com
Using malware for software-defined
networking–based smart home
security management through a taint
checking approach
Ping Wang
1, Kuo-Ming Chao
2, Chi-Chun Lo
3, Wen-Hui Lin
1,
Hsiao-Chung Lin
1and Wun-Jie Chao
1Abstract
Numerous security concerns exist in smart home systems in which Internet of Things devices are connected through a home network to enable control using a centralised gateway with a handset device from the Internet. Safeguarding personal information privacy is an increasing concern in smart living services. To guarantee the mobile security of smart living ser-vices, security managers use taint checking approaches with dynamic taint propagation analysis operations to examine how a software-defined networking app uses sensitive information and investigate suspicious security vulnerabilities of devices and the effects of the spread of taint propagation over the Internet by identifying taint paths. For solving the dynamic taint propagation analysis problem, most approaches focus on cloud computing applications (apps) with malware threat analysis that involves program vulnerability analyses, rather than on the risk posed by suspicious apps connected to the cloud com-puting server. Accordingly, this article proposes a taint propagation analysis model incorporating a weighted spanning tree analysis scheme for tracking data with taint marking using several taint checking tools with an open software-defined net-working architecture for solving the dynamic taint propagation analysis problem. In the proposed model, Android programs perform dynamic taint propagation to analyse the spread of risks posed by suspicious apps connected to the centralised gateway in a smart home system. In probabilistic risk analysis, risk and defence capability are used for each taint path to assist a defender in recognising the attack results against network threats caused by malware infection and to estimate the losses of associated taint sources. A case of threat analysis of a typical cyber security attack is presented to demonstrate the proposed approach. A new approach was used for verifying the details of an attack sequence for malware infection by incorporating a finite state machine to appropriately represent the real dynamic taint propagation analysis situations at vari-ous configuration settings and safeguard deployment. The experimental results proved that the threat analysis model enables a defender to convert the spread of taint propagation to loss and estimate the risk of a specific threat using beha-vioural analysis associated with 60 families of real malware. Consequently, our scheme was significantly effective in predict-ing the risk and loss of tainted data propagation for security concerns in smart home systems when the number of taint paths associated with the propagation rules discovered through taint analysis was increased.
Keywords
Mobile security, taint checking, software-defined networking, dynamic taint propagation, smart home system
Date received: 27 February 2016; accepted: 28 June 2016 Academic Editor: Suat Ozdemir
Introduction
Cloud computing uses the Internet to deliver informa-tion services to open networks and involves the
1
Department of Information Management, Kun Shan University, Tainan, Taiwan
2
DSM Research Group, Faculty of Engineering and Computing, Coventry University, Coventry, UK
3
Institute of Information Management, National Chiao Tung University, Hsinchu, Taiwan
Corresponding author:
Ping Wang, Department of Information Management, Kun Shan University, Tainan 710-03, Taiwan.
Email: pingwang@mail.ksu.edu.tw
Creative Commons CC-BY: This article is distributed under the terms of the Creative Commons Attribution 3.0 License (http://www.creativecommons.org/licenses/by/3.0/) which permits any use, reproduction and distribution of the work without further permission provided the original work is attributed as specified on the SAGE and Open Access pages (http://www.uk.sagepub.com/aboutus/ openaccess.htm).
deployment of large-scale platforms; therefore, com-mercial data on the clouds might become targets of net-work attacks. For example, in September 2014, celebrities’ private photographs stored in the iCloud were disclosed. To prevent such a hack, a security anal-ysis of the information exchange within intersuspicious modules (intramodules) and program of an external network (interapp), such as illegal access memory, buf-fer overflow attacks of the intramodule and malware downloaded by the botnets of the interapp, are required. In practice, new malware attacks can bypass firewall-based detection by bypassing stack protection and using Hypertext Transfer Protocol logging, kernel hacks and library hack techniques and to the smart liv-ing appliances (apps). Effective security defence mechanisms involving threat analysis techniques are essential for detecting intruder attacks in open net-works. Taint checking (TC) is a blacklisting approach because it asserts that certain values are dangerous for taint analysis. Generally, TC involves evaluating spe-cific security risks from attacks such as memory cor-ruption and a buffer overflow attack.1 Unlike the traditional threat analysis technique, in TC, the focus is more on detecting exploits, and data flow analysis is used to determine whether the value is derived from a user input. In taint analysis, modules connected to data originating from untrusted network channels are marked as contaminated, and a series of arithmetic and logic operations to track data with taint marking.
To guarantee the security of cloud computing sys-tems, network administrators use TC approaches with an open software-defined networking (SDN) architec-ture to examine how a cloud app uses sensitive infor-mation and investigate suspicious behaviours of users before deploying an app. An SDN architecture may facilitate network-related security applications because of the controller’s central view of the network, and its capacity to track data with symbolic taint marking and identify the spread of intents. In performing malware
threat analysis against unspecified malware attacks, network administrators can use a TC approach for tracking information flows between attack sources (malware) and detect vulnerabilities of targeted net-work apps.
Many TC approaches have been developed to enhance security by preventing malicious users from executing commands on a host computer,2–5 which require computing emulations with a set of distinct mis-sion hosts in a virtual security experimental environ-ment. As described previously, most existing TC schemes focus on examining the security hole for mobile device apps but do not fully address the severe issues regarding the risk posed by suspicious apps con-nected to security holes in the cloud computing server. The comparative analyses of TC schemes are provided in Table 1.
The literature contains various proposals for solving the TC problem based on sandbox analysis techniques (SATs). Although SATs have many advantages, they have several limitations. For example, multiple taint sources cannot be traced online. In addition, taint sources can be easily infected through app connections. Furthermore, an SAT does not adequately answer criti-cal questions regarding (1) the security holes of various risk levels in the development of network apps and (2) the attack paths selected for introducing safeguards. By contrast, the TC scheme emphasises specific security risks primarily associated with websites that are attacked using techniques such as SQL injection and buffer overflow attack approaches.1 Thus, TC tech-niques effectively specify possible targeted information flows between the attack sources (malware) and the security holes of network apps. Moreover, the technical content of an SAT differs from that of the traditional threat risk approach; that is, an SAT focusses on the detection of the dynamic behaviour between the suspi-cious host and the test app’s vulnerability, whereas the TC technique emphasises examining the scope of taint Table 1. Comparison of TC approaches for cloud app security.
Issue Goal
Client site Server site
Targeted at Privacy of mobile devices Commercial information of enterprise servers Solving problem Stain checking for the privacy leakage of mobile
devices
Examine the stain propagation and leakage problems caused by the invasion of both the server and business repository in virtual machines
Information security needs
Find vulnerable apps containing security holes that are not exploitable
Evaluate the content of transmission messages that may be modified or stolen in cloud servers, which can compromise user privacy
Assess the spread of taint propagation with loss for leaking personal privacy
Accurately assess taint analysis with time constraints
propagation within an intramodule or interapp. In addition, the connection to taint sources by judging the intents of a contaminated information flow is derived from either the user input or external taint sources for determining the exact signature of exploits (SOEs).
Accordingly, this study proposes a taint propaga-tion analysis model that incorporates a weighted span-ning tree analysis for tracking data with taint marking and identifying the spread of intents by considering the state transitions of a program in an SDN-based smart home security management system. Both dynamic taint analysis (DTA) and risk analysis are incorporated in the scheme and used for possible sys-tem exploits to solve the dynamic taint propagation analysis (DTPA) problem. In the following context, each taint analysis tool, Valgrind6 and ComDroid,7 associated with two malware behavioural analysis tools, Androguard8 and Droidbox,9 is used to assist defenders in examining data correct. This analysis helps defenders to analyse the SOEs accounting for the behavioural profiles for assessing the risk of a taint source to the commercial data in the cloud com-puting server. In developing the proposed model, we considered two crucial aspects: (1) the investigation of the taint paths, propagation rules (PRs) and SOEs for a taint source by tracking data with symbolic taint marking and (2) the evaluation of risk in accordance with the taint paths responding to specific attacks.
The remainder of this article is organised as follows. Section ‘Related work’ reviews previous studies in this field. Section ‘Dynamic taint propagation model for threat risk analysis of mobile malware’ introduces the proposed taint propagation analysis model based on the behavioural profile of suspicious apps. An analysis of the results is presented in section ‘Cyber security app’. The taint risk in the DTPA process is discussed in section ‘Discussion’. Finally, section ‘Conclusion’ pro-vides the conclusions of this study.
Related work
This section describes the use of two important parts to solve the DTPA problem in open networks, namely, TC approaches for assessing threats and security using SDN architecture.
TC approaches for assessing malware threats
Typically, the following two basic approaches are used for TC: (1) static taint analysis (STA): examine the pro-gram text and analyse overmultiple paths of a propro-gram. Typically, STA is performed on a control flow graph in which statements are nodes, and an edge exists between nodes if there is a possible transfer of control. (2) DTA: investigate the instructions executed when the program
runs. In particular, DTA inspects a single path once of a single run and determines exact taint values.10By con-trast, the STA might generate extra taint paths from control flow graph and result in false positives.
Normally, three crucial steps are followed in DTA: (1) taint source analyses, (2) propagation analysis with taint marking and (3) testing of the code with the asser-tions. Since the 2000s, TC approaches have been used for exploring the vulnerabilities in information systems and identifying possible impacts from malware attacks by altering the flow of program execution. In compari-son to STA, DTA tracks intents with taint marking to the information flow of the intramodule or interapp; consequently, it is relatively accurate for monitoring the running app and is suitable for tracking the flows of pri-vate sensitive data.11
Many TC approaches incorporate taint propagation algorithms for detecting malware. TC techniques for an analysis algorithm, including Argos,2 Panorama,3 TaintCheck,4ComDroid7and TaintDroid12approaches, have been used to increase the analysis precision by pro-viding insights into how activities and outputs are formu-lated through the transmission of intents from tainted sources. These TC schemes are summarised in Table 2.
Security management using an SDN architecture
SDN began after Sun Microsystems released Java in 1995. SDN enables network administrators to manage network services through the abstraction of high-level functionality. SDN is a dynamic, manageable, cost-effective and adaptable architecture suitable for the high-bandwidth, dynamic nature of today’s applica-tions. SDN architectures decouple network control and data forwarding functions, enabling network control to be directly programmable and the underlying infra-structure to be abstracted from applications and net-work services.15In smart living appliances, Internet of Things (IoT) devices are connected through a home network to enable control using a centralised network controller associated with remote network devices from the Internet. When integrated by wireless sensing and information communication technologies for IoT devices, home systems and appliances are advantageous because they can communicate in an efficient manner that provides living convenience, health promotion and safety benefits. Because personal information in smart living services cannot be disclosed without legal permis-sion, using private information, including personal IDs, locations, biometrics and secret data, requires ensuring its security.
Theoretically, an SDN-based network architecture provides a user with secure remote monitoring and managed smart living appliances for the home environment. Examples include remote control lighting
systems, fire warning, the remote monitoring of infant activity, pet status remote monitoring and the transmit-ting of personal health information to a cloud platform for analysis. Although mobile devices and IoT devices with an SDN architecture for smart living appliances have improved the convenience of our daily lives, they also pose a threat to personal privacy and information security for users. Moreover, networking manufactur-ers generally collect pmanufactur-ersonal information and private habits without warning. Consequently, mobile devices or IoT devices are controlled by remote malicious users and cause the improper disclosure or sharing of
information. In practice, devices in smart homes pro-vide network-layer security and privacy control mechanisms to ensure the privacy and information security of users by monitoring network activity and detecting suspicious network behaviour. Accordingly, a dynamic security mechanism based on network-layer security and privacy control mechanisms is adopted in the SDN controller (Figure 1).
In addition to existing security mechanisms, novel approaches using SDN as a network-wide control mechanism for resolving high-risk security concerns, including distributed denial of service detection and Table 2. Security analysis approaches for TC.
Reference Features Suitable for Limitations
Newsome and Song4
Developed the TaintCheck tool to capture a system-wide information flow for malware detection, including most types of exploits
TaintCheck produces low false positives for all suspicious programs because the static stain analysis performs
according to all possible control flows
May generate too many control flows connected to security holes, often resulting in high
computational costs for complex system modelling
Portokalidis et al.2 Argos is a full and secure system emulator based on Qemu, which uses dynamic translation to achieve a satisfactory emulation speed
Uses DTA to track data throughout execution and detects any attempts to use them illegally
Argos provides immediate network attack alerts through program execution, which requires a considerable amount of time Yin et al.3 Implemented a TC tool,
Panorama, to detect and analyse malware and offer valuable assistance to code analysts and malware scientists
Suitable for quickly
comprehending the behaviour of an unknown sample malware by capturing fundamental traits
Malware must be analysed manually; therefore, it is time-consuming
Kim et al.13 Developed a DTA tool to track multiple mixed information flows among several processes across a distributed enterprise
Examines the taint propagation scope of information flows within the intramodule or interapp to taint sources
Sensitive to the information structure of an organisation, which heavily depends on the
customisation of tool usage McClurg et al.10 Proposed an integrated system
involving DTA to mark certain information sources as tainted and keep track of the tainted data propagating in the system
Detects privacy leaks with a relatively minimal overhead, assisting defenders in determining exact taint values with a reduced computational overhead
Produces extremely large suspicious paths to analyse interapps and outputs from taint sources such as user inputs and reads from network connections or definite memory locations and API calls
Chin et al.7 Proposed an STA tool,
ComDroid, to examine Android app interaction and identify security risks in app components
ComDroid can describe the disassembled output from Dedexer and log potential app component outputs and intent vulnerabilities to perform the dynamic symbolic execution of programs
The authors tracked the intent control flow across functions but did not distinguish between paths through if and switch statements. Instead, they followed all branches. This can lead to false-negatives Enck et al.12 Built a real-time monitoring
system called TaintDroid to track how apps use sensitive information on Android platforms at a low level
Precisely analyses how private information is obtained and released by apps downloaded on consumer phones
Requires integrating parts of TaintDroid’s API calls into an app. Consequently, implementing TaintDroid as a stand-alone app is not possible
Rastogi et al.14 Developed a security analysis of the app AppsPlayground for an automated dynamic security analysis of Android apps
AppsPlayground is suitable for automatically detecting privacy leaks and malicious
functionalities in apps
For automatic exploration, many events are simulated; this requires substantial time and is sometimes deficient because user interfaces for apps have complex requirements
mitigation,16,17worm propagation18and botnet protec-tion,19have been suggested by several researchers.
Dynamic taint propagation model for
threat risk analysis of mobile malware
The proposed model was designed to examine informa-tion flows associated with suspicious taint sources, use a taint graph to track the suspicious connection with the taint source and identify the spread of tainted data.Basic concept
Suppose there are taint sources and a taint sink of a targeted network (i.e. an SDN-based smart home sys-tem) in which hackers attempt to compromise network security. For solving the DTPA problem, our approach focusses on developing apps using malware threat anal-ysis that involves program vulnerability analyses for identifying both security holes and malicious beha-viours associated with malware attacks.
The first task is initialising and marking all modules for cloud services as a clean state in a targeted network. The basic concept involves using the weighted spanning tree algorithm (WSTA) and determining the cut sets for DTPA on the basis of taint marking; that is, the information type is assigned to tainted data. A taint graph was constructed by starting from a taint source to any connected module through intent transmission. A depth-first search (DFS) was then performed on a
taint graph in accordance with taint marking to gradu-ally connect the edges between the two adjacent mod-ules, which pass tainted data (i.e. intents) through the network. In such a situation, the module is marked as contaminated, and the module is marked as clean if no tainted data transmit; that is, the edges between the two adjacent modules are disconnected (dotted lines in Figure 2).
At the end, after visiting all modules, the traversal path of taint propagation was constructed using the DFS spanning tree algorithm. The taint graph repre-sents how tainted data or messages propagate during program execution and is depicted as a directed graph G = (V, E), wherein a set of vertices V = {u, v1,
v2,., vm}. u represents a taint source; v1, v2,., vs
repre-sent a set of modules in an app or a cloud service; E= {e1, e2,., en} represent a set of edges between
two neighbouring modules of G (Figure 2).
As shown in Figure 2, existing TC approaches do not consider the state transition of an app module in a system, including preconditions and postconditions. In other words, although the receiver module accepted intents, defenders used security protection, such as bug fixes in the operating system and a firewall in the net-work system, to repel the taint propagation results. However, if defenders do not patch the security vulner-abilities, tainted data would spread. Thus, this study incorporated a finite state machine (FSM) to appropri-ately represent DTPA using a network flow analysis technique (Figure 3). Figure 3 shows that the FSM may generate uncontaminated states for a module in a taint graph in defence situations and contaminated states for the same module shown in Figure 4. Using an FSM-based taint propagation of information analy-sis produced various results that represent the actual situations in which various configuration settings, secu-rity fixes and safeguard deployments were set up in the DTPA processes.
Figures 3 and 4 show that considering the state tran-sition of a module for taint analysis is more suitable than those in existing TC approaches. As shown in Figure 4, if tainted data are received from an untrusted source for a module that accepts tainted data and out-put intents to the connected modules, it would be marked as a contaminated state. The module connects the edges between these modules. By contrast, a mod-ule is marked as uncontaminated if it disconnects the edges between two modules.
This study proposes an SDN-based smart home sys-tem with an OpenFlow protocol for network configura-tion, traffic management and security monitoring (Figure 5), in which an OpenFlow switch (network device) and a controller communicate via the OpenFlow protocol. In the proposed SDN system, the SDN architecture enables the network controller to track data with taint marking and determine the path Figure 1. SDN-based network architecture.
of network packets across a set of networks of switches with two basic components: (1) a control tool (controller) for determining the network packet flow and (2) the OpenFlow routing table (Flow Table) for selecting the network packet transmission path. Thus, OpenFlow can enable the remote admin-istration of packet forwarding tables for layer 3 switch by adding, modifying and removing packet matching rules and actions.20
As Figure 5 illustrates, two management tools for OpenFlow are incorporated into the smart home system to detect suspicious behaviour: (1) Open vSwitch, which is used to build a network device for data forwarding and packet routing management in the SDN infrastruc-ture layer, and (2) Floodlight, which is an open-source tool used as a supervisor to manage the SDN control layer and application layer for access control and traffic and security monitoring.
Figure 2. Use of taint analysis to determine whether the module is contaminated via intents.
Penetration testing with malware through a trace of intents is an effective approach that facilitates evaluat-ing the security of SDN infrastructures to safely identify vulnerabilities of systems. In practice, sending intents to the improper app modules can lead to user privacy leakage and permissions transferred among apps. Therefore, a taint marking–based framework for track-ing intents is proposed and described in the followtrack-ing.
Constructing a taint graph involves large amounts of intent transmission from taint sources to taint sinks and often requires numerous logic operations and cost analy-ses. Therefore, the WSTA associated with an open SDN controller was used to assist defenders in tracking data with taint marking for DTPA (Figure 6). In addition, the mechanism was developed to analyse the spread of taint propagation in the information flow between Figure 4. Taint analysis by considering the state transition of a module.
mobile devices and cloud computing servers and to help defenders to define the SOEs for taint sources.
Figure 7 shows that the malware behavioural analy-sis incorporated in the framework is suitable for taint source detection and propagation analysis using appli-cation programming interface (API) hooking and taint marking to identify the taint paths of the propagation spread. Three subprocesses included in the DTPA pro-cess are taint source analysis, taint propagation analy-sis and determination of SOEs.
TC process of malware threat analysis
Assume that partial system vulnerabilities of a cloud service are known and a set of behavioural profiles
associated with each malware has been identified. The following DTPA algorithm includes a new resolution process of taint propagation to track the taint paths of propagation according to the behavioural profiles of a specific threat, thereby estimating the SOEs of a suc-cessful attack by malware.
Step 1: taint source analyses
Step 1.1: malware behavioural analyses. To perform behavioural analysis of malware, a common approach is to use virtual machine analysis techniques. Generally, a sandbox provides capabilities such as stopping at a control point to prevent potentially dangerous pro-grams from running, as well as monitoring and record-ing activity in a closed environment when the malware is running. Malware signatures were derived by combin-ing both the security flaws of static code analysis and dynamic behavioural patterns of behavioural analy-sis with the support of a virtual machine emulator to facilitate the detection of unidentified mobile malware and variants.
Dynamic behavioural analysis was conducted to obtain the major runtime behaviour regarding access to the network, file, registry and disc of each app, which was compared with malicious and normal behavioural profiles. Static analysis was conducted to examine the specific source codes and binary strings of malware, and comparison results were recorded in a log file to discriminate the differences in the signatures of malware variants and new viruses. In the malware behavioural analyses, two free shareware products, Androguard8 and DroidBox,9 developed by the Honeynet project, were used to generate malware signatures as the source data set; these signatures were used to taint analyses later. An experiment involving the following four steps was conducted:
Figure 6. Framework for DTPA with an open SDN controller.
1. Download the suspected apps (.apk file format) from a mobile phone;
2. Perform in-depth behavioural analysis on the DroidBox platform;
3. Perform code analysis on the Androguard plat-form using reverse engineering;
4. Output the synthesis report.
Step 1.2: malicious activity analyses of taint sources. This step involves the violation detection for the permission rules as the taint source analyses. Four protection levels exist for the access to the system API with permissions on Android platforms: Normal, Dangerous, Signature and SignatureOrSystem. Apps request the appropriate permissions in their manifests to obtain a privileged access to system commands or protected API calls. To analyse the behaviours of the taint sources, the com-mands of program executables and API calls outputs connected modules to be listed as the basis of malicious instruction sets (MISs).
To identify the attack profiles of MISs, intent-based analyses are adopted to inspect the transmission of intents from taint sources to the receiving module. Intents can be sent between three of four components: Activities, Services, Receivers and Broadcast. Intents can be used to start Activities; start, stop and bind Services; and broadcast information to Broadcast Receivers.7 Generally, intent operations include three types of instruction sets: (1) source: MISs for taint source analysis exchange parameters between the taint sources and sinks, such as startActivity, startService, stopService, bindService, read and gets; (2) sink: the instruction sets for a taint sink include receive, onReceive and write; and (3) propagation: commands for taint propagation comprise sendBroadcast and sendOrderedBroadcast. Once the MISs are located, intent-based analysis can be used to construct the mali-cious behavioural profiles for taint sources.
Step 2: examining security holes in cloud apps. This step identifies security holes using STA that involves pro-gram vulnerability analyses for developing apps. Theoretically, more security holes in apps cause mali-cious behaviours.
Available TC schemes for examining security holes using analysis mechanisms, such as Panorama,3 Valgrind,6TEMU21and TAJ,22are capable of inspect-ing security holes in apps. Valgrind,6 developed by Seward, was proposed for automatic multimemory debugging and detailed memory leak detection. Valgrind was originally designed to be a free memory debugging tool for a Linux operating environment, and it has evolved into a generic framework for creating dynamic analysis tools such as checkers and profilers for inspecting programs being developed. In particular,
Valgrind can recompile a binary code to run on the host and target of the same architecture using a simu-lated CPU technique. Therefore, it is suitable for sup-porting the inspection of data at possible exploits through the examination of program control transfers.
Valgrind contains multiple tools. The most fre-quently used tool is Memcheck. Valgrind is a virtual machine using just-in-time compilation techniques, including dynamic recompilation. In STA, six types of test cases are examined using Memcheck: (1) invalid write, (2) conditioned jump on an uninitialised value, (3) memory boundary check for invalid read and write, (4) source and destination overlap, (5) inconsistencies between dynamic memory allocation and release and (6) memory leak. The evaluation of risk based on the security holes responding to a specific threat is described in the following.
Step 3: DTPA. This step helps defenders to examine whether a testing app is vulnerable to potential cyber attacks by comparing normal and malicious beha-vioural profiles (i.e. permissions, PRs and SOEs) between a legitimate app and a malware website. In DTPA, PRs and SOEs for taint sources are charac-terised using three subprocesses: (1) correlation analysis (CA) for MISs, (2) taint propagation analysis using the WSTA and (3) the determination of SOEs.
Step 3.1: correlation analysis for MISs. To identify the spread of taint propagation, PRs must be defined by tracking the information flow. Theoretically, PRs can be derived using CA for app components and relevant tainted data via the execution of MISs to analyse the stain propagation behaviour. Furthermore, many CA approaches incorporate association rules, frequent epi-sode rules and data mining approaches to facilitate pre-cise prediction for generating PRs.
PRs for tainted data can be analysed by comparing the distinct calling sequences of the malicious API calls in which the calling sequences are establishing using a pair of [Sourcej, SinkkSinkk+1, .] between the malware
website and the proper app. In practice, network analy-sis tools, such as Netflow and Wireshark, can be used to assist a defender in collecting large amounts of logs to identify the specific calling sequences of MISs. Finally, the relevant calling sequences of MISs based on program execution for each taint source j are summed to generate the PR, which has the form PRi
(Apk name, Taint source, Module and Calling sequence of MISs), as shown in Table 3.
As shown in Table 3, the calling sequence of MISs represents the propagation chain of a taint source i (i = 1,., m) and comprises a set of methods used in evaluating the attack signature for each module. The module name associated with a specific MIS is
measured using a set of calling sequences, where a lon-ger calling sequence might cause a higher risk and severe loss.
When deciding the calling sequence of MISs (Table 3), determining the exact pattern of the taint propagation actions is difficult. On the basis of the con-cept of an intrusion detection system, the occurrence of taint propagation is solved using frequent episode rules23 by accumulating and associating the security logs as follows. Generally, episodes are partially ordered sets of events. The frequent episode rule is used to determine the specific event sequences for appropri-ately determining the MISs of a taint source, as shown in Figure 8.
Given an event sequence s = (s; Ts; Te) and a
win-dow width win, let the time winwin-dow of an episode be given by w = (w; Ts; Te). The support degree of an
epi-sode is defined as the fraction of windows where the episode occurs. Theoretically, given s and win, the sup-port degree of an episode (a) (i.e. MISs) for a single taint path j in s is
sup að Þ =jfaoccurs in vgj
W s, winð Þ
f g
j j ð1Þ
Once sup(a) is obtained, it can be used to predict the probability of an attack occurrence pijfor a single taint
path j from taint source i. In other words, sup(a) reveals the connections between attack events with MISs in the given security event sequence. Eventually, the normal behavioural profiles for apps are compared with the
calling sequence of MISs for a taint source to determine whether an app is vulnerable to a specific taint source.
Step 3.2: taint propagation analysis using the WSTA. Suppose a spanning tree T models the network flow for DTPA using graph theory. Here, T is an undirected graph G used to construct a tree, including all vertices and edges without any loop.
To evaluate the taint risk of DTPA, the probability of attack success for taint path pij(0 1) is assessed using equation (1). The defender must determine the normalised value of loss of taint propagation lj(0 1) and defence capability dj(0 1) of a taint path by con-sidering the attack–defence scenarios of networks in the following.
According to equation (2), the taint risk matrix was used to describe the probability of attack success for taint source i (i = 1,., m), which was caused by a set of security holes that generated taint paths j( j = 1,., n) by propagating taint and has the form
P = p ij mxn= p11 p12 p1j p1n p21 p22 .. . .. . .. . .. . .. . p33 .. . .. . .. . pij .. . .. . . . . ... pm1 pm2 pmj pmn 2 6 6 6 6 6 6 6 6 6 6 4 3 7 7 7 7 7 7 7 7 7 7 5 ð2Þ
Xi indicates that a taint source caused by a security hole exists in an app or cloud service, and ph(Xi) indi-cates that a defender has estimated the detection prob-ability of a security hole for a security test. Suppose a defender performed taint analyses and recorded the possible taint paths of propagation spread to examine the links between the occurring threat event Sj and security holes Ph(XijSj), which is assessed using equa-tion (1). Obviously, Ph(XijSj) is a posterior probability, and Sj, j = 1, . . . , n means that the threat events were produced by the spread of taint propagation. The prob-ability of attack success caused by security holes and their tainted data, Ph(SjjXi), can then be estimated by applying the Bayesian decision rule
pij= Ph SjjXi =Ph XijSj 3 Ph Sj Phð ÞXi ð3Þ
Table 3. Examples of the taint propagation rule.
Apk Taint source Module Calling sequence of MISs lottery.apk SubscriberId
service url
com.lotsynergy [Source:SubscriberId,Sink1:Landroid/telephony/TelephonyManager/getSubscriberId]
[Source:service,Sink1:Landroid/content/Intent]
[Source:url,Sink1:Ljava/net/URL/openConnection]
Figure 8. Determine the exact pattern of the taint propagation using sliding windows.
Ph(SjjXi) increases as the probability of both ph(Xi) and Ph(Sj) is increased. The process for dynamic taint track-ing ustrack-ing the WSTA is depicted in the followtrack-ing.
Initially, the WSTA ensures the connection between any two nodes of a network in which there is only a single path without a loop. The modelling of taint pro-pagation based on the connectivity of the information flow is then used to construct a spanning tree algo-rithm. In particular, a taint graph is constructed by aggregating spanning subtrees, which involve edges with weights. Theoretically, the graph must assign a greater weight to an edge when a high degree of the spread of taint propagation causes a series threat.
A defender assigns a weighted value to each edge at time t by considering the normalised ratio of the loss of data leaks for a single taint path to those for all taint paths for a specific threat in a taint graph G, as follows
wjð Þ =t ljð Þt Pn j=1 ljð Þt ð4Þ
In practice, the weight of a traversal path for a taint path must be updated by the continual spread of taint propagation along its path at time t+1, and this may increase the loss Dlj(t+1). Thus, when reconstructing the possible taint paths, the weight on the taint path is obtained using wjðt + 1Þ = ljðt + 1Þ + Dljðt + 1Þ Pn j = 1 ljð Þt ð5Þ
By contrast, the defence investment resources on each path against tainted data pass through that helps a defender to identify the total cost to secure the possi-ble taint paths. If the project time or defence resource is limited, the minimum spanning tree (MST) can be applied to determine the priority of guarding the taint path, thereby preventing maximum leaks to users using minimum resources. After defining the PRs for a taint source, the WSTA is used to identify the spread of taint propagation associated with the development of the TC tool.
Generally, two algorithms for the WSTA can be used: Dijkstra’s algorithm and Prim’s algorithm. The MST algorithm proposed by Dijkstra is used for identi-fying the shortest paths between nodes in a graph. It selects the unvisited vertex with the lowest distance, cal-culates the weights across it to each unvisited neigh-bour vertex and updates the neighneigh-bour’s weighting value if it is smaller. The vertex is marked as visited when the neighbour vertex is updated. By contrast, Prim’s algorithm is a greedy algorithm that identifies an MST for a weighted graph. It identifies a subset of edges that forms a tree including every vertex, and the
total weight of all the edges in the tree is minimised. The algorithm operates by building this tree one vertex at a time from an arbitrary starting vertex and at each step adding a low-cost possible connection from the tree to another vertex. In WSTA analysis, taint risk assessment is performed in the following.
DTPA was used to examine the various vulnerabil-ities in information systems, identify risks regarding tainted data propagation and resolve high-risk security concerns. The proposed model was designed to describe the SOE and estimate the risk of each taint path for selecting appropriate safeguards to defend against cyber attacks. In DTPA, the taint risk (ri) is
charac-terised using two quantities referring to the national vulnerability database (NVD) of common vulnerability scoring system (CVSS): (1) the probability of attack success for s single taint path j (pij) and (2) the loss of taint propagation (lj) caused by a set of security holes for a taint source i, which generates the possible taint paths j (j = 1,., n). The taint risk is obtained using
ri=
Xn
j = 1
pij3 lj ð6Þ
Step 3.3: determination of SOEs. The recognised secu-rity vulnerabilities of network apps have been investi-gated, examined and reported. For example, Mitre Corporation maintains a list of disclosed vulnerabilities in a system called common vulnerabilities and expo-sures (CVEs), in which vulnerabilities are scored using a CVSS.
The loss of data leaks may correlate closely to the spread of taint propagation. The SOEs indicate a set of possible attack profiles24caused by security holes for a taint source. In this study, the form for SOEs was defined as (IDj, CVE, taint source url, affected module
name and PRs) and was generated by collecting a set of PR, PRk, PRk + 1, PRk + 2, . for each taint source in
accordance with the behaviour analysis of malware. Once the PRs and SOEs were identified, they were used to distinguish whether the app was malicious or benign by comparing the differences in the signatures of mal-ware and legitimate apps. A detailed algorithm for tracking data with taint marking for dynamic propaga-tion analysis is described by Program Descrippropaga-tion Language (PDL) and shown in Figure 9.
Cyber security app
In this section, the applicability of the proposed TC analysis model is demonstrated by considering an example of cloud security using an open SDN-based smart home system (Figure 10). In constructing the SDN infrastructure layer, our experiment incorporated both Raspberry Pi and a wireless access point (AP)
with a set of management software tools including OpenWrt, Open vSwitch and Floodlight to construct an SDN-based smart home system, in which Floodlight serves as a supervisor to manage the SDN controller layer and application layer for detecting network anomalies in security monitoring. As Figure 10 illus-trates, Open vSwitch assists OpenFlow switches in communicating with each other using the OpenFlow protocol via a secure channel to connect the SDN con-troller. In the proposed SDN project, the SDN control-ler uses an Ryu SDN framework in an Ubuntu operation system to determine the network
configuration and network packet flow of network pro-cedures, such as access control, network traffic and security monitoring.
The smart home gateway is responsible for connec-tion to external communicaconnec-tions on the Internet. SDN applications for smart home scenarios with home secu-rity monitoring, lighting control and temperature and humidity monitoring were synchronised with three subnetworks: 192.168.1.0/24, 192.168.2.0/24 and 192.168.3.0/24. Each of these subnetworks commu-nicates via a Wi-Fi base station (wireless AP) with OpenFlow switches (Table 4).
In the proposed SDN system, security monitoring entails periodically collecting network statistics from OpenFlow switches and then applying classification algorithms to those statistics to detect any network anomalies. If an anomaly is detected, the application instructs the controller on how to reprogram the data plane to mitigate it.
In the experiment, the DTPA is constructed using the following three-step procedure involving the taint source analysis, malware behavioural analysis and DTPA on an android platform. For example, malware Zitmo (Zeus-in-the-mobile) Trojan attacks Android and Blackberry smartphones. As shown in Figure 11 and Table 5, Zitmo was found to have a connection to the command-and-control (C&C) server used in a bot-net, IP 224.0.0.251 for performing multicast Domain
Name System (DNS) queries by examining the traffic information of OpenFlow switch with taint sources.
In the experiment, the DTPA is constructed using the following three-step procedure involving the taint source analysis, malware behavioural analysis and DTPA on an android platform.
Step 1: Taint source analyses
Step 1.1: malware behavioural analyses. A total of 60 mal-ware families identified on mobile devices using active infections were obtained from blacklists pub-lished on the Dr Web and Contagio Blogger websites for an experiment conducted from February 2013 to February 2014. Initially, the suspected app (.apk) was downloaded from a smart device to both the Table 4. Experiment environment.
Role Hardware Software IP address
Smart home gateway TP-Link 841ND wireless AP OpenWrt + Open vSwitch 192.168.0.1 SDN controller A personal computer with
Intel Core i5 4210U 4-GB RAM
Ubuntu 14.04.3 + Floodlight 192.168.0.104 OpenFlow switch#1–3a Raspberry Pi 2 model B Raspbian + Open vSwitch 192.168.0.252–254
Wireless AP#1–3 TP-Link 841ND wireless AP OpenWrt + Open vSwitch 192.168.1.1, 192.168.2.1, 192.168.3.1
SDN: software-defined networking.
a
OpenFlow switch adopts an Ethernet-enabled USB interface wireless AP.
DroidBox9and the Androguard analysis platform. The experimental results of the behavioural analysis and code analysis of the mobile viruses are shown in Table 6. Defenders can verify the details of an attack sequence to obtain the possible attack profile.
Step 1.2: malicious activity analyses of taint sources. To ana-lyse the intent-based signature for taint source attacks and examine whether an app is vulnerable to special cyber attacks according to four protection levels, install the APP package file Android application package (APK) into the testing folder; execute TC tools, ComDroid, API_Monitor and Wireshark; examine ille-gal memory access; collect message passing to trace the taint source; inspect API call outputs; investigate taint paths for service, activity and receiver and broadcast com-munication among modules; and analyse binary interac-tions with the environment. An example of malicious activity analyses of a taint source is shown in Table 7.
In practice, the N-gram modelling scheme is used to obtain the more occurred API calls for MISs. We ran-domly examined 30 suspicious apps to examine the capability of vulnerability detection for ComDroid and API_Monitor in proposed SDN system, thereby deter-mining the common weaknesses of the apps. Consequently, ComDroid detected a total of 179 exploits, 49 warnings for exposed components and 353 warnings for exposed intents across 30 suspicious apps. In sum, the most occurred API calls associated with the relevant MISs for the 30 suspicious apps were obtained using analyse intent source, sink and broad-cast operations for Input/output (I/O), service, activity and communication, as shown in Table 8.
After defenders identify the calling API for MISs for the taint source, the attack profiles can be accumulated to perform TC analysis with the security holes.
Step 2: examining security holes in apps
In this step, two Valgrind-based analysis tools, Valgrind-3.9.0 for X86/Linux and X86/Android (4.0), were used to perform taint source analyses. Initially, Dedexer was used to disassemble DEX files; the Valgrind tool was then employed to record potential vulnerabilities for modules and intents, and Androguard was then used to confirm the results of Valgrind and to further track information flows between the attack sources (i.e. malware) and the possi-ble tainted data of targeted network apps to reveal the possible taint source, as illustrated in Figure 12.
Essentially, six types of test cases for control vari-ables of the module were examined using Valgrind: (1) invalid write, (2) conditioned jump on an uninitialised value, (3) memory boundary check for invalid read and write, (4) source and destination overlap, (5) inconsis-tencies between dynamic memory allocation and release and (6) memory leak. These test cases were examined by considering the taint policies of an organisation (Figures 13 and 14). For conducting a security check of network apps, Androguard can perform STA on the major activities (namely, MainActivity) for APPs to reveal the potential taint source.
Typically, two auxiliary tools in Androguard, dex2jar-0.0.9.15 and jd-gui, are used to disassemble the binary files and form the source code in which a folder contains classes.dex, a .APK file, a package and AndroidManifest.xml. The execution of tool./ Figure 11. An example of malicious activity analyses of a taint source with OpenFlow switches.
Table 5. Malicious activities for malware Zitmo.
Malware API call Infected module
Zitmo READ_PHONE_STATE (read phone state and identity) com/security/service/MainActivity ACCESS_NETWORK_STATE (view network status) com/security/service/MainActivity INTERNET (full Internet access) com/security/service/MainActivity WAKE_LOCK (prevent phone from sleeping) com/security/service/MainActivity
T able 6. Relationships betw een viruses and beha viours. Virus Beha viour Sent SMS Information leaks Aut hority ov erride Cir cumv ented permissions Started ser vice Br oadcast receiv er Op eration links Outbound traffic Inbound traffic Encr ypted API File read File write SMS Zombie 33 Chuli.A 33 3 3 Enesoluty 33 3 3 System security 33 3 3 3 3 Fak eGuar d 33 3 Sumzand 33 3 Fak eLook out 33 3 3 3 FinFish 3 3 Loozfon 33 3 3 Kranxpa y 33 3 3 3 3 3 Dr opdialer 33 3 3 Gonfu 33 3 3 3 3 FindandCall 33 3 3 Fak eInst.a 33 3 Qicsomos 33 3 Uxipp 3 T ascudap 3 Fak etok en.b 33 3 3 3 3 Scipiex 33 3 3 Gen.2 3 3 Fak eguar d 33 3 3 Startapp .5.origin 33 3 3 3 3 Monad.c 3 3 Andef.b 33 3 3 3 API: applica tion pr og ramming inte rface.
Table 7. Malicious activities for a taint source.
Taint source Module Operation Intent receiving communication
Activity sink Service sink Broadcast sink Pending intent sink DDreamLight com. Beauty.Leg-1.apk com/Beauty/Leg/lightdd/c handleMessage 1 1 com/Beauty/Leg/lightdd/Receiver onReceive 1 com/Beauty/Leg/lightdd/CoreService com/Beauty/Leg/lightdd/a/ onStart 1 com/Beauty/Leg/SexyImages/a Run 1 1 com/Beauty/Leg/SexyImages 1
Table 8. API calls for MISs with 30 taint sources.
API calls Number of API calls Types of instruction sets
Activity sink Service sink Broadcast sink Pending intent sink
Ljava/lang/Void 1 1 Ljava/util/List 1 1 Ljava/lang/Class 1 1 Landroid/net/Uri 1 1 Landroid/view/View 1 1 Landroid/view/MenuItem 1 1 Landroid/graphics/Bitmap 1 1 Landroid/content/ServiceConnection 1 1 Landroid/os/Message 3 3 Landroid/webkit/WebView 3 3 Landroid/content/DialogInterface 3 3 Landroid/app/Activity 5 5 Landroid/os/Bundle 11 8 2 1 Ljava/lang/String 14 8 1 1 5 Landroid/content/Intent 17 6 7 1 3 Landroid/content/Context 20 4 7 1 8
API: application programming interface; MIS: malicious instruction set.
dex2jar.sh generates the jar file for classes.dex. In the disassemble process, the tool jd-gui can unzip the jar file and obtain the source code. After analysing the source code, the hacker was observed to have set a thread in clService in the downloaded package for automatically reporting the associated information to a zombie using the HttpPost method (Figures 15 and 16).
Step 3: DTPA
In DTPA, the SOE of a taint source is characterised using three subprocesses: (1) correlation analysis for
MISs, (2) taint propagation analysis using an STA and (3) the determination of SOEs.
Step 3.1: correlation analysis for MISs. To identify the MISs of a taint source, the TC analysis tool ComDroid7was employed to analyse the statistical information of disas-sembled output from Dedexer and to log potential com-ponents and intent vulnerabilities. By using (3), detection probability of the MISs that appeared most for malicious behaviours were extracted from the collected file details.log regarding the intent creation and transmis-sion operations in component modules (Table 9).
Figure 13. Invalid write checking.
Step 3.2: taint propagation analysis using the WSTA. In this step, ComDroid was used with the WSTA to monitor tainted data for the following purposes: (1) inspect intent transmission from taint sources to the receiving module, (2) examine the intents of intermodule trans-mission and (3) determine whether the connected app and database are contaminated. In practice, ComDroid can track the intents of communications among apps by analysing the file details.log and listing information on activity, service and broadcast sink. Figure 17 illus-trates the analysis of suspicious links between malware and an app after the module received intents. A defen-der can click on allActions to examine the activity in detail (Figure 18).
A defender can apply the analysis results of ComDroid to conclude the rule of taint propagation on the basis of the frequent episode patterns of security event logs using equation (1) for a specific taint source. The PRs derived from the experiment are shown in Table 10.
After the formulation of PRs, DTPA tools can auto-matically correlate these PRs to perform taint propaga-tion analysis along with the possible taint paths. For example, for the APK:Geinimi-Banking Trojan invasion of cloud services (information available at www.ipay.com.cn), we downloaded samples from http://contagiominidump.blogspot.tw/2011/10/geinimi-banking-trojan-wwwipaycomcn.html to analyse the Figure 15. Security check of the main activity for network apps.
communication between Android apps and cloud ser-vices and then constructed a taint graph of information flow using the detail.log files derived from ComDroid associated with the WSTA (Figure 19). In setting the weights to an edge in a taint graph, a defender must consider the relative severity of data leaks. For exam-ple, a defender assigns a higher weight than that of mobile devices to the connection of a cloud server. The Kruskal MST algorithm was used to remove the taint-free source of information flow in communication and generate a new taint graph (Figure 20) to decide the priority of securing the taint paths.
Step 3.3: determination of SOEs. Vulnerabilities issued by United States Computer Emergency Readiness Team
(US-CERT) for an Android platform are listed in Table 11. The proposed model was designed to describe the SOE and estimate the risk of each taint path for selecting appropriate safeguards to defend against cyber attacks. Once the system vulnerabilities, taint paths and PRs are identified, the defender can form the SOEs for tracking taint paths between the malicious website and the detected vulnerabilities of targeted net-work apps. The form for SOEs is defined as (IDj, TS,
PRk, PRk + 1, PRk + 2,.), generated by collecting a set
of PRs in accordance with the taint sources and the rel-evant packages. Examples of the SOEs are shown in Table 12. Furthermore, the zombie infections for a taint source are located in Honeynet Map for manage-rial purposes.
Table 9. MISs of taint sources.
Malware Package name MISs
Smszombie 4d13d1bc63026b9c26c7cd4946b1bae0.apk SendTextRequest, SendTextMessage, SendBroadcast FakeGuard com.stech.stopphishing.apk onReceive, connMgr.getActiveNetworkInfo
com.stech.spamguard.apk com.stech.stopphishing.apk
MIS: malicious instruction set.
Figure 17. Application of ComDroid to inspect exposures between malware and an app.
Figure 18. Actions performed by the receiving intents in an app.
Table 10. Examples of the taint propagation rule.
ID Malware Taint source Package name Calling sequence of MISs 1 SMSsender.apk Sms_sent
SubscriberId
com.c101421042723 [Source:SubscriberId, Sink1:Landroid/telephony/ TelephonyManager/ getSubscriberId]
2 vksafe.apk File io SMS com.vksafe [Source:file io, Sink1:java/io/BufferedWriter/write, Sink2:com/ vksafe/WatcherService/openFileInput,Sink3:Ljava/io/
BufferedReader/readLine]
[Source:sms,Sink1: Landroid/telephony/SmsManager/ sendTextMessage]
Figure 19. Spanning tree approach for analysing the taint path.
Table 11. Vulnerabilities for an Android platform.
CVE Exploit pattern Release date Impact (10) CVSS score
CVE-2014-8609 Android settings application privilege leakage vulnerability 15 December 2014 10.0 High (7.2) CVE-2014-7911 Android \5.0 privilege escalation using ObjectInputStream 15 December 2014 10.0 High (7.2)
CVE: common vulnerability and exposure; CVSS: common vulnerability scoring system.
Table 12. Examples of SOEs.
ID Taint source Package name Propagation rule
1 com.c101421042723 SMSsender.apk [Source:SubscriberId, Sink1:Landroid/telephony/ TelephonyManager/getSubscriberId 2 com.lotsynergy lottery.apk [Source:SubscriberId,Sink1:Landroid/telephony/TelephonyManager/getSubscriberId]
[Source:service,Sink1:Landroid/content/Intent] [Source:url,Sink1: Ljava/net/ URL/openConnection]
3 com.vksafe vksafe.apk [Source:file io, Sink1:java/io/BufferedWriter/write, Sink2:com/vksafe/ WatcherService/openFileInput, Sink3: Ljava/io/ BufferedReader/readLine] [Source:sms,Sink1:Landroid/telephony/SmsManager/ sendTextMessage
SOE: signature of exploit.
Figure 21. Risk represented by loss of data leak and probability of attack success.
Discussion
The taint risk in the DTPA process is discussed in the following. Because of limited contexts available, the experiment data sample for smart home system is reported in Table 13. In Table 13, 10 taint sources were tested using websites blacklisted by Google, including the captured malware samples from Contagio Blogger. Notably, taint sources were identified as risks from attacks caused by security holes in the apps and smart living services; Figure 21 shows the links among the probability of attack success for a taint source, the loss
of possible spreads of the taint path and the taint risk. The results presented in Figure 22 show that the taint risk increases as both the degree of taint propagation and the loss of taint spread are increased. In addition, losses of tainted data propagation increase with an increasing degree of taint propagation but decrease with the defence capability. The high loss originated from the unsettled vulnerabilities that caused the spread of taint propagation represented by the number of PRs, which is associated with a low defence capabil-ity against taint propagation
Figure 22. Risks of a taint source with various spreads of taint propagation.
Table 13. Risks of a taint source with various spreads of taint propagation and impact. Taint path Probability of attack
success pij(0–1) Degree of taint propagation PRj(0–1) (number of PRs/ maximum number of PRs) Defence capability dj(0–1)
Loss of taint propagation for the taint path j, lj
Taint risk ri (3100%) j = 1 0.1 0.50 (4/8) 0.7 (MH) 0.714 71.4 (MH) j = 2 0.5 0.75 (6/8) 0.5 (M) 1.500 75.0 (MH) j = 3 0.9 1.00 (8/8) 0.9 (H) 1.110 99.9 (H) j = 4 0.5 0.250 (2/8) 0.3 (ML) 0.833 41.6 (M) j = 5 0.3 0.625 (5/8) 0.7 (MH) 1.071 32.1 (ML) j = 6 0.7 0.750 (5/8) 0.5 (M) 1.250 87.5 (H) j = 7 0.5 0.500 (4/8) 0.5 (M) 1.000 50.0 (M) j = 8 0.9 0.375 (3/8) 0.5 (M) 0.750 67.5 (MH) j = 9 0.7 0.250 (2/8) 0.5 (M) 0.500 35.0 (ML) j = 10 0.3 0.875 (7/8) 0.7 (MH) 1.250 37.5 (ML) PR: propagation rule.
The degree of taint propagation is calculated by converting individual value of PRs to normalised score and the defence capability is scored on a typical 5-point Likert scale, low(L) [0, 0.2), medium low (ML) [0.2, 0.4), medium (M) [0.4, 0.6), medium high (MH) [0.6, 0.8) and high(H) [0.8, 1.0].
lj= 8 j PRj dj ð7Þ
Conclusion
This article proposes a threat analysis model for solving the mobile security problem by performing in-depth behavioural analysis on the ComDroid platform to indicate the attack profile for malware infection, con-sidering both code analysis and behaviour analysis for program vulnerabilities in a smart home system. In the proposed model, an improved DTPA scheme was obtained by revising the approach in Newsome and Song4 and used as an enhancement method for the DTA of cloud security. Our scheme enables a defender to convert the spread of possible taint paths to loss and practically estimate the risk of a specific threat. Additionally, the proposed scheme not only considers the taint source, PRs and SOEs from tainted data to system vulnerability but also estimates the losses when tainted data are propagated. Consequently, the pro-posed method improves the defence reactions to a risk associated with the evolution of a system’s security con-cerns and assists defenders in making appropriate deci-sions when tracing possible taint sources.
Declaration of conflicting interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author(s) disclosed receipt of the following financial sup-port for the research, authorship, and/or publication of this article: This work was supported jointly by TWISC@NCKU and the Ministry of Science and Technology of Taiwan under grant nos MOST 104-2632-E-168-001, MOST 104-2218-E-001-002 and MOST 105-2410-H-168-002.
References
1. Wikipedia. Taint checking, http://en.wikipedia.org/wiki/ Taint_checking
2. Portokalidis G, Slowinska A and Bos H. Argos: an emu-lator for fingerprinting zero-day attacks for advertised honeypots with automatic signature generation. SIGOPS Op Syst Rev2006; 40(4): 15–27.
3. Yin H, Song D, Egele M, et al. Panorama: capturing sys-tem wide information flow for malware detection and analysis. In: Proceedings of the 14th ACM conference on computer and communications security, Alexandria, VA, 29 October–2 November 2007, pp.116–127. New York: ACM.
4. Newsome J and Song D. Dynamic taint analysis for automatic detection, analysis, and signature generation
of exploits on commodity software, 2005, http://valgrind. org/docs/newsome2005.pdf
5. Wang P, Chao KM, Lo CC, et al. Using dynamic taint approach for of malware threat. In: IEEE international conference on e-business engineering, Beijing, China, 23–25 October 2015, pp.408–416. New York: IEEE. 6. Valgrind, http://valgrind.org/docs/manual/dist.news.html 7. Chin E, Felt AP, Greenwood K, et al. Analyzing inter-application communication in Android. In: Proceedings of the 9th international conference on mobile systems (MobiSys2011), Bethesda, MD, 28 June–1 July 2011, pp.239–252. New York: ACM.
8. Desnos A. Androguard, http://code.google.com/p/ androguard/wiki/Usage
9. The Honeynet project. Droidbox, 2012, http://www. honeynet.org/gsoc/slot11
10. McClurg J, Friedman J and Ng W. Android privacy leak detection via dynamic taint analysis, Northwestern Uni-versity, Evanston, IL, 2013, http://www.jrmcclurg.com/ papers/internet_security_final_report.pdf
11. Balakrishnan G and Reps T. WYSINWYX: what you see is not what you eXecute. ACM Trans Program Lang Syst 2010; 32(6): 1–84.
12. Enck W, Gilbert P, Chun BG, et al. Taintdroid: An infor-mation-flow tracking system for realtime privacy moni-toring on smartphones. In: Proceedings of the 9th Usenix symposium on operating systems design and implementa-tion, 2010, pp.393–408.
13. Kim HC, Keromytis AD, Covington M, et al. Capturing information flow with concatenated dynamic taint analy-sis. In: Proceedings of international conference on avail-ability, reliability and security, Fukuoka, Japan, 16–19 March 2009, pp.355–362. New York: IEEE.
14. Rastogi V, Chen Y and Enck W. AppsPlayground: auto-matic security analysis of smartphone application. In: Proceedings of the third ACM conference on data and application security and privacy (CODASPY13), San Antonio, TX, 18–20 February 2013, pp.209–220. New York: ACM.
15. Open Networking Foundation. Software-defined net-working: the new norm for networks. ONF White Paper, 13 April 2012, https://www.opennetworking.org/images/ stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf
16. Braga R, Mota E and Passito A. Lightweight DDoS flooding attack detection using NOX/OpenFlow. In: IEEE 35th conference on local computer networks (LCN), Denver, CO, 10–14 October 2010, pp.408–415. New York: IEEE.
17. Giotis K, Argyropoulos C, Androulidakis G, et al. Com-bining OpenFlow and sFlow for an effective and scalable anomaly detection and mitigation mechanism on SDN environments. Comput Netw 2014; 62: 122–136.
18. Jin R and Wang B. Malware detection for mobile devices using software-defined networking. In: Proceedings of the 2013 second GENI research and educational experiment workshop (GREE), Salt Lake City, UT, 20–22 March, pp.81–88. New York: IEEE.
19. Feamster N. Outsourcing home network security. In: Proceedings of the 2010 ACM SIGCOMM workshop on
home networks, New Delhi, India, 3 September, pp.37–42. New York: ACM.
20. Kreutz D, Ramos FMV and Verı´ssimo P. Towards secure and dependable software-defined networks. In: Proceed-ings of the second ACM SIGCOMM workshop on hot topics in software defined networking (HotSDN), Hong Kong, China, 16 August 2013.
21. TEMU, http://bitblaze.cs.berkeley.edu/temu.html 22. Tripp O, Pistoia M, Fink SJ, et al. TAJ: effective taint
analysis of web applications. In: Proceedings of the 30th ACM SIGPLAN conference on Programming language
design and implementation, Dublin, 15–20 June 2009, pp.87–97. New York: ACM.
23. Mannila H, Toivonen H and Verkamo IA. Discovery of frequent episodes in event sequences. Data Min Knowl Disc1997; 1(3): 259–289.
24. Chad WA, Bamshad M and Robin B. Defending recom-mender systems: detection of profile injection attacks. Serv Oriented Comput Appl2007; 1(3): 157–170.
25. Contagio malware dump, http://contagiodump. blogspot.tw (accessed February 2015).
