Detecting unsecure data flow in automation task programs

An automation task program is inspected for unsecure data flow. The task program is parsed to generate a parse tree, which is visited to generate control flow graphs of functions of the task program. The control flow graphs have nodes, which have domain-agnostic intermediate representations. The control flow graphs are connected to form an intermediate control flow graph. The task program is deemed to have an unsecure data flow when data is detected to flow from a data source to a data sink, with the data source and the data sink forming a source-sink pair that is indicative of an unsecure data flow.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to device security, and more particularly but not exclusively to automation task programs.

2. Description of the Background Art

As its name indicates, an automation task program (“task program”) comprises instructions that are executed by a device to perform a particular task. In the context of industrial robots, a task program comprises instructions that when executed cause a robot to perform a mechanical task, such as welding, pick-and-place, transport, assembly, or other manufacturing-related task on a factory floor. Task programs for industrial robots are also referred to herein as “industrial robot programs.”

An industrial robot program is written in an Industrial Robot Programming Language (IRPL). An IRPL is inherently different from general-purpose programming languages, such as C/C++, C#, Go, Python, and PHP programming languages. First, different industrial robot vendors have different, proprietary IRPLs. That is, an IRPL is typically domain-specific and proprietary to one vendor. Second, the semantic of a typical IRPL is typically unique and different from general-purpose programming languages. Third, an IRPL, compared to general-purpose programming languages, typically has fewer features that make it easier for the programmer to avoid introducing vulnerabilities (e.g., string manipulation, cryptographic primitives). These and other differences make it difficult to evaluate the security of industrial robot programs using techniques employed for programs written in a general-purpose programming language.

SUMMARY

In one embodiment, an automation task program is inspected for unsecure data flow. The task program is parsed to generate a parse tree, which is visited to generate control flow graphs of functions of the task program. The control flow graphs have nodes, which have domain-agnostic intermediate representations. The control flow graphs are connected to form an intermediate control flow graph. The task program is deemed to have an unsecure data flow when data is detected to flow from a data source to a data sink, with the data source and the data sink forming a source-sink pair that is indicative of an unsecure data flow.

DETAILED DESCRIPTION

FIG. 1is a logical diagram of an automation system150in accordance with an embodiment of the present invention. In the example ofFIG. 1, the automation system150is that of an industrial facility, such as a factory. The automation system150includes one or more robots151, a server170, and an evaluation system160. The robots151, the server170, the evaluation system160, and other devices of the automation system150communicates over a computer network155, which may be wired or wireless.

A robot151may comprise a commercially-available industrial robot, such as those from the ABB Robotics company, KUKA Robotics company, and other industrial robot vendors. A robot151may include one or more moveable members, such as arms, end effectors, and other movable mechanical structures. A robot151may include a control module152with a processor that executes instructions of a task program153to cause the robot151to move a moveable member to perform an automated task, such as to build a product, dispense liquid, transport or move a load, or other industrial automation task. The control module152may be integrated in the housing of the robot151or in a separate housing that is directly connected to the robot151.

In the example ofFIG. 1, the task program153is an industrial robot program that is written in a proprietary, domain-specific IRPL. The task program153is in source-code, human-readable form. The task program153may be written in the RAPID robot programming language, the KRL robot programming language, or other programming language for industrial robots. The task program153may be loaded onto the control module152of the corresponding robot151directly (e.g., from a local storage or input port of the control module152) or over the computer network155.

The server170may comprise computer hardware and associated software for providing file storage or other service to the robots151. In the example ofFIG. 1, the server170includes a storage device171that may store task programs153for loading onto the robots151over the computer network155. The storage device171may also store configuration files for the robots151.

An unsecure data flow is flow of data, from a data source to a data sink, that creates a vulnerability in a robot151. A data source is an instruction or a function that may receive untrustworthy data, whereas a data sink is an instruction or a function that operates on received data. In the present disclosure, “function” includes a procedure, a subroutine, or other callable code block in a task program. As can be appreciated, a function may comprise a plurality of instructions.

An unsecure data flow in a task program153may cause a robot151to move a moveable member (e.g., swing an arm) in an unsafe manner during operation, creating a physical safety issue that may harm personnel who work in the vicinity of the robot151. An unsecure data flow may also make the task program153susceptible to inadvertent programming errors. Additionally, an unsecure data flow poses a security risk that may be exploited by an attacker to maliciously control the robot151or to attack other devices connected to the computer network155.

Unsecure data flow may make the robot151vulnerable to externally-received untrustworthy data, such as data from outside the task program153. For example, a task program153may receive external inputs from files, communication interfaces (e.g., computer network155, serial communication bus, fieldbuses), a user interface of a teach pendant, or other external input source. Such external inputs to the robot151can be exploited by an attacker. For example, data files can be tampered with by malicious third-parties (e.g., contractors); inbound communication data can originate from compromised devices on the computer network155or other endpoints; and user interfaces of teach pendants can be manipulated by an insider.

Table 1 below summarizes example external inputs that may be exploited by an attacker.

The inventors identified at least four categories of sensitive data sinks, which may be an instruction or function that may render a task program vulnerable. “Data sinks” and “data sources” are also simply referred to herein as “sinks” and “sources”, respectively.

A first category of sensitive data sinks comprises instructions or functions that perform movement commands. More particularly, the first category of sensitive data sinks receives data that are used to control the trajectory of a moveable member of a robot. Data sinks of the first category are widely used as a way to control or influence a robot's movement from an external program. For example, MELFA robots from the Mitsubishi Electric company support an Mxt (move external) instruction, which allows a robot to be controlled by way of User Datagram Protocol (UDP) packets containing information about robot position. Similarly, the ABB Robotics company provides the Robotware Externally Guided Motion option, which allows an external device to perform direct motion control of the robot.

A second category of sensitive data sinks comprises instructions or functions that perform file and configuration handling. Tainted data received from a sensitive data source (e.g., network socket) may be used as part of the filename parameter of a file open or configuration open instruction without validation. This vulnerability enables a network attacker to control the name of the configuration file to be opened and read, allowing the attacker to access confidential information (e.g., intellectual property) stored in files or to modify information in configuration files. If the robot control module has a structured file system rather than a flat file system, this vulnerability may also lead to the classic directory traversal vulnerability.

A third category of sensitive data sinks comprises instructions or functions that perform file and configuration modification. Orthogonal to the second category of sensitive data sinks, untrustworthy data may be used as the content to be written in configuration files or passed as parameter to configuration setting functions. If data is not sanitized (e.g., checked against a white list or against an acceptable range), an attacker may overwrite configuration values in an unexpected and potentially unsecure way.

A fourth category of sensitive data sinks comprises instructions or functions that are called by name. More particularly, some IRPLs have the capability of resolving, at runtime and programmatically (e.g., by “late binding”), the names of the functions to be called. For example, a developer may use, in the RAPID robot programming language, the % fun_name % instruction in order to call a function, where “fun_name” is a variable containing the function to be called. If the fun_name variable originates from an untrusted data source and there is no input validation, the task program is vulnerable; an attacker may subvert the control flow of the task program, with varying effects according to the semantics of the loaded module.

Table 2 below summarizes the above-described sensitive data sinks by functionality.

Besides the presence of vulnerabilities, the complexity of IRPLs renders them susceptible to be used as a way to codify malicious functionalities. Malicious code, which are also referred to herein as “malware”, may steal information, drop and execute second-stage malware, or perform other malicious actions in the automation system150. The inventors identified at least two cases of malicious functionalities that can be implemented in an IRPL.

A first case is the information stealer malware. This is particularly relevant in industrial settings because both the configuration parameters and the task programs residing on the robot control module are considered high valuable intellectual property and are thus attractive targets for attackers. An information stealer malware may, for example, exfiltrate confidential information from local files through an outbound connection.

A second case is the dropper malware. This piece of malware allows the attacker to download and execute a second-stage malware. In one embodiment, the task program analyzer161is able to detect a dropper malware as a pattern. More particularly, the task program analyzer161may detect malware based on flow of data from a sensitive data source to a sensitive data sink, which is also referred to herein as a “source-sink pair”.

Table 3 below provides a summary of malware, including their actions, sensitive data source, and sensitive data sink.

In the example ofFIG. 1, the evaluation system160comprises computer hardware and associated software for detecting unsecure data flow in task programs153. The evaluation system160may include a task program analyzer161, which in one embodiment comprises instructions that are stored in a memory of the evaluation system160and executed by a processor of the evaluation system160to cause the evaluation system160to detect unsecure data flow in task programs153. More particularly, the task program analyzer161may receive a task program153(see arrow181), evaluate the task program153for unsecure data flows (see arrow182), and generate a result of the evaluation as an output152(see arrow183). The output152may indicate whether or not the task program153has an unsecure data flow. In one embodiment, the task program analyzer161performs data flow analysis between predetermined sensitive data sources and predetermined data sinks. The sensitive data sources may be defined as taint sources and the sensitive data sinks may be defined as taint sinks. The task program analyzer161may detect unsecure data flow in the task program153when data flow from a taint source to a taint sink that have been defined as a source-sink pair indicative of unsecure data flow. The source-sink pair may be indicated in the output152.

In response to detecting an unsecure data flow in a task program153, one or more corrective actions may be performed to prevent the task program153from being executed by a robot151. More particularly, the task program153may be put into quarantine, deleted, further analyzed for correction, etc. An alert, such as by email, log entry, visual indicator, alarm, etc. may also be raised in response to detecting an unsecure data flow.

FIG. 2is a logical diagram of the task program analyzer161in accordance with an embodiment of the present invention. In the example ofFIG. 2, the task program analyzer161comprises a plurality of parsers210(i.e.,210-1,210-2, . . . ,210-n), a control flow graph (CFG) generator212, an intermediate control flow graph (ICFG) generator214, and a dataflow analyzer216. In one embodiment, the task program analyzer161is a source code static analyzer. That is, the task program analyzer161evaluates the source code of a task program153statically, i.e., not at runtime.

In one embodiment, the task program analyzer161includes a parser210for each IRPL that is recognized by the task program analyzer161. For example, the task program analyzer161may include a parser210-1for parsing a task program written in the RAPID robot programming language, a parser210-2for parsing a task program written in the KRL robot programming language, etc.

A parser210is configured to receive a task program153(see arrow201) and parse the objects (e.g., functions, data, variables) of the task program to identify the syntactic relationships of the objects to each other according to the grammar of a particular IRPL. In the example ofFIG. 2, the parser210outputs a parse tree211(see arrow202), which represents the syntactic relationships between objects of the task program153.

In one embodiment, a parser210is implemented using the ANTLR Parser Generator. As can be appreciated, other parser generators may also be employed without detracting from the merits of the present invention. The ANTLR Parser Generator may be used to generate a lexical analyzer and a parser from a specification of a corresponding IRPL grammar. Grammars of an IRPL may be developed from information available in reference manuals of the IRPL, by looking at existing task programs written in the IRPL, etc. As a particular example, the official language reference for the RAPID robot programming language includes portions of the extended Backus-Naur form (EBNF) grammar, which may be ported to the ANTLR Parser Generator to generate the parser210-1for the RAPID robot programing language.

In one embodiment, the CFG generator212is configured to generate a plurality of CFGs213, a separate CFG213for each function of a parsed task program153. In the example ofFIG. 2, the CFG generator212visits the parse tree211of the parsed task program153(see arrow203) to build one or more CFGs213(see arrow204) in memory. Each node of a CFG213, which is also known as a “basic block”, contains a list of instructions. These instructions in the nodes of the CFG213are expressed in a language-independent, simplified, intermediate representation. That is, the instructions in the nodes of the CFG213are domain-agnostic and not specific to a particular IRPL. In one embodiment, the intermediate representations do not preserve the complete semantics of the instructions, but only their data flow. This is because, in one embodiment, the data flow is all that is needed for subsequent taint analysis performed using the dataflow analyzer216.

A modular approach may be taken to make the task program analyzer161easily extensible to recognize different IRPLs. As a particular example, the parser210and the CFG generator212, which may be implemented using the ANTLR Parser Generator visitor pattern, are tailored for a specific IRPL; the rest of the components of the task program analyzer161may be used for different IRPLs. A CFG may be simplified by running a set of IRPL-agnostic simplification passes, such adding CFG edges at “goto” statements, enforcing a single exit point/return for the CFG of each function, eliminating dead code blocks, etc.

The ICFG generator214is configured to generate an ICFG215(see arrow206), which connects the CFGs213together at function calls (see arrow205). In one embodiment, to build the ICFG215, the ICFG generator214visits the CFG213of each function and replaces nodes that have calls to functions defined in the same module (i.e., functions where the CFG213is available) with two CFG edges:(a) a first edge from the instruction immediately preceding the call to the entry basic block of the called CFG. To properly model the data flow from the function calls' actual parameters to the function's formal parameters, additional assignment nodes may be added along this first edge; and(b) a second edge from the exit basic block of the called CFG to the instruction following the call. Additional nodes may be added to correctly propagate the returned value to the caller, as well as to propagate the value of any output parameter declared as such in the function prototype.
With the above procedure, the ICFG generator214is used to build an extended control and data flow graph of all the functions in the target task program153being evaluated.

In one embodiment, the dataflow analyzer216is configured to analyze flow of data through the ICFG215to detect vulnerabilities caused by unsecure data flow in the task program153. The dataflow analyzer216may perform a forward-only dataflow analysis for taint tracking, which propagates taint information from sensitive data sources (e.g., inbound network data) towards all the basic blocks (i.e., nodes) in the task program153. Any input parameter of instructions and functions defined as data sinks (e.g., coordinates passed to robot-movement functions) may be checked to determine if the input parameter was tainted and by which data source. For each node in the ICFG215and for each variable, the analysis algorithm may compute the set of “taints”, i.e., the set of data sources that influenced the value of the variable.

A work-list based iterative algorithm may be used by the dataflow analyzer216to compute the result of the dataflow analysis. More particularly, the dataflow analysis may be defined by a carrier lattice that represents the taint information computed for each node of the ICFG215, and by a transfer function that defines how the taint information is propagated according to the semantics of each instruction. Elements in the carrier lattice may be the set of data sources that taint each variable. The transfer function may be defined as a function that propagates the taint information from the variables used by the instruction to the variables defined by the instruction. For example, the transfer function for a binary operation adds, to the taint information of the result, the union of the taint information of the two operands.

A function call may refer to another function that is not present in the task program being analyzed. For example, a function call may be to library functions or to functions defined in a file not available to the dataflow analyzer216. In that case, because the dataflow analyzer216does not have the function's CFG, the behavior of the function may be approximated by assuming that the function uses all parameters to compute the return value, if any. Hence, the default transfer function for the function call adds, to the taint information of the return value, the union of the taint information of all the parameters. However, there are library functions that may not work this way. More particularly, a library function may have output parameters and also accept parameters that do not influence the result in a security-sensitive way. To address this, function calls to library functions may be modeled in an IRPL-specific fashion. That is, for each supported IRPL and for each library function, parameters that are considered inputs and parameters that are considered outputs may be specified for taint propagation purposes.

The transfer function employed by the dataflow analyzer216may support the concept of sanitization, i.e., an operation that removes the taint from a variable. This reflects the behavior of functions that are used for input sanitization or functions that change the handled resource. For example, to monitor for data that is written (e.g., in the case of exfiltration) to a user-controlled file, the Close instruction may be considered as a sanitizer, because further uses of the same, closed file descriptor would necessarily refer to a different file. The dataflow analyzer216may support a set of sanitizers that are defined in a configuration data217.

In one embodiment, unsecure data flow to be detected in task programs are defined in terms of source-sink pairs. The source-sink pairs for detecting unsecure data flow may defined in the configuration data217, which is input to the dataflow analyzer216(see arrow208).

As a particular example pertaining to the KRL robot programming language for KUKA industrial robots, functions that receive data from the computer network via the KUKA.Ethernet KRL extension, functions starting with eki_get (e.g., eki_getreal), and functions belonging to the KUKA.Ethernet KRL XML package (e.g., EKX_GetlntegerElement) may be defined as sensitive data sources. Instructions involving movements, such as ptp, lin, and circ, may be defined as sensitive data sinks. As another particular example pertaining to the RAPID robot programming language for ABB robots, the SocketReceive (i.e., Str and RawData) instruction may be defined as a sensitive data source. Functions involving movement, file and configuration-handling, and late binding, such as those with Move, Open, OpenDir, SaveCfgData, WriteCfgData, Load, and CallByVar instructions, may be defined as sensitive data sinks. In general, sensitive data sources may be paired with sensitive data sinks to form predetermined source-sink pairs that are indicative of unsecure data flow.

To detect malware, source-sink pairs may be defined using data sources and data sinks that are shown in Table 3 above, for example.

Unsecure data flow is detected in a task program153when data flow from a data source to a data sink that are defined as a source-sink pair. The dataflow analyzer216may generate an output152(see arrow209) that indicates the result of evaluation of the task program153for unsecure data flow. The output152may indicate whether or not the task program153has one or more unsecure data flows and, when the task program153is detected to have an unsecure data flow, the corresponding source-sink pair.

As a particular example, to detect exfiltration of data in the RAPID robot programming language, taint information propagation from the ReadRawBytes instruction (and other device read instructions) to the SocketSend instruction may be monitored. The ReadRawBytes instruction and the SocketSend instruction may be defined as a source-sink pair. Unsecure data flow that is potentially by malware is detected when the taint information propagates from a function with the ReadRawBytes instruction to a function with the SocketSend instruction.

An example operation of the task program analyzer161is now described with reference toFIGS. 3-6. The example operation evaluates a target task program that has the following source code:

The target task program has two functions, namely functions proc1and proc2. The target task program is written in the RAPID robot programming language. The target task program is parsed with a corresponding parser210. The parsing of the target task program generates a parse tree, which is input to the CFG generator212to generate a CFG for each of the functions proc1and proc2.

FIG. 3is graphical representation of a CFG213-1of the function proc1andFIG. 4is a graphical representation of a CFG213-2of the function proc2. The CFG213-1has nodes301-305. Similarly, the CFG213-2has nodes311and312.

The ICFG generator214generates an ICFG215-1(seeFIG. 5) that connects the CFG213-1of the function proc1to the CFG213-2of the function proc2.FIG. 5is a graphical representation of the ICFG215-1. The function proc1makes a call to the function proc2(seeFIG. 3, arrow306), which is reflected by the node321of the ICFG215-1. The ICFG generator214generates a first edge341from the instruction of the node321to the node322, which is the entry basic block of the function proc2. The ICFG generator214also generates a second edge342from the node323, which is the exit basic block of the function proc2, to the end of the ICFG215-1. If another instruction follows the function proc2, the edge342would be connected to that instruction.

FIG. 6is a graphical representation of the ICFG215-1, showing data flow analysis performed by the dataflow analyzer216in the example operation. In the example operation, a source-sink pair for detecting an unsecure data flow has the SocketReceive instruction as the data source and the MoveAbsJ instruction as the data sink. The SocketReceive instruction is sensitive in that it receives data over a computer network, and the MoveAbsJ instruction is sensitive because it involves robot arm movement. Accordingly, an execution path from a function with the SocketReceive instruction to another function with the MoveAbsJ instruction is deemed to be an unsecure data flow.

In the example operation, the SocketReceive instruction is present in the function proc1(see alsoFIG. 3, node302) and the MoveAbsJ instruction is present in the function proc2(see alsoFIG. 4, node312). During data flow analysis, data is detected to flow from the SocketReceive instruction of the function proc1to the MoveAbsJ instruction of the function proc2(FIG. 6, arrows401-404). Accordingly, the target task program153is detected to have an unsecure data flow.

FIG. 7is a flow diagram of a method700of detecting unsecure data flow in a task program in accordance with an embodiment of the present invention. The method700may be performed by the task program analyzer161to evaluate a task program prior to the task program being loaded to a robot151.

In the example ofFIG. 7, a task program to be evaluated for unsecure data flow is received (step701) in the evaluation system160. There, the task program analyzer161parses the task program for readily identification of the objects of the task program and their relationships (step702). In one embodiment, the parsing of the task program generates a parse tree that is visited (i.e., traversed) by the task program analyzer161to identify functions of the task program and generate a CFG for each of the functions (step703). The task program analyzer161generates an ICFG that connects together the CFGs of the functions according to their calling relationships (step704). In one embodiment, unsecure data flows are defined as source-sink pairs. The task program analyzer161monitors data flow between predetermined data sources and data sinks (e.g., in the ICFG) and detects presence of unsecure data flow when data is detected to flow from a data source to a data sink that are designated as a source-sink pair for detecting an unsecure data flow (step705).

Although the above embodiments are described in the context of industrial robots, one of ordinary skill in the art will appreciate that, in light of the present disclosure, the present invention may be applied to other special-purpose devices that execute domain-specific programming languages. For example, the present invention is equally applicable to a network of Internet-of-Things (IOT) devices from different vendors. Such IOT devices may execute task programs that are written in different, special-purpose programming languages. In that case, task programs for the IOT devices may be evaluated for one or more unsecure data flow in the same manner as described above. More specifically, a task program for an IOT device may be parsed, a parse tree of the parsed task program may be visited to generate CFGs for each function of the task program, an ICFG of the CFGs may be generated, and data flow of the ICFG may be analyzed to detect an unsecure data flow code sequence as described above for task programs of industrial robots.

Referring now toFIG. 8, there is shown a logical diagram of a computer system100that may be employed with embodiments of the present invention. The computer system100may be employed as the evaluation system160or another computer described herein. The computer system100may have fewer or more components to meet the needs of a particular cybersecurity application. The computer system100may include one or more processors101. The computer system100may have one or more buses103coupling its various components. The computer system100may include one or more user input devices102(e.g., keyboard, mouse), one or more data storage devices106(e.g., hard drive, optical disk, solid state drive), a display screen104(e.g., liquid crystal display, flat panel monitor), a computer network interface105(e.g., network adapter, modem), and a main memory108(e.g., random access memory). The computer network interface105may be coupled to a computer network, which in this example is the computer network155.

The computer system100is a particular machine as programmed with one or more software modules, comprising instructions stored non-transitory in the main memory108for execution by the processor101to cause the computer system100to perform corresponding programmed steps. An article of manufacture may be embodied as computer-readable storage medium including instructions that when executed by the processor101cause the computer system100to be operable to perform the functions of the one or more software modules. In one embodiment where the computer system100is configured as the evaluation system160, the software modules comprise a task program analyzer161.

Systems and methods for detecting unsecure data flow in task programs have been disclosed. While specific embodiments of the present invention have been provided, it is to be understood that these embodiments are for illustration purposes and not limiting. Many additional embodiments will be apparent to persons of ordinary skill in the art reading this disclosure.