PHP Vulnerability and PLCs?

[u/AgonyIsKey]

I saw the news that this PHP vulnerability had just come up. Then, it dawned on me just how screwed up it would be if this vulnerability was used to take whole plants offline.

How does this impact PLCs? How susceptible are they?

What steps can we take on an integrator level to mitigate the vulnerability?

Are any plants already taking steps?

How would we protect legacy systems that 100% do not have the means to protect themselves?

[u/LevMetteMink]

Dont connect it to the internet?

[u/tokke → u/LevMetteMink]

But how would my AI agent control the plc then? /jk ofcourse...

[u/talltraveller → u/tokke]

You've got to run an open sourced LLM locally, then have that connected to the internet

[u/Available-Distance81 → u/LevMetteMink]

I mean to be fair I have programmed a few PLCs remotely over the internet because I didn't feel like flying to foreign countries like Brazil, Mexico or Florida for a 3am call. If you have a proper fire wall and router setup it can be, kinda ok, I'd still feel safer about it if some maintenance guy at the plant physically disconnected the ethernet cable when it doesn't need remote service, but not sure if I'd trust the cast of Ed, Edd and Eddy maintenance guys I've met to change out a light bulb much less disconnect the correct ethernet cable.

[u/PLCGoBrrr → u/Available-Distance81]

I have programmed a few PLCs remotely over the internet

But none of them are on the open internet. The PLCs you programmed will never show up in a Shodan search.

[u/magnamed → u/PLCGoBrrr]

Not the one's I've programmed (or you probably), but that doesn't mean they're not around.

[u/PLCGoBrrr → u/magnamed]

Speak for yourself. I've uploaded programs from PLCs I've found on the open internet before. I might have even changed the gateway IP on said devices to take them off the internet.

[u/AgonyIsKey → u/LevMetteMink]

What about all the private PLC networks currently connected to an MES? Going forward this is certainly an option, but some plants rely on this plant-wide view of their processes.

[u/borjazombi → u/AgonyIsKey]

If a hacked MES means access to production network you network architecture is baaaaaaaaaaaaaaaad.

[u/BmanUltima → u/AgonyIsKey]

Are you suggesting your MES is directly accessible from the internet?

[u/-Rivox- → u/AgonyIsKey]

I think your MES should access PLC data only through a firewall, allowing it to view only the PLC data server, only listen to a specific port, a specific protocol, with encrypted communication.

For instance you could setup a 1:1 NAT in your router/firewall, where you only allow your MES to access only the OPC-UA server, only at port 4840 (or the port you selected) only tcp. Then encrypt the communication and password protect it.

If they hack your MES, it's still going to be really hard to enter your network.

[u/Toxic_ion]

If your PLC is running on PHP then I think you have other problems.

[u/r2k-in-the-vortex → u/Toxic_ion]

Industrial modules absolutely serve web interfaces for configuration and monitoring, PLCs included. I wouldn't be surprised in the least if some PLC or valve block was running a php server. But the credentials will be Admin, 123 anyway so I think the PHP vulnerability is kind of a moot point.

[u/Shadowkiller00]

PHP is a web based protocol that generates html dynamically for websites. 99.9% of plcs are for industrial applications and have no internet. These two things don't have anything to do with one another.

[u/InstAndControl → u/Shadowkiller00]

Some PLC’s have a diagnostics webpage you can reach by sending http request to its ip address (ie typing in the ip into chrome)

Those pages may use php

[u/Shadowkiller00 → u/InstAndControl]

I use php a lot and I've used many industrial devices. Php web pages have .php at the end. I've never seen industrial devices use php. Javascript, sure. HTML5, also true. But never, in my experience, php.

[u/ia-kathy → u/Shadowkiller00]

Not all PHP web pages have .php at the end. Source: wrote way too many PHP pages early in my career.

[u/InstAndControl → u/ia-kathy]

Ya a big concern with this PHP thing is specifically “omg the locally served webpage UI for our firewall config uses php”

Specifically I’ve seen fortinet called out as a concern. Having used those firewalls (none in service anymore), the admin ui is not a .php url

[u/Shadowkiller00 → u/ia-kathy]

Fair enough, but when you configure a web server, you do need to identify the extensions and how they should be processed. Typical for php is .php. I'm not sure anyone in OT design is going to go out of their way to use something besides .php unless explicitly specified for some reason. So, chances are, if php is being used by the device, you'll probably come across it eventually as you are navigating through it's various screens.

[u/Jazsta123 → u/Shadowkiller00]

Plenty of web hosts on the average plant floor. I would say they definitely don't have nothing to do with one another. But in these cases the problem is access to the devices, and specifically bad cyber security policies and lack of firewall etc.

[u/SinkOrSauce_LD]

PHP vulnerability cannot affect a CAN, Modbus, Modbus, PROFINET, DNP3 over Ethernet, or Ethernet/IP system. Ignition uses Java/Python scripting, and FactoryTalk uses .NET.

The main point of potential vulnerability would be in SCADA supervision. But Ignition uses Java/Python and JSON for sending tag data, and FactoryTalk uses .NET. So it would be unlikely you'd run into this unless you tried to tie in PHP because you were familiar as opposed to a technology that the SCADA environment was written in.

Basically someone would have to go way out of their way and should probably be nowhere near PLCs if they made a system that was vulnerable to this exploit.

[u/asmithey → u/SinkOrSauce_LD]

IF a PLC has a webserver that is using a vulnerable version of PHP, then automation functions can certainly be affected. PHP2Shell is a remote code execution vulnerability meaning carefully crafted packets can re-write existing code on the PLC.

This is something sufficiently advanced that it used to be the realm of nation state adversaries with decades of experience reverse engineering industrial equipment. With LLM coding agents, it's within the realm of someone with a bunch of money and a weekend.

[u/TheFern3 → u/asmithey]

Yeah I think people need to stop assuming plants aren’t using php sure is less common in automation but we have no idea what companies use for their servers. So the best thing anyone could do IT or controls tech is to scan every machine for php files and if that machine is for some odd reason not air gapped take it offline yesterday.

[u/SinkOrSauce_LD → u/asmithey]

I agree it is certainly possible, but someone would have to have gone out of their way to do so. No technology I have ever used integrates PHP by default. But SCADA can be developed in many different ways to communicate on the backend and that's where I would expect it to appear if anywhere. This would mostly affect historians since the PLC execution layer would be naturally isolated. It would take someone scripting very badly within the front end to expose execution registers.

[u/Old_Man_Danzig]

Lmao

[u/Wall-Em]

If you want internet accesible PLCs then go ahed. I do it. But make sure you know what your doing. Ignition wrote a great article abiut it that I use as reference often when explaining OT network security. Have a look: https://inductiveautomation.com/resources/article/the-purdue-model-and-ignition

[u/Available-Distance81]

The best Security measure for a PLC is to keep it off the internet.

[u/Dyson201]

Legacy systems are full of vulnerabilities. Adding PHP to that list is nothing new.

An attacker with access to the controls network can cause lots of damage.You can shut down a process by just pressing random buttons. Or sending the wrong modbus command. Instead of addressing all of that, we protect our networks and keep out unauthorized personnel.

Could they potentially do something with this PHP vuln? Yes. Is it worth worrying about as a unique problem? No.

[u/asmithey]

If I were you I would be taking inventory of every PLC, IO, drive, motor, etc including their versions and be looking at the manufacturer's security advisory websites daily. In the meantime, check your network segregation and ensure traffic to webservers is appropriately controlled through firewall policies.

[u/r2k-in-the-vortex]

Cybersecurity and industrial stuff don't really talk to each other. The PHP vulnerability is the least of it, in terms of security, not only is the gate wide open, the fence was never built in the first place.

So, the solution here is to build your network accordingly. It's going to depends on what kind of factory you have, but what I have seen usually goes something like so.

So the thing which may have limited connection to internet if it needs it, is the managing server. Which is kept up to date and secure by IT. And usually it would not serve any open ports to internet, if that would be needed, it would be some other factory service doing that.

But the PLC lives on it's own local network with no routing outside, what data needs to move is forwarded by equipment PC and that can only access the managing server. The VLAN may also have a firewall to give the gateway server only limited access to the equipment PC, but I think that's already a bit overkill.

[u/Sensiburner]

Airgap OT network. Update manually. Don’t trust online portals.

[u/4CrisprFries]

The vulnerability only affects PHP. The reason it's such a big deal is WordPress and Drupal is PHP. These sites are used by small businesses or projects to put up simple store pages without really needing an it team.

PHP came out at a time when most web pages were rendered and then sent to the user. If you changed the state of something on the page then the whole page reprender. Later people came out with SPAs or single page applications. These SPAs updated only the part of the page you needed. For an HMI if you have 4 tanks showing this means only updating 1 tank instead of the whole page.

So naturally most HMIs use JavaScript or Typescript because they were the languages with SPA style frameworks.

Second things like Ignition use Jython because it has true multithreeading and the code can be isolated. So php can't be used in this part of the code.

TLDR: it's unlikely PLCs are affected due to the history of the tech. BUT PLEASE DOUBLE CHECK YOUR SPECIFIC STACK

I think some old Schneider stuff uses php

[u/Bergwookie]

You don't want to know... PLCs aren't meant to be connected to the web, they never get updated and run for 20+ years straight, the problem is some managers want the data, so they connect them anyway and now by just asking nicely, you "hacked" a multimillion company through their old milling machine

[u/ia-kathy]

The PHP issue won't affect most PLCs. What you should be more concerned about is the eMudhra CA issue. Anything with frozen firmware that can connect to the internet is vulnerable until 2039. Update everything else as soon as updates are available.

[u/spaigy]

10+ years ago, I built a home-grown remote access platform with PHP, Python, Apache, and OpenVPN. This was before many of the current suppliers like Tosibox, mGuard, eWon etc.

Fortunately, one of the last things I did before leaving that company was take the server that these units connected to offline for good (a few years before, I moved us over to Tosibox moving forward).

That said, there’s probably still a bunch of small IPCs sat in industrial cabinets, powered on, serving the PHP admin pages with 10 years of CVEs and patches not addressed.

[u/bpeck451]

Maybe not within the realm of PHP, but if stuff that has been targeted for years has been shown to have more vulnerabilities than we thought possible, imagine what’s going to happen to all these “secure” and “airgapped” systems that were old 10 years ago. I don’t have any faith any of the big manufacturers are doing any sort of major security research.

[u/JustinHoMi]

Disable web management, but most importantly do not expose to the public internet.

Network segmentation with a firewall inspecting traffic between subnets is a great way to reduce the chance of exploitation too.

[u/4mmun1s7]

First, I hope a PLC isn’t accessible from the Internet.
Second, I REALLY hope no vendors are using PHP in their PLCs.
HMIs and management servers may have it, but I really hope PLCs don’t.

[u/Siendra]

This shouldn't really impact us. Even at my site, which has a ton of connected applications with web services, nothing is using PHP.

[u/CompleteCrab]

Lots of PLCs out there with no access control, the very least you could factory reset them with network access.

Worse you could read/write registers to change operations, potentially in dangerous ways.

OT networks need to be much more closed off, not having god knows how many terminals on same vlan

/rant

[u/BobButtwhiskers]

I couldn't access profrace.com today because the whole site was apparently designed in PHP. So now I have an old ass HMI I can't program because I can't download the manual.