Endpoint Detection and Response (EDR) can be beneficial in detecting and responding to hacking attacks, but if misconfigured or vulnerable, they can also increase hacking risks since they are generally trusted and granted high privileges.
The use of Endpoint Detection and Response is growing rapidly and for good reasons. Their promise is to keep systems safe by monitoring and detecting malicious activities through data analytics and deception. After detection, EDRs also try to stop attacks – often through automated responses. EDRs usually need broad access to the system, and this is what can turn them into an interesting attack surface for hackers.
EDRs have created security issues before. Research by Optiv and others shows how EDRs by different vendors can be hacked through hooking. What these approaches have in common with other EDR related vulnerabilities and bypassing techniques documented in the National Vulnerability Database (NVD) – is that they focus on bypassing the detection of the EDR itself rather than abusing its functionalities and privileges. Our new findings highlight how the overall security of an EDR can be compromised by a web interface interacting with the EDR.
Our research found new configuration and design issues in a popular EDR system. During a recent red team exercise, we found three now patched zero-day vulnerabilities in the Cynet 360 web portal. We worked through a responsible disclosure process with Cynet, we successfully addressed the design issues in the latest Cynet 360 version. Now it is up to you to install the latest version and to address the default password issues.
This post revisits how we identified these high-severity vulnerabilities, how they could have been exploited, and what EDR users and vendors need to do to stay safe.
Cynet 360 is an EDR that allows users to monitor and respond to security threats. Like other EDR solutions, Cynet 360 runs an agent on the target machines that continuously collects data and sends it to a master node where alerts are generated.
The default Cynet 360 setup also includes a web portal running on port 8443 for the management node, which will be the focus of this blogpost. The portal can be configured to be reached externally, internally, or limited to a local host network interface. The default configuration is having port 8443 accessible internally for the required communication between the agents, slave, and master nodes.
Through the portal users and administrators/operators are allowed to view and take actions on various functionalities depending on their privileges, including:
The hacker’s wish list: five attack scenarios
We found five attack scenarios to be particularly interesting from an offensive point of view during red teaming:
A default password issue allows hackers to achieve all five attack objectives. Three separate and new vulnerabilities allowed hackers to achieve three out of five.
As a standard step in red teaming, we try to find default credentials for target software. To our surprise, Cynet 360 has a default credential for the on-premise versions, documented in the public user guide.
Users are encouraged to change the credentials. And yet, it worked on all the Cynet 360 on-premise portals we encountered during red team exercises.
At this point all the possible blue team remediation actions could be converted into offensive actions. The hacker can run arbitrary commands on the machines, isolate, un-isolate, pull files, or shutdown/restart them. See Figure 3 for available options.
If a hacker can disable or redirect the alerts, then they can cause as much or as little noise as they want without getting detected. Figure 4 pictures some of the available alert actions that we could access and as you can see in Figure 5, we were also able to modify alert recipients.
This checks off #1 and #2 from the hacker wish list. Attack scenarios #3, #4, and #5 can also be achieved, this time even without any default credentials.
