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

11/19/2019
01:00 PM
Nicole Sette
Nicole Sette
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

I 'Hacked' My Accounts Using My Mobile Number: Here's What I Learned

A feature that's supposed to make your account more secure -- adding a cellphone number -- has become a vector of attack in SIM-swapping incidents. Here's how it's done and how you can protect yourself.

As a director at a cyber-risk investigations company and a former FBI cyber analyst, I'm very familiar with SIM-swapping threats. For many people, the term SIM swapping conjures up an image of a hacker tapping into a phone company, or foreign fighters swapping out SIM cards to avoid government surveillance. In reality, SIM swaps are a legitimate function that happens daily at phone companies around the world. At the most basic level, a SIM swap is used by a telephone service provider to transfer an individual's existing mobile phone number to a new SIM card and phone.

Unfortunately, criminals have learned to use SIM swapping to turn a profit. Criminals trick or bribe phone company employees into transferring a victim's mobile phone number to a new SIM card and phone controlled by the criminal. But why would a criminal want to gain control of someone's mobile phone number?

Enter the modern concept of mobile phone authentication. This is the practice employed by online service providers to verify a user's identity by sending a one-time password to a mobile phone number that previously was linked to that account using two-factor authentication (2FA). While this is an easy way of resetting forgotten passwords, it also allows anyone in control of that mobile number to gain access to email, social media, and financial accounts tied to that number. If the Greek warrior Achilles is representative of 2FA in all its glory, then SMS-based mobile phone authentication is Achilles' heel.

Hacking Three Accounts with One Phone Number
The idea of hacking someone with their phone number was so intriguing, I decided to simulate the hacking of my own accounts using just my mobile phone. I started with my Twitter account, where I selected "Forgot password?" and received an "Enter phone number" option. At this point, I didn't remember ever connecting my Twitter account to my mobile number but figured I'd try.

I immediately received a one-time passcode from Twitter and was able to read the code via a notification on the locked screen of my cellphone. Upon entering the code into Twitter's website, I was prompted to enter a new password and gained full control of the account. Since SMS notifications appear on my phone's locked screen, anyone with physical access to my phone and my phone number could have taken over my Twitter account.

The most disturbing thing about my Twitter experiment is the knowledge that any family member, friend, or co-worker who had my phone number could enter it in Twitter's "Forgot password?" field, pick up my locked phone to view the one-time password, and gain full control of my account. A SIM swap wasn't even necessary.

The privacy implications of this scenario are unsettling, but this also highlights the potential for an individual to have offensive content sent out from their social media accounts, or worse, become implicated in a crime committed by someone who gained control of their accounts. The intruder (for example, estranged spouse or vindictive co-worker) would only need access to the victim's phone number and locked phone. I did receive an email alert from Twitter that my password had been reset, but an attacker could gain access to my email account using the same technique and delete any notifications.

Bolstered by the hack of my Twitter account, I used the same technique against my dated Hotmail account, and achieved the same result. The steps for Hotmail included clicking "Forgot password," entering my (very guessable) email address, and following a prompt to enter my mobile number. A one-time password was sent to my cellphone, allowing me to reset my password and gain access to years' worth of email correspondence, all while bypassing the complex password I had set up for the account. I was starting to see how easily a SIM swapper or nosy individual could gain access to a variety of accounts by controlling a phone number.

At this point, I was in "think like an attacker" mode and searched my Hotmail inbox for financial statements. I found an email from a financial institution and clicked on "View statement." Hacking the financial account required a bit more effort than just entering a mobile number, but the only additional hurdle was entering a Social Security number, which can often be purchased on Dark Web marketplaces. At this point in my experiment, I had gained access to a social media account, an email account filled with financial statements, and a financial account from which I could transfer funds.

Lessons Learned
What did I learn from hacking my accounts with my mobile phone? Mainly, if my accounts hadn't been linked to my mobile phone and were solely protected by the complex passwords I use, they would have been more secure.

Many online providers suggest adding a mobile phone number as a way to implement 2FA — that is, 1) something you know and 2) something you have. Indeed, 2FA is used to initially link a user's phone number to an online account; however, after the initial confirmation of the phone number, the authentication process often reverts back to single-factor authentication (a phone number) for authenticating accounts.

The false sense of security encouraged by the SMS-based authentication scenario leaves users vulnerable to SIM-swapping attacks and privacy vulnerabilities. Unless you have disabled certain notification features on your phone, someone with access to your locked phone could gain access to your social media, email, and potentially financial accounts with only a publicly available phone number and email address.

The Takeaway
This experiment has spurred me to make some immediate changes, which I suggest you consider doing as well: 

  • I will be deleting my phone number from my online accounts and will authenticate to accounts with complex passphrases and more-robust 2FA options, like Google Authenticator, Microsoft Authenticator, Duo, or a USB hardware authentication device such as YubiKey. (I obviously won't be linking my mobile phone number to these 2FA applications.)
  • I will protect sensitive email contents by archiving and backing up email so it's not accessible to an intruder if I'm hacked.
  • To protect against SIM swapping, I will add a PIN to my mobile account and plan on requesting that SIM transfers only take place in person for my account.
  • To deter mobile phone authentication attacks from opportunistic snoopers, I have disabled notifications on my phone's lock screen.

Bottom line: A key feature advertised to make your account more secure — adding a mobile phone number — has actually proved to be a vector of attack in a growing number of SIM-swapping incidents. The security and privacy implications of this are serious, and the industry needs to move toward more secure authentication mechanisms in lieu of SMS-based mobile phone authentication.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "How Medical Device Vendors Hold Healthcare Security for Ransom."

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
CharlotteSmithAG
50%
50%
CharlotteSmithAG,
User Rank: Apprentice
11/23/2019 | 3:04:19 AM
Re: Common Sense always rules out
Looking forward to more details regarding it
tdsan
50%
50%
tdsan,
User Rank: Ninja
11/21/2019 | 1:32:31 PM
Re: Common Sense always rules out

One thing I didn't elaborate on in the article is that both my Pixel and Apple phones' default settings with notifications 'turned on' reveal the first line of a text on the notifications screen. [The onetime code comes through usually since it's in the first line].

I do believe it is less user-error and more of a structural/endemic vulnerability, since the presumption is that a majority of users will leave their phones on the default setting. [Please correct if I'm wrong about that - it's possible that the default for notifications varies for different versions of different mobile phones]
  • Interesting point, so from a technical and security standpoint, most individuals will install certain security tools (controls) to ensure or reduce the chances of it being compromised. A number of security individuals verify the patches are up-to-date, install Antivirus, HIDS, Firewall and other mechanisms (checks and balances). The same should apply to the phone, it is not any different since the operating system is based on Linux or Linux variant. So in this case you may be wrong about that, they give you the box but it is up to you on how to fill it. We should apply the same principles to the phone as we do the computer.

T

 

 
CyberLady
50%
50%
CyberLady,
User Rank: Author
11/21/2019 | 1:18:55 PM
Re: Common Sense always rules out
Todd,

Thanks for your feedback. I enjoyed reading your responses to the different sections of the paper.

One thing I didn't elaborate on in the article is that both my Pixel and Apple phones' default settings with notifications 'turned on' reveal the first line of a text on the notifications screen. [The onetime code comes through usually since it's in the first line].

Since it's my understanding that this is the 'default' notifications setting for many cell phones, I do believe it is less user-error and more of a structural/endemic vulnerability, since the presumption is that a majority of users will leave their phones on the default setting. [Please correct if I'm wrong about that - it's possible that the default for notifications varies for different versions of different mobile phones]. I don't have any statistics on the topic, but in our era of convenience over security, I do belive most (non-infoSec) users opt for notifcations on their phones. 

I agree that much of security is the responsibility of the user. And, I guess, my hope is to help educate users who have their notifications turned-on for messaging, that this can be an issue. I also agree that this is not any sort of traditional 'hack' - the title was mean to be a bit tongue-in-cheek. 

Thanks again for the perspective. I will incorporate your feedback into this topic as a present or write about it in the future. 

Cheers,

Nicole
tdsan
50%
50%
tdsan,
User Rank: Ninja
11/21/2019 | 12:50:20 PM
Common Sense always rules out

I immediately received a one-time passcode from Twitter and was able to read the code via a notification on the locked screen of my cellphone. Upon entering the code into Twitter's website, I was prompted to enter a new password and gained full control of the account. Since SMS notifications appear on my phone's locked screen, anyone with physical access to my phone and my phone number could have taken over my Twitter account.
  •  You have actually addressed some of what I am going to say in the later parts of your response but first of all, why would the user allow text messages to be displayed on a locked screen. The phone makes a sound and informs the user they have a new text message. But to Twitter's point, they can't think for you, that is up to the end user. When things happen like this, the accountability is on the end-user because they have not taken the precautions to address basic security concerns.

 
The most disturbing thing about my Twitter experiment is the knowledge that any family member, friend, or co-worker who had my phone number could enter it in Twitter's "Forgot password?" field, pick up my locked phone to view the one-time password, and gain full control of my account. A SIM swap wasn't even necessary.
  •  Again, how can we blame Twitter for leaving the door open. That is almost like leaving your door open when you leave for work, you're asking for trouble. Again, common sense comes into play here and with a number of different situations (i.e. CapitalOne, Marriott, Accenture, etc). In the S3 bucket situation, there is a section in AWS that says "Block All Public Access", what more can they do, it is a service.

 
Many online providers suggest adding a mobile phone number as a way to implement 2FA — that is, 1) something you know and 2) something you have. Indeed, 2FA is used to initially link a user's phone number to an online account; however, after the initial confirmation of the phone number, the authentication process often reverts back to single-factor authentication (a phone number) for authenticating accounts.
  • I do think MFA/2FA is great, but if the person leaves their phone open (where the vendor thinks the phone is suppose to be with the user and locked -no sensitive info on the screen - since it has sensitive data), that is even a problem. Again, it comes to making good choices. This is not a hack, because you have the phone. The hack comes into place when you don't have the phone and they are able to figure out the sequence of the TOTP codes being used or they capture the string or QRCode that you used to create the TOTP process.

The points are valid but the problem with the argument is that you had the phone in your possession and did nothing during the time you had the phone in use (did not follow best practices). So it is not up to the vendor, it is a service the vendor has made available to the end-user. If the end-user does not take the necessary steps to lock their home (rhetorical), then anyone can enter even with MFA/2FA (common sense and basic security steps).

Todd
SOC 2s & Third-Party Assessments: How to Prevent Them from Being Used in a Data Breach Lawsuit
Beth Burgin Waller, Chair, Cybersecurity & Data Privacy Practice , Woods Rogers PLC,  12/5/2019
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19619
PUBLISHED: 2019-12-06
domain/section/markdown/markdown.go in Documize before 3.5.1 mishandles untrusted Markdown content. This was addressed by adding the bluemonday HTML sanitizer to defend against XSS.
CVE-2019-19616
PUBLISHED: 2019-12-06
An Insecure Direct Object Reference (IDOR) vulnerability in the Xtivia Web Time and Expense (WebTE) interface used for Microsoft Dynamics NAV before 2017 allows an attacker to download arbitrary files by specifying arbitrary values for the recId and filename parameters of the /Home/GetAttachment fun...
CVE-2019-19617
PUBLISHED: 2019-12-06
phpMyAdmin before 4.9.2 does not escape certain Git information, related to libraries/classes/Display/GitRevision.php and libraries/classes/Footer.php.
CVE-2012-1114
PUBLISHED: 2019-12-05
A Cross-Site Scripting (XSS) vulnerability exists in LDAP Account Manager (LAM) Pro 3.6 in the filter parameter to cmd.php in an export and exporter_id action. and the filteruid parameter to list.php.
CVE-2012-1115
PUBLISHED: 2019-12-05
A Cross-Site Scripting (XSS) vulnerability exists in LDAP Account Manager (LAM) Pro 3.6 in the export, add_value_form, and dn parameters to cmd.php.