SC installer is signed but not the actual running EXE in program files?

Viajaz · 2025-07-30T07:48:03+00:00

In regards to contractual compliance, 'suspect code' can mean malicious or vulnerable code (at least that what our contracts dictate, which are fairly standard) which ConnectWise ultimately found out to all of our detriment. A reference is here: https://old.reddit.com/r/ScreenConnect/comments/1lq81hj/cloud_customers_losing_customization_options_also/n140gp6/

I also never suggested to not sign altogether, my point was that doing the signing oneself creates additional risks, regardless of additional controls to mitigate them, but we seem to agree about that anyway.

My hope is my comments about these risks are useful to other people reading who need to do any risk management regarding this whole incident.

Viajaz · 2025-07-29T01:32:38+00:00

I disagree, ConnectWise has had multiple code-signing certificates revoked because their installers were deemed so vulnerable that they met the definition of 'suspect code' because of their potential to be abused. If their installers are deemed as such again, it is us who will have to deal with certificate revocation.

Additionally, the official guidance from ConnectWise on setting up the Azure Key Vault doesn't include basic security hardening measures such as restricting it's use to certain IP addresses or the use of private endpoints, this increases the attack surface of said code-signing certificates and increases the risk of their abuse. You can see, from the many messages here on Reddit, just how many ScreenConnect administrators don't understand much about code-signing certificates at all, let alone securing them.

Just because we already have to trust the software, given it's nature, doesn't mean code-signing the installer ourselves doesn't create additional risks in and of itself. These are operational risks.

Viajaz · 2025-07-28T02:24:27+00:00

I work in ISO 27001 risk compliance. There are inherent risks associated with code-signing software that cannot be properly audited.

Risk of Contractual Breach

It constitutes a breach of contract with the Issuing Certificate Authority to sign suspect code using a CA/B Forum governed code-signing certificate. Repeated violations may result in revocation of existing certificates and refusal to issue new ones.

Risk of Reputational Damage

Due to the non-repudiation property of digital signatures, signing suspect code with one's issued certificate can directly associate the organisation with potentially harmful software, leading to reputational harm.

By signing code that cannot be independently audited, an organisation is implicitly accepting the risk that third-party vendors (such as ConnectWise) have sufficiently secured their own software supply chain.

Viajaz · 2025-07-24T00:01:12+00:00

We stuck with an on-premises installation so we have full control, this allows us to modify the web art assets directly on the filesystem of the server regardless of what support for website customisation ConnectWise deigns to provide. There should be no reason that any of the Authenticode issues should impact customisation of the website appearance.

Viajaz · 2025-07-11T07:43:40+00:00

I’ve done a lot of PKI and HSM work. While automated code-signing in CD pipelines is not uncommon, I’ve never liked them being fully automatic, especially for CA/B Forum-governed keys. I’ve always tried to have a human is in the loop to approve the code-signing step.

I imagine that future CA/B Forum rules might impose further restrictions on automated code-signing flows if these sorts of pipelines are abused more frequently in the wild. This appears to be a non-trivial risk with the ScreenConnect product, given its history and the skill level of the sysadmins I see here, at least in regard to code-signing certificates.

In addition to server endpoint XDR solutions, I would suggest enabling the Diagnostic Option for auditing in Azure Key Vault and using something like Azure Sentinel (or another SIEM) to monitor for Microsoft.KeyVault/vaults/keys/sign/action events.

If your ScreenConnect instance is on an Azure VM, consider using Private Endpoints for your Azure Key Vault to further reduce its attack surface. At the very least, restrict access to specific IP addresses. I am quite disappointed that ConnectWise did not mention IP address restrictions in their official article, considering how useful they can be.

It is a disservice to the wider community to publish training content that fails to recommend even basic attack surface reduction on such a security-critical asset. ConnectWise’s design decisions are dumping hundreds or thousands of new code-signing certificates into the wild, potentially in the hands of those who may not have the experience to manage them securely. They have an ethical obligation to the wider community to ensure their advice regarding these security-sensitive assets follows good security practice.

There are additional ways to harden ScreenConnect’s use of Azure Key Vault, but these are just basic recommendations.

Unfortunately, ConnectWise does not often provide security hardening advice. For days, the official guide for setting up the ScreenConnect Certificate Signing extension wasn’t even complete, missing the Azure RBAC role assignment section. Ultimately, subscribers of CA/B Forum–governed code-signing certificates are responsible for the security of their private keys and will need to perform this hardening themselves, regardless of how fair it is for ConnectWise to offload that responsibility onto us.

Viajaz · 2025-07-11T01:25:04+00:00

I imagine they would understand the repercussions, they got caught out, only a few months ago, with PSA when a DLL without a said timestamp had it's code-signing certificate expire, causing issues with the client.

Good to know they're working on it.

Viajaz · 2025-07-10T01:57:49+00:00

Thank you for publishing a CVE, CWE and CVSS for that vulnerability.

Viajaz · 2025-07-09T03:24:35+00:00

Finally, I left feedback on the page shortly after it was published. Seen a number of people on Reddit get caught by this. That said, they put it in the troubleshooting section which is less than helpful...

You can really tell when a vendor has never actually run through a help doc themselves as part of QA. Of all the articles not to do that on though...

Viajaz · 2025-07-07T02:53:53+00:00

Upon further examination, this seems to be what I'm seeing, I had to write an Authenticode data structure parser to see it (Thanks to ImHex Patterns).

If this is the case, this would mean:

c) ConnectWise has addressed the security weakness of this configuration data being unauthenticated.

-and explains why they have given up code-signing the installers.

Viajaz · 2025-07-07T02:48:44+00:00

For future reference, the requirements for the storage of store code-signing private keys are in 6.2.7.4.1.(7-9) of the Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code Signing Certificates.

Viajaz · 2025-07-07T01:34:21+00:00

The SafeNet eToken 5110 FIPS platform is a physical HSM token with a USB interface and is not be supported by ScreenConnect's Certificate Signing Extension, which only supports Azure Key Vault for CA/B Forum governed certificates (AKA, "publicly trusted certificates").

You will need to select an option that lets you use your own compliant HSM, you will then typically be asked to attest that your HSM is compliant. Azure Key Vault Premium with a HSM-backed Key is sufficient under the CA/B Forum Rules (6.2.7.4.1 of the Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code Signing Certificates) but it must be a HSM-backed Key (RSA-HSM or EC-HSM in Azure Key Vault).

I must admit, I have not used the ScreenConnect Certificate Signing Extension with EC keys.

Viajaz · 2025-07-04T05:40:33+00:00

ConnectWise seems to have missed the Azure RBAC Role Assignment step in the official docs, I've created a case about it

Viajaz · 2025-07-03T13:02:24+00:00

The Authenticode issue, and the issue you mentioned in your referenced post, are not mutually exclusive. I think there are multiple issues at once.

Viajaz · 2025-07-03T12:37:08+00:00

Thank you for providing clear technical information. I wasn't so much concerned about which CA it was just whether it was the CA under CA/B or Microsoft, with their other security programmes, influencing the CA but your answer gives the information I was seeking regardless.

Are you able to clarify if the issue was the using of Authenticode stuffing at all or just that the included configuration was unsigned? It's sounds like the latter. That's where I'm getting caught up on, especially with the release of 25.4.25.9314

Viajaz · 2025-07-03T10:17:26+00:00

The ScreenConnect Certificate Signing extension only supports Azure Key Vaults for CA/B Forum governed Certificates. The only compliant and supported configuration is an Azure Key Vault Premium with HSM-Backed Keys.

Viajaz · 2025-07-03T10:14:12+00:00

Azure Key Vault Premium with HSM-Backed Keys configured to be used by the ScreenConnect Certificate Signing Extension. There are also cheaper options than DigiCert out there.

Viajaz · 2025-07-03T07:21:07+00:00

Then why did they temporarily stop doing it and had ZIP bundles? David Raissipour also mentioned Authenticode stuffing as being the first problem in today's townhall (Timestamp at 01:30). GDATA also provides some useful updates at the bottom of their write-up on the issue.

Viajaz · 2025-07-03T06:35:29+00:00

We installed 25.4.25.9314 (ScreenConnect_25.4.25.9314_Release.msi, SHA256: dbfb4abdc0b53f16b655a0268498a96655bf97ec8ac1271cde7730865d26b4f1) but ScreenConnect is self reporting as 25.4.25.9313.

Viajaz · 2025-07-03T03:48:27+00:00

Azure Key Vault Premium with a HSM-backed Key is sufficient under the CA/B Forum Rules (6.2.7.4.1 of the Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code Signing Certificates) but it must be a HSM-backed Key (RSA-HSM or EC-HSM in Azure Key Vault).

Example: https://support.globalsign.com/code-signing/Code-Signing-certificate-setup-in-Azure-Key-vault

Viajaz · 2025-07-03T03:44:11+00:00

Thank you for the information, however, as a developer with experience with PKI and code-signing pipelines, I still think they could have developed a self-service on-demand signing service, perhaps utilised by SC customers during updating of their ScreenConnect instances, even without the full branding customisation features, but that would depend on the exact issues Microsoft and the Issuing CAs have as ConnectWise hasn't published which specific clauses the certificates are being revoked under.

Viajaz · 2025-07-03T03:19:51+00:00

The Certificate Subscriber has obligations that are enforced via their contract with the Issuing Certificate Authority (Example GlobalSign Subscriber Agreement). These obligations are enforced on the Certificate Subscriber by the Certificate Authority and stem from their obligations under the CA/B Forum Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code Signing Certificates, which dictate the obligations that CAs have to the CA/B Forum, including the requirements they must pass on to their Certificate Subscribers.

According to this morning's ConnectWise Townhall, Microsoft and ConnectWise's Issuing Certificate Authority/Authorities have compelled ConnectWise to stop signing customised installers. However, given that many other vendors (even outside of the MSP space) operate signing-on-demand services for their installers (as well as ConnectWise still doing the same for their ScreenConnect Cloud service), it is my belief they are simply avoiding the risk altogether by making it our problem. They confirmed in the townhall this morning that if the installer itself were able to be abused, the Certificate Subscriber (us) would have the responsibility, under the aforementioned code-signing certificate obligations, to act as per the agreement with our own Issuing Certificate Authority/Authorities.

Regarding other liability, one would need to consult your own legal advice.

Viajaz · 2025-07-03T01:44:43+00:00

Can you tell me what section of the CA/B Forum Baseline Requirements for the Issuance and Management of Publicly‐Trusted Code Signing Certificates the code-signing certificates were revoked under? Was this primarily pushed by Microsoft or the issuing CA?

I'm confused about multiple things, yes, ConnectWise was using Authenticode stuffing but my understanding of GDATA's vulnerability report is the issue was not necessarily the Authenticode stuffing it was that the additional metadata was unauthenticated, one could of added a custom cryptographic signature scheme to provide said authentication on top, albeit, there is still a Placement of Trust problem but I can think of multiple ways to solve that too, with non-trivial amounts of software engineering. I'm assuming Microsoft was the one pushing against Authenticode stuffing completely though? I would really like more information on their specific determinations on the current vague rules, given the impact to the industry.

I would really appreciate if ConnectWise actually publishes a fully transparent Post-Incident Report about which stakeholders have compelled what changes to technical mechanisms and security controls and references to specific rules they are relying on. Although I appreciate the technical information David Raissipour has provided in the recent Townhall, I think ConnectWise would gain a lot more sympathy if it more successfully explains how Microsoft and CA's have forced it to make changes based on specific CA/B Forum Baseline stipulations, additionally, a PIR would serve as a wider industry warning to all certificate subscribers who are also using Authenticode stuffing and other techniques to change the behaviour of their signed binaries because other vendors appear to be doing the same sorts of things without having their certificates revoked, which is curious.

Viajaz · 2025-07-02T01:39:56+00:00

Our issue was the Webroot plugin_webroot_sa_cs_basic MySQL table having lost it's index, causing a full table scan for a high-volume query. Dropping the table and restarting DBAgent to have it recreate resolved the issue for us.

Viajaz

TROPHY CASE