Doubtless, large swathes of this story are covered by blankets of classification; it’s one of the governments’ best tools for hiding incompetence. Because – not to mince words – the only way this thing could have happened is massive incompetence.
The Army may have festooned its Stryker fighting vehicles with a slew of new armaments as part of the Pentagon’s relentless pursuit of lethality, but the upgunned infantry carriers are apparently hobbled by a major deficiency that makes them especially vulnerable in a fight against Russia or China.
The Stryker Infantry Carrier Vehicle – Dragoons that are currently flexing their muscles with the 2nd Cavalry Regiment in eastern Europe remain vulnerable to cyber attacks, so far that “adversaries demonstrated the ability to degrade select capabilities of the ICV-D when operating in contested cyber environment,” according to the Pentagon’s operational testing and evaluation report released last month.
Even worse, the report notes that “the exploited vulnerabilities predate the integration of the lethality upgrades,” suggesting that the the Army spent too much time slapping new weapons systems like Stryker ICV-D’s 30mm autocannon onto the new vehicles and not enough time fixing a major design flaw.
“Major design flaw” and “30mm autocannon” are not words that go together well, my Michelle.
What’s probably going on here is that some energetic folks in the Stryker program realized they needed a computer system and a network for some purpose, and got the job done using some Linux distro, or other. I’ll bet a dollar to a stack of donuts that whoever did that said (at the time) “we should eventually replace this with a production system” and someone else said, “no let’s put it in production now!” and someone else who did not like how that happened arranged for the final, integrated system, to get a good vulnerability scan, which revealed that the whole system was thrown together at the last minute. Normally, that kind of result gets classified but in this case someone made sure the story leaked and faces are getting egg on them.
I’ve seen this sort of thing before and it’s really depressing. Especially since a vulnerability scan presupposes you’re on the target’s network, which is basically presupposing “game over, man.” As the report implies: if the underlying network is being degraded, the services that run atop it will, too. That’s something that needs to be thought about at design-time, not once it’s too late and the systems are deployed. Because it’s always more expensive and time-consuming to try to repair something that was built wrong than it is to avoid building it wrong in the first place.
Operation “Throw Money At The Problem” [the drive]
The U.S. Army has hired a company to develop a prototype cybersecurity kit for its Stryker family of 8×8 wheeled armored vehicles. This comes more than a year after it first emerged that unspecified “adversaries” had successfully launched cyber attacks on up-gunned XM1296 Stryker Dragoon variants, which The War Zonewas first to report.
Let me tell you: nothing is more fun than writing a prototype kit to solve an unspecified vulnerability against an unspecified adversary. Money is no object! In fact, it’s hard to tell what the object is.
I’m willing to bet that there’s important stuff that’s being ignored, and unimportant stuff that is being made important. Under the rubric of “unimportant stuff” I probably put 95%+ of the vulnerabilities that were found in the total system. The “important stuff” is executive-level questions like: “how did this system come into existence without network trust and vulnerabilities being considered and addressed?” Any cluster of systems that are going to share a battlefield network ought to come with a “Plan B” and documentation for how they can be re-organized into a private network when necessary. This is a design problem, not an implementation issue – it needs to be addressed before the implementation begins. For example, someone should have given a briefing explaining that the system has 2 modes of operation, one in which the network is reliable and the system trusts it for DHCP leases, ARP responses, DNS, and allows outbound traffic to ${virtual locations} and the other in which everything falls back to hardcoded addresses and routes and the cluster of systems can not communicate outside of the cluster. This is “101” level stuff for system administrators: you need to configure your automatic gun’s controller software so that it doesn’t suddenly complain that it needs to download a new version of node.js and now there are compatibility issues, please see error log to resolve them. This is the important stuff that cannot be ignored: if your gun has a computer in it, you now need a “system administrator” for your gun. In addition to the people whose job it is to polish it and fire it, someone has to keep that software stack up-to-date and compatible with other versions of it.
The important stuff, which is being ignored everywhere, is that computers come with a unique set of maintenance requirements that most other real-world things don’t. It’s highly unlikely that General Motors will push out a power train update that makes your vehicle’s transmission fail. But, if you release a software-fusion-driven system and don’t keep the software up to date, eventually some jackass at some cloud vendor will change a parameter in some API and suddenly the storage system that worked perfectly 5 minutes ago needs to have its software replaced, checked for function, re-tested, and certified. What, you mean there’s no process for that replacement, check, test, and certification? Then you’re not qualified to be using computers in that application – it’s that simple.
Put the jerricans of gas next to and above the sally port in the back, so if someone gets a couple shots into them, the troops in the back exit into a simulation of hell. Way to go, guys!
So the “important” question is “how did this shit happen in the first place?” which is basic sloppiness and incompetence, and executive-level non-comprehension of how disastrous software can be. Those are a serious strategic problem.
But what I really love here is that there’s someone willing to raise a hand and say “I’ll fix that unknown thing for an unknown amount of money, in an unknown way!” That’s consulting gold, right there: you may as well promise to write me a check every month as long as I’m alive.
On Nov. 16, 2020, Virginia-based cybersecurity firm Shift5, Inc. announced that it had received a $2.6 million contract from the Army’s Rapid Capabilities and Critical Technologies Office (RCCTO) to “provide unified cybersecurity prototype kits designed to help protect the operational technology of the Army’s Stryker combat vehicle platform.” The company says it first pitched its plan for these kits at RCCTO’s first-ever Innovation Day event in September 2019.
“Prototype kits” probably means “a bunch of iptables configuration scripts” and maybe configuring syslog correctly and grouping the relevant systems into a VPN using some static ipsec rules. If I’m doing a good enough job of reading between the lines, what I’m betting will happen is that a few firewall rules to drop traffic that’s not from the cluster of Strykers will mean dropping traffic from whatever system is doing the vulnerability scans; therefore the number of seen vulnerabilities will go from 1,289 (a made-up number) to 0. If whoever had set the system up in the first place hadn’t been conspicuously incompetent, that is what would have happened in the first place: if you have 10 machines in a cluster, you should have iptables rules that mean those 10 machines can talk to each other and everything else gets thrown on the floor like a democrat ballot in Georgia. (did someone yell “too soon”?) the fact that whoever set this thing up didn’t even think of that means that they were not qualified to set it up.
“Adversaries demonstrated the ability to degrade select capabilities of the ICV-D when operating in a contested cyber environment,” according to an annual report from the Pentagon’s Office of the Director of Operational Test and Evaluation, or DOT&E, covering activities during the 2018 Fiscal Year. “In most cases, the exploited vulnerabilities pre-date the integration of the lethality upgrades.”
Sounds like “You used a Linux distro from 2017 and no patches have been applied, so it’s got 12,389 vulnerabilities if you run a Nessus scan against it. But the real question is: why weren’t the system builders prepared for that? It’s the kind of problem they could have not had, at all, if they had spent 15 minutes of attention to detail.
Back when I first started getting into security, I identified that security has an interesting property that other software doesn’t have: it goes bad over time. With most software, your question is whether anything has broken compatibility (“will it still work?”) but with security, there are interdependencies with other software that can go bad, in different ways, on its own. In fact the whole security problem is a matter of maintaining a strategic configuration while the entire software market is oriented toward forcing you to upgrade. And you can see it works just great.
This is why I see things like Huawei as transients; sure Huawei gear may have some backdoors but who cares when developers are also grabbing Linux distros and authoring their very own operating system release that is undocumented and unknown. I doubt, for example, that the Stryker depends on node.js but, if it did, then that means that node.js has become a critical part of some software infrastructure and it needs to be maintained and managed as such. Back in 2002, I was suggesting that the US should define a critical software infrastructure as well as hardware infrastructure for certain applications (e.g.: energy control systems, you will use these options and nothing else) controlling what goes on and off that list gets you halfway to dealing with the Huawei challenge – but even that was too much to expect from the US defense industry. Go ahead, guys, and roll your operating system releases; it’s just one more thing that you can be bad at.
That’s reminiscent of the old Soviet APCs with back doors that ARE fuel tanks.
Formula 1 may have exorbitant budgets, but nowhere near the money the US military has, and yet they still have a better and affordable design for auxilliary fuel tanks.
Gasoline? No, that’s kombucha.
Putting the extra fuel on the back of the armored vehicle is the sensible thing. Like would you rather have it on the front? Also, it is pretty hard to light gasoline on fire by simply shooting at it, so there’s no real reason to think this stuff is bad design.
Think before you snark, basically.
Ketil Tveiten@#3:
Also, it is pretty hard to light gasoline on fire by simply shooting at it, so there’s no real reason to think this stuff is bad design.
What?! Since WW1 most machine-guns have a few incendiary/tracer rounds in the mix for exactly that sort of reason, and there are many many incidents where AFVs were destroyed by being lit on fire and the crew bailed out. The one M-1 Abrams lost in Iraq was lost because it was carrying fuel and some fedayeen saddam managed to light it up.
Yes, there’s every reason to think its bad design.
Like would you rather have it on the front?
No, you’d have it in a protected area in the vehicle, where it belongs, or in another vehicle that is designed to safely carry fuel. When you’ve got jerricans strapped on the exterior of a vehicle, it means you’ve got a logistical problem not a vehicle design problem.
Intransitive@#1:
Formula 1 may have exorbitant budgets, but nowhere near the money the US military has, and yet they still have a better and affordable design for auxilliary fuel tanks.
Yes!
OK, so I was stuck in England one morning, jet-lagged as hell, wide awake and watching TV because I couldn’t sleep and I had an interview that afternoon. There was a show on about Formula-1 tech, and it was mind-blowing. The design issues those guys are dealing with are of the same order as jet fighter aircraft, for the same reasons – in fact, I bet the only way you could make F-1 more complicated and cooler was if the cars also carried weapons systems and armor. But, I digress. One of the bits I will never forget is one of the designers from West/McLaren was talking about fuel bladders and said that they have basically the same design as an F-16s fuel tanks – when a car goes into a rapid back and forth curve, the fuel in the tanks is now doing – what – at very high speed. How do you reliably feed that into an engine? Interesting problem – I believe they have the fuel in a silicone/fiber bladder and the feed is done by pressurizing the tank housing so that the fuel rate is controlled by the air pressure and the valves.
I’m on my phone, so I can’t link you the Mythbusters episode where they try hard and fail to light up a gas tank with incendiary rounds, but I’m sure you can find it yourself.
Molotovs thrown at tanks in urban areas are a whole ‘nother thing of course. The problem there is idiots trying to fight irregulars inside cities using machines designed for fighting proper military stuff out in the non-city part of the world.
External fuel tanks on armor is pretty standard and not really considered insane; see for instance soviet T-whatevers (big drum on the back) or the Swedish S-tank (sides lines with jerrycans).
Also, carrying with you extra fuel isn’t a logistical problem, it solves a logistical problem. Every truck you rely on to stay fighting, is a logistical problem!
Maybe it’s a psychological thing. If you plaster the back of the vehicle with gasoline, your guys are motivated to keep facing the enemy. If they turn, they’re toast.
I mean, if the enemy is shooting at you from behind, you have much bigger problems than some fuel that might be on fire. The front is the most heavily armored part for many reasons.
With regards to Formula 1 vs fighter jets… I remember hearing some time ago that there had been work done on using airfoil designs to create a partial vacuum under the cars to help hold them to the ground during tight turns. It became a big thing for a short period of time, and everybody started looking into it because the first cars to do it were getting serious advantages.
Then it was discovered the hard way that this design had a catastrophic failure mode: if the car lifted up too much (say, because it ran over something on the track) and the air could rush into the partial vacuum faster than it could be removed, the sudden shift in pressure pretty much launched the car into the air, along with adding a spin based on whichever side was the most open to air coming in. Accidents in cars with this sort of design became a LOT less survivable: drivers don’t expect hitting a piece of debris from a previous car to put them into an end-over-end flip.
I believe there are rules against using ‘partial vacuum’ designs now, at least past a certain threshold.
Jerry cans on the back wouldn’t be there burning for long, the poly straps holding them on would melt in a instant then the jerries become someone else’s problem.
Marcus Ranum (#5) –
Continuing the topic of fire risks, F1 and other top level racing series use magnesium tire rims. It’s as strong as steel and much lighter, but as I’m sure you know, magnesium fires are nasty to deal with. That Indy 500 clip is from two months ago. In a choice between speed and safety, racing teams opt for speed, even if it means a flat tire would incinerate the car.
jenorafeuer (#10) –
It’s called ground effects. Some of the teams did things like moving “skirts” around the car that would move slightly up and down if they brushed the road, or the Brabham “fan car” which had a fan that literally sucked the air out from under the car. The fan car was banned after winning its only race (it would have been unbeatable) as were all ground effects after a few years on the grounds of safety. But the Venturi effects (grooves on the undersides of cars to channel air flow) remain legal if restricted in implementation.
One of the biggest changed in the early 1980s was carbon fibre. Teams were wary of its lightness, unwilling to believe it was stronger and safer than steel and aluminium until John Watson’s crash at Monza in 1981. Teams and onlookers saw a cloud of dust and thought he was dead. Instead he gets out unhurt. By season’s end, everyone was using carbon fibre.
Does the DoD even have a coherent infosec policy established that they can follow?
If they do, is it any good? If so, why didn’t they follow it here?
If they don’t… gaaah. My company’s security policy says that I don’t have to worry about state-level actors and equivalent threats; these shenanigans suggest that we’re already better off than they are.
routinely carrying extra fuel isn’t just a logistical problem, it’s a goddamned snowballing logistical problem.
Because now your vehicle that previously had a range of X miles, now has X+Y miles, with auxiliary fuel. So all the planning is done in regards to X+Y range. Some out-side-the-box thinking boot lieutenant is going to realize they can double they Y part by sticking the MRE boxes inside, and strapping on some more jerry cans there. And then they will start planning ops with X+2Y range. Until some other boot lieutenant gets the idea to stick some more jerry cans inside with the grunts…
@14: I’m very skeptical of that scenario. The whole reason all the stowage (except ammunition) on armored vehicles is on the outside is that there’s no room on the inside for all that stuff. It’s usually very cramped in there, for obvious reasons (the more room you have on the inside, the more steel you need to encompass that vilume, and the heavier and more expensive the whole thing becomes to make and run).
@Ketil Tveiten, #6, I googled that fory ya -click- and it sez something different than what you are sayin’.
My emphasis: «the MythBusters surmised that had the tank been properly enclosed, it may have exploded; but overall it remains extremely improbable.»
I feel like I can still stand by my stance that external fuel tanks aren’t a relevant problem for armored vehicles.
Ketil Tveiten @15, Prior enlisted here, and part of my enlistment was as a scout on an LAV-25 in an LAR unit, and I was speaking from experience (not in this specific example but many others followed similar trajectories). Any training op where the small unit officers had control over things, we’d always be doing some stupid shit.
Prior to that, I was in a standard infantry unit, and there was the running joke of how many troops will fit on a ? The answer was always “one more”
And, it’s already been addressed, but there was no shortage of tracer rounds. I forget the exact spacing, but for all the belted ammo (SAWs and M240s in my personal experience) had regularly spaced tracer rounds, and there was often tracer rounds supplied to those with the standard M16. Not to mention if we had time twixt getting loaded up and going on range (we always had so much time…), we would often swap out rounds to play with the spacing/timing of tracer rounds for various reasons, mostly amusement.
Anyways, the main reason stuff is stuck on the outside (MREs, packs, etc.) is because most of that can still work with a few holes and melted spots in it. Your MRE is going to be a bit of a mess, but you’ll still be able to eat it. Your sleeping bag and pad will still work with a couple dozen holes in them. The bivy, goretex, and poncho might have some problems, but if you need them in that climate, you are probably already wearing them, and even so, that’s what duct tape is for…