Claroty’s Team82, JFrog align on a vulnerability research project examining BusyBox utilities

BusyBox

Claroty’s Team82 and JFrog announced on Tuesday details of their collaboration on a vulnerability research project that examines BusyBox, a software suite of many useful Unix utilities, known as applets. Using static and dynamic techniques, Claroty’s Team82 and JFrog discovered 14 vulnerabilities affecting the latest version of BusyBox.

The BusyBox software suite consists of several Unix utilities packaged as a single executable file. Within BusyBox, users can find a full-fledged shell, a DHCP client/server, and small utilities, apart from several operational technology (OT) and IoT (Internet of Things) devices running BusyBox utilities. These may include programmable logic controllers (PLCs), human-machine interfaces (HMIs), and remote terminal units (RTUs), many of which now run on Linux.

All vulnerabilities were privately disclosed and fixed by BusyBox in version 1.34.0, which was released in August. In most cases, the expected impact of these issues is a denial of service (DoS). However, in rarer cases, these issues can also lead to information leaks and possibly remote code execution. Users were urged to upgrade, and if upgrading BusyBox is not possible due to specific version compatibility needs, “BusyBox 1.33.1 and earlier versions can be compiled without the vulnerable functionality (applets) as a workaround,” Claroty researchers wrote in a company blog post.

The BusyBox utilities have been written with size-optimization and limited resources in mind. It is also extremely modular so that users can include or exclude commands (or features) at compile-time, making it easy to customize embedded systems.

To assess the threat level posed by these vulnerabilities, Claroty inspected JFrog’s database of more than 10,000 embedded firmware images made up of only publicly available firmware, and not images uploaded to JFrog’s Artifactory. The researchers found that 40 percent of them contained a BusyBox executable file that is linked with one of the affected applets, making these issues extremely widespread among Linux-based embedded firmware.

In addition to disclosing the vulnerabilities, Team82 is also open-sourcing its custom AFL fuzzing harnesses, which were responsible for triggering many of the mentioned vulnerabilities. Hopefully, this will help fellow researchers find and disclose even more issues, the post added.

Claroty launched in July its research arm Team82 to provide vulnerability and threat research to customers and defenders of industrial networks worldwide. The unit ​​investigates industrial software, networks, and protocols for vulnerabilities, and works in a coordinated manner with vendors to get flaws addressed before threat hackers can exploit them. Its dashboard is a resource for users to stay up to date on the latest CVEs disclosed by its researchers, affecting industrial devices and networks. Equipped with an extensive industrial control systems (ICS) testing lab, the team works closely with industrial automation vendors to evaluate the security of their products.

Claroty researchers used static and dynamic analysis approaches to research BusyBox. A manual review of the BusyBox source code was conducted in a top-down approach following user input up to specific applet handling. They also looked for obvious logical/memory corruption vulnerabilities. 

The next approach used by the researchers was fuzzing. “We compiled BusyBox with ASan and implemented an AFL harness for each BusyBox applet. Each harness was subsequently optimized by removing unnecessary parts of the code, running multiple fuzzing cycles on the same process (persistent mode), and running multiple fuzzed instances in parallel,” according to the post.

“We started from fuzzing all the daemon applets, including HTTP, Telnet, DNS, DHCP, NTP, etc. Many code changes were required in order to effectively fuzz network-based input. For example, the main modification we performed was to replace all ‘recv’ functions with input from STDIN in order to support fuzzed inputs. Similar changes were done when we fuzzed non-server applets as well,” they added.

The researchers then prepared a couple of examples for each applet and ran hundreds of fuzzed BusyBox instances for a few days. “This gave us tens of thousands of crashes to evaluate. We had to create classes of crashes with the same root cause to help reduce the volume of crashes we had in our sample set. Later, we minimized each group representative in order to work with a small subset of unique crash inputs,” they said.

To fulfill these tasks, the Claroty researchers developed automatic tooling that digested all crash data and classified it based on the crash analysis report that mainly includes the crash stack trace, registers, and assembly code of the relevant code area.

Finally, they researched each unique crash and minimized its input vector to understand the root cause, which allowed us to create a proof-of-concept (PoC) that exploits the vulnerability responsible for the crash. In addition, “we tested our PoCs against several BusyBox versions to understand when the bugs were introduced to the source code,” they added.

Forescout Research Labs along with JFrog’s security research team (formerly Vdoo) announced in August, the presence of INFRA:HALT, a set of 14 new vulnerabilities affecting the HCC-owned, closed source TCP/IP stack NicheStack.

The vulnerabilities affect PLCs and other controllers made by over 200 device vendors, including industrial automation companies such as Siemens, Emerson, Honeywell, Mitsubishi Electric, Rockwell Automation, and Schneider Electric, JFrog said at that time. The security flaws identified can enable remote code execution, denial of service, TCP spoofing, information leak, and DNS cache poisoning.

Related