Security Flaws Discovered In Ninebot Segway Hoverboards

News broke yesterday that Ninebot, the company behind Segway hoverboards, has issued new firmware to fix various security flaws that allow an attacker to connect to and take over users’ devices.The flaws were discovered last year by Thomas Kilbride, a security researcher for IOActive, who contacted the company in private and disclosed his findings. Chris Schmidt, Senior Security Research Manager at Synopsys commented below.

Chris Schmidt, Senior Security Research Manager at Synopsys: 

“This is exemplary of what a real-world attack would look like; those responsible for implementing each of the involved components very likely have little-to-no interaction with each other during crucial phases of design, resulting in a set of components that “can” interact, but maybe weren’t intended to ever actually interact with each other within the device. The ability to connect to the device using a default credential is a single flaw, but by itself it’s relatively harmless in most cases; it’s what you can do once you’ve connected that makes this example interesting.”

“Each of the vulnerabilities discussed by the researchers demonstrates a vulnerability that, by itself has implicit limitations as a viable attack and are simple design-time issues that would be “cheap” to solve if applied at the right time.”

• Default credentials for Bluetooth connections – we all know that use of default credentials is bad, we’ve all seen all the stories over the last few years about devices using default credentials being “hacked”, there’s even a service called Shodan on the internet that will let you search for specific models of devices that are connected to the internet so you can automate your attack against all those devices and their default credentials; yet somehow, vendors continue to ignore the advice of the industry to simply “force” a password change the first time a user connects to their device. This simple guidance, if practiced could serve to reduce the attack surface of devices exponentially.
• Verification and Encryption of Firmware – let’s be real here, the fact that this is still a concern today, frankly concerns me. If I can build my own firmware and upload it to your device; and all that does is voids the warranty then we have much bigger problems to address. As an attacker if I can control your firmware I fully own the device, and generally can do anything I want within the limitations of the devices capabilities and available hardware. The limiting factor that generally I have to have physical access to a device limits the likelihood of mass-attacks against devices that don’t protect their firmware components and simply purchasing and protecting encryption keys to encrypt your firmware, then performing validation of any updates *before* they’re applied to the device further limits the feasibility of this type of attack. The ability to remotely update firmware and the ability to disassemble vendor firmware and customize it to do whatever one may want it to do with no verification makes this a critical vulnerability.
• While ethically questionable from a privacy perspective, the ability to view any nearby riders anonymously poses no actual technical security threat. Privacy concerns should dictate that during design of the application, you would only be able to view the precise location of another rider if that other rider specifically granted you permission to do so. Viewing “nearby riders” without exposing their precise location could act as a catalyst for a function that a rider could send a “request” to other riders in the area to “meet up” which would explicitly inform the users that the requesting user would be able to view their precise location once confirmed. The real danger here is that to a motivated attacker, this allows a compromised device to act as a agent of infection in a wormable attack, creating an opportunity for a widespread and automated attack; installing rogue firmware on many as many devices as could be located, then allowing those devices to do the same. Imagine a robot army of hoverboards and you’ll start to get an idea of why this is generally a bad idea.

To summarize –

1. Vendors *must not* allow devices to function with default credentials.
2. Vendors *must* encrypt and verify firmware updates
3. Vendors *must not* allow remote, unauthenticated access to update firmware
4. Vendors *must* adhere to privacy best-practices