Issue 135: Millions stolen from cryptoexchanges through APIs 💱

Researchers from CyberNews found how cybercriminals locate and exploit API keys from cryptocurrency exchanges to steal millions of dollars.

Many users take advantage of various applications to make their cryptocurrency trades easier. To give these applications access to their cryptocurrency account, users give the apps their private API keys for the cryptoexchange.

Unfortunately, many applications (and users) do a poor job keeping these API keys safe. Some applications put them in unprotected environment variable files, or the keys end up in public GitHub repositories or S3 buckets. The API keys that researchers found in various public locations at the time of their research provided access to wallets with a total value of over a million dollars.

For security reasons, cryptoexchanges typically limit API key permissions. By default, the keys give access to data and trading operations, but the permission to withdraw money or transfer it to another wallet is not.

However, being infinitely ingenious as they are, cybercriminals have worked around that limitation. Instead of transferring the money out of an account directly, they use bots and controlled trade middlemen to manipulate the market and then use the trade permissions on the leaked or stolen API keys for massive simultaneous buy or sell orders in the cryptoexchange. These cause spikes and drops in the value of cryptocurrencies that criminals use to buy the assets cheaply or sell them at a premium (at the expense of the victims!), effectively ridding their victims of their account balances in a blink of an eye.

Lessons learned here:

• Never underestimate cybercriminals: if there is profit to be made, they will find a way to take advantage of it.
• Static, long-lived API keys are dangerous and should be avoided.
• Additional measures must be taken to prevent API key reuse: mandatory IP whitelisting, mutual TLS authentication, tying the keys to specific API clients, and so on.
• And, of course, API keys are extremely sensitive secrets and should be treated as such. Never, ever, store the keys in unprotected, accessible locations!

Rocket.Chat is a popular open-source team communication software that has more than 12 million users worldwide and is deployed on over 800 000 servers.

Security researchers at SonarSource found API vulnerabilities in Rocket.Chat that could be chained to take over an administrative account and lead to remote code execution. In short:

1. 1. Attackers locate the email address of a user account that does not have two-factor authentication (2FA) enabled. These tend to be regular users, not administrators.
   2. Attackers send a password reset request (which inherently cannot require authentication) for that account. The request includes a parameter with a regular expression that causes a MongoDB NoSQL injection and allows them to retrieve the password reset token one character at a time. Once they know the full token, the attackers take over the user account and are now authenticated as the user.
   3.  The attackers use the account to invoke the API endpoint /api/server/v1/users.js and cause the top-level NoSQL operator $where to throw an error that leaks any user’s — including administrators — email, password hash, and 2FA secret.For example, this query would leaks an admin user’s secret:
      
      {"$where":"this.username==='admin' && (()=>{ throw this.secret })()"}
      
      The API response for a call with this filter parameter would include the secret:

      {
        "success": false,
        "error": "uncaught exception: aHR0cHM6Ly9iaXQubHkvM3VQclgwUA=="
      }

   4. The attackers take over an admin account they have now discovered.
   5. The attackers have now access to perform remote code execution.

The root cause of the problem here boiled down to the fact API input was not validated, so researchers could send NoSQL injections, and initiate the whole chain of events. The fact that filtering was done with blocklists rather than allowlists did not help: it is much easier to miss something coming from outside, than when you can use your own definitions as a checklist.

You can see the attack in action in this quick video:

Lessons learned with this one:

• Strictly define and enforce all your API inputs.
• Also define and enforce outputs, so attackers cannot cause your APIs to leak unexpected data.
• Use allowlists rather than blocklists. Not only will that support you in locking down your inputs and outputs, but blocklists are also a lot less effective than allowlists.
• Use 2FA whenever possible.

Are you using Let’s Encrypt certificates for the HTTPS transport in your APIs? If so, you might need to update your clients.

The old Let’s Encrypt DST Root CA X3 root certificate will expire on September 30, 2021. This is not a problem for browsers, because all modern browsers include the current Let’s Encrypt ISRG Root X1 in their list of root certificates. However, API clients might not have that and thus might require a manual update.

If you use OpenSSL, you also need to make sure you are on OpenSSL 1.1.0 or later.

See the announcement from Let’s Encrypt for more details.

“Offensive GraphQL API Exploitation” is a recording of the Red Team Village 2020 talk by Arun S. He discusses common security issues in GraphQL APIs and how attackers use them to attack the underlying infrastructure and ex-filtrate sensitive data: