Validating the Bishop Fox Findings in ConnectWise Control

In computer security, responsible disclosure is a vulnerability disclosure model in which an issue is publicly disclosed only after a period of time that allows for the affected party to patch/resolve the problem in a reasonable amount of time. For most bugs that are not being actively exploited, this period usually lasts 90–120 days. After this grace period, the details of the findings are published in order to educate the masses on the risks posed should those affected decide not to patch.

Security researchers at Bishop Fox uncovered eight vulnerabilities in ConnectWise Control that ranged from low to high severity with one deemed critical by the security company. Today marks the end of the embargo for these vulnerabilities and Huntress was contacted to:

• Validate Bishop Fox’s (top notch) research
• Confirm if the issues were patched
• And weigh-in on the community impact

We sincerely hope you enjoy this no-hype overview and please don’t hesitate to post your questions to r/MSP or chat with us on MSP Geek’s Slack.

We've updated each section of this blog with additional information we gained from discussions with Bishop Fox and with the ConnectWise Control team. Additionally, ConnectWise released a summary matrix of the analyses and their own response.

Administrative Note: the flow of this blog mimics the order of Bishop Fox’s findings and is not ranked by priority or severity. This blog is also a work in progress that we’ll continue to update as we complete our research.

Appearance Modifier Cross-Site Scripting (XSS)

Status: Partially Mitigated
CVE ID: CVE-2019-16512

Bishop Fox Summary: The ConnectWise Control application is affected by a stored cross-site scripting vulnerability in the Appearance modifier. The vulnerability allowed any malicious customer to execute arbitrary JavaScript in visitors’ browsers.

As demonstrated above, this bug works exactly like the Bishop Fox team described. For those that didn’t notice, this stored XSS vulnerability abuses a legitimate feature within Control that allows MSPs/IT Departments to customize the appearance of their product. As you can imagine, completely removing this capability would be fairly controversial for ConnectWise so we believe they’ve opted to accept the risk.

This simply means that hackers could register for trials of Control and potentially serve malicious JavaScript from a *.screenconnect.com domain. Theoretically, this could be a building block for other attack chains. However, we understand ConnectWise’s decision. With that said, ConnectWise could consider a middle-ground approach that disables the Appearance Modifier feature on trials. This would raise the level of effort required for hackers and require them to compromise users’ accounts to perform this XSS attack.

Overall this is not a great situation, but it’s not worth losing sleep over.

Update 1/25/2020: After discussing the Bishop Fox findings with ConnectWise, they confirmed our assumptions that this behavior is intentional. We suggested that it would be best to not allow HTML script tags but that this filtering has been tried unsuccessfully many times. Based on the most recent statements from ConnectWise on the issue, they are removing the appearance customization feature from trials which goes a long way to mitigating malicious use of this feature. We think it’s a great compromise.

Cross-Origin Resource Sharing (CORS) Misconfiguration

Status: Mitigated
CVE ID: CVE-2019-16517

Bishop Fox Summary: Both the ConnectWise Control cloud and customer instances were affected by a CORS misconfiguration, which reflected the Origin provided by incoming requests. This allowed JavaScript running on any domain to interact with both the Control cloud and customer Control server APIs and perform administrative actions, such as signing session identifiers, without the victim’s knowledge.

Based on our analysis, it appears the ConnectWise team mitigated the exact CORS and CSRF issue in SetAccountAttributes that was highlighted in the Bishop Fox report. 🎉

However, we did notice that other endpoints — like GetMessages—fail to reject external origins as demonstrated in the video with https://himom.com.

Control’s configuration of CORS appears to be implemented on an endpoint-by-endpoint basis which is a bit like playing whack-a-mole (hard to get them all and keep up with the changes). Endpoints like GetMessages appear to “reflect” whatever Origin is specified, thus open up the opportunity for other undesirable actions.

We agree with Bishop Fox’s assessment that is a “High” security risk.

Update 1/25/2020: After discussing this vulnerability with the ConnectWise Control team they confirmed they have a limited whitelist of endpoints that will allow any origin for CORS. After receiving the report from Bishop Fox, ConnectWise removed the SetAccountAttributes endpoint from the whitelist. They also informed us that GetScripts and GetMessages are intended to be public endpoints which is why they allow cross-origin requests. Based on this information, it looks like ConnectWise Control is correctly using CORS to defend against malicious JavaScript.

Cross-Site Request Forgery (CSRF)

Status: Mitigated
CVE ID: CVE-2019-16513

Bishop Fox Summary: The ConnectWise Control cloud and user instances do not implement CSRF protection. If a user with Adobe Flash or an outdated version of Chrome or Chromium visited a third-party website while authenticated to the Control application, script running on the malicious website would be able modify a user’s Control account by sending API requests, without the knowledge of the victim Control user.

As demonstrated in this video, Bishop Fox’s JavaScript PoC for disabling Control’s “suspicious account activity” email alerts no longer works. This appears to be a direct result of ConnectWise’s efforts to enforce CORS on the SetAccountAttributes endpoint. However, this video also highlights how it’s still possible to forge a request from an external website via the GetScripts endpoint.

To provide comprehensive protection throughout Control, CSRF-prevention tokens should definitely be used. We again agree with the Bishop Fox team’s recommendation:

Update 1/25/2020: Security works best when there are multiple mitigations that work together to prevent attacks. The industry term to describe this is defense-in-depth. Without CSRF tokens, a simple mistake that caused the CORS whitelist to be too permissive meant that attackers from any domain could disable security settings for a ConnectWise Control account. We recommended ConnectWise implement CSRF tokens for all endpoints that modify data to further enhance security. They agreed and stated:

ConnectWise acknowledges CSRF prevention tokens as industry best practice against this type of attack and is actively planning for implementation.

The GetScripts and GetMessages endpoints are technically not vulnerable to CSRF since they don’t mutate any data. This aligns with the intention that these are public endpoints.

Personally Identifiable Information (PII) Disclosure

Status: Mitigated
CVE ID: Not Assigned

Bishop Fox Summary: The ConnectWise Control cloud service is affected by an information disclosure vulnerability that allows an unauthenticated attacker to reveal the administrator email address and postal code of an arbitrary customer Control instance.

This vulnerability was especially interesting as it could have provided hackers a trove of pre-positioning and targeting data against MSPs. Our team has even mused about this idea during December’s episode of Tradecraft Tuesday. Thankfully, the ConnectWise team has removed partners’ email addresses and postal codes from the returned requests.

With that said, it’s still plausible that hackers could brute force the six-character instanceId in order to determine valid IDs. They may also be able to correlate this data with the returned currentLicenseCount to build a prioritized list of targeted instances. If ConnectWise plans to use these unique IDs for looking up sensitive data, we’d suggest they crank up the ID complexity.

User Enumeration Information Disclosure

Status: Mitigated
CVE ID: CVE-2019-16516

Bishop Fox Summary: ConnectWise Control is vulnerable to a user enumeration vulnerability, allowing an unauthenticated attacker to determine with certainty if an account exists for a given username.

As demonstrated in the video above, we have validated that Control no longer returns the X-Login-Result header which prevents attackers from identifying valid usernames. This security issue was publicly addressed in the Control 2019.5 release notes. Job well done ConnectWise!

Malicious Extension Remote Code Execution

Status: Mitigated
CVE ID: CVE-2019-16514

Bishop Fox Summary: The ConnectWise Control server is vulnerable to a remote code execution vulnerability. Administrative users could upload unsigned extension ZIP file containing executable code that is subsequently executed by the server.

Given the limited time frame before this was publicly disclosed, we’ve yet to validate this finding. Keep checking back for more updates.

Update 1/25/2020: While we weren’t able to validate this ourselves (ConnectWise Control trials don’t allow uploading custom extensions), we discussed this with the Control team and they confirmed that uploading arbitrary extensions is intentional. They also highlighted that their security stance is to treat each customer instance as they would any other machine on the internet (potentially malicious). They also confirmed that even though an extension uploaded with an invalid signature would be disabled, it was possible to execute the disabled extension as documented by Bishop Fox. This has subsequently been fixed.

Missing Security Headers

Status: Unmitigated
CVE ID: CVE-2019-16515

Bishop Fox Summary: The ConnectWise Control application does not implement modern HTTP security headers, which is a missed opportunity to implement optional security features in browsers.

This is a less exciting, low-impact finding. Yes, it is currently unmitigated and we’ll likely update this section last.

Update 1/25/2020: The ConnectWise Control team is working on implementing some of these headers and will hopefully have them deployed in the coming weeks.

Insecure Cookie Scope

Status: Mitigated
CVE ID: Not Assigned

Bishop Fox Summary: The ConnectWise Control authentication cookie, CloudAuth, is scoped to the parent domain, .screenconnect.com. When a user visits a Control instance owned by a malicious SaaS customer, the user’s CloudAuth token would be sent to the malicious user’s SaaS instance.

This is a less exciting, low-impact finding. Yes, it is currently unmitigated and we’ll likely update this section last.

Update 1/25/2020: After discussing this with the ConnectWise Control team they informed us they felt this finding was actually a more significant threat than the low security risk assigned by Bishop Fox. The team patched this vulnerability on 10/2/2019. Rather than using a single CloudAuth cookie, this cookie was split into two separate cookies; CloudInstanceAuth and CloudSiteAuth, with each being correctly scoped to reduce the chance of misuse. This seems like a solid fix.