/ Security

Cyber Security & Cryptocurrency Startups

"Follow the money."

A mantra followed by many, but embraced by the criminal community.

Startups aren’t often (immediately) targeted by hackers and scammers. This does not apply to startups within the cryptocurrency sector, however. It is becoming increasingly easier to turn an idea into a technology startup with a good presentation, followed by an initial coin offering.

The nouveau riche are quite trigger-happy with spending their money to get more value out of it. This eagerness is shared by many within the cryptocurrency spectrum (and those that just got in), which leads to people not always checking the source of things as they should, which in turn causes them to be easily socially engineered into something they regret.

Social engineering, however, is as old as time, and not within the scope of this article.

Cyber security. An interesting topic seemingly forgotten by most tech startups within the cryptospace. This article is (yet another) wake-up call to everyone starting within this sector.

$ nmap -T Insane <redacted>
Starting Nmap 7.40 ( https://nmap.org ) at 2017-09-10 12:18 CEST
Nmap scan report for <redacted> (<redacted>)
Host is up (0.053s latency).
Not shown: 988 filtered ports
21/tcp    open  ftp
53/tcp    open  domain
80/tcp    open  http
110/tcp   open  pop3
135/tcp   open  msrpc
143/tcp   open  imap
1433/tcp  open  ms-sql-s
3389/tcp  open  ms-wbt-server
8443/tcp  open  https-alt
49153/tcp open  unknown
49154/tcp open  unknown
49156/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 4.94 seconds

The above example is from a company of reasonable size that has had a rather successful crowd sale, but doesn't believe in firewalls. It shows an alarming amount of ports open to the internet. Whilst this does not directly give access to the administration interface of the server, it certainly allows any attacker to make a good attempt.

The keen observer may note that there is no HTTPS support, favoring HTTP instead.

The frightening thing is that the notion of security might not even have come up. Any SysOp or DevOp would have locked down external-facing ports immediately.

In this case, zero work has been spent on the issue, and it makes one wonder how secure a contributor's investment is, if the company won't even secure a simple server.

Anyone is able to attack the above-mentioned server, either by making educated guesses, or by simply using brute-force:

$ hydra -l Administator -P wordlist.txt ftp://<snip> -t 64 -W 1
Hydra v8.3 (c) 2016 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.

Hydra (http://www.thc.org/thc-hydra) starting at 2017-09-10 13:09:43
[DATA] max 64 tasks per 1 server, overall 64 tasks, 3107 login tries (l:1/p:3107), ~0 tries per task
[DATA] attacking service ftp on port 21
1 of 1 target completed, 0 valid passwords found
Hydra (http://www.thc.org/thc-hydra) finished at 2017-09-10 13:10:10

Let it be known that the goal of the above is not to gain access, and therefore no further attempts were made. This was done using a minimal word list (i.e. default John the Ripper word list).

A persistent attacker, however, would not stop here, and he does not need to, because nothing is blocking him from trying.

service.addAdminToSite = function (siteId, data) {
    return $http.post((“http://api.<redacted>/api/v1/") + siteId + '/admins', data);

service.getSiteAdministratorList = function (siteId) {
    return $http.get(("http://api.<redacted>/api/v1/") + siteId + '/admins');

The above is a different example, from a different company. It is a snippet taken from a publicly available file sent to viewers of their website.

The snippet exposes (a part of) their administration interface to all visitors. There is nothing stopping a potential attacker making an attempt to connect to the interface.

$ curl http://api.<redacted>/api/v1/0/admins
{"errors":["Authorized users only."]}

The attacker now knows he can make attempts to trick existing administrators into logging in on a different page to the login, or steal their session cookie and gain control directly. Another fact is that the API calls are done over HTTP instead of HTTPS, simplifying things for the attacker immensely.


The above are good examples of issues that should have been addressed earlier, and the list of issues is rather immense (yet not exhaustive):

  • No HTTPS available at all and/or accessible via HTTP.
  • No HTTP security headers available.
  • FTP, SSH, Remote Desktop accessible.
  • POP3 and IMAP accessible.
  • Blog administration interface accessible.
  • No implementation of OWASP.
  • Missing security patches.
  • No enforcing of cipher suites.
  • No multi-factor authentication in place.

This reflects a lot of the startups currently appearing within the cryptocurrency community, which raises significant doubt regarding their seriousness about cyber security.

It has taken a long time for companies to accept the requirement of spending time and resources on cyber security, and yet, these measures appear entirely absent for most of the cryptocurrency startups.

With all this said, it surprises one that not more hacks have taken place within the cryptocurrency ecosystem. Let this be a wake-up call.