{"id":21688,"date":"2018-08-02T16:24:30","date_gmt":"2018-08-02T16:24:30","guid":{"rendered":"http:\/\/ci027cfe79d0022697"},"modified":"2018-08-02T16:24:30","modified_gmt":"2018-08-02T16:24:30","slug":"audits-and-quality-assurance-patching-holes-smart-contract-security","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/culture\/audits-and-quality-assurance-patching-holes-smart-contract-security","title":{"rendered":"Audits and Quality Assurance: Patching the Holes in Smart Contract Security"},"content":{"rendered":"
<\/div>
<\/figure>\n

On July 10, 2018, news broke that cryptocurrency wallet and decentralized exchange Bancor was hit with a hack<\/a>. A wallet the Bancor team used to update the protocol\u2019s smart contracts was infiltrated, and the $23.5 million vulnerability allowed the hackers to run off with $12.5 million ETH, $1 million NPXS tokens and $10 million of Bancor\u2019s BNT token.<\/p>\n

Following the hack, the Bancor team froze the BNT in question in an effort to stanch its losses.<\/p>\n

The latest of its kind, the attack is an unfortunate reminder that smart contracts are not foolproof. Even built as they are on the blockchain\u2019s security intensive network, they can feature bugs, backdoors and vulnerabilities that are ripe for exploitation.<\/p>\n

Before Bancor, we saw the popular Ethereum wallet Parity<\/a> drained of 150,000 ETH (now worth just over $68 million) in July of 2017. In November of the same year, Parity lost even more than this when a less-experienced coder accidentally froze some $153 million worth of ether and other tokens.<\/p>\n

In perhaps the most infamous smart contract hack in the industry to date, The DAO, a decentralized venture fund, lost 3.6 million ether in June of 2016. The stolen funds are now worth $1.6 billion, and the fallout of the attack saw Ethereum hard fork to recoup losses.<\/p>\n

The Why and How: Making the Same Mistake<\/h3>\n

If three\u2019s company, then The DAO, Parity and now Bancor have become the poster triplets of smart contract vulnerabilities. But they\u2019re not alone in their weakness, and similar smart contract bugs have been exploited or nearly exploited on other networks<\/a>.<\/p>\n

For such a nascent technology, such flaws may be expected, but given the mass sum of funds these contracts are supposed to protect, truly stalwart security measures are not yet routinely employed.<\/p>\n

To Hartej Sawhney, co-founder of Hosho<\/a> cybersecurity firm, the sheer amount of funds at stake is enough of an incentive to attract black hats to these smart contracts, especially if there\u2019s a central point through which they can probe for access.<\/p>\n

\u201cThere\u2019s money behind every smart contract, so there\u2019s an incentive to hack into it. And the scary part of smart contracts like Bancor is that they\u2019ve coded their smart contracts in a way that gives centralized power to the founders of the project. They\u2019ve put this backdoor in there,\u201d Sawhney told Bitcoin Magazine<\/em> in an interview.<\/p>\n

Sawhney is referring to Bancor\u2019s ability to confiscate and freeze tokens at will, as the smart contracts that govern their wallet and exchange feature central points of control. This degree of control has been widely criticized as centralized to the point that Bancor shouldn\u2019t be able to advertise itself as a decentralized exchange.<\/p>\n

And it may have even provided the hackers with an entry point into the network. While Bancor has not revealed the specifics of the hack and its execution, the team wrote in a blog post that \u201ca wallet used to upgrade some smart contracts was compromised.\u201d Sawhney indicated in our interview that \u201cmost smart contracts are coded to be irreversible,\u201d while Bancor\u2019s own are completely mutable. The hackers could have exploited \u2014 and likely did exploit \u2014 the same backdoor that the developers put into place to manage their project.<\/p>\n

Bancor aside, Dmytro Budorin, CEO of cybersecurity community Hacken<\/a>, echoed Sawhney\u2019s belief that the industry\u2019s treasure trove of assets is a powerful impetus for hackers to dirty their hands. He also believes that the relative youth of the technology makes it vulnerable to detrimental exploits.<\/p>\n

\u201cCoding on blockchain is something new,\u201d Budorin added in an interview with Bitcoin Magazine<\/em>. \u201cWe still lack security standards and best practices on how to properly code smart contracts. Also, when coding smart contracts, programmers think more about functionality than about security, since a programmer\u2019s main task is to simply make the code work, and security is usually an afterthought.\u201d<\/p>\n

Working with new programming languages, security can take a back seat to functionality. More than just the casualty of a steep learning curve, Sawhney believes that security can slip by the eye of software engineers because they \u201cdon\u2019t have a quality assurance (QA) mindset.\u201d<\/p>\n

With millions at stake and potential holes in the code to exploit, hackers are bound to drum up a scheme to breach these contracts, according to Budorin. Even if a team has audited their code for expected or known vulnerabilities, \u201ca new type of attack can be developed any time and nothing can protect you from this.\u201d<\/p>\n

All it takes is a spurt of intuitive thinking to probe a smart contract\u2019s code for an unexplored opening, Amy Wan, CEO and co-founder of Sagewise<\/a>, iterated in a separate interview with Bitcoin Magazine<\/em>.<\/p>\n

\u201cIt is not often that developers are able to write perfect code that works the first time around \u2014 and even when that happens the code cannot be adapted to unforeseen situations. Code is also static, which makes smart contracts very rigid. However, humans are anything but static and very creative when it comes to problem solving. This combination creates something of a perfect storm, making smart contracts ill-suited where there are bugs in coding or loopholes\/situation changes.\u201d<\/p>\n

Wan believes that \u201ctechnology isn’t about tech itself as much as it is about how humans interact with it,\u201d meaning that we \u201care always going to have folks looking for opportunities to test the shortcomings of technology, which may result in hacks.\u201d<\/p>\n

To Wan, smart contracts feature intrinsic vulnerabilities. To make security matters worse, she also holds that they \u201ccannot be amended or terminated (or in technologist speak, evolved or upgraded),\u201d and their static nature renders them susceptible to the dynamic, adaptive strategies of black hats.<\/p>\n

\u201cCode aside, with every situation, there are an infinite number of things that can go awry. The rigidity of smart contracts presently cannot accommodate the fluidity of the real world,\u201d she said.<\/p>\n

Mending the Achilles Heel<\/h3>\n

If technical flexibility is the crux of smart contract weakness, then the fix is in the inception and carry-through of their development. Developers should put preventative measures in place to ensure that their code can bend without breaking, the CEOs expressed.<\/p>\n

\u201cWe need to have a more comprehensive approach in order to solve this problem in the long term,\u201d Budorin argued. \u201cFirst of all, even though it is impossible to make all contracts absolutely secure, smart contract risks can be reduced. The best way to secure a smart contract is to have a security engineer on staff, conduct two different independent audits, and launch a bug bounty program for a dedicated period of time before deployment.\u201d<\/p>\n

Hacken itself facilitates such bug bounties, and the platform, called HackenProof, has seen its white hat community audit and test such industry projects as VeChainThor, Neverdie, Legolas Exchange, NapoleonX, Shopin and Enecuum. Budorin and his team find that bug bounties provide a reliable if tertiary buffer for projects before they go public.<\/p>\n

\u201cWe believe that the only efficient way to mitigate modern cybersecurity threats is to host bug bounty programs on bug bounty platforms. This is called a crowdsourced security approach,\u201d Budorin explained.<\/p>\n

\u201cBug bounty platforms attract a crowd of third-party cybersecurity experts (dozens if not hundreds at a time) to test the client\u2019s software. Testing can be ongoing for months or even years.\u201d<\/p>\n

Sawhney agrees that projects need to house more on-staff security experts to police vulnerabilities, while lamenting the fact that some projects lack a CIO or CTO for this effect. But he also indicated that, in some cases, companies need only to submit themselves to a proper audit to avoid a fate similar to Bancor\u2019s.<\/p>\n

\u201cSome of these companies believe that they have the world\u2019s best engineers, so they think they don\u2019t need an audit. And if they get one, chances are they\u2019ve done a third-party audit that was in their favor. Even if they\u2019re getting an audit, some of these audit companies aren\u2019t doing what we deem to be a professional audit. They\u2019re taking the code and putting it through automated tooling. They\u2019re not taking the time to do some of the more manual tasks which includes a dynamic analysis, quality assurance,\u201d he explained.<\/p>\n

The manual tasks that Sawhney lauds are at the heart of Hosho\u2019s own auditing processes. They allow Hosho\u2019s team to sniff out coding errors that automated tooling might miss, like discrepancies between the smart contract\u2019s token algorithms and a white paper\u2019s business model.<\/p>\n

\u201cSo the most manual part of conducting an audit is marrying the code to the words \u2014 we call it dynamic analysis. Most of the time when we find errors with a smart contract, we\u2019re finding colossal errors in the business logic. We\u2019re finding everything from mathematical errors to errors in token allocation,\u201d Sawhney said.<\/p>\n

He went on to reveal that Hosho\u2019s team includes professionals \u201cfrom the infosec, defcon communities that are white hats who have spent years doing QA.\u201d QA, shorthand for quality assurance, is a method by which coders test a code for its designed function to check for any malfunctions, defects and other flaws that may render it vulnerable or inoperable.<\/p>\n

As Sawhney indicated earlier, part of the reason these projects and their auditors don\u2019t do QA is simply because they lack the professional experience to do so. It\u2019s easier, he claimed, to teach Solidity (a smart contract coding language) to those who know how to conduct sound QA than the other way around.<\/p>\n

When lack of QA training or a learning curve isn\u2019t the issue, however, Sawhney suggested that, at times, projects won\u2019t secure a thorough audit because they\u2019re simply cutting corners.<\/p>\n

\u201cSometimes I think it\u2019s sheer laziness and being cheap. They see that cost to code a smart contract was only $10k and [an auditor] is charging $30k to review it. They say, \u2018Nah, we don\u2019t need that. We have the best engineers in the world so we\u2019re good.\u2019\u201d<\/p>\n

To Sawhney, there\u2019s no substitute for a thorough audit. He also holds that, once an audit has been completed, the smart contract should come with a seal of approval, one that both attests to the audit\u2019s quality and reassures users that no code has been altered after the fact. For Hosho\u2019s work, this comes in the form of a GPG file, a cryptographic stamp that simultaneously functions like a certificate of authenticity and denotes the final (or at least most recent) version of audited code, acting rather like the seal on a bottle of cough syrup that proves it hasn\u2019t been tampered with since it last passed quality control.<\/p>\n

\u201cHaving central governments, regulators, lawyers, PR firms, investors, token holders \u2014 everyone \u2014 looking for this GPG file, this sign of approval [answers the question]: Has this code been sealed? Because we can monitor this code once we\u2019ve put this seal on it to prove that no one has touched this code, not one line of this code has been changed since a third party audited it. If code changes you\u2019re opening up room for security vulnerabilities.\u201d<\/p>\n

Wan\u2019s own solution offers a different sort of prescription, in that she adds post-audit safety nets like Sagewise\u2019s software as a smart contract\u2019s third line of defense.<\/p>\n

\u201cGoing forward, I believe that blockchain companies will be able to prevent smart contract disasters by using a smart contract developer whose sole focus is developing smart contracts, hiring a reputable security auditing firm, and including a catch-all safety net into smart contracts, such as Sagewise’s SDK.\u201d<\/p>\n

The Sagewise SDK integrates with smart contracts to police malicious inputs. It gives developers the chance to freeze the smart contract in question and adjust it accordingly.<\/p>\n

\u201cIt starts with a monitoring and notification service so users are aware of what’s happening with their smart contract. Paired with our SDK, which basically acts as an arbitration clause in code, users are notified of functions executing on their smart contract and, if such functions are unintended, [they have] the ability to freeze the smart contract. They then can take the time they need to fix whatever needs to be fixed, whether that’s merely fixing a coding error to amending the smart contract or resolving a dispute,\u201d she said.<\/p>\n

A Community Problem, a Community Solution<\/h3>\n

In our interview, Wan claimed that \u201c[less than] 2 percent of the population is able to read code.\u201d Fewer people still are able to read Solidity, let alone at the level needed to insulate it with airtight security features.<\/p>\n

So even if projects and companies want to take the measures necessary to vet and protect their code properly, they may be wanting for talent and resources. This problem will likely be educated out of existence as more software engineers develop a thorough, more sophisticated understanding of Solidity and other smart contract programming languages. More mature coding languages may present a solution to this ailment, as well.<\/p>\n

But for the time being, the community can help developers and teams to err on the side of caution. Like an arbiter with skin in the game, people using these services need to step up and demand action and change, Wan believes. Otherwise these types of security breaches will continue to happen.<\/p>\n

\u201c[B]ecause much of the population cannot read code, it is difficult for them to hold developers accountable for when they do things like code an administrative backdoor into their smart contract (which many large projects have done),\u201d said Wan.<\/p>\n

\u201cJust in 2017 alone, half a billion dollars in value was lost in smart contracts, but that apparently has not been enough to get developers to consider adding additional safety nets or community members to demand them. Perhaps we will need to lose billions more to get people to realize that this isn’t how the system should work.\u201d<\/p>\n

Sawhney also reiterated this point: \u201c[More] people need to be outspoken, call people out. I think people are scared because the community is tight-knit and everybody knows everybody. No one wants to shun people. There\u2019s not enough self-governance in this space, and I think that\u2019s the biggest step this community needs to take.\u201d<\/p>\n

He added, \u201c[not] enough pressure [is] being put on security; there\u2019s not enough regulation around security.\u201d<\/p>\n

In an effort to bring self-regulation to the forefront of the industry\u2019s to do list, Hosho will partake in a summit for cybersecurity firms in Berlin. Slated for this September, Sawhney hopes that ETHBerlin<\/a> will spawn a self-regulatory organization (SRO) from its attendence, \u201ccomplete with a certificate for our work, kind of like the Big Four for financial audits.\u201d<\/p>\n

Adding to the conversation on self-regulation, Budorin finds that the community would do well to document exploited vulnerabilities. This would create a library of case studies and situations for developers to study and to create the solutions necessary to avoid the same pitfalls in the future.<\/p>\n

\u201c…the blockchain community needs to collect, store and analyze all known vulnerabilities that have been found in smart contracts and host regular security conferences that will cover security issues in blockchain and develop security guidelines so that new generation of blockchain programmers is more prepared for these problems,\u201d he said.<\/p>\n

Both Hacken and Hosho are answering Budorin’s call for security-centric conferences. Hacken is hosting HackIT<\/a> from October 8-11, a cybersecurity conference that “is all about bringing hackers and [the] crypto community together.” In the same vein and in the same month, Hosho will host HoshoCon<\/a>, one of the first conferences to focus on blockchain cybersecurity. From October 9-11, 2018, community members will come together in Las Vegas, Nevada to listen to, learn from and discuss with each other what the industry could be doing better to bolster its security. <\/p>\n

While working toward proper security is a community effort, the onus is not on the community alone, as the lion\u2019s share of responsibility rests on developers to ensure that their code is as sound as possible before reaching an audience. Together, however, the industry\u2019s community and its architects may combine perspectives to make smart contract hazards an issue of yesterdays.<\/p>\n

Until then, Sawhney, Budorin and Wan\u2019s perspectives \u2014 and their respective companies\u2019 purposes \u2014 provide a healthy reality check for the industry\u2019s pain points. For mainstream adoption and acceptance, these points need be addressed if there is to be any sort of sustained sense of confidence in this new technology.<\/p>\n","protected":false},"excerpt":{"rendered":"

“Code aside, with every situation, there are an infinite number of things that can go awry.” It’s time to demand higher standards when it comes to smart contract security.<\/p>\n","protected":false},"author":3468,"featured_media":21689,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[33],"tags":[2500,3388,2606,1279],"class_list":{"0":"post-21688","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-culture","8":"tag-audit","9":"tag-bancor","10":"tag-hacks","11":"tag-smart-contracts"},"author_data":{"id":3468,"name":"Aaron Van Wirdum And Colin Harper","nicename":"aaron-van-wirdum-and-colin-harper","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/88b6c65a7515990786b1c04473e15469e5b0d0fffef947ed629a60854e1cb426?s=96&d=robohash&r=g"},"featured_image_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/11\/audits-and-quality-assurance-patching-the-holes-in-smart-contract-security.jpg","_links":{"self":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/21688","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/users\/3468"}],"replies":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/comments?post=21688"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/21688\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media\/21689"}],"wp:attachment":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media?parent=21688"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=21688"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=21688"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}