In this post, I'll dive into a comprehensive overview about the results of a research about security vulnerabilities found in some Launchpad Applications. The purpose of this research was to investigate these applications' security, vulnerabilities, and potential for exploitation. The findings dissected here aim to shed light on existing weaknesses, propose solutions for those vulnerabilities, and promote further advancements in this crucial aspect of cybersecurity.
It's important to mention that all vulnerabilities described here, were found inside the Web Applications of the Launchpad Platforms, not in the Smart Contracts.
All the platforms here were contacted to receive the reports to fix the vulnerabilities found. Some of them accepted the report / help to fix and paid a bounty.
Finally I decided to publish this research :) (It was done in ~2021)
Initial DEX Offering (IDO) platforms, also known as launchpad applications, are platforms in the cryptocurrency world that offer a decentralized form of conducting an Initial Coin Offering (ICO). These platforms allow projects to raise capital by issuing tokens in exchange for existing cryptocurrencies. Here are some key features of IDO platforms: 1. Decentralization: Unlike traditional fundraising methods, like IPOs or even ICOs, IDOs operate on decentralized exchanges (DEX), eliminating the need for intermediaries such as banks or venture capitalists. 2. Liquidity: As soon as the tokens are listed on the DEX after the IDO, they become available for trading, providing immediate liquidity. 3. Access and Participation: IDO platforms often provide opportunities to a wider range of individuals to participate in the token sales as there are typically lower barriers to entry compared to other methods.
Some popular IDO platforms include Polkastarter, Seedify, Uniswap, SushiSwap, and PancakeSwap, among others. Each of these platforms operates on different blockchains like Ethereum or Binance Smart Chain and may have their own unique mechanisms for users to participate in IDOs.
During the research, approximately 18 launchpads were analyzed, however, in this post I'll show only the targets with highest impact.
The table below contains all tested Launchpads during the research, it lists vulnerabilities and potential for funds to be stolen for various Launchpad applications. The vulnerabilities includes IDOs modification, authentication bypass, and access to administrative panels, which could allow for funds to be stolen.
This section will shows an overview that outlines all the steps undertaken and the vulnerabilities discovered in some launchpads.
The chosen targets to describe the vulnerabilities were: TrustPad, PlayPad, GamiWorld, DaoLaunch and Seedify.
So let's stop to talking and let's hack the targets :D
"TrustPad is the #1 multi-chain launchpad enabling projects to raise capital and promise safety to early stage investors. Stake TrustPad tokens ($TPAD) to get early-access to top-tier projects." - TrustPad
Basically, when looking at the source code of the application and accessing the _buildManifest.js file, all platform routes were available, including one in particular /pool/super-secret-krya that was accessible.
Upon accessing, it was possible to obtain the information related to the available IDOs on the platform. However, there was only the possibility to read the information, since all control is done through smart contracts.
This "misconfiguration" has been properly reported to the team and rewarded with a bounty :)
"The ultimate choice of crypto investors to invest in high quality blockchain projects: The fastest and the most cost effective way of investing in crypto." - IQZone
Following the same previous methodology, when looking at the available routes in the _buildManifest.js file, several interesting routes were available, such as /admin.
Upon accessing the page's source code, I noticed a hardcoded address being used in a comparison within the JavaScript.
This address was being used to verify if the wallet connected to the platform's website is the admin account. With the help of Burpsuite, through a match & replace rule, it was possible to bypass the verification and gain access to the administrative panel.
With access to the administrative panel, it was possible to change all the information related to the IDOs that were available on the platform, as demonstrated below:
Above, I made a simple modification to the project description. When saving and updating the project page, the modification was carried out successfully:
It is important to make it clear that the team was contacted, however, they were not interested in paying any type of bounty and after a certain period of time, the error was corrected.
"GAMI World is a modular blockchain platform consisting of multiple DeFi & web 3.0 products, which are forming GAMI World’s ecosystem." - GamiWorld
In this scenario, there were 2 vulnerabilities:
Users could increase their allocation amount
Users did not need to own the platform's tokens to obtain an allocation in a specific IDO
In the first case, a given user received an allocation value based on the number of platform tokens that the user had in stake.
In the following image, the request contains the allocation value that I had in the vestedAmount and StakedAmount parameters, in this case 587.5 and 587 respectively
The nonce and cryptCode parameters are calculated based on the wallet and the amount of tokens the user has, however, it is not validated if the Vested and Stake values in the back-end, resulting in the generation of the cryptoCode and nonce valid for values that are not match the number of tokens the user had.
To obtain a higher allocation value with the same number of tokens, the user was required to:
Generate the cryptCode and nonce based on the values he wanted
Send the request to the /Pool/Insert endpoint passing the previously generated values and the changed VestedAmount & StakedAmount values
In the following image, the same address as the first request, which had a value of 587.5, successfully obtained an allocation of 9000
After exploring, the user just needed to wait for the IDO to start and make their purchase on the modified allocation.
The second vulnerability was quite similar, with the difference that any user could obtain an allocation in any IDO WITHOUT OBTAINING ANY STAKE TOKEN FROM THE PLATFORM.
In the image below, the request sent came from an address that did not have any tokens from the platform in question in stake (nor in holding), however, its allocation of 26000 (maximum allocation allowed on the platform, in other words, the highest tier) was successfully carried out:
I've tried contact with the Team, however, didn't received any response back :/
"DAOLaunch is decentralized fundraising platform, we aims that anyone to seamlessly create and support new economic across borders, anyone branding themselves as Decentralized Venture Capital, obtain preferable investment conditions depending on their investment performance." - DaoLaunch
Not very different from the others, some very interesting routes were found when looking at the source code, among them some restricted only to Administrators:
When trying to directly access the above endpoints, there was a redirection to the home page due to the return of the isAdmin attribute returned when logging into the platform. This attribute/check was successfully bypassed after using a match & replace through Burpsuite, as shown below:
With access to the administrative panel, it was possible to modify all information related to IDOs and even the address where users would deposit the tokens at the time of purchase.
As an example, the information of the above token, which was already registered on the platform, was edited:
After the vulnerability was discovered, the team was contacted and the vulnerability was reported. However, it is important to make it clear that the bounty was not carried out as planned, as a "bounty table" was presented and the final payment was completely different.
The initial bounty table said the following:
However, when paying the bounty, the team decided to pay 5000 points ($5000) for the critical severity vulnerability, that is, according to the table that was shared, a vulnerability that directly allowed the diversion of its investors' funds was classified as average.
¯\_(ツ)_/¯
"Seedify is a blockchain gaming-focused incubator and launchpad ecosystem, empowering innovators and project developers." - Seedify.fund
Last but not least, we have Seedify. This was one of the platforms I enjoyed the most due to the impacts that could be made when exploiting the vulnerabilities.
Using the methodology that you are already tired of seeing in the post, the endpoints for administrative access had protection only on the client side that could be bypassed through burpsuite's match & replace:
With access to the administrative panel, it was possible to modify the IDO information, as well as the address that would receive users' funds, that is, it allowed attackers to divert users' tokens.
In the following example, the functionality was used to add new addresses to the whitelist that could be part of a given IDO:
The following image illustrates the project editing screen:
In addition to the vulnerability in the main web application, vulnerabilities were also found in the API that was responsible for managing users registered on the platform, administrators and even stake pools (yes, it was also possible to modify the addresses of the pools in which users would stake stake, allowing the diversion of tokens to a contract controlled by the attacker).
The following image illustrates the endpoint responsible for adding a new admin to the Seedify API. It can be noted that there is no protection for who can or cannot add new admins. With this, any user could send a request to the endpoint and register a new admin user in the API and perform all possible functions:
With this, it was possible to create a new Admin user in the API, as shown below:
After logging into the API and obtaining the authentication token, it was possible to perform any administrator action. In this example, a query was carried out to list all users registered on the platform, in which user data such as email, balance and wallet address was returned. In the second image, we can see a total of 3320 registered users:
After the vulnerabilities were discovered, the responsible team was contacted and the report was sent. In response, unlike other platforms, I received excellent feedback and a great bounty for the report :)
We reached the end of the post (finally) hahahaha.
This research really motivated me to study more about the Web3 and Blockchain world. I hope that future research will be much more productive and much more interesting.
I would like to thank everyone who reached the end of the post and I apologize if I said anything wrong (you can get in touch for suggestions and feedback, I would be grateful).
That's it folks! I hope you enjoyed the content and see you next time.
Valeu :]