CVE-2021-30120
📋 TL;DR
This vulnerability allows attackers to bypass two-factor authentication (2FA) in Kaseya VSA by manipulating client-side authentication logic. Attackers who obtain valid credentials can use a proxy to modify server responses and gain unauthorized access without providing the second factor. This affects all Kaseya VSA users with 2FA enabled on versions before 9.5.7.
💻 Affected Systems
- Kaseya Virtual System Administrator (VSA)
📦 What is this software?
Vsa by Kaseya
⚠️ Risk & Real-World Impact
Worst Case
Complete compromise of the Kaseya VSA management platform, allowing attackers to deploy ransomware, steal sensitive data, and gain persistent access to managed endpoints across an organization's entire infrastructure.
Likely Case
Unauthorized administrative access to the VSA console, enabling attackers to execute arbitrary commands on managed systems, deploy malware, and escalate privileges across the network.
If Mitigated
Limited impact if strong network segmentation, strict access controls, and comprehensive monitoring are in place to detect and block unauthorized authentication attempts.
🎯 Exploit Status
Exploitation requires valid username/password credentials and the ability to intercept/modify HTTP traffic. The technique is well-documented and requires minimal technical skill.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: 9.5.7 and later
Vendor Advisory: https://help.kaseya.com/webhelp/EN/RN/index.htm#VSA/ReleaseNotes/Release_Notes_9.5.7.htm
Restart Required: Yes
Instructions:
1. Backup current VSA configuration and database. 2. Download Kaseya VSA 9.5.7 or later from the Kaseya support portal. 3. Run the installer and follow upgrade prompts. 4. Restart VSA services. 5. Verify authentication now properly validates 2FA server-side.
🔧 Temporary Workarounds
Disable 2FA temporarily
allTemporarily disable two-factor authentication until patching can be completed, reducing the attack surface but increasing other authentication risks.
Navigate to VSA Admin > Security Settings > Two-Factor Authentication > Disable
Network isolation
allRestrict access to VSA console to specific IP ranges using firewall rules to limit exposure.
# Example iptables rule for Linux
iptables -A INPUT -p tcp --dport 5721 -s TRUSTED_IP_RANGE -j ACCEPT
# Windows Firewall
New-NetFirewallRule -DisplayName "Restrict VSA Access" -Direction Inbound -LocalPort 5721 -Protocol TCP -RemoteAddress TRUSTED_IP_RANGE -Action Allow
🧯 If You Can't Patch
- Implement strict network segmentation to isolate VSA servers from general network traffic and critical systems
- Enforce strong password policies and credential monitoring to detect compromised accounts before they can be exploited
🔍 How to Verify
Check if Vulnerable:
Check VSA version in Admin > System > About. If version is below 9.5.7 and 2FA is enabled, the system is vulnerable.Check Version:
In VSA web interface: Admin > System > About, or check registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Kaseya\VSAServer\VersionVerify Fix Applied:
After upgrading to 9.5.7+, attempt to authenticate with valid credentials while using a proxy to modify MFARequired flag. Authentication should fail if 2FA is required.📡 Detection & Monitoring
Log Indicators:
- Multiple failed authentication attempts followed by successful login without 2FA challenge
- Unusual source IP addresses accessing VSA console
- Authentication logs showing MFARequired flag manipulation
Network Indicators:
- HTTP traffic to VSA login endpoint with modified response headers
- Proxy tools like Burp Suite communicating with VSA servers
- Unusual authentication patterns bypassing normal 2FA flow
SIEM Query:
source="vsa_logs" AND (event_type="authentication" AND mfa_bypass="true") OR (http_request_modified="true" AND destination_port="5721")