Apache Karaf is an open-source container that simplifies the deployment and management of enterprise applications based on the OSGi (Open Services Gateway Initiative) standard. OSGi is a modular architecture that allows developers to build and deploy highly modular, dynamic, and scalable applications. Apache Karaf builds upon the strengths of OSGi, providing a lightweight and flexible runtime environment for Java applications.
The Karaf Web Management Console provides a compelling functionality that an attacker can exploit if misconfigured. While conducting this assessment activity, the following versions of Eclipse Equinox and OSGi bundle have successfully been exploited:
- Apache Karaf v4.4.3
- Apache Felix Framework v7.0.5 (OSGi R8)
The exploit and additional tooling to develop custom payloads can be found here.
Installing the Console
One of Karaf’s handy and powerful features is the web management console. This component allows for plugin management or debugging. The web console is often installed and enabled for the user’s convenience to manage the jar bundles efficiently. To install the web console, it is required to run the following commands in the Karaf shell:
karaf@root()> feature:install http
karaf@root()> feature:install webconsoleCommon Misconfiguration
External Access
The first issue we observe after enabling the Web Console is that the service runs on all interfaces on the local machine (see Figure 1), which means it is accessible externally (see Figure 2). Therefore, the attacker can access it from another host by connecting to the same network.
Default Credentials
By default, the karaf user is disabled for security purposes. However, to use the web console and be able to log in, the typical action is to enable the user. This can quickly be done by uncommenting the two last lines in the configuration file, see Figure 3.
Once the two lines depicted above are uncommented, the user can use karaf credentials to log into the web console. The username is karaf, and the default password is karaf.
Lack of SSL
Although the misconfiguration described in the previous section can be mitigated by changing the default credentials, the web console uses an insecure HTTP protocol by default. This means an attacker connected to a network can capture and reuse the credentials, see Figure 4.
At first, it can be observed that the user who accesses the web console is presented with the 401 Unauthorized response. The user then logs into the web console, providing a username and password, and due to a lack of SSL, the attacker captures the packet containing the raw credentials.
Exploitation
Based on the misconfigurations described above, an attack vector has been designed, and an exploit has been developed that chains the vulnerabilities. It allows reverse shell access to the victim server.
Figure 5 shows two windows. The top window shows the execution of the Karaf Exploit. It takes several parameters, which are:
- rhost – Remote host (victim’s IP).
- rport – Remote port (port on which the web console runs).
- lhost – Attacker’s host to which the reverse shell will be returned.
- lport – Attacker’s port on which the reverse shell will connect.
- creds – Karaf credentials (either the default ones or the ones captured with Wireshark).
The bottom window shows the reverse shell connection as proof-of-concept.
Browsing to the Karaf Web Console shows that the malicious bundle responsible for opening a reverse shell connection has been installed and activated, see Figure 6.
To develop a self-contained Karaf exploit that returns a reverse shell, several vulnerabilities had to be chained together and executed in the following order:
- Log in to the web console with the default/captured credentials.
- Establish the session and capture the session details stored in the cookies.
- Generate a Java class file and update its bytecode to use the reverse shell parameters provided at the execution time of the exploit.
- Create a jar bundle containing the malicious payload.
- Deploy and start the jar bundle via the web console.
All the steps listed above are contained and executed automatically in a single script.
Risk Assessment
We used the Common Vulnerability Scoring System (CVSS) version 3.1 to assess the risk from the presented attacks. Please note that this should highlight the impact of misconfiguration, not claim a new vulnerability in Apache Karaf.
The two exploited vulnerabilities resulted in an attacker being able to open a reverse shell from the target system—our initial assessment results in an overall CVSS score of 9.3.
The calculation can be checked and modified using the CVSS calculator.
Recommendations
While easily misconfigured, the Apache Karaf documentation includes a comprehensive guide on mitigating the issues highlighted in this report.
Detection
Indicators of Attack (IOA) can be collected using any network monitoring tool that captures the unsuccessful attempts to log into the web console. Another indicator is the presence of an unknown bundle deployed on the Karaf bundle list, see Figure 8 (note: the bundle details will be different).
Indicators of Compromise (IOC) may differ depending on the type of payload an attacker chooses. For instance, it might be a new process running and conducting malicious activities or communicating back to the Command-and-Control server.
Prevention
To prevent this type of attack, it is recommended to take the following into account:
- Avoid running Web Console on all interfaces; if this is not possible, ensure a firewall blocks the connection from unknown sources.
- Make sure to change the default credentials.
- If possible, use the SSL to prevent malicious actors from capturing your credentials.
- Void using the web console.
Written by: Andy Olchawa , Milenko Starcik @visionspace
