The recent Poly Network inter-chain hack, including Ethereum, Binance Smart Chain, and Polygon, has caused a lot of hype as the hacker returned the stolen funds.

The longer the story goes on, the more details and speculation about the hacker’s true motives appear.

If you take a closer look at this event, you may wonder whether this was attack fully implemented by outsiders.

The Poly Network hack happened through a vulnerability exploit in the interchain bridges built by Poly Network. This has been provided in the report by cybersecurity firm SlowMist.

The BlockSec cybersecurity firm has offered a version of the hack. In this version, the hacker got hold of a key that enabled him to sign cross-chain transactions using the Poly Network bridges. Otherwise, he found a bug in Poly Network’s smart contract that allowed him to generate his own transactions.

Both such exploits would be very hard to find for both hackers and auditors. Evidently, the auditors did not find the exploit. So it opens up for us a possibility of doubt regarding an outside hacker.

Also, you have to factor in the PR effect that the news has caused. This makes me consider the possibility that it was a PR exercise by the company.

However, the “real hacker” scenario is still relevant down to a few facts. The hacker decided to return the funds. This was after the information relating to the hacker’s IP address and the client’s verified address on the China-based cryptocurrency exchange Hoo.com appeared on Twitter.

Before the attack, the hacker withdrew 0.47 ETH from it to pay for the gas fees on the transactions. The exchange was able to register the email and the IP address used by the hacker.

So, threatened by criminal prosecution, the hacker decided to return the stolen funds to avoid indictment. However, that looks rather doubtful, as the hacker used numerous anonymization instruments. This was also in his response to the SlowMist report.

Also, it’s worth noting that the attacker sent some of the stolen funds into an Ellipsis Finance liquidity pool. This might have already brought him a decent profit, making the rest of the funds not worth the risk.

The major reason behind the hacks is the use of new programming languages that many blockchain developers are not entirely familiar with, for example, the Solidity programming language.

However, the biggest burden lies with the architectural characteristics of smart contracts that create the biggest security threat to decentralized finance in particular.

Also, the number of security staff is obviously insufficient in most blockchain startups. Some of them do not even bother doing a proper audit on their tech.

Meanwhile, as the industry grows, so does the number of geeks who study the tech. The difference in numbers is often in favor of the geeks who, once united in a group, can cause massive jeopardy to a few thousand hardworking people across the industry.

The more the industry grows, the more vulnerabilities there will be as long as the situation with security in the industry remains as it is now.

First and foremost, more attention should go to the security of smart contracts. Most often, successful hacking attacks happen on smart contracts that have not been properly audited.

Only a systemic approach to the security of blockchain projects could allow DeFi to scale. That includes audits done by professionals and following security protocols inside the business.

Talking about tackling the architectural risks, the modular approach could be a good solution to the problem. The good thing about modular development is that it is like building a local network using blade systems that can be replaced without shutting down the whole unit they work in.

You can replace the server without compromising the work of the local network. So you can rebuild a module without compromising the work of the rest of your technology stack.

The example of Poly Network is not unique, any project that works with huge amounts of money has to go through countless code checks, and it is always best to use the service of several auditors rather than one, however good and professional they might be.

Double-checking should be a guiding principle in this respect. Secondly, the project should not be released in a rush because the price of a mistake in an unalterable code is too high. Even if some of the release dates have to shift, it is better to do so than run the risk of releasing a product you do not have full confidence in.

Both these tactics could substantially lower the controllable and non-influenceable risks.

This may be a third-party hacker attack or an insider who decided to cause hype around the project. Currently, it is unlikely that we will know the truth until the company reveals its results.

However, if it were an attack pulled by the company for the sake of public attention, it would be silly to expect them to come clean as it might incur very serious consequences for all of its executive managers.

The truth of the story is that the security problem needs to be seriously addressed. As long as it is not, we are going to see more headlines about epic thefts surfacing in the cryptocurrency media.

The post Poly Network Hack — Reconsidering the ‘Real Hacker’ Scenario appeared first on BeInCrypto.

Similar to Notcoin - Blum - Airdrops In 2024

origin »

202 +