Have you ever wondered how seemingly innocent, everyday tools can be transformed into powerful hacking devices for use in cybersecurity engagements and adversary simulations? In today’s rapidly evolving digital world, exploring these possibilities is crucial to stay ahead of potential threats. In this research, we’ll delve into the fascinating process of turning a mundane VoIP USB device, typically used for communication, into a potent malware carrier capable of compromising multiple devices.
Unlike traditional USB storage devices, VoIP USB sticks often feature custom components and an RJ11 input, with a NAND chip serving as their primary storage. In many cases, the NAND chip storage is readonly, or in our example, partially readonly, which would seemingly protect the device from tampering. However, our research has uncovered a groundbreaking method that bypasses this readonly partition, allowing us to host malware on an alternative location within the device.
Imagine a world where a simple USB stick, commonly used for VoIP communication, can be weaponized by an attacker to infiltrate and backdoor a user’s system, leading to a widespread compromise of numerous devices. As we take you through this eye-opening journey, we’ll unveil the steps to convert a seemingly harmless VoIP USB stick into a formidable hacking tool. By understanding these techniques, you’ll gain valuable insights into the potential vulnerabilities present in everyday devices and learn how to protect yourself and your organization from such threats.
So, let’s dive in and explore the world of Red Teaming through this innovative research on exploiting VoIP USB devices for remote code execution, bypassing readonly partitions, and hosting malware in unexpected locations!
I am convinced that any device has the potential to become an attack vector, ranging from smartwatches and USB adapters to custom USB drives. While visiting a hardware store, I encountered a peculiar item that I had never seen before – the Magic Jack USB stick:
To be honest, I impulsively purchased it as soon as I saw the “Never Pay a Monthly Phone Bill Again!” slogan ?. However, upon returning home and examining it more closely, I realized that it could potentially serve as a Swiss army knife for hackers due to several reasons. First, its inconspicuous appearance; it resembles a typical USB drive, and even researching the brand yields ordinary information. This can easily lure victims into using it, as they would be enticed by the “Never Pay a Monthly Phone Bill Again!” promise, just like I was. Secondly, the inclusion of an RJ11 LAN port could be repurposed for nefarious activities if subjected to in-depth research, such as network sniffing or even more malicious acts:
Unfortunately, chips like these often have write protection features such as OTP (one-time programmable) or WORM (write once read many). In general, these mechanisms allow vendors to install their software directly onto the chip, after which it cannot be rewritten (at least for the time being). As a result, it can be difficult for us to modify the chip’s contents. However, I am interested in thoroughly examining this issue. To do so, I have analyzed the chip at both the hardware and software levels.
During the analysis of the MagicJack device, I encountered challenges in clearly identifying certain components, including the NAND flash memory. However, I was able to utilize the camera on an Apple iPhone to capture a clear image of the component by adjusting the exposure and contrast settings. In order to further understand the functionality of the Hynix HY27US08561A NAND flash memory, I consulted the data sheet for the component. The data sheet provided valuable information on the read and write protections that were in place by default on the chip.
Upon reviewing the data sheet, I discovered several interesting details that helped to answer my primary research question, namely whether the chip could be programmed.
The OTP (one-time programmable) feature is an important security measure that can be applied to devices like the MagicJack in order to prevent software replacement or manipulation. This feature ensures that the original software on the device cannot be overwritten, thereby protecting the device from potential threats.
On the other hand, the “Program/Erase locked during Power transitions” feature is primarily a data integrity protection measure. While it may not be considered a security protection in the strictest sense, it can provide some level of protection against certain types of fault injection attacks that involve manipulating the USB bus or the power supply of the host computer.
By locking the program and erase operations during power transitions, the feature helps to prevent data loss or corruption that could result from power-related issues, such as voltage spikes or other power-related disturbances. In this sense, it can enhance the integrity of the data stored on the device.
Now that we have gathered information about the potential data protection mechanisms that may be in place, the next step is to connect the device to a laptop and begin analyzing it from a software perspective.
As shown in the picture above, once the user inserts the magicJack USB stick, a window pops up immediately displaying the software needed to access it. However, since it’s a bit outdated, it doesn’t work on my laptop. Nevertheless, I began to investigate the partitions that were mounted on my laptop to see if any additional ones were added to the original one, and I found the following:
Upon examination, it is evident that the chip comprises of two partitions, specifically:
Of the two, disk5 is the larger partition and is mounted as a CD on our Apple machine, while the other partition is formatted with an Apple partition scheme. It is possible that the magicJack USB stick automatically detects the operating system and mounts its partition accordingly, however, we must verify our permissions on each partition to determine which is writable and which is not. Consequently, my initial attempt was to access the standard partition which was mounted at /Volumes/magicJack, where I discovered the following stored files:
Then I mounted it to a Linux device, and I found that the magicJack threw windows executable and DLL files as a proof that it doesn’t support Linux in this system and if the magicJack wasn’t able to determine which OS being used, it will throw windows version software:
After mounting the magicJack on a Linux device, I discovered that it contains Windows executable and DLL files, indicating that it does not support Linux in this system. Furthermore, if the magicJack fails to detect the operating system being used, it will install the Windows version of the software.
In pursuit of our main objective, our next step is to locate a writable partition on the USB stick. However, due to the system incorrectly identifying the device as a CD-ROM, we will not be able to write to it directly. Our initial course of action, therefore, will be to conduct an analysis to determine the type of CD with which we are dealing and investigate whether it is possible to circumvent this issue by sending low-level commands. For this process, we will be using Linux Debian, as certain tools may not be compatible with other Unix-based operating systems like macOS.
In this scenario, the USB partition containing the software is intentionally set to be non-writable by some vendors. This is done by installing firmware that causes the system to recognize the USB partition as a CD-ROM, thus preventing any software manipulation. However, it may be possible to extract the firmware by removing the chipset, although this is beyond the scope of our current objective.
Our primary goal is to find a way to directly write to the magicJack device. As a final attempt before moving on, we attempted to send low-level SCSI commands to the identified CD-ROM device. If successful, we could potentially perform a low-level reset on the USB stick in order to create a writable partition.
In the following example, we attempted to communicate with the USB stick in a low-level manner using a SCSI command. However, it appears that the device did not respond to the command.
We attempted to communicate with a USB stick that the system identified as a CD-ROM device by sending two commands using the sg_raw utility. The first command sent was the REPORT KEY command, which requests the USB stick to send information about access controls, copy protection, corrupted sectors, and other security features. We followed this command with a series of NOP ’00’ bits in an attempt to trigger errors on the remote device and reset it to its original state.
For the second command sent with sg_raw, we used the WRITE command, which is designed to write data to the device. The ’10’ byte in the command is the opcode for the WRITE command in the SCSI command set. We attempted to write empty data (i.e., all zeros) to the remote memory, but unfortunately, neither of these commands achieved our objective of making the USB stick writeable.
Returning to our Apple device, we have made the decision to revisit the other partition that we previously identified. Upon inspection, we discovered that the partition is writable, which indicates a misconfiguration. Since a portion of the memory is writable, it is possible for us to easily modify its contents and even change its file system. Our focus is specifically on Apple devices, particularly MacBook computers. As a result, we intend to reformat the partition to utilize the Apple MacOS Extended file system.
After mounting the partition, we discovered that it was indeed empty. Our next step was to create a clone of the original application by copying the folder’s background and application icon. This resulted in the creation of an Apple application that executes a command. Prior to this, we completed the necessary formatting and renamed the application to closely resemble the original, while still allowing it to be easily identified by its index (e.g. “magicJak-1”). The end result of these actions is as follows:
In the attached photo, you can see that we successfully created a clone of the original application on the same USB stick. This clone is virtually indistinguishable from the original, with the exception of a single character “K” added to the name of the USB. Additionally, we implemented a hidden trick to further conceal the cloned application.
After carefully analyzing the behavior of the original application, we designed the icon of the cloned application to closely resemble the original. This was done to ensure that the victim would quickly identify and click on the cloned application after the first attempt failed on the original partition.
Upon clicking the cloned application, the were able to execute commands as showing below.
We successfully exploited the insecure permissions of the NAND chip in this device to clone the software and convert it into a malicious program capable of dropping malware, encrypting files, or even providing remote access to an attacker. Our findings underscore the need for vendors to establish clear security standards for their products, particularly with respect to access controls and permissions.
In light of our research, we recommend that the NAND chip should be completely read-only, rather than creating one partition that is read-only and another that is both readable and writable. While we acknowledge that there may be additional attack vectors and operational security considerations, we have chosen to conclude our investigation at this point, having conveyed the primary message of our research.