One Civic owner purchased a cheap aftermarket head unit off Amazon, and decided to have Claude work its magic on it, like it would a smart TV. What was reportedly discovered isn’t surprising, but is worth knowing about.
Among the pre-installed bloatware—or spyware, if you’re being less charitable—was a voice assistant equipped with WebView, an Android system component that lets apps display content off the web. This apparently always used about a third of processing power, even while idle, which isn’t great. There were also Baidu location services, a call recorder (!), a DAB radio client that is pretty much useless in the U.S., and Adobe Acrobat, presumably so your passenger can entertain themselves with PDFs on the go.
It’s interesting because it exposes all the insecurities in this piece of IoT software. But I think the real story is that a random person was able to do this reverse-engineering with the help of AI. Expect a lot more stories like this in the future.
St. Lucie County in Florida discovered (alt link) a dozen Flock cameras whose ownership it can’t identify, and that the county government had not permitted.
I am reminded of the decade-old story of StingRay cell phone surveillance devices in Washington, DC, whose operators were also unknown.
My guess is that in the StingRay case, the devices were operated by foreign actors. This Flock case is more likely some local government entity that didn’t bother getting approval. Were I a foreign actor, I would rather hack the existing Flock network—like Israel did with Tehran’s surveillance cameras—than risk installing my own.
Regardless, once we normalize a surveillance infrastructure, both friends and foes will take advantage of it.
Researchers at Northeastern University, in collaboration with Consumer Reports, evaluated how much modern cars spy in their drivers:
The new Northeastern study shows, for the first time, data flowing among the vehicles, the vehicle apps you download when you buy your car, and third-party companies, documenting exactly what kind of data gets siphoned from our vehicles and which companies are receiving that information.
Basically, your car’s manufacturer has you under constant surveillance, and they use that data against you.
The companies on the receiving end of your data, our investigation has found, include car insurers and lenders that are partners in “telematics data exchanges,” which compile driving data on millions of drivers, thousands of data brokers that create personalized risk scores, companies selling infotainment and WiFi hotspot products, and even local and state government agencies working on planning, traffic, and safety initiatives.
Nearly every automaker sent data to outside companies.
Even more troubling, almost a quarter of the vehicle apps were found to be sending out personally identifiable information, including vehicle owners’ names, vehicle identification numbers (VINs), and precise geographic locations. That information can make it easy for companies to link driving behavior to personal data profiles created by data brokers and marketers. Such profiles are routinely sold to banks, insurers, pharmaceutical companies, lenders, and retailers, who can use it for personalized loan terms and filtered bank and insurance offers, a CR and CalMatters investigation found.
Remember the adage “If you’re not the customer, then you’re the product”? (The sentiment is older than you think.) Turns out that with modern internet-connected everything, you’re the product even if you are the customer.
Hackers captured a Flock camera and got a look (alternate link) at the software:
While much of the automatic license plate reader’s (ALPR) most sensitive storage remained encrypted and inaccessible, the joint analysis of the recovered data shows that software running on the device explicitly detects people as well as vehicles, license plates, and bicycles. The camera can produce dozens of images of a single passing vehicle and, according to several weeks of recovered logs, generated more than a million images. Its computer-vision software also sometimes isolated bumper stickers and other graphics, including, in one case, an American flag patch on a motorcyclist’s saddlebag.
If you’re wondering how the hackers got by disk encryption, one of the unencrypted partitions contained the key for an encrypted partition. That’s pretty bad security engineering.
…some municipalities, including Denver, Colorado, are ditching their Flock arrays. But keep in mind that if they’re only switching from Flock to another brand of license-plate readers, like Axon, it’s like a gambling addict trying to kick the habit by switching from FanDuel to DraftKings.
[…]
Despite what you may read on the Flock website, Axon cameras are pretty effective when it comes to hoovering up personal details that can go far beyond your license plate numbers. That means a municipality that opts for Axon cameras instead of Flock units won’t necessarily reduce the amount privacy its citizens lose through their use.
Officers can also tap into data showing a car’s decals, bumper stickers, back and top racks—along with temporary and unique state tags.
Flock calls it a “Vehicle Fingerprint” and it’s touted as a way for law enforcement officials to get more information “even when you don’t have full plate information,” the company’s presentation shows.
The company gives police officers the ability to search that data as well, to “build stronger cases with less information upfront.” That includes being able to locate multiple vehicles law enforcement officials believe are moving together and what Flock calls a “multi geo search.”
This kind of thing is older than AI; I wrote about it in my 2014 book Beyond Fear. Edward Snowden revealed that the NSA was using cell phone location data to track phones that were habitually near each other.
As bad as Flock is, remember that anyone with broad access to cell phone location data can do the same thing.
There are over a dozen cases around the country where police officers are using the Flock surveillance camera system to obsessively and illegally stalk people.
The surveillance company Leonardo wants more data:
A surveillance company plans to add sensors to automatic license plate readers (ALPRs) that would mean the devices, as well as capture the license plate of passing vehicles, would also sweep up unique identifiers of mobile phones, wearables, and other Bluetooth-enabled devices in those cars, potentially letting law enforcement identify specific drivers or passengers.
The technology, called SignalTrace, would turn ALPR cameras from devices focused on tracking cars to ones that can more readily track the location of particular people. ALPR cameras have become a commonly deployed technology all across the U.S.; SignalTrace would make some of those cameras capable of collecting much more data.
Yes, it’s bad that more companies are collecting this level of surveillance data. But all of this pales in comparison to the type and quantity of data our smartphones already collect about us.
According to global research, the market share of highly automated, driverless vehicles is growing rapidly. Analysts estimate that the next 10 to 15 years will mark a major shift from pilot projects to the mass adoption of autonomous transport. The momentum is building worldwide: Europe has already rolled out over 35 autonomous vehicle pilots, while the U.S. and China log more than 450 000 and 250 000 commercial trips per week, respectively. However, the report notes several roadblocks slowing down this progress. One such hurdle is the uncertainty surrounding legal liability and regulation, including in the areas of safety and security. The allocation of responsibility among suppliers, manufacturers, enterprise clients, and end users remains a major point of discussion.
Each market stakeholder sees the issue of ensuring the safety of autonomous vehicles differently. For automakers, it means taking responsibility for how a vehicle behaves on the road and for vetting their suppliers. For the suppliers themselves, it means designing security mechanisms directly into their solution architecture from day one and guaranteeing their adequacy. For insurance companies, it means completely overhauling their risk models to account for not just accidents, but also potential software glitches and cyberattacks. Ultimately, everyone agrees on one fundamental point: security must be a foundational feature of the vehicle — not an optional add-on.
Ensuring vehicle security in the modern era
For years, discussions around automotive safety focused strictly on functional safety. In other words, the goal was to ensure that vehicle systems operated correctly, and that risks associated with potential failures were fully mitigated or reduced to an acceptable level. The ISO 26262 standard “Road vehicles — Functional safety” helps address this very challenge, and serves as the baseline for the automotive industry.
However, the modern connected vehicle is a complex cyberphysical system that stores and processes massive amounts of data, including sensitive information. And this leads to the emergence of new basic needs. To draw an analogy with two levels of Maslow’s hierarchy of needs, a modern vehicle must:
Satisfy the need for “esteem” — meaning it must securely and reliably store user profile data, such as account credentials, biometric data, payment details, and more.
Satisfy the user’s cognitive needs — meaning it must provide secure internet connectivity, transmit vehicle telemetry, and send reminders for scheduled or emergency maintenance.
All of this means equipping vehicles with a wide array of interfaces — telematics, Bluetooth, Wi-Fi, cellular connectivity, OTA updates, and V2X — which opens the door to remote attacks. Therefore, it becomes necessary to ensure not only the functional security, but also the information security of the vehicle. As a result, specialized industry standards that help address automotive cybersecurity challenges have emerged in most countries. The key international standards are ISO/SAE 21434 “Road vehicles — Cybersecurity engineering”, UNECE R155, and UNECE R156.
China’s regulations are evolving too. In 2024, the country published the national standard GB 44495-2024 “Technical Requirements for Vehicle Cybersecurity”, which went into effect on January 1, 2026. The document introduces mandatory cybersecurity requirements for vehicles, including communications protection, security event management, threat monitoring, and secure vehicle interaction with external infrastructure.
Understanding and applying these standards is becoming absolutely critical. Research shows that cybersecurity risks are escalating daily, and their impact on functional safety can sometimes trigger far more dangerous incidents than an internal system failure. What happens if an attacker gains access to a self-driving truck’s remote-control system, or manages to reflash a critical electronic control unit during an unauthorized diagnostic session?
One of the key components for mitigating these scenarios is a security gateway, which isolates the vehicle’s architecture into different domains based on criticality, while providing secure routing, filtering, and traffic control. Developing this type of software solution is precisely what our team focuses on as we build the Kaspersky Automotive Secure Gateway based on KasperskyOS.
Why Kaspersky Automotive Secure Gateway?
The primary purpose of Kaspersky Automotive Secure Gateway (KASG) is to secure the vehicle’s CAN domain, since the CAN bus is used to transmit a vast number of critical control commands. This impacts nearly 80% of the electronic control units inside the car, which handle engine management, braking, body electronics, and more. Because of this, we utilize the Safety-Aware Cybersecurity approach — a unified architecture that accounts for both functional safety and cybersecurity requirements.
For example, standard End-to-End Protection (E2E) mechanisms are typically used to mitigate risks associated with dropped, out-of-order, or corrupted CAN messages. However, these mechanisms were not originally designed to counter targeted cyberattacks. If an attacker manages to construct a malicious frame that conforms to the required E2E format, the system may accept it as valid.
This introduces a new factor: it’s critical not only to verify that a message was delivered without errors, but also to ensure that it was actually generated by a trusted electronic control unit (ECU), and was not altered in transit. This is particularly vital for transmitting control commands — such as those sent to the vehicle’s braking system — or for implementing keyless entry (NFC) systems.
To address that challenge, Secure Onboard Communication (SecOC) mechanisms are integrated into the vehicle’s architecture. They use cryptographic methods to verify message authenticity and integrity, protecting the system against message spoofing and replay attacks. KASG successfully implements these mechanisms, which, in addition to message verification, perform the crucial function of centralized key management. This allows encryption keys to be distributed and updated from a single point within the vehicle, reducing both the cost and the processing load on the ECUs involved in SecOC-backed data exchange.
Automotive IDS
However, in complex systems, it’s no longer enough to apply security mechanisms only to individual messages or separate network segments. It’s essential to provide vehicle-wide monitoring and control, tracking behavioral anomalies, unusual cross-domain interactions, and unauthorized tampering attempts. In the IT domain, this is known as an Intrusion Detection System (IDS). These systems have been successfully adopted by the automotive industry as well.
At the same time, it’s important to realize that for a modern vehicle, an IDS is not a single magic point of data collection and analysis; the vehicle requires a distributed monitoring system. Monitoring is carried out at various architectural levels: within domains, at the individual controller level, and at network boundaries.
The security gateway becomes a critical monitoring point because all cross-domain interaction passes through. Additionally, the gateway provides visibility into data exchange across different segments of the vehicle network. Its job is to detect deviations from normal behavior and generate security events.
When it comes to the CAN domain monitoring implemented in KASG, the IDS looks at the following criteria for traffic analysis:
Alignment of CAN message parameters (CAN ID, DLC) with their descriptions in the DBC specification.
Frequency and periodicity of CAN messages.
Allowable ranges for CAN signals.
In practice, however, an important limitation becomes clear: even with an onboard IDS, more context is required to determine the exact characteristics of an attack. Furthermore, when operating highly automated vehicles — where fleet-wide monitoring is essential — such isolated analysis becomes inherently insufficient.
Connecting a vehicle to an SIEM
Multi-object monitoring, data correlation, and data analysis can be efficiently handled externally — specifically in SIEM (Security Information and Event Management) systems, which are traditionally used in corporate and industrial cybersecurity operations centers. Therefore, utilizing a SIEM system fleet-wide is a logical step that makes it possible to:
Collect security events from multiple vehicles.
Correlate events over time and across contexts.
Detect advanced and distributed attacks.
Provide incident auditing and investigation.
Respond to individual incidents and manage cyber-risks fleet-wide.
When integrating with external SIEM systems, several critical tasks must be addressed: ensuring a secure connection, tuning the security event transmission process, and establishing baseline rules for event processing and correlation. We are actively working through all of these challenges using our own SIEM system — Kaspersky Unified Monitoring and Analysis Platform — as a blueprint.
There are still many issues ahead that need to be resolved. This article covered only a fraction of the approaches currently used in KASG to ensure vehicle safety and security. Yet even this small part demonstrates that automotive security cannot be achieved by solving a single problem or applying a single mechanism. Achieving it requires an approach that enables methodical architecture development — balancing diverse requirements for vehicle functionality, security, and reliability.
Abstract: Embodied Artificial Intelligence (AI) promises to handle edge cases in robotic vehicle systems where data is scarce by using common-sense reasoning grounded in perception and action to generalize beyond training distributions and adapt to novel real-world situations. These capabilities, however, also create new security risks. In this paper, we introduce CHAI (Command Hijacking against embodied AI), a new class of prompt-based attacks that exploit the multimodal language interpretation abilities of Large Visual-Language Models (LVLMs). CHAI embeds deceptive natural language instructions, such as misleading signs, in visual input, systematically searches the token space, builds a dictionary of prompts, and guides an attacker model to generate Visual Attack Prompts. We evaluate CHAI on four LVLM agents; drone emergency landing, autonomous driving, and aerial object tracking, and on a real robotic vehicle. Our experiments show that CHAI consistently outperforms state-of-the-art attacks. By exploiting the semantic and multimodal reasoning strengths of next-generation embodied AI systems, CHAI underscores the urgent need for defenses that extend beyond traditional adversarial robustness.
British defence firms have reportedly warned staff not to connect their phones to Chinese-made EVs
Mobile phones and desktop computers are longstanding targets for cyber spies – but how vulnerable are electric cars?
On Monday the i newspaper claimed that British defence firms working for the UK government have warned staff against connecting or pairing their phones with Chinese-made electric cars, due to fears that Beijing could extract sensitive data from the devices.
Login
