Mapping the ICO threat landscape
You’re already on the path for an ICO. Along with you, there are numerous people trying to do the same. Not all of them have that great idea of yours, but they might know that you do. They could just join you, and you know, not all people are polite enough to ask. Who knows, they might even do your ICO without you.
Going through an ICO makes you a target for hackers, adversaries capable of finding ways to steal your incoming funds.
In this post, we will go through the most common assets an attacker will go over when trying to disrupt a company aiming for an ICO.
There are endless articles detailing every single hack that occurred by exploiting smart contracts. One of the greatest flaws in the smart contract technology is that they cannot be updated. Once they are on the blockchain they are written in stone, they cannot be changed. If the contract is vulnerable, it will stay that way.
A smart contract, being code, is prone to vulnerabilities. Even though there are multiple solid attempts to make the ICO contract development easier and more secure like OpenZeppelin, ConsenSys etc. your developers can always make mistakes. It’s not bad to make mistakes, but it is bad to deploy your contract without going through a security assessment.
Due diligence should be made by the development team. By no means should you leave the smart contract development to just one person. One of the most interesting facts about the blockchain is the prevalence of the “insider” threat actor. The smart contract is used to collect your funds, and as such communication about its design, development, and deployment should be handled by more than one person. You don’t want your funds to be sent to a different address ;).
OSINT — Going after personal data
This could be the easiest step for an attacker to take. Going after the team. An attacker would first scrape the organization’s website for user data. That data could contain emails, pictures or social media account links. This information can be inserted into reverse image searching services like TinEye or to people search engines like Pipl. With all this information attackers can build up a substantial knowledge base about the team.
The extracted emails can be checked as to whether they have been compromised in data breaches with the help of https://haveibeenpwned.com/. The next step is to locate the data breach dump and find a potentially valid password for that email address.
Attackers will not only focus on business email addresses but personal as well. An old password for one account could be the current for another. It could also be a variation. The old compromised password “P@ssw0rd!” could be the new “P@ssw0rd1”. Once access to one asset is accomplished even if it is a personal account it could be escalated to something more.
Sometimes though, you might be stopped from gaining access to an account even if the attacker has the correct credentials by a Two-Factor Authentication (2FA) scheme.
2FA: Mobile Networks
What can go wrong with 2FA? Two-factor authentication is used to protect our data, and it’s good at it. Well, some of the 2FA mechanisms are good and some aren’t. Take for example SMS verification. It’s not.
There are already offers in the deep web selling interception services from various telecom providers. Nonetheless, the user’s SMS OTP could be redirected to another user providing them with the access token.
SMS verification should be considered deprecated and new technologies should be used instead. A great alternative which does not involve receiving an SMS is the Google Authenticator Application.
Web Application / Web Server
You might already be familiar with this section as it refers to traditional vulnerabilities on the web application and web server. Adversaries map all the assets of the organization and attempt to find the weakest link. As the old saying goes, “Your defense is as strong as your weakest link”. Once the weak point is identified, attackers will attempt to gain access.
A common weak point is the testing environments. Usually, the testing environments are replicas of the production ones but have fewer protection mechanisms. This might allow for the attackers to identify vulnerabilities on the system with greater ease which might translate directly to the production environment.
In your case, an attacker does not need a remote code execution vulnerability to do damage to your brand. What if they could modify your landing page and place their own address as the ICO address? Defacement, if done properly, is very hard to notice, of course up until the moment when you see your funds going to another address.
Hosting Control Panel
Hosting services, there is nothing wrong with that. We all use or have used them at some point. Easy, convenient and cheaper than owning the whole environment. But as it is logical and natural, hosting services have vulnerabilities too. This is an indirect way to gain access to your service. Your website might be secure, but what if your hosting provider lands you on an insecure server?
An even cheaper and more convenient solution is using shared hosting. Unless your website is a static page with no access to sensitive corporate data and is not used to affect your client’s financial decisions a.k.a. your ICO landing page, you should change your plan as soon as possible.
The problem with shared hosting is that you share the same environment with a bunch of other websites. It could be 5 more or 20 more different services. You might trust your website and your hosting control panel to be bullet-proof but can you trust the rest of sites being hosted on the same server? It only takes one site to be compromised for an attacker to be able to manipulate yours.
Social Engineering Attacks
This might be the most difficult attack vector to protect against. The only way to protect your ICO from it is user education. In reality, it doesn’t affect your ICO but more likely a portion of your potential investors. The thing is that you don’t want investors to send their funds to the wrong address, it’s a kinda lose-lose situation unless you are the attacker. In that case, it’s a win for you.
You might have been encountering this issue already. If not, you’ll encounter it as your ICO start date is getting closer. Adversaries register a large number of tricky domains and social media accounts and pretend to be you, luring unsuspecting victims. Your domain might be ‘example.com’ and now the malicious ‘examp1e.com’ pops up (Note the difference between the number one ‘1’ and the lower case ‘L’ ‘l’.). Even if you can notice the difference and won’t get tricked by it, can you guarantee that your investors will do the same? Talk to your potential investors, educate them.
One of the most common practices is to clone your website and its basic functionality. The next step would be to social engineer your investors. Again the only thing you can do for this is to educate your potential investors.
How about your social media accounts? This could be Telegram, Slack, a Facebook group etc. Even if you don’t use them, you should register the company name to avoid identify theft. Let your users know that you have digital presence only on a specific number of services.
Register to social media that have high impact but you’ve decided to not use. Set a placeholder for your company and let them know that you have no presence on this service. This step might be tedious but you don’t want a community to pop up under different management.
If you are communicating by email with your potential investors you might want to consider configuring your SPF records and DKIM keys. These settings will allow you to provide DMARC protection to your emails.
DMARC provides email authentication and will quarantine potential spam emails. With the lack of the above security feature, it is possible sometimes for attackers to send emails on your behalf, by manipulating the “From” field. Unsuspecting investors might be manipulated by this technique and perform financial decisions based on the information provided by the fraudulent emails.
Going for an ICO is a make or break moment for a company. If the ICO fails the chances of success are thinning down. You don’t want to fail on your ICO due to hackers. The pressure that an organization goes through during that phase sometimes can be too much.
There are numerous things to take care when going for an ICO. The attack vectors listed above are some of the main points of failure we encounter at Positive Security when conducting ICO security assessments.
As a takeaway, the following points might help you tighten your perimeter and increase the security of your assets.
- Educate your users. Let them know how will you communicate with them, when, and from where
- Secure your website and services. Audit them
- Minimize your asset footprint. Probably you don’t need that development environment unsecured and facing the internet
- Vet your team, protect your accounts, use strong passwords. Use a different password for each service, preferably use password managers
- Apply the same to your personal accounts
- Use 2FA
- Don’t use SMS 2FA, it’s deprecated!
- Make shorter smart contracts, reuse existing safe code
- Let a third-party audit your smart contracts