How to remediate – Derby Network Server Detection

1. Introduction

A Derby Network Server is listening on the remote host, meaning a Java-based relational database developed by Apache Software Foundation is accessible over the network. This allows potential attackers to access sensitive data stored within the database. Systems running Derby in a production environment are usually affected. A successful exploit could lead to information disclosure, impacting confidentiality of data.

2. Technical Explanation

The remote host is running a Derby Network Server which enables network connections to the database engine. By default, it may be configured without authentication or with weak credentials. An attacker can connect to this server and potentially execute arbitrary SQL queries, gaining access to sensitive information. There is no known CVE associated with simply *running* the service; risks arise from insecure configuration.

• Root cause: Derby Network Server running with default settings allowing remote connections without strong authentication.
• Exploit mechanism: An attacker connects to the server using a database client and executes SQL queries to retrieve data or modify the database. For example, connecting via `ij` (the interactive JDBC tool) and executing `SELECT * FROM sensitive_table`.
• Scope: Systems running Apache Derby Network Server versions 10.2 through current releases are affected if not properly secured.

3. Detection and Assessment

You can confirm whether a system is vulnerable by checking for the listening service and its configuration. A quick check involves identifying open ports, while thorough assessment requires examining Derby’s security settings.

• Quick checks: Use `netstat -tulnp` or `ss -tulnp` to identify if any processes are listening on port 1527 (the default Derby port).
• Scanning: Nessus plugin ID 36984 can detect exposed Derby instances. This is an example only and may require updates.
• Logs and evidence: Check system logs for Derby startup messages indicating network server mode. Look for configuration files in the Derby installation directory (e.g., /opt/apache-derby-*/conf).

netstat -tulnp | grep 1527

4. Solution / Remediation Steps

Fixing this issue involves either disabling the network server or securing it with strong authentication and access controls.

4.1 Preparation

• Ensure you have the necessary permissions to modify Derby configuration files. A roll back plan involves restoring the database from the backup and restarting the application.
• A change window may be needed depending on service impact. Approval should come from the IT security team.

4.2 Implementation

1. Step 1: Stop the Derby Network Server process if it is running as a standalone server.
2. Step 2: Edit the `derby.properties` file located in the Derby configuration directory.
3. Step 3: Set the `derby.networking.server.ssl.enabled` property to `true`.
4. Step 4: Configure strong authentication by setting appropriate user credentials and roles within the database.
5. Step 5: Restart the Derby Network Server process.

4.3 Config or Code Example

Before

derby.networking.server.ssl.enabled=false

After

derby.networking.server.ssl.enabled=true

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue.

• Practice 1: Least privilege – limit the database user’s permissions to only what is necessary, reducing potential damage from a compromised account.
• Practice 2: Secure defaults – avoid using default configurations and credentials; always change them to strong values.

4.5 Automation (Optional)

Automation is not directly applicable for this vulnerability due to the configuration changes required, but infrastructure-as-code tools can be used to manage Derby’s configuration files.

5. Verification / Validation

Confirm the fix by checking that strong authentication is enabled and network access is restricted. A negative test involves attempting to connect without valid credentials.

• Post-fix check: Use `netstat -tulnp` to confirm the server is listening on port 1527, then attempt a connection using a database client with invalid credentials – it should fail.
• Re-test: Re-run the initial `netstat` command and verify that no unauthorized connections are possible.
• Monitoring: Monitor system logs for failed connection attempts, which could indicate brute-force attacks or misconfigured clients.

netstat -tulnp | grep 1527

6. Preventive Measures and Monitoring

Preventive measures include updating security baselines and incorporating checks in CI/CD pipelines.

• Baselines: Update your security baseline to require strong authentication for all database servers, including Derby.
• Pipelines: Add static analysis tools to your CI pipeline to scan configuration files for insecure settings like default credentials or disabled SSL.
• Asset and patch process: Implement a regular review cycle for database configurations to ensure they remain secure.

7. Risks, Side Effects, and Roll Back

Enabling strong authentication may require application changes if existing clients use default credentials. A roll back involves reverting the `derby.properties` file and restarting the server.

• Risk or side effect 1: Application downtime during configuration change. Mitigation: Plan for a maintenance window and test thoroughly.
• Risk or side effect 2: Compatibility issues with older clients that do not support SSL/TLS. Mitigation: Upgrade clients or use alternative connection methods.
• Roll back: Restore the original `derby.properties` file, restart the Derby Network Server process, and verify connectivity.

8. References and Resources

• Vendor advisory or bulletin: http://db.apache.org/derby/
• NVD or CVE entry: Not applicable for this configuration issue.
• Product or platform documentation relevant to the fix: https://en.wikipedia.org/wiki/Apache_Derby