Four vulnerabilities closed on a platform that runs real heating systems.
A scan had found four vulnerabilities on the platform a geothermal company uses to monitor its customers' systems. The request was to move to PHP 8.4. We showed why that was not possible and closed the vulnerabilities another way, without touching the application logic.
A group that designs and installs geothermal and HVAC systems monitors its customers' installations with a web platform built on CakePHP 2.9.5. We had to close three PHP CVEs and one jQuery CVE on a tight time and budget. We verified that the framework cannot run on PHP 8, moved the site to the latest PHP 7.4 by fixing the handler that actually served the domain, updated jQuery in the views and proposed a real migration as a separate project.
Context
The group designs and installs geothermal and HVAC systems, and follows its customers' installations through a web platform: thermostats, heat pumps, ventilation, energy metering, heating and hot water schedules, alarms and charts, with Google Home and Alexa integrations. We also run the group's AWS account, websites and email.
The problem
A scan had flagged CVE-2022-37454, CVE-2022-31629 and CVE-2017-8923 in PHP and CVE-2020-11022 in jQuery. The application is built on CakePHP 2.9.5, a framework frozen for years, and the initial request was to move it to PHP 8.4. Time and budget were tight, and a mistake on a system that talks to heating plants has physical consequences.
What we did
- 01
Find out what really runs
We analysed the code from a full server backup: CakePHP 2.9.5, MySQL, jQuery, Bootstrap, amCharts, a custom OAuth2 server and VPN provisioning for the plants. The backup also held credentials in clear text, which we flagged as the first thing to rotate.
- 02
PHP 8 was not the answer
Run over 425 files, the PHP 8.3 compiler failed on 13 framework files: words that became reserved, removed syntax and removed functions. CakePHP 2 does not start on PHP 8. We put the result in a report and closed the three PHP CVEs with PHP 7.4.33, the last release of the series, without touching the application code.
- 03
The version that serves the pages
From the command line the server already reported PHP 7.4.33, but the HTTP response header said 7.2.34: the domain was served by a different PHP-FPM handler. We fixed the handler in the control panel and checked again on the site's response, not on the server.
- 04
jQuery in seven views
The pages loaded jQuery 3.4.1 through CakePHP's helper, which adds the file extension by itself. We updated the references to jQuery 3.7.1 in seven views, from the main layout to the sign-in and password recovery pages.
- 05
A plan for later
We proposed a time-boxed mitigation, with a web application firewall and hardening, and a migration to a maintained framework as a separate project. The main controller has 5,357 lines, 58 hand-written SQL queries and 21 near-identical chart methods: that is where to start.
How it went
The four CVEs are closed and the platform works as before. The client received a formal closure limited to the work done, and the group the technical report it needs to decide when to tackle the migration.
Tools
FAQ
Can a CakePHP 2 application move to PHP 8?
Not without a rewrite: the framework does not support PHP 8 and some of its files do not compile. The quick route is the latest PHP 7.4 with mitigations; the lasting one is a migration to a maintained framework.
Why check the PHP version from the HTTP header?
Because several PHP versions often live on the same server: the command-line one is not necessarily the one serving the site.
Is PHP 7.4 safe?
It closes these four CVEs, but it is out of support: every new vulnerability has to be mitigated by hand. That is why we treat it as a temporary solution, not an end point.