How we work with Security Research Labs to keep peaq secure

In a nutshell: To keep peaq safe, we are working with Security Research Labs, which includes them doing regular assessments of our Agung network network with an automated tool. After a September review revealed a vulnerability that could have allowed malicious actors disrupt the network, we fixed it by implementing a new framework for handling network fees more effectively. We will continue to work with SRLabs to keep peaq as secure as possible.

‍

Only in Q3 this year, hackers and scammers got their hands on some $428 million worth of tokens, according to Immunefi, which should tell you just enough about why security shouldn’t be an afterthought for anyone in Web3. Least of all, for developers, we should add. As sympathetic we are to individual users who got phished out of their private keys — we feel you, it sucks, and we hope the people who did it will get what they deserve from both the cops and the karma — an error in the code can give hackers exponentially more room for profit at everyone’s expense. In Web3, code is the law, and you don’t want the Constitution to say that someone can just steal your hard-earned money.

We are very much aware of all this, which is why we are working with Security Research Labs, a leading IT security consultancy, to keep peaq as rock-solid as possible. This collaboration sees SRLabs conduct regular security assessments of our network using their semi-automated tools. After each assessment, we get a report with the findings and take action to eliminate whatever bugs and vulnerabilities they find. Just to be clear, the assessment is focused on Agung, our standalone testnet, but fixing errors there means they won’t be replicated on our other networks. Here is what the entire process usually looks like.

In September, SRLabs found a vulnerability on Agung that had to do with weights assigned to several extrinsics (or functions, as they also say, these are blocks of code that are executed when called) on Agung. You can find more information in the report here, but the bottomline is this: a bunch of extrinsics in our code came with default weights. Weights are assigned to extrinsics to calculate the network fee for executing the specific blocks of code and must depend on how much computational power each extrinsic requires. This was not the case with some of the extrinsics on Agung. This vulnerability had the potential to enable a malicious actor to cause network disruptions and time-outs by overwhelming it with extrinsics calls.

To fix the issue, we used a Substrate benchmark framework which changes the way Agung assigns weights to extrinsics. With the fix in place, this is done automatically, in a dynamic manner which assigns weights to extrinsics based on how much workload they would put on the network. As a result, trying to overwhelm peaq with a flurry of extrinsics calls will now come at a hefty price tag set to discourage most prospective attackers. 

While the update makes Agung and, by extension, peaq more secure, there is always room for another unknown attack vector that’s not on our radars yet. For this reason, we will continue to work with SRLabs and will make sure to patch every vulnerability they find moving forward to the best of our ability.

‍

Want to help us make peaq even better?

We’re hiring across the board, from engineering to communications. Join us in building the Economy of Things.

Are you interested in building a dApp for vehicles, robots, devices and other machines? Get inspired, get funded, and start building today.

Want to stay in the loop? Visit our website and join the conversation on our channels.