<p><a href="https://www.linkedin.com/in/annh">Jeff Atkinson</a>, Principal Security Engineer, Verizon Media<br/></p><p><b></b></p><p>Today we are excited to announce the release of <a href="https://github.com/theparanoids/spicy-noise">Spicy Noise</a>. This open source project was developed to address the need to identify and monitor <a href="https://www.wireguard.com/">WireGuard</a> traffic at line speed with <a href="https://zeek.org/">Zeek</a>. The <a href="https://docs.zeek.org/projects/spicy">Spicy</a> framework was chosen to build the protocol parser needed for this project. Please share your questions and suggestions by <a href="https://github.com/theparanoids/spicy-noise/issues">filing an issue on Github</a>. </p><p><b></b></p><p>WireGuard was implemented on the <a href="http://www.noiseprotocol.org/">Noise Protocol Framework</a> to provide simple, fast, and secure cryptographic communication. Its popularity started within the Linux community due to its ability to run on Raspberry Pi and high end servers. The protocol has now been adopted and is being used cross platform. To explain how Spicy Noise works, let’s look at how Zeek and Spicy help monitor traffic.</p><p>Zeek is a network monitoring project that is robust and highly scalable. It supports multiple protocol analyzers on a standard install and provides invaluable telemetry for threat hunting and investigations. Zeek has been deployed on <a href="https://www.cspi.com/wp-content/uploads/2016/09/Berkeley-100GIntrusionDetection.pdf">100 gigabit networks</a>.</p><p>Spicy is a framework provided by the Zeek community to build new protocol analyzers. <a href="https://zeek.org/2020/05/18/announcing-the-new-spicy-parser-generator/">It is replacing Binpac</a> as a much simpler method to build protocol parsers. The framework has built-in integration with Zeek to enable analysis at line speed.<br/></p><p><b>How it works</b></p><p><a href="https://docs.zeek.org/en/master/intro/index.html#architecture">Zeek’s Architecture</a> begins by reading packets from the network. The packets are then routed to “Event Engines” which parse the packets and forward events containing details of the packet. These events are presented to the “Policy Script Interpreter” where the details from the event can be acted upon by Zeek scripts. There are many scripts which ship with Zeek to generate logs and raise notifications. Many of these logs and notifications are forwarded to the SIEM of a SOC for analysis.</p><p><b></b></p><p>To build the capability to parse WireGuard traffic a new “Event Engine” has been created. This is done with Spicy by defining how a packet is parsed and how events are created. Packet parsing is defined in a .spicy file. Events are defined in a .evt file which will forward the details extracted by the .spicy parser for the “Policy Script Interpreter”. A dynamic protocol detection signature has to be defined so Zeek knows how to route packets to the new Event Engine. Refer to the diagram below to understand the role of the .spicy and .evt files of the new WireGuard parser or “Event Engine”.</p><figure data-orig-width="960" data-orig-height="1060" class="tmblr-full"><img src="https://64.media.tumblr.com/61501380af7abeb8c7980ac48245c05d/a26b803c0835433f-98/s540x810/dd8436c511c994c628ba0978b1e266953041f194.png" alt="image" data-orig-width="960" data-orig-height="1060"/></figure><p><b>Technical Implementation</b></p><p>The first step to building a new “Event Engine” is to define how the packet is to be parsed. Referring to the <a href="https://www.wireguard.com/protocol/">WireGuard protocol</a> specification, there are four main UDP datagram structures. The four datagram structures defined are the Handshake Initiation, Handshake Response, Cookie Reply, and Transport Data. The diagram below depicts how the client and server communicate.</p><figure data-orig-width="626" data-orig-height="482" class="tmblr-full"><img src="https://64.media.tumblr.com/c2a0f0821e507d2e7c6594e69fb1a343/a26b803c0835433f-aa/s540x810/cc9aa616c41e4f50f8c975b30dcd45d75195202a.png" alt="image" data-orig-width="626" data-orig-height="482"/></figure><p><b><br/></b></p><p>We will focus on the first, Handshake Response, but the same method is used to apply to the other three packet structures. The following diagram from the <a href="https://www.wireguard.com/papers/wireguard.pdf">WireGuard whitepaper</a> illustrates the structure of the Handshake Initiation packet.</p><figure data-orig-width="794" data-orig-height="368" class="tmblr-full"><img src="https://64.media.tumblr.com/abdbb066b92fc98f564d2e0308686ef6/a26b803c0835433f-76/s540x810/456fa0d7a70fa286a5594a46d59e210bea6fe44f.png" alt="image" data-orig-width="794" data-orig-height="368"/></figure><p><b></b></p><p>The sections of the packet are defined with their respective sizes. These details are used in the .spicy file to define how Spicy will handle the packet. Note that the first field is the packet type and a value of 1 defines it as a Handshake Initiation structured packet. Below is a code snippet of wg-1.spicy from the repository. A type is created to define the fields and their size or delimiters.</p><figure data-orig-width="1256" data-orig-height="632" class="tmblr-full"><img src="https://64.media.tumblr.com/21419ab567307cf04cade5ff2624fbff/a26b803c0835433f-e6/s540x810/3f4aace78a25862ae574f262a8375429d41a2364.png" alt="image" data-orig-width="1256" data-orig-height="632"/></figure><p><b></b></p><p>Spicy uses wg-1.spicy as the first part of the “Event Engine” to parse packets. The next part needed is to define events in the .evt file. An event is created for each packet type to pass values from the “Event Engine” to the “Policy Script Interpreter”. </p><figure data-orig-width="1258" data-orig-height="244" class="tmblr-full"><img src="https://64.media.tumblr.com/63927e70d70d054ea384008fab434f97/a26b803c0835433f-dd/s540x810/21c7ff3e24cf33e1c63d75e64e976426e256ff8e.png" alt="image" data-orig-width="1258" data-orig-height="244"/></figure><p>The .evt file also includes an “Analyzer Setup” which defines the Analyzer_Name, Transport_Portocol and additional details if needed.<br/></p><figure data-orig-width="1242" data-orig-height="184" class="tmblr-full"><img src="https://64.media.tumblr.com/8fe0db3b0654a338f4e9cf21df029168/a26b803c0835433f-a5/s540x810/28f282967da85c02442074ea77b3d6d92b869cc4.png" alt="image" data-orig-width="1242" data-orig-height="184"/></figure><p><b></b></p><p>The Analyzer_Name is used by dynamic protocol detection (DPD). Zeek reads packets and compares them against DPD signatures to identify which Analyzer or “Event Engine” to use. The Wireguard DPD signature looks for the first byte of a UDP datagram to be 1 followed by the reserved zeros as defined in the protocol specification. Below is the DPD signature created for matching on the WireGuard Handshake_Initiation packet which is the first in the session.</p><figure data-orig-width="1260" data-orig-height="282" class="tmblr-full"><img src="https://64.media.tumblr.com/6faeb085c80447321cd601b261411e64/a26b803c0835433f-ce/s540x810/af32ceb316ee647acbbd956e124e4a90c959486f.png" alt="image" data-orig-width="1260" data-orig-height="282"/></figure><p><b></b></p><p>Now as Spicy or Zeek parse packets, anytime a packet is parsed by the Handshake_Initiation type it will generate an event. The event will include connection details stored in the $conn variable which is passed from the stream processor portion of the “Event Engine.” The additional fields are extracted from the packet as defined in the corresponding .spicy file type. These events are received by the “Policy Script Interpreter” and can be acted upon to create logs or raise notifications. Zeek scripts define which events to receive and what action is to be taken. The example below shows how the WireGuard::Initiation event can be used to set the service field in <a href="https://github.com/corelight/bro-cheatsheets/blob/master/Corelight-Bro-Cheatsheets-2.6.pdf">Zeek’s conn.log</a>.</p><figure data-orig-width="1256" data-orig-height="390" class="tmblr-full"><img src="https://64.media.tumblr.com/5af9fd67e9efaf9448d50fff89f35415/a26b803c0835433f-50/s540x810/eb27cb2f3562b05fc9545ed20e57067ac334637f.png" alt="image" data-orig-width="1256" data-orig-height="390"/></figure><p>The conn.log file will now have events with a service of WireGuard.<br/></p><figure data-orig-width="1252" data-orig-height="148" class="tmblr-full"><img src="https://64.media.tumblr.com/906ccfdfcf76ee1442d53f52548867e5/a26b803c0835433f-67/s540x810/136614001ac2972deeb1b081e0dd9c09454856d2.png" alt="image" data-orig-width="1252" data-orig-height="148"/></figure><p><b>Conclusion</b><br/></p><p><b></b></p><p>Wireguard provides an encrypted tunnel which can be used to circumvent security controls. Zeek and Spicy provide a solution to enhance network telemetry allowing better understanding of the traffic. Standard network analysis can be applied with an understanding that WireGuard is in use and encrypting the traffic.</p>