It’s still summer and friends of two-wheeled transportation continue to pedal across the country in droves. And since electrically assisted bicycles are now more the rule than the exception, it’s no surprise that motorized bikes are now also becoming smart and integrated into the Internet of Things. As always, besides the obvious benefits, the whole thing naturally brings with it implications for security and privacy.
As part of the Quick Check, we have taken a representative of the “smart bike” category (or rather: “borrowed” it from a colleague) to analyze and judge both the bike and the mobile application: The Ampler Stout.
There’s not much to say about the bike itself from our perspective: the Stout is described by the manufacturer as a versatile all-rounder. It weighs just under 18kg, is equipped with a 336Wh battery that is fully charged in 2.5h and should thus allow an average range of 70km. The current version of the Stout (our version doesn’t have this feature yet) is also equipped with a small screen in the frame crossbar that presents you with the most relevant data at a glance, such as remaining range, battery level and average speed. The Ampler Bikes mobile app (com.amplerbikes.mobile in tested version 2.4.3) can then be used to perform firmware updates, view ride statistics, make bike settings and view the bike’s location. In addition, the app offers the option to lock the bike and also share it with other app users. The latest version of the Ampler Stout has a cellular module that is used for communication and tracking. The version we have still uses a Bluetooth connection between the bike and the app and mobile Internet from the app.
Apart from that, the app looks absolutely fine according to static analysis: As with virtually every app, there are some services, receivers and activities that are not fully secured and thus could possibly allow data leakage to other installed apps, but practically, we see rather low risk potential here.
What also strikes us is the decidedly consistent use of code obfuscation to hinder reverse engineering. We rarely see application source code that has been obfuscated to such an extent. Of course, this makes it much more difficult for us to analyze the application, but as long as the obfuscation is not used here to deliberately conceal a weak implementation according to the principle of “security by obscurity”, the developer cannot be blamed for this of course.
As mentioned before, the communication between the bike and the app in the version of the Stout that was presented to us runs completely via Bluetooth. This allows the app to find any nearby Ampler bike, even with a dB value, so that the distance can be estimated. The Bluetooth range is of course limited to a few meters, but some users will certainly dislike this behavior. Especially as Bluetooth cannot be deactivated nor can the bike be set to “invisible”. It was noticeable that the application requires an Internet connection to detect bicycles in the vicinity. We assume that the application only displays bikes if it can check online to which user they belong.
Apart from the official app, the Ampler bikes can always be found via Bluetooth and can actually be connected freely and without authentication. Thus, we could connect to the bike at any time in the test and read and write the individual Bluetooth services and characteristics. As long as we maintained the connection, not even the legitimate user could connect to the bike – a classic denial of service attack (DoS) is therefore very easy and can be extremely annoying for the user: He locks his bike via the app, we as the attacker then take over the connection and maintain it permanently, and unlocking is no longer possible. Of course, the other way around is just as possible.
During the partial analysis of the Bluetooth communication, we also noticed that the bicycles are each provided with a fixed ID, which makes them uniquely identifiable for the application and, of course, for anyone else who knows what to look for. Movement profiles and tracking are thus possible without any problems.
Overall, we have the impression that Bluetooth communication could be the Achilles’ heel in the Ampler solution. The extensive code obfuscation made sure that a complete reverse engineering of the Bluetooth communication was beyond the scope of our Quick Check format, but there are some indications that there might be more wrong than we could find right away. This is certainly one of the reasons why Ampler relies on a direct online connection via cellular radio for their new versions of the smart two-wheelers and could thus save quite a bit of Bluetooth communication. However, we did not have the opportunity to test a bike of the new generation.
There is actually not much to report about the application’s communication via the Internet: The connections are always encrypted and secured with the TLS protocol in version 1.3. All attempts to gain access to the content of these connections using man-in-the-middle attacks were also unsuccessful. The only chance is to modify the application itself in such a way that the implemented certificate pinning can be explicitly disabled – a possibility that a remote attacker would only have if he had complete control over the user’s phone anyway. In practice, this is rather to be ruled out. In this respect, the Ampler solution can be considered absolutely adequately secured.
Data protection and privacy
The Ampler Stout is very popular among our cycling colleagues, and even though we could find one or the other point in the test that clouds the picture a bit from a security point of view, the overall impression is still a positive one. However, the mentioned points in Bluetooth communication cannot be denied. And even though we would not down rate the device due to the presumption of further threat potential in this area, the identified points are enough to deduct one star. Overall, we still rate it with a good 2 out of 3 stars.