By Jean-Baptiste Aviat, Co-founder and CTO of Sqreen. Originally published on Sqreen.
ICOs are all the rage these days. You have ICOs raising millions in seconds, and others losing millions in seconds. Coming from a security background, I wondered if these ICOs deserved the love/hate they were receiving.
We ran an analysis to grade ICO security that raised more than $5M.
tl;dr ICOs suck at security. Our research brings to light the poor practices that reign in ICO security.
Why is security important for ICOs?
It is known and expected that most young companies do not invest in security: they have a product to build and need to acquire users and clients first. In the case of ICO companies, this is extremely different.
ICO companies handle millions of dollars in crypto money. That’s often their own customer’s money — and/or investor’s money.
Many ICOs have failed or were endangered because of technical security issues:
- DAO: a vulnerability in the smart contract allowed attackers to steal ⅓ of amount raised
- Tether lost over $30 million
- Parity has seen wallets frozen because of a security bug
- CoinDash where hackers managed to change a payment address.
- Veritaseum lost $8 million in ICO tokens
More importantly, many of these companies have platforms to allow their users to exchange their coins or convert their tokens. An attack on this application is part of what can make an ICO fail.
ICOs fail to show decent security for their users…
So what is the current state of ICO security?
More than 60% of the companies in our analysis show obvious worrying and technical misses at the application and network security level. The most worrying things we have detected are not listed in this article but were reported to the companies. Here is a selection:
Exposed private cloud administration portals (VMware ESXi).
This can allow an attacker to take over the whole infrastructure of the company.
Out of date and vulnerable SSH servers.
Many companies have SSH servers that are 2 years old, proving operating systems were never updated.
Exposed build tools.
It is common practice to publish build tests, but build tools are complex beasts and regularly show security failures. You shouldn’t expose them.
Exposed DNS servers.
DNS servers have shown lots of vulnerabilities in the last years. They may also be used to perform denial of service against online services.
This allows attackers to brute-force the database credentials, or a former employee or contractor to still be able to connect to it. It also makes it way easier for an attacker with some knowledge of the company to access these systems. Databases are also a vector to perform other attacks on various systems of the company.
Exposed graphical administration tools (Microsoft Remote Desktop, VNC, Webmin).
That’s an easy way for an attacker to find its way into the company.
Analytics and monitoring engines (Grafana, Munit).
They are often a plain interface into the database or a great way of displaying infrastructure details.
All the above-listed items should be private. We found them because they are publicly accessible, from the internet. It is a basic security measure to hide them behind a VPN or source address monitoring.
These companies also host a lot of services themselves, such as chat services and forums. Hosting such services is a difficult thing to keep secure: they need to be updated, configured accordingly, and for most companies, this is often not an important focus. Thus, they are quite complicated to keep secure.
Self-hosted services are extremely hard to secure: network filtering has to be implemented, authentication needs to use great password policy, 2-factor authentication, to ensure the hosted services are secured. In this case, many services were found publicly accessible.
ICO companies make basically no usage of security measures intended to protect their users such as a Content Security Policy (they actually are 3 times less likely to use a CSP than the average of the internet).
The simplest security measures, such as HTTP headers, are not even put on their websites. Such security headers bring basic but important protections to force browsers to use HTTPS, block Cross-site Scripting (XSS) or MIME attacks.
And finally, none of the ICO apps use any serious sort of real-time application security solution to protect their data.
… but care about speed
We have however found out that ICO companies are concerned about their availability and speed. They use CDNs that make their websites run faster and can protect against Distributed Denial-of-Service (DDoS). Almost 70% of the ICOs analyzed use a CDN like CloudFlare. This CDN adoption seems to be much more prevalent than for other companies.
Anti-DDoS CDNs protect websites against attacks that can make them temporarily inaccessible. The business impact of having a website down is terrible: it prevents users from signing in, visitors (potential investors) to check the company website or… whitepapers.
But CDNs do not protect applications users or investors: Cross-site Scripting (XSS), NoSQL injections, account takeovers and more.
The full result of the analysis is available here.
Outlook on ICO security
Here are a couple of small pointers for ICO actors:
What you need to do if you’re planning or running an ICO?
For your business, security is not an option. We’ve built a basic security checklist that developers should follow to improve their ICO security.
You can get it here.
The important thing is to build a clear roadmap and to prioritize it. Tackle simple steps first.
In the case of ICOs, security issues are not about bad press, legal issues, or losing customers. It’s about the end of your company and the potential loss of millions of dollars.
What you need to do if you’re a crypto investor?
The focus needs to be spent on 2 things: First, as a Coin or Token owner, you need to secure yourself. You can check these tutorials:
Second, in addition to all your additional “smart investment criteria”, ensure the ICO you want to invest in takes security seriously! Their grade on https://www.sqreen.io/opendoor/ico/ is an indicator. Other indicators are:
- Their history of security issues and their reaction: have they fixed quickly? Did they communicate about the issue and the fix?
- Whether they run a security team or a security bug bounty program.
Thanks for reading this until the end! Have comments or feedback? Let me know!
About the author
Jean-Baptiste Aviat spent half a decade hunting vulnerabilities at Apple; helping developers solve them, and developing security software. He is now Co-founder and CTO at Sqreen.
Originally published at blog.sqreen.io on January 11, 2018.