Introduction

Suricata is a widely used Network Intrusion Detection System. Rules can be written in order to detect patterns in communication flows in a network. We aim at testing Suricata’s ability to retrieve patterns in fragmented packets. The idea is to fragment and/or segment packets at various network layers during a communication. The tests are conducted on Suricata versions 6.0.9 (November 2022) and 7.0.5 (April 2024). The main application protocols tested are MS-RPC over SMB1 (integrity removed), TCP and IPv4. The article starts with the presentation of the configuration for Fragscapy, M&NTIS platform and Suricata. Then, we explain the methodology used in order to test the performance of the probe. Next, the results are shown, before finally, exposing a vulnerability discovered in Suricata.

Configuration

Fragscapy

Fragscapy is a tool created to perform network evasion attacks at different network levels of the OSI model. Its objective is to benchmark network security devices such as probes, firewalls, etc. against complex attacks. To this end, Fragscapy allows the combination of different fragmentations/segmentations methods during a network exchange. It can operate in proxy mode or locally. In this article, the former configuration is considered: it is configured to intercept packets from an attacker, split them as multiple fragmented packet and send them to the victim. Fragscapy will be detailed in a future blog article.

Usage of M&NTIS Platform

With the M&NTIS adversary emulation platform, we have created a network where an attacker (“attacker”) running on Ubuntu tries to communicate with a Windows victim machine (“vwindows”) running on Windows 2016 server. The machine running Fragscapy (“fragscapy”) is inserted between the two subnets “switchA” and “switchB”. As explained, it acts as a proxy, intercepting packets from the attacker to the Windows machine and applying modifications on the fly in a Man-in-the-Middle fashion. It updates the network streams in real-time to modify TCP seq/ack numbers when it changes packet sizes and integrity at different levels. All packets transiting between the “switchB” switch and the “vwindows” machine are mirrored to the Suricata machine (i.e. with the modifications made by Fragscapy).

DCE/RPC protocol

DCE/RPC (Distributed Computing Environment / Remote Procedure Calls) is a system developed for DCE that enables programmers to write distributed software as if it were running on a single computer, eliminating concerns about the underlying network code. MS-RPC is the Microsoft’s version of DCE/RPC, derivating from DCE 1.1 reference implementation. The keyword dcerpc in Suricata rules works for both MS-RPC and DCE/RPC.

We focus on the MS-RPC event opcode 50. It is used for the creation of a new user on the remote machine. The legitimate request codes each character of a username over two characters. For example, an ‘F’ will be translated to 46 00 in the packet content. Suricata’s rules focus on a command to create a user FAKE_USER_ROOT. This string will be translated in an MS-RPC packet to 46 00 41 00 4b 00 45 00 5f 00 55 00 53 00 45 00 52 00 5f 00 52 00 4f 00 4f 00 54 00.

rpcclient -U 'Login'%'Password' 192.168.0.5 --command "createdomuser FAKE_USER_ROOT"

This can be observed in a legitimate packet as seen in the following image:

To manually analyze this packet, check out packet number 49 in the legitimate PCAP. The two Suricata rules created for detecting and inspecting the user creation request with MS-RPC are focused on both the IP and dceprc levels:

alert dcerpc any any -> any any (dcerpc.stub_data; content:"F|00|A|00|K|00|E|00|_|00|U|00|S|00|E|00|R|00|_|00|R|00|O|00|O|00|T|00|"; sid:2;)
alert ip any any -> any any (content: "| 46 00 41 00 4b 00 45 00 5f 00 55 00 53 00 45 00 52 00 5f 00 52 00 4f 00 4f 00 54 00 |";  msg:"Alert: pattern: 'FAKE_USER_ROOT'."; sid:1000032; rev:1;)

If Suricata successfully reconstructs packet fragments, then it triggers an alert.

Methodology

To stress Suricata’s defragmentation engine, we focus the tests on three different fragmentation and segmentation techniques which are combined together:

• IPv4 fragmentation with a max size of 30 bytes,
• TCP segmentation with a max size of 20 bytes, and
• MS-RPC fragmentation with a max size of 10 bytes.

The maximum size for each fragment was chosen so that the username will be split into a minimum of 2 distinct packets. The combination results in 8 tests, including the case where no modifications are applied to the packets.

For each test, we check if Suricata detected the payload and if the packet successfully generated the creation of a user on the target Windows machine (i.e. we only consider packets that are still valid and understood despite their modifications and fragmentations). As it turns out, all packets generated by fragscapy during our tests were indeed understood by the server, and considered valid.

Results

The following table summarizes the test results. For each, we provide the live generated pcap file.

We observe three cases where the user creation is not detected by Suricata. It seems that IP fragmentation combined with any other modifications allows the bypass of the probe’s rules. Therefore, there is an issue with the transition from a reconstructed MS-RPC or TCP fragment/segment to the IP defragmentation engine.

The results show that the cleartext string is not detected at the IP level nor at the MS-RPC level. This shortcoming in Suricata’s engine opens the door to potential abuses and exploitations. For instance, an external actor could use this cleartext communication channel to interact with a compromised machine within the network without being detected. Also, it should be noted that there is an implementation, Samba, for Linux that understands user creation requests (however, in this implementation, the user is not created, and the server responds that the user already exists). By modifying the code or adding a backdoor in Samba’s code, it is possible to instrument this command to replace the username with a filename, and have the response send the file contents back, thus exfiltrating the file’s contents.

How to Test Yourself

To test this vulnerability yourself, you need to install Suricata version <= 7.0.5.

# If you are on Ubuntu, the current version is 7.0.5-0ubuntu0
$ sudo apt install suricata=7.0.5-0ubuntu0

# Create the detection rule for Suricata in ~/local.rules
$ echo "alert ip any any -> any any (content: \"| 46 00 41 00 4b 00 45 00 5f 00 55 00 53 00 45 00 52 00 5f 00 52 00 4f 00 4f 00 54 00 |\";  msg:\"Alert: pattern: 'FAKE_USER_ROOT'.\"; sid:1000032; rev:1;)" > ~/local.rules
$ echo "alert dcerpc any any -> any any (dcerpc.stub_data; content:\"F|00|A|00|K|00|E|00|_|00|U|00|S|00|E|00|R|00|_|00|R|00|O|00|O|00|T|00|\"; msg:\"Alert: pattern: 'FAKE_USER_ROOT'.\"; sid:2;)" >> ~/local.rules

# capture.pcap corresponds here to the combination of the 3 fragmentations/segmentations provided above
# i.e : download the pcap from test number 8 in the table
$ suricata -r capture.pcap

# Check if the FAKE_USER_ROOT pattern is present in eve.json
$ cat eve.json | grep "FAKE_USER_ROOT"

If nothing appears, Suricata has not detected the payload.

Vulnerability analysis

Suricata relies on the ID field at the IP layer in order to reconstruct fragmented packets. In our tests, Fragspapy fragments the packets using the next rule:

• the first, the second and the last fragment of packets have different ID and
• between the second and the last packet fragment, the ID is the same one used.

As a result, Suricata overwrites all new fragments to the corresponding ID in a table it handles. Therefore, the original fragmented packet cannot be reconstructed, leading to the vulnerability.

Conclusion

We have found a vulnerability in Suricata’s code. As a result, Suricata does not have the entire payload reconstructed. It allows an attacker to bypass pattern rules at least at the IP level. We have informed the Open Information Security Foundation (OISF), Suricata’s developers, so that this vulnerability can be patched. It has been fixed starting from Suricata version 7.0.6 and 6.0.20. The vulnerability is registered as CVE-2024-37151. We have thus shown that using Fragscapy and its attacks is effective in testing the performance of a network probe.

References

CVE-2024-37151

Suricata-release

IP-id-Reuse