On this episode, we talk about the importance of having relevant, accurate recommendations for your security findings. Tackling the challenge to integrate security into the development process. Looking for insights, answers and practical solutions to avoid getting overwhelmed. Welcome to the DevelopSec podcast, where our focus is your success in securing and improving development processes. And here is your host, James Jardine. Hey everyone. Welcome to this episode of the DevelopSec podcast. Today I wanted to talk about security recommendations and when I mean security recommendations, I'm talking about when you have a pen test done or even automated scans that exist within your systems or tools. All of these, when they find something, are going to give some sort of recommendation to the development team, to whoever might actually fix this. Maybe it's not a developer thing, maybe it's infrastructure, but we've gotten a lot better over the years of having better recommendations outside of just outputting coding or something simple like that. We've gotten a lot more detailed and we try to really cater to those recommendations, to the situation at hand. I spent a lot of years doing penetration testing, offensive security, writing reports for the findings that we see, reviewing reports that come from the different tools or from different vendors for testing, and working with development teams to try to help make sure that the information that there is helpful and they don't have to spend a lot of time trying to figure out, okay, how do I implement this? You've said something is broken or the logic's not right, but now I have to figure out how do I go ahead and resolve this. And when the recommendations aren't clear, it causes confusion. It really kind of creates a big issue. And the reason I started thinking about this was I was reading through my normal morning news feeds and I stumbled across a CISA ICS medical advisory. And basically what this was, some people had found some vulnerabilities in a specific model of electric wheelchairs. And so with this, it was possible these electric wheelchairs have some sort of Bluetooth connectivity or some near field communication that could be taken advantage of. There was missing authentication for, they call it missing authentication for critical function. And basically it allowed somebody that was within range, typically from a Bluetooth. Maybe you're talking 6 or 10 meters for common range, within range, somebody could bypass the authentication and be able to control this wheelchair, which, I mean, that could be concerning depending on where you are. I mean, there's definitely a risk around this. And I won't go too deep into the actual vulnerabilities and the risks around that, but this was an interesting thing to start looking at wheelchairs. We've Seen also in the past. There was a story a while back talking, and this was actually 2015. And I'll put a link to this story as well, just for reference. Title of it is hackers can hijack electric skateboards Now. And this was something where some of these electric skateboards have a controller on them. It's Bluetooth connected. The Bluetooth pairing doesn't have authentication on it, or there's no encryption on it, and somebody within range could actually control the skateboard. They actually called it, I think Faceplant was the name of their exploit. And you know, they say in there, imagine you're going 20 miles an hour on this skateboard and then all of a sudden somebody else locks the brakes up on it. So I mean, there's a risk, obviously with this, It's a, it's a physical presence risk. It's not over the Internet. This is something, somebody has to be close enough to take advantage of the Bluetooth that exists. There was also another story, and this is actually more recent. Let me see if this actually tells me when it. Well, okay, so this is 2024, that they came out with a way. And I didn't know this, apparently on bicycles or some of the higher end cycling rigs out there for pro cyclists, they have electronic shifters that also run through like a Bluetooth setting. And some researchers found out there was a way to replay commands to those systems. I think they actually cite 10 meters in there. But, you know, if you're within 10, maybe even 15 meters enough where the signal would get picked up, you could actually cause the gears to shift on the bicycle. Now, these things, some of them I kind of find comical. We put it out there as this end of the world situation, but typically it's really not sure. I mean, you could mess with somebody shifting gears, but you got to be close enough to them. And somebody that's riding pro cycles, probably riding 25, 30 miles an hour. So if you're standing still, you get a very small window to capture and replay these commands. But there is risk. I won't deny that there's risk around that. But in all these situations, and these ones are similar, we want to understand, okay, so how do I resolve this? If I go back to the gear shifter manufacturer, you know, what am I telling people? How we can resolve this? And what could you do to mitigate this to protect yourself? If you have one of these, these shifters or if you have this wheelchair or if you have that skateboard? Oftentimes, especially with these, it's a communication issue. So we got to update how we're doing our Bluetooth authentication, making sure that we protect against replay attacks. There's not a lot the user can really do in these situations but wait for firmware update and then apply that patch to our system and that'll protect us. And so really what got me with this advisory when I saw it was around the recommendations and they kind of threw me for a little bit because they weren't really relevant. They were almost kind of generic recommendations. I'll read a couple of these off to share what they were. Now, again, keep in mind this is some sort of Bluetooth, I'm assuming, connection that's being taken advantage of in this case to be able to take control over this system. Again, most of the part you're waiting for a patch from the creator to be able to update the firmware or somehow get an update to it. So that way it'll remove this unauthenticated capability to perform these actions. Their list of items on there starts with to really mitigate this problem, they start talking about how you want to minimize network exposure for all control system devices and or systems ensuring they are not accessible from the Internet. So right there is kind of this first interesting what are we talking about? Because this isn't a network connected system or at least it's not being taken advantage of that way. This is being taken advantage of because somebody's accessing Bluetooth. So reducing this network exposure from the Internet really isn't relevant. The next one is locate control system networks and remote devices behind firewalls and isolating them from business networks. It's a wheelchair out in the public or at your home. It's not on a business network. Again, it's Bluetooth. The recommendation doesn't really do anything in this case. I don't know how you put a firewall around your wheelchair or if we were to apply this to the skateboard or the shifter. I don't know if we're going to start seeing people riding around in wheelchairs looking like bubble boy out there with a bubble around their thing to block any external connections to protect against somebody that could connect through Bluetooth and start controlling their device. Then the final one that they had is their prime recommendations. And these are defensive measures to minimize the risk of exploitation is when remote access is required. Use more secure methods such as VPNs. Recognizing VPNs may have vulnerabilities and should be updated to the most current version available. I don't know how you connect to your wheelchair or other bluetooth devices through a vpn. Maybe that technology exists. I haven't seen it. But again, it feels irrelevant to what we're really trying to address, that the issue is here. And then we also go on to. They have some other steps to recommend users take following measures to protect themselves from social engineering attacks. Talking about, do not click on web links or open attachments and unsolicited email messages. So those are the recommendations, but when you take a step back, they don't match the issue at all. These are just generic recommendations that you can't even apply. They don't even exist for this situation. And that, I think, is where we start seeing confusion amongst people because now they're thinking, oh, how do I do this? How do I go find a way to set up a VPN between my phone and the wheelchair device? How do I disconnect it from the Internet? How do I do these other things when in the end there's no way to do it and if there was, it so wouldn't have solved the problem. Now, I do want to be clear. They did. The company did issue patches to help resolve this and mitigate these issues fairly quickly, it looks like. But the focus here isn't on the risks that exist. We can say there's definitely risks to these situations. All of these, even though some of them are somewhat comical when you think about it, you know, I'm going to wipe somebody out on their skateboard. Sure, there's true risk to that, but it's still kind of funny to think about. But it's the recommendations, I think, that matter. And this is where I see the difference between the good security teams and the ones that are just kind of getting by. You get a lot of people that'll just take these recommendations, like, oh, here's the generic recommendations for this. It looks close. Let me just throw these on here and I'll throw it back over the fence. We see this problem, even with bug bounties, different things where the reports aren't that great. Even professional pen test firms sometimes don't give the best advice for resolving the issue. And I think we've struggled with this on the security side for a while. And it's easy to identify flaws and some of these things are harder. I won't diminish the work to find some of these things. Some are very novel, but they are. It's easier to show what the problem is sometimes than it is to say how to fix it. Especially with a lot of these systems, the person finding the issue may not have the insights into how that system actually works. When we're doing pen tests, we often don't have the source code. We don't know exactly what that code looks like. We're guessing sometimes that, hey, you could do it this way, or a common best practice would be this. But I don't know if that works in your context. So there's a challenge there. There's no doubt there's a challenge there, but we want to make sure we're taking that time to try to dig in and get the right information because it builds the trust. And for me, in application security, when I'm talking with developers, I want them to trust that I know what I'm talking about and that if I'm giving you a recommendation and it's somewhat detailed at times that I know what I'm talking about, this will work for your situation, or it'll be pretty close. And I've saved you a bunch of time. You don't have to go dig into it a whole lot. And again, we can't always do that. But I don't want you to think that I just pulled something up because I saw it someplace and threw it over. And then when you go to implement it, it doesn't fit your narrative, it doesn't work with your platform. It's a completely different thing. I'm not giving you a Ruby on Rails example of how to resolve something when you're programming in. NET and it's irrelevant. I'm not telling you about using reference maps, which is something I'd see in a Java app. When you're using. Net, which doesn't have those natively built in, it's a matter of building up that rapport and showing, hey, I understand what you're going through. I have that empathy. I did the legwork to try to help build up what I'm going to send to you, and when I send is going to be good. And you build that trust between each other, that you trust that the findings are real, you don't have to second guess them. You trust that the information coming across is good, you don't have to second guess it. It's starting you on the right path. But when we start seeing things that are just blatantly way off base, we start breaking down that trust. And now questions start appearing, oh, is this vulnerability real? Now I have to go out and verify it myself. I have to recreate it to prove it, because I'm not sure if you were wrong here, how do I know you're not wrong over there? So I Think it's important that we try to emphasize getting those things right. And I think from the development side, when you're receiving reports back and you're getting recommendations in there, have that open dialogue. Keep in mind that we don't see from the offensive side, everything necessarily that you see. Sometimes we're making guesses and we've had. I've seen plenty of findings on reports that what looks like an issue to the tester, you get talking to the development team or the product owner and you start to understand no, wait, it's actually supposed to work like that. And now having more context, it makes sense so we adjust accordingly. Same thing with the recommendations. Maybe the, the default, I want to say generic, but the default recommendation pushes towards a certain thing. But had I known you have this in place, maybe that pushes me to take it a step further. Oh, you have a WAF in place. Okay, well maybe there's a recommendation we can make for the WAF to help mitigate while you're waiting. But that's not the full mitigation. Let's also include. We want to make sure we're doing output encoding here or parameterization of your SQL queries over here. It's building up and making sure we have the best information possible. So I just wanted to just share that this came out actually a little bit ago, probably a month or a month and a half ago. I think when I saw this first report, I just been thinking about it to record it and I just think it's interesting to see the different things. I mean last one of the other episodes we talked about the importance of terminology and using the right terms in certain areas. And I think this ties directly with that of the importance of having accurate information both in the vulnerability and in the remediation or recommendation steps to have as complete of the information that we can have out there. So I hope you found this interesting Again I'll share the links to those three different pages, the web pages talking about the shifters, the, the wheelchair and the skateboard if anybody's interested to go back and check those out. It is kind of interesting to see the different things people come up with to what they can do from a hacking standpoint. And I think it's helpful from a developer standpoint to see that too because while you might not have the skateboard, you might not have that wheelchair or the sifters, you might be a developer that's out there working on some sort of OT device or these types of devices. And maybe you didn't think about the communication channel through the Bluetooth of things being replayed or tampered with. Intercepted authentication, these kind of like the old days of mobile apps, we didn't really think a lot about the authentication because we, it was kind of hidden from our view. Same thing here. A lot of people, they're not seeing these different hacks that happen and I think when we see them, it helps us better understand if we have to program against it. Oh yeah, I remember there was an issue where somebody did this. Let me make sure I'm covering that. And that's really the point is raising that awareness and getting you to understand some of the different risks that affect different areas. So if you ever have to work in those, they're kind of back of mind and you're just thinking, okay, I got to protect against this. So I'll put the links in there. I appreciate everybody listening and I look forward to the next episode. You have been listening to the DevelopSec podcast with James Jarvine to find out more about how we can help you with application security. Follow us on Twitter velopsec or check out our website at www.developsec.com.