Attacking a BusyBox, the small Gaulish village

More and more devices are using Linux in the industrial environment. The increase in embedded systems with this operating system, in this environment, is due to the possibility of having a small system, but also to the ability to operate continuously without requiring attention and the possibility of modifying the system depending on the need of the process. It is here where BusyBox comes into play, a software that is located on a higher layer than the operating system and brings together programs in a multi-call executable, offering, through a list of commands, the execution of various tasks.

What is BusyBox?

The characteristics of BusyBox will depend on the needs of each embedded system and the options that the developer wants to provide; however, they all share some common parameters:

• BusyBox lacks the full command functionality of bash and other shells. Instead, it makes use of the so-called Almquist shell.
• The functionality depends on the compilation options chosen by the developers.
• The implementation and, therefore, the capacity of most commands has a slightly different operability compared to the Linux version itself.

When it comes to security, the operating systems that include a BusyBox are usually quite secure, but they may have vulnerabilities, some of which are documented.

- Architecture of operating system with BusyBox -

Vulnerabilities and attacks

Like almost all software, BusyBox has also been targeted by attackers. Since its creation, several vulnerabilities have been identified, which have been fixed with patches and updates but, in some cases, the attackers have been able to exploit them, taking control of the equipment that use this tool.

The most important vulnerabilities that have affected this software are related to memory access, such as the following:

• Out-of-bounds read: problem until version 1.30.0. It affected udhcp components and could allow a remote attacker to filter confidential information from the stack by sending a specially designed DHCP message. This problem appeared due to an incomplete solution for another, earlier vulnerability that affected version 1.25.0, which allowed a possible remote attacker to have an impact on the software through the OPTION_6RD parameter, by the use of an overflow buffer in the DHCP client, and could cause the leak of confidential information or remote code execution.
• Memory-based buffer overflow: BusyBox software performs operations on a memory buffer but can read or write to a memory location that is outside the desired buffer limit. In some cases, direct addressing of memory locations is allowed, which does not automatically guarantee the validity of these locations for the memory buffer referred to. This can cause read or write operations to be performed in memory locations that may be associated with other variables, data structures or internal program data.

Now that we have seen various vulnerabilities, let's see how the best-known cyberattacks happened to a BusyBox, which are Mirai, Brickerbot and Bashlite.

The first attack, Mirai, exploited hosts that implemented Telnet within BusyBox, in addition to using weak passwords, to gain access to the devices.

Once inside, the malware was installed and established a connection with the command and control server (C&C), where it waited for further instructions. When attacking, the Mirai C&C server instructs all bots under its control to launch an avalanche of various types of traffic, flooding the host target. Mirai mainly affected CCTV cameras, which it used to carry out the end target flood attack.

Mirai contained a list of servers that included those of several major manufacturers, in addition to the US Department of Defense servers.

The second attack, Brickerbot, occurred in 2017. The malware made brute force access attempts using default passwords, using the Telnet protocol. When the attacker gained access to a device, they accessed the BusyBox and subsequently blocked the device, leaving it unusable. This attack, which caused a Permanent Denial of Service (PDoS) was executed through a series of BusyBox commands that removed all the contents of the device's internal storage by using the Unix rm command, along with commands that reconfigured the kernel. Finally, they restarted it, leaving the device totally unusable.

Finally, the Bashlite malware, which aimed to gain control of devices running BusyBox, such as some routers. This version of Bashlite used a vulnerability in Shellshock to gain control. By monitoring this vulnerability, it was observed that the malware, detected as ELF_BASHLITE.SMB, scanned the network for machines or devices that were running BusyBox, accessing the machine using the username and password. When the attacker acceded, they executed a series of BusyBox commands to download and launch some scripts (bin.sh and bin2.sh) to give them control over the system.

- Commands executed in BusyBox by an attacker. Source: Trend Micro. -

As the previous image shows, there are several commands that are executed by means of malicious scripts, including:

• Change of directory to the temporary folder where there may be files with write permissions.
• Download a remote file using HTTP or TFTP (unencrypted protocols).
• Execution of the script that has been downloaded.

Protection in BusyBox

One of the main recommendations to avoid these cyberattacks is to change the default username and password, in addition to disabling the remote access of the devices.

In general, being free code, BusyBox security improvements are mitigated by software updates, which are not usually as constant since they are open-source, compared to those received by proprietary software, but also the use of a robust configuration inside the device that BusyBox uses will help reduce the number of vulnerabilities, and make it more difficult to access this software. Some of the characteristics of a robust configuration are:

• Implementation of white lists.
• Proper management of users and privileges.
• Robust credentials.
• Disable unnecessary ports.
• Update the use of obsolete encryption systems or those that are considered weak.

On the other hand, the services or applications that we can use through the BusyBox software must be as secure as possible, and unnecessary or insecure services must not be enabled. An example would be to use encrypted protocols such as HTTPS, SSH or SFTP, and not use unencrypted protocols under any circumstances, since they are an input channel to circumvent our security.

In addition, it is advisable to update the BusyBox modules whenever possible, while waiting for a security update.

Conclusion

The function of BusyBox as a software suite (application package) is quite complete, since it has diverse utility both with programs executable through commands, as with scripts and other types of files. In order for BusyBox to be useful and efficient, it is important that developers of this type of software incorporate their own content, such as shell scripts and configuration files, which control the tools to be executed.

As we have seen, its security is not perfect, since it is not free of possible vulnerabilities, and therefore it will be necessary to apply security updates constantly to minimize the risk of a possible cyberattack that exploits any of its weaknesses.