ICO SECURITY- ALL YOU NEED TO KNOW

GENERAL, SMART CONTRAT & WEB SECURITY CONSIDERATIONS

Every crypto company is raising millions of dollars by organizing their own ICO, marketing their innovative idea. ICO has become the buzzword of recent times. Although, it is important to note that they’re meant to deal with huge sums of money, people’s money, your money. This makes it important for ICO organizers to ensure a fool proof security, especially after the recent ICO hacks.

This blog is aimed to help newbies to find general, web-security and smart contract based security solutions, to help ICO organizers find a solution to the security problem.

Smart Contract Recommendations

Ethereum and complex blockchain environment is highly volatile. In this manner, you ought to expect consistent changes in the security scene, as new bugs and security dangers are found, and new accepted procedures are produced. Following the security hones in this report is just the start of the security work you should do as a shrewd contract designer.

Pausing

In case a mishap occurs during the ICO, organizers should be able to pause their crowdsale. Deal with the attack or bug and then proceed. Zeppelin-solidity provides a process life cycle management interface allowing to implement an emergency stop mechanism. Solidity developer are advised to use it in their contract code with essential functions as a damage control mechanism. You can see it here.

Upgrading

Code should be changed if errors are found or if upgrades are needed. Finding a bug, yet having no real way to manage it can be very bad. Similarly, token contracts should be able to fix bugs discovered during bounties and should be able to add functionalities later if necessary. Their can be two approaches to this problem:

• Solidity developers can have a registry contract, pointing to the current version of the contract. Here developers must take care that all user requests are pointed to the current version of the contract only and a way to handle data from older versions of the contract.
• Solidity developers can use delegate call to forward data and calls. This method removes overheads associated with the previous one, but introduces drawbacks of its own. If the new version of contract has a different storage layout than the first one, it’s data may end up corrupted. Additionally, this simple version of the pattern cannot return values from functions, only forward them, which limits its applicability.

Rate limiting

Rate limiting is a strategy which halts or requires approval before substantial changes are made. For instance, a depositor may only be allowed to withdraw a certain amount or percentage of total deposits over a certain time period (e.g., max 100 ether over 1 day) — additional withdrawals in that time period should fail or require some sort of special approval. Or the rate limit could be at the contract level, with only a certain amount of tokens issued by the contract over a certain time period. Here is an example to help developers.

Bug Bounties

Bug Bounties are an important part of a crowdsale and should be taken very seriously by ICO organizers. It develops trust among investors and helps identify hacks overlooked by the developers of organizing team. Here’s a Zeppelin Solidity based bug bounty contract.

Security tools

Automated audit tools like Oyente, Mythril and Securify should be used to audit ICO contracts and discover vulnerabilities, before they go through a manual audit process. These are static analysis tools with features ranging from bytecode analysis to test case generation. Though, most of them are still in their beta versions and therefore cannot be completely trusted. Some other tool like — Solidity-Coverage, code coverage for solidity testing and Solint, Solidity linting that helps you enforce consistent conventions and avoid errors in your Solidity smart-contracts, are advised to be used.

Security Notifications

This is a catalog of sources that should be followed to know abou regular updates in Ethereum or Solidity environment. The official source of security notifications is the Ethereum Blog, but in many cases, vulnerabilities will be disclosed and discussed earlier in other locations. It’s highly recommended that ICO organizers regularly read all these sources, as exploits they note may impact your contracts.

• Ethereum Blog: The official Ethereum blog
• Ethereum Blog — Security only: All blog posts that are tagged Security
• Ethereum Gitter chat rooms
• Solidity
• Go-Ethereum
• CPP-Ethereum
• Research
• Reddit
• Network Stats

Web Security Practises

Blockchain is very hard to be hacked but people hackers know that it’s interface to web based services is not that secure. They find loopholes overlooked by the developer and use it to cause nuisance. It’s the responsibility of a website owner to safeguard their website against nefarious hackers. In addition to regularly backing up their files, taking the following steps will help them keep their website safe:

Content Security Policy (CSP)

Content Security Policy (CSP) can help ICO organizers to specify the domains a browser should consider valid sources of executable scripts when on their webpage, so browser knows to ignore any malicious script that might infect their visitor’s computer.

Using CSP is simply a matter of adding the proper HTTP header to ICO web page that provides a string of directives that tells the browser which domains are allowed and which are to be banned. Developers can find details on how to craft CSP headers for a website provided by Mozilla here.

Input Validation and Sanitization

Validation checks if the input meets a set of criteria (such as a string contains no standalone single quotation marks).

Sanitization modifies the input to ensure that it is valid (such as doubling single quotes).

These checks should be handled at the front-end of ICO website. Developers should combine these two techniques to provide in-depth defense to ICO website. For example, developers might change all single quotation marks in a string to double quotation marks (sanitize) and then check that all the quotation marks were actually changed to double quotation marks (validate). Validation checks include testing for the length, format, range, and allowable characters. For example, if your application expects positive integer input, developers need to validate that any input string consists of the digits 0 through 9 only. Another popular technique which can be used here is asset integrity check, where checksum of assets is verified on frontend.

Handling File Uploads

Files uploaded however innocent they may look, could contain a script that when executed on server completely opens up a website. If an ICO website has a file upload form, then developers cannot solely rely on the file extension or the mime type to verify that the file is an image as these can easily be faked and a file with the name image.jpg.php has been known to get through. Even opening the file and reading the header, or using functions to check the image size are not full proof. Most images formats allow storing a comment section which could contain PHP code that could be executed by the server.

Some options are to rename the file on upload to ensure the correct file extension, or to change the file permissions, for example, chmod 0666 so it can’t be executed. The recommended solution is to prevent direct access to uploaded files all together. This way, any files uploaded to ICO website are stored in a folder outside of the webroot or in the database as a blob.

API Throttling

In order to protect API from being abused, API throttling should be used. If a single IP is making more requests, much higher than what is expected from an average user, then new requests from such an address should be banned. This is to save ICO website from DDOS attacks. Malicious users can make too many requests and bring ICOs website down during crowdsales. In such a case the IP can be banned for a relatively small period of time, to handle accidental situations. Although if the user repeats his actions, blocking periods should be exponentially increased each time a user crosses the limit.

Handle Account Takeovers

Account takeovers or brute force attacks are easy to set up. Developer should make sure their website users are protected against account takeovers. A popular and easy way to handle this is by restricting the number of login attempts for a particular user. Another strategy is to restrict user to be logged in only from a particular device at a particular time, i.e. disable multiple login. We can add another layer of security against brute force attacks by using user IP-tracking to stop IP abuse. For instance users trying to login from varied geographical locations should be blocked. This will also help developers handle DDOS attacks.

Library Vulnerabilities

Developers need to fix library versions of their project and upgrade them only after properly testing the new upgrade. This stops exposed vulnerabilities in library upgrades from affecting the ecosystem of your ICO. For testing these vulnerabilities there are many popular tools available. Among them snyk is a popular option and is widely used. For ultimate security needs developers can also fork libraries to a private repo and then use them.

HTTPS

HTTPS is a protocol used to provide security over the Internet. HTTPS guarantees to users that they’re talking to the server they expect, and that nobody else can intercept or change the content they’re seeing in transit.

• Get your certificate from a reliable CA that offers technical support
• Decide the kind of certificate you need:
• Single certificate for single secure origin (e.g. www.example.com).
• Multi-domain certificate for multiple well-known secure origins (e.g. www.example.com, cdn.example.com, example.co.uk).
• Wildcard certificate for a secure origin with many dynamic subdomains (e.g. a.example.com, b.example.com).
• Redirect your users and search engines to the HTTPS page or resource with server-side 301 HTTP redirects.
• Do not block your HTTPS pages by robots.txt files.
• Do not include meta noindex tags in your HTTPS pages.
• Use Fetch as Google to test that Googlebot can access your pages.
• We recommend that HTTPS sites support HSTS. HSTS tells the browser to request HTTPS pages automatically, even if the user enters http in the browser location bar. It also tells Google to serve secure URLs in the search results. All this minimizes the risk of serving unsecured content to your users.

Server Monitoring

ICO organizers should prepare for an attack. First of all they should have a monitoring system in place that will detect security events targeting their application before it’s too late. Knowing when your application is starting to get massively scanned is key to stop more advanced attacks. They can use alerta for this. Secondly, they should have something similar to an emergency protocol in place to help themselves through such attacks. Takeovers can also be intended to steal ICO data or setup your servers to be used as bouncers. These can be detected by watching for unusual patterns in metrics such as network bandwidth, CPU and memory consumption, and disk usage. Developers can use server monitoring tools like — newrelic’s server-monitoring or sysdig, to achieve this. Use free tools by mozilla and ssllabs to scan your infrastructure regularly and make sure the SSL configurations are correct.

Hack Yourself

Once in awhile, the entire technical team should sit together and spend time targeting all parts of the application, looking for vulnerabilities. This is a great time to test for account isolation, token unicity, unauthenticated paths, etc. Developers will heavily rely on their browser’s web console, curl, and 3rd party tools such as Burp.

Additional Tips

• Infrastructure logs and application logs are your most precious allies of a developer, for investigating a data breach. Make sure your logs are stored somewhere safe and central. Also make sure you whitelist or blacklist — specific incoming data to avoid storing personally identifiable information (PII) data.
• Developers should run security linters on their code. Static Application Security Testing (SAST) is an easy and fast way to find unsafe patterns in your code. You can enforce SAST security checks with a pre or post commit hook, but be aware of the high number of false positives.
• Use third-party services to store credit card information to avoid having to manage and protect them. Stripe and braintree are recommended and commonly used payment gateways.
• Before committing their code or publishing their package to a repository, developers should ensure no sensitive data will be shipped. Using a pre-commit hook or a prepublish script helps to prevent such leaks. You should particularly look for: Database credentials, API keys or configuration files. Here’s a recommended tool.
• If using node, developers should avoid using fs, child_process and vm modules with user data. The fs module allows access to the file system. Using it with unsafe data can allow a malicious user to tamper with the content of your server. The child_process module is used to create new processes. Using it can allow a malicious user to run their own commands on your server. The vm module provides APIs for compiling and running code within V8 Virtual Machine contexts. If not used with a sandbox, a malicious user could run arbitrary code within your web application.
• It is a very common mistake to confuse authorization with authentication and ignore the former one. Developers should ensure proper endpoint authorization for their APIs.
• Projects using SQL, should not use incremental IDs and prefer UUIDs instead. Incremental IDs can be used by hackers to guess IDs of other users and exploit this knowledge in an unfavorable way.
• Never try to implement your own cryptography, unless you’re an expert. The problem with cryptography is that you don’t know you are wrong until you are hacked. So don’t do your own crypto. Use standards instead. For most crypto related operations, the ‘crypto’ core module can help you.
• Mocking your server details can be a good practice, for example if Node.js is used for ICO website , portray that ruby is used. This deception can make the task of a hacker somewhat difficult.
• When using a templating engine, you should know which syntax can introduce XSS vulnerabilities. For instance, Pug (formerly, Jade) escapes all inputs by default unless you use the ‘!’ symbol.
• If using React, serve static parts of ICO front end app from a secure location such as AWS S3 bucket.
• Users session and cookies can be hijacked by a hacker and misused to gain unauthorized access to ICO applications. Simple things such as an appropriate time to live for a session can have a huge impact against this problem. Here’s a link to help users setup secure sessions.
• Developers also need to setup a firewall, and block all non essential ports. If possible setting up a DMZ (Demilitarized Zone) only allowing access to port 80 and 443 from the outside world.
• If possible run database on a different server to that of your web server. Doing this means only your web server can access required database, minimizing the risk of user data being exposed.

General Considerations

When considering hacks the first thing that comes to our mind is code breaches, server vulnerability, or application flaws. Although, recent incidents point, most of the times something as trivial as a stolen password or a stolen social media account, leads to a huge mess. Here are a few things ICO organizers can do to avoid them:

Facebook

Facebook virus link

• Only valid users should be listed as site admins. Give lower permissions and remove everybody who is not needed.
• Owners should make sure they know about the the third party apps that they add, it should not be a scam.
• Owners should enable post approval option before they’re published on their website by any guest.
• Educate users and employees not to identify fake links and stay away from them.

Slack

Slack is becoming a popular medium for establishing crypto company communities. However, it was primarily developed as a channel to communicate among team members, who in most cases, are trusted people. Misleading messages like these are quite common in the crypto community space:

Phishing attempt on Slack

The link provided won’t direct users to the real myetherwallet website but to a website that looks almost exactly the same. ICO organizers can take the following points into consideration to avoid such mishaps:

• Only allow site admins and owners to communicate on general channel, especially during ICOs, it is mainly to avoid fake addresses, when a website is down due to DDOS attack.
• Channels should only be achieved by admin users.
• Slackbot reminders should be removed before they reach users.
• Two factor authentication should be enabled for company members.
• Unnecessary third party applications should be removed.

Some companies even consider ditching Slack and moving to different platforms like the messenger app Telegram or gaming platform Discord.

Twitter

• Twitter teams should be able to share one account, for this owners can use the Tweetdeck application. In this case they don’t have to share the password and it’s much easier to manage If somebody leaves their company.
• Also enable two factor authentication for all users. It’s one of those things that should be enabled wherever it’s possible.

Additional Tips

• ICO Organizers should make sure their domain names are secure. Special care must be taken to renew them regularly and if bought from a third party, they should make sure that the authoritative configured name server is their own. Hackers can also use similar domain names to confuse your community members and spread misleading messages. Organizers can use domain name generators to find domains similar to their domain name, then buy the ones which can confuse their customers, especially during their ICOs.
• ICO Organizers should have a public security policy in place. This is a page on your corporate website describing how you plan to respond to external bug reports. You should advise you support responsible disclosure. Keep in mind that most of the reports that you receive probably won’t be relevant. Here’s an example.
• ICO Organizers should release their crowdsale address in advance and inform their community about it. They should also use the Ethereum name service to purchase an address that can be easily remembered by their community.
• ICO Organizers should use a hardware wallet, such as Ledger Nano S or Trezor to access their ICO smart contract/wallets or store funds. Lock up their wallet in a safe so that it doesn’t get stolen or lost.
• Organizers should be honest about their practices and the data they collect. In the case of a breach, people will disclose any data they gather. Your customers need to be aware of what data you’re storing and what practices you use. Moreover, it helps build a relationship of trust with the users.
• Non tech employees are less used to technical tricks and can be deceived more easily than others, opening the door to ransomware or confidentiality issues. They should be trained and empowered to be distrustful and to preserve the company’s assets.
• Educate users about possible security measures. Organise periodic workshops to talk about latest observations, different types of hacking (like social engineering).
• Use password managers, use different passwords for different accounts. This will ensure that even if one account is compromised, the rest of the accounts are safe.
• ICO Organizers should have a full time community manager monitoring their ICO slack & telegram chats. Check through the member list regularly and proactively ban members with suspicious names (e.g. their company founder name) or throwaway email address (e.g. yopmail email accounts).
• ICO Organizers should organize a bug bounty program, it will allow external hackers to report vulnerabilities. Most of the bug bounties programs set rewards in place. Security-aware developers should evaluate the reports received during a bug bounty
• A secure development life cycle should be implemented, it is a process that helps tackle security issues at the beginning of a project. While rarely used as is, it provides good insights at all stages of the project, from the specification to the release. It will allow you to enforce good practices at every stage of the project life.

SUMMARY

Security is a constant process which has to be taken under consideration with every new implementation, with every new system or every new medium crypto companies plan to use. Don’t forget about it, especially in the case of ICOs because your mistake can lead to someone’s loss of money.

Lastly we need to ask this question — Is it possible to be fully secure? You can’t be always sure, but at least you can do your best and follow common rules of security, just like these basic ones already described.