Abstract:
A method for detecting a malicious code which is injected into the command stream of a widget running by a web-based OS at a device is disclosed. The method requires (a) analyzing the widget at an App-Store to determine first invariant data; (b) recording within a metadata file first invariant data; (c) associating said metadata file with said widget, and supplying said widget within a user device; (d) upon running said widget, activating a monitoring module, analyzing the running widget and determining by said module a second invariants data, and comparing respectively said second determined invariant data with said first determined invariants data; and (e) issuing an alert upon detection of a variation above a predefined value between said second determined invariant data and said first determined invariant data, respectively.

Description:
FIELD OF THE INVENTION 
       [0001]    The invention relates to the field of detecting exploitation of a system by the execution of malicious code. More specifically, the invention relates to a method and system for detecting the running of a malicious code which is injected to within in the execution context of a widget at a device having a web based operating system. 
       BACKGROUND OF THE INVENTION 
       [0002]    The web based operating system is an emerging technology which becomes more and more popular these days. A prominent example is the Tizen OS developed jointly by Samsung Electronics and Intel Corporation, targeting consumer devices such as smartphones and SmartTVs. 
         [0003]    A Web based operating system forms an execution environment, which is built around a web browser. This technology allows running within the device of widgets mainly written in HTML/JavaScript, said widgets are rendered by the runtime engine of the web browser. 
         [0004]    The widget is the most typical software code for running within the Web based operating system. As the Web based OS is typically designed for the operation of mobile devices (such as smartphones, tablet, etc.) and smartTVs, the various widgets are typically supplied to the within the relevant device from an App-Store, which is most commonly owned by the manufacturer of the specific device. For example, widgets for the Samsung SmartTV are supplied by the Samsung owned App-Store. 
         [0005]    As with any new platform, web based operating systems have their own unique set of security problems and weaknesses, many of them are inherent to the web OS architecture. The most prominent security weaknesses evolve from the lack of: (a) proper access control; (b) distinct and enforceable user privileges; and (c) a clear separation between the presentation layer and the business logic. 
         [0006]    Injection-type vulnerabilities, such as, XSS and HTML injections are the most critical vulnerabilities that affect web based applications. These vulnerabilities allow execution of malicious code in the execution context of the vulnerable application (i.e., widget). The abovementioned type of security weakness amplifies the severity of malicious injection to any widget, an injection that may potentially result in a broad system exploit and a complete security compromise within the consumer device. 
         [0007]    Measures against injection attacks have been studied by both the academia and the industry. There are two main approaches for protecting against injection attacks:
       Strengthening the input validation: Improper input validation is one of the root causes for injection vulnerabilities. Strengthening the validation can be done either generically by assigning metadata to all user inputs, or specifically by assigning different encodings to trusted and untrusted input sources. Both approaches require significant manual coding from the widget&#39;s author, and are prone to the same problems that affect standard input validations.   Limiting the scope in which scripts can execute: This can be performed either by use of a policy embedded in the HTML, and specifying those scripts that are allowed to run on the respective page. Alternatively, a context based policy can be applied to each script execution, respectively, in which only trusted inputs are allowed access security sensitive resources.       
 
         [0010]    The existing solutions target specific vulnerabilities and require extensive manual changes in existing applications or components used in the web application or widget. None of them target emerging threats such those arising in web based operating systems. None of the known solutions can handle generic HTML malicious injections. 
         [0011]    While some of said prior art techniques can be applied to the context of a web based OS, for example, the assigning metadata to the input channels, none of these techniques are specifically designed for a web based OS environment, and thus cannot take advantage of its unique characteristics, such as, the tight coupling between the App-Store and the web runtime that can be leveraged to achieve better security. 
         [0012]    Regardless of any specific type of the security weakness, the user expects the widget to behave in the same manner as intended by its author. Since there are many different types and subtypes of vulnerabilities that can modify the runtime behavior and a widget&#39;s user interface (UI), it is advantageous to address the vulnerability problem in its entirety, rather than to focus on the mitigation of the variety of specific threats. 
         [0013]    Furthermore, said existing solutions relate to regular web applications and are not suitable to the web based execution environment, therefore, a need arises to address those threats that are specific to web based operating systems, while taking into account its specific architecture. 
         [0014]    It is therefore an object of the present invention to provide a method and system for detecting and preventing the exploitation of injection-type vulnerabilities in a Web based Operating system environment. 
         [0015]    It is another object of the present invention to provide a generic method and system for detecting and preventing such exploitation, said method and system do not require any a-priori knowledge of the malicious code nature, behavior, or its structure. 
         [0016]    It is still another object of the invention to provide said method and system that are particularly suitable for operation in the context and environment of a web based operating system. 
         [0017]    It is still another object of the present invention to provide such method and system in a simple and compact manner. 
         [0018]    Other advantages of the present invention will become apparent as the description proceeds. 
       SUMMARY OF THE INVENTION 
       [0019]    The invention relates to a method for detecting a malicious code which is injected into the command stream of a widget running by a web-based OS at a device, which comprises: (a) analyzing the widget at an App-Store to determine a first collection of invariants; (b) recording within a metadata file first invariant data, said first invariant data being the determined first collection of invariants, a first structural representation of said invariants, or a first combination thereof; (c) associating said metadata file with said widget, and supplying said widget, including said associated metadata file to within a user device; (d) upon running said widget by a web based OS at said user device, activating a monitoring module, analyzing the running widget and determining by said module in a manner substantially the same as previously done at the App Store a second invariants data, said invariants data being a second collection of invariants, a second structural representation of said invariants, or a combination thereof, and comparing respectively said second determined invariant data with said first determined invariants data; and (e) issuing an alert upon detection of a variation above a predefined value between said second determined invariant data and said first determined invariant data, respectively. 
         [0020]    Preferably, said first or second invariants data comprises one or more of (a) HTML pages; (b) a Java Script (JS) functional call graph; (c) external JS libraries items that are used by the widget; and (d) The CSSs (Cascading Style Sheets) that are used by the widget. 
         [0021]    Preferably, said first or second invariants data of the HTML pages, is the DOM tree of the HTML pages. 
         [0022]    Preferably, said monitoring module is a part of said web-based OS. 
         [0023]    Preferably, when an update is introduced at the APP-Store to said widget, a corresponding updated metadata file is also prepared, and sent to the device together with said update to the widget. 
         [0024]    Preferably, the monitoring module is a part of the web based OS rendering engine. 
         [0025]    Preferably, all updates to said widget, said metadata file, and said web based OS are performed by the App-Store. 
         [0026]    Preferably, the method is generic in terms of being independent from the nature of the specific widget, and from the nature of the malicious code which is injected into the command stream of a widget. 
         [0027]    Preferably, the web based OS is the Tizen OS. 
         [0028]    Preferably, the first or second invariants data are a partial relative to the entire invariants data of the widget, respectively. 
         [0029]    Preferably, the metadata file is encoded, before supplying the same to the device. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0030]    In the drawings: 
           [0031]      FIG. 1  shows in block diagram form a typical prior art system for running a widget within a device; 
           [0032]      FIG. 2  illustrates a portion of the process of the invention, as performed at the App-Store; 
           [0033]      FIG. 3  illustrates in a general block diagram form how according to the present invention a device can detect injection of a malicious code into a widget execution context; and 
           [0034]      FIG. 5  illustrates a process at the device as performed with respect to the process of  FIG. 4  by the monitoring module, which operates within a web based OS (i.e., browser). 
       
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
       [0035]    A typical prior art system for running a widget within a device is shown in  FIG. 1 . As noted above, a web based OS  70  is a browser-like operating system for use in mobile devices, SmartTVs, and the like devices. When used as the operating system of the device  10 , it becomes the sole mechanism for initiating the running of widgets  12   a - 12   f  within the device. Moreover, the web based operating system  70  is generally supplied by the manufacturer of the device, which is the sole source for applying updates and revisions to the operating system—all those come from an entity  20  which is typically referred to in the art as the “App-Store”. The term App-Store was originally associated with a digital distribution platform for mobile applications on iOS, developed and maintained by Apple Inc. Later on, when many other manufacturers and distributors of mobile devices have adopted this type of platform, the meaning of the term was expanded such that it now refers to an application (or widget) distribution and update platform, which is maintained by any entity, typically by the manufacturer of the respective device  10 . The present application refers to the term App-Store in said expanded meaning. 
         [0036]    In any case, by its nature the App-store  20 , although receiving applications and widgets for distribution from many sources, is considered as a reliable entity whose task, among others, is to assure the authenticity, reliability, and security of the applications and widgets that are supplied to the end devices  10 . Furthermore, to a large extent, each user of a device uses a single App-Store  20 , which is typically owned and operated by the manufacturer of the respective device  10 . As also noted, the App-Store  20  of the device manufacturer is also the supplier of the web based OS  70 , when used to operate the device. These facts are utilized by the security system of the present invention. 
         [0037]    The system of the present invention detects and prevents injection of a malicious code to within the context of a widget running within a web based OS, and execution the same. Thus, the invention protects consumer devices having a web based operating system from malicious attacks. 
         [0038]    The solution by the present invention is based on the observation that when a widget executes properly, there are certain invariants that remain constant and preserved throughout the entire execution of the widget. 
         [0039]      FIG. 2  illustrates a portion of the process of the invention, as performed at the App-Store  20 . Initially, in step  70  the App-Store  20  receives the widget from the widget&#39;s author. In step  71 , the App-Store analyzes the widget to determine and extract a collection of invariants or their respective structure from the widget. In step  72 , the App-Store creates a metadata file which contains said collection of invariants, or one or more values that represent this collection of invariants. In step  73 , the App-Store  20  associates the metadata file with the respective widget, and conveys said widget and the associated metadata file to the device, optionally in an encoded form. 
         [0040]    There are a variety of invariant types that may be collected and used by said analyzing step  71 . For example, the following types of invariants are suitable for use by the present invention: (a) HTML pages; (b) the Java Script (JS) functional call graph; (c) external JS libraries items that are used by the widget; and (d) The CSSs (Cascading Style Sheets) that are used by the widget. 
         [0041]    For example, JavaScript functions that are used by the widget are not expected to change after the widget is uploaded to the App-Store. However when the widget&#39;s running context is exploited, a new code is added to the widget running context. As a result of this exploitation, the widget may execute one or more new JavaScript functions that were not originally present at the time when the widget was uploaded to App-Store  20 . Similarly, an exploit may create fake items in the HTML page or alternatively it may remove or disguise HTML objects that are part of the original page. As will be further elaborated hereinafter, a monitoring module at the device will detect these modifications to invariants of the widget, and upon such detection, the monitoring module will issue an alert, indicating that the system is exploited. 
         [0042]      FIG. 3  illustrates in a general block diagram form how according to the present invention a device  110  can detect injection of a malicious code into a widget  112  execution context. According to the present invention, the widget  112  which is conveyed to the device  110  (for example, from the App-Store  120  or from the manufacturer of the device  110 ) is associated with a respective meta data file  140 , which in turn comprises a list of invariants, or structural details relating to them, as determined by the analysis process at the App-Store  120 . The web based OS  170  which is supplied to the device  110  from the App-Store  120  (or from the manufacturer of the device) is also modified to include a monitoring module  160 . 
         [0043]    The monitoring module  160  is part of the web based OS rendering engine. When the widget is launched on the device the web runtime begins its execution and the widget&#39;s metadata file  140  is loaded to the web runtime along with its code. As will be further discussed hereinafter in more detail, upon execution of the widget, the monitoring module operates in run time by parsing the executed widget code to determine and verify the relevant invariants or their structure, respectively. The monitoring module  160  uses the parsing results to verify the validity, correctness, and accuracy of said invariants or their structure, respectively. This verification is performed by comparing the real time parsing results with the corresponding data within the metadata file  140 . 
         [0044]    If the verification shows a mismatch between the real time invariants and the respective data within the metadata file  140 , the monitoring module  160  issues an alert. Otherwise, the monitoring module concludes that the widget execution context is clean from a malicious code. 
         [0045]    The present invention is based on the following assumptions:
       There is a tight coupling between the App Store  120  and Web base OS  170  web runtime (preferably both are controlled by the same entity).   Widget exploitation will modify one of the widget&#39;s invariants, and this modification is detectable at the device where the exploit has just taken place.       
 
         [0048]    Both of said assumptions are correct in the context of a Web based OS, for the following reasons:
       A web based OS, contrary to a traditional operating system, is a relatively constrained environment. Regular users do not build code or install it at their will, but rather. most of the applications (widgets) come from a central, controlled App Store. While it is possible to bypass the App Store functionality, the majority of the users do not do so. Since the App Store  160  is a major (almost sole) source for applications (widgets) running on the respective devices, there is a tight coupling between App Store and web runtime. This coupling manifests itself in the format in which widgets are packaged, how they are delivered to the system, and in the protocol in which they are automatically updated.   Widget exploitation invariably changes some of the widget&#39;s invariants due to the fact that the only way a widget can misbehave maliciously is by executing a new code or rendering information which is in turn detectable by the system of the invention.       
 
         [0051]    When a widget first arrives App Store, a detailed analysis procedure is initiated to create the metadata file  140 . Preferably, the following description will discuss three types of invariants of which the respective lists or structures are included within the metadata file  140 . It should, however, that the invention is not limited to any type of invariants, as the invention may use any combination of said invariants, or other invariants that may be selected using similar principles. More specifically, the invention preferably suggests use of the following invariants: the JavaScript functional call graph, the HTML pages, and the list of external dependencies. 
         [0052]    The inclusion of call graph information within the metadata file  140 , and a respective verification in real time by the monitoring module  160  allows mitigation of the script injection vulnerabilities. The call graph of widget  112  may be extracted, for example, by use static code analysis techniques. It should be noted that the invention is not limited for operation with a complete call graph, as it is possible to perform the verification with a reduced call graph which contains only those parts of the code that are reachable from the input controls—this will reduce some of the overhead associated with the verification by invention. 
         [0053]    Another type of invariants that may be verified by the invention is the list of all functions and global variables. More specifically, the monitoring module  160  may verify during the execution of the widget any deviation from the expected list of invariants or from their respective structure, by performing verification against the metadata file  140 . Obviously, the more complete the invariants information is, the higher the accuracy of the detection becomes. 
         [0054]    The call graph analysis presents several challenges due to the dynamic nature of the Java Script. It is not always possible to build a call graph statically, because the graph itself may change during run time. Therefore, in an embodiment of the invention a dynamic call graph  140  is created at the App Store, and a dynamic verification is performed during run time at the device  110 . The dynamic analysis at the App Store may involve running the widget multiple times, and storing stacks of respective invariant information. The collected invariants information is the verified with respect to their fitting into the metadata file. Any stack of a call graph that does not fit is ignored, and is not included within the metadata file  140 . 
         [0055]    It is also possible to use crowdsourcing for the creation of the call graph. In this scenario the widget is executed multiple times on multiple devices, and then all the stacks are collected and compared with an existing call graph. All the paths that are not yet included within the existing call graph are added to the existing call graph. 
         [0056]    The inclusion of HTML within the metadata file  140  allows mitigation of HTML injection vulnerabilities. If during the widget execution the monitoring module  160  detects that the HTML DOM does not match to the one that is included within the metadata file  140 , an alert is issued. The creation of an HTML DOM, as is done at the App Store is relatively straightforward, as substantially all the HTML parsers have the functionality of building a DOM of a parsed HTML page. 
         [0057]    The list of all the external functions that are used by the widget may also be included within the metadata file  140 . This list the external functions includes, among others, the respective versions. This allows detection exploit where a malicious library having the same name is downloaded by an attacker to within the device. Another variant of this type of attack is where an older version of a same library which is known to have certain vulnerabilities is brought to device by an attacker. The inclusion of the appropriate version number within the metadata file ensures the integrity of the library, as well as of the widget itself. 
         [0058]    The monitoring module  160  which, as said, is present within the web based OS  170  is a part of the web rendering engine. 
         [0059]    In one preferred embodiment of the invention, when the widget is launched by the web runtime at the device  110 , the metadata file  140 , which is in fact a part of the widget, is loaded as well, and the web runtime begins a simultaneous execution of the monitoring module  160 . Due to this process, the widget&#39;s invariants data are extracted in a similar manner as was done at the App Store. The widget execution, according to the invention may comprise several additional steps as follows: (a) Identifying the dependencies (i.e., the code components that are necessary to put into the page so the page rendering will succeed) of the page (external JS, CSSs, images, and so on); (b) HTML parsing that includes building a DOM for rendering the page; and (c) JavaScript execution. The functionality of the monitoring unit  160  may be implemented in a form of special callbacks that are called at appropriate points within these three steps:
       During the widget execution, monitoring module  160  records and maintains a respective list of all (or a portion of) the libraries and CSSs that are loaded by the widget during run time. At the end of this process, a callback is performed to compare the list with the respective data within a metadata file  140 . If a deviation is detected in either names or versions of the libraries, an appropriate alert is triggered.   An HTML parsing functionality within the monitoring module  160  builds a DOM tree which is an entity against which a layout manager of the widget operates. Upon completion of the creation of the DOM tree, a callback is initiated, and the DOM or its parts are compared with the corresponding data within the metadata file  140 . If a deviation is found in the DOM structure or in the DOM elements, then an alert is generated.   The JS interpretation consists of 3 stages: (a) a parsing stage where the syntax is validated and respective binary representation is built; (b) a function resolution stage where all the functions are registered; and a code execution stage where the code is “played back”. Preferably, according to the present invention the call back is inserted into the 3 rd  stage. In this stage it is possible to check whether the stack matches the call graph as created at the App Store. At this stage it is also possible to determine whether a special predefined sensitive function is called, or whether there is an unexpected access to a security sensitive resource. In the case that one of these events is detected by the monitoring module  160 , an appropriate alert is triggered.       
 
       Example 
       [0063]      FIG. 4  illustrates a preferred procedure  600 , as performed at the App Store according to an embodiment of the invention. In step  601 , the widget is received at the App Store  120 . In step  602 , the widget is parsed, and a call graph of the widget is created. In step  603 , a list of DOMs for all the HTML pages is created. In step  604 , a list which details all the external dependencies (i.e., libraries and cascading stylesheets) that are used by the widget is created. Finally, in step  605 , the data that was accumulated in steps  602 ,  603 , and  604  is stored within the metadata file  140 . 
         [0064]      FIG. 5  illustrates a process at the device  110  as performed with respect to the process of  FIG. 4  by the monitoring module  140  which operates within a web based OS (i.e., browser). In step  701 , the monitoring module  140  performs a URL parsing of the running widget. In step  702 , the monitoring module  140  performs a protocol handling. In step  703 , the monitoring module performs an HTML parsing. More specifically, during this stage, the monitoring unit creates a list which summarizes all the external functions that are used by the widget during runtime, and compares this list with the corresponding list at the metadata file  160 . Furthermore, during this stage the monitoring unit  140  creates a DOM tree for the running widget, and when this is completed, the DOM tree is compared with the corresponding DOM tree at the metadata file  160 . If any deviation is found during this stage, an alert is issued. In step  704 , the JavaScript of the widget is executed. During the widget&#39;s code execution, the monitoring unit  140  compares the temporary function stack with the call graph as stored within the metadata file  140 , and also in this stage, when a deviation is detected, an alert is issued. In step  705 , a page layout calculation is performed. 
         [0065]    While some embodiments of the invention have been described by way of illustration, it will be apparent that the invention can be carried into practice with many modifications, variations and adaptations, and with the use of numerous equivalents or alternative solutions that are within the scope of persons skilled in the art, without departing from the spirit of the invention or exceeding the scope of the claims.