How to remediate – Detect RPC over TCP

1. Introduction

Detect RPC over TCP indicates an RPC service is running on a port that isn’t registered with the portmapper service. This can happen for legitimate reasons, but it also means the service might be exposed unexpectedly. Affected systems are typically those using Windows Remote Procedure Call (RPC) or similar services on Linux/Unix platforms. A successful exploit could allow remote code execution or denial of service. Impact on confidentiality is possible if sensitive data is transmitted over the RPC channel; integrity can be compromised through malicious code injection, and availability may be affected by service disruption.

2. Technical Explanation

This vulnerability occurs when an RPC service starts listening on a TCP port but doesn’t register itself with the portmapper (port 111). This means clients might not be able to discover the service, and security tools like Nessus may report it as potentially exposed. An attacker could attempt to connect directly to the open port and exploit any vulnerabilities in the RPC service itself. The preconditions for exploitation are an open TCP port running an RPC service and a lack of registration with the portmapper.

• Root cause: The RPC service failed to register with the portmapper, or the portmapper is unreachable due to firewall rules or network issues.
• Exploit mechanism: An attacker could attempt to connect to the open TCP port and exploit vulnerabilities in the RPC service’s implementation. For example, they might try buffer overflows or format string bugs if present.
• Scope: Windows systems using DCOM/RPC are commonly affected, as well as Linux/Unix systems running RPC-based services like NFS.

3. Detection and Assessment

To confirm whether a system is vulnerable, first check for open ports listening on TCP that aren’t registered with the portmapper. Then, attempt to identify the service running on those ports.

• Quick checks: Use netstat -ano | findstr (Windows) or netstat -tulnp | grep (Linux/Unix) to see if a process is listening on the port.
• Scanning: Nessus vulnerability ID 85641 can detect this issue, but results may be false positive.
• Logs and evidence: Check Windows Event Logs for RPC-related events or errors. On Linux/Unix, examine system logs (e.g., /var/log/syslog) for service startup messages.

netstat -ano | findstr 135

4. Solution / Remediation Steps

To fix this issue, ensure the RPC service is properly registered with the portmapper or that the service doesn’t require registration. If it’s a legitimate service, investigate why it isn’t registering and correct the configuration.

4.1 Preparation

• Ensure you have access to restart the RPC service. A roll back plan is to restore the original configuration or restart the server.
• A change window may be needed depending on the impact of restarting the RPC service. Approval from a system administrator might be required.

4.2 Implementation

1. Step 1: Check if the RPC service is configured to automatically register with the portmapper. This setting varies by operating system and service configuration.
2. Step 2: If not, configure the service to register with the portmapper. On Windows, this may involve modifying registry settings related to DCOM or RPC.
3. Step 3: Restart the RPC service to apply the changes.

4.3 Config or Code Example

Before

(Example - Windows Registry)
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftRpcClientInterface]
"UseLocalHostOnly"=1

After

(Example - Windows Registry)
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftRpcClientInterface]
"UseLocalHostOnly"=0

4.4 Security Practices Relevant to This Vulnerability

List only practices that directly address this vulnerability type. Use neutral wording and examples instead of fixed advice. For example: least privilege, input validation, safe defaults, secure headers, patch cadence. If a practice does not apply, do not include it.

• Practice 1: Network segmentation to limit the blast radius if an RPC service is compromised.
• Practice 2: Regularly review and update firewall rules to ensure only necessary ports are open.

4.5 Automation (Optional)

# Example PowerShell Script to check RPC registration status
Get-WmiObject Win32_Service | Where-Object {$_.Name -like "*RPC*"} | Select-Object Name, StartMode, State

5. Verification / Validation

Confirm the fix worked by checking if the service is now registered with the portmapper and that security tools no longer report it as exposed.

• Post-fix check: Run rpcinfo -p (Linux/Unix) or use a tool like PortQryUI on Windows to verify the RPC service is listed in the registered services.
• Re-test: Re-run the Nessus scan and confirm that vulnerability ID 85641 no longer appears.
• Smoke test: Verify any applications or services relying on the RPC service are functioning correctly.
• Monitoring: Monitor system logs for RPC-related errors or unexpected behavior.

rpcinfo -p localhost

6. Preventive Measures and Monitoring

Suggest only measures that are relevant to the vulnerability type. Use “for example” to keep advice conditional, not prescriptive.

• Baselines: Update security baselines or policies to include requirements for RPC service registration.
• Pipelines: Add checks in CI/CD pipelines to ensure proper configuration of RPC services during deployment.
• Asset and patch process: Implement a regular patch cycle for operating systems and applications that use RPC.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 1: Restarting the RPC service may cause temporary service disruption.
• Risk or side effect 2: Incorrect registry modifications could lead to system instability.
• Roll back: Restore the original configuration settings or restart the server if necessary.

8. References and Resources

• Vendor advisory or bulletin: No specific vendor advisory available for general RPC registration issues.
• NVD or CVE entry: https://nvd.nist.gov/vuln/detail/85641
• Product or platform documentation relevant to the fix: Microsoft documentation on DCOM and RPC configuration.