Case Study: Hacken’s Audit of EBSI Smart Contracts
Hacken performed smart contract audits for the EBSI, contributing to the safety and reliability of digital public services across Europe
🇺🇦 Hacken stands with Ukraine!Learn more
As you may already know, last month HackenProof has hosted an onsite bug bounty marathon called Hacken Cup. We’ve invited 25 of our community members – a carefully selected group of some of the most talented hackers in the world to come to Ukraine and test 3 products: a local ridesharing service – Uklon, blockchain-based social and business communication network – Crypviser and an international social platform, that wished to remain anonymous. Previously, we’ve published a detailed overview of the event, and in this post, we are going to tell you about some of the vulnerabilities that hackers have found in Uklon during the event.
To give you a bit of perspective about the service – Uklon launched 8 years ago, as a student “pet project” by a 22-year-old Vitaliy Diatlenko. He was frustrated by the fact that he couldn’t order a taxi “online”. Since he was working at a company that was developing IT solutions for taxi companies – he was in a perfect environment to start.
Fast forward 8 years – Uklon is the largest ridesharing app in Ukraine with millions of downloads and hundreds of thousands of active users. The service itself is comprised of three main elements – a web application, Android and iOS apps.
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user.
The key problem in Uklon’s case was that the error message in case of a wrong address, which was displayed as an on-screen notification, contained user input almost “as is” without filtering special characters. (Screenshot 1). In this particular case, a low-level vulnerability (Self XSS) could be raised to a medium-level one (Reflected XSS).
The vulnerability allowed the attacker to:
Insecure Direct Object References, aka IDOR, occur when an application provides direct access to objects based on a user-supplied input.
In the case of Uklon, any user of the app or website could manipulate (edit, delete, upload) images or files of any driver within the Uklon database.
By entering a query:
It is possible to replace the driver’s avatar (with the type driveravatar and the unique identifier uid = 7890b85e-aa8c-4ae9-8e13-fbb1c30a1fc3).
Another IDOR allowed an imaginary attacker to change and/or delete user comments on their trips via Uklon’s app.
So in theory, a driver that uses Uklon (and knows how to exploit an IDOR) could replace all positive feedback about his competitor drivers with negative ones and vice versa, and replace all negative comments about himself with positive ones
This was feasible when replacing the ID with the ID of someone else’s comment. You may also notice that the ID is not unique, but a simple increment of a number. By sending this request with an ID increase of +1, we can delete all reviews of all drivers ID = 1 ID = 2 ID = 3 …
Other queries were also found:
– PUT / api / v1 / feedbacks – editing and creating comments from other users
– GET / api / v1 / drivers / f0994a5dbf5f4b58afd7fbf2a804765f / feedbacks – get feedback on other drivers (you need to know its ID)
Blind XSS is a type of XSS. It occurs when an attacker’s input is saved by the server and displayed in another part of the application or in another application. For example, an attacker injects a malicious payload into a contact/feedback page and when the administrator of an application is reviewing the feedback entries the attacker’s payload will be loaded. The attacker input can be executed in a completely different application (for example an internal application where the administrator reviews the access logs or the application exceptions).
The vulnerability was present in two parameters (Name of the passenger and in the comments to the payment). In the user and driver interface, special characters were filtered and the vulnerability did not work, but this did not happen in the administrator interface, as a result, an arbitrary js code could be executed. As seen in the screenshot, an attacker could track other people’s orders, phone numbers, ip-addresses, and other useful information.
This vulnerability allowed an attacker to:
We’d like to add that this vulnerability could potentially lead to even greater losses for Uklon, but this would have been a direct breach. So, in the real world, this vulnerability could have lead to significant losses.
The Vulnerability has been found by Arbin
At the end of the day, hackers managed to submit 74 reports. Uklon Founder and CTO, Vitaliy Diatlenko has been shocked by the results:
“We have been genuinely surprised by the amount of work hackers have managed to do in a single day. Throughout the whole day, Uklon’s technical team have been discussing reported vulnerabilities with hackers that were present at the event, which helped us a lot in seeing things “through hackers’ eyes”.
I think that Bug Bounty Programs are a great and cost-efficient way to strengthen security for large and mature companies. Thanks to HackenProof, our product is now more secure, hence we are able to deliver better services to our customers, which is what we are always aiming to do. It’s been a great decision for Uklon to participate in an onsite bug bounty marathon.”
As a bug bounty platform, it’s very important for us to deliver tangible results to our clients. We understand that the more vulnerabilities our community of ethical hackers find, the less there is left for cybercriminals to exploit.
Bug Bounty marathons are an excellent way to extensively test products in a short period of time. In addition, it gives companies a unique opportunity to talk to hackers and understand how they think when planning their attacks.
At the same time, it is important to understand that cybersecurity is a continuous problem, not a discrete one. Participating in one bug bounty marathon does not mean that your product will never ever be hacked.
It’s important to remember to follow the best practices for developing secure products:
– Implement Secure Software Development Lifecycle
– Conduct regular pentests
– Publish a Vulnerability Disclosure Policy on your site or host bug bounty programs.
We are always happy to talk to companies that want to learn how a crowdsourced security approach can help their businesses increase the security of their products.