How to secure the open-source world

While coding mistakes and errors are not always destructive, many of them can cause vulnerabilities that malicious actors can exploit. A data breach that costs an average of $4.35 million can occur with just one exploitation, vulnerability, or human error — and some predict these breaches will cost $10.5 trillion by 2025. In addition, a single breach can have a significant long-term impact on an organization's ability to generate revenue, as it can give cybercriminals access to products, company data, and consumers’ confidential information, which ultimately damages the brand reputation.

That said, web applications have generally improved in security over the last few years. It’s less often that a single vulnerability leads to remote code execution because attackers would have to chain together multiple vulnerabilities in order to fully compromise a system. These chains are sometimes only made possible because security measures become less rigorous as authentication levels increase.

However, when an initial security border is crossed, it can swiftly cause a domino effect to occur if it is assumed that an attacker lacks a particular skill. A chain of exploits can be mitigated by adding even one seemingly insignificant security check, which will break the entire chain.

The vulnerabilities discovered in Checkmk

Checkmk is a cutting-edge monitoring tool for IT infrastructure, similar to Zabbix or Icinga, and was created in Python and C++. Checkmk is used by more than 2,000 customers, according to its website. Due to its function, Checkmk is a crucial element that is typically deployed at a central position within a company's network. Therefore, it has become a popular target for threat actors.

In an effort to help secure the open-source world, researchers investigated the open-source version of Checkmk, which is built on a Nagios monitoring core and seamlessly incorporates NagVis to display status information on maps and diagrams. During the investigation, several vulnerabilities in Checkmk and its integration with NagVis were discovered that a remote, unauthenticated attacker might use in a chain to completely take control of a server running a vulnerable version of Checkmk.

The first two vulnerabilities were a server-side request forgery and a line feed injection. The server-side request forgery vulnerability resides within a component called agent-receiver. This vulnerability served as the initial link in the exploitation chain, allowing an attacker to get access to an endpoint that is only accessible from “localhost.” This endpoint contains a line feed injection vulnerability, which makes it possible for an attacker to create custom Livestatus Query Language (LQL) queries.

The LQL interface is primarily used to retrieve the monitoring core’s data. For example, this information includes the internal host names and IP addresses of the monitored hosts, running services, contact information, and email addresses. Even though this information is not particularly sensitive, it can help an attacker launch other attacks. Therefore, obtaining this data would be of interest to an attacker. One way an attacker can retrieve data from the LQL interface is by utilizing time delays. Time delays are used so that some data can only be retrieved when a certain condition is met. By measuring the response time from the server, attackers can derive the corresponding data values.

LQL queries can further be used to delete arbitrary files. This ability allows attackers to bypass the NagVis component's authentication. By leveraging an arbitrary file read vulnerability in the NagVis component, attackers can gain access to the Checkmk GUI and exploit a code injection vulnerability to fully compromise the underlying server.

“Clean as you code” methodology

Cyberattacks against open-source software have increased by 633% year over year, according to researchers. And, even when companies upgrade to the latest version of a package, there’s still a 32% chance it will have vulnerabilities. This is why it’s so critical that developers adopt a “clean as you code” approach that integrates security into the software and app development process. Addressing security concerns shouldn’t be a painful aftermath of overlooked coding errors and bugs. By following the clean code methodology, no new bugs are introduced into the released code, which sets developer teams up for success and mitigates technical debt buildup. A clean code approach also provides developers with the resources and solutions needed to produce high-quality, secure code as it’s written.

Writing clean code from the start allows developers to simultaneously resolve current code issues by adhering to established quality standards. This will ultimately save time, effort, and frustration by directly addressing and preventing problems as the code is being created. Then, developers can spend more time focused on creating innovative new apps and services rather than cleaning code, leading to happier developers and better-quality software.

Stefan Schiller

Stefan Schiller is a vulnerability researcher at SonarSource.