
See icon
See icon
Vulnerabilities in common Electronic Logging Devices (ELDs) required in US commercial trucks could be present in over 14 million medium- and heavy-duty rigs, according to boffins at Colorado State University. In a paper presented at the 2024 Network and Distributed System Security Symposium, associate professor Jeremy Daily …
Frankly, i'm glad that these researchers were allowed to expose a vulnerability and not be treated as criminals, as seems to be a trend..
Because when people are discouraged from looking for vulnerabilities in infrastructure, the holes are left behind for the real baddies to do their worst.
exactly. Gummint at "work"
A federal mandate requires most heavy-duty trucks to be equipped with ELDs, which track driving hours.
So, because gummint cannot trust drivers to keep logs and maintain things on their own (including themselves) they have to INVENT A CRISIS in which a SURVEILLANCE system is MANDATED because we're just a bunch of DUMB PEASANTS who cannot manage ANYTHING without THEM.
And, naturally, they made it WORSE.
What's next, AIRLINE PILOTS? No, wait...
My uncle was a trucker, owned his own rig. He's probably FURIOUS. With the mileage he accumulated he had to buy a new one every few years. Long haul, interstate stuff. Gummint dweebs have NO clue as to what truckers need to know, and the skills involved.
And without the truckers, there will be CHAOS.
This is not the least bit surprising; a product that most people aren't aware of that the manufacturer thought didn't need more than minimal security, or none at all really, simply because few were aware of it. What is surprising is that it hasn't been attacked already. When will "security through obscurity" become illegal? Fourteen million devices isn't even a small potential volume. It's just been safe until now because it's a niche product with little obvious way to make it worth attacking, but now that attacks are so widespread and cheap to do, and there are people who would do them solely to try to cripple the economy, it's a huge vulnerability. It could even be attacked by people in the industry just to modify the data in the system to get around regulations.
Breaking into the module alone would only risk forged logging and minimal risk. It's a mistake to focus on the particular device here. The issue is that underlying data network in modern vehicles is dangerously misarchitected. Anything plugged into the CANBUS is essentially given direct access to everything else on the wiring harness by default. There are no sane security zones and critical systems are not air gapped from insecure components like in-vehicle entertainment systems. Worse, these vehicles often have CANBUS tied cellular links now, in addition to the WiFi and Bluetooth the article mentions. So in addition to a vehicle to vehicle worm, an attacker could both access command and control servers as well as mount an attack against the sponsoring organization.
There have also been in vehicle takeovers of the self driving systems, raising a combined attack to the level of a potential Maximum Overdrive scenario.
Airgap the critcal safety systems. Isolate all devices that don't need to talk to each other by default, and implement a firewall and DMZ setup between any WAN or wireless links.
Most of these embedded devices are probably a *NIX anyway, all of the tools to implement a proper secure my default footing are already built, free, and well understood.
Maximum Overdrive Part II
Faced with a murderous trucker tracking him across the desert, our intrepid hero picks up a hacker hitchhiking to Defcon in Las Vegas, who helps him hack the truck and force it to pull over. They continue uneventfully to Las Vegas.
Guess it would have to be a Short rather than a full length feature...
That's just the pre-title sequence. The main plot itself needs the constantly looming, ever more calamitous-sounding near-certain but clearly to-be-avoided epic disaster of the 'Truck Worm'. Spectacled infosec nerds frequently remind us that without it's trucking fleet US food supplies will run out in hours, free-ways will be blocked by crashed or stopped trucks, there'll be widespread looting and disorder and the shadowy organisation that plans to upload the worm in just...[on-screen display reports: 05 hours 14 minutes 21 seconds] will use the chaos to implement part two of their largely unspecified plan. An ensemble cast of diverse heroes must variously: Make US Army ammunition supply trucks safe, recruit the help of trucking personalities with CB radios to get the message out to thousands of truckers that the must cover their logging devices with thick metal shielding or whatever comedic substitute they can find, unmask some of the deputies in the shadowy terrorist organisation (but not the main boss, he gets away grr!), reverse engineer the worm, and confront the CEO of the corporation which manufactured all the duff ELDs..
1. You don't actually have to "take over" the engine/vehicle control features of a big rig to cripple a nation's truck fleet. You just have to get into the less-secure entertainment bus. E.B. command #1: "stereo on"; E.B. command #2: "volume 100%"; E.B. command #3: "play Rick Astley's Never Gonna Give You Up on continuous loop" (repeat command sequence to defeat any users' attempts to manipulate their stereo controls).
2. Someone in government has, or will, command programmers under their authority to write a "harmless" ELD-worm, which will also transmit an (ever-growing) list of GPS coordinates, with each data point being where that copy of the worm jumped from one truck to another truck-or-trucks. This will give the government person a real-world model and insight into the vectors and "contagiability" of such software. And like the Robert Morris worm, things will grow out-of-hand ...
(Icon for playing Never Gonna Give You Up on continuous loop at maximum volume.)
Sales of wire cutters and nail clippers would skyrocket at truck stops.
"What are you doing Dave(the trucker)?"
"Sorry Pal, I'm going to have to cut of your tweeter"
Enterprising roadside sellers would then make a killing on boom boxes and headphones.
You forgot the bimbo with her norks half hanging out of a sweaty tee shirt and niople pokes for those without any vestige of imagination at all. Also omitted is the obligatory woke wonder who doesn't actually do anything significant but balances up the ethnicity. You also need a long gunfight, a couple of doors being smashed in and at least one huge explosion.
And the whole film sponsored by Tesla
I dunno. After reading this article and the comments about CAN bus insecurity, I'm thinking Teslas are an obvious target. One of the features being Tesla's fart sounds. So create a self-replicating fart worm that can infect Teslas while they're clustered at charging points, and bring on the fart that never stopped. Having just read about the hotel card key issue and Flipper Zero, there seems so much potential for mostly harmless mischief. ICE trucks farting in Tesla's general direction as they overtake them.
Wonder if I could be prosecuted as a juvenile for plotting stuff like that?
Interesting article. I recently interviewed a customer who makes similar equipment. They stressed that their software development is compliant with UN ECE regulations 155 (Uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system) and 156 (Uniform provisions concerning the approval of vehicles with regards to software update and software updates management system).
Those regulations aim to prevent the scenarios discussed here. Complying with them took my customer a fair amount of effort but they now think they have a safe system. Incidentally, switching an HGV to low speed mode while it's driving on the motorway was one of the threats they mentioned.
But as these are UNECE (UN Economic Commission for Europe) regulations it could be that only European manufacturers are covered by them.
--> As it's almost that time of the week (but never when driving) and a good weekend to all Commentards.
"Incidentally, switching an HGV to low speed mode while it's driving on the motorway was one of the threats they mentioned."
I'd like to know exactly how that would be implemented: automatic transmissions are comparatively rare in HGV vehicles due to long-term durability at the rated weight classes. Almost all HGV's in the U.S. are manual transmissions (usually 9 to 13-speed) and I believe it is the same in the EU. 'Switching' to 'low speed mode' isn't something that software can do :p Kick the engine into a retarded or 'limp-home' mode, yes, but shift a manual transmission?
That may be the case in North America, but the majority of new LGVs sold in Europe nowadays have an automated manual transmission where the load and speed are electronically monitored and the gearshifts are performed by electronic means rather than the driver manually using the clutch and physically selecting what he thinks is the right gear. Whilst not a true automatic, the overall effect is similar.
Bearing in mind the number of European truck makers who now sell appreciable numbers of trucks in North America, I would be surprised if such systems are not becoming more common over there?
Probably in the smaller classes this is available, but European HGV trucks are cabovers which are highly unpopular here in the U.S. There's a legacy reason for this: the early design of cabovers, spring-ride (versus air-ride for modern designs) and limited driver space during long hauls gave them a poor reputation that they have never overcome to this day.
My own, first experience driving HGV was in a spring-ride International 7-speed cabover and let me tell you, when I switched over to a standard, cab-rear, air-ride International 9-speed it was like switching over to a Cadillac from a Yugo :D The 7-speed was a recalcitrant little biatch, plus add in the fact that the clutch rod was partial frozen in the bearings (and no one believed me until the mechanic's inspection), and the switch to the 9-speed air-ride was joy itself.
So, in America, it's still engine-forward, manual transmissioned (and no syncromesh) designs. Double-clutching is mandatory; many companies will fire you if they find you speed-shifting without a clutch, considered abusing the machinery.
"automatic transmissions are comparatively rare in HGV vehicles .... Almost all HGV's in the U.S. are manual transmissions (usually 9 to 13-speed) and I believe it is the same in the EU"
Different in Europe. Quote from page 87 of the January issue of Truck & Driver "... you can't get a full-size manual tractor unit anymore. DAF was the last manufacturer to offer one, and Scania has discontinued its manual R-series this year as well." And buses, shunter tractors and municipal vehicles have long had automatic gearboxes
"Switching' to 'low speed mode' isn't something that software can do"
Oh, yes it can. On some units (e.g. refuse collection vehicles) personnel can travel standing on the back* when the vehicle is in low speed mode (say, max. 20 km/h). So triggering low speed mode (basically engaging a speed limiter, not necessarily anything to do with the transmission) while driving at high speed is both possible and highly undesirable.
*Permitted in mainland Europe, but not in the UK where safety standards are higher and RCV loaders have to travel in the cab - which is why you see more low-entry cabs in the UK. And now Dennis Eagle have a factory in the US building them as well.
More and more big trucks are using Automated Manual Transmissions. If you open up the transmission, the insides are clearly a traditional manual transmission (input shaft, countershaft(s), output shaft, plus various gears), and you'll see a clutch at the front, not a torque converter. Look inside the cab, and you'll see a gas pedal and a brake pedal, but no clutch. The truck will have a shift lever similar to that used in an automatic transmission passenger car.
The truck's transmission control unit fires solenoids to control the clutch and selected gears. It coordinates with the engine controller to reduce torque and match revs while shifting. If you buy the nifty add-ons, it also consults with GPS so that your speed and gear selection are optimal for the terrain ahead (it can decide: oh, I'm going downhill, but there's a big hill coming up shortly, let's pick up a couple MPH, and let's not upshift just yet)
DT12 is Daimler's version (Mercedes-Benz, Freightliner, Western Star).
These vehicles have an ECU controlling the throttle and the engine. The transmission is for picking a gear, but the _electronic_ fueling system is the choke point for how fast you can go, even in a stick shift.
The good ones trim the fuel map back so you just can't accelerate past the cutoff. The crappy ones clipped the fuel once you got over the cutoff speed and don't kick back in until you drop below a target speed, and are probably a hazard themselves.
In a source of further joy, they are suggesting all cars in California should have such limiters installed to keep people from speeding, and they set themselves to whatever the local streets speed limit is.
Don't build the Torment Nexus kids...
From what is in the public domain, these are more targeted at ensuring security management is taken seriously ie. The manufacturer needs to have policies and procedures, but no actual requirement for devices to be security hardened. Thus provided a vulnerable system has been assessed through a documented procedure and the results capatured, all is okay…
Note they stressed their software development was compliant, not the resulting product…
Assuming that these are intended to be "monitor only" devices (which is what I would expect for a data recorder), then cut (and tie appropriately) the PCB track to the transmit pin of the CAN transceiver - it will then only be able to monitor, with the added advantage that any fault can't disrupt the vehicle CAN bus.
Great idea, the only minor snag with it is that CAN is a bi-directional bus that uses differential signaling over two wires only so there is no dedicated TX pin as such and cutting the connection would isolate the ELDs from the CAN network thus rendering it completely unable to monitor the vehicle systems.
You might be able to disable the TX Enable on the transceiver IC if it's actually a separate transceiver and not integrated into a microcontroller but it really depends what information the monitoring system wants and if it's all exposed on the wider CAN bus by default.
If it's hidden behind a gateway controller that only exposes it when requested to which would require TX capability on the ELDS.
I thought there are already gateways separating actual control systems and stuff like entertainment systems so you can get some data (current speed, rpm, ...) on the entertainment side but not control anything vital?
If so why is the logging device not on the entertainment side?
I don't know what data ELDs collect or if/what they can control so can't really comment but from the info in the article it would suggest it needs access to more than just speed, RPM, it seems to want info about engine load, performance, emissions etc. which would need more than the limited subset of data which might be available to the infotainment systems.
What I do know is that the gateway modules are not permanently opaque, you can make them transparent and communicate with all systems on a CAN bus by throwing the right combination of incantations at it from a scan tool via the OBD connector or by tapping in to the bus somewhere else.
Plus, we already know that automotive CAN networks in vehicles are not good at security, for example there's plenty of ways to steal vehicles by tapping into the CAN bus where it's easily accessible on the exterior (headlights, mirrors, "hidden" engineer service access ports) .
Thus all bets are off if you have 'physical' access (WiFi in this instance) and can implant your own dodgy firmware on something CAN connected.
Securing CAN has challenges, but there are some things we can do. Safety critical messages tend to use a 1 byte or 1 nibble counter, use the counter as an index into a lookup table of values, and then calculate a CRC based on the lookup value and the payload of the CAN message.
AUTOSAR E2E is the common standard.
Of course, each CAN message is only 8 bytes long (and you're down to 6.5 bytes usable if you have an 8 bit CRC plus 4 bit counter), so reverse engineering the algorithm isn't totally impossible once you collect enough data.
I'm pretty sure E2E was more concerned with detecting and correcting for things like failed hardware, corrupted memory, or similar failures, not malicious intent, so it will only help so much, but it's a lot better than no protection (OTOH, it's a pain in the rear if you have a legit reason to inject CAN traffic, like bench testing).
CAN messages also tend to zip by fairly quickly, and can have hard real time requirements, so you need something fairly lightweight.
The old school thinking was that with CAN, you needed to have physical access to the vehicle. In the IT world, we assume that physical access usually means you win.
One other note on CAN, it's no longer "The" CAN bus. Vehicles now have many CAN busses. Commercial semi trucks will typically have powertrain, chassis, diagnostics, infotainment, steering, suspension, and plenty more (plus a bunch of LIN networks). I pulled up an architecture diagram for one of our lines, and I think I see 8 CAN, over 20 LIN, and one each for FlexRay, MOST, and Ethernet. (This is somewhat extreme, we're moving to more Ethernet, the one-off protocols are probably for proprietary customer add-ons).
Always nice when one of those in the know chime in on these discussions. Also glad to see at least some in the industry are paying attention to the problems of segmenting the in-vehicle systems.
Do you think the industry is on track to address these concerns in a timely manner, or can we expect the rest of the manufacturers to lag years behind where yours seems to be heading?
?
Great idea, the only minor snag with it is that CAN is a bi-directional bus that uses differential signaling over two wires only so there is no dedicated TX pin as such and cutting the connection would isolate the ELDs from the CAN network thus rendering it completely unable to monitor the vehicle systems.
If the transceiver is separate from the µController, there will be a tx-enable and/or separate rx/tx data pins, so it it should be possible to cut a trace on the board and turn it into a rx-only device.
If the transceiver is integrated into the µController (didn't used to be a thing, especially for automotive), then that's not possible.
All of the microcontrollers I work with use external transceivers (I've not come across any yet with them integrated), and I have made nodes in the past that are "receive only".
"Receive only" only works when there are at least two other nodes on the bus, as any transmitted message is only valid (and receivable) if another node sends back an "ack" to say it has been received without error.
I've designed CAN firewalls to filter messages, but they are not ideal as they introduce latency of at least the message length plus forwarding time (which can be kept to a few uS) - though this isn't generally an issue when forwarding to logging equipment.
Also, cars are moving to plastic optical fiber to cut costs/weight/power use on the wiring harness. Hilarious that the Mercedes dealers wanted $$$$ to fix a cut, when it is a glorified TOSLINK cable and could be patched with plastic fiber from children's light up toys.
I should have explained myself better - I was talking about the transmit signal between the microcontroller and the transceiver (which drives the differential bus).
I have deployed a number of receive only CAN devices over the years, so it does work (assuming a gateway doesn't need to be triggered).
MOM: “Johnny, what are you doing with your computer?”
JOHNNY: “I’m building myself a CONVOY!”
—-
It was the dark of the moon
On the sixth of June
In a Kenworth, pullin' logs
Cabover Pete with a reefer on
And a Jimmy haulin' hogs
We was headin' for bear
On 'I-1-0
'Bout a mile out Shakey Town
I says, Pig Pen this here's the Rubber Duck
And I'm about to put the hammer down
Oh wait! What’s happening?
Am I the only one who thinks that the connected world being created seems more like Stephen King's Mist than the idyllic fluffy cloud the marketing drones are peddling? Perhaps it's time to start thinking about disconnecting critical infrastructure from the instant-access digital universe and limiting the latter to relatively safe and possibly realistically securable applications like entertainment streaming.
One of the big problems is the CAN bus itself. It's a clunky late '80s inter-device comms system that requires all devices to be connected on a common physical bus. The result is that breaching one function on the bus can allow access to anything else on it. It's a great pity that CAN bus was not abandoned in favour of (for example) Ethernet.
The common bus is partly why it's remained so popular, especially in scenarios where minimising the amount of physical wiring is either beneficial (cost/weight savings) or essential (can't actually fit more cables into the available space).
That said, you don't *need* all your CAN devices to sit on the same bus, you can run seperate buses for different classes of device, with your main controller handling any bus to bus bridging of comms data that might be required. Yes, this means having to run more than one set of bus wiring, but you're still only looking at a handful of busses rather than a few hundred (and then some in some scenarios) point to point links, so it's still more feasible within whatever design constraints apply.
I suspect the reason CAN bus has not been replied with something else (e.g. Ethernet) is simply cost.. First, I've read in the past that CAN Bus devices don't need a lot of processing power, and second, it's designed to reduce copper. Removing excess copper also has the advantage of making the vehicle lighter, which reduces fuel usage. I know it's only likely a kilo at most, but bear in mind some car manufacturers (particularly sports car manufacturers) have strict weight limits on their devices, saving the odd kilo here or there might be important.
Regarding processing power, this was the case pretty much from the early 90s to the late 2010s. It wasn't feasible for small low power devices to have Ethernet because it required more CPU power than was available.
In terms of raw CPU power, it is now. If the weight ot the copper is a problem, perhaps it's an idea to improve the security on CAN Bus?
So the faster implementations can pass higher level protocols on the data bus, but the PHY layer is different. Using Ethernet PHYs wouldn't help the security situation.
Ethernet and PCI physical signalling use closely related SerDes transmission, tuned for the different transmission distances and mediums. Those don't provide the security features a vehicle with active external connections needs either.
The missing parts are mostly higher level than the physical layer, or architectural design issues like full separation of critical systems on separate busses.
CAN has a lot of advantages that mean it cannot always be replaced by other interfaces - hard real-time control systems, for example.
It has also evolved since the first version was released in the early 2000's - it now supports more than 1 Mbps (including switching bitrate to higher speeds when transmitting the payload), more than 8 bytes of data, and new variants (e.g. CAN XL) are on the way.
Work is also being done on "zero overhead" security improvements. One of the big issues is that it is very easy to "spoof" a message - all a hacker with access to the bus needs to do is send a message with the desired identifier*. This can be guarded against by the node that is permitted to send that identifier monitoring the bus and invalidating any message (by sending an error frame) it sees that is sent on the bus by another node (there is at least one CAN implementation out there that supports this in hardware).
* A CAN bus can be though of as a virtual table, with the identifier of a message selecting a row in the table. Any node can read any row, but only one (should) write to a row.
Yes, there is a path for international terrorists to take over your truck. More to the point, there is a path for drivers to over-write the speed and distance logs.
"Honestly officer, I'd only been on the road for an hour when I fell asleep, veered off, and collected two cars killing 7 people"