Hi all, I’m steam
Some time ago I’ve come across some research that has been done on our digital transport infrastructure and here I would like to share some insights that could be developed by you to understand such protocols and their security. I leave to the reader the most important task: think carefully about whether these facilities around you are managed well, ethically speaking. This case of study will provide some general tools to analyze and eventually screw up some bad guys.
I know this could just lead to some more protected protocols developed by the same folks but that’s why we should suggest an alternative: exploit the discovered weaknesses to put the focus on our alternatives and try to avoid an endless attack and defense loop.
So let’s dive into our first case of study: bike sharing.
Some time ago we surely have noticed the increasing number of electronic devices such as electric bikes, scooters and even cars. Usually the user can ride one of these shared vehicles by downloading an app and paying a fee. This is a great opportunity to switch to a more sustainable way of moving but we have to interrogate ourselves in order to check the genuineness of such transports, the entity that advertises such models has to be coherent with its choices, providing it with an affordable price, avoiding the private agencies that aim to make money out of it and understand whether it’s just a greenwashing cover.
Ok, I wanted to point out these small but important considerations to make evident my reasons.
In the links page you will find some references to some projects, tools and ideas.
One standard scheme is
BIKE <——– BLE ——-> APP(phone) <—– HTTP —–> SERVER
sometimes the server can even communicate directly to the bikes if these are provided with a sim card and an internet connection
BIKE <——– BLE ——-> APP(phone) <—– HTTP —–> SERVER
| |
|___________________ HTTP_____________________|
In this second scenario the bikes can be tracked down and you have to be cautious. Maybe you might want to extract the firmware and analyze how the device communicates directly with servers since intercepting 4G communication is pretty difficult. Getting the binaries probably involve some physical manumission and this is a different story and I’m not going to dive into that.
Here BLE stands for Bluetooth Low Control and HTTP are the API requests delivered on the internet.
We have almost full control on the Phone and therefore on the App, all the information that passes through here can be read, modified, blocked and analyzed as a man in the middle attack. I said almost because it can be tricky to gain that control but it’s feasible.
To discover some vulnerabilities in the protocols we have to understand it and I advise starting sniffing all the traffic between the APP and the SERVER. They’re much more readable than decompiling the app and read hundreds lines of Javascript…
The sniffed traffic could explain how the server processes the unlock requests, what data is involved in the unlocking/locking/time_used/bill_procedure since something has to be delivered to the server in order to register our payments, our trips…
You can spot the request for getting some bike information, location… and once you have the http request you can even script your actions with simple curl requests in your exploits.
One wonderful tool to do this is mitmproxy that allows you to set up a proxy to redirect all your traffic to and modify, intercept, block and read it.
BIKE<——–>APP(Phone)<———->mitmproxy<—————->SERVER
This would work straight if the calls were in clear http, but you will surely deal with https ones. Here I don’t want to explore the details of this protocol since I just want to provide you some tools, who wants can look it up and discover that apps won’t trust any proxy, but I think the skilled reader will know the details.
For this situation there are some workarounds but they require opening up the application and change some trusting policies inside, we have to add our mitmproxy certificate to be able to decrypt the https. There are some tools like Apktool that allow you to decompile the package, make the required changes and than build it up again. So there are several ways to avoid this certificate checking, some are even automated, just look them up in github ( certificate-pinning remover, android-unpinner…). Sometimes Apktool fails to rebuild the application and in this case Frida comes in help, look for some tutorials (Frida unpinner) on how to use this powerfull tool to sniff even the traffic of the hardest app (you will need to have the phone connected to the Computer as a downside, so maybe it will be harder to exploit some vulnerabilities that involve packet injection and modification since you will haven’t a remote proxy to filter the traffic wherever you are, you might want to create a specific app or modify the existing one but it will require much more effort).
Frida is a dynamic code instrumentation toolkit, it enables you to inject code into a binary during runtime, It can help with tracing APIs in an application, build a tool to evaluate performance or manipulate function calls, and no source code is needed! That’s why we don’t even have to modify the app itself.
As far as the Bluetooth part is concerned you can sniff the communication even without any specific device that can capture the air signal since on android you can enable the Bluetooth HCI snoop logs (under Developer Options) and open them in wireshark.
Once we have some ideas of how the protocol works we might outline some possible vulnerabilities and possible exploits:
App to bike
● Replaying of BLE messages from a previous session
● Sending of forged BLE messages
App to Server
● Interfering with API requests (e.g. blocking of
acknowledgement packet, etc.)
● Modifying API responses to enable certain features of
the app (client sided)
● Updating the server with fake location data (location spoofing)
● Sending lock API request directly after unlocking (minimum fee ride)
● Sending multiple API requests to the server containing random/malformed data
● Sending API requests that would trick the server into thinking the bike is faulty
● Sending API requests to reserve multiple bikes indefinitely
● Session Hijacking
Reader, this list can continue and if you’ll find some new approaches or techniques I’d be really interested in analyzing them in detail.
I’m aware I’ve omitted a lot of details and it won’t be easy to follow these instructions but remember that all the cases are different and these are suggestions, anyway I’m here to help if someone needs some specifics or wants to share his/her project or to investigate some vulnerabilities together.
Contact me in the discussion page.
PS If you think you need some privacy while texting in the discussion, consider using Tor: a powerful implementation of the onion routing scheme that provides anonymity, to a certain extent and if used well… but I think you know it pretty well.
