KR101640033B1 - Privacy information leak Detecting method using monitoring communication between android processes - Google Patents

Abstract

The present invention relates to a method for inter-process communication monitoring, the method comprising: reading a binder IPC message; and verifying a function requested by a first application from a second application from the binder IPC message, Is read out from the kernel area, it is possible to detect that personal information is leaked from an arbitrary app and warn it.

Description

[0001] The present invention relates to a privacy information leak detection method using communication monitoring between processes of an Android process,

The present invention relates to an inter-process communication monitoring method, and more particularly, to a method for detecting personal information leakage using monitoring of a binder IPC message.

Research is underway to monitor interprocess communication. Conventional techniques related to this are as follows.

The first is a paper titled 'Quire' to prevent 'Confused Deputy Attack' which is similar to a privilege elevation attack using vulnerabilities of Android security model. A method of managing the rights of apps and processes requesting personal information in the form of a chain and checking the chain in which apps and processes that request personal information are present in the app providing personal information and then prohibiting the provision of information when there is no request permission to be. However, this technique is only valid for Confused Defuty attacks, and it is impossible to analyze and monitor the behavior of various types of malicious code.

The second is a thesis titled 'Aurasium' which is a kind of sandbox-type operation at the user level to monitor various behaviors of the app and to prevent malicious behavior by internal policies. However, in order for this technique to work, it is necessary to repackage existing apps. However, since the probability of repacking is not 100% at present, the technique may not be applied.

The third is a technique for monitoring personal information leakage with the title of 'TaintDroid'. It is a technology that tracks the flow from Taint Source, which is the source of personal information, to Taint Sync, which is a personal information outlet, by changing various parts of the platform. However, in order to apply it, it is difficult to actually apply it because the source code of the platform and the kernel must be modified and rebuilt.

The prior art related to the present invention includes a wireless access point device and a network traffic intrusion detection and blocking method using the same (Korean Patent Laid-Open Publication No. 10-2007-0054067).

SUMMARY OF THE INVENTION The present invention provides a method for detecting personal information leakage using monitoring of a binder IPC message.

According to another aspect of the present invention, there is provided an inter-process communication monitoring method comprising: reading a binder IPC message; And confirming a function requested by the first application from the binder IPC message to the second application; And the binder IPC message is read from the kernel area.

According to another embodiment of the present invention, the step of reading the binder IPC message may be performed by reading a system call for the binder driver of the first application using a kernel probe.

According to another embodiment of the present invention, the step of reading the binder IPC message may be a method of analyzing the system call of the first application and classifying and reading the system call related to the binder IPC .

According to another embodiment of the present invention, the step of confirming the function requested by the first application to the second application may include transmitting a service connected to the service client included in the binder IPC message, a function in the service, A process, and a parameter for using the service.

According to another embodiment of the present invention, when the requested function includes personal information, the first application reads a system call for opening an external network and a socket, and the first application transmits the personal information to the external network And confirming whether or not the liquid is discharged.

According to another embodiment of the present invention, the method further includes confirming whether the verified function is a function declared from the first application, and the functions requested by the first application include a function declared from the first application And if so, determining that the first application is not a malicious application, even if the first application does not require all of the functions declared from the first application.

According to the present invention, a kernel-based monitoring technique can detect the leakage of personal information from an arbitrary app and warn it. In addition, by detecting and notifying the leakage of personal information of malicious apps, users can restore confidence in Android.

1 is a flowchart of a method for monitoring an inter-process communication according to an embodiment of the present invention.
2 to 3 are flowcharts of a method for monitoring inter-process communication according to another embodiment of the present invention.
FIGS. 4 to 5 illustrate the process of performing inter-process binder IPC.
FIG. 6 shows the factors used to check whether personal information is leaked.
FIGS. 7 to 8 illustrate an example of detecting that the current position of the device is to be leaked.

Prior to the description of the concrete contents of the present invention, for the sake of understanding, the outline of the solution of the problem to be solved by the present invention or the core of the technical idea will be given first.

The method for inter-process communication monitoring according to an embodiment of the present invention includes the steps of reading a binder IPC message and confirming a function requested by the first application from the binder IPC message to the second application, And the binder IPC message is read out from the kernel area.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. It will be apparent to those skilled in the art, however, that these examples are provided to further illustrate the present invention, and the scope of the present invention is not limited thereto.

BRIEF DESCRIPTION OF THE DRAWINGS The above and other features and advantages of the present invention will become more apparent by describing in detail preferred embodiments thereof with reference to the attached drawings in which: It is possible to quote the above. In the following detailed description of the principles of operation of the preferred embodiments of the present invention, it is to be understood that the present invention is not limited to the details of the known functions and configurations, and other matters may be unnecessarily obscured by the present invention. A detailed description thereof will be omitted.

1 is a flowchart of a method for monitoring an inter-process communication according to an embodiment of the present invention.

In order to implement an inter-process communication monitoring method according to an exemplary embodiment of the present invention, a message of a binder IPC is monitored to determine which services and functions a specific application requires.

The environment in which the inter-process communication monitoring method according to the embodiment of the present invention is implemented is shown in FIG. An environment in which the first application 410 and the second application 420 of the user area 440 perform the binder IPC communication through the binder driver 430 of the kernel area 450, The call 460 may be analyzed to monitor the functionality that the first application 410 requests the second application 420.

Inter-Process Communication (Binder) Interprocess Communication (IPC) records the contents of the request and the response to the kernel memory shared by all processes, and the memory copy overhead in the form that each process refers to the memory address It is a communication method to minimize. It is a technique used for interprocess communication in Android.

In Android, binders are used to connect independent processors. In order to take advantage of system functions in Linux, system calls are used to make use of the processor and file system functions provided by the system. However, in Android, it is at the core of the binder to be able to take advantage of the functions of each independently operated process, especially the service.

In order to perform the Binder communication, it is necessary to be able to convert the memory address mapped by each process and the memory address mapped in the kernel. Therefore, a binder driver exists in the kernel area for this purpose. Since the binder driver exists in the kernel area, an application operating in the user mode can perform communication by calling a system call provided by Linux.

Step 110 is a step of reading the binder IPC message.

More specifically, in order to confirm necessary information, a binder IPC message is read out. By reading the binder IPC message from the kernel area, necessary information is read without affecting the user area. The binder IPC message is a message used by the first application to perform communication with the second application. By monitoring the binder IPC message, the first application can know the function requested by the second application.

In order to read the binder IPC message, a system call to the binder driver of the first application can be read using a kernel probe. Unlike other applications, the kernel is not easy to debug. If you modify and rebuild the kernel, it will take a lot of time to build. To solve this problem, a dynamic probe is used. A dynamic probe is a way of dynamically debugging a kernel without rebuilding it, and it is also possible to debug or patch the desired code in a kernel routine. You can also leave a specific log or modify the function when a particular function is executed. Dynamic probes include a kernel probe (Kprobe), a jumper probe (Jprobe), or a return probe (Kreprobe). Kprobes (Kernel Dynamic Probes) are dynamic probes that insert specific virtual instructions into the kernel. The kernel probe is a debugging mechanism of the Linux kernel that can monitor events within the Linux kernel. It is mainly used for hooking functions performed in the kernel, and system calls for the binder driver of the first application can be read using the kernel probe. The first application can call the ioctl () system call provided by Linux. Because system calls are compiled with the existing kernel source code, the symbol information can be extracted from '/ proc / kallsyms' because the kernel symbol exists, and system calls can be made with the kernel probe (Kprobes) based on the extracted symbol information You can create a module to monitor.

The step of reading the binder IPC message may analyze the system call of the first application and classify and read the system call related to the binder IPC. On the Android platform, ioctl () is called for other uses besides binders, so to reduce analytics you need to extract only the calls that are needed for the analysis. First, after analyzing the arguments of the binder ioctl (), the system call related to the binder IPC is classified and read out. The binder ioctl () message structure is as follows.

ioctl ("/ dev / binder", BINDER_WRITE_READ, struct binder_write_read)

The binder's ioctl () is supposed to take "/ dev / binder" as the first argument and BINDER_WRITE_READ as the second argument. You can use this to filter ioctl () for binder IPCs. The third argument 'arg' in the binder is the binder_write_read structure, whose content changes according to the binder protocol. The binder protocol is used as shown in FIG. 5 according to the data transfer direction. Referring to FIG. 5, it is possible to confirm that the process A requests the process B to the process B even if the binding process is invoked only when the BC_TRANSACTION protocol of the binder IPC protocol is called.

Step 120 is a step of confirming a function requested by the first application to the second application from the binder IPC message.

More specifically, the information contained in the binder IPC message is analyzed to determine what function the first application requires for the second application. In order to confirm the requested function for the second application of the first application, a service connected to the service client included in the binder IPC message, a function in the service, a process of transmitting the binder IPC, You can analyze the parameters.

The ioctl () calling the BC_TRANSACTION protocol is extracted in step 110, and the binder_write_read structure, which is the third argument of the extracted ioctl (), is shown in FIG. In the binder_transaction_data structure, handle, code, sender_pid, and data are analyzed as four factors (410). The functions of the above factors are shown in Table 1 below.

Variable name function handle Identifying Services Connected to Service Clients code Distinguishing features in the service sender_pid Identify the process that sent the binder IPC data Parameters for using this service

By analyzing the four factors, it is possible to confirm the function requested by the first application to the second application.

2 to 3 are flowcharts of a method for monitoring inter-process communication according to another embodiment of the present invention.

In step 210, when the function requested by the first application identified in step 120 includes the personal information, the first application reads a system call for opening the socket with the external network, And confirms whether information is leaked.

More specifically, the first application can monitor whether personal information is leaked through whether the personal information is included in the function requested by the second application. The first application can confirm whether the first application has made a system call to open the socket with the external network in order to confirm whether the first application has requested the personal information with proper authority or requested the personal information to leak the personal information to the outside. If you ask for personal information and open an external network and socket, you may decide to leak personal information.

A malicious application that collects personal information through a binder IPC should open an external network and socket using the Connect () system call in order to leak information collected on the external network. However, the Conncet () system call needs to be filtered as well, because it can be used not only for external network communication (TCP / IP) but also for communication between internal processes (IPC), kernel level and user level communication (NETLINK). The sockaddr structure, which is a parameter of the Connect () system call, is a general-purpose structure for compatibility with a number of socket address systems. The sockaddr structure required for connection to the outside is 16 bytes in sockaddr_in structure. Therefore, it is possible to monitor only Connect () connecting to the outside using this size.

Hereinafter, an example of detecting the leakage of personal information (location information) will be described in detail using an application com.example.sms_puller detecting that the location of the current device is to be leaked using the LocationManager. 7 is a source code of a program created by one example. Call the requestLocationUpdate API to update the location information to the current location. In an apparatus to which an inter-process communication monitoring method according to an embodiment of the present invention is applied, when an operation related to such personal information occurs, a log as shown in FIG. 8 is output by monitoring the binder IPC. The RPC Code 1 of the LoacationManager interface is requestLoacationUpdates, so you can see the result that a particular application com.example.sms_puller detected that it called the device location operation. It is difficult to say that personal information is leaked to the outside only when a specific application accesses personal information. However, when a specific application accesses personal information for Binder IPC monitoring, it is highly likely that personal information will be leaked to the external network when confirming external network and socket communication in Connect () monitoring. It can be used not only for device location information, but also for leakage detection of sensitive information such as address book, IMEI, and SMS.

Step 310 is a step of checking whether the verified function is a function declared by the first application.

More specifically, by monitoring the functions required by the first application through steps 110 and 120, it can be determined whether the first application is a malicious application. Even if it is not a malicious application, it may be judged to be a malicious application if it requires a function different from the function declared by the application. In order to solve this problem, it is possible to monitor the functions required by the first application and check the requested functions of the first application to be monitored to confirm that the first application is a malicious application.

If the functions requested by the first application are included in the function declared from the first application, the first application is not a malicious application even though the first application does not require all of the functions declared from the first application Can be confirmed.

An inter-process communication monitoring method according to an embodiment of the present invention may be implemented by an inter-process communication monitoring apparatus. The inter-process communication monitoring apparatus may include at least one communication unit for transmitting and receiving a message, at least one processing unit for reading and processing information, and at least one storage unit for receiving information processed by the communication unit or storing information processed at the processing unit. The inter-process communication monitoring device may be a user terminal or a separate device. The detailed description of the process performed by the inter-process communication monitoring apparatus corresponds to the detailed description of the inter-process communication monitoring method of FIGS. 1 to 3, and is a detailed description of the inter-process communication monitoring method of FIGS. 1 to 3 Instead.

Embodiments of the present invention may be implemented in the form of program instructions that can be executed on various computer means and recorded on a computer readable medium. The computer-readable medium may include program instructions, data files, data structures, and the like, alone or in combination. The program instructions recorded on the medium may be those specially designed and constructed for the present invention or may be available to those skilled in the art of computer software. Examples of computer-readable media include magnetic media such as hard disks, floppy disks and magnetic tape; optical media such as CD-ROMs and DVDs; magnetic media such as floppy disks; Magneto-optical media, and hardware devices specifically configured to store and execute program instructions such as ROM, RAM, flash memory, and the like. Examples of program instructions include machine language code such as those produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter or the like. The hardware devices described above may be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.

As described above, the present invention has been described with reference to particular embodiments, such as specific elements, and specific embodiments and drawings. However, it should be understood that the present invention is not limited to the above- And various modifications and changes may be made thereto by those skilled in the art to which the present invention pertains.

Accordingly, the spirit of the present invention should not be construed as being limited to the embodiments described, and all of the equivalents or equivalents of the claims, as well as the following claims, belong to the scope of the present invention .

Claims (6)

A method for inter-process communication monitoring,
Reading a binder IPC message; And
And confirming a function requested by the first application to the second application from the binder IPC message,
The binder IPC message is read from the kernel area,
Wherein the step of confirming the function requested by the first application to the second application comprises:
And analyzing a service connected to the service client included in the binder IPC message, a function in the service, a process of transmitting the binder IPC, and parameters for using the service. The method according to claim 1,
Wherein reading the binder IPC message comprises:
And reading the system call for the binder driver of the first application using a kernel probe. The method according to claim 1,
Wherein reading the binder IPC message comprises:
Wherein the system call of the first application is analyzed to classify and read the system call related to the binder IPC. delete The method according to claim 1,
If the requested function includes personal information, reading the system call for opening the socket with the external network, and confirming whether the first application is to leak the personal information to the external network How to. The method according to claim 1,
Further comprising confirming whether the identified function is a function declared from the first application,
If the functions requested by the first application are included in the function declared from the first application, the first application is not a malicious application even though the first application does not require all of the functions declared from the first application ≪ / RTI >

Images