This post will discuss how the Kaseya LAN Cache sets and uses credentials when configured using default settings. It will also mention some regulatory compliance implications that could result from using the default LAN Cache configuration. For those interested in exploitation, see the companion post which demonstrates how those credentials can be abused under certain circumstances. (CVE-2019-14510 – Abusing the Kaseya LAN Cache FSAdmin – Red Team Edition) My research centered on abusing the default FSAdminxxxxxxxxx credential to move laterally from a domain member to a Domain Controller, but the same technique may be used to move between domain members and WORKGROUP computers when certain settings are applied (discussed further in the post for Red Teamers). Kaseya VSA administrators who have deployed the LAN Cache feature using default accounts should consider the potential risks to their environment and take actions to limit that risk. MSP’s who have deployed LAN Cache should work with their customers to ensure they aren’t at increased risk from the deployment. Kaseya has stated that they will issue specific guidance to their customers.
Research Background and Disclaimer
I did not intend to research the Kaseya VSA, nor has my work therein been comprehensive. The potential for abuse was discovered during the course of one of our Foundational Security Assessments of a customer environment which includes a risk review of local accounts. Discovering the wide distribution of an account named “FSAdminxxxxxxxxx” where the “x” was a set of 9 random numbers led to this research. If you have ever wondered whether regular entitlement reviews are worth your time, hopefully this post will solidify their value.
The LAN Cache
The LAN Cache is a repository where updates and software are distributed. The purpose is for the package to be published once to the LAN Cache (perhaps across a low bandwidth link to a branch office) then distributed to machines on the same high bandwidth LAN as the LAN Cache. This provides a necessary distribution method to branch offices and even remote workers. This is similar to a distribution point in SCCM, but Kaseya publishes the LAN Cache in the form of a SMB share requiring NTLM authentication.
When configuring the LAN Cache repository for the first time, the Administrator must choose between using credentials created and managed by the VSA or creating a domain account then manually assigning the required permissions. The post will focus on the implications of using the credentials created by the Kaseya VSA. It’s important to understand what happens under the hood when those accounts are used. Note that all of the information to follow was taken directly from Kaseya’s VSA R95 Agent manual on pages 58-61: http://help.kaseya.com/webhelp/EN/VSA/9050000/EN_agent_R95.pdf
When the LAN Cache is first created using the default settings, the following process occurs:
- Creating the LAN Cache
- The Administrator chooses a machine on which to create the LAN Cache repository
- If the Administrator chose to utilize default credentials, a local account is created on the computer hosting the LAN Cache repository:
- Username = FSAdmin123456789 (the numbers are a random sequence during an actual deployment)
- Password = A random strong password consisting of 15 uppercase, lowercase, numbers, and special characters
- The newly created account is made a member of the local Administrators group on the LAN Cache host
- Of note, this particular group membership appears to be utilized because the SMB share is created as a Windows administrative share, but Kaseya has acknowledged that they are actively determining the best way to reduce the permissions of this account.
- The newly created account is made a member of the local Administrators group on the LAN Cache host
- Assigning computers as LAN Cache members
- When a computer is assigned as a client to a LAN Cache repository, the same FSAdmin123456789 is created locally on the LAN Cache client
- The same password used on the LAN Cache repository computer is set on this account.
- The account is then automatically granted membership in the local Administrators group on the LAN Cache client
- When the LAN Cache client is a Domain Controller, this same account is created as a domain account with the same password and made a member of the Builtin\Administrators group of the domain. Because of the nature of domains, the account and group membership are replicated to other Domain Controllers even if they are not LAN Cache clients.
- When a computer is assigned as a client to a LAN Cache repository, the same FSAdmin123456789 is created locally on the LAN Cache client
It’s important to stop and think about what just happened if an Administrator created the LAN Cache and assigned 1000 workstations and servers to it. There is now an account that has local admin rights and shares the same username and password on each computer (including WORKGROUP computers/servers). If Domain Controllers were included as LAN Cache clients (or hosting the LAN Cache), the account also exists in the domain and has admin rights on each Domain Controller. If you don’t know the term “pass-the-hash”, take a few minutes and Google it. You will quickly come to understand the implications of what I just described. The following graphic shows how it could be abused:
Audit Compliance Implications
Many compliance standards can be ambiguous as to shared password policies, and some don’t actually provide direct requirements to meet compliance. Certain audit standards may have requirements that cannot be met by this method of granting access. The following references show varying points that may apply during an audit. The underline and italics are mine.
- PCI-DSS 3.0 Requirement 2.2 states, “Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry accepted system hardening standards. Sources of industry-accepted system hardening standards may include, but are not limited to: (a) Center for Internet Security (CIS), (b) International Organization for Standardization (ISO), (c) SysAdmin Audit Network Security (SANS) Institute, (d) National Institute of Standards Technology (NIST).” https://www.pcisecuritystandards.org/documents/Prioritized-Approach-for-PCI_DSS-v3_2.pdf
- CIS Control 4 states in part, “The second common technique used by attackers is elevation of privileges by guessing or cracking a password for an administrative user to gain access to a target machine. If administrative privileges are loosely and widely distributed, or identical to passwords used on less critical systems, the attacker has a much easier time gaining full control of systems, because there are many more accounts that can act as avenues for the attacker to compromise administrative privileges.” https://www.cisecurity.org/controls/controlled-use-of-administrative-privileges/
- NIST 800-53 IA-5(6) states, “The organization protects authenticators commensurate with the security category of the information to which use of the authenticator permits access.” https://nvd.nist.gov/800-53/Rev4/control/IA-5
- NIST 800-53 IA-5(8) states, “The organization implements safeguards to manage the risk of compromise due to individuals having accounts on multiple information systems.” https://nvd.nist.gov/800-53/Rev4/control/IA-5
Despite some audit standards being less than specific than others, most security professionals would agree that Kaseya’s default approach to granting LAN Cache access would not be appropriate. Allowing the Kaseya VSA to create and manage the accounts used to access the LAN Cache across many systems may end up with an auditor failing an organization based on the standards mentioned above.
What can the network defenders do?
An organization should always know the implications a certain software or feature may have on the risk profile of any given system (or set of systems) prior to deployment. Additionally, the existing periodic entitlement reviews should not be limited to accounts in the domain. New local accounts and group memberships can have serious implications to the risk of environment that may not be readily apparent. Lastly, if an account looks suspicious, don’t rest until you are confident the account does not pose risk above the risk appetite of the organization.
Administrators should take the following action to limit the potential damage caused by the default FSAdminxxxxxxxxx accounts:
- Remove any Domain Controllers as clients of the LAN Cache and remove all FSAdminxxxxxxxxx accounts from the domain.
- Deploy a new LAN Cache using domain credentials following least privilege principles
- Please note that I have not personally reviewed the implications of using this approach, but this is the only other option for using the LAN Cache feature according to Kaseya’s documentation. I also do not know what permissions may be truly required. I don’t recommend using the “Domain Admins” group for granting access rights.
- Ensure that local FSAdminxxxxxxxxx accounts are removed from all workstations and servers in the environment. It’s unclear if the VSA will do this automatically.
- Kaseya also offers peer-to-peer file sharing as an alternative to the LAN Cache, and their security team provided this as the current recommended solution. I did not perform any research surrounding this technology or implementation, and I cannot speak to the effectiveness of security controls. It does appear that the new technology has moved away from using local accounts and SMB in favor of PKI and HTTPS though. https://helpdesk.kaseya.com/hc/en-gb/articles/229039628-Use-of-digital-certificates-to-secure-Endpoint-communication-channel
Disclosure Timeline
6/20/2019 – Initial discovery of FSAdminxxxxxxxxx accounts and research into how they are used
6/21/2019 – Performed PoC exploitation using off-the-shelf toolsets. Crafted an email and sent to Kaseya security team
7/12/2019 – Sent an email to Kaseya security requesting a status
7/16/2019 – Received first response from Kaseya and I responded with clarifying information
7/18/2019 – Received second response from Kaseya that provided a recommendation to use the domain account method rather than the default method
7/24/2019 – Conference call with Kaseya senior executive team where they promised to investigate and demonstrated commitment to take the issue seriously
8/1/2019 – Submitted CVE request to Mitre and CVE-2019-14510 received (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14510)
8/22/2019 – Conference call with Kaseya security and software architecture teams clarifying the issue further
9/6/2019 – Received notice that Kaseya would offer specific guidance to their customers regarding this issue
10/9/2019 – Public Disclosure
