The present invention relates to the field of security. More particularly, the invention relates to an improved method and system for assessing the security threats that may be potentially posed by an application uploaded to an App Store.
In recent years software designed for Smart devices (hereinafter referred to as “applications”) has been made available in large numbers through the so-called “App Stores”, such as those run by Samsung, Google and Apple. Those App Stores allow independent developers to upload applications that were not developed under the control of the App Store owner. As a result, some developers have taken advantage of this platform to include malicious code in their applications, which can be used for a variety of malicious activities.
In the context of this application the term “App Store” is meant to include any web-based store that sells software suitable to be run on Smart devices and includes, for instance, Smart TV AppStores or Mobile AppStores.
Because very large numbers of applications are developed independently, the App Store owners only have very limited capability to prevent malicious exploitation. There is therefore an urgent and clear need to assure that the applications, which are uploaded to an App Store are not malicious.
So far the art has employed two main approaches in an attempt to deal with the problem described above:
(1) Scanning—is an approach that allows runtime analysis of the application in order to detect patterns of malicious activity.
(2) Malware—is an approach that allows a mobile device to contact a server in order to receive a security assessment of the installed application and so, if the application is unsafe, to be able to remove it.
The above approaches use run time analysis of the executable in order to reach a conclusion whether the application is malicious or not. This leads to a large number of inaccuracies since every application behaves differently and it is hard to drive the application into all the states in which it may function. Many malicious functions of an application may be dormant until triggered at some future time and may not be detected during runtime analysis of a closed application for which no knowledge of the actual code is available. For example, the malware can be activated by a command coming from the outside. This cannot be detected during the run time analysis lacking the knowledge that the code may receive a command from the outside.
For example, it is possible and easy to develop a widget for SmartTV that sends a large number of HTTP Requests to the URL, which was received through a backdoor. This may create a distributed denial of service attack emanating from a device which doesn't raise a suspicion. As a further example, it is possible and easy to create a malware application for the mobile phone that dials a premium phone number, or registers itself to paid services. This would inflate a customer's bill and lead him to a decision to leave a cellular provider.
It is therefore clear that it is necessary to provide a method and a system that overcomes the drawbacks of the prior arts, allowing a better and more in-depth analysis of potential threats contained in the software code of the application.
It is an object of the present invention to provide such a method and system, which performs a static code analysis (also known as “program analysis”) and inspects the code in its entirety.
It is another object of the invention to provide an inspection method and system which is capable of detecting a backdoor which can activate a malware.
Other objects and advantages of the invention will become apparent as the description proceeds.
The present invention relates to a method for assessing the level of security of an application to be uploaded to an App Store, comprising:
The invention also relates to a method for preventing the distribution of applications containing malicious codes through an App Store, comprising performing steps a) through d) above, and thereafter:
In one embodiment of the invention the method further comprises contacting the developer of the application to obtain clarification for suspicious behavior found in the software code. This further step may be conveniently used to avoid “false positives”, i.e., situations where innocuous software code may appear, upon an automated analysis, as if it were malicious or potentially malicious.
The invention is not limited to applications intended for any specific device and includes, inter alia, applications to be uploaded to the App Store which are intended for a device selected from among smart phones, tablet PCs or Smart TV.
The invention also encompasses a system for distributing applications through an App Store, comprising:
In the drawings:
The invention exploits the knowledge of the development platform of the application. For example the widgets for the Samsung Smart TV are developed using a special SmartTV SDK (www.samsungdforum.com), which also provides a development environment. The development environment sees the code of the developed application and can perform static analysis of the entire code to detect the potential malicious patterns.
The invention allows exploiting the full knowledge possessed by the AppStore owner about the system, in order to detect whether an application uploaded to the AppStore is suspicious or not. According to the invention the various components of the system are assigned a security sensitivity grade, according to their function and the sensitivity that the AppStore owner attaches to them. For example the Smart TV comprises the following subsystems: Camera, Microphone, persistent storage, Tuner, Display and etc. Each subcomponent is assigned a security sensitivity grade. For example the Camera and persistent storage are assigned the grade 5 (i.e., the highest grade), the Tuner and Display are assigned the grade 0 (the lowest grade) and the Microphone the grade 1.
Now the system contains an Identifier which is capable of recognizing the API's related to each of the subsystem. The Identifier is an entity that contains a full specification of the system that includes a set of exposed APIs, along with the sensitivity grade of each subsystem belonging to a device. Given that data the Identifier is capable to inspect each line of code and to calculate the sensitivity grade of the information flows emanating from that line, it may also specify the highest sensitivity grade as the one that represents said line. This Identifier is also capable of inspecting each line of the code and to calculate the maximum security sensitivity grade for each information flow emanating from a given line of code. Different Identifiers can be designed by the skilled person, as long as they fulfill the abovementioned role.
The AppStore security system also contains a full attack dictionary which is relevant for each specific device that may use applications downloaded from the AppStore. The attack dictionary can be developed by the AppStore owner or can be taken from an external source such as available from http://capec.mitre.org/data/slices/2000.html.
For each attack in the dictionary the AppStore security system contains the information about the system, which is needed to be known in order to recognize the attack. For example, if the attack is a sandbox penetration attempt, then the AppStore security system contains the information about how the sandbox is defined. For example, each widget that is installed on the system may perform file operations in the folder named WidgetFolder, and all the cache related to the widget is stored under the key uniquely identified by the widget name. The same is also true about the temporary files and downloads directory.
Now, as explained above, the AppStore security system is equipped with a Detector which for each specific attack is capable to see whether it is attempted in the code. The Detector is a software entity that is capable to detect whether the attack is attempted, regardless of the sensitivity grades. The data it uses is the attack dictionary and the system specification that includes more attack specific definitions, such as sandbox definitions and the like. Different Detectors can be designed by the skilled person, as long as they fulfill the abovementioned role. In the specific context of the sandbox the Detector needs to detect at least one information flow which contains a file access API that tries to access file outside the permitted area.
Thus, in the example of a Smart TV that comes with hardware such as a microphone, a camera, the capability to record from the screen, etc. the SDK according to the invention uses a restricted language, and the API used by the developer employs a semantic that is fully known to the AppStore owner. By knowing the functional specifications of the environment it is known that all the written widgets are running in the sandboxed environment. All this knowledge combined allows the AppStore security system to detect applications that touch various entities in the system such as the camera or microphone, attempts to penetrate the sandbox.
According to the invention the development environment (Smart TV for example) is augmented with a rule-based engine that performs static analysis of the code. Such static analysis detects and informs its user of any unusual behavior/performance of the application. For example:
Different rules may be applied as applicable for scrutinizing the code of the developed application, as will be apparent to the skilled person and, therefore is not described herein in detail, for the sake of brevity.
The method of the invention can be illustrated with reference to
The metadata produced by the development environment may contain the descriptive information about the developer of the application. The information includes origin IP, domain name, and other information that may help to identify the developer in the future.
In the example shown below the widget tries to get access to the restricted file by exploiting the existing security bug in the SmartTV. The static analyzer will analyze all the parameters in the widget and will detect that the parameter sendUrl contains potentially unsafe value.
All the above description has been provided for the purpose of illustration and is not meant to limit the invention in any way. The invention presents significant advantages over the existing prior art. For example it sees the entire code and therefore it wouldn't miss application states from which the attacks occur.