Researchers: Last Year’s ICOs Had Five Security Vulnerabilities on Average | Hacker News Reader

Researchers: Last Year’s ICOs Had Five Security Vulnerabilities on Average

bleepingcomputer.com

100 pointsmikece39 comments

It's a pretty interesting topic/field to get in if you're a security researcher, just because everyone is starting from zero and a lot of vulnerabilities are quite surprising.

If you're interested we've made a TOP 10 of issues with smart contracts here: https://www.dasp.co

    and also failed to register all versions of an ICO domain

Surely that's just not feasible these days with the massive amount of TLD's available.

I've been in businesses that wanted to own domain.com, domain.net, domain.org, domain.co.uk, domain.com.au, et al and it was a "vulnerability" if you missed one. But with hundreds of TLDs and some costing hundreds of dollars a registration, this has to be seen as a lost battle.

Doing the top 3-5 should be trivial though. Some just have those oddball tlds (ie, bloc.kcha.in or whatever) and nothing else

Correct. Heres a full list https://en.wikipedia.org/wiki/List_of_Internet_top-level_dom...

What's the difference between a token and a receipt? without legal obligation, it seems that what you're getting is a proof of purchase.

So far, we have a long way to go to build higher quality code. There's a few reasons:

1. Blockchain smart contracts are often unchangeable, so you can't fix bugs

2. The language is being built as people write code, with some bad design choices that encourage mistakes (slowly being fixed)

3. Libraries are still being developed

4. Tooling is still limited (even basic linting)

5. People are not taking the time to have a beta process.

6. People prematurely optimize gas, at the cost of readability

(For non-Ethereum devs, here's a short tutorial for how the language works: https://learnxinyminutes.com/docs/solidity/ )

My own view is that you have to code expecting that things go wrong, and ensure that your logic survives inevitable mistakes ('resiliency').

There's a lot of great resources on security, for people interested in this space:

Ethereum Safety: https://github.com/ethereum/wiki/wiki/Safety

Decentralized Application Security Project: https://dasp.co/

Consensys Smart Contract Best Practice Guide (I helped coauthor this back in 2016 after the DAO): https://consensys.github.io/smart-contract-best-practices/

Hacking Distributed is a great blog for blockchain security:

http://hackingdistributed.com/

Emin and Phil Daian are great to follow on Twitter:

https://twitter.com/phildaian

https://twitter.com/el33th4xor

Audit Checklist (written by my team): https://github.com/cryptofinlabs/audit-checklist

(Disclosure: Our team does audits for a few projects: http://audit.cryptofin.io/index.html )

Feel free to add other resources to this thread. Imagine it'll be useful for everyone.

> Blockchain smart contracts are often unchangeable, so you can't fix bugs

This is the fatal flaw with smart contracts as a concept.

If they can be changed by the author then they don't provide the security guarantees that make the system worth using, but if they aren't changeable by the author then a huge fraction of smart contracts will ultimately end up doing something unintended because of any of the million reasons we don't normally expect first releases of alpha software to work perfectly in all circumstances.

In a perfect world Etherium would work great, but we don't live in a perfect world. People make mistakes. Any system which expects human input but isn't designed to gracefully handle human error (including the humans who programmed the system) is probably not going to end well.

Changed arbitrarily by the author and immutable are pretty clearly not the only two options. Ethereum lets you design whatever governance scheme you want. You can build a system in which people vote on upgrades, for instance. You can structure that scheme however you want. It's just plain lazy thinking to say "welp code imperfect, therefore we can never use it for important stuff".

Sure hope that system is bug-free.

Yep, it'll take time to converge on high assurance implementations of these schemes. But we will. It is possible to write bug free code, particularly for relatively well defined, small areas.

The whole idea behind smart contracts that code can be law is fatally flawed, because it is a bet on our ability to write bug-free code. We know from experience that this is virtually impossible, especially at large scale, even for the best people and organisations in the world.

This means this ultimately require some form of human arbiter to decide in cases like that, but this ultimately defeats the entire purpose of smart contracts.

Quite. This is a live topic for me. Wiser heads pointed me toward

https://medium.com/@jimmysong/the-truth-about-smart-contract...

when I had my own blockchain moment. I think that immutability and lack of human judgement limit the usefulness of these things. And of course, not everything needs decentralised.

It's worse than that because immutability and lack of human judgement is also the killer feature that smart contracts offer over good old fashioned paper contracts and binding arbitration agreements. Any attempt to make maintaining smart contracts manageable is almost by definition going to undercut one of the main rationales for wanting to use them in the first place.

> The whole idea behind smart contracts that code can be law is fatally flawed, because it is a bet on our ability to write bug-free code. We know from experience that this is virtually impossible, especially at large scale, even for the best people and organisations in the world.

You mean, except for the cases where we do exactly that? Like mars rovers, space shuttles, medical devices, IOT, etc...

Do you see blockchain developers doing the diligence that any random part of the space program does as a reflex?

Absolutely not. The state of blockchain development is shit. My point isn't that it's being done well. My point is that, in theory, it can be done well, and I believe that it can get there, and I think the end goal is worthwhile.

> My point is that, in theory, it can be done well, and I believe that it can get there,

You really mean that eventually smart contracts can be reliable, no bugs, etc? I've seen procurement sign contracts with various unclear wordings in them. I've seen vendors wrongly apply contracts in their rates. It's quite common to have errors in real world contracts. I fail to see how a smart contract would work especially as it's even more complicated.

Smart contracts will not replace complex traditional contracts. They will replace simple ones, especially at first. There will be issues at first, for sure. Over time people will iterate on them and there will be a library of well vetted, well understood, standardized contracts.

Also of note, smart contract does not necessarily mean no human intervention. A smart contract can appeal to an external and possibly human judge/arbitrator.

To assume those code bases don't contain bugs or go through multiple revisions and iterations is just naive. Just because bugs have not been exposed does not mean they are not present.

Smart contracts have people actively snooping and trying to exploit bugs for gain. Oh, and they are publicly accessible.

Also, IOT...pwned many times over ;)

> To assume those code bases don't contain bugs or go through multiple revisions and iterations is just naive.

To assume smart contracts don't go through multiple revisions is equally naive. Now we're arguing about implementation, anyway, which is not the point. Implementation and best practices can be iterated on. The fact that the ecosystem isn't mature yet isn't an argument against getting it there.

I think there's a difference between what you're saying (doing it right is possible) and what the critics are saying (doing it wrong needs to be impossible). There's nothing that best practices can do to prevent a motivated novice from throwing together a minimum effort contract that "works" by whatever test criteria they thought up over the past five minutes.

Imagine surfing the web, but instead of showing a 500 error a broken page would withdraw a random sum from your checking account. It doesn't matter how good the best pages are, no one in their right mind would ever open a browser.

> I think there's a difference between what you're saying (doing it right is possible) and what the critics are saying (doing it wrong needs to be impossible). There's nothing that best practices can do to prevent a motivated novice from throwing together a minimum effort contract that "works" by whatever test criteria they thought up over the past five minutes.

You're absolutely right. There's also nothing to prevent a motivated novice from writing software to control a mars rover. Just, nobody's going to send his rover to Mars. Nothing stops anyone from writing a smart contract, but common sense will (eventually, once the dust settles) stop people from throwing money at them.

a counterpoint: https://en.wikipedia.org/wiki/Mars_Climate_Orbiter

The rovers and shuttles have backup systems with different code in them specifically to deal with coding bugs. These fallback systems have also been repeated needed because of bugs in the shipped system.

You mean like how many smart contracts have reference implementations in other languages?

Being written in other languages is not sufficient. A different algorithm is needed.

I believe the idea is that you write the alternative reference implementation in a language that's easy to computationally reason about (e.g. Haskell) and then try to prove equivalence between your Solidity implementation and that one.

If the algorithm has bugs (and they often do) using the same algorithm in different languages doesn't help.

Sure, but in certain languages you can reason formally about them, and prove properties of them. It's not completely perfect, but particularly for relatively simple models you can get pretty high confidence in correctness, at least, up to certain invariance assumptions.

Proofs have bugs in them, too. Would you bet your life on them? Algorithms are also based on a model of reality. The models are usually wrong, too.

You bet your life on them all the time. Every time you cross a bridge. Medical devices rely on algorithms. The standard of evidence you're requesting here is unreasonable, and not applied in any other domain.

This is from an auditing agency, so by definition these flaws were solved. Most ICOs get multiple security audits. How many startups can you say that about?

> "Typically, these would consist of non compliance with the ERC20 standard"

Given that ERC20 standard was ratified in the 3rd quarter of last year, ~70% through the year, and only ~70% of ICOs had this issue...

> ..contained vulnerabilities in smart contracts, the heart and soul of an ICO

> Once an ICO starts, the contract cannot be changed and is open to everyone

Many teams have upgraded their contract without an issue. The market has stopped reacting to it completely. They just release a new contract and airdrop it to all existing holders. Notify the exchanges, and it is business as usual.

This is more of a FYI. I'm not really curious about what this particular research group is doing, or why this article uses "vulnerability" without the distinction of how benign these things are.

There are still downstream effects with this. Exchanges, financial products on top, all have to deal with this. And this also goes against decentralization.

Airdrops don't seem like a complete solution to me. If someone sells a lot of stolen/hacked tokens, it still decreases the value of the airdropped tokens, since there's absolutely no recourse once the stolen ones are converted to something else. The only way to stop a hacked contract from becoming a problem is if every path to liquidity is immediately halted, but I'm not sure its realistic to do that. I'm sure there is always a long tail of exchanges and holders still transacting in the hacked tokens. People are still transacting in ETC, lol.

People not caring is probably just due to the crazy risk and volatility in crypto in general.

Most "smart contract vulnerabilities" don't involve the ability to steal them.

Again like I said, I don't know why this article doesn't point out how benign most of these things are.

so for the one example you presented, thats right it isn't a complete solution, and that one example requires its own individual discussion. This article doesn't distinguish about the level of severity of the vulnerability

the reality is that most of these are as benign as any random website not getting 100% in a cursory test

If that's what they're doing then why not just do an auction on a web site? What's the point of using the block chain if your solution to any problem is to go around it anyway?

The idea is generally to get to the point where minimal maintenance is necessary

The distributed ledger technology makes it easy to offload accounting and user management, which helps you quickly bootstrap the supply and demand side of a network much faster while coupling that with the capital you need or simply want.

These are typically catch-22 problems for other kinds of networks, VC backed or otherwise. It is dime a dozen in silicon valley to have a company that raised 10 million in a series A to barely have 10,000 users before ultimately closing the doors and giving nothing to its vested common stock employee/holders.

Not too much different with ICOs, except people get more than nothing and don't have to wait for it.

Reply on news.ycombinator.com