Malicious Behavior Analysis of Android gui based on adb
Download 49.2 Kb.
|
- Navigate this page:
- III.ANALYSIS OF THE ATTACK
- C.Activity transition detection and inference
- IV.ATTACK DESIGN AND IMPLEMENTATION
- B.Activity hijacking attack Activity hijacking attack
- 1)Activity hijacking attack review
- 3)Implementation of attack
- C.Attack results and analysis
| Malicious Behavior Analysis of Android GUI Based on ADB
Li Yang School of Computer Science and Technology Xidian University Xi’an 710071, China yangli@xidian.edu.cn Lijun Wang School of Computer Science and Technology Xidian University Xi’an 710071, China 952198007@qq.com Dongdong Zhang School of Computer Science and Technology Xidian University Xi’an 710071, China zdd205@qq.com
Abstract—The Android application is part of people’s lives, however the functionality required by various user has greatly exceeded its original design. As a result, one must seek other ways to gain permission that is not directly available to the user. A typical approach is using the Android Debug Bridge (ADB), a developer tool that is used to grant permission to critical system resources. There are millions of downloads on Google Play that using this method. However, we found that ADB level functionality is not well protected by Android. A striking example of our investigation is that the ADB tool can be used to get the system application logs. Based on this finding, malicious applications can intelligently gather logs of application activity and then perform hijacking attacks. To understand this threat, we have developed an application that can detect the login time of the target application and then carry out the Activity hijacking attack, so as to obtain his account and password. Keywords- Android; ADB; Activity hijacking I. INTRODUCTIONWith the progress of Android smart phone and tablet computer technology, its application market is expanding rapidly. However, UI attacks based on applications pose a growing threat to the intelligent end-users [1][2][3]. In this attack, the malicious application cheats the user to enter sensitive data in its malicious control window or provides the wrong input to the normal window. In Android mobile terminal malicious attacks, UI based attacks are particularly serious because they collect and control information at the point closest to the user. Once a malicious application gets a foothold on the mobile device, it is likely to steal the credentials and cause the user to grant additional permission, totally compromising the device. One class of these attacks is application-based phishing. For example, svpeng is such a malicious mobile application, it deceives users to provide sensitive data in a malicious window, including bank credentials and credit card numbers [4][5]. Due to current mobile phone application sharing screen mode is very rich, this kind of deception can be stealthy and convincing. Qi Alfred Chen et al. [6] through the newly discovered side channel –shared memory to infer the UI state of the mobile phone. They carried out the UI state inference experiment and found an accuracy of 80%-90% in determining the foreground Activity for 6 out of 7 popular applications. In order to prove that it is able to carry out attacks on this, they designed and implemented some attacks based on UI state inference. The importance of GUI-related attacks on Android has been pointed out by several publications in the past, such as [7] (with a focus on “tapjacking”). In this paper, the author described a user interface attack that has a profound impact on the mobile device, and presented some possible techniques to mitigate this attack. Fortunately, because of restricting the operation of individual applications in their own sandboxes and their access to critical system resources through a permission mechanism, the development of Android is good, and so far the number of malicious applications found in the application market is reduced to 0.5% [8].However, more and more people are not satisfied with the resources provided by Android API and try to get new features that the ordinary Android user do not have, such as wireless network, system backup and new fonts adding, etc. One way to get this function is to root the phone, allowing users to access the device's root permission, but rooting new device will lead its warranty failure or damage the device. In view of this risk, more and more people are seeking other methods do not require root mobile phone. The most widely used method is Android ADB [9]: the user connects his smart-phone to PC, starts the ADB debugging and invokes the privilege service further. Then the application can communicate with the service process to obtain the resources that the Android API does not provide, even after the phone is removed from Personal computer (PC). It’s important to note that this method is completely legal, and also very convenient to use under the help of correct guidance and installation scripts. However, this solution escalates the normal application’s privileges, and exposes the ADB level resources. So far, its security and privacy implications are not very clear for application developers, and apparently also to the android designers. The use of ADB tools will also bring great risk to the user's Android mobile phone, and it could become a way for malicious attackers to attack the Android system, though there is less research and analysis in this area. In order to understand the threat better, we design a program can monitor application running in real time, and carry out Activity hijacking as soon as it detected target application’s login activity. We use the application’s log to infer the UI state. It is easier to obtain than the shared memory changing size, and cost lower memory and power consumption. In this paper, we will show that the state of the UI can be inferred without any privileges. In this attack, the attackers first construct an offline UI state machine based on UI state signature, and then use a non-privileged background application to infer the UI state in real time. In Android terminology, the UI state is known as Activity, so it can also be called the Activity inference attack. It is found that the generated log by the Android application can be obtained by other applications without require additional privileges based on ADB. After obtained the target application’s running logcat, attacks can use it to infer the user’s operation (such as the bank application login operation) and then carry out UI hijacking attack. For the rest of the paper, we first discuss the attack background in II. The discovered Activity transition detection through log is detailed in III, and based on that, we evaluate this attack with popular applications in IV. We describe the conclusion in V, before acknowledging in VI. II.BACKGROUNDIn Android, the Activity provides interface for users to interact. In our attack, Attackers use the Android log to infer Activity transition, so in the following we will discuss the attack background. A.Android ActivityActivity is one of the four components of the application, and its main function is to provide the interface [10]. An application is generally composed of multiple Activities, the relationship between the Activities is very loose, and there is no direct correlation between them, there must be an Activity designated as the main Activity, it is the interface that first appears when the application starts. B.Activity TransitionIn Android, multiple Activities usually work together, and transit from one to another to support the entire application functions [11]. As shown in Figure 1, during the whole transition process, the current foreground Activity pauses and creates a new Activity. Activities are stored in the back stack and maintained by the Android system. In order to prevent excessive memory usage, only the Activity at the top of the stack has an allocated window buffer at any time. Whenever an Activity transition occurs, the new Activity window buffer allocation will appear and the existing Activity buffer allocation will be canceled.  Figure1 Activity Transition
Activity transition only occurs in two kinds of situation: a new Activity is created, or previously used Activity resumes when the BACK key is pressed. These two types of transition started by pausing the current foreground Activity and then laughing a new Activity. When starting a new Activity, the former transition will call the onCreate() and onResume() method, while the latter transition only calls the onResume() method. When the onCreate() and onResume() method is executed, perforTraversal() will be called, using measure() and layout() to calculate the size and location of the UI components, and then use draw() to generate a new Activity interface. Finally, in the first transition type, the new Activity will be pushed into the top of the stack, and in the second transition type, the new Activity will be popped and destroyed. C.Android logAndroid system provides a simple and convenient Log mechanism [12].During the development process, Log is used to record the execution process, which can be used for program debugging, and also be used to record the application event. An important piece of the Android log is the level of the log which in the second location of the log format. Android log classification, from low to high is shown in Table 1: Table 1 Android log classifications
Due to the redundancy of Android log information, it will take a long time to analyze it directly, so it is necessary to filter and then analyze it, by doing this, we can save a lot of time. III.ANALYSIS OF THE ATTACKA.Android permission and ADBADB is a command-line tool that allows developers to communicate to an Android device connected to a development system (such as PC) [13]. Therefore, it has a set of unique functions specified under the Android permission system. It is summarized as follows: Android uses permissions to protect its system resources, which application access specific resources need to apply for permission first. According to the risk level of each permission, Android assigns a protection level so as to handle different levels of permission in different ways. Specifically, most permissions have normal level or dangerous level. Those in the normal level are considered to be risk-free (such as setting alarms), so it will be granted to the requesting application automatically. On the other hand permission in the dangerous level may bring security risks (for example, permission to open the network sockets), which the system only give it to application only after the user's explicit consent (such as whenever permission is requested asking the user to press the confirm button). For the permissions that has the highest risk impactions (such as accessing to the frame buffer), Android classifies them into the signature level, which are only granted to trusted party (such as the Android development team). To this end, Android has created a database to store these trusted certificates. Most of the third party application developers are not in them, so their applications do not have this level of permissions. On the other hand, some signature level permissions are very important to the user, such as modifying the configuration to control the backup process. Of course, the permission for gaining the system and other applications’ running log. If an Android user wants to use the resources, it is necessary to protect the permissions by default access mechanism. This is not open to third party applications, for example, modifying the system configuration needs to go through a system application; screen shooting can only be taken by the Power and Volume Down button combination. Some signature level permissions considered to be very useful to application developers are given to the ADB. In the default access mechanism, ADB is probably the only way that developers use to programmatically access some signature-level resources. The system tool can run Android native executable files, which can be used to create a proxy for its third party application to obtain the required signature level permissions. Since the applications using this method have accumulated tens of millions of downloads on Google Play, and Google did not hear any objections, so it is considered to be legitimate. Given its popularity among the application developers, the security risk has never been well understood. Our research shows that this approach indeed brings in serious security risks, and if the developers do not understand them well, it is likely to lead to devastating consequences.
B.Problem DescriptionAs a development tool, ADB allows developers to launch a remote shell to connect to a development PC. Through the shell, he can perform applications with ADB’s signature-level permissions. Specifically, the developers first pack all methods that require signature-level permission along with a front-end that communicates with a third-party and unprivileged application into a native Android executable file, then connect the target Android device to the development PC, and then through the ADB shell command to trigger the executable file. Once the executable file is under operation, developers can disconnect the equipment from the PC. Unprivileged applications can invoke packaged methods through the front-end to access resources protected by signature-level permissions. In order to simplify the process, developers typically implement a script to automatically perform the necessary operations. The script can even include the ADB binary file to avoid having the user configure the Android SDK. Therefore, the user only needs to execute the script once he restart the device, and then can run the unprivileged applications to obtain signature application permissions. C.Activity transition detection and inferenceThrough the above knowledge, we can detect Activity transition according to the applications’ log. In order to achieve real-time detection of Activity transition, we use ADB tool to generate real-time applications’ running log and store them in database. When detected the Activity transition, we will match the target application’s log. If matching with the target application, then we will carry out attack otherwise continue to match. The detailed steps of inference are shown in Figure 2: In order to infer the current Activity interface, we design a signature for the application’s Activity, and use the Android application’s running log to mark signature changes during the process of starting activity. In the implementation of this paper, we use the logging system by calling the application framework layer's Java interface (android.util.Log). The Java interface uses the JNI method and the system runtime library to call the kernel driver Logger to write the log to kernel space finally. Since the log format is: timestamp + log level + tag + thread + details, for example: I/ActivityManager( 602): Displayed com.sina. weibo/.account.SwitchUser: +2s201ms. After matching part of the information, we can know the log information is Sina weibo switches users. Therefore we can according to a series of application’s login log to establish Activity signature. The mobile terminal’s log information in log buffer can be obtained by the ADB. Because there are many types of log, we need to further filter the allocated log, and finally get the log generated by ActivityManager. 
Figure 2 Schematic diagram of Activity inference Using BM algorithm to match the generated ActivityManager log, we can get the target activity’s running information. BM algorithm mainly uses three kinds of clever and effective methods, namely from right to left scanning, bad character rule and good suffix rule [14].
In the process of scanning from right to left, if a character X does not match, it is discussed as following two conditions:
Let Skip(x) represents for P right shift distance, m is the length of pattern string P. max(x) represents for the right location of the character x in P.  (1)
Let j be the current matching character position and s be the distance between t 'and t (distance i above) or distance between x and P' '(where x is the distance from the left to the right, (ii) above.  (2)
After detecting the login of the target application, the Activity hijacking attack can be performed. IV.ATTACK DESIGN AND IMPLEMENTATIONA.Overview of the attackThe Activity hijacking attack we put forward is a side channel attack against GUI system, the purpose is to infer the application interface that user is interacting successfully, and then hijacking. In order to achieve such attack, we use the log information of Android application. In this paper, we mainly focus on the Activity interface inference attack in the Android platform. Attack scenario: supposing a malicious application silently running in the victim device’s background; the application does not need to apply for other permission except the Internet permission. The victim device need to connect to a computer, and open the USB debugging, and also installed a malicious application in the connected computer, the application is mainly used to collect and analyze log information. So that analysis and matching the log information is on the PC side. This can reduce the memory and power consumption on mobile terminal, so as to ensure the concealment of the attack.Attack steps are shown in Figure 3. B.Activity hijacking attack Activity hijacking attackIn this section, through successful inference of UI state, we designed an attack that break the integrity of the GUI: Activity hijacking attack. The attack is based on a simple principle: inject fishing Activity secretly when the target Activity is running in the foreground, and then steal the input information such as user login and password. 1)Activity hijacking attack reviewFigure 4 shows the general steps of the Activity hijacking attack [15]. In the first step, the background attack application uses Activity inference to monitor foreground Activity, waiting for the attack target, in the second step, once the Activity inference detect the target Activity entering the foreground, at the same time the attack application injects a prepared fake login Activity to the foreground. The challenge here is that the injection of fishing Activity may be too early or too late causing visual disruption (e.g., broken animation). In order to choose a suitable time, we carry out a pre filter of the Android log; it can quickly detect the target application, and won’t cause the user's suspicion during the transition of the Activity, and continue to enter his user name and password. After this step, information is stolen by the attacker successfully; in the third step, attack application need to end the attack without causing the user’s suspicion as much as possible. As the attack Application is now in the foreground, it needs to transition back to the original application in some way without causing the user's suspicion. 
Figure 3 Attack steps 
Figure 4 General steps of Activity hijacking attacks 2)Attack design details
In order to understand how an Activity is injected into the front desk and replace the existing Activity, we need to understand the design principle of intelligent mobile phone UI. If we consider such as alarm or reminders application, they need to pop and ability to replace any current front Activity. In Android, there are two kinds of methods support this function without any permission: (1) Start an Activity with a restricted boot mode "SingleInstance"; (2) Start an Activity from the Android broadcast receiver. In the experiment, we select the after starting mode. Through the computer client to send a broadcast that detection of the target Activity, as soon as the phone side receiving the broadcast, immediately carries out the injection of Activity.
In order to ensure that the fishing Activity UI and victimization Activity looks the same, we use Apktool application APK decompile the victim and copy all the relevant UI resources to attack application]. However, sometimes Activity UI may have dynamic loading areas, these areas are uncertain UI resources such as bank application’s users verification code. To solve this problem, considering the Android mechanism that support part transparent of Activity, this area can be designed to be transparent. As Figure 5 and Figure 6 is the normal WeChat login interface and faked malicious login interface, it is difficult for users to distinguish which is the real WeChat UI. F F
Because of the introduction of the additional Activity into Activity transition, the animation of the additional transition would clearly disrupt the flow. Fortunately, this problem can be solved by disabling the transition animation (allowed by Android) by modifying an Activity configuration of the attack application without needing any permission This makes Activity injection become completely seamlessly.
In order to be able to successfully attack, Activity injection time need to occur before any user interaction with the Activity or UI change trigger may be injected into the Activity interrupt. Because the interface technology at present Activity injection need quite a long time (receiving PC sends a broadcast after about 1300ms can be injected Activity during this period of time), any user interaction will cause suspicion during this time.
After successfully performing the Activity hijacking attack, we try to switch from the attack application to the normal application and do not cause the user's suspicions. As the fishing activity now has the user input information on the screen, if directly close the Activity and then jump to the victim application will blunt. In our design, we use "benign" exception to hide the attack, such as the attack application display "password mistake" and then quickly destroyed after the user click the login button and then back to the victim application. As shown in Figure 7.   
Figure 7 Switches to normal application after obtaining user information
After the successful access to the user input data, then the attack need to save data the data to the database, and wait a right time to spread the server side through the Interne. 3)Implementation of attackImplement the method of Activity hijacking: First run a StartServiceActivity() in the mobile terminal, this Activity is boot from the start, there is a broadcast receiver used to receive the broadcast send from PC-side. While in the PC side, the program will collect and filter log, after matching the target application’s login Activity then sends a broadcast to the mobile terminal, once the malicious application in the terminal receiving the broadcast, it will carry out hijacking immediately. At this time, Activity will launch the HijackService() to hijack, and the FakeMainActivity() will be started. Its main purpose is to start a login interface that appears the same as the target application’s login interface, to deceive the user to enter login account and password. After the user successfully obtains information, the Activity will pop up ERROR information and prompt the user to re-enter the account password. When the user clicks the confirmation button, FakeMainActivity() will pop out of the stack, after that the real login activity will interact with user. And the malicious application will send getting account and password to the attackers via the Internet. C.Attack results and analysisIn our implementation of the Activity hijacking attack, through the method that filtering log and matching, we can quickly detect the target application’s login Activity. Different application’s login UI detection time are shown in Figure 8:  Figure 8 Detection time of different application login UI
From Figure 8 we can see that detect different application login UI cost different time. The main reason is that the log content generated by each application is different, but we all can detect the target application’s login activity before the user interacts with them. Figure 9 shows the required time for different fake Activity injections:
In the experiment, the average time of fake login Activity injection is 550 milliseconds; this can quickly complete the injection of Activity before user interacts with target activity. Different Activity injection time is different; the main reason is that the amount of memory occupied by the Activity is different. Typically, it takes a long time to inject a large memory activity. V.CONCLUSIONIn this paper, we design and implement a Activity hijacking attack that using the log generated by the application. Through collecting and filtering these log in real time, using the BM algorithm to inference the login interface of the target application, and then can carry out the Activity hijacking attack. In the experiment, the average time of the fake login Activity injection is 550 milliseconds, the user can quickly complete the injection of Activity before it interacts with the user without causing suspicion. Different Activity’s injection time is different, the main reason is that the Activity memory size is different, usually; the larger memory Activity’s injection takes a long time. AcknowledgmentWe would like to thanks the anonymous reviewers for their careful reading and useful comments. This work was supported by the National Natural Science Foundation of China (U1405255, 61671360, 61672415, 61672409), and the Fundamental Research Funds for the Central Universities (JB161505). References
Directory: cpir -> UploadedFiles UploadedFiles -> Packet Diversity-based Anomaly Detection System with ocsvm and Representative Model Download 49.2 Kb. Share with your friends:
|
Figure 9 Time required injecting different Activity