App Analysis: Bird
Based out of Santa Monica, Bird is a scooter sharing platform which has amassed more than 10 million rides across more than 80 cities and university campuses and in July 2019 Bird was valued at 2.5 Billion dollars. Bird provides electric scooters which are available to rent for short periods of time through their mobile application.
To rent a scooter the user first scans a QR code (or inputs a code) found on the scooter with the Bird app. Once the user has scanned the scooter they are free to drive it. Once they've taken the scooter to their destination they end their ride which locks the scooter until it is rented again. This writeup describes the analysis of Birds Android app.
Analyzing the Bird App involved installing it from the Google Playstore on a rooted device. The device was then connected through a SSL-intercepting web debugger to the Internet and the Bird servers. Finally a geo-spoofing tool was installed on the device which allowed the device to pretend to be in different locations around the world. LA, Calgary, and the San Fransisco Bay Area were selected as test locations due to their large Bird presence.
Bird Scooters available while geo-spoofing in LA, Calgary, and the San Fransisco Bay Area
The Bird application lent itself well to analysis as it had minimal defense measures implemented to prevent abnormal connections. Initially, the device experienced issues connecting to the Bird servers as Cloudflare detected and reset connections from a VPN. Once the VPN connection was removed there were no other measures, such as certificate pinning, to prevent abnormal connections and made analyzing the API significantly easier.
Once connected, the analysis began by geo-spoofing the device's location to Calgary where requests to the API were observed retrieving information about nearby scooters. Whenever a scooter is selected, a request is made to the endpoint "birdapp.com/bird/chirp" which retrieves detailed information about the scooter. The "chirp" endpoint request is made with a parameter "alarm" set to false.
Replaying this request with the parameter set to true will cause the Bird alarm to go off, and is designed to assist users in locating a nearby scooters. A subscriber of The App Analyst assisted by going to a location in Calgary to record as alarms were programatically triggered through the Bird API. Using this API one could imagine that entire cities of Bird scooters could be set off at once.
Bird Scooter having it's alarm triggered through the API
Ride from anywhere
The detailed information returned from the "chirp" endpoint also contained a code associated with the Bird Scooter. This code is equivalent to the QR code which is physically located on the scooter. This QR code could be seen as a form of 2-factor authentication as it is required when reserving the scooter to ensure the user is physically there.
When reserving the scooter a user can opt to input this code instead of scanning the scooters QR code. This allows a user to remotely reserve Bird Scooters by sending a request to the "scan" API endpoint with the code returned from the "chirp" endpoint response. This effectively defeats the implied 2-factor authentication.
Leveraging code from "chirp" API response to remotely ride a Bird Scooter
Weak physical locks
The "scan" endpoint returns further detailed information about the scooter. This response contains details about the physical lock which is used to secure the scooter. These details include the locks "pin", "serial_number", "mac_address", and more. These locks are produced by Nokelock, who have been shown to produce locks which have been susceptible to bluetooth attacks.
Another interesting note is that the serial number is provided in the response, in other models of locks produced by Nokelock this serial number is used to gain ownership of the lock from the Nokelock app. Revealing this serial number could potentially allow for the mass takeover of physical locks used by Bird to secure their scooters.
Physical Bird Scooter locks created by Nokelock
Disclosure: Bird was made aware of the issues found October 2nd and "will not trigger any new changes" based on the findings.
Bird is generally a safe application to install on a device, they don't appear to do anything with user data that is inappropriate. The issue with Bird comes with the amount of scooter data that they reveal. It's understandable that Bird would consider this data hidden to the end-user as it's not shown in the app, however anyone savvy with burp-suite or an equivalent tool has a great deal of information provided to them. Bird would do well to implement certificate-pinning to raise the barrier of entry to accessing their API from the app. That being said, recommendations to Bird to increase their security posture are as follows:
- Remove the scooter's code from the response to requests made to the "chirp" endpoint (and any other response for that matter). This code can be leveraged to remotely "scan" the scooters QR code and reserve it, potentially allowing for mass fraudulent reservation of Bird scooters. As this code is also a form of 2-factor authentication that the rider is physically present it may also facilitate a remote actor from attacking a scooter while in use, this is yet to be seen but would not be outside the realm of possibility.
- Secondly Bird should reduce the total amount of data returned to the application to the minimal set required for it's functionality. There appears to be quite a bit returned from the scooter such as statistics, damage, and physical lock information.
Electric scooters are a growing mode of transportation in urban environments. These scooters are Internet connected and allow a certain level of remote control. Companies such as Bird and Lime should be ensuring their applications and APIs are secure as possible, riders should be aware that they are riding what is in essence IoT device.