The two sides of the same coin.
In this new series of posts we want to shed light once again on the very core of software security fundamentals: security mechanisms operate on different stages. The stage at which they operate makes the difference. Once a bug yields a reliable exploitation primitive then the attacker fully controls the execution environment - the actual impact on the system depends on the privilege domain at which the attacker operates.
💡 Photon's security posture design is flexible enough to react before the triggering operation reaches the vulnerable code and to provide an AI-driven post-exploitation approach when trigger-level prevention is impractical.
It is important to distinguish the core difference between exploiting the bug (so-called triggering the vulnerability stage) and achieving privilege escalation (post-exploitation stage). The practical distinction is fundamental to the effectiveness of the security mechanism: stopping the exploit chain in the post-exploitation stage does not prevent the bug from being exploited but it is effective in minimizing the damage to the system.
The following image might help in clarifying the different stages:
The exploitation stage requires interacting with the target through the specific sequence of actions that directly trigger the vulnerability. The post-exploitation stage, in contrast, leverages the exploitation primitives (i.e., arbitrary r/w, auth bypass, etc…) obtained from the bug to achieve any privileged action (priv escalation, command execution, file tampering, etc.).
Every exploit crosses the exploitation / post-exploitation critical border: the moment a corrupted state hands the attacker a reliable primitive and the target becomes a weird machine executing the attacker's operations. This raises a critical question for runtime security solutions: is it always possible to stand in the right place to prevent attacks from happening? That is our main goal in order to deliver effective runtime security across our customer base.
Where Photon Stands
Exein's Photon guarantees stand in kernel-land by means of LSM eBPF custom programs. It is naturally designed to react before the vulnerable code is reached. Nevertheless, there are vulnerabilities that cannot be fully prevented such as bugs with little to no relevant kernel interaction (i.e., command injection, authentication bypass, int overflow, etc…). For all those situations Photon's post-exploitation defense mechanism is in-place to detect and minimize damage to the system.
For the sake of understanding, in the next posts of the series we will provide two examples on different vulnerability scenarios: one Linux Kernel bug where Photon's runtime protection acts at the root of the issue, by fully preventing the vulnerability from being exploited; and another user-space bug where Photon's AI-driven solution detects and reacts to post-exploitation operations. STAY TUNED!
Conclusion
Software security fundamentals are built on top of different layers and security solutions react to different stages of the attack. In this first episode of the series we defined the fundamental base on top of which Photon's security runtime solution operates on to guarantee the most advanced level of protection at different stages: exploitation and post-exploitation.
For kernel-level runtime enforcement on your own hardware, or a firmware analyzer scan contact the Exein team for a demo.
Author
The Exein Tech Team
