CN111783092A - Malicious attack detection method and system for communication mechanism between android applications - Google Patents

Malicious attack detection method and system for communication mechanism between android applications Download PDF

Info

Publication number
CN111783092A
CN111783092A CN202010572689.0A CN202010572689A CN111783092A CN 111783092 A CN111783092 A CN 111783092A CN 202010572689 A CN202010572689 A CN 202010572689A CN 111783092 A CN111783092 A CN 111783092A
Authority
CN
China
Prior art keywords
intent
model
receiver
sender
icc
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202010572689.0A
Other languages
Chinese (zh)
Other versions
CN111783092B (en
Inventor
胡玉鹏
金哲
郭亮
冯小博
黄芸
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hunan University
Original Assignee
Hunan University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hunan University filed Critical Hunan University
Priority to CN202010572689.0A priority Critical patent/CN111783092B/en
Publication of CN111783092A publication Critical patent/CN111783092A/en
Application granted granted Critical
Publication of CN111783092B publication Critical patent/CN111783092B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55Detecting local intrusion or implementing counter-measures
    • G06F21/56Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/566Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/546Message passing systems or structures, e.g. queues

Abstract

The invention discloses a malicious attack detection method and system for a communication mechanism between android application programs, wherein an application program file is operated to obtain an operation log; analyzing the application package and the running log, constructing an ICC (inter-component communication) model, and detecting the attack behavior in the ICC model. The method can accurately detect the control flow and the data flow in the communication process between the android applications, construct the communication model and detect the attack behavior in the model, and has more detected attack types and higher detection accuracy.

Description

Malicious attack detection method and system for communication mechanism between android applications
Technical Field
The invention relates to a detection technology for attacks existing in the communication process between android applications.
Background
In recent years, we have witnessed an explosive growth in the number of mobile devices, and the large number of diverse mobile applications on these mobile devices has made our daily lives more convenient. However, with the rapid growth of mobile applications, which have become more and more the target of mobile malware authors, they often develop and distribute mobile malware with the aim of stealing and disclosing various sensitive and valuable information related to mobile users or devices, such as credit card numbers, real-time geographical locations and IMEI numbers, etc. Malware has become one of the most significant security threats to mobile operating systems, especially the android system.
In the android system, applications run in sandboxes that are isolated from each other. When communication is needed between applications, the applications utilize an inter-component communication mechanism (hereinafter ICC) to communicate messages and to launch components, and the carrier communicated between the components is an encapsulated Intent (carrier for inter-component communication) class. While this flexible approach makes a great contribution to function multiplexing and data sharing, it also exposes vulnerable sites to a variety of security attacks.
When developers neglect security issues under the ICC mechanism, applications often suffer from risk vulnerabilities such as Intent (i.e., Intent) hijacking and spoofing, resulting in sensitive user data leakage, privilege elevation, and launching of private components. As shown in FIG. 1, from the Victim application Vistim, an intent is sent from component A to component B. While malicious application Malware1 hijacks an intent sent from component A to component B, this process is called intent hijacking. Malicious application Malware1 forges intent sent from component A to component B and was issued by component D to component B, a process known as intent spoofing. In addition, two or more malicious applications can also utilize the mechanism to cooperate with each other to jointly complete an attack behavior, and the attack behavior is disguised as a common message exchange behavior by utilizing the ICC mechanism and is difficult to perceive. As shown in fig. 1, a malicious application, maliware 1, obtains location information, a component D sends the location information to a component E of maliware 2 through an ICC mechanism, and maliware 2 sends the location information to a remote attacker, which is called collusion attack of an application program.
The malicious application attacked by the ICC mechanism can expose attack behaviors only when the malicious application and an attack object run together, and the main malicious application detection method can not discover the attack behaviors only by analyzing one application during detection, so that the malicious application can often bypass the detection easily.
Many existing static ICC-based static program analysis focus on detecting attack planes in benign applications, only identifying possible exploited vulnerabilities. None of these techniques provide any solution for identifying malicious applications using ICC tunnels. Most recent research work to study ICC vulnerabilities has been divided into two parts: static analysis and dynamic operation protection. Static analysis typically extracts sensitive ICC paths by matching intent filters and tracing the data stream, while analyzing two or more applications (e.g., IC3, amandloid, DIALDroid) simultaneously. Even the most advanced of them suffer from a large number of false positives. Besides the inherent limitations of static analysis when encountering reflective and inaccessible codes, the false alarm has the great influence of neglecting the verification of the data format. Ignoring the verification of data formats, these analysis techniques recognize many coincidental or common behaviors as malicious behaviors. Dynamic operation protection techniques (e.g., xmanddroid, seamount, SCLib) will enforce mandatory access control according to a predefined set of policies or ask the end user for access permission decisions when applications communicate with each other based on intent mechanisms. But the dynamic run protection technique only checks the attributes of intent, which can result in a large number of false alarms, and it directly prohibits the application from receiving intent regardless of the behavior of the application that accepts intent. In general, it only focuses on what happened before the intent received, not the entire process, and does not provide any solution for identifying malicious applications.
Disclosure of Invention
The invention aims to solve the technical problem that aiming at the defects of the prior art, the invention provides a malicious attack detection method and system facing to a communication mechanism between android applications, and the detection precision of the malicious attack is improved.
In order to solve the technical problems, the technical scheme adopted by the invention is as follows: a malicious attack detection method for a communication mechanism between android applications comprises the following steps:
s1, operating the application program file to obtain an operation log;
and S2, analyzing the application package and the running log, constructing an ICC model, and detecting the attack behavior in the ICC model.
Through the steps, the invention can identify the attack behavior existing in the specific process of communication between applications, and the accuracy of malicious attack detection is high.
The specific implementation process of step S1 includes:
1) when an application program acquires sensitive data, marking a stain for the sensitive data, and outputting stain information in a running log;
2) identifying the sensitive data when the application program constructs Intent, re-marking the stain, and outputting the re-marked stain information in a running log;
3) when the application program sends Intent, determining a sender of the Intent, determining a receiver of the Intent, and outputting the information of the sender and the receiver in a running log;
4) detecting parameters input into each sensitive method, if the parameters are polluted and the parameters are sensitive data which are marked as taints again in the step 2), determining that the parameters are transmitted through intent, and outputting information such as sensitive method names and taint data of the detected taint data in a running log.
The information required by the analyzer to build the model can be obtained through the above steps.
The specific implementation process of step S2 includes:
A) extracting information in the running log, and constructing a plurality of ICC models consisting of a Sender (namely an assembly for sending Intent), Intent and a Receiver (namely an assembly for receiving Intent) by utilizing the extracted information;
B) correcting real sensitive data sources in all ICC models, and removing redundant models;
C) possible attack behaviors are identified in the ICC model after the redundancy model is removed.
Through the steps A) -C), the whole communication process of the application operation can be accurately restored, and the attack behavior in the communication process can be identified.
The specific implementation process of the step A) comprises the following steps: extracting application program file information by analyzing the application program file; filtering irrelevant logs from an Android (Android) system and other application programs according to the application program file information; the remaining logs are read and information related to Intent is extracted, and the analyzer reads each filtered log and extracts information related to Intent, which can be used to build the ICC model. The method comprises the steps of extracting taint data in the Intent, sending an Intent component, Intent attributes (including action, categories and the like), matching the Intent component, receiving the Intent component and utilizing points of Intent propagation data from logs, obtaining all attributes of an Intent object, a process number, an application program name, a source method of sensitive data and candidate component attributes in a Sender, a process number, an application program name, a sensitive data using method and starting component attributes in a Receiver. Determining the required authority in the Sender according to the authority required by the polluted data in the intent, and determining the attribute of the authority required by the Receiver in the model according to the authority required by the sensitive method used in the Receiver. The authority required by the attribute Sender missing in the authority of the Receiver is the missing authority in the Receiver object; and determining the required permission in the Receiver according to the use condition of the taint data in the Receiver, wherein the attribute of the missing permission of the Sender is a collection of the permissions which do not comprise the required permission of the Receiver in all the permissions of the Sender. The communication process is constructed into a specific model, so that malicious attacks can be conveniently detected.
In order to filter out redundant and internal communication models and further improve the malicious attack detection efficiency, in step B), the specific implementation process of correcting the true sensitive data source in the ICC model includes: and constructing an ordered model list according to components in Sender (i.e. Sender) and Receiver (i.e. Receiver), traversing each ICC model, comparing the taint and the taint source in each ICC model, and determining and correcting the taint source corresponding to the taint in the ICC model.
In the step B), the specific implementation process for removing the redundancy model comprises the following steps: intermediate models between ICC models and communication models inside the application are removed.
The specific implementation process for removing the intermediate model between the ICC models comprises the following steps: if model A (a model with Intent sending application as sender and Intent receiving application as receiver) and model B (a model with Intent activity as sender and Intent receiving application as receiver) are generated, models A and B are reduced to a model with Intent sending application as sender and Intent receiving application as receiver. In step C), the specific implementation process for identifying the possible attack behavior in the ICC model after removing the redundant model includes:
iterating all components in the sender application, and checking whether a component list of the candidate receiving intent contains components from the sender application; if yes, the attack type of the ICC model is determined to be Intent hijacking;
if the sender has the authority related to the sensitive method in the receiver and the data in the Intent used by the sensitive method exists in the receiver, the attack type existing in the ICC model is considered to be Intent hijacking;
if the sender lacks the authority required by the receiver to call the sensitive method in the ICC model, and the receiver obtains the permission for the data from the sender, the sender is considered to send intent for deceiving the receiver, and the attack threat in the ICC model is intent deception;
when the receiver component starts the private component and the receiver does not lack the authority for generating data from the sender, the sender is considered to deceive the receiver, and the attack type of the ICC model is Intent deception;
if the sender lacks the authority required by the receiver to call the sensitive method and the receiver also lacks the data for generating the authority from the sender, the sender and the receiver are considered to carry out collusion attack through an ICC mechanism, and the attack type in the ICC model is collusion.
The identification process considers 5 different conditions, the conditions cover all attack types aimed by the invention, and each model is traversed, so that the best matching condition can be found, the attack behavior in each communication model is detected, and the detection precision is further improved.
The invention also provides a malicious attack detection system facing the communication mechanism between the android applications, which comprises the following steps:
the monitor is used for running the application program file to obtain a running log;
and the analyzer is used for analyzing the application program package and the running log, constructing an ICC model and detecting the attack behavior in the ICC model.
The monitor of the present invention comprises:
the system comprises a first marking unit, a second marking unit and a control unit, wherein the first marking unit is used for marking a stain for sensitive data when an application program acquires the sensitive data and outputting stain information in a running log;
the second marking unit is used for identifying the sensitive data when the application program constructs Intent, re-marking the stain and outputting the re-marked stain information in a running log;
the Intent determining unit is used for determining a sender of the Intent, determining a receiver of the Intent and outputting the information of the sender and the receiver in a running log when the application program sends the Intent;
and the detection unit is used for detecting the parameters of the input sensitive methods, determining that the parameters are transmitted through intent if the parameters are polluted and the parameters are sensitive data marked as stains again by the second marking unit, and outputting the information such as the name of the sensitive method and the stain data of the detected stain data in a running log.
The analyzer includes:
the extraction unit is used for extracting information in the running log and constructing a plurality of ICC models consisting of a Sender, an Intent and a Receiver by using the extracted information;
the correcting unit is used for correcting the real sensitive data sources in all ICC models and removing the redundant models; and the identification unit is used for identifying possible attack behaviors in the ICC model after the redundant model is removed.
Compared with the prior art, the invention has the beneficial effects that:
the method can accurately detect the control flow and the data flow in the communication process between the android applications, construct the communication model and detect the attack behavior in the model, and has more detected attack types and higher detection accuracy.
Drawings
Fig. 1 shows three attack models.
Fig. 2 shows the monitor monitoring step.
Fig. 3 shows the analyzer modeling process.
FIG. 4 shows a communication process between multiple components of multiple applications.
Detailed Description
The invention discloses a malicious attack detection method for a communication mechanism between android applications, which mainly comprises the following two steps: the first step is to run the application program file in a monitoring sandbox (hereinafter referred to as a monitor) and obtain a running log; and the second step is to analyze the application program package and the running log by using an analyzer module, construct an ICC model and detect the attack behavior in the ICC model.
Firstly, running an application program file in a monitor, wherein the main implementation process is as follows:
and installing the application program to be tested in the monitor, and triggering the behavior of the application program in the monitor by writing a corresponding script or manually.
The monitor module is an extension of an android operating system, checks related components on an ICC path and data streams associated with Intent when an application runs, and acquires related information of Intent at several key points of an ICC process, including components for sending Intent, components for matching Intent, and the like. In addition, the monitor module utilizes dynamic taint analysis techniques to identify: (a) whether there is sensitive data to be transferred from the sender application to the recipient application via the intent, and (b) whether the sensitive data is used by the recipient, including recording, sending, etc. Fig. 2 shows the monitoring step of the monitor, which is detailed as follows:
in a first step, the monitor marks sensitive data with a smudge when the application acquires the sensitive data.
When an application program acquires sensitive data in a device, the sensitive data sources are marked as taints through a dynamic taint analysis method, and the marked sensitive data sources mainly relate to some api about user privacy and information input by a user, such as (contact persons, address information, mobile phone state information and the like).
In the second step, the monitor identifies the sensitive data and relabels the taint when the application builds Intent.
When an application program constructs Intent, if the sensitive data acquired in the last step is used, the monitor detects the transmitted parameters in the construction method of the Intent, and identifies the attribute of the sensitive data through the taint carried by the sensitive data to determine whether the Intent carries the sensitive data and what the sensitive data is. If Intent carries sensitive data, the sensitive data that has been tainted is re-tainted in order to be able to trace that taint data came from Intent when the sensitive data is detected in the application that received the Intent. If sensitive data in the parameters that build Intent are not contaminated, taint is added to these parameters indicating that this is non-sensitive data from Intent.
And thirdly, when the application program sends the Intent, the monitor determines the sender of the Intent.
When an application sends an intent to another application or component, the monitor captures the event sent and the object from which the event originated. An application can call an API (intent) to send an intent in the inheritance classes of components Activity, Service, and Broadcast. The API for sending the intent in the Activity, Service and Broadcast calls the API by inheriting the ContextWrapper class or acquiring the ContextWrapper object, so that the object for calling the API, the related attribute of the object and the attribute information (e.g. action, category and type) of the intent can be acquired in the ContextWrapper class by a reflection method. Thus, the monitor captures the send event of the intent and obtains the relevant information of the sender by monitoring in the ContextWrapper class.
And fourthly, the monitor determines the receiver of the intent.
After capturing the sent event of the intent, it needs to determine which component attribute matches successfully become the candidate for receiving, and finally which component becomes the receiver and receives the intent. In the android system, a PackageManageService (PMS) is responsible for querying the component that best matches Intent by traversing all the components of the applications in the system. When the receiving component is of Activity and Service type, if a plurality of components are all in accordance with the condition, the best component is selected to receive according to the priority, the default condition and the like. And finally, when the only meeting condition cannot be obtained, the Activity pops up a prompt box to the user for selection, and the Service defaults to the first candidate of all the candidates. When the recipient is Broadcast, the intent is sent to all conforming components. Therefore, the monitor monitors all candidate components matching the meeting intent and the components that ultimately accept the intent in the PMS.
And fifthly, monitoring the privacy data of the intent receiver in the processing of the intent by the monitor.
The monitor detects incoming parameters in various sensitive methods (including log out, exporting to a file, sending a short message, storing in shareference, etc.). If the parameter has been contaminated and the taint corresponds to a characteristic of the sensitive data that has been contaminated after the recontamination in the second step, the monitor can determine that the parameter has propagated through the intent to that point, indicating that the recipient application processed the sensitive data from the intent using the sensitive method.
And secondly, analyzing the application program package and the running log by using an analyzer module, constructing an ICC model and detecting the attack behavior in the ICC model. The analyzer builds an ICC model from information obtained by the monitor and information extracted from an APK (application package) file, and then identifies attack behavior by matching the model to rules. Finally, the analyzer distinguishes malware from benign applications. It can be refined into three steps: (1) building a model, (2) normalizing the model, and (3) identifying aggressive behavior in the ICC model.
In the first step, the analyzer builds a model by analyzing the log and the application package.
The model constructed (the process of construction is the process of extracting information from the application and the APK) is composed of 3 objects including Sender, Intent and Receiver. FIG. 3 illustrates details of the model. The parser first extracts information, such as package name and authority of each application, by parsing the APK file. The package name helps the parser to obtain the process number of the application, which is the unique identifier assigned to each application by the android system. Each log contains a process number associated with the application that generated the log. Second, based on the process number, the analyzer filters irrelevant logs from the android system itself and other applications, and only keeps logs related to applications that are of interest to the user. Third, the analyzer reads each filtered log and extracts information about Intent, which can be used to build the ICC model. The method comprises the steps of extracting taint data in the Intent, sending an Intent component, Intent attributes (including action, categories and the like), matching the Intent component, receiving the Intent component and utilizing points of Intent propagation data from logs, obtaining all attributes of an Intent object, a process number, an application program name, a source method of sensitive data and candidate component attributes in a Sender, a process number, an application program name, a sensitive data using method and starting component attributes in a Receiver. The rights-related properties in the model require more work. The analyzer identifies the authority attribute required by the Sender as the required authority in the Sender according to the authority required by the polluted data in the intent. The property of the rights missing in Receiver is the rights required to implement the Receiver method. And determining the required authority in the receiver according to the use condition of the taint data in the receiver. The attribute of the missing rights of a Sender is a collection (set) of rights required by a Receiver not included in all the rights of the Sender.
TABLE 1 ICC (Intercomponent Communication) model
Figure BDA0002550211650000091
And secondly, normalizing the ICC model of the analyzer, wherein the normalization is mainly used for correcting a real sensitive data source in the ICC model and removing a redundant model.
The profiler will use the log from the API (for sending intent) to start the test of the entire ICC process. Whenever the parser reads a log of sending intent from the API, it ends the current inter-component communication process and begins building a new log. However, if we are only concerned with the component that sends or receives intent, in the case shown in FIG. 4, three models A, B and C are constructed. However, this is clearly wrong, since the source of the contaminated sensitive data (e.g., T-data) is not in the component that sent the intent. In Model B and Model C, the sources of T-data are considered to be C2 and C3, respectively, but it is concluded that the sources are both C1 located in Model A. Therefore, after temporarily partitioning the four components into three models, the analyzer must find the true source and true sink of the data in intent in models B and C. Therefore, the analyzer firstly constructs an ordered model list according to components in the Sender and the Receiver, then traverses each model and compares the target label to identify the source in the Sender and the sink in the Receiver, and finds out whether the Receiver starts a private component after obtaining the intent.
After extracting the information of the inter-component communication model, it is noted that the analyzer needs to exclude some unnecessary interference models. The model used by the android system to launch applications is independent of us. If the type of the recipient component is active and there are multiple components that match the intent property, then the android system will pass intent to ResolverActivity (Activity selector) for the user to select the desired component. After the user selects the target component, ResolverActivity then sends intent, rather than the sender application. This process will generate two models, which are a model with the sending application as the sender and the resolving activity as the Receiver, and a model with the resolving activity as the sender and the receiving application as the Receiver, respectively. The analyzer reduces the two models into a model with the sender of the sending application and the receiver of the receiving application.
In addition, the analyzer removes the model that occurs inside the application, i.e., the sender and receiver belong to the same application.
And thirdly, identifying the attack behavior in the ICC model.
Possible attack behavior in the ICC model is identified after all models are built. The detection algorithm takes into account 5 different cases that cover all attack types for which the invention is directed and traverses each model to find the best match.
Case 1: and iterating all the components in the sender application, and checking whether the component list of the candidate receiving intent contains the components from the sender application. If so, the attack type of the ICC model is assumed to be Intent hijacking, in which case we assume that the instance in FIG. 1 is occurring and that the component from the sender application in the candidate component should be the destination of Intent, so the receiver component hijacks Intent that should be sent to another component.
Case 2: and if the sender has the authority related to the sensitive method in the receiver and the data in the Intent used by the sensitive method exists in the receiver, considering that the attack type Intent existing in the ICC model is hijacked. After the receiver acquires data from the intent, the sensitive method uses the data, which means that the receiver acquires private data from the sender by acquiring the intent, and the sender does not lack the authority related to the sensitive method in the receiver, in this case, the receiver is considered to hijack the intent sent by the sender.
Case 3: if sender lacks the authority required by receiver to call sensitive method in ICC process, and receiver does obtain permission for data from sender, we think that sender sends intent for deceiving receiver, and attack threat in the ICC model is intent deception. In this case, the sender spoofs the receiver to perform an operation that the sender cannot perform because it lacks the necessary rights.
Case 4: when the receiver component starts the private component and the receiver does not lack the right to generate data from the sender, we consider that the sender spoofs the receiver, and the attack type of the ICC model is Intent spoofing. In this case, the sender calls the private component through other public components, and does not simultaneously perform any illegal action.
Case 5: if the sender lacks the authority required by the receiver to call the sensitive method, the receiver also lacks the data for generating the authority from the sender. We consider these two applications collude to launch attacks through the ICC mechanism, the type of attack in this ICC model is collusion. They upgrade privileges to each other through inter-component communication procedures and complement rights to each other, which is a typical example of an intent collusion attack.

Claims (10)

1. A malicious attack detection method for a communication mechanism between android applications is characterized by comprising the following steps:
s1, operating the application program file to obtain an operation log;
and S2, analyzing the application package and the running log, constructing an ICC model, and detecting the attack behavior in the ICC model.
2. The method for detecting the malicious attack to the inter-android-application-program communication mechanism according to claim 1, wherein the specific implementation process of the step S1 includes:
1) when an application program acquires sensitive data, marking a stain for the sensitive data, and outputting stain information in a running log;
2) identifying the sensitive data when the application program constructs Intent, re-marking the stain, and outputting the re-marked stain information in a running log;
3) when the application program sends Intent, determining a sender of the Intent, determining a receiver of the Intent, and outputting the information of the sender and the receiver in a running log;
4) detecting parameters input into each sensitive method, if the parameters are polluted and the parameters are sensitive data which are marked as taints again in the step 2), determining that the parameters are transmitted through Intent, and outputting information such as sensitive method names and taint data of the detected taint data in a running log.
3. The method for detecting the malicious attack to the inter-android-application-program communication mechanism according to claim 1, wherein the specific implementation process of the step S2 includes:
A) extracting information in the running log, and constructing a plurality of ICC models consisting of a Sender, an Intent and a Receiver by using the extracted information;
B) correcting real sensitive data sources in all ICC models, and removing redundant models;
C) possible attack behaviors are identified in the ICC model after the redundancy model is removed.
4. The method for detecting the malicious attack of the communication mechanism between the android applications as claimed in claim 3, wherein the specific implementation process of the step A) comprises: extracting application program file information by analyzing the application program file; according to the file information of the application program, irrelevant logs from the android system and other application programs are filtered; reading the remaining logs and extracting information related to Intent, the analyzer reading each filtered log and extracting information related to Intent; extracting taint data in the Intent, a component for sending the Intent, an Intent attribute, a component for matching the Intent, a component for receiving the Intent and a utilization point of the Intent transmission data from a log, and acquiring all attributes of an Intent object, a process number, an application program name, a source method of sensitive data, a candidate component attribute in a Sender, a process number, an application program name, a sensitive data using method and a starting component attribute in a Receiver; determining the required authority in the Sender according to the authority required by the polluted data in the Intent, determining the attribute of the authority required by the Receiver in the model according to the authority required by the sensitive method used in the Receiver, wherein the authority required by the attribute Sender missing in the authority of the Receiver is the missing authority in the Receiver object; determining the required authority in the Receiver according to the use condition of the taint data in the Receiver, wherein the attribute of the missing authority of the Sender is a collection of all the authorities of the Sender, which does not include the authority required by the Receiver.
5. The method for detecting the malicious attack of the communication mechanism between the android applications as claimed in claim 3, wherein in the step B), the specific implementation process for modifying the real sensitive data source in the ICC model comprises: and constructing an ordered model list according to the assemblies in the Sender and the Receiver, traversing each ICC model, comparing the taint and the taint source in each ICC model, and determining and correcting the taint source corresponding to the taint in the ICC model.
6. The method for detecting the malicious attack of the communication mechanism between the android applications as claimed in claim 3, wherein in the step B), the specific implementation process for removing the redundancy model comprises: intermediate models between ICC models and communication models inside the application are removed.
7. The method for detecting the malicious attack of the communication mechanism between the android applications as claimed in claim 6, wherein the specific implementation process of removing the intermediate model between the ICC models by combining application runtime monitoring and analysis detection comprises: if the model A and the model B are generated, simplifying the model A and the model B into a model with a sending application as a Sender and a receiving application as a Receiver; the model A is a model taking Intent sending application as a sender and resolution activity as a Receiver; model B is a model with resolution activity as Sender and Intent receiving application as Receiver.
8. The method for detecting the malicious attack of the communication mechanism between the android applications as claimed in claim 3, wherein in the step C), the specific implementation process for identifying the possible attack behavior in the ICC model after the redundancy model is removed comprises:
iterating all components in the Sender application, and checking whether the component list of the candidate receiving Intent contains the components from the Sender application; if yes, the attack type of the ICC model is determined to be Intent hijacking;
if the Sender has the authority related to the sensitive method in the Receiver and data in the Intent used by the sensitive method exists in the Receiver, the attack type existing in the ICC model is considered to be Intent hijacking;
if the Sender lacks the authority required by the Receiver to call the sensitive method in the ICC model, and the Receiver obtains permission for the data from the Sender, the Sender is considered to send Intent for deceiving the Receiver, and the attack threat in the ICC model is Intent deception;
when the Receiver component starts a private component and the Receiver does not lack the authority for generating data from the Receiver, the Receiver is considered to be deceived by the Receiver, and the attack type of the ICC model is Intent deception;
if the Sender lacks the authority required by the Receiver to call the sensitive method and the Receiver also lacks the data for generating the authority from the Sender, the Sender and the Receiver are considered to carry out collusion attack through an ICC mechanism, and the attack type in the ICC model is collusion.
9. A malicious attack detection system oriented to an inter-android-application communication mechanism is characterized by comprising:
the monitor is used for running the application program file to obtain a running log;
and the analyzer is used for analyzing the application program package and the running log, constructing an ICC model and detecting the attack behavior in the ICC model.
10. The inter-android-application-communication-mechanism-oriented malicious attack detection system of claim 9, wherein the monitor comprises:
the system comprises a first marking unit, a second marking unit and a control unit, wherein the first marking unit is used for marking a stain for sensitive data when an application program acquires the sensitive data and outputting stain information in a running log;
the second marking unit is used for identifying the sensitive data when the application program constructs Intent, re-marking the stain and outputting the re-marked stain information in a running log;
the system comprises an Intent determining unit, a log processing unit and a log processing unit, wherein the Intent determining unit is used for determining a sender of Intent and a receiver of Intent when the application program sends the Intent, and outputting information of the sender and the receiver in a running log;
the detection unit is used for detecting the parameters of each input sensitive method, determining that the parameters are transmitted through Intent if the parameters are polluted and the parameters are sensitive data marked as stain again by the second marking unit, and outputting the information such as the name of the sensitive method and the stain data of the detected stain data in a running log;
preferably, the analyzer comprises:
the extraction unit is used for extracting information in the running log and constructing a plurality of ICC models consisting of a Sender, an Intent and a Receiver by using the extracted information;
the correcting unit is used for correcting the real sensitive data sources in all ICC models and removing the redundant models;
and the identification unit is used for identifying possible attack behaviors in the ICC model after the redundant model is removed.
CN202010572689.0A 2020-06-22 2020-06-22 Malicious attack detection method and system for communication mechanism between Android applications Active CN111783092B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010572689.0A CN111783092B (en) 2020-06-22 2020-06-22 Malicious attack detection method and system for communication mechanism between Android applications

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010572689.0A CN111783092B (en) 2020-06-22 2020-06-22 Malicious attack detection method and system for communication mechanism between Android applications

Publications (2)

Publication Number Publication Date
CN111783092A true CN111783092A (en) 2020-10-16
CN111783092B CN111783092B (en) 2023-08-22

Family

ID=72756077

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010572689.0A Active CN111783092B (en) 2020-06-22 2020-06-22 Malicious attack detection method and system for communication mechanism between Android applications

Country Status (1)

Country Link
CN (1) CN111783092B (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114692168A (en) * 2022-04-13 2022-07-01 哈尔滨尚展科技开发有限公司 Cloud service application program vulnerability analysis method and system based on attack big data

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103996007A (en) * 2014-05-29 2014-08-20 诸葛建伟 Testing method and system for Android application permission leakage vulnerabilities
CN104834862A (en) * 2015-03-25 2015-08-12 南京大学 Overall static analysis system for Android authority-escalated attack
CN104992116A (en) * 2014-09-27 2015-10-21 武汉安天信息技术有限责任公司 Monitoring method and system based on intent sniffer
CN106294149A (en) * 2016-08-09 2017-01-04 北京邮电大学 A kind of method detecting Android application component communication leak
CN109145603A (en) * 2018-07-09 2019-01-04 四川大学 A kind of Android privacy leakage behavioral value methods and techniques based on information flow
US20190349756A1 (en) * 2018-05-11 2019-11-14 University Of Southern California Sealant: security for end-users of android via light-weight analysis techniques

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103996007A (en) * 2014-05-29 2014-08-20 诸葛建伟 Testing method and system for Android application permission leakage vulnerabilities
CN104992116A (en) * 2014-09-27 2015-10-21 武汉安天信息技术有限责任公司 Monitoring method and system based on intent sniffer
CN104834862A (en) * 2015-03-25 2015-08-12 南京大学 Overall static analysis system for Android authority-escalated attack
CN106294149A (en) * 2016-08-09 2017-01-04 北京邮电大学 A kind of method detecting Android application component communication leak
US20190349756A1 (en) * 2018-05-11 2019-11-14 University Of Southern California Sealant: security for end-users of android via light-weight analysis techniques
CN109145603A (en) * 2018-07-09 2019-01-04 四川大学 A kind of Android privacy leakage behavioral value methods and techniques based on information flow

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
王允超;魏强;武泽慧;: "基于静态污点分析的Android应用Intent注入漏洞检测方法", 计算机科学, no. 09 *
马川;王涛;祁晓园;王倩;尤殿龙;: "Android应用程序的组件间通信行为检测", 小型微型计算机系统, no. 01 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114692168A (en) * 2022-04-13 2022-07-01 哈尔滨尚展科技开发有限公司 Cloud service application program vulnerability analysis method and system based on attack big data

Also Published As

Publication number Publication date
CN111783092B (en) 2023-08-22

Similar Documents

Publication Publication Date Title
CN107659583B (en) Method and system for detecting attack in fact
CN106828362B (en) Safety testing method and device for automobile information
US7555777B2 (en) Preventing attacks in a data processing system
CN112685737A (en) APP detection method, device, equipment and storage medium
CN107612924B (en) Attacker positioning method and device based on wireless network intrusion
CN110881043B (en) Method and device for detecting web server vulnerability
EP3224984A1 (en) Determine vulnerability using runtime agent and network sniffer
CN112637220A (en) Industrial control system safety protection method and device
CN110881024B (en) Vulnerability detection method and device, storage medium and electronic device
CN107465702B (en) Early warning method and device based on wireless network intrusion
CN110677381A (en) Penetration testing method and device, storage medium and electronic device
US11777961B2 (en) Asset remediation trend map generation and utilization for threat mitigation
CN114329489A (en) Web application program vulnerability attack detection method, server, electronic equipment and storage medium
CN110880983A (en) Penetration testing method and device based on scene, storage medium and electronic device
JP2022037896A (en) Automation method for responding to threat
WO2016014014A1 (en) Remedial action for release of threat data
CN110765333A (en) Method and device for collecting website information, storage medium and electronic device
CN110768949B (en) Vulnerability detection method and device, storage medium and electronic device
CN113411297A (en) Situation awareness defense method and system based on attribute access control
CN114339767B (en) Signaling detection method and device, electronic equipment and storage medium
CN109784051B (en) Information security protection method, device and equipment
CN110768950A (en) Permeation instruction sending method and device, storage medium and electronic device
CN113660222A (en) Situation awareness defense method and system based on mandatory access control
CN111783092B (en) Malicious attack detection method and system for communication mechanism between Android applications
CN111314370B (en) Method and device for detecting service vulnerability attack behavior

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant