Method for creating a honeypot

Abstract

According to various embodiments, a method for creating a honeypot is described, comprising sending requests to a target system, observing the responses of the target system to the requests, generating, according to the observed responses of the target system, a state machine model for the behavior of a network protocol according to which the target system responds to requests, and generating a honeypot that responds to requests according to the state machine model.

Description

[0001] The present disclosure relates to methods for creating a honeypot.

[0002] The number of networked data processing devices (including embedded devices) is increasing rapidly. A crucial aspect of all these devices—whether server computers on the internet or control units in the automotive or IoT sectors—is product security. Honeypots are decoys that mimic such valuable (target) systems to attract attackers and gather information about their attack strategies and objectives. Honeypots are an established threat analysis tool, particularly in enterprise IT, and are now also being used in the (Industrial) Internet of Things (IoT). While honeypots are a very useful tool for complementing cybersecurity strategies, implementing suitable honeypots for specific needs and target systems requires significant manual work by experts.

[0003] Therefore, approaches that allow for simpler deployment (especially configuration) of a suitable honeypot are desirable.

[0004] According to various embodiments, a method for creating a honeypot is provided, comprising: • Sending requests to a target system (e.g., API calls, service calls, shell commands); • Observing the target system's responses to the requests; • Generating, based on the observed responses of the target system, a state machine model for the behavior of a network protocol according to which the target system responds to requests (i.e., according to which it responds to requests from a communication partner with whom it communicates via a network interface); and • Creating a honeypot that responds to requests according to the state machine model.

[0005] According to various embodiments, a honeypot is thus automatically generated, for example, by estimating a state machine for a target system (including target software), in particular a network protocol used by the target system. Such an estimated state machine can then be used for an interactive honeypot. Porting and adapting such an estimated state machine so that it appears as if a network protocol with a specific software version is implemented can thus be done simply and automatically.

[0006] The method described above improves the impersonation of services by a honeypot without requiring manual implementation of service characteristics, specifically those of a network protocol used for the services. This allows for the deployment of a honeypot that appears realistic, for example, without the need for manual implementation of a server for a network protocol (or a service acting as a proxy). In particular, a new or updated version of a network protocol can be automatically incorporated into a honeypot. Thus, a honeypot can impersonate not only different versions of a service but also different implementations of that service.

[0007] The following are various examples of implementation.

[0008] Exemplary embodiment 1 is a method for creating a honeypot, as described above.

[0009] Embodiment 2 is the method according to embodiment 1, wherein the state machine model is generated by adapting a previously generated different state machine model for a different (e.g., non-critical) target system according to the observed reactions of the target system.

[0010] This allows the state machine model to be generated efficiently, especially when honeypots are created for different target systems.

[0011] Exemplary embodiment 3 is the method according to exemplary embodiment 2, wherein the other state machine model is generated by sending the and / or other requests to the other target system, observing reactions of the other target system to the or the other requests and generating the other state machine model according to the observed reactions of the other target system.

[0012] According to one embodiment, the state machine is learned using a two-stage process: first, a state machine is learned for a "base" target system (i.e., the "other" target system), and then this state machine is adapted for the actual target system. The state machine model for the base target system can be adapted for different target systems. It should be noted that in the general procedure described above, the "target system" can also refer to the base target system, and that creating a honeypot that responds to queries according to the state machine model includes, in this step, the adaptation to the target system.If the actual target system (of the honeypot) and the base target system do not differ significantly (for example, only version numbers or other information that is output are adjusted), then according to this interpretation, the honeypot will respond to requests "according to the state machine model" despite the adjustment - but it is then a honeypot for the actual target system and not for the base target system to which the requests were sent.

[0013] Embodiment 4 is the method according to embodiment 2 or 3, wherein the adaptation of the other state machine model comprises adapting a version of the network protocol whose behavior is modeled by the other state machine model, according to the observed reactions.

[0014] If necessary, the other state machine model only needs to be slightly modified, for example by supplementing it with features of the version of the network protocol used by the target system.

[0015] Embodiment 5 is the method according to one of embodiments 2 to 4, wherein the other state machine model is selected from a set of other state machine models for the other target system or one or more other target systems by checking whether the other state machine model fulfills the functions required for imitating the target system.

[0016] This allows the state machine model for the target system to be generated efficiently on the one hand, and on the other hand ensures that it is suitable for modeling the network protocol of the target system.

[0017] Embodiment 6 is the method according to one of embodiments 1 to 5, wherein the network protocol is an application layer network protocol.

[0018] Examples of this are HTTP (Hypertext Transfer Protocol) and SSH (Secure Shell). The honeypot can thus be created in such a way that it behaves credibly at the application layer.

[0019] Embodiment 7 is the method according to one of embodiments 1 to 6, wherein, when generating the state machine model, information about the target system that is to be kept secret is removed from the state machine model according to a secrecy criterion.

[0020] The state machine model can therefore be filtered with regard to information to be kept secret (such as passwords but also the operator of the honeypot) in order to avoid security problems for the target system (e.g. due to passwords becoming known).

[0021] Exemplary embodiment 8 is a honeypot generating device, configured to carry out the method according to one of the exemplary embodiments 1 to 7.

[0022] Embodiment 9 is a computer program with instructions which, when executed by a processor, cause the processor to perform a method according to one of embodiments 1 to 7.

[0023] Exemplary embodiment 10 is a computer-readable medium that stores instructions which, when executed by a processor, cause the processor to perform a method according to one of the exemplary embodiments 1 to 7.

[0024] In the drawings, similar reference numerals generally refer to the same parts in all the different views. The drawings are not necessarily to scale, with the emphasis generally placed on illustrating the principles of the invention. Various aspects are described in the following description with reference to the drawings. Fig. 1 shows a computer network Fig. Figure 2 illustrates the learning of a state machine for a network protocol. Fig. Figure 3 shows an example of a learned state machine for a network protocol. Fig. Figure 4 illustrates the creation of a honeypot according to one embodiment. Fig. Figure 5 shows a flowchart illustrating a method for creating a honeypot according to one embodiment.

[0025] The following detailed description refers to the accompanying drawings, which illustrate specific details and aspects of this disclosure in which the invention can be implemented. Other aspects may be used, and structural, logical, and electrical modifications may be made without deviating from the scope of the invention. The various aspects of this disclosure are not necessarily mutually exclusive, as some aspects of this disclosure may be combined with one or more other aspects of this disclosure to form new aspects.

[0026] Several examples are described in more detail below.

[0027] Fig. Figure 1 shows a computer network 100. The computer network 100 contains a variety of data processing devices 101-105, which are interconnected by communication links. The data processing devices 101-105 include, for example, server computers 101 and control units 102, as well as user terminals 103, 104.

[0028] Server computers 101 provide various services, such as websites, banking portals, etc. A control unit 102, for example, is a control device for a robotic device, such as a control unit in an autonomous vehicle. Server computers 101 and control units 102 thus fulfill different tasks, and typically, a user terminal device 103 or 104 can access a server computer 101 or a control unit 102. This is particularly the case when a server computer 101 offers a user functionality, such as a banking portal. However, a control unit 102 can also allow external access (e.g., for configuration). Depending on their task, server computers 101 and control units 102 can store security-relevant data and perform security-relevant tasks. Accordingly, they must be protected against attackers.For example, an attacker using one of the user terminal devices 104 could, through a successful attack, obtain secret data (such as keys), manipulate accounts, or even manipulate a control unit 102 in such a way that an accident occurs.

[0029] One security measure against such attacks is a so-called honeypot 106 (implemented by one of the data processing devices 105). It ostensibly provides functionality and thus serves as bait to attract potential attackers. However, it is isolated from confidential information or critical functionality, so that attacks against it occur in a controlled environment and the risk of impairing the actual functionality is minimized. This allows for the acquisition of knowledge about attacks on a target system (e.g., one of the server computers 101 or one of the control units 102) – and thus the threat landscape – which can then be addressed by implementing appropriate measures on the target system without endangering the target system itself.

[0030] A honeypot is a deceptive system that mimics a target system (also known as a "valuable target"). It tricks attackers into attacking the honeypot and revealing attack vectors that target the real valuable target. For example, a web server (or rather, the web server software) is a popular target for honeypots. Since web servers make up a large part of the public internet, it is important to continuously monitor threats targeting them.

[0031] Honeypots are particularly interesting for the automotive industry because there is very little data on actual attacks. Depending on various implementations, the Honeypot 106 can, for example, be implemented in a vehicle. The computer network 100 can then include at least part of the vehicle's internal network (but also a network that establishes connectivity to the vehicle from outside, such as a mobile network).

[0032] Honeypots are only effective, however, as long as there is no easy way for attackers to identify a potential target as a honeypot. Fingerprinting is a form of honeypot reconnaissance that an attacker can perform for such identification. Since most honeypots aim to impersonate a wide range of possible target systems, they must also be able to determine (for a credible imitation of a target system) the version of the network protocol that connects a given target system to the public internet. An example of such a network protocol (for communication from the honeypot to the outside, e.g., with other data processing devices) is Secure Shell (SSH).Since no honeypot can implement all possible versions of SSH servers, and most honeypots are implemented in a different programming language than real SSH servers, SSH libraries can be used that are manually adapted to the SSH messages used when an attacker connects.

[0033] In the case of SSH, the SSH protocol version exchange message can, for example, be made configurable: SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u7 For example, it imitates an SSH server for a Debian system, while SSH-2.0-0penSSH_8.5 QNX_Secure_Shell proposes an SSH server for a QNX operating system (e.g., in a handshake between client and server).

[0034] However, such superficial modifications can be easily detected by creating messages that are only one step further along in the protocol handshake. Furthermore, fingerprinting is also possible for other network protocol applications. To counteract this form of honeypot exploration, a honeypot can be restricted to imitating only a specific version (which limits its use) and manually capturing all protocol messages, or a real SSH server can be manually implemented to act as a proxy for the honeypot (which is complex and inefficient).

[0035] Therefore, according to various embodiments, an approach is provided that makes it possible to automatically adopt arbitrary implementations and versions of a network protocol for a honeypot implementation using learned state machines (i.e., to automatically create the honeypot so that it implements the network protocol according to the learned state machine).

[0036] In state machine learning, or automata learning, the state machine of a program or software (i.e., the learning objective) is typically unknown but can be learned by observing the resulting output with well-formulated inputs. State machine learning is divided into two dimensions: (1) activity and (2) visibility. Regarding activity, there are active and passive learning algorithms. While passive algorithms learn only from observing data traffic, such as recorded traffic between a client and a server, active algorithms can send new queries to the server, for example, to discover even more states. To ensure visibility, learning algorithms operate in either a black-box, grey-box, or white-box environment. In a white-box environment, everything within the software and code is visible to the algorithms.State machine learning can, for example, utilize additional static analysis tools. In the black-box setting, only the messages to the learning target can be created and the learning target's responses observed, without any knowledge of the software's internals. In the grey-box environment, lightweight instrumentation is typically compiled into the learning target to obtain some additional coverage information during runtime and to facilitate state estimation.

[0037] Learning algorithms for state machines can generate various models that represent the state machine for a target system. In general, state machines can be deterministic or non-deterministic. A deterministic finite automaton (DFA) exhibits deterministic behavior with respect to its state transitions; that is, a target state depends only on the input symbols and its output state. A non-deterministic finite automaton (NFA) does not follow the deterministic behavior of a DFA; that is, state transitions in an NFA from an identical output state with an identical input symbol can result in a different state transition. One of the most well-known algorithms for learning state machines is the L* algorithm.

[0038] Fig. Figure 2 illustrates the learning of a state machine for a network protocol.

[0039] The algorithm initially begins with a state machine 201 with a single state 203, e.g., "init" (or even with an empty machine). While trying messages from the SSH protocol, a next state 204, e.g., "closed", is (typically quickly) discovered, so the state machine is extended accordingly to a state machine 202 with two states.

[0040] The algorithm continues to run and eventually terminates, producing a state machine as its output, as shown in Fig. 3 shown.

[0041] Fig. Figure 3 shows an example of a learned state machine 300 for a network protocol.

[0042] This one, for example, has • a first state 301, e.g. “init”, • a second state 302, e.g. “prekex” • a third state 303, e.g. “kexed” • a fourth state 304, e.g. “keyed” and • a fifth state 305, e.g. “closed”.

[0043] The state transitions are triggered, for example, as follows: • 301 to 302: KEXINIT / KEXINIT, GUESSINIT / KEXINIT; SR_AUTH / KEXINIT, KEX30 / KEXINIT, SR_CONN / KEXINIT • 302 to 303: KEX30 / KEX31+NEWKEYS • 303 to 304: NEWKEYS / NO_RESP • 301 to 305: DISCONN / KEXINIT • 302 to 305: DISCONN / NO_CONN, OTHER / DISCONN • 303 to 305: DISCONN / NO_CONN, OTHER / DISCONN • 304 to 302: DISCONN / NO_CONN, SR_CONN / DISCONN, NEWKEYS / NO_CONN • 305 within itself: KEXINIT / UNIMPL, GUESSINIT / UNIMPL, SR_AUTH / ACCEPT, KEX30 / UNIMPL

[0044] Fig. Figure 4 illustrates the creation of a honeypot according to one embodiment.

[0045] The determination of a honeypot configuration (and, if applicable, the selection of an architecture for the honeypot to be configured) is performed by a honeypot generation device (or honeypot configuration device), which corresponds, for example, to one of the user terminal devices 104 (e.g., a computer with which a user (such as a system administrator) configures the honeypot 106 and instructs the data processing device 105 to provide the configured honeypot 106). The honeypot generation procedures described herein are therefore performed, for example, by such a honeypot generation device (e.g., automatically).

[0046] First, in 402, basic automata 403 are trained for different protocol implementations of one or more non-critical target systems 401 (e.g., by sending requests 413 to the one or more non-critical target systems (or "basic" target systems) 401 and observing the responses to the requests). Since different versions of a protocol implementation are similar, this pre-creation reduces the time required for a later version takeover.

[0047] Once a basic automaton is derived, a series of static and dynamic tests (404) are performed in step 405 to verify that the basic automaton fulfills all required functions. Additionally, unnecessary states are removed from the basic automaton in this step. This includes states that exist in only a few versions (these are relearned more quickly for a few versions during version increment than for the majority of versions) or simplification of very deep and complex protocol implementations (e.g., to comply with certain constraints such as execution time).

[0048] In 406, a suitable base automaton is then used to adopt one or more specific network protocol implementation versions running on a particular target system 407 (also called the "critical target") that is to be emulated by a honeypot. This target system 407 is probed (i.e., the responses of the target system 407 to the requests 414 are observed) by sending requests 414 to the target system 407—these may be the same or different requests as the requests 413 to the base target system(s)—and the automaton assumes the states corresponding to the specific version of the respective network protocol of the target system. The result is a customized state machine 408.

[0049] A simple HTTP example is the incorporation of header fields to include the correct service version: If a return header state in the base automaton Server: Apache / 2.4 returns the state machine adapted to a target system with Ubuntu Server. Server: Apache / 2.4.29 (Ubuntu) return and the state machine adapted to a target system with Windows, for example Server: Apache / 2.4.33 (Win32). return.

[0050] Since the version takeover (i.e., the adaptation of the base state machine to the target system in 406) probes an actual target system 407, which is later mimicked by the honeypot, meaningful data in 409 is filtered out from the adapted state machine 408 to prevent data leaks and reputational damage.

[0051] For example, the learning algorithm might find a state transition to successfully authorize itself in a login state. To prevent an attacker from discovering legitimate login credentials (e.g., via a brute-force attack), the adapted state machine 408 is configured (i.e., modified during filtering 409) to distribute login credentials randomly.

[0052] Another example is that a system intentionally made vulnerable (in this case, the honeypot) typically must not contain any references to, for example, company names, as this could damage the reputation of the respective company. These can be removed during filtering.

[0053] A state machine determined in this way (especially filtered) can then be used to configure a Honeypot 412, which imitates freely configurable network services (with regard to network protocol).

[0054] This is done, for example, by determining a suitable configuration 410, creating a container 411 with appropriate honeypot software and executing the honeypot software on a data processing device 105 in the computer network 100.

[0055] Honeypot 412 is implemented by using the discovered state machine to simulate a network protocol (e.g., for a service) (i.e., it imitates the network protocol according to the discovered state machine). Alternatively, states can be copied into a configuration of Honeypot 412. Honeypot 412 can then change states depending on the attacker's input and / or other internal conditions, e.g., a timeout for transitioning to a vulnerable state after 10 minutes of being attacked.

[0056] Static and dynamic 404 tests, as well as the filtering of sensitive data, can also be performed together in one step.

[0057] The static and dynamic 404 tests can also be omitted, but this can lead to an excessive number of generated basic automata (since none are removed based on the tests, and a learning algorithm, for example, is executed multiple times, thus producing several basic automata).

[0058] The 409 filtering step is also optional (if the risk of the honeypot containing sensitive data can be accepted).

[0059] In summary, a method is provided according to various embodiments, as described in Fig. 5 shown.

[0060] Fig. Figure 5 shows a flowchart 500, which represents a method for creating a honeypot according to one embodiment.

[0061] 501 responses are used to send requests to a target system (e.g., API calls, service calls, shell commands).

[0062] In 502, responses of the target system to the requests are observed.

[0063] In 503, a state machine model for the behavior of a network protocol is generated according to the observed reactions of the target system, according to which the target system responds to requests (i.e., according to which it responds to requests (or messages) from a communication partner with whom it communicates via a network interface).

[0064] In 504, a honeypot is created that responds to requests according to the state machine model (i.e., it operates or communicates, i.e., it reacts to messages, in particular, it answers).

[0065] The procedure of Fig.5. This can be performed by one or more computers with one or more data processing units. The term "data processing unit" can be understood as any type of entity that enables the processing of data or signals. The data or signals can, for example, be processed according to at least one (i.e., one or more than one) special function performed by the data processing unit. A data processing unit can include or be composed of an analog circuit, a digital circuit, a logic circuit, a microprocessor, a microcontroller, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), an integrated circuit, a programmable gate array (FPGA), or any combination thereof.Any other method for implementing the respective functions described in more detail herein can also be understood as a data processing unit or logic circuit arrangement. One or more of the process steps described in detail herein can be executed (e.g., implemented) by a data processing unit through one or more special functions performed by the data processing unit.

[0066] According to various explanations, the process is therefore implemented primarily using computers.

Claims

[1] A method for creating a honeypot (106, 412), comprising: Sending (501) requests (414) to a target system (407); Observing (502) reactions of the target system (407) to the requests (414); Generating (503), in accordance with the observed reactions of the target system (407), a state machine model (300) for the behavior of a network protocol according to which the target system (407) responds to requests (414); and Creating (504) a honeypot (106, 412) that responds to requests according to the state machine model (300). [2] The method of claim 1, wherein the state machine model (300) is generated by adapting a previously generated other state machine model (403) for another target system (401) according to the observed responses of the target system (407). [3] The method of claim 2, wherein the other state machine model (403) is generated by sending the and / or other requests to the other target system (401), observing responses of the other target system (401) to the requests or the other requests, and generating the other state machine model (403) according to the observed responses of the other target system (401). [4] The method of claim 2 or 3, wherein adapting the other state machine model (403) comprises adapting a version of the network protocol whose behavior the other state machine model (403) models according to the observed responses of the target system (407). [5] Method according to one of claims 2 to 4, wherein the other state machine model is selected from a set of other state machine models for the other target system (401) or one or more other target systems (401) based on a check as to whether the other state machine model fulfils functions required for the imitation of the target system (407). [6] The method of any one of claims 1 to 5, wherein the network protocol is an application layer network protocol. [7] Method according to one of claims 1 to 6, wherein, when generating the state machine model, information about the target system (407) to be kept secret is removed from the state machine model according to a secrecy criterion. [8] Honeypot generating device, arranged to carry out the method according to one of claims 1 to 7. [9] A computer program comprising instructions which, when executed by a processor, cause the processor to perform a method according to any one of claims 1 to 7. [10] A computer-readable medium storing instructions which, when executed by a processor, cause the processor to perform a method according to any one of claims 1 to 7.

Images