US20160142437A1

US20160142437A1 - Method and system for preventing injection-type attacks in a web based operating system

Info

Publication number: US20160142437A1
Application number: US14/542,943
Authority: US
Inventors: Evgeny BESKROVNY; Yaacov HOCH; Maya MAIMON
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2014-11-17
Filing date: 2014-11-17
Publication date: 2016-05-19
Also published as: US10542040B2; US20170357804A1; KR20160058673A

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

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

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.
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.
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.
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.
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.
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'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.

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.
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.
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'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.
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.
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.
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.
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.
It is still another object of the present invention to provide such method and system in a simple and compact manner.
Other advantages of the present invention will become apparent as the description proceeds.

SUMMARY OF THE INVENTION

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.
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.
Preferably, said first or second invariants data of the HTML pages, is the DOM tree of the HTML pages.
Preferably, said monitoring module is a part of said web-based OS.
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.
Preferably, the monitoring module is a part of the web based OS rendering engine.
Preferably, all updates to said widget, said metadata file, and said web based OS are performed by the App-Store.
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.
Preferably, the web based OS is the Tizen OS.
Preferably, the first or second invariants data are a partial relative to the entire invariants data of the widget, respectively.
Preferably, the metadata file is encoded, before supplying the same to the device.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings:

FIG. 1 shows in block diagram form a typical prior art system for running a widget within a device;

FIG. 2 illustrates a portion of the process of the invention, as performed at the App-Store;

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

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

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.
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.
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.
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.
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'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.
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.
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'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.
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.
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'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.
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.
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's invariants, and this modification is detectable at the device where the exploit has just taken place.

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'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.

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.
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.
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.
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.
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.
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.
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.
The monitoring module 160 which, as said, is present within the web based OS 170 is a part of the web rendering engine.
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'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^rdstage. 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

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.
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'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.
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.

Claims

1. 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.

2. The method according to claim 1, wherein 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.

3. The method according to claim 1, wherein said first or second invariants data of the HTML pages, is the DOM tree of the HTML pages.

4. The method according to claim 1, wherein said monitoring module is a part of said web-based OS.

5. The method according to claim 1, wherein 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.

6. The method according to claim 1, wherein the monitoring module is a part of the web based OS rendering engine.

7. The method according to claim 1, wherein all updates to said widget, said metadata file, and said web based OS are performed by the App-Store.

8. The method according to claim 1, which 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.

9. The method according to claim 1, wherein the web based OS is the Tizen OS.

10. The method according to claim 1, wherein the first or second invariants data are a partial relative to the entire invariants data of the widget, respectively.

11. The method according to claim 1, wherein the metadata file is encoded, before supplying the same to the device.