
Researchers: Last Year’s ICOs Had Five Security Vulnerabilities on Average - mikece
https://www.bleepingcomputer.com/news/security/researchers-last-year-s-icos-had-five-security-vulnerabilities-on-average/
======
baby
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](https://www.dasp.co)

------
technion

        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.

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

------
brighton36
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.

------
nemild
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/](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](https://github.com/ethereum/wiki/wiki/Safety)

Decentralized Application Security Project:
[https://dasp.co/](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/](https://consensys.github.io/smart-contract-best-practices/)

Hacking Distributed is a great blog for blockchain security:

[http://hackingdistributed.com/](http://hackingdistributed.com/)

Emin and Phil Daian are great to follow on Twitter:

[https://twitter.com/phildaian](https://twitter.com/phildaian)

[https://twitter.com/el33th4xor](https://twitter.com/el33th4xor)

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

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

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

~~~
this_user
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.

~~~
darawk
> 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...

~~~
daylightsavings
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 ;)

~~~
darawk
> 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.

~~~
vec
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.

~~~
darawk
> 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.

------
woah
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?

------
deltateam
> "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...

------
deltateam
> ..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.

~~~
gnarcoregrizz
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.

~~~
deltateam
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

