Exposed pfSense - Yet Another Management Interface Examined
Earlier on, I wrote about management interfaces and how they actually represent big, fat attack surface if exposed to the whole Internet. In general, this topic has gotten very little exposure in the media, where people tend to focus on the vulnerability-of-the-day and move on. Very little attention is paid to the fact that a given vulnerability would not be directly exploitable, if the interface was not exposed to the Internet in the first place.
Put plain and simple, focusing on the symptom (vulnerability) instead of the exposure (root cause) is shortsighted.
pfSense Web UI, a Management Interface written in PHP
This time I will turn a critical eye towards pfSense and its web-based management interfaces by default listening to TCP/8443. The interface is written in PHP, which as a programming language requires quite a lot from the developers. In other words, writing secure code in PHP is not easy and the vulnerabilities below exemplify this claim.
Why I decided to focus on pfSense is the fact that in December 2023, three new vulnerabilities affecting its Web UI were published. The vulnerabilities themselves are nothing spectacular, namely two of them are cross-site-scripting vulnerabilities (CVE-2023-42325, CVE-42327) exposing the interface to client side attacks against the administrators and one of them (CVE-2023-42326) is a remote code execution vulnerability affecting logged in users. Chained together these vulnerabilities represent a significant risk, since the XSS can be used to gain a foothold and the RCE to compromise the whole system.
Of course the vulnerabilities have to be patched, since the attack scenario above is likely to succeed even if the management interface is not directly exposed to the Internet. Not exposing it, however, is just good common sense and will raise the bar for the attacker quite a bit.
After all, you do not want to be amongst the first exploited, whenever a new set of vulnerabilities for a given management interface emerge. The map above paints a vivid picture of the scope of the problem and is just one example of many. Approximately 86 thousand firewall owners have not received the memo and happily operate their firewalls with the management interface up for grabs – for the teenager in a basement or the ransomware operator intent on causing harm.
Being on the map above paints a target on your forehead.
No Sensible Defaults is Part of the Problem
As I have asserted earlier, the economy of scale dictates that easy-to-use management interfaces are a must for complex applications such as firewalls. At a glance, these interfaces bundle together a set of functions to lower the barrier to entry in making use its business functions. For the power user, a REST API might be a better way to operate the appliance, but I would contend that the problem we see on the Internet is not caused by the power users.
Configurability and access to the bigger picture in terms of Key Performance Indicators, KPI, are features which any application user wants to have and replicating them over an API are beyond most users’ abilities. That is why dashboards are a feature which must not be overlooked.
The crux of the problem, however, is that the developers of these applications make it too easy to do the wrong thing. Instead, they should enforce defaults, which make it difficult to expose these interfaces to the Internet. A firewall device after all is likely to have more than one network interface, so why does the management function need to be exposed on the Internet interface by default?
You Cannot Patch Human Laziness
As I stated in the previous post on end-of-life-components, human laziness plays a large role in this equation. Having to set up a separate management network or an SSH bastion host, through which the management connections are made seems to be too much for many a sysadmin. Getting hacked may help the individual to realize this, but as a recent study shows, trauma isn’t necessarily conducive to the organization learning a better security culture. Once the incident has been handled and the media attention has subsided, the organizations tend to carry on as before.
The Quest Continues
Let’s face it, public exposure is one of the most systemic problems on the Internet. Even if for this write-up, I used publicly exposed pfSense management interfaces as an example, the actual problem is pervasive and revolves around the trichotomy of people, processes and technology. More often than not technology is not the problem.
If people and organizations see cyber security as a compliance issue rather than something that each user does every day, very few things actually improve in practice. I mean good security practices do not need to overcomplicate things even if they require a bit more effort on the users’ part.
For example, using an SSH jump host to tunnel through to the management interface isn’t rocket science. It does require a bit of expert knowledge, but no great investments need to be made to improve the overall security of the environment.
Often, the problem seems to be that organizations are willing to invest into technology but not the people who use it. This often leads to a situation where even the best technological solution is poorly maintained and the invention turns against its master. In my experience, outsourcing the maintenance to an uninterested third party seems to be a good recipe for disaster.
Be as it may, my quest to point out systemic failure of the Internet continues. Shedding light on exposed management interfaces, such the one pfSense ships with is what motivates me and my small team of researchers.
Give Us Feedback or Subscribe to Our Newsletter
If this post pushed your buttons one way or another, then please give us some feedback below. The easiest way to make sure that you will not miss a post is to subscribe to our monthly newsletter. We will not spam you with frivolous marketing messages either, nor share your contact details with nefarious marketing people.