Tignes Ski Trip

After a busy year of work, the Modux team earned a well-earned break and headed off to Tignes in the French Alps for a week of skiing and team building.

Since the majority of the team work remotely, this was a great opportunity to get the team together in person.

The mornings were spent exploring the ski runs of Tignes. The more experienced skiers in the group enjoyed going off-piste to the Hidden Valley, while others in the group stayed closer to the resort and learned to ski on the beginner slopes.

For most of the week, skiing conditions were ideal with blue skies and plenty of fresh powder. While one day was a total white-out, that didn't put off some the more committed skiers.

After energetic mornings on the slopes, the group was welcomed back to the chalet with fresh cakes and spent the evenings playing Codenames, Linkee and other board games.

Hack Week Part 1: DIY network diode, Virtual Com Port Driver & GTFOBins for AWS

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 made a low-cost network diode with TCP over UDP tunnelling capabilities

• Thomas attempted to build a virtual COM port driver

• Lucas made a version of GTFOBins for AWS

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.

Ben's network diode within its 3D printed enclosure

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:

1. Intercept & then complete the Tx-side 3-way TCP handshake on the Tx Pi

2. Obtain the TCP payload data

3. Encode and encapsulate the TCP packet within a UDP packet stream

4. The Rx Pi then unpackages the TCP data payload and spoofs the onwards TCP handshake to the destination address

5. 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.

Serious security issues uncovered with the Enabot Smart Robot

Modux was recently commissioned by Which? to perform a security assessment of the Enabot Ebo Air, a small robotic device which moves around your home and lets you interact with pets and family remotely. We tested the robot to see how it would hold up against a cyber attack and found some serious security issues that could pose direct risks to the privacy of the end-user.

About the Enabot Ebo

The Enabot Air is billed as a smart companion robot that keeps your family company while you are away. You can chat through the robot; it can take photos and videos as well as recognise faces. By automatically detecting motion, the robot has the capability to act as a mobile security camera that the user can steer around the house via Wi-Fi. It’s controlled remotely through the smartphone app, where the user can view Ebo’s on-board camera.

Security Assessment

We wanted to understand any potential risks within the device itself and within the control applications for Android and iOS mobile devices. During our testing, amongst other issues, we uncovered two serious security flaws:

1. Shared password

The most severe security issue we found concerned the use of a shared password for the system administrator (root) user account. The Enabot Ebo robot comes pre-configured with a hardcoded system administrator password that is weak and shared across all devices. Anyone who knows this password and is suitably positioned on a users’ network could potentially connect to the robot over SSH and gain full administrative permissions. An attacker could then gain access to all underlying hardware functionality, including the camera or microphone.

Our team of testers found it was even possible to access the onboard SD card within the device and download photos and videos held on the card. Because of the shared password flaw, it would also be possible for a hacker to access logs on the device that disclosed the password of the Wi-Fi networks.

Remotely copying stored images off the device

Viewing captured image

With sufficient time spent reverse engineering the device firmware in use, it’s possible that a skilled individual could directly issue commands to the camera, microphone, speaker and motors -effectively gaining remote control of the device.

To discover this password, it was necessary to intercept a firmware update intended for the device and unpack it, revealing the protected (hashed) password. Cryptographic cracking attacks were then undertaken against this password hash until the cleartext version of the password was recovered.

Extraction of root password hash from firmware update file

While local network connectivity is required for initial access to the Enabot robot, our testers found that the onboard software provided could be used to establish a remote connection back to an external server via the Internet. This connection remains as long as the device does not run out of battery, even when the device is in ‘sleep’ mode. This could be used to set up a remote link to control the device over the Internet without the owner’s knowledge.

The end risk posed by this issue is complex, currently a degree of skill is required to obtain the password and determine the methods to gain access to the underlying SD card and to establish a remote external connection. A high level of skill would be required to reverse engineer the connections to the hardware in order to gain complete remote control of the device. However, due to the nature of the device and the attacks, if the password itself and the methods used were made public, the barrier to exploitation would drop considerably.

2. Missing secure-delete functionality

The second issue we identified was the lack of secure-delete functionality, which could potentially disclose information from the previous owner if the robot was resold.

We found that the robot did not effectively perform a secure deletion of data when a factory reset was initiated, leaving behind artifacts from previous uses of the device, including cleartext Wi-Fi passwords and session tokens from the previous owner.

Recovery of previous WiFi SSID and PSK, despite factory reset

These logs could be accessed via the hardcoded password discussed above. If someone were to buy one of these devices pre-owned, with relatively little technical skill, they could retrieve this sensitive information from the previous owner - allowing access to their enabot account or home WiFi network.

Our recommendations to fix the security issues

Modux worked with Which? to disclose the two issues to the manufacturer who have since addressed the risks and fixed the vulnerabilities.

To resolve the shared password issue, we recommended that the manufacturer should disable the remote access SSH service, since it does not appear to be in use during normal operation of the device. This was enacted by the manufacturer and confirmed by Modux.

We also recommended that the password for the system administrator account should be removed entirely or set to a unique value. If the password is required, it could either be included within the packaging of each device, in a similar manner to passwords issued with home routers, or could be set via the mobile application upon initial configuration.

To remediate the risk associated with the lack of secure-delete functionality, we recommended that a factory reset of the device should employ secure deletion functionality, overwriting all sensitive data multiple times to prevent its retrieval by unauthorised users.