But as I stated above they don't need to. The systems doesn't need to be connected to the net to be vulnerable. You don't need to get all the way there, and you don't even need to be there yourself as some mission impossible spy. you just need to get the worm 90% of the way there and some guy doing system upgrades with all the right clearance will do the work for you when he plugs in that USB stick he's carrying around system updates on.
Most embedded systems are safe from this kind of attack because they can't be updated by USB or from just running a command on a network. The majority of the older and current embedded gear makes use of physical connectors on the hardware to perform the updates. The connectors to update embedded hardware use connections like JTAG which means you need physical access to the hardware , the correct programming adapters, and a laptop with the correct software running. The other popular way to do more modern embedded hardware updates is to use a bootloader.
A bootloader is a small piece of code that resides at the very beginning of the firmware. On start-up the mcu will run the bootloader code before doing anything else, it then will wait for a specific command and if it doesn't receive it in say , 5 seconds, it will proceed to load the main firmware. The bootloader code itself can be set so it has to be done locally with the JTAG unit so someone can't just replace your code nor can they download your code while the main firmware is running. The flash chips have hardware read and write protection that can be set to block any reading after the bootloader has loaded the main firmware.
To update the firmware, you reset the device, wait for the bootloader to load then send it the correct string to halt the firmware loading. In bootloader mode you then issue the commands to update the firmware. This is easy to protect too because all you have to do is set up the bootloader to only accept firmware with your unique key, these keys can be 256 bits in length.
To physically protect the chips the flash can also be set to be unreadable even if you physically remove the flash chip and place it in a flash chip programmer. The solutions to protecting embedded gear are already in place, the problem is engineers not using them . It comes back to the same thing as normal pc security. If engineers are not going to enable security features, are going to leave passwords at defaults, then nothing can protect devices.
A good example of security done right is directTV. Directv had trouble from the time they started offering service with people pirating tv channels. Their solution was to use smart cards, basically small computer chips on a plastic card that would hold the users information and whether they could watch a channel. Hackers quickly overcame each revision of the cards. For years the company struggled to block them out until they finally hit on the solution, don't use off the shelf software and hardware, create your own in house.
Now they had a truly difficult product to hack because there was no public documentation of the methods used and security was tightened from allowing anyone at a manufacturing plant to gain information to just allowing those who need to know. It has been several years since Directv switched over to this practice and nobody has cracked it yet. The market for pirate cards or boxes is in the millions of dollars and people have poured hundreds of thousands into reverse engineering the protocols and hardware yet it remains secure.