1. Introduction
RSA Security Console Detection identifies instances where the RSA Security Console web server is running on your network. This application manages users and security tokens for RSA appliances, handling authentication, access logs, and password policies. A publicly accessible console presents a risk of unauthorised access to user accounts and sensitive configuration data, potentially impacting confidentiality, integrity, and availability.
2. Technical Explanation
The vulnerability exists because the RSA Security Console is exposed on a network connection. Attackers can attempt to gain access to the web interface and exploit default credentials or known vulnerabilities within the application itself. Successful exploitation allows attackers to manage users, tokens, and authentication settings. There is no specific CVE currently associated with simply detecting the presence of the console; however, older versions may be vulnerable to documented attacks.
- Root cause: The web server hosting RSA Security Console is accessible from a network.
- Exploit mechanism: An attacker attempts to access the console via its web interface (typically HTTPS) and uses default credentials or brute-force techniques. If successful, they can modify user accounts and system settings. For example, an attacker could attempt to log in using the default username ‘admin’ and a common password.
- Scope: This affects any server hosting RSA Security Console, regardless of operating system, but is most relevant when exposed directly to the internet or untrusted networks.
3. Detection and Assessment
Confirming the presence of the console can be done through network scanning and web interface identification. A thorough assessment involves checking for default credentials and known vulnerabilities.
- Quick checks: Use a web browser to access the server’s IP address or hostname on port 443 (HTTPS). If the RSA Security Console login page appears, it is present.
- Scanning: Nessus plugin ID 68952 can identify RSA Authentication Manager/Security Console. OpenVAS also has relevant checks. These are examples only and may require updates.
- Logs and evidence: Web server access logs should be checked for requests to the console’s URL path (e.g., /rsa). Event IDs related to authentication attempts on the server might indicate activity.
curl -I https://[target_ip]4. Solution / Remediation Steps
The primary solution is to restrict access to the RSA Security Console or remove it if no longer needed. If required, ensure strong authentication and regular security updates are applied.
4.1 Preparation
- Ensure you have access to restore from the snapshot if necessary. A roll back plan involves restoring the snapshot or reverting configuration changes.
- A change window may be required depending on the impact of stopping the web server. Approval from the security team is recommended.
4.2 Implementation
- Step 1: Restrict access to the RSA Security Console using a firewall or network ACL, allowing only trusted IP addresses.
- Step 2: If the console is not required, uninstall it from the server.
- Step 3: If the console must remain accessible, enforce strong password policies and multi-factor authentication.
4.3 Config or Code Example
Before
# Firewall rule allowing access from any source IP address
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
After
# Firewall rule allowing access only from trusted IP addresses
iptables -A INPUT -s [trusted_ip]/32 -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP
4.4 Security Practices Relevant to This Vulnerability
Several security practices can help prevent this issue.
- Practice 1: Least privilege access to reduce the impact if the console is compromised.
- Practice 2: Network segmentation to isolate sensitive applications like RSA Security Console from untrusted networks.
4.5 Automation (Optional)
# Example Ansible playbook to restrict access via firewall
- name: Restrict RSA Security Console Access
iptables:
chain: INPUT
protocol: tcp
dport: 443
jump: DROP
state: present
source: [trusted_ip]/32
5. Verification / Validation
Confirm the fix by verifying that access to the console is restricted as intended and that no default credentials are active.
- Post-fix check: Attempt to access the console from an untrusted IP address. The connection should be refused or blocked.
- Re-test: Re-run the curl command from section 3. It should not return a valid RSA Security Console login page.
- Smoke test: Verify that authorised users can still access the console from trusted networks.
- Monitoring: Monitor web server logs for failed authentication attempts or unexpected traffic to the console’s URL path.
curl -I https://[target_ip] # Should return a connection refused error6. Preventive Measures and Monitoring
Implement security baselines and regular vulnerability scanning to prevent similar issues.
- Baselines: Update your server hardening baseline to include restrictions on access to sensitive applications like RSA Security Console.
- Pipelines: Integrate SAST tools into your CI/CD pipeline to identify potential vulnerabilities in web application code.
- Asset and patch process: Review the asset inventory regularly, identifying any unnecessary services or software running on servers. Implement a regular patch cycle for all installed software.
7. Risks, Side Effects, and Roll Back
Restricting access could disrupt legitimate users if not configured correctly.
8. References and Resources
- Vendor advisory or bulletin: RSA Support
- NVD or CVE entry: No specific CVE for detection, but search for vulnerabilities related to RSA Authentication Manager on the NVD website (https://nvd.nist.gov/).
- Product or platform documentation relevant to the fix: RSA Security Console Documentation