Kia Telematics, Telecom Security, and Documentation.

Introduction

Kyle Fox here. Slow week this week, we have car telematics and some thoughts on documentation and telecom security.

Researchers Find Vulnerabilities in Kia Telematics

Sam Curry's team found issues with Kia's telematics backend back in June and disclosed those a couple of weeks ago. The flow springs from a Kia system that is setup to allow dealers to associate cars with new owners, the system had no limits in its ability to make changes to Kia telematics accounts, so it could be used with cars that had long since been sold and by dealers who had never touched those cars.

The researchers went on to use a license plate to VIN service to make an app that would automate the exploit, allowing for an attacker to quickly gain access to a vehicle. After reporting the issue to Kia in June it took unusually long for the automaker to start responding to researchers, highlighting a common issue seen when companies not used to the cybersecurity space start operating in it and get reports of issues.

This whole situation highlights potential for security risks in the emerging vehicle telematics field, with Kia being one of smaller players behind companies like Ford and Tesla. As one can imagine it would be a lot better to limit the access dealers have to their part of the vehicle life cycle than to attempt to impose tight security on employees of tens of thousands of dealers.

This was also covered by Nikki over on the Transport Evolved YouTube channel.

The Slow Grind that is Telecom Security

A couple of weeks ago Veritasium released a video where they hacked Linus Sebastian's cell phone using the backend control protocol of the global phone system, Signaling System 7. This video serves as a summary of a large body of research into how untrustworthy service providers allow malicious agents access to track mobile users and hijack their phone calls and SMS messages. I recommend watching the video as I don't have nearly enough time to re-summarize it, but I have some thoughts.

Telephones are still a ubiquitous thing in most countries, almost everyone carries around a device that nominally can act as a telephone, and large amounts of commerce still depend on them every day. But as time goes on, the relative late response to bad actors on the telephone networks has proven to be a rising problem for everyone who uses them. Take for example, they sometimes massive quantity of scam phone calls that cheap VoIP connectivity has enabled (I even got one while writing this). While attempts like STIR/SHAKEN make it more difficult for scam artists to get through to victims, as one browsing r/Scams can see, they very much still get through quite a bit.

For us in the security world, this means we should not act like the public telephone network is trustworthy. As we see more and more attackers are hijacking accounts or otherwise intercepting SMS messages, so those should not ever be used for authentication, nor really should phone calls. Even in the 1990s we saw spoofing of ANI, the caller-id-on-[redacted] that comes with an inbound WATS line, for various purposes. Ringback modems (where you call them, hang up and they call back a pre-programmed phone number) were developed based on threats like that.

So, to recap:

SMS is insecure and can be intercepted.
Caller-ID and ANI can be spoofed.
Things exposed to the phone system should have security on them as if they were exposed to the internet. Got a modem at a remote site that allows you to log into a jumpbox? Make sure its reporting bad password attempts and disconnecting after a few failed attempts.
Someone might be tracking you by your phone, they don't even need to get malware on it to do this.

Sometimes the Dumb Things Need Documentation

I frequently look at escalations from F5 Network Support to Engineering Services and one thing I ran across while looking was an escalation asking what kind of cable goes between two SFPs that use MPO-12 connectors. For a bit of background, the MPO-12 connector is a fiber optic connector designed to carry 12 strands and connect them in one compact package. Prior to this connector the only multiple strand connections normally seen were twinned individual connectors like SC or LC or the rare FDDI connector.

Fiber polarity can be quite complicated, as seen in this article on FS.com's website. And I had some experience with MPO as used in single-mode fiber trunks, so I suspected that it would be easy to quickly find an answer to the customer's question that is well documented. But I found that most materials dealing with fiber polarity do not directly address the question of connecting two SFPs, and when they do the wording is quite vague. F5 does not do much better, with an article on fiber networking cables highlighting the answer, but not answering it in the text. The answer being you use a Type B cable that rolls over the fibers so that TX1 on one end is connected to RX1 on the other, and so on.

This may sound trivial, but in the thick of an incident you might encounter something that your 99% sure is correct, but for some reason looks off, and you need to check on these things because from how processes look in commands like ps aux to how a door lock cylinder sits in a mortise, little details may reveal that something is not right and chasing down that something might uncover an otherwise unnoticed breach. So, while your working on documenting things, think about someone who might not have seen them before, or is not an expert in structured cabling or security doors, and specify a little more about how it should be. And stop using "in the usual fashion" when that's not ever explicitly specified.