BOOFUZZ
BOOFUZZ
Abstract
Virtual Private Networks (VPNs) establish private and secure connections between a remote user and a network. Historically, VPNs often have high complexity, leading to vulnerabilities. WireGuard is a simpler, modern VPN protocol growing in popularity. It features reduced complexity and there are several independent user-space implementations. Despite its decreased complexity, there is still the potential for implementation bugs. Fuzzing is an effective technique to expose software vulnerabilities, by providing the target program with abnormal or unexpected inputs. There is little existing research on fuzzing being applied to user-space implementations of WireGuard, leaving a gap in security testing for WireGuard. This study implemented a fuzzer for the WireGuard handshake sequence, using the Boofuzz fuzzer. The fuzzer was run against Wireguard-go, a user-space WireGuard implementation. No vulnerabilities were found. Maintaining a persistent connection with Wireguard-go was found to be much more efficient. There were minimal effects on performance for changing the number of fields fuzzed. Wireguard-go was found to be robust and secure when faced with abnormal fuzzing inputs. The results have shown the value of fuzzing network protocols, and demonstrate a reproducible method for fuzzing other VPNs.
Research Questions
This study is guided by the following research questions.
Is Boofuzz able to effectively fuzz a modern network protocol, such as Wireguard-go?
How do different parameters, such as persistent connections, different mutation strategies, and differing numbers of fields impact the efficiency and performance of Boofuzz?
Does Wireguard-go implement strategies to reduce attack risk?
Objectives were created to address these questions
Objectives
• Configure Boofuzz that follows the Wireguard-go protocol so that a handshake initiation message is received and accepted by Wireguard-go.
• Investigate and discuss the effects of different parameters on Wireguard-go.
• Send Wireguard-go packets that have an invalid aspect and monitor the response.
Results
Two tests (random bytes and bad patterns) finished running before the three hours were up, regardless of sleeps being present or not.
The same number of tests were completed across all four mutation strategies in 1 hour for no sleeps between test cases (2389) and in 40 minutes for 0.5s sleeps between test cases (2392).
This shows that mutation strategy does not have much of an effect on Boofuzz’s performance and runtime.
One field being fuzzed finished running in just over an hour (1h 6 min 1s 12ms).
The other numbers of fields, which completed 3 hour runs, completed a similar number of test cases (range of 48). The range of test cases completed in an hour for all tests was 5, showing that the number of fields fuzzed does not have much of an effect on Boofuzz’s performance and runtime.
The persistent case with no sleeps proved to be almost 9x (8.999x) times more efficient than the non-persistent case. With 0.5s sleeps, the persistent case was more than 6x (6.351x) more efficient than the non-persistent case.
These results indicate that significant overhead is incurred when the process is restarted for each iteration.
Non-persistent execution should be reserved for cases where it is strictly necessary.