SYNful Knock – Analysis by FireEye

The initial infection vector does not appear to leverage a zero-day vulnerability. It is believed that the credentials are either default or discovered by the attacker in order to install the backdoor. However, the router’s position in the network makes it an ideal target for re-entry or further infection.

Finding backdoors within your network can be challenging; finding a router implant, even more so. This article not only dissects the implant, but also provides practical methods and tools for detecting a SYNful Knock compromise.

The impact of finding this implant on your network is severe and most likely indicates the presence of other footholds or compromised systems. This backdoor provides ample capability for the attacker to propagate and compromise other hosts and critical data using this as a very stealthy beachhead.

Implant Summary

The implant consists of a modified Cisco IOS image that allows the attacker to load different functional modules from the anonymity of the internet. The implant also provides unrestricted access using a secret backdoor password. Each of the modules are enabled via the HTTP protocol (not HTTPS), using a specifically crafted TCP packets sent to the routers interface. The packets have a nonstandard sequence and corresponding acknowledgment numbers.  The modules can manifest themselves as independent executable code or hooks within the routers IOS that provide functionality similar to the backdoor password. The backdoor password provides access to the router through the console and Telnet.

Known Affected Hardware

• Cisco 1841 router
• Cisco 2811 router
• Cisco 3825 router

Note: Our initial identification revealed that other models are likely affected based on the similarity in core functionality and IOS code base.

Persistence

The implant resides within a modified Cisco IOS image and, when loaded, maintains its persistence in the environment, even after a system reboot. However, any further modules loaded by the attacker will only exist in the router’s volatile memory and will not be available for use after reboot. From a forensic standpoint, if the modules are loaded in volatile memory, one can analyze them by obtaining a core dump of the router image[1].

Details

Modifications to the IOS binary can be broken down into the following four functions:

1. Modify the translation lookaside buffer (TLB) Read/Write attributes
2. Modify a legitimate IOS function to call and initialize the malware
3. Overwrite legitimate protocol handling functions with malicious code
4. Overwrite strings referenced by legitimate functions with strings used by the malware

TLB Read /Write Attributes

The malware forces all TLB Read and Write attributes to be Read-Write (RW). We believe this change is made to support the hooking of IOS functions by loaded modules. If the TLB attributes are not set to RW, then modifications to the cached pages may not be propagated to the original page in memory.

This is accomplished with two single-byte modifications made to the IOS function suspected to be responsible for configuring the TLB. The unmodified function set the first two bits of a register to 1, and the modified function sets the first three bits to 1. Mandiant believes that the third bit controls the Write permissions on the TLB entry. Figure 3 shows the modified instructions.

Figure 3: Modification to TLB attributes

This brings us to one of the host-based indicators discussed above. The TLB attributes can be examined using the enable mode command “show platform”. The TLB output of an unmodified IOS image is shown below in Figure 4.

Figure 4: TLB entries for a legitimate IOS image

If the router has been implanted with a modified IOS image, the RW attributes should be:

Figure 5: TLB entries for a modified IOS image

Depending on router hardware, certain ranges of memory addresses are typically read only executable code sections. The simplest way to determine if the router has been modified is to use the “show platform | include RO, Valid” command. The IOS image may have been tampered with to allow the modification of executable code if no results are displayed.

Initialize the Malware

To execute the malware during IOS image loading, Mandiant believes that a function associated with process scheduling was modified. This was chosen because the modified function is called early on during the IOS boot sequence, and is always called, as long as the IOS boots correctly. The target address of a function call is modified to point to the malware hook processing function. Our research has shown that the malware is initialized after the hook processing function checks the calling function is valid in the modified IOS. Now that the malware is up and running, it executes the original IOS function so no one is the wiser.

Mandiant believes the modified function is linked with the process scheduling task, the behavior is such that it enters an infinite loop once called. In addition, several of the sub functions reference strings associated with process scheduling, such as “Threshold: %s CPU Utilization(Total/Intr):…”.

Malware Executable Code Placement

To prevent the size of the image from changing, the malware overwrites several legitimate IOS functions with its own executable code. The attackers will examine the current functionality of the router and determine functions that can be overwritten without causing issues on the router. Thus, the overwritten functions will vary upon deployment.

Malware Strings and Configuration

Keeping with the theme mentioned above, since the image size cannot change, the implant also overwrote some reporting strings with its own configuration. This is another indicator of compromise that can be used for detection purposes. The legitimate strings that are overwritten are shown in Figure 6.

Figure 6: Strings associated with a valid function overwritten by the malware

The contents shown in Figure 6 were replaced with the contents shown below in Figure 7. Clearly visible are the malware’s strings included in the HTTP header used in Command and Control, along with the default password, which we have intentionally blanked. This will provide potential victims time to search their own networks for compromise and remediate the issue. Feel free to contact us via email at synfulknock-at-fireeye.com and we can provide the password after you suspect you have been compromised.

Figure 7: Malware strings

Again we arrive at another host-based indicator that can potentially be used to identify the presence of the implant; however, the location of the configuration strings may vary depending on deployment and must first be discovered.

A modified IOS image will produce a very different and suspicious result when running what would seem to be an ordinary IOS command.

Backdoor Password

The attacker can utilize the secret backdoor password in three different authentication scenarios. The implant will first check to see if the user input is the backdoor password. If so, access is granted. Otherwise, the implanted code will pass the credentials on for verification of potentially valid credentials. This ensures that the least amount of suspicion is raised. The following three instances were verified to enable access using the backdoor password:

Table 1:  Authentication functions in which the secret backdoor password can be used

Research has shown that SSH or HTTPS sessions do not provide access for the backdoor password. This could be a configuration issue and may vary on compromise.

Figure 8:  Subtle difference between authenticating using a legitimate password and the backdoor password

Network Command and Control (CnC)

The Command and Control portion of the implant is modular and allows additional functionality to be loaded into the IOS. The CnC functionality is stealthy because it requires a series of TCP trigger packets that the malware monitors for specific TCP header values and content. Even if filters are enabled on the router, the TCP trigger is processed by the malware. The malware will respond to trigger packets sent to three different addresses: the router interface, the broadcast IP, and the network address (the first IP in a subnet).

1.     To initiate the process, a uniquely crafted TCP SYN packet is sent to port 80 of the “implanted” router. It is important to note that the difference between the sequence and acknowledgment numbers must be set to 0xC123D. Also the ACK number doesn’t need to be zero.

Figure 9:  TCP SYN with sequence and acknowledgement offset of 0xC123D

1.     As typical with a 3-way handshake, the malware responds with a TCP SYN-ACK message acknowledging the first SYN message. However, the following conditions will be present:

• The differential between the acknowledgment and sequence numbers is now 0xC123E
• The following hard-coded TCP options are set:  “02 04 05 b4 01 01 04 02 01 03 03 05”
• The urgent pointer is also set to 0x0001 but the urgent flag is not set
• The malware also copies the acknowledgment number from the SYN packet for the sequence number. A typical server usually generates a random sequence number, thus this is not a standard TCP handshake.

These unique conditions are the anomalies that Mandiant used to write network detection signatures and tools.

Figure 10:  TCP SYN-ACK with sequence and acknowledgement offset of 0xC123E

1.     After the final ACK to complete the 3-way handshake, the controller then sends the following TCP message:

• The PUSH and ACK flags are set
• From the start of the TCP header, at offset 0x62, the string “text” is written
• The command shown below is at offset 0x67 from the TCP header

The command is in the following format:

The [CMD Data] is XOR encoded with a static key. There is a checksum algorithm, which is a four-byte XOR of the decoded [CMD Data].

Figure 11:  Controller command packet

1.     The malware response is encapsulated in the following static HTTP/HTML server response. Fortunately, the response from the malware is not XOR encoded and will be easy to decipher.

Figure 12:  Victim response

Supported Commands

We mentioned previous that this implant is modular. The five commands shown in the table below are used for loading additional modules and functionality on the victim router. A total of 100 additional modules can be loaded, however these modules are memory resident and will not persist after a reboot or reload.

Command messages set the first WORD (4-byte big-endian) to zero. The second WORD identifies the message type (values zero through four). All message types will start with the following eight bytes:

ID	Description
0	List loaded modules and their current state. The response contains a word representing the ID number followed by a word representing the state for each loaded module. Valid states are as follows: 00 – Memory is allocated 01 – Module is loaded into memory 02 – Module is activated For example, if the malware responds with this message: 00 00 00 03 00 00 02 Then, the message would indicate module 03 is in the activated state (02).
1	Allocate space for an additional module to be loaded. The command provides the module size for two required buffers. The malware allocates the memory for two buffers and returns the addresses in the response. The first buffer is the executable code, and we suspect that the second buffer is for configuration and storage. The syntax for this message follows this format: [WORD ID][WORD first buffer length][WORD second buffer length] An example command that tells the malware to allocate 0x0C bytes for the first buffer and 0x90 bytes for the second buffer of module ID 0x02: 00 00 00 02 00 00 00 0C 00 00 00 90 An example response from the server shows the first buffer is at memory address 0x66012C4C and the second is at 0x650DCD20: 66 01 2C 4C 65 0D CD 20 After executing this command, the module state is set to zero.
2	Populate the memory allocated for the module. This command is used to populate the executable code and suspected configuration data. [0x80 Bytes hook data][WORD first buffer length][WORD second buffer length] [First buffer…][Second buffer…] Similar to how the default password hook functions, the hook data buffer is used to inject additional hooks into the IOS. The hook buffer provides addresses within the IOS where hooks should be installed, and the code that should be run when the hooks are executed. After executing this command, the module state is set to one.
3	Activate a loaded module. The malware parses the hook data buffer and creates the necessary hooks within the OS to execute a module. The only argument is a WORD representing the module ID. After executing this command, the module state is set to two.
4	Remove a module. The memory allocated for the module is released and the state is set to zero. The module will no longer show up in the active modules command.

Table 2: Supported Commands

If the first WORD of a message is not zero, the code associated with the module ID of the first WORD is executed. This enables the execution of code that is not hooked into an IOS function.

Conclusion

We hope that this post has advanced the understanding of this flexible and stealthy router implant. It should be evident now that this attack vector is very much a reality and will most likely grow in popularity and prevalence. In the next part of this series, we will examine methods that can be used to passively and actively detect this implant.

 

The following blog entry shows how to produce a Cisco IOS core dump: http://blogs.cisco.com/security/offline-analysis-of-ios-image-integrity