A creative exploit of Palo Alto Networks’ Extended Detection and Response (XDR) software could have allowed attackers to turn it into a malicious multitool.
In a briefing at Black Hat Asia on April 17Shmuel Cohen, a security researcher at SafeBreach, described how he not only reverse engineered and hacked into the company’s proprietary Cortex product, but also weaponized it to deploy a reverse shell and ransomware.
All but one of the weaknesses associated with his undertaking have been repaired by Palo Alto. It is not yet clear whether other similar XDR solutions are vulnerable to a similar attack.
A deal with the devil in cybersecurity
There is an inevitable deal with the devil when it comes to using certain types of far-reaching security tools. For these platforms to do their job, they need to be granted highly privileged carte blanche access to every corner of the system.
For example, to perform real-time monitoring and threat detection Across IT ecosystems, XDR requires the highest possible permissions and access to highly sensitive information. And, what’s more, it cannot be removed easily. It was this immense power wielded by these programs that inspired a twisted idea in Cohen.
“I thought: Would it be possible to turn an EDR solution into malware?” Cohen tells Dark Reading. “I would take all these things that the XDR has and use them against the user.”
After choosing a laboratory subject, Cortex, he began to decode its various components, trying to understand how it defined what is and what is not harmful.
A light bulb went on when he discovered a set of plain text files that the program relied on the most.
How to make XDR evil
“But those rules are inside my computer,” Cohen thought. “What would happen if I removed them manually?”
It turned out that Palo Alto had already thought of that. An anti-tampering mechanism prevented any user from touching those precious Lua files, except the mechanism had an Achilles’ heel. It worked by protecting not each individual Lua file by name, but the folder that encapsulated them all. To reach the files he wanted, therefore, he would not have to cancel the anti-tampering mechanism, if only he could reorient the path used to reach them and bypass the mechanism entirely.
A simple shortcut probably wouldn’t have sufficed, so he used a hard link: the way your computer links a file name with the actual data stored on a hard drive. This allowed him to point his new file to the same location on the drive as the Lua files.
“The program was unaware that this file was pointing to the same location on the hard drive as the original Lua file, and this allowed me to modify the original content file,” he explains. “So I created a hard link to the files, edited and removed some rules. And I saw that as I removed them – and did another little thing that caused the app to load new rules – I could load a vulnerable driver. And from there, the entire computer was mine.”
After taking complete control of his proof-of-concept attack, Cohen recalls: “What I did first was change the security password on the XDR so it couldn’t be removed. I also blocked any communication to its servers .”
Meanwhile, “Everything seems to be working. I can hide malicious activity from the user. Even for an action that would have been prevented, the XDR will not provide a notification. The endpoint user will see green signs indicating everything goes good, while underneath I’m running my malware.”
The malware it decided to run was first and foremost a reverse shell, which allowed full control of the targeted machine. Then he successfully deployed the ransomware, right under the program’s nose.
The solution in Palo Alto failed
Palo Alto Networks has been receptive to Cohen’s research, working closely with him to understand the exploit and develop solutions.
There was one vulnerability in its attack chain, however, that they chose to leave as is: the fact that Cortex’s Lua files are stored entirely in plain text, without any encryption, despite their highly sensitive nature.
It sounds alarming, but the reality is that encryption wouldn’t be much of a deterrent to attackers, so after discussing the matter, he and the security company agreed that there was no need to change the situation. As he notes, “The it would be an extra step to read those files, but I can still read them.”
It also says that other XDR platforms are likely susceptible to the same type of attack.
“Other XDRs will implement it differently, perhaps,” he says. “Maybe the files will be encrypted. But whatever they do, I can always get around it.”