3CX DLL-Sideloading attack: What you need to know
We have observed that the systems we tested the Early Access Agent on have run into issues with SAML Authentication. Any system we installed the BETA version on has broken authentication relying on our Hybrid Azure ADFS for authentication. Meaning that the users affected cannot log into any of our internal applications that usually rely on Single Sign ON via ADFS. Any attempts to log in to applications/resources reliant on this authentication result in null values being sent to ADFS, based on review of the logs from Azure.
I will add, that if we uninstall the EAP/BETA version and install the main version the issue is resolved.
We have seen the same issue with a customer that recently (last week) got the new endpoint agent from Sophos (https://support.sophos.com/support/s/article/KB-000043550?language=en_US).
Before the update clients were able to authenticate using adfs with sso. This is when logging in to internal applications.After the update the ADFS page suddenly shows a login prompt and it doesn't matter which login credentials you provide, it will just not log you on and bring the credentials popup back.
The customer found out that if they removed the Sophos Endpoint Agent it would work again, so we started looking in that direction.We tested by pulling a laptop that was offline for 20 days from the shelve, try the sso login -> worked, forced a sophos agent update and reboot, try the sso login again -> didn't work anymore.
After a lot of research we found out it was the "Real Time Scanning - Internet" on the client option that caused this. When we disabled that option SSO worked again.As a workaround we've now added the client domain as a website exclusion in the endpoints policy and this fixed the issue right away for all their endpoints.
The most confusing was that it didn't show any errors or blocks anywhere from Sophos. Not on the client, not in Sophos Central.Could be because they're running InterceptX Essentials, but would've at least liked to see something. Hope this is not a preview of what is going to happen for all our customers in the upcoming weeks...
Do you see Server Sent Events (SSE) failing in the Developer tool of the browser?
Hard to say now, as we already have the workaround in place... Had to do this in the base policy because of interceptx essentials, so there's no real way to troubleshoot anymore unless I want to break it again for all machines.
On a test computer, you could go into:HKLM\SOFTWARE\Sophos\Management\Policy\ThreatProtection\[revision]\web_protectionIn the approved_site_patterns value, I assume you see the exclusion you made. With Tamper Off, you could remove it and restart the "Sophos Network Threat Protection" service. I assume this then breaks the site again?If so, do you see "red" entries in the Network view? I assume if you add the domain column, it will be a resource from the domain you excluded?
Do these appear to be SSE related requests?
Thanks.
I'll ask the customer if they still have a test machine available for me. Will get back to you!
I found a test machine in the customer lan in our dc, installed customers Sophos Endpoint on it and tried your steps to reproduce the issue... Unfortunately this didn't work... I cannot get it to "not work" now ;-)I've asked the customer if they have a physical machine in their office available for me to run some tests on.
By the way, I'm almost convinced this has to do with the "SSL/TLS decryption of HTTPS websites" setting that also came in effect with the new agent.This setting is supposed to be turned off by default according to https://support.sophos.com/support/s/article/KB-000043550?language=en_US but it seems to be turned ON by default as we're now getting more customer complaints about opening websites with error message "the encryption used by the server hosting this url is insecure".Article https://docs.sophos.com/central/Customer/help/en-us/ManageYourProducts/Overview/GlobalSettings/DecryptHTTPS/index.html#turn-decryption-on-or-off shows an instruction on how to exclude sites from being decrypted/checked, but that option is nowhere to be found in the MSP portal of Sophos Central (I am partner super administrator so this should be somewhere in the global settings...)Only options I have for now are creating exclusions for the sites in the threat policy or disabling the SSL/TLS decryption (which is probably what I'm going to do...)
If you use a "bad ssl" test site, then if web protection (not web control) is enabled, when you visit a site such as:dh-composite.badssl.com/
Inspection disabled you get the browser message;
Inspection enabled:
The sites mentioned by our customers seem to be sites that require the user/computer to have/select a certain certificate to log on. Instead of the log on / select your certificate page they now immediately get the Website Blocked page from Sophos.
When I create an exclusion for the site it works again (because it will not be checked in any way anymore).
Maybe the customers ADFS site is not running TLS 1.2 and could be blocked for that reason? (though you don't see an error because the failure happens during a log on process and it will treat it as a failed logon)
When we initially discovered the issue we ran test logins and the ADFS system showed that no values were submitted to ADFS, despite entering username and password when prompted.