Topics:
Silent patches—vendors providing security updates in software updates without publishing an advisory or alerting customers to a potential vulnerability or exploitable weakness—are not an accepted best practice in cybersecurity. Defenders are blind to the risk and in the event a software or feature update is delayed, organizations could be exposed to threats for an extended period of time. Attackers, meanwhile, have tools at their disposal—including AI-powered offensive weapons—that can identify new code and build exploits for existing flaws.
Overall, silent patches can compromise the trust and transparency that vendors and users have established and thrived upon for decades.
In this episode of the Nexus Podcast, Ben Gardiner, Senior Cybersecurity Research Engineer at the National Motor Freight Traffic Association (NMFTA), shares his experience analyzing security risks in heavy-duty commercial vehicles. His research into the Bendix EC80 braking system controllers confirmed that a safety recall that resolved several software defects also patched a number of critical vulnerabilities that put the risk of a truck’s braking architecture at risk.
Gardiner presented his research at the Black Hat Briefings in Las Vegas and described how an attacker within a relatively short physical proximity could wirelessly inject malicious signals through connected systems on the trailers that could impact safety functions such as the anti-lock brake system (ABS) and pose a physical risk to the vehicle and driver.
“We got a hot tip from a friend in the industry to take a look at [the safety recall]. And the recall said that noise could trigger crashes on these brake controllers due to power line communication, and it even suggested memory corruption,” Gardiner said. “If you're a security person, you hear memory corruption, you think, okay, there could be something security relevant going on there. So our suspicions were eventually confirmed.
“We did we did a whole bunch of work supported by our fleets and other people in the industry to to get our hands on the controllers, do the reverse engineering, and even test this stuff in the field in motion to confirm that before the patch this could be triggered intentionally, and after the patch, it's all all done,” Gardiner added. “So it's not just a safety recall, it's also a security patch.”
Gardiner did compliment Bendix for promptly addressing the vulnerabilities in the recall, but pointed out the gap and risks introduced by silent patching. Because cybersecurity remediations were bundled into routine or safety-focused recalls without clear security advisories, fleet managers could not accurately assess the urgency or calculate risk scores for unpatched vehicles in their service bays. Gardiner emphasized that manufacturers must transparently communicate security impacts alongside safety updates so fleets can prioritize maintenance effectively.
“[Trucks are] really industrial control systems in motion. They're field bus controllers that do what they're told based on what messages that are on the bus,” Gardiner said. “Fleets need the business information that telematics gives them. So in trucking, telematics are connected devices that read data on the bus and sometimes also write to it. They need that connectivity for business functions, but that connectivity comes with the additional risk of potentially sending malicious messages and spoofing on the bus too. So really they are ICS systems on wheels.”
Gardiner added that the NMFTA developed the Truck Cybersecurity Assessment Tool (TCAT), a security tool distributed free of charge to fleet operators, TCAT enables maintenance crews to conduct standardized cybersecurity vulnerability assessments on their own vehicle clusters without requiring dedicated penetration testing or proof-of-concept exploits. This tool empowers fleets to benchmark security features across different truck models, compare security architectures, and maintain better oversight over trailer-connected telematics systems.
Mimoso 0:14
All right, welcome back to the next podcast. Ben Gardner is my guest. He is a senior cybersecurity research engineer at the National Motor Freight Traffic Association. And I think he's the first truck hacker I've ever met.
SPEAKER_00 0:27
Oh, my pleasure. Thanks for having me.
Mimoso 0:29
Yeah, absolutely. Thanks for coming. We're a black cat. You did a great talk this morning on uh some pretty interesting research around brake controllers and kind of something I didn't think I was going to hear about this year at surprised you. Um great stuff. So before we get into it, just tell me a little bit about your role and about the NMFTA.
SPEAKER_00 0:51
You got it. So NMFTA is the National Motor Freight Traffic Association. We're a trade association made up of LTL, less than truckload fleets, which is a small subsector of trucking, but has some of the most valuable freight. So even though we work for the fleets, LTL, our mission in the cybersecurity program is broader than that. We we have a mission to secure the whole industry. I'm a research engineer with the NMFTA, which means I split my time between breaking things and fixing things. So we publish vulnerabilities, but we also publish guidances and work in standards bodies to make things better.
Mimoso 1:27
So let's get into your your talk a little bit. As I said, it's a kind of a complicated issue. There were some patches to well, let me back up the Bendix brake controllers on the truck network, on the power line network of trucks. And there was a recall recently. So tell me a little bit about what happened there and then what you guys found.
SPEAKER_00 1:53
Right. So the recall is in 2024. We got a hot tip from a friend in the industry to take a look at it. And the recall said that noise could trigger crashes on these brake controllers due to power line communication. And it even suggested memory corruption. And if you're a security person, you hear memory corruption, you think, okay, there could be something security relevant going on there. So our suspicions were eventually confirmed. We did we did a whole bunch of work supported by our fleets and other people in the industry to uh to get our hands on the controllers, do the reverse engineering, and even test this stuff uh in the field in motion to confirm that before the patch this could be triggered intentionally, and after the patch, it's all all done. So it's not just a safety recall, it's also a security patch. Trevor Burrus, Jr.
Mimoso 2:39
But it was a silent patch, as you discovered, correct? So what led you to look at this firmware update? What what what raised your suspicions here?
SPEAKER_00 2:48
Aaron Ross Powell We've been working on J2497 PLC for truck security for a while. We have three different CVEs that have been released and ICS advisories that go along with those. So we had always been told that the tractor systems were completely isolated. We have CVEs on the protocol itself and on trailer equipment, but you know, we were always told tractors are isolated. We've been telling everyone else, don't worry about tractors, there's no impacts. So when we read the recall, just that implication that you could get crashes on the controller due to noise on power line meant that that assumption was false. So it's important to actually understand what is that impact because fleets need to have the correct threat models for really what are the potential impacts on their trucks.
Mimoso 3:35
So by crash, you're talking about denial of service correct type of crash.
SPEAKER_00 3:40
Correct. It doesn't perform its main function, which is to do automatic brake system functions with ABS pulsing.
Mimoso 3:46
So it basically shuts it off or keeps it from working.
SPEAKER_00 3:50
And you know the details matter here, right? Because this is a high assurance safety critical system, probably ACL C or D. So we definitely see that it stops streaming data, which means like that main processing loop has crashed in like the conventional sense. Because the data stops streaming other parts of the truck, depending on the vehicle architecture, shut down, for example, in many trucks the speedometer dies as well, but not all. Not all. But then yeah, the main service of the brake controller, which is to like do stability control, activate the ABS function, that stuff also stops.
Mimoso 4:22
And when you you've referenced noise a couple times, you're talking about physical noise, right?
SPEAKER_00 4:28
Yeah, yeah. I think um so Bendix talks about this in a chronology document that they updated that they released, sorry, with the uh the first recall. They saw competitors reporting crashes in the field due to noise, due to low PLC signal and high noise in band, and they reported the same thing themselves. So we're talking about noise, but it it turns out that it's not just noise that can trigger these things. It it does appear that, yeah, noise probably did cause these crashes, but you can also cause these crashes intentionally by sending well-formed messages in band as well. Right. So what what prompted the recall?
Mimoso 5:04
I guess that's a good place to start.
SPEAKER_00 5:06
Yeah, so you can read this in their chronology document. Uh competitors found in the products that that were out there that also received J2 and Race 7, they were seeing crashes in the field. And they weren't able to ascribe this to any obvious function, so they all started thinking this could be noise that's triggering this thing. And apparently Bendix found the same thing in their products. And you can look at their technical service bulletins and their chronology document to confirm that. But it appears that they did an amazing job of starting with we don't know what these crashes are, to oh, it's actually this component in the firmware, and then even putting together a full remediation patch and deploying that in less than a year's time. So really quite an amazing turnaround.
Mimoso 5:45
So how familiar were you with these communication networks on the tractors, on the trailers and the between the trucks and so forth?
SPEAKER_00 5:53
We've been looking at 2497 uh since 2019, and we had really the first public research on that uh to be released in collaboration with AIS, and we continued down and did some work on other trailer equipment. And with J1939, there's many other truck hackers in the world for sure, and we know about those systems too, but we're not the uh we're not the default experts on Jir9.
Mimoso 6:15
I thought it was pretty cool in your talk you said these just aren't boxes on wheels. They're not. Yeah. They're rolling computers, basically.
SPEAKER_00 6:22
Rolling computer networks. Right. Yeah. Sometimes you can think of them actually, since I'm sure you have industrial control system experts on the podcast. Sure. They're really industrial control systems in motion. They're field bus controllers that kind of do what they're told based on what's the bus. It what's messages that are on the bus. So it really looks like a rolling control. That's a terrifying sentence. Yeah. Yeah, it can be, especially because fleets, I'm sure this is also present in ICS. Fleets need the business information that telematics gives them. So in trucking, telematics are interconnect connected devices that read data on the bus and sometimes also write to it. They need that connectivity for business functions, which I know your listeners in ICS can also relate to, but that connectivity comes with the additional risk of potentially sending malicious messages and spoofing on the bus too. So really they are ICS systems on wheels.
Mimoso 7:12
And how complex or proprietary are these systems? Because I think that's a challenge in securing just overall OT.
SPEAKER_00 7:23
That's a cool question. So whereas 1939 was designed so that fleets could purchase trucks by picking components and having the OEMs put them together, and 1939 is there for interoperability, the actual control loops of the trucks have migrated away from the standardized messages into proprietary messages. So today, we've seen some research, for example, from CANBUCK, where they created a simple fuzzer that just sent A's, as you do when you're starting an attack, all A's, to the proprietary space. And that caused all kinds of things to fall over because that's where they're listening for messages in the proprietary space. And those 1939 messages still stick around for interop, but it's not the commands that they're responding to. So it's a mix, right? If you want to read data and understand the vehicle state, you have 1939 and it's there. But if you want to command these functions, you're going to be reaching into proprietary encodings of the signals.
Gardiner 8:19
Right.
Mimoso 8:20
You decided to look at the firmware before it was the a version that wasn't up to both, correct? And okay, so take me into that part of your research, what you found.
SPEAKER_00 8:31
Right. So that was uh that was a daunting task. It used uh an S12X microprocessor, which uh if you're old like me, you probably learned about the Motorola HC11 in university. Okay. Uh and the S12X is uh an extension of that. We had a bare metal firmware. We obviously knew where the interrupt handlers were, but in order to really understand what the patch did, we needed to have a complete disassembly of the firmware before the patch and another disassembly afterwards. So you can start at the interrupt handlers, but there's so much parts of the code that were data dependent, and because of that we needed to write like emulation of the CPU so that it could calculate the offsets that it was going to jump to and keep feeding that disassembler all the next function pointers until we had a complete image. Once we had the complete image before and after, we used a bin diff tool called QBinDif from Quarkslab. Quarkslab's tool let us actually anchor points before and after. So we could say all these interrupt handlers are the same here before, same after, and then the tool was able to kind of spider down from there and show us the differences. With that in hand, we were able to confirm that between 100 to 120 functions were deleted in the firmware update. We had three different brake controllers, one for each of the affected OEMs. Okay. So two of them had 120, roughly, functions deleted, the other one had a hundred. And that's because in trucking, there's one OEM that still uses J1587. So we found that like those 20 extra functions, they're still actually used by other parts of the code. Yeah, yeah. And the 120 total in the ones that don't use that protocol at all.
Mimoso 10:10
Some of those functions that were removed, what did you learn about them? What were they? Yeah, yeah. So I don't expect you to go through all 120, but.
SPEAKER_00 10:18
Right, we're definitely not going to cover 120. Uh the short answer is they are signal processors, so they're signal handlers for something that's called J1587 PIDs. And PIDs are like a really old specification from the 80s that predates J1939. We notice, so we always just focused on J2497 because we're really interested in what did the recall do, and the recall said it's all about power line. So we just focused on powerline, and we noticed there was some small changes to the housekeeping that the interrupt handler did. And then when messages are received, there's like this message processor and it says, Are you a lamp fault message? which is the standardized thing that it has to do. And then it hands off to this giant table of handling J157 PIDs, like 50 plus entries. Okay. And the P some of the PIDs it handled were even requests for data. So it actually had code in there that was receiving requests for data, processing the request, scheduling the transmission of the result, and then there was a little config switch at the end that just said don't send anything. So if you ever interacted with one of these controllers on the power line, you never get a response back. It's always silent. So your perspective is always that it's just like deaf, it's not doing anything. But actually under the hood, it's doing all the parsing and all the processing of the stuff you send it. And then the truth is we didn't actually need reverse engineering to find the vulnerabilities. We wrote a simple fuzzer that looked at the 1587 standard, and for every single one of them that had a variable length encoding, we just wrote a fuzzer that sent random data regarding that variable length. It turned out that this firmware was supporting four different variable length encodings, and of those four, three of them had vulnerabilities in them. Two were memory corruptions in the handlers, and one of them was a hard-coded password. And this was all deleted by it. All deleted by the update. So not that complicated.
Mimoso 12:14
So I mean, in order to exploit a memory issue or something like that, it's gotta be able to read and write and accept commands, correct?
SPEAKER_00 12:22
Is that yeah, you know, um certainly to get remote code execution, it's a little bit involved. You do have access to a pretty big buffer in the receiver, so you can like kind of put your code in a buffer just like an old school buffer overflow and then jump to the code. Yeah. But because there's 21 byte limits for the messages, you have to do a little bit of acrobatics to get your stuff lined up in the buffer for remote code execution. To crash the processor though is quite simple. You can do it with just a single message in those handlers, and it's a very short message. Beyond that, also, because the command that had that password is a traction control disable command, you could not even exploit it at all, just request it to turn off its traction control features with the right password, and it would respond. So that's also a denial of service, but it's not exploitation, it's abuse.
Mimoso 13:09
So it doesn't sound like there's super advanced technical exploits here.
SPEAKER_00 13:13
No, no, pretty simple. Buffer overflow exploitation was textbook, and uh the the out-of-bounds write stuff, uh sort of the unbounded coffee stuff, copy stuff was very textbook. There were some theoretical ones we didn't confirm that involved an out-of-bounds write due to the interrupt handler, and then the uh the abuse for the bypass was just send the password.
Mimoso 13:33
So those of us who were in your talk saw the very cool videos and demos that you showed, but tell everybody what happens when you can successfully exploit this.
SPEAKER_00 13:43
Yeah, so when you can actually crash the controller, the streaming data stops. So in many architectures we saw the speedometer got lost. So you could be driving down the road, speedometer dies, faults all over your dash. And then what we do is we have the driver do a hard break event. Now what we need to do is actually confirm is ABS functioning or not. So we need to drive just fast enough so that the ABS engages when the driver breaks, but not so fast that someone inside would get hurt. So we usually do five mile an hour and nine mile an hour tests. So we would crash the brake controller, see that the streaming data stops, and then we would ask the driver to do a hard break, and then we confirm that we felt a lock of the brakes as opposed to a normal pulsing of the brakes. And were drivers experiencing anything like this? Um so basically the reports from the technical service bulletins do suggest that there was some kind of a crash of the brake controller due to noise, and it's not clear that, you know, it doesn't say like loss of braking functionality or anything like that in the reports, but based on what we did with the in-road tests, we can assume that yeah, the brake lockups would have been part of what were what were experienced. Now remember, this is this is brake lockup in the sense that the driver applies the brakes with their foot and the ABS system doesn't respond to pulse the brakes. We're not talking about application, spontaneous application of breaks.
Mimoso 14:59
So they weren't so it wasn't necessarily someone maliciously exploiting the why would the noise work?
SPEAKER_00 15:08
Yeah, a great question. Um so if you talk to electrical engineers, particularly ones that do embedded development, they'll tell you that edge-triggered interrupts can be really difficult to get right. And one of the first patches we noticed in the housekeeping of the interrupt handler is they fix up edge-triggered interrupts by disabling it. So the previous version of the firmware had a suspend functionality, probably for power savings, and it would wake up from suspend on edge-triggered interrupts. But we found that there was like a time of check, time of use race condition that could cause corruption of memory. So it's entirely possible that noise would cause like spurious reception of bytes, and then like truncate the message too early, and you can imagine like edge conditions where the edge-triggered interrupts would cause this memory corruption. We also know from experience that trailers stream C2 PIDs, which is one of the ones that had the buffer overflow. And we know that from the work we did to create the technical mitigations against wireless attacks, where we made a keyhole mitigation. You can get bit flips and you can get truncation of messages, and the checksums are really weak. Yeah. So it seems possible that like a normal C2 message on the bus from a trailer could get transformed through corruption into a C2 message that triggers the buffer overflow. That seems clear too. Yeah. It's not clear to us, however, how noise could type in a password. Right. Even even a two-character password. Right, right. That doesn't seem clear.
Mimoso 16:26
But does the the architecture as it was designed, does it make sense? And in I mean, this isn't your normal attack vector.
SPEAKER_00 16:34
Right. Uh yeah, I think it does make sense. And um, you know, one of the things I mentioned in the talk is this is a very high assurance safety critical architecture. It has a safety monitor, like an entire separate processor that runs alongside and can observe the state of the first processor. So like we definitely have uncovered some kind of a crash, but it still is kind of failing safe in a certain sense, right? Like that monitor is still running and observing the state. And I think the crash is actually a fail-safe state of the brake controller. Uh brakes can still be applied. So yeah, I think it is, you know, implemented correctly in this case. Yeah.
Mimoso 17:10
Have you seen or heard of any similar situation in your experience?
SPEAKER_00 17:16
No. This is the first evidence that we're aware of of impacts on tractor safety from power line communications.
Mimoso 17:25
And uh maybe we should probably should have explained the the power line kind of architecture there, just what it means.
SPEAKER_00 17:31
So there's two wires running between the tractor and the trailer, uh, power and ground. And these are the same wires that people have been using to power trailers since the 60s. Okay. The connector that goes between them actually predates the ATA TMC formation and they grandfathered in the standard for the J560. So it's old, old, old. When the industry had to show trailer faults to drivers to know if there's a fault on the trailer to satisfy an FM VSS 121 regulation, they decided to add power line communication. What this does is it takes radio frequency signals and couples them to that power and ground line. So now we have uh just power, but it has like radio frequencies on top. And of course, the size of these equipments and the radio frequencies have yielded the fact that you can read and write to this wirelessly.
Mimoso 18:21
So and part of the demo too, I mean it's not exactly remotely exploitable, but you guys were within 15 feet, I believe. Is that kind of explain that?
SPEAKER_00 18:29
So we call it uh I think it's classified as adjacent wireless or uh CVSS, right? So it is totally equipment dependent. So it really depends on what tractor and what trailer you have set up. The trailer seems to be the biggest factor. Dry vans, which is a term for like the boxes that you see on the road, they're the least susceptible. Where but unfortunately, tankers are very susceptible. And tankers don't just haul water and milk, they also haul things that are hazardous, right? For about $300, you can buy equipment that will get you a three-meter range. The particular setup that I showed you in the talk achieved a 20-foot range for around $300. Now we did just get brand new results that there is a difference between stationary reception and in-motion reception.
SPEAKER_03 19:17
Okay.
SPEAKER_00 19:18
So in that particular demo that I showed you, for the for a $10,000 cost at $150 watts, so triple the power, and a fourth of the distance, a quarter of the distance at uh at five feet, we weren't able to get reception at two miles an hour creep. So there does the good news is that it does seem like the actual while it's in motion risk is mitigated by something else that we don't understand, but it is very good news. The stationary risk of these tankers though is still present, and you know, trucks and and tra and trailers stay stationary all the time at stoplights and fueling and like you name it. So it's not like they're always in motion. So it's not a completely uh good, solid mitigation, unfortunately.
Mimoso 19:59
Tell me about the actual demo experience. I mean, you guys have partners that were willing to kind of sacrifice, so to speak.
SPEAKER_00 20:06
Uh so nothing was damaged in uh in the course of this research. So no sacrifices were made, thankfully. Um yeah, we're really lucky at the NMFTA to have the support of our member fleets. And when we reach out to our fleets and we say we have topics we need to do research, can we visit your facility? Will you let us use a truck? They uh very often say yes. And you know, we do between three and four on-site tests at our fleets per year. We also were really lucky to be hosted by AIS, which is Assured Information Security, and the Air Force Research Labs, AFRL, in Rome, New York. They had that class A truck that you saw in the video, and they hosted us on the apron at Griffiths Air Force Base, which is a nice closed test course. So, like, these tests are really hard to organize because you have to get somebody who owns a truck, the truck is usually making money for somebody. You have to get somebody to loan you a trailer, and the trailer is also probably making money for somebody, and then you have to find a closed course. And finally, you know, in November 2025, we were also lucky to be hosted by an OEM themselves. So we reached out to all the OEMs, and one of them was like, this sounds very important. Please come to our closed course that they host with their own trucks, and we tested there as well.
Mimoso 21:11
Yeah. So let's talk about the the remediation part of this. What what's involved here to I mean a simple I guess as I would say a simple firmware update, but a firmware update is required. Yeah. But uh you also have to deploy this thing. I think you set to 450,000 units.
SPEAKER_00 21:27
Correct, yeah. Estimated 450,000 units impacted. The the firmware update runs like most ECU updates do. It uses uh unified diagnostic services, UDS, transfer data. The code gets rewritten in one of the two microprocessors, so the safety monitor appears to be untouched in terms of code. But yeah, like the mechanics of it is that fleets have to schedule time for each of these trucks to come into the maintenance bay, and then you have to have an updater executable that was released by Bendix coincident with a recall. You plug that into one of your diagnostic adapters. And it takes about three three to five minutes if you're successful on the first try. Hopefully, but always successful in the first try. But you know, the problem with older trucks is the communications are flaky and you have to do restarts and things like that. So it does take a bit of downtime for the trucks. The the good news is that, you know, trucks are used to having maintenance schedules where they come in and they spend time in the bay. So most of these recalls, as far as I know, were executed with normal scheduled maintenance. Right. But now the flip side of that is that no one none of the fleets were told that this had a security impact. Right. So whereas that most of the recalls were executed as normal scheduled maintenance, I think that if they were told that there was a security impact, they might have actually treated it more like an incident that really accelerated some of those deployment timelines, particularly the fleets that run tankers. Yeah. Because they're the ones that are the most vulnerable to these attacks.
Mimoso 22:53
So it's interesting, this is not an over-the-air Tesla type of update.
SPEAKER_00 22:58
As far as I know, yeah. As far as I know, the update is done through the ID9363 Windows executable, which requires a diagnostic adapter connection to Windows. So no OTA, as far as I know. That doesn't mean it isn't possible for this to be done OTA because it's just UDS.
Mimoso 23:13
But it's fixed. We should be clear about that, that everything was updated.
SPEAKER_00 23:17
Thank you for making that clear. Yeah, we're not talking about O days, these are patched vulnerabilities.
Mimoso 23:21
Right, right. Um so kind of as a last question, last point, just where's your what's your stance on silent patches? Because that's kind of what we're talking about.
SPEAKER_00 23:29
Right. You know, I think that according to best practices such as ISO IEC 12497 and CISA's own guidance on this, silent patches do not help users. Users need to be told what the security impact is of a change so that they can do their own risk calculations. Right. And today, I'm pretty sure that those users' risk calculations would include estimating the likelihood that a malicious actor would reverse engineer the patch itself and take advantage of that patch window time between known vulnerability to when it's patched. This is a very short timeline on like connected to typical IT infrastructure, and we're used to this patching cycle. But in OT, it's a totally different story, and that window is long. And I think that fleets now have a better idea of how much easier it is to reverse engineer the exploits from these patches, right? They need to be told about these things.
Mimoso 24:20
Yeah, that's a big deal. Yeah. Yeah. So what's next on their research agenda?
SPEAKER_00 24:24
Uh so we we have a lot of things that we're interested in in general. We're always looking for collaboration. Obviously, we're focusing on trucking. One of the extant threats to trucking is low-quality telematics devices, right? There's regulation that requires everyone to have them, and of course, there wasn't any testing and certification requirements in this regulation for ELDs. So we're very worried about the follow-on impacts for these telematics devices. Obviously, trailer-connected telematics devices could also send these payloads, right? The ones that we talked about that could happen at Jason Wireless that can go through compromised telematics. So we're just in trailer telematics. And then, you know, we do on-site testing of vehicle networks three to four times a year. We're trying to help fleets understand how they can do their own vulnerability assessments of trucks. Not necessarily a pen test, no POCs involved, but how can they actually compare two trucks and have some kind of estimation of which one has a better security cluster? So we have a tool called the TCAT, uh, and we are releasing that free to fleets for them to use in their maintenance base to try to do their own assessments.
Mimoso 25:34
Nice. All right.
Michael Mimoso is Director of Influencer Marketing at Claroty and Editorial Director of Nexus.
