Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Endpoint

1/2/2020
10:30 AM
Nicole Sette
Nicole Sette
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

Mechanics of a Crypto Heist: How SIM Swappers Can Steal Cryptocurrency

The true vulnerability at the heart of SIM-swap attacks on crypto accounts lies in crypto exchanges' and email providers' variable implementation of 2FA.

Recently, I shared with you how alarmingly simple it was to not only "hack" my own email account but then to use that compromised account to hack my other online accounts. Given how SIM-swap attacks on cryptocurrency exchanges escalated in 2019, I wanted to better understand these modern-day bank heists as we go into the new year. My hunch was that SIM swappers were using hijacked phone numbers like a set of keys to open locked doors into a world of online crypto accounts. Would I (or a hacker) have the same success hacking my crypto exchange accounts using just my phone number?

The first step in hacking my cryptocurrency accounts was gaining access to my personal email account with just a phone number. As I did in my first "hacking" experiment, I chose the "forgot password" option on my Yahoo account and was able to reset the password using only my publicly available username (my email address) and an SMS code sent to my mobile phone.

The fact that I only needed to type in the SMS code sent to my mobile phone indicates that single-factor authentication was in place here, not two-factor authentication (2FA). 2FA is the practice of authenticating to an account using (1) something you know, (2) something you have, or (3) something you are (biometrics). In the case of the SMS code, I simply had to type in "something I had" without a second factor proving my identity. This means a hacker who SIM-swapped my phone number would be able to reset my email account within a matter of minutes, even though I added my number to these accounts for added security. (You can read more about how SIM swapping works in my earlier experiment.)

After resetting my email password with an SMS code sent to my phone number (which could have been swapped to a hacker), the next step involved using that email access to identify and reset passwords on my cryptocurrency accounts. For a cybercriminal, the end goal is transferring bitcoin or other crypto assets to the attacker's crypto wallet.

I navigated to my first cryptocurrency account (let's call it Account #1), entered my publicly available email address as my username, and chose the "forgot password" option. Account #1 sent an email message to my now "hacked" Yahoo account. I was able to click the password reset link, enter an SMS code from my (SIM-swapped) mobile phone, and change the password on Account #1.

I tried the same technique with my second crypto exchange account (Account #2). This account did offer the option for application-based 2FA (such as Google Authenticator), but I had disabled that in favor of traditional password authentication. Given these settings, when I clicked "forgot password," I received a simple password reset link to my (hacked) Yahoo account that allowed me to set a new password and gain full access to Account #2.

At this point, I had gained access to an email account and two cryptocurrency accounts in about 10 minutes or less. These steps demonstrate how an attacker receiving text messages to a compromised mobile number could take over email accounts and easily gain access to crypto funds. Had I been an attacker, I could have quickly transferred crypto assets from my exchange accounts to a series of other crypto wallets and laundering sites that would funnel the money through various untraceable paths. This would leave the victim with little recourse to recoup the stolen assets.

Some cryptocurrency platforms have built-in mechanisms to prevent a SIM swapper from facilitating such a quick compromise of accounts. For example, one exchange where I opened an account (Account #3) allows single-factor authentication but implements a 24-hour lockout period before the password reset will take place. This effectively times out SIM swappers who have a short window in which to empty accounts before the stolen number is retrieved by its rightful owner.

This table highlights the variability in SMS authentication security options offered by crypto exchanges:

Crypto Exchange

Authentication

Password Reset

Account #1

App-based 2FA/optional

Email link + SMS code

Account #2

App-based 2FA/optional

Email link

Account #3

Single-factor (creds)/IP check

24-hour wait period

As I learned firsthand, several exchanges still allow for password resets via a link sent to an email account, which could easily be hacked by a SIM swapper in control of a phone number. Most exchanges offer stronger application-based 2FA for resetting passwords, but many still allow users to default to weaker single-factor authentication. For example, my Account #2 defaulted to application-based 2FA during registration, but users can log in before enabling this setting.

Similarly, while Account #1 offers more secure forms of 2FA such as application-based options, it also allows users to opt for SMS-based authentication settings that created the vulnerability in this experiment. Traditional bank accounts generally require more in-depth authentication to reset a password, such as Social Security number or security questions. Until cryptocurrency accounts implement similar password reset requirements, SIM swappers will continue to target these exchange accounts using the techniques outlined above.

It's clear that the true vulnerability at the heart of SIM-swap attacks on crypto accounts lies in crypto exchanges' and email providers' variable implementation of 2FA. Until all crypto exchanges force the implementation of more secure application-based 2FA, these vulnerabilities will continue to allow for SIM-swapping attacks against crypto accounts.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "5 Pieces of GDPR Advice for Teams Without Privacy Compliance Staff."

Nicole Sette is a Director in the Cyber Risk practice of Kroll, a division of Duff & Phelps. Nicole is a Certified Information Systems Security Professional (CISSP) with 15 years of experience conducting cyber intelligence investigations and technical analysis. Nicole served ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Small Business Security: 5 Tips on How and Where to Start
Mike Puglia, Chief Strategy Officer at Kaseya,  2/13/2020
Architectural Analysis IDs 78 Specific Risks in Machine-Learning Systems
Jai Vijayan, Contributing Writer,  2/13/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
How Enterprises Are Developing and Maintaining Secure Applications
How Enterprises Are Developing and Maintaining Secure Applications
The concept of application security is well known, but application security testing and remediation processes remain unbalanced. Most organizations are confident in their approach to AppSec, although others seem to have no approach at all. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-4230
PUBLISHED: 2020-02-19
IBM DB2 for Linux, UNIX and Windows (includes DB2 Connect Server) 11.1 and 11.5 is vulnerable to an escalation of privilege when an authenticated local attacker with special permissions executes specially crafted Db2 commands. IBM X-Force ID: 175212.
CVE-2019-4429
PUBLISHED: 2020-02-19
IBM Maximo Asset Management 7.6.0 and 7.6.1 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 162886.
CVE-2019-4457
PUBLISHED: 2020-02-19
IBM Jazz Foundation 6.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.0.6, and 6.0.6.1 could allow an authenticated user to obtain sensitive information that could be used in further attacks against the system. IBM X-Force ID: 163654.
CVE-2019-4640
PUBLISHED: 2020-02-19
IBM Security Secret Server 10.7 processes patches, image backups and other updates without sufficiently verifying the origin and integrity of the code which could result in an attacker executing malicious code. IBM X-Force ID: 170046.
CVE-2020-4135
PUBLISHED: 2020-02-19
IBM DB2 for Linux, UNIX and Windows (includes DB2 Connect Server) 9.7, 10.1, 10.5, 11.1, and 11.5 could allow an unauthenticated user to send specially crafted packets to cause a denial of service from excessive memory usage.