Tag Archive for: Vulnerability

Joseph Lee

AMI BMC Flaw: Remote Takeover and DoS of Server Infrastructure

A new critical vulnerability of the highest possible severity score – CVE-2024-54085, CVSS 10 – has just been disclosed. It is found in the widely used American Megatrends’ (AMI) MegaRAC BMC (Baseboard Management Controller) software allowing authentication bypass and exploitation. Due to AMI’s dominant role in the motherboard supply chain, dozens of major hardware vendors are likely impacted. The vulnerability has a full technical explanation and proof-of-concept (PoC) further increasing the risk.

The PoC can effectively create a service account for the Redfish management console, and thus allows unauthenticated access to all remote BMC features. The exploit was verified against HPE Cray XD670, Asus RS720A-E11-RS24U, and ASRockRack. Other analysts have noted that although this CVE was released in 2025 its ID (CVE-2024-54085) was likely reserved in 2024.

CVE-2024-54085 allows an attacker to:

  • Exploit and remotely control a server
  • Install malware on the server including ransomware
  • Modify firmware for tampering
  • Potentially brick motherboard components (BMC or potentially BIOS/UEFI)
  • Cause physical damage via over-voltage
  • Induce indefinite reboot loops causing DoS conditions

Greenbone is able to detect affected servers with a remote vulnerability test that actively probes for a vulnerable BMC.

Potential Scope of the Impact

The particular interface for the MegaRAC BMC (Baseboard Management Controller), called Redfish, is just one of several BMCs that support remote server management. The Redfish standard has seen significant adoption in the enterprise server market as a modern replacement for legacy management interfaces like IPMI. This scope of the impact will include all products including OT, IoT or IT devices using AMI’s MegaRAC. When similar flaws were previously discovered in MegaRAC, the scope included products from Asus, Dell, Gigabyte, Hewlett Packard Enterprise, Lanner, Lenovo, NVIDIA and Tyan. AMI released patches on March 11, 2025, with HPE and Lenovo already issuing updates for affected.

A Technical Description of CVE-2024-54085

CVE-2024-54085 is a flaw in AMI’s SPx (Service Processor) firmware stack. More specifically SPx is part of AMI’s MegaRAC BMC solution. BMCs are microcontrollers embedded on a server’s motherboard that enable remote management and monitoring of the server, even when the system is powered off or unresponsive.

CVE-2024-54085 is classified as a “Authentication Bypass by Spoofing” [CWE-290] flaw. Using a client’s IP address for authentication is a typical scenario when CWE-290 occurs, since the source IP address can often be spoofed by the sender. Although AMI’s advisory is thin on details, Eclypsium researchers, attributed with the discovery, have provided a detailed article explaining the root cause. CVE-2024-54085 in fact does stem from using an IP address as a means for authentication. Redfish’s Lua-based access control logic uses HTTP headers, either the X-Server-Addr header or Host specification to determine whether an HTTP request is internal or external; automatically trusting internal requests as authenticated.

In BMC systems like MegaRAC, the “host interface” refers to a logical and physical connection between the BMC and the main server system (the host). For simplicity, this could be compared to the loopback interface (often named lo) with the IP address 127.0.0.1 and hostname localhost. In this case, the interface that communicates between the BMC chip and the host is assigned an address from the link-local IP range (169.254.0.0 to 169.254.255.255). Furthermore, this IP address is included in a list of trusted addresses during MegaRAC’s HTTP authentication process and successfully spoofing it results in authentication bypass. By reverse engineering the MegaRAC firmware, researchers discovered the link-local address 169.254.0.17 being used across several BMC chips.

The flaw also depends on the implementation of a regular expression that extracts all text from the X-Server-Addr header before the first colon character, and verifies if this text matches the trusted IPs stored in a Redis database. The BMC chips use Lighttpd as an embedded web server which was found to automatically add its own X-Server-Addr value. If a request already includes this header supplied by the client, Lighttpd appends its value after the user supplied one, allowing the attacker to provide a specially crafted header and control the value extracted by the regex. By supplying an X-Server-Addr value that matches the Host system’s link-local address, followed by a colon, (such as 169.254.0.17:) an attacker can trick the BMC into treating the request as though it comes from the internal host interface, bypassing authentication entirely.

Once authentication is bypassed, the rest of the HTTP request is processed, allowing the attacker to execute arbitrary API actions such as creating privileged accounts to gain full remote control over the server’s BMC and access its admin web-interface.

Steps for Mitigating CVE-2024-54085

Organizations must track their hardware vendor’s advisories closely and download the correct firmware updates when they become available. As a temporary safeguard, organizations can inspect their device manuals to determine if Redfish can be disabled if it’s not in use. Since BMCs can remain active even when the main server is powered down, affected systems must be treated as persistently exposed until the firmware is patched, unless Redfish is disabled, or the system is also air-gapped (disconnected from the network). Security teams may also develop new firewall rules or IPS rules to block attempts to exploit this flaw and protect vulnerable BMC management interfaces.

Because the flaw lies in an embedded proprietary firmware, patching is more complex than simply applying a routine operating system or application update. Unlike conventional software, BMC firmware resides on the motherboard’s dedicated chip. Therefore, BMC updates typically require a specialized software utility provided by the device vendor to “flash” the updated firmware. This process also results in downtime since administrators may need to boot into a special environment and reboot the system after the firmware update has been completed.

Summary

CVE-2024-54085 poses an extreme risk to enterprise infrastructure, allowing unauthenticated remote control of servers from major vendors like HPE and Lenovo. Given AMI’s dominant presence in data centers, exploitation could lead to mass outages, bricked hardware, or persistent downtime – making urgent detection and firmware patching essential for all affected systems.

Greenbone is able to detect affected servers with a remote vulnerability test that actively probes for an exploitable BMC interface.

Contact Test Now Buy Here Back to Overview

/by
Joseph Lee

Escalating Attacks Targeting CVE-2024-4577 in PHP-CGI for Windows

CVE-2024-4577 (CVSS 9.8 Critical) is currently climbing the winners’ podium of the most malicious security vulnerabilities. Disclosed in early June 2024 by Devcore security researchers, weaponization began within a mere 48 hours. It is a PHP-CGI OS Command Injection vulnerability [CWE-78] impacting PHP for Windows. Attacks distributing “TellYouThePass” ransomware were immediately observed and the CVE added to CISA’s KEV list (Known Exploited Vulnerabilities of the Cybersecurity and Infrastructure Security Agency). Several months later, exploitation of CVE-2024-4577 suddenly continues to escalate.

Greenbone provided vulnerability tests (VTs) to detect systems impacted by CVE-2024-4577 since it was released in June 2024. This allows defenders to identify affected systems across public-facing or internal network infrastructure. Let’s look deeper into the threat of CVE-2024-4577.

Exploiting CVE-2024-4577 for RCE and Lateral Movement

Proof of concept (PoC) exploit code and a full technical breakdown has long been published by watchTowr Labs, and a Metasploit module was also released in mid-2024. National CERT advisories have recently been issued by CERT New Zealand (CERT NZ) and the Canadian Center for Cyber Security. However, the flaw had already been alerted by CERT-EU, and CERT-FR (French Government CERT) back in June 2024.

Due to CVE-2024-4577, the PHP-CGI (Common Gateway Interface) may misinterpret certain characters as PHP options, which may allow a malicious user to pass options to the php.exe binary. This trick can reveal the source code of scripts or run arbitrary PHP code on the server. CVE-2024-4577 is considered a bypass of a long-ago patched vulnerability in PHP, CVE-2012-1823.

In the case that attackers gain initial access to a victim’s network through social engineering or a different software vulnerability, CVE-2024-4577 can provide an attacker with the opportunity for lateral movement, or covert persistence, penetrating deeper into a victim’s infrastructure and increasing the blast radius of a cyber attack.

A Brief Technical Explanation of CVE-2024-4577

In a nutshell, exploitation of CVE-2024-4577 works by leveraging Unicode character conversion to inject malicious command-line arguments to the php.exe process. On a high-level, web servers behave differently when CGI mode is enabled. A webserver will normally parse HTTP requests and pass them to a PHP script for processing. However, when CGI mode is enabled, attributes are extracted from the URL and passed as arguments to the executable PHP binary (php.exe on Windows). This PHP-CGI process is known to introduce distinct security risks.

Although PHP-GCI is supposed to sanitize shell meta characters (such as hyphens, double-hyphens, ampersands, and equal signs) before being passed, this still opens a pathway to command injection if attackers can find a way to bypass the sanitization process. PHP-CGI encoding was also the target of exploiting CVE-2012-1823. Furthermore, similar character encoding battles are continuously waged resulting in new ways for attackers to execute XSS and SQL injection vulnerabilities.

In the current iteration of this attack, using a soft hyphen (0xAD) instead of a standard hyphen (0x2D), attackers can initiate PHP directives to achieve Remote Code Execution (RCE). This is because Windows uses the UCS-2 character set, converts all characters to the UCS-2 code-point value and also executes an additional “best-fit” conversion. In the case of CVE-2024-4577, it is the best-fit schema that converts soft hyphens into standard hyphens. This allows injecting php.exe with arguments to prepend and execute the HTTP request body itself by adding the command “-d allow_url_include=1 -d auto_prepend_file=php://input” using URL encoded soft hyphens to the HTTP GET string. Soft hyphens are typically invisible UTF-8 characters used to specify locations word breaks, but only when necessary to fit the text on the line. Thanks to Windows’ best-fit conversion, they are effectively converted into command line flags.

CVE-2024-4577 is Being Leveraged Globally in 2025

According to new reports released in March 2025, attacks leveraging CVE-2024-4577 are ongoing,  widespread and escalating. Cisco detected exploitation of CVE-2024-4577 in January 2025, targeting Japanese education, ecommerce and telecommunications companies. After gaining initial access via PHP, attackers installed Cobalt Strike’s ‘TaoWu’ plugins and modified Windows registry keys to establish persistent access through scheduled tasks.

Another recent report from GreyNoise reveals that mass exploitation of CVE-2024-4577 has extended to targets in the US, UK, Singapore, Indonesia, Taiwan, Hong Kong, India, Spain and Malaysia. Germany and China were reportedly the primary sources of attacks, accounting for 43% globally. GreyNoise also maintains a honeynet that detected over 1,089 unique IPs attempting exploitation in January 2025 alone, and counted 79 publicly available, specialized exploit kits. The cybersecurity firm warned of growing attack volume in February 2025, driven by automated scanning and signaling a rapidly escalating cyber threat.

Mitigation for CVE-2024-4577

CVE-2024-4577 affects all PHP versions (including PHP 5 and PHP 7 which are end-of-life) before 8.1.29, 8.2.20 and 8.3.8 on Windows. The best mitigation is to upgrade to a patched version with urgency. For environments where immediate patching isn’t feasible, defenders may disable the execution of PHP-CGI mode in favor of PHP-FPM (FastCGI Process Manager) or alternatively, utilize a web-application firewall (WAF) to filter and block exploitation attempts. PHP system administrators should also note several additional security risks associated with CGI and review them for optimal security.

Greenbone has provided vulnerability tests (VTs) to detect systems impacted by CVE-2024-4577 since it was first disclosed in June 2024. This early detection capability allows defenders to identify affected systems across public facing or internal network infrastructure. Greenbone’s detection tests include remote version detections [1][2], and a remote active check [3].

Summary

CVE-2024-4577 is a critical PHP-CGI vulnerability affecting PHP installations on Windows, that allows remote code execution (RCE). The flaw was weaponized within 48 hours of disclosure and used in TellYouThePass ransomware attacks. According to reports from Cisco and GreyNoise, mass exploitation of CVE-2024-4577 has been escalating globally, and multiple national CERT advisories have been issued. Defenders need to identify where affected products are operating within their infrastructure, and immediately update to a fixed version of PHP, disable PHP-CGI completely or switch to PHP-FPM (FastCGI Process Manager).

Contact Test Now Buy Here Back to Overview

/by
Joseph Lee

Apache Camel Case-Sensitive Flaw May Forfeit Remote Command Execution

Two new CVEs in Apache Camel have been disclosed warranting immediate attention from users. On March 9, 2025, Apache disclosed CVE-2025-27636 (CVSS 5.6), a Remote Code Execution (RCE) flaw. Two days later, on March 11th, Akamai’s Security Intelligence Group (SIG) reported a bypass technique for the original patch, resulting in CVE-2025-29891 (CVSS 4.2) being published on March 12th.

Green graphic with stylised camel in a desert landscape. To the right is a button with the inscription ‘RCE in Apache Camel’.

Although the two vulnerabilities have only been assigned moderate CVSS severity scores by CISA-ADP (CISA’s Authorized Data Publisher), they could be severe impact vulnerabilities depending on the targeted Camel instance’s configuration. Both CVEs have the same root cause: improper filtering of HTTP headers or HTTP parameters when communicating to an Apache Camel instance. As the article’s title suggests, parameters were filtered using case-sensitive methods, while the arguments themselves were being applied in a non-case-sensitive manner.

Furthermore, publicly available proof-of-concept (PoC) code and a relatively complete technical description adds to the risk. Greenbone can detect both CVE-2025-27636 and CVE-2025-29891 with vulnerability tests that actively check for exploitable HTTP endpoints. Let’s review the details.

What Is Apache Camel?

Apache Camel is a popular open-source Java library for integrating different components of a distributed enterprise system architecture such as APIs or microservices. In a nutshell, Camel is a versatile platform for routing and mediation based on the Enterprise Integration Patterns (EIPs) concept of enterprise system architecture design. Apache Camel is heavily based on EIPs and provides an implementation of these patterns via its domain-specific languages (DSL) that include Java, XML, Groovy, YAML and others.

As of 2021, Apache Camel held approximately 3.03% of the Enterprise Application Integration market. The software is used by over 5,600 companies, roughly half being US-based. Camel’s market share is predominantly in the Information Technology and Services industry (33%), Computer Software industry (12%) and Financial Services industry (6%).

Two New CVEs in Apache Camel May Allow RCE

When any of Camel’s HTTP-based components handle requests, a default filter is supposed to prevent exposure of sensitive data or execution of internal commands. However, due to a flawed case-sensitive filtering rule, only exactly matched headers were filtered. However, downstream in the program logic, these headers were being applied in a non-case-sensitive manner, allowing filter bypass. Changing the case of the first character of the header name, an attacker could bypass the filter to inject arbitrary headers.

The good news is that either the camel-bean or camel-exec component must be enabled in combination with an http-based component such as such as camel-http, camel-http4, camel-rest, camel-servlet or others. Also, exploitation is limited to internal methods within the scope declared in the HTTP request URI. One final saving grace is that this flaw has not been implicated as an unauthenticated vulnerability. Therefore, unless the system designers have implemented any authentication and authorization for a Camel HTTP API, it is not exploitable.

At the high-end of the risk spectrum, if the Camel Exec component is enabled and targeted, an attacker can achieve arbitrary RCE as the user controlling the Camel process. RCE is achieved by sending the CamelExecCommandExecutable header to specify an arbitrary shell command, overriding the commands configured on the back-end. If exploitable Camel HTTP APIs are Internet accessible, the risk is especially high, however, this flaw could also be used for lateral movement within a network by an insider, or by attackers who have gained initial access to an organization’s internal network.

A technical description of the exploit chain and proof-of-concept (PoC) has been provided by Akamai.

What Is the Appropriate CVSS Score?

Although CVE-2025-27636 (CVSS 5.6) and CVE-2025-29891 (CVSS 4.2) have been assigned moderate severity scores, they could have a critical impact if either the camel-bean or camel-exec components are enabled in combination with http-based components. The situation highlights some limitations of the scoring by CVSS (Common Vulnerability Scoring System).

Akamai researchers report that the flaw is trivial to exploit and have published proof-of-concept (PoC) code, increasing the risk. This implies that the CVSS Attack Complexity (AC) metric should be set to Low (L). However, CISA-ADP has assessed attack complexity as high (AC:H) given these facts. Red Hat has accounted for these factors and increased the CVSS for CVE-2025-27636 to 6.3.

Also, the CISA-ADP assessed no impact to confidentiality for CVE-2025-29891, despite the potential for arbitrary RCE. However, if an Apache Camel instance has a vulnerable configuration, a high impact assessment for Confidentiality (C), Integrity (I) and Availability (A), is justified further increasing the criticality to CVSS 9.8.

On the other hand, the CISA-ADP assigned a Privileges Required (PR) value of None (N). However, although Akamai’s PoC does not use an HTTPS connection or authentication, it would be extremely negligent to operate an unencrypted and unauthenticated API. Apache Camel supports Java Secure Socket Extension (JSSE) API for Transport Layer Security (TLS) or using a KeyCloak Single Sign-On (SSO) authorization server. Camel instances with some form of client authentication enabled would be protected against exploitation. For most cases, the PR value should be adjusted to Low (L) or High (H) resulting in a diminished CVSS of 7.3 or 8.8.

Furthermore, the CVEs were assigned a Scope value Unchanged (UC). According to the CVSS v3.1 specification: “The Scope metric captures whether a vulnerability in one vulnerable component impacts resources in components beyond its security scope.” Execution of arbitrary shell commands on the compromised system is typically assigned the value of Changed (C). If the Camel process is owned by the Linux/Unix root or a Windows administrator user, an attacker would have virtually unlimited control of a compromised system. Accounting for the variety of possible CVSS assessments, CVE-2025-27636 and CVE-2025-29891 should be considered critical severity vulnerabilities if an instance meets the configuration requirements and does not apply authentication.

Mitigating the CVEs in Apache Camel

CVE-2025-27636 and CVE-2025-29891 affect Apache Camel version 4.10 before 4.10.2, version 4.8 before 4.8.5 and version 3 before 3.22.4. Users should upgrade to 4.10.2, 4.8.5 or 3.22.4 or implement custom header filtering using removeHeader or removeHeaders in Camel routes. It should be noted that Camel versions 4.10.0, 4.10.1, 4.8.0 to 4.8.4, and 3.10.0 to 3.22.3 are still vulnerable although they were considered security updates that addressed the flaw.

Also, it is strongly recommended that all HTTP endpoints in a distributed architecture employ strong authentication. For Apache Camel, options include: using Java Secure Socket Extension (JSSE) API for TLS with Camel components or using a KeyCloak OAuth 2.0 SSO authorization server. For legacy systems, a minimum of HTTP Basic Authentication should be configured.

Summary

Apache Camel users should immediately upgrade to versions 4.10.2, 4.8.5 or 3.22.4 to mitigate the newly published CVEs affecting Apache Camel. Alternatively, implement custom header filtering using removeHeader or removeHeaders in Camel routes. Strong authentication on all HTTP endpoints is also highly recommended for security best-practices. Apache Camel supports the JSSE API for TLS or KeyCloak SSO solutions. Greenbone is able to detect both CVE-2025-27636 and CVE-2025-29891 with vulnerability tests that actively check for exploitable HTTP endpoints.

Contact Test Now Buy Here Back to Overview

/by
Jan-Oliver Wagner

Cyber attacks are like earth quakes

Earth quakes and cyber attacks have much in common. First: The forces are outside of our control and we can not prevent them to happen.

Second: We are not helplessly at the mercy. We can install early warning, minimize destructive effect and recover quickly. But only if we act BEFORE it happens.

Sure, earth quakes are about human live and cyber attacks are so far usually not. Yet I think this comparison is important in order to make it easier to understand the significance of cyber attacks the the options for action.

Of course there are also differences and the most striking one to me is the average frequency of occurence. This vivid direct comparison shows the parallels:

We have no technology to prevent them to happen, but… Earth quake Cyber Attack
We have prognosis models where they happen most likely Tectonic models Vulnerability intelligence

We have sensors that provide early warnings shortly before it happens

(sometimes they fail though with false positive and false negatives)

 Seismographs Vulnerability scanning and threat intelligence
We have a scale to compare events about potential damage

Richter magnitude scale: Ranges from 1.0 to 9.9

  • Sometimes the effect is just shaking indoor objects and sometimes it is collapse of buildings

Severity Score: Ranges from 0.1 to 10.0

  • Sometimes you have some extra network load and sometimes a remote administrative exploit.
…you can do something to minimize negative impact:
Make you infrastructure stable against this type of force

Obligatory architecture designs

  • Overview and controlling of compliance

Obligatory security policies

  • detection and limitation of attack surface:
  • Vulnerability testing and remediation
  • Vulnerability management and compliance
Have trained teams ready to help recover quickly when it happens
  • Central command center and
  • distributed on-site medical and repair teams
  • Processes and and regular trainings thereof
  • Security operation center and distributed system administrator
  • Dev-ops or suppliers for operational support
  • Processes and and regular trainings thereof
Make all people aware on how to save their lives best when it happens
  • Understandable training materials and
  • regular awareness trainings
  • Understandable training materials and
  • regular awareness trainings


Contact Free Trial Buy Here Back to Overview

/by
Markus Feilner

Orange Security Report: Many old vulnerabilities still open

According to the latest study by Orange Security, 13 percent of the vulnerabilities found in today’s corporate networks were already known in 2012, and almost half of all gaps are more than five years old – and the trend is increasing. Professional vulnerability management such as the Greenbone product family can provide a remedy.

The Orange Security Navigator takes a look at the current threat situation on many pages every year. In the latest edition, the security software manufacturer comes to astonishing insights regarding the age of vulnerabilities in companies. The oldest risks have existed for 20 years or more, writes Orange, and patching is also taking longer and longer.

Even recently, problems that were actually fixed long ago filled the headlines: A security hole in VMWare’s ESXi server, which had been closed for years, was actively exploited by attackers. According to the German Federal Office for Information Security (BSI), thousands of servers were infected with ransomware and encrypted – details here in the Greenbone blog.

Orange Security can also sing from the same song: “Our pentesters find vulnerabilities that were first identified in 2010 (…) [and] problems whose causes go back to 1999. (…) This is a very worrying result.” In the case of the ESXi incident, the vulnerability had already been closed by the manufacturer in February 2021, but not all users had applied the necessary updates – which is exactly where Greenbone’s products help by actively scanning your systems for known, open vulnerabilities.

This is becoming increasingly important because, even according to Orange, more and more critical gaps are sometimes open for six months or longer, In recent years, the average time to a fix has increased by 241 percent. While patching of serious vulnerabilities is on average one-third faster than for less critical threats, the maximum time required to apply a patch is a concern: “Whether critical or not, some patches take years to apply.

Only one-fifth of all vulnerabilities found are fixed in less than 30 days, the study explains, while 80% remain open for more than a month. On average, it takes a full 215 days for gaps to be closed. Of the vulnerabilities waiting 1000 days for a patch, 16% were classified as severe, with three-quarters of medium threat, it said. In the case of the ESXi vulnerability, there has been an alert for two years, a high-risk classification and also a patch to fix it. Despite this, a large number of organizations have been successfully attacked by exploiting the vulnerability.

The problem is well known: Calls for vulnerability and patch management from data protection regulators, for example, are a regular occurrence. “I look at the topic of information security with concern. On the one hand, many organizations still haven’t done their homework to eliminate known vulnerabilities in IT systems – the data breach reports show us how such vulnerabilities are exploited again and again, and often data can be leaked.” Marit Hansen, Schleswig-Holstein State Commissioner for Data Protection, February 2022.

When it comes to cybersecurity, companies face major challenges, she said: More than 22 vulnerabilities with CVE are published every day, with an average CVSS score of 7 or more, she said. Without professional vulnerability management, this can no longer be handled, Orange also explains.

This makes the early detection and recording of vulnerabilities in the company all the more important. Greenbone products can take a lot of the work out of this and provide security – as a hardware or virtual appliance or as a cloud service. The Greenbone Enterprise Feed, from which all Greenbone security products are fed, receives daily updates and thus covers a high percentage of risks. Our security experts have been researching the topic for over 10 years, so we can detect risks even in grown structures.

Vulnerability management is an indispensable part of IT security. It can find risks and provides valuable information on how to eliminate them. However, there is no such thing as one hundred percent security, and there is no single measure that is sufficient to achieve the maximum level of security – vulnerability management is an important building block. Only the totality of the systems deployed, together with comprehensive data protection and cyber security concepts, is the best possible security.


Contact Free Trial Buy Here Back to Overview

/by
Markus Feilner

Notus is live! New vulnerability scanner from Greenbone

,

Greenbone, a world leader in open source vulnerability management software, has released its latest scanner, Notus.

“With Notus, a milestone for the performance of extensive comparisons of software versions has been created in recent years,” explains CIO Elmar Geese.

With Notus, Greenbone is also responding to customer requests for better performance in version checks. Whether a security vulnerability is dangerous for a company depends mainly on the installed software versions and their patch level. In very many cases, a vulnerability scanner must therefore match a large number of software versions and detect combinations of these. As the complexity of the setups increases, this test becomes more and more extensive. However, because the overall result of the scan also depends heavily on this data collection, Notus will enable such scans much faster than any of its predecessors.

Faster thanks to JSON

“The scanner rattles off the relevant servers and captures software running there. For the actual scan, it essentially only gets the info about affected and fixed packages,” explains Björn Ricks, Senior Software Developer at Greenbone. “With the previously used scanner and its predecessors, we usually had to start a separate process per version check, meaning a separate manually created script. Generating these scripts automatically is time-consuming.” Notus, on the other hand, only loads the data it needs from JSON files. Ricks sums it up, “Notus is significantly more efficient, requires fewer processes, less overhead, less memory, …”

CIO Geese then also declares the Notus scanner to be a “milestone for our users, it improves the performance significantly. Our well-known high detection quality as well as performance, central goals of our product strategy, will be optimally supported by the new scanner.”

Notus, Greenbone and OpenVAS

The Notus project consists of two parts: a Notus generator, which creates the JSON files containing information about vulnerable RPM/Debian packages, and the Notus scanner, which loads these JSON files and interprets the information from them.

OpenVAS, the Open Vulnerability Assessment System, was created in 2005, when the development team of the Nessus vulnerability scanner decided to stop working under open source licenses and move to a proprietary business model.

Since 2008, Greenbone has been providing professional vulnerability scanning support. For this purpose, Greenbone took over the further development of OpenVAS, added several software components and thus transformed OpenVAS into a comprehensive vulnerability management solution that still carries the values of free software. The first appliances came onto the market in spring 2010.

Contact Free Trial Buy Here Back to Overview
/by
Markus Feilner

Ransomware as a Service: the Role of Bitcoin and Darknet

Both the cryptocurrency Bitcoin and the darknet have a dubious reputation. The media like to portray both as opaque, criminal parallel worlds. For Ransomware as a Service, Bitcoin and the darknet are welcome tools. Organized crime has been using them for a long time to disguise its business, even if it by no means makes the criminals anonymous and safe from prosecution.

Ransomware became the world’s biggest threat to IT systems in 2021. If you want to successfully protect yourself against it, you also need to understand how the parties involved proceed. Part one of this series of articles focused on the business model of Ransomware as a Service. Part two showed why this “professionalization” also leads to a changed mindset among attackers. Part three now explains why the IT tools that organized crime uses to order and transfer money are far from secure.

Ransomware as a Service: abstract image of Bitcoin logo

Anonymous and Secure?

Bitcoin as a means of payment and the darknet are proving to be practical, helpful and attractive for attackers. Under the cloak of supposed anonymity, they think they are protected from prosecution and shielded from consequences. But this is a common misconception: neither Bitcoin nor the darknet are anonymous in practice.

While cryptocurrency was never designed for anonymity, but explicitly for traceability of transactions even without a reliable central authority, the darknet turns out to be not even remotely as anonymous as its creators would have liked. This is also shown by reports such as the recent ones about KAX17’s “de-anonymization attacks” on the Tor network. Nearly always, classic investigative methods are enough for law enforcement to track down even ransomware actors like the REvil group. This group had collected half a million euros in ransoms in more than 5,000 infections, according to Heise [German only].

Never a Good Idea: Cooperating With Criminals

No matter whether online or offline, anyone who gets involved with blackmailers is abandoned. As in real life, good advice is never to pay a ransom. Regardless of how professional the hotline on the other end seems, trust is not appropriate. The operators of REvils Ransomware as a Service, for example, even stole the extorted ransoms from their clients via a backdoor in the malware.

It all started out so friendly and idealistic. Roger Dingledine and Nick Mathewson laid the foundations for the Tor network in the early 2000s. Based on the idea of onion rings, numerous cryptographically secured layers on top of each other were supposed to ensure reliable anonymity on the web – in their opinion, a fundamental right, analogous to the privacy definition of Eric Hughes “Cypherpunk’s Manifesto”. Then in 2009, Bitcoin saw the light of day, first described by the almost mystical figure of Satoshi Nakamoto.

Darknet and Bitcoin Are Not “Criminal”

Neither the darknet nor Bitcoin were designed to conceal or enable dark schemes. The goal was to create free, independent, supposedly uncontrollable and largely secure structures for information exchange and payment. Like a knife, however, the services can be instrumentalized for both good and evil – and, of course, organized crime knows how to use this to its advantage. The focus is not always on leaving no traces. Most often, the focus is on the simplicity and availability of the means. Bitcoin and the darknet are simply the tools of choice because they are there.

But as in the real world, the easiest way to catch the extortionists is during the money transfer: a blockchain like Bitcoin documents all transactions ever made, including the wallet information (i.e., the Bitcoin owner), and makes it available for viewing at any time. The same applies to the darknet: even if anonymity is technically possible, people regularly fail to meet the simplest requirements. GPS meta-data can be found in photos or UPS codes in the illegal store. The legendary drug store Silkroad was busted because employees made mistakes and confessed.

Digitized, Organized Crime

The darknet and cryptocurrencies are helpful tools for organized crime and thus fire accelerators for the rapidly growing number of serious ransomware attacks. But they are by no means essential, nor are they to blame. Such cyber crime is just the modern IT variant of what we can also experience on the streets of any major city. Ransomware is, so to speak, the modern protection racket, Bitcoin is the garbage can for the handover, and the darknet is the dark bar where deals are made.

The perfidy is not in the tools, but in the methods and the long experience in the “business”. Trend Micro, for example, describes the “double extortion ransomware” approach. Here, attackers first make an image of the data and threaten to publish it if payment is not made (i.e., if it is not decrypted). Organized crime has been in the extortion business not just since Bitcoin or the darknet came into existence. Even though the two technologies now enable cyber criminals to extort large sums of money undetected at first, conventional methods are almost always sufficient for detection. The most important prerequisite here is that enough law enforcement personnel are available, not primarily their technical equipment.

Take Precautions

But at this point, in the company, the horse has already bolted. If you are faced with encrypted data and a ransom demand, the darknet, Bitcoin and the detection rate are probably of secondary importance. Much more important is the question of how to get out of the unfortunate situation. And you can only do that if you were prepared. This includes backups, restore tests and the immediate disconnection of all affected machines (network split) – in other words, proactive risk management, disaster recovery tests and constant maintenance of your own systems. Another important component is multi-factor authentication, which prevents attackers from shimmying from one system to the next using acquired passwords alone.

The most important thing, however, is to avoid critical situations in the first place and to identify vulnerabilities in your own systems and close them quickly. Modern vulnerability management like Greenbone’s does just that: it gives you the ability to close gaps in your systems, making the corporate network unattractive, costly, and thus a deterrent to professional cyber criminals, not just from the Ransomware-as-a-Service world.

Greenbone’s products monitor the corporate network or external IT resources for potential vulnerabilities by continuously and fully automatically examining it and, as Greenbone Enterprise Appliances or the Greenbone Cloud Service (software as a service hosted in German data centers), guarantee security by always up-to-date scans and tests.

How this works is described by Elmar Geese, CIO/CMO at Greenbone, also here in the blog with a post around the Log4j vulnerability. In addition, Geese explains how quickly and securely the administration and management are also informed of the latest vulnerabilities and how exactly the scan for vulnerabilities such as Log4Shell is carried out.


Contact Free Trial Buy Here Back to Overview

/by
Elmar Geese

Additional Log4j Vulnerabilities Published

Log4j was affected by a vulnerability that allowed Remote Code Execution (RCE) attacks. In short, user inputs into a software could lead to a code execution on a remote server. This represents a severe security risk. It was named “Log4Shell” (CVE-2021-44228) and immediately addressed by the Log4j team, who provided a fix. In the following days, additional Log4j vulnerabilities were found. While these do not have the same impact as the first one, they can also cause severe damage. For this reason, it is very important to check systems and always update to the latest versions.

Since Log4j is included in numerous software products, the manufacturers of the products had to and still have to provide updates as well. This is still ongoing, and more Log4j vulnerabilities may emerge in the future.

As a moving target, Log4j still gets a lot of attention, under various aspects:

  • New (and luckily still less severe) vulnerabilities are found.
  • New initiatives are emerging proactively to check log4 sources, such as Google’s initiative: Improving OSS-Fuzz and Jazzer to catch Log4Shell
  • At Greenbone, we are creating even more vulnerability tests to get better test coverage, and deploy them to our products on a daily basis.

We have already received a pretty good CVE coverage for the additional Log4j vulnerabilities that have been published in the last few days, including:

  • CVE-2021-44228
  • CVE-2021-4104
  • CVE-2021-45046
  • CVE-2021-45105

As mentioned earlier, we do not stop here. More local security checks will follow today and tomorrow, once Linux distributions have published their advisories.

We already published some facts about Log4j and how to deal with it in our recent posts:


Contact Free Trial Buy Here Back to Overview

/by
Elmar Geese

Scanning for Vulnerabilities like Log4Shell – How Does It Work?

Greenbone’s vulnerability management finds applications with Log4j vulnerabilities in systems that definitely need to be patched or otherwise protected. Depending on the type of systems and vulnerability, these can be found better or worse. Detection is also constantly improving and being updated. New breaches are found. Therefore, there may always be more systems with Log4Shell vulnerabilities in the network. For this reason, it is worthwhile to regularly update and scan all systems. The Greenbone vulnerability management offers appropriate automation functions for this purpose. But how are vulnerabilities found, and where can they be hidden? Why are vulnerabilities not always directly detectable? The following article will give you a brief insight into how scanning for vulnerabilities like Log4Shell works.

A vulnerability scanner makes specific queries to systems and services and can read from the responses what kind of systems and services they are, but also what products are behind them. This also includes information such as their versions or even settings and other properties. In many cases, this makes it possible to determine whether a vulnerability exists and whether it has already been eliminated. In practice, these are sometimes highly complicated and nested queries, but above all they are also very, very many. Entire networks are scanned for thousands of different vulnerabilities.

The Log4j vulnerability “Log4Shell” (CVE-2021-44228) is a flawed program library used in many web services products. Therefore, partly it is directly visible through a vulnerability scan, but partly it is hidden behind other elements. That is why there is not only one vulnerability test for Log4j, but several. More are added all the time because the manufacturers of the respective products share relevant information and also provide updates to close the gaps. The list of systems affected by Log4Shell is constantly updated at https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592.

Some of the vulnerability tests require an authenticated scan. This means that the scanner must first log into a system and then detect the vulnerability in the system. An authenticated scan can provide more details about vulnerabilities on the scanned system.

The vulnerability tests that are suitable to find the Log4j vulnerability are provided collectively in a scan configuration. Greenbone keeps this “Log4j” scan configuration continuously up-to-date in order to keep adding new tests. As a result, a scan may report a Log4j vulnerability tomorrow that was not found today. It is therefore advisable to configure the Log4j scan to run automatically on a regular basis. This is especially important in the next weeks, when many software vendors are gathering more findings. Greenbone continuously integrates these findings into the tests and the scan configuration.

scanning for vulnerabilities like Log4Shell
Does a Vulnerability Have to Be Exploited to Find It?

Exploiting a vulnerability to find it is not advisable. And fortunately, it is not necessary either. Doing so could cause the very damage that should be avoided at all costs. Moreover, a product vendor that provides vulnerability exploitation as a feature would potentially strongly encourage misuse of that feature, which raises further – not only legal – issues. Therefore, Greenbone’s vulnerability management does not include such features.

Exploitation of the Log4j vulnerability as attackers would do is also not required to prove the existence of the vulnerability. Greenbone has developed several tests to prove Log4Shell, each of which looks at systems in different depths. Several tests can detect the Log4j vulnerability with 100 % certainty, most with 80 % to 97 % certainty. Some tests also collect indicators of 30 % where they do not get close enough to the vulnerability. Each test at Greenbone makes a statement about detection certainty, which is stated as “Quality of Detection.”

What Is the Role of Software Product Vendors?

Manufacturers of a wide variety of products can use Log4j libraries, which are now vulnerable with it. Product manufacturers have included Log4j in different ways. Usually, a deep scan can find Log4j without the vendor’s help. However, most manufacturers also support the process through public vulnerability reports. These can then be used to write vulnerability tests that can provide a reliable vulnerability statement even with less deep scans. The reason for this is that the scans can use simpler configurations through vendor information. In addition, they also run faster.

In principle, however, a vulnerability scanner can also check and find vulnerabilities without the manufacturer publishing a vulnerability report.

Conclusion

Vulnerability management is an indispensable part of IT security. It can find risks and provides valuable information on how to fix them. However, no single measure provides 100 % security, not even vulnerability management. To make a system secure, many elements are used, which in their entirety should provide the best possible security.

This is comparable to a vehicle, where the passenger compartment, seat belts, airbags, brake support, assistance systems and much more increase safety, but can never guarantee it. Vulnerability management makes risks controllable.


Contact Free Trial Buy Here Back to Overview

/by
Elmar Geese

In-Depth Information About Greenbone’s Log4j Vulnerability Test Coverage

Update from 2021-12-20: information about additional vulnerabilities found for Log4j can be found here.

Update from 2021-12-20: vulnerability tests for products running on Microsoft Windows are now available.

Note: The tests check the existence of Log4j and its version. A separate vulnerability test may not be available for each affected application, but all Log4j files are found and reported (/path-to-log4j-file/).

The issued installation paths must be checked and, if necessary, the vendor must be contacted. It must be checked whether updates are already available for the respective application and whether the find is relevant.

PowerShell execution privileges on a target system are required for the account used in an authenticated scan. Some vulnerability tests execute PowerShell commands to increase the accuracy of the results, which require permissions for the duration of a scan.

Update from 2021-12-15: an additional attack vector was identified and reported in CVE-2021-45046. We are working on vulnerability tests for this vector, although our tests are working for this additional case too. We recommend to update to the latest Log4j version. The attack is more complicated and a protection requires a different configuration. But as this is a very new vector, we advise to better be save than sorry. For more information see https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/.

This article collects answers to the most frequently asked questions regarding Greenbone’s Log4j vulnerability test coverage.

What Is this Vulnerability About?

The “Log4Shell” vulnerability affects a software library responsible for recording events (so called “logging”) in software written in the Java programming language. A malicious attacker can use this vulnerability to execute code on the affected systems.

Since this vulnerability can be exploited through the Internet and without any authentication, this can be very critical for affected systems and companies. As the software is also included in a lot of software and services accessible through the Internet, many companies and services are likely to be affected.

More information about this vulnerability can be found here:

Are any Greenbone Products and Services Affected?

We checked the status of potentially affected systems with the highest priority. None of our products or internally and externally provided services are affected.

Can Greenbone Products Detect this Vulnerability?

Yes, detection routines have been integrated into the Greenbone Community Feed and into the Greenbone Enterprise Feed starting with feed version 202112130808. This means that both our appliances and our cloud product are able to detect this vulnerability.

While detection routines are available, the complex nature of this vulnerability means that a detection cannot be guaranteed to find every single affected system or products. This especially applies to unauthenticated “remote” checks, for the following reasons:

  • The product or service may only be vulnerable under very specific circumstances. As the Log4j library is very complex and highly configurable and it is used differently in many products, it is not possible to find all vulnerable instances through a remote check.
  • Security configurations in the customer’s network may prevent a successful verification of the vulnerability.
  • Products and services may also be affected indirectly.

A custom scan configuration for directly detecting this vulnerability as quickly as possible is also available through both feeds. Please note that the current scan configuration only contains active checks (remote and local). Package-version checks are not included to keep the scan configuration, and thus the scan time, minimal.

Is the Detection Included in the Greenbone Community Feed?

Yes. A basic detection for the vulnerability is included in both feeds. Additional vulnerability tests for potentially affected enterprise products are available through the Greenbone Enterprise Feed.

Which Detection Is Included in Which Feed?

Greenbone Enterprise Feed

We are continuously deploying vulnerability tests into the Greenbone Enterprise Feed, so the following list may be incomplete, but reports the status of 12:00 p.m.

Important: To get the most current information regarding your installation, you can search for ~CVE-2021-44228 in the “CVE” and “NVTs” section of the “SecInfo” menu on the web interface of your installation.

  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (Log4Shell)
  • Apache Log4j Detection (Linux/Unix SSH Login)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (HTTP, Log4Shell) – Active Check
  • Apache Struts 2.5.x Log4j RCE Vulnerability (Log4Shell)
  • Apache Druid < 0.22.1 Multiple Vulnerabilities (Log4Shell)
  • Apache Flink < 1.13.4, 1.14.x < 1.14.1 Log4j RCE Vulnerability (Log4Shell)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (TCP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (UDP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (SIP, Log4Shell) – Active Check
  • Apache Solr 7.x, 8.x Log4j RCE Vulnerability (Log4Shell) – Version Check
  • Debian: Security Advisory for apache-log4j2 (DSA-5020-1)
  • Debian LTS: Security Advisory for apache-log4j2 (DLA-2842-1)
  • Elastic Logstash Log4j RCE Vulnerability (Log4Shell)
  • Openfire < 4.6.5 Log4j RCE Vulnerability (Log4Shell)
  • VMware vCenter Server 6.5, 6.7, 7.0 Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell) – Version Check
  • VMware Workspace ONE Access Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Operations Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Log Insight Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Automation Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vRealize Orchestrator Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell)
  • VMware vCenter Server 6.5, 6.7, 7.0 Log4j RCE Vulnerability (VMSA-2021-0028, Log4Shell) – Active Check
  • ArcGIS Server <= 10.7.1 Log4j RCE Vulnerability (Log4Shell)
  • Metabase < 0.41.4 Log4j RCE Vulnerability (Log4Shell)
  • Splunk 8.1.x, 8.2.x Log4j RCE Vulnerability (Log4Shell)
  • Wowza Streaming Engine <= 4.8.16 Log4j RCE Vulnerability (Log4Shell)
  • SonicWall Email Security 10.x Log4j RCE Vulnerability (SNWLID-2021-0032, Log4Shell)
  • IBM WebSphere Application Server Log4j RCE Vulnerability (6525706, Log4Shell)
Greenbone Community Feed

We are continuously deploying vulnerability tests into the Greenbone Community Feed, so the following list may be incomplete, but reports the status of 12:00 p.m.

Important: To get the most current information regarding your installation, you can search for ~CVE-2021-44228 in the “CVE” and “NVTs” section of the “SecInfo” menu on the web interface of your installation.

  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (Log4Shell)
  • Consolidation of Apache Log4j detections
  • Apache Log4j Detection (Linux/Unix SSH Login)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (HTTP, Log4Shell) – Active Check
  • Debian: Security Advisory for apache-log4j2 (DSA-5020-1)
  • Elastic Logstash Log4j RCE Vulnerability (Log4Shell)
  • Debian LTS: Security Advisory for apache-log4j2 (DLA-2842-1)
  • Openfire < 4.6.5 Log4j RCE Vulnerability (Log4Shell)
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (TCP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (UDP, Log4Shell) – Active Check
  • Apache Log4j 2.0.x < 2.15.0 RCE Vulnerability (SIP, Log4Shell) – Active Check

About Authenticated/Unauthenticated Tests

Some version checks require authentication, others do not. Additionally, some could have both.

The respective information is available through the links returned by the search for ~CVE-2021-44228 in the “CVE” and “NVTs” section of the “SecInfo” menu on the web interface of your installation.

The “Quality of Detection” contains information on the detection method. A value of “package (97 %)” indicates an authenticated check, other values like “remote_banner (80 %)” happen unauthenticated.

For more technical information about this see https://docs.greenbone.net/GSM-Manual/gos-21.04/en/reports.html#quality-of-detection-concept.

About Active Tests/Test Checking Version, QoD

You can see if it is an active check based on the QoD and the “Detection Method” on the web interface when viewing the vulnerability test details.

Note: Only systems which are actually logging input which can be modified by an attacker (e.g., specific HTTP request headers, URLs, …) are vulnerable.

The detection method, Quality of Detection, mitigation and lots of further details are available through the links returned by the search for ~CVE-2021-44228 in the “CVE” and “NVTs” section of the “SecInfo” menu on the web interface of your installation.

Scanning for Nodes on Separate VRFs & VLANs

  • Out-of-band (OOB) scanning is currently not possible. Please scan in each segment.
  • We think of such an Out-of-band (OOB) communication/external interaction possibility to be integrated in the future.


Contact Free Trial Buy Here Back to Overview

/by