Summary
Crosswalk signal systems using audio were hacked and playing fake or AI generated audio of people such as Elon Musk or Mark Zuckerberg. This happened in cities in California. How this was achieved was through using an app by the company and Bluetooth connectivity to access the devices and uploading the new audio. It seems that this app was previously publicly available, and the default passcode was either your first or second guess. This allowed the hacker to upload the audio onto the device and played with user normal interaction with the device. There was a lockout after too many failed attempts, which means that even a simple PIN change is enough to thwart all but insider attacks. This provides a great simple case study on secure from start thinking and why you need cybersecurity in the beginning and not just when an incident occurs.
Video Link
Cost Savings Right into Insecurity
So, there are many potential mitigation strategies that could have been employed to prevent this type of attack from occurring. However, they almost all come with an increase in cost or complexity or both. These pressures likely lead to the vulnerability exploited here.
1. Force Default PIN change
These are public devices with open Bluetooth connection, the least you can do is force the default password / pin to change on initial setup. Now this is not a panacea as most organizations will simply pick a single PIN code and if it’s leaked or an inside job then this mitigation is much less, but the threat surface is greatly reduced.
Why do companies not do this? Increased complexity and increase in support required for their devices. Now you have someone new start and they didn’t tell you or record the PIN. You are calling the company to get help with a force reset if that’s even possible. As the company you must consider and develop around this process and support this code base in machines that are embedded with controllers which are already deployed. In this case physically in the ground. A recall vs. the risk to the company is likely highly in favor of risk acceptance.
2. Bluetooth Physical Key
One solution to help would be to put a switch or contact closure on the device required for Bluetooth to be enabled. This can be behind a locked port which again is a DID concept and not a perfect solution. Now you need to break in or have a key to enable Bluetooth and hopefully without a default pin (see options 1).
This suffers from the same issues as option 1 as it requires modification to existing devices in the field. This is again financially and physically impractical and likely again will lead to risk acceptance.
3. App with Verification
One potential option is to lock down the app using some form of cryptographic keying to match authorized use apps to the devices. Again, a firmware update would likely be needed but not physically changing the controllers.
Released as a patch for the staff and an update of the app itself would allow this to be added to a simple feature. This would enable with another form of authentication (login to the company website from authorized account) to pair the devices before configuration would be allowed. This would remove the PIN.
Lessons for Cybersecurity Professionals
When companies or organizations do not engage with Cybersecurity at the start of projects or product development this is a very likely outcome. We end up with physical devices installed with inherent security flaws. In the case of software, we can usually patch this out quickly but in the OT/ICS space where things are physical and on embedded controllers this becomes a much more costly miss. This case serves as a funny (really a prank more than a hack) to demonstrate how thinking about secure from start is essential in successful and secure products.