Deep Dive: Thoughts on Juniper’s new product: Cloud Workload Protection
The blog article  announces, that Juniper’s Cloud Workload Protection can protect applications against the “OWASP Top 10”  web application security risks. Often a web application firewall (WAF) is used to help mitigate these risks. The datasheet  also mentions that it works with containerized applications and lists a set of programming languages and runtimes that are supported. To my surprise, the popular languages Python and GO are not on that list.
Another capability that this new product claims to offer really got my attention: prevention of memory-based attacks including the ones based on buffer overflows and ROP techniques. Long ago during my university time, I played a bit with simple buffer overflows and think I know how they work. A few years ago I also learned about the ROP technic. Todd Mortimer from the OpenBSD project hardened OpenBSD against this technic and explained his work in talks at BSD conferences . He also wrote a paper about his work .
ROP stands for “return-oriented programming” . Modern processors and operating systems with support for the “NX bit”  can prevent that an attacker executes code that she injected. The NX bit ensures that memory pages that are writeable can not be executed. To circumvent that attackers use code functions that are already present in memory. Then they chain these functions (called gadgets) together. Usually with the goal to give them a shell that allows controlling the system. To make this work an attacker needs to be able to change the call stack and manipulate the control flow of the program. Finding gadgets in memory is not hard since good tooling for that purpose is easily available. The defence method Todd Mortimer applied in OpenBSD reduces the number of gadgets substantially.
With this background, I was really curious to discover what method Juniper uses to stop ROP based attacks! But I was disappointed: I could not find technical documentation on Junipers website. It looks like the marketing team is much faster than the technical doc writers.
While searching further I found via an article on packetpushers.net . The product is actually not from Juniper, but from their partner “K2 Cyber Security” . Apparently, Juniper demonstrated the integration of vSRX with K2 solution in March 2021 . I could not find any technical documentation on the K2 website either. However, K2 has some whitepapers, webinars and videos. For most of this material, they require you to register. But the short introduction videos are accessible without any obstacles.
I registered for the 30 day trial on the K2 website and got access after a few days and emails. I got an account on the web-based manager application from K2. There I also found install instructions. I opted for the “VM/Node” variant that requires Docker to run the agent in a container.
To try it, I installed an Ubuntu VM. Initially I wanted to try the K2 agent with NextCloud, that I installed via snap in the Ubuntu VM. Since I couldn’t figure out how the K2 agent installer works with a snap based installation, so I changed my plan and installed the PHP based application Baikal  with nginx and php-fpm. The “PHP language agent” then changes the php.ini to include extensions from K2. After this, the K2 agent sends telemetry data to the cloud-based K2 manager. There it is now visible that the process “/usr/sbin/php-fpm7.4” is protected.
Besides PHP there are language-specific agents available for Java, Node.js and Ruby. As mentioned earlier, I was surprised to not see agents for popular languages like Python or Go. But I was told more programming languages will be supported soon.
I did not particularly like the installer script. I would have prefered proper documentation explaining that the K2 PHP extension needs to be loaded and how it communicates with the agent that runs in the Docker container. With that, it should also be possible to protect the snap based NextCloud installation.
With the knowledge, I would not recommend the product because of two nontechnical reasons:
- The technical documentation is very sparse on K2’s website and I could not find it on juniper.net. (Checked end of August 2021).
- The terms and conditions of the free trial program prohibit testing or reverse-engineering the product to find limitations or vulnerabilities (screenshot retrieved on August 13.)
The last point is the exact opposite of a bug bounty program and not appropriate for security software. In addition, I want to know the performance impact it has on my application. To find these performance limitations I need to do proper and thorough testing.
I hope that these issues dissolve since the problem space K2 addresses are very interesting and many applications could profit from its protection.
There are two other thoughts I have in mind about this:
- If Juniper is convinced that this product is good, then why did they not buy K2?
- Why did Juniper not find a better name than “Cloud Workload Protection”. It feels really bulky and does not flow well in conversations. But that is just a question of personal taste.
I guess only time will tell.