For one week at the start of every year, Modux employees take part in a Hack Week, where they take a break from their day-to-day work and instead come up with their own self-driven project. It’s an opportunity for the team to learn skills that are not directly applicable to their everyday work and role.
In this post, we’re going to look at three Hack Week projects from our technical team:
Ben's DIY network diode
Since most network diodes cost many thousands of pounds to buy, Ben, a Security Consultant at Modux, spent his hack week trying to make his own for a fraction of the cost.
Much like an LED, which acts as a one-way electrical component, a network diode restricts data flow to a single direction. This is commonly used to facilitate one-way data transfers between high-risk and low-risk networks. Unlike a network-based firewall, the majority of high-end diodes use physics to prevent return dataflow (such as laser emitters and receivers) instead of software-defined rules.
As well as the extremely high cost of network diodes currently on the market, their lack of extensibility as well as their unknown design and internal components motivated Ben to build his own.
After some trial and error, Ben arrived at the solution of using two or more fibre media converters in order to natively facilitate the transfer of data in only a single direction, whilst not requiring the installation of any additional software on either side of the diode. The network layout consisted of two primary media converters which were connected via RJ45 to the high-side and low-side clients and in turn the Tx (transmit) fibre connection from one side was connected to the Rx (receive) port on the other side, thus only allowing data to flow in one direction.
With the initial hardware design of the network diode successfully completed, Ben’s next task was to package up the solution. He 3D printed an enclosure with an integrated power distribution circuit, wired it up, and through the creative use of spare fibre-optic cable, routed the internal media converter status LEDs to the enclosure exterior.
Due to the nature of the TCP/IP stack, this solution, whilst simplistic, would only support UDP-based traffic, as the return network path does not exist in order to complete any TCP 3-way handshakes.
To combat this, Ben had the idea of tunnelling TCP-based traffic over the UDP protocol in order to bypass the handshake problem. This solution required the addition of intermediary network-capable devices on either end of the diode (in this case two Raspberry Pi’s) in order to do the following:
Intercept & then complete the Tx-side 3-way TCP handshake on the Tx Pi
Obtain the TCP payload data
Encode and encapsulate the TCP packet within a UDP packet stream
The Rx Pi then unpackages the TCP data payload and spoofs the onwards TCP handshake to the destination address
The unpackaged packet is modified to set the Rx Pi as the source and then send to the destination address
This solution also handles multiple data payload segments for multi-part communications and detects Tx connection close events (TCP FIN) and forwards them appropriately to the destination server.
The video below (slowed down for ease of viewing) demonstrates the tunnelling capabilities in action, using the netcat utility to perform multi-part communication from one side of the diode to the other, encapsulating the TCP traffic inside UDP and forwarding across relevant TCP flags.
Top-left: Raspberry Pi running Tx client application
Top-right: Raspberry Pi running Rx server application
Bottom-left: netcat utility client - sending data
Bottom-right: netcat utility server - receiving data
Ben's ideas for potential future additions to this project include:
Powerline isolation between Tx / Rx
A custom PCB instead of using consumer hardware
Support for multiple simultaneous connections from multiple users
Hardware security accreditation
Thomas's Virtual COM Port Driver
For his Hack Week project, Thomas, a Security Consultant at Modux, challenged himself to build a virtual COM port driver.
A driver is a piece of software that interfaces with the operating system on a computer that is normally used to control various hardware devices. A virtual COM port would simulate a COM connection without the presence of a physical device, instead routing traffic to other programs.
Thomas saw multiple potential applications for a COM port driver - it could be used for internal testing (by creating a virtual pair) or interface with software on virtual machines.
Going into this project, Thomas had no experience with the process of creating a driver, nor any experience of the programming languages Windows drivers are written in, so spent the first part of his week researching development processes and techniques.
Once he had a grasp on the basics of driver development, Thomas set up necessary software on his computer to allow for running and debugging drivers, including setting up a Windows virtual machine and configuring tools such as WinDbg.
Whilst ultimately Thomas wasn’t able to write a driver himself due to the complexity of driver software, he was able to find a functional open-source driver available on the internet, com0com. Thomas installed it on the virtual machine along with a number of Microsoft sample drivers.
“Over the week I discovered a lot about how drivers work and learned not to underestimate low level programming!” - Thomas
Lucas's new version of GTFOBins for AWS
Lucas, a Security Consultant at Modux, worked on recreating the resource GTFOBins for Amazon Web Services (AWS).
“GTFOBins provides a list of dangerous sudo permissions that can potentially be abused to escalate local privileges to that of the root level. GTFOBins could therefore present similarly dangerous AWS permissions that may allow a user to escalate their privileges to the root level.” Lucas
While this information largely already exists, Lucas realised that there did not appear to be a singular location collecting all known escalations and relevant permissions that also allows new submissions to be suggested by any internet user.
Using a similar format to GTFOBins, Lucas modified the site to accommodate the different format that information about AWS privilege escalations required:
With the site made, Lucas spent the remaining project time researching escalations, determining what privileges were necessary and which were useful for successful exploitation. Lucas also made it possible for his site to record any required configurations within the environment for the escalation to be possible.
Lucas will soon be launching his GTFOBins for AWS site on Github.