Tech Review tl;dr- A walkthrough of CVEs-2023–44049 to 44052

Edward Farrell

Yesterday Mercury released its Report on Internet 2.0s Internet Cloaking firewall. It was my intention back in August was to evaluate this product as part of a trial run of our research, test and evaluation capabilities (ideally vulnerability research). As it became apparent the product was largely based on existing components, understanding the risks associated with product implementation became our focus.

I wanted to do a few short write ups in coming weeks to provide a distilled, digestable edition of what we found and why its relevant. Sometimes the subtleties of discoveries can be a little hard to make out, so I figured a more informal approach to explanation may assist.

So what is a CVE?

CVE stands for Common Vulnerabilities and Exposures. The intent of the CVE Program is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities to aid in disclosure and dissemination.

An overview of what we found

When we analysed the Azure offering of the Cloaking Firewall, it became apparent that the system was missing patches on two software components and did not appear to be in a state where it could be updated. This included:

1. CVE-2023–44051: The way pfSense Plus has been instantiated is such that it cannot be patched. As the Azure instance is using v21.05.2 (out of date by 2 years) and has itself known vulnerabilities, even at the time of its release to Azure. This product does not appear as if it can be updated.
2. CVE-2023–44052: Suricata isn’t patched. This isn’t an immediate risk, but if specific changes are made to the system this could facilitate remote code execution.

The other area of concern we raised was around hardening. The product itself is hardened in such a way its actually difficult for a user to individually maintain, however an offline copy did reveal credentials that, if unchanged, could facilitate unauthorised access. This included:

1. CVE-2023–44050: root and admin passwords are both the same and appear to be enabled. Given our observations on hardening and a lack of guidance, there is every chance one of these systems could be sitting there with the same default password remaining in place.
2. CVE-2023–44049: this one was a bit of a tricky one to even deduct, but the SSH public keys remaining in place and associated with a user no longer at the organisation is problematic. It indicates key management has not taken place and other artefacts have not been cleared off. If the user still has their private key, there is a risk they can gain access to these systems. Thankfully this issue was not present in the AWS instance.

If you want a bit more information, feel free to access our PDF report available here: https://mercuryiss.com.au/report/internet-cloaking-firewall-report/