Оффлайн
- Регистрация
- 1 Мар 2015
- Сообщения
- 1,481
- Баллы
- 155
If a system (whether it’s a firewall, SaaS app, or database) is only supposed to work once someone has proven they’re entitled to access it (in technical terms: authenticated and authorized), why are they built today with the power to operate before that critical step?
Most systems today are built with this inherent contradiction. It means the system itself has the authority to make decisions about access without needing to verify who is asking, leaving it exposed when that authority is tricked or bypassed. This isn’t a small oversight - it’s a fundamental design flaw.
Fortinet’s latest zero-day vulnerability () is a fresh reminder of this problem. When a product has god-like access to the sensitive data or abilities it holds, without itself needing external permission, a single exploit can give attackers that level of access. This isn’t a problem that can be fixed by just “patching faster.” It requires a fundamental rethink of how these systems handle authority to begin with.
The problem we keep bandaging over
Every year, we see the same kinds of vulnerabilities hit the headlines. Last November, researchers discovered a in FortiOS/FortiProxy that allowed attackers to slip straight into the management GUI without presenting a single credential. The patch landed in January 2025 — after the damage was already done. Just this month, another vulnerability () was found that allowed a particular legitimate mode to skip authentication altogether and log in as an admin.
These aren’t isolated incidents, and it’s not limited to Fortinet.
A history of band-aids
While each entry point or exploit is different, they all take advantage of the same fundamental flaw: once you’re inside the box, you’ve got everything you need to cause damage.
Feel free to skip the boring stuff, but here’s a sample of Fortinet’s history of these “login-optional” bugs:
This design approach breaks two fundamental security principles we claim to live by:
Yet, in practice, we keep building systems with total, unverified power because “that’s how it’s always worked.”
A better model
Instead of designing systems as all-knowing, all-powerful gatekeepers that poorly dispense the explicit access they have over sensitive data, what if the systems themselves lacked that god-like access entirely? What if only through the act of a user successfully authenticating could the system gain the authority to access sensitive data or operations?
It’s like a circuit that only completes when a user logs in. Without that signal, the system can store data, but it can’t act on it. Once the user session is gone, so too is the system’s ability to operate. If the code inside the system is tricked or compromised, the authority over sensitive data is nowhere to be found.
This act of “” keeps an indispensable piece outside the blast-radius, and only lends it when the user authentically connects.
Moving from “access control” to “authority control”
A way forward
The next patch will come, and another critical vulnerability will follow. To break the cycle, we need to change the way these systems are built, so they literally cannot grant themselves access until someone authenticates. Shift from “access control” to “authority control.” If we do that, there’s nothing stopping us from moving fast because the inevitable breach leaves nothing for an attacker to find.
Original post -
Most systems today are built with this inherent contradiction. It means the system itself has the authority to make decisions about access without needing to verify who is asking, leaving it exposed when that authority is tricked or bypassed. This isn’t a small oversight - it’s a fundamental design flaw.
Fortinet’s latest zero-day vulnerability () is a fresh reminder of this problem. When a product has god-like access to the sensitive data or abilities it holds, without itself needing external permission, a single exploit can give attackers that level of access. This isn’t a problem that can be fixed by just “patching faster.” It requires a fundamental rethink of how these systems handle authority to begin with.
The problem we keep bandaging over
Every year, we see the same kinds of vulnerabilities hit the headlines. Last November, researchers discovered a in FortiOS/FortiProxy that allowed attackers to slip straight into the management GUI without presenting a single credential. The patch landed in January 2025 — after the damage was already done. Just this month, another vulnerability () was found that allowed a particular legitimate mode to skip authentication altogether and log in as an admin.
These aren’t isolated incidents, and it’s not limited to Fortinet.
A history of band-aids
While each entry point or exploit is different, they all take advantage of the same fundamental flaw: once you’re inside the box, you’ve got everything you need to cause damage.
Feel free to skip the boring stuff, but here’s a sample of Fortinet’s history of these “login-optional” bugs:
- 2024–21762 — SSL-VPN out-of-bounds write lets attackers run code pre-auth
- 2023–27997 (“XORtigate”) — Heap overflow, again pre-auth on SSL-VPN
- 2022–40684 — Bypass the admin API, create your own super-admin
- 2020–12812 — Change username case to dodge FortiToken 2FA
- 2018–13379 — Path-traversal that leaks raw VPN session files and passwords
This design approach breaks two fundamental security principles we claim to live by:
- : “No asset is implicitly trusted” (NIST SP 800–207)
- : Every component should get only the power it absolutely needs
Yet, in practice, we keep building systems with total, unverified power because “that’s how it’s always worked.”
A better model
Instead of designing systems as all-knowing, all-powerful gatekeepers that poorly dispense the explicit access they have over sensitive data, what if the systems themselves lacked that god-like access entirely? What if only through the act of a user successfully authenticating could the system gain the authority to access sensitive data or operations?
It’s like a circuit that only completes when a user logs in. Without that signal, the system can store data, but it can’t act on it. Once the user session is gone, so too is the system’s ability to operate. If the code inside the system is tricked or compromised, the authority over sensitive data is nowhere to be found.
This act of “” keeps an indispensable piece outside the blast-radius, and only lends it when the user authentically connects.
Moving from “access control” to “authority control”
A way forward
The next patch will come, and another critical vulnerability will follow. To break the cycle, we need to change the way these systems are built, so they literally cannot grant themselves access until someone authenticates. Shift from “access control” to “authority control.” If we do that, there’s nothing stopping us from moving fast because the inevitable breach leaves nothing for an attacker to find.
Original post -