CN111783092B - 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 PDFInfo
- Publication number
- CN111783092B CN111783092B CN202010572689.0A CN202010572689A CN111783092B CN 111783092 B CN111783092 B CN 111783092B CN 202010572689 A CN202010572689 A CN 202010572689A CN 111783092 B CN111783092 B CN 111783092B
- Authority
- CN
- China
- Prior art keywords
- model
- receiver
- sender
- icc
- intent
- 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.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
- G06F21/566—Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements 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/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Virology (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Debugging And Monitoring (AREA)
- Storage Device Security (AREA)
Abstract
The invention discloses a malicious attack detection method and a malicious attack detection system for a communication mechanism between android applications, which are used for running application files and obtaining running logs; and analyzing the application program package and the running log, constructing an ICC (inter-component-component communication) model, and detecting the attack behavior in the ICC model. The method and the device can accurately detect the control flow and the data flow in the communication process between the android application programs, construct a communication model and detect the attack behavior in the model, and have more attack types and higher detection accuracy.
Description
Technical Field
The invention relates to a detection technology for attacks existing in a communication process between android application programs.
Background
In recent years, we have witnessed an explosive growth in the number of mobile devices, and the great variety of mobile applications on these mobile devices has made our daily lives more convenient. However, with the rapid growth of mobile applications, they have become increasingly targeted by mobile malware authors, who often develop and distribute mobile malware aimed at stealing and disclosing various sensitive and valuable information related to mobile users or devices, such as credit card numbers, real-time geographic locations, and IMEI numbers, etc. Malware has become one of the most significant security threats to mobile operating systems, especially android systems.
In an android system, applications run in sandboxes that are isolated from each other. When communication is required between application programs, they use inter-component communication mechanism (hereinafter referred to as ICC) to transfer messages and start components, and the carrier transferred between components is an encapsulated inter-component carrier. While this flexible approach makes a great contribution to functional multiplexing and data sharing, it also exposes vulnerable places to multiple security attacks.
When developers ignore security issues under the ICC mechanism, applications typically suffer from risk vulnerabilities such as Intent (i.e., intelt) hijacking and spoofing, resulting in sensitive user data leakage, rights promotion, and launching proprietary components. As shown in fig. 1, from the Victim application victims, the content is sent from component a to component B. While malicious application Malware1 hives the content sent from component A to component B, a process called content hijacking. Malicious application Malware1 counterfeits the content sent from component A to component B and is sent by component D to component B, a process known as content spoofing. In addition, two or more malicious application programs can also cooperate with each other by utilizing the mechanism to finish the attack behavior, and the attack behavior is disguised as the common message exchange behavior by utilizing the ICC mechanism and is difficult to detect. As shown in fig. 1, a malicious application Malware1 obtains location information, a component D sends the location information to a component E of Malware2 through an ICC mechanism, and Malware2 sends the location to a remote attacker, which is called collusion attack of an application program.
Malicious applications attacked by the ICC mechanism can only expose attack behaviors when running together with an attack object, and when the main stream malicious application detection method is used for detecting, only one application is analyzed, so that the malicious applications can easily bypass detection.
Many existing static program analysis based on static ICC focus on detecting attack surfaces in benign applications, identifying only vulnerabilities that may exist that are exploited. None of these techniques provide any solution for identifying malicious applications using the ICC channel. Recently, most research efforts to study ICC holes have been divided into two parts: static analysis and dynamic run protection. Static analysis typically extracts sensitive ICC paths by matching intent filters and tracking data streams while simultaneously analyzing two or more applications (e.g., IC3, amanDroid, DIALDroid). But even the most advanced of them suffers from a large number of false positives. In addition to the limitations of static analysis when encountering reflective, unreachable codes, such false positives have a greater impact on ignoring verification of the data format. Neglecting verification of the data format, these analysis techniques treat many coincidences or common behaviors as malicious behaviors. Dynamic run protection techniques (e.g., xmanDroid, SEALANT, SCLib) may implement mandatory access control according to a predefined set of policies or query the end user for access permission decisions when the applications communicate with each other based on an intent mechanism. However, the dynamic run protection technique only examines the properties of the content, which can lead to a large number of false alarms, and it directly prohibits the application from receiving the content, regardless of the behavior of the application accepting the content. In general, it only focuses on what happens before the intent receives, not the entire process, and does not provide any solution for identifying malicious applications.
Disclosure of Invention
Aiming at the defects of the prior art, the invention provides a malicious attack detection method and a malicious attack detection system for a communication mechanism between android applications, which improve the detection precision of malicious attacks.
In order to solve the technical problems, the invention adopts the following technical scheme: a malicious attack detection method for a communication mechanism between android applications comprises the following steps:
s1, running an application program file to obtain a running log;
s2, analyzing the application program package and the running log, constructing an ICC model, and detecting the attack behavior in the ICC model.
Through the steps, the method and the device can identify the attack behaviors in the specific process of communication between applications, and the malicious attack detection accuracy is high.
The specific implementation process of the step S1 comprises the following steps:
1) When an application program obtains sensitive data, marking the sensitive data with stain, 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 an operation log;
3) When an application program transmits an Intent, determining a sender of the content, determining a receiver of the content, and outputting sender and receiver information in a running log;
4) Detecting and inputting parameters of each sensitive method, if the parameters are polluted and the parameters are the sensitive data re-marked as the stain in the step 2), determining that the parameters are transmitted through the points, and outputting the information such as the name of the sensitive method and the stain data of the detected stain data as an operation log.
The information required by the analyzer to build the model can be obtained through the steps.
The specific implementation process of the step S2 comprises the following steps:
a) Extracting information in the operation log, and constructing a plurality of ICC models consisting of a Sender (namely a component for sending the Intnt) and a Receiver (namely a component for receiving the Intnt) by utilizing the extracted information;
b) Correcting real sensitive data sources in all ICC models, and removing redundant models;
c) Possible attack actions in the ICC model after removing the redundancy model are identified.
Through the steps A) -C), the whole communication process of the application running can be accurately restored and the attack behaviors in the communication process can be identified.
The specific implementation process of the step A) comprises the following steps: extracting application file information by analyzing the application file; according to the application file information, irrelevant logs from an Android (Android) system and other application programs are filtered; the remaining logs are read and information about Intent is extracted, and the analyzer reads each filtered log and extracts information about Intent, which can be used to construct an ICC model. The method comprises the steps of extracting stain data in an Intnt, sending an Intnt component, an Intnt attribute (comprising action, categories and the like), matching the Intnt component, receiving an Intnt component and an utilization point of Intnt propagation data from a log, acquiring all attributes of an Intnt object, and obtaining 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. And determining the required authority in the Sender according to the authority required by the polluted data in the content, and determining the attribute of the authority required by the Receiver in the model according to the authority required by the Receiver by using the sensitive method. The authority required by the attribute Sender which is missing in the authority of the Receiver is the authority which is missing in the Receiver object; and 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 set of authorities which are not required by the Receiver in all authorities of the Sender. The communication process is constructed into specific models, so that malicious attacks can be detected conveniently.
In order to filter out redundant and internal communication models, further improve the malicious attack detection efficiency, in step B), the specific implementation process of correcting the truly sensitive data source in the ICC model includes: and constructing an ordered model list according to components in a Sender (i.e. Sender) and a Receiver (i.e. Receiver), traversing each ICC model, comparing the stain and the stain source in each ICC model, and determining and correcting the stain source corresponding to the stain in the ICC model.
In the step B), the specific implementation process for removing the redundant model comprises the following steps: intermediate models between the ICC models and communication models inside the application are removed.
The specific implementation process for removing the intermediate model between ICC models comprises the following steps: if model A (the model with the Intent's sending application as sender and the resolution Activity as receiver) and model B (the model with the resolution Activity as sender and the Intent's receiving application as receiver) are generated, models A and B are reduced to one model with the sending application as sender and the receiving application as receiver. In step C), the specific implementation process for identifying possible attack behaviors in the ICC model after removing the redundancy model includes:
iterating all components in the sender application, and checking whether a component list of the candidate receiving content contains components from the sender application; if yes, the attack type of the ICC model is determined to be Intent hijack;
if the sender has the authority related to the sensitive method in the receiver and the data in the content 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 rights required by the receiver to invoke the sensitive method in the ICC model, and the receiver obtains permission for data from the sender, the sender is considered to send an agent for spoofing the receiver, and the attack threat in the ICC model is agent spoofing;
when the receiver component starts the private component and the receiver does not lack the authority of generating data from the sender, the receiver is considered to be deceptively deceived by the sender, 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 of the generation authority from the sender, the sender and the receiver are considered to collusion through an ICC mechanism to launch the attack, and the attack type in the ICC model is collusion.
The identification process considers 5 different situations, which cover all attack types aimed by the invention, and traverses each model, so that the best matching situation 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 for the communication mechanism between android applications, which comprises the following steps: the monitor is used for running the application program file and obtaining 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 first marking unit is used for marking the sensitive data with stain when the 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 the sender of the content and determining the receiver of the content when the application program transmits the Intent, and outputting the information of the sender and the receiver in an operation log;
and the detection unit is used for detecting and inputting parameters of each sensitive method, if the parameters are polluted and the parameters are sensitive data of the stain marked by the second marking unit again, determining that the parameters are transmitted through the points, and outputting the information of the sensitive method name, the stain data and the like of the detected stain data as an operation log.
The analyzer includes:
the extraction unit is used for extracting information in the operation log and constructing a plurality of ICC models consisting of Sender, intent and Receiver by utilizing the extracted information;
the correction unit is used for correcting real sensitive data sources in all ICC models and removing 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 following beneficial effects:
the method and the device can accurately detect the control flow and the data flow in the communication process between the android application programs, construct a communication model and detect the attack behavior in the model, and have more attack types and higher detection accuracy.
Drawings
Three attack models are shown in fig. 1.
Fig. 2 shows the monitor monitoring steps.
Figure 3 shows the analyzer build model process.
Fig. 4 shows the communication process between multiple applications of multiple components.
Detailed Description
The malicious attack detection method for the communication mechanism between android applications, which is designed by the invention, mainly comprises the following two steps: the first step is to run the application program file in a monitoring sandbox (hereinafter referred to as monitor) and obtain a running log; the second step is to analyze the application package and the running log using an analyzer module, construct an ICC model, and detect the attack therein.
Firstly, an application program file is run in a monitor, and 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, and is used for checking related components on an ICC path and data streams associated with an Intent when an application runs, and acquiring related information of the Intent at a plurality of key points of the ICC flow, including a component for transmitting the Intent, a component for matching the Intent and the like. In addition, the monitor module utilizes dynamic stain analysis techniques to identify: (a) Whether there is transmission of sensitive data from the sender application to the receiver application through the intent, and (b) whether the sensitive data is used by the receiver, including recording, sending, etc. Fig. 2 shows the monitoring steps of the monitor, which are refined as follows:
first, when an application acquires sensitive data, a monitor marks the sensitive data with a stain.
When an application program acquires sensitive data in the equipment, the sensitive data sources are marked as blobs through a dynamic blobs analysis method, and the marked sensitive data sources mainly relate to some api related to user privacy and information input by the user, such as (contacts, address information, mobile phone state information and the like).
And secondly, identifying sensitive data and re-marking the stain when the application program constructs the Intent.
When an application program constructs an Intnt, if the sensitive data acquired in the previous step is used, the monitor detects the transmitted parameters in the construction method of the Intnt, and determines whether the Intnt carries the sensitive data and what the sensitive data is by identifying the attribute of the sensitive data through the stain carried by the sensitive data. If the Intet carries sensitive data, the contaminated sensitive data is recontaminated so that the dirty data is tracked from the Intet when the sensitive data is detected in the application receiving the Intet. If sensitive data that is not contaminated in the Intent's parameters is constructed, adding a stain to these parameters indicates that this is non-sensitive data from Intent.
Third, when the application transmits the Intent, the monitor determines the sender of the content.
When an application sends an intent to other applications or components, the monitor captures the event sent and the initiating object of the event. The application can call an API (e.g. startservice) in the inheritance class of component Activity, service, broadcast to send the content. Activity, service and the API sending the content in Broadcast are API calls by inheriting the ContextWrapper class or obtaining the ContextWrapper object, so that the API calling object, the related attribute of the object and the attribute information of the content can be obtained by the reflection method in the ContextWrapper class (e.g. action, categories, type). Thus, the monitor captures the send event of the content and obtains the relevant information of the sender by monitoring the ContextWrapper class.
Fourth, the monitor determines the recipient of the content.
After capturing the send event of an intent, it is necessary to determine which component attributes match successfully as candidates for receipt, and finally which components become recipients and receive the intent. In an android system, a Packagediananagesservice (PMS) is responsible for querying the components that best match an intelt by traversing all the components of the applications in the system. When the accepted component is of the Activity and Service type, if there are a plurality of the accepted components meeting the condition, the best component reception is selected according to the priority, the default condition, and the like. And finally, when the unique meeting condition is not available, the Activity pops up a prompt box for the user to select, and Service defaults to the first one of all candidates. When the recipient is a Broadcast, the content is sent to all conforming components. Therefore, the monitor monitors the PMS for all candidate components matching the subject and components ultimately accepting the subject.
Fifth, the monitor monitors the private data in the content of the content recipient's processing content.
The monitor detects the incoming parameters in various sensitive methods (including log output, output to a file, sending a short message, storing in a shareference, etc.). If the parameter has been contaminated and the stain matches the characteristics 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 content to which it indicates that the recipient application has processed the sensitive data from the content 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 behaviors in the ICC model. The analyzer constructs an ICC model from information obtained by the monitor and information extracted from an APK (application package) file, and then recognizes an attack by matching the model with 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 an attack in the ICC model.
In a 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 APK) consists of 3 objects, including Sender, intent and Receiver. Fig. 3 illustrates detailed information of the model. The analyzer first extracts information, such as package name and rights of each application, by analyzing the APK file. The package name helps the analyzer 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 about applications of interest to the user. Third, the analyzer reads each filtered log and extracts information about the Intent, which can be used to construct the ICC model. The method comprises the steps of extracting stain data in an Intnt, sending an Intnt component, an Intnt attribute (comprising action, categories and the like), matching the Intnt component, receiving an Intnt component and an utilization point of Intnt propagation data from a log, acquiring all attributes of an Intnt object, and obtaining 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. The attributes associated with rights in the model require more effort. The analyzer identifies the rights attributes required by the Sender as the rights required in the Sender based on the rights required by the contaminated data in the content. The attribute of the rights missing in the 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 stain data in the receiver. The missing rights of the Sender is a collection (set) of rights required by the Receiver, which is not included in all rights of the Sender.
TABLE 1 ICC (Inter-Component Communication) model
The second step, the analyzer ICC model is normalized, mainly to correct the truly sensitive data sources in the ICC model and to eliminate redundant models.
The analyzer will use the log from the API (for sending the content) to start the detection of the whole ICC process. Whenever the analyzer reads the log of the send content from the API, it ends the current inter-component communication process and begins building a new log. However, if we focus only on the components that send or receive the content, in the case shown in FIG. 4, three models of Model A, B and C will be constructed. However, this is clearly erroneous because the source of the contaminated sensitive data (e.g., T-data) is not in the sending intent component. In Model B and Model C, the source of T-data is considered C2 and C3, respectively, but the root source is C1 located in Model A. Thus, after temporarily dividing these four components into three models, the analyzer must find the true source and true sink of the data in the entries in models B and C. To this end, the analyzer first builds an ordered list of models from the components in Sender and Receiver, then traverses each model to compare the point tags to identify sink in source and Receiver in Sender, and ascertains whether Receiver has launched the proprietary component after the content is obtained.
After extracting 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 an application is independent of us. If the type of the recipient component is active and there are multiple components that match the intent attributes, the android system passes the intent to a resolution Activity selector for the user to select the desired component. After the user selects the target component, the resolution activity then sends the content instead of the sender application. The process generates two models, namely a model with sender and Receiver as the sending application and a model with Receiver as the receiving application. The analyzer reduces the above two models to one model to send an application sender and receive an application as receiver.
In addition, the analyzer removes models that occur inside the application, i.e., the application to which sender and receiver belong is the same.
Third, an attack behavior in the ICC model is identified.
After all models are built, possible attacks in the ICC model are identified. The detection algorithm considers 5 different cases that cover all attack types for which the present invention is directed and traverses each model to find the best match case.
Case 1: all components in the sender application are iterated, and whether the component list of the candidate receiving content contains components from the sender application is checked. If so, the type of attack of the ICC model is deemed to be Intent hijacking, in which case we consider the example of FIG. 1 as occurring and that one of the candidate components from the sender application should be the destination of the Intent, so the receiver component hives the Intent that should be sent to the other component.
Case 2: if the sender has rights related to the sensitive method in the receiver and data in the content used by the sensitive method exists in the receiver, the attack type Intent hijacking existing in the ICC model is considered. After the receiver acquires the data from the content, the sensitive method uses the data, which means that the receiver acquires the private data from the sender by acquiring the content, and the sender does not lack the authority related to the sensitive method in the receiver, in this case, we consider that the receiver hives the content sent by the sender.
Case 3: if the sender lacks the rights required by the receiver to invoke the sensitive method in the ICC flow, and the receiver does obtain permission for data from the sender, we consider that the sender sends an intent to spoof the receiver, and the attack threat in the ICC model is intent spoofing. 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 initiates a private component and the receiver does not lack the right to generate data from the sender, we consider that sender spoofs the receiver, and the attack type of the ICC model is Intent spoofing. In this case, sender invokes the private component through other public components and does not perform any illegal actions at the same time.
Case 5: if sender lacks the rights required by receiver to invoke the sensitive method, receiver also lacks the data from sender to generate rights. We consider that both applications collude to launch attacks through the ICC mechanism, the type of attack in the ICC model being collusion. They upgrade privileges to each other and supplement rights to each other through the process of communication between components, which is a typical example of an intent collusion attack.
Claims (5)
1. A malicious attack detection method for a communication mechanism between android applications is characterized by comprising the following steps:
s1, running an application program file to obtain a running log;
s2, analyzing the application program package and the running log, constructing an ICC model, and detecting the attack behavior in the ICC model;
the specific implementation process of the step S1 comprises the following steps:
1) When an application program obtains sensitive data, marking the sensitive data with stain, 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 an operation log;
3) When an application program transmits an Intent, determining a sender of the Intent, determining a receiver of the Intent, and outputting sender and receiver information in a running log;
4) Detecting parameters input into each sensitive method, if the parameters are polluted and the parameters are the sensitive data re-marked as the stain in the step 2), determining that the parameters are transmitted through the Intent, and outputting the information such as the name of the sensitive method and the stain data of the detected stain data as an operation log;
the specific implementation process of the step S2 comprises the following steps:
a) Extracting information in an operation log, and constructing a plurality of ICC models consisting of Sender, intent and Receiver by using the extracted information;
b) Correcting real sensitive data sources in all ICC models, and removing redundant models;
c) Identifying possible attack behaviors in the ICC model after the redundant model is removed;
in the step B), the specific implementation process for removing the redundant model comprises the following steps: removing an intermediate model between ICC models and a communication model inside an application program; the specific implementation process for removing the intermediate model between ICC models by combining application runtime monitoring and analysis detection comprises the following steps: if model A and model B are generated, simplifying model A and model B into one model with sending application as Sender and receiving application as Receiver; the model A refers to a model taking the sending application of the Intent as a sender and the resolution activity as a Receiver; model B refers to a model with a resolution activity as Sender and an Intnt receiving application as Receiver.
2. The malicious attack detection method for the inter-android application communication mechanism according to claim 1, wherein the specific implementation process of the step a) includes: extracting application file information by analyzing the application file; according to the application file information, irrelevant logs from the android system and other application programs are filtered; reading the rest logs and extracting information related to the Intent, and reading each filtered log and extracting information related to the Intent by an analyzer; extracting stain data in an Intent, a component for transmitting the Intent, an Intent attribute, a component for matching the Intnt, a component for receiving the Intnt and a utilization point of Intent propagation data from a log, acquiring all attributes of an Intent object, and acquiring 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 use 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 Intnt, and determining the attribute of the authority required by the Receiver in the model according to the authority required by the sensitive method in the Receiver, wherein the authority required by the attribute Sender which is missing in the authority of the Receiver is the authority which is missing in the Receiver object; and 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 set of authorities which are not required by the Receiver in all authorities of the Sender.
3. The malicious attack detection method for an inter-android application communication mechanism of claim 1, wherein in step B), the specific implementation process of correcting the truly sensitive data source in the ICC model includes: and constructing an ordered model list according to the assemblies in the Sender and the Receiver, traversing each ICC model, comparing the stain and the stain source in each ICC model, and determining and correcting the stain source corresponding to the stain in the ICC model.
4. The malicious attack detection method for an inter-android application communication mechanism according to claim 1, wherein in the step C), the specific implementation process of identifying possible attack behaviors in the ICC model after removing the redundancy 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 existing in the ICC model is determined to be Intent hijack;
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 permission for data from the Sender, the Sender is considered to send an Intnt for spoofing the Receiver, and the attack type existing in the ICC model is Intnt spoofing;
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 existing in the ICC model is Intent deceive;
if the Sender lacks the authority required by the Receiver to call the sensitive method and the Receiver also lacks the authority to generate the data from the Sender, the Sender and the Receiver are considered to collusion and launch the attack through an ICC mechanism, and the attack type existing in the ICC model is collusion.
5. A malicious attack detection system for a communication mechanism between android applications is characterized by comprising:
the monitor is used for running the application program file and obtaining a running log;
the analyzer is used for analyzing the application program package and the operation log, constructing an ICC model and detecting the attack behavior existing in the ICC model;
the monitor includes:
the first marking unit is used for marking the sensitive data with stain when the 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 Intentit determining unit is used for determining a sender of the Intentit and determining a receiver of the Intentit when the application program transmits the Intentit, and outputting the sender and receiver information in a running log;
the detection unit is used for detecting and inputting parameters of each sensitive method, if the parameters are polluted and the parameters are sensitive data of the stain marked by the second marking unit again, determining that the parameters are transmitted through the Intent, and outputting the information of the sensitive method name, the stain data and the like of the detected stain data as an operation log;
the analyzer includes:
the extraction unit is used for extracting information in the operation log and constructing a plurality of ICC models consisting of Sender, intent and Receiver by utilizing the extracted information;
the correction unit is used for correcting real sensitive data sources in all ICC models and removing redundant models;
the identifying unit is used for identifying possible attack behaviors in the ICC model after the redundant model is removed;
the specific implementation process for removing the redundancy model comprises the following steps: removing an intermediate model between ICC models and a communication model inside an application program; the specific implementation process for removing the intermediate model between ICC models by combining application runtime monitoring and analysis detection comprises the following steps: if model A and model B are generated, simplifying model A and model B into one model with sending application as Sender and receiving application as Receiver; the model A refers to a model taking the sending application of the Intent as a sender and the resolution activity as a Receiver; model B refers to a model with a resolution activity as Sender and an Intnt receiving application as Receiver.
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 CN111783092A (en) | 2020-10-16 |
| CN111783092B true 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) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114792006B (en) * | 2022-03-29 | 2024-06-14 | 西安电子科技大学 | LSTM-based android cross-application collusion security analysis method and system |
| CN114692168B (en) * | 2022-04-13 | 2023-01-13 | 中咨数据有限公司 | Cloud service application program vulnerability analysis method and system based on attack big data |
| CN117527369B (en) * | 2023-11-13 | 2024-06-04 | 无锡商业职业技术学院 | Hash function-based android malicious attack monitoring method and system |
Citations (5)
| 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 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10827349B2 (en) * | 2018-05-11 | 2020-11-03 | University Of Southern California | SEALANT: security for end-users of android via light-weight analysis techniques |
-
2020
- 2020-06-22 CN CN202010572689.0A patent/CN111783092B/en active Active
Patent Citations (5)
| 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 |
| 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 (1)
| Title |
|---|
| 基于静态污点分析的Android应用Intent注入漏洞检测方法;王允超;魏强;武泽慧;;计算机科学(第09期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111783092A (en) | 2020-10-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111783092B (en) | Malicious attack detection method and system for communication mechanism between Android applications | |
| CN110620753B (en) | System and method for countering attacks on a user's computing device | |
| Xu et al. | Iccdetector: Icc-based malware detection on android | |
| US7555777B2 (en) | Preventing attacks in a data processing system | |
| CN107612924B (en) | Attacker positioning method and device based on wireless network intrusion | |
| CN112685737A (en) | APP detection method, device, equipment and storage medium | |
| CN105915532B (en) | A kind of recognition methods of host of falling and device | |
| CN107465702B (en) | Early warning method and device based on wireless network intrusion | |
| CN111786966A (en) | Method and device for browsing webpage | |
| CN112149123B (en) | Safety inspection system and method for application program | |
| US11777961B2 (en) | Asset remediation trend map generation and utilization for threat mitigation | |
| US20140344931A1 (en) | Systems and methods for extracting cryptographic keys from malware | |
| US11762991B2 (en) | Attack kill chain generation and utilization for threat analysis | |
| CN110881024A (en) | Vulnerability detection method and device, storage medium and electronic device | |
| CN113746781A (en) | Network security detection method, device, equipment and readable storage medium | |
| 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 | |
| CN106209907A (en) | A kind of method and device detecting malicious attack | |
| CN110768950A (en) | Permeation instruction sending method and device, storage medium and electronic device | |
| Boggs et al. | Discovery of emergent malicious campaigns in cellular networks | |
| CN107517226B (en) | Alarm method and device based on wireless network intrusion | |
| Johnson et al. | Sms botnet detection for android devices through intent capture and modeling | |
| CN114257404B (en) | Abnormal external connection statistical alarm method, device, computer equipment and storage medium | |
| Boyarchuk et al. | Keeping up with the emotets: Tracking a multi-infrastructure botnet | |
| Sharma et al. | Smartphone security and forensic analysis |
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 |