They had to work pretty hard
To patch one problem only to make themselves even more vulnerable. Wow.
Rapid 7 security man Todd Beardsley says new firmware released to patch hardcoded SSH keys in Advantech EKI industrial control system gateways contains known brutal flaws including Shellshock, Heartbleed, and buffer overflows. A module for the Metasploit hacking box has been published to help attackers hose the zero day holes …
Trying to "stay secure" sounds a lot like trying to climb an untied rope in free-fall faster than it's falling to avoid hitting the ground; ie. a nice ideal but an oxymoron nonetheless. Granted, the sort of shenanigans described in the article doesn't help at all - but even in its absence, even the best security will only get you from "ludicrously unprotected" to "merely vulnerable". Even if you religiously apply every new patch as soon as it comes out, you're perpetually open to attack from anyone interested enough in the time-frame between the discovery of the latest hole and the release of a fix for it. Strict patching and doing nothing both work best if no-one is actually trying to get in; once someone wants to, _both_ are a game of Russian Roulette, the only difference is the number of bullets in play. Patching - a smart thing to do, just don't expect it to change anything whatsoever...
patching one vulnerability to only open yourself up to several well known ones is akin to locking your upstairs window, but leaving the front door wide open and a pile of cash sitting on the floor.
You must have to employ some weapons grade idiots to create and deploy something that bad.
The scenario running through my head is that the PHB was berating the staff, "Why is this taking so long? I could do it faster myself!", and someone said, "Go Ahead, show us oh wise leader", in a voice dripping with sarcasm.
Unfortunately, PHBs never recognise sarcasm, so he belted this mess out, and ordered, "Ship it!"
That is what makes the CyberIntelAIgent Defence Systems Enterprise such a Root Hoot to Boot, Mentor and Monitor, DropBear. Security is not needed whenever Sub-Prime is not an Element or Component in Projects and Programs.
Lipstick on a Pig of a System is a waste of Lipstick and changes not the Pig of a System.
While I offer no evidence to counter the "bunch of muppets" hypothesis, I would point out that it is pretty easy for something like this to happen. They obviously did not build the update with a library that had itself been updated. Either by forgetting that part, or by company policy against changing things (said library) that are not part of the "mission". Being careful about accepting updates is actually part of pro-active security.
Yes, they should have been more careful, but if you have never been bitten by a bug introduced by an update to a third-party library, then either you are very lucky or you haven't actually done this much.