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.

Risk

2/3/2020
10:00 AM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

How Device-Aware 2FA Can Defeat Social Engineering Attacks

While device-aware two-factor authentication is no panacea, it is more secure than conventional SMS-based 2FA. Here's why.

In the ever-escalating arms race between attackers and defenders, the latest defense to crumble under fire is two-factor authentication (2FA). Hackers have become increasingly successful in using social engineering techniques that defeat 2FA and let them take control of victim accounts.

Many of these attacks, however, including account takeover using SIM-jacked phone numbers, can be thwarted by restructuring part of the authentication process, using a minor modification to existing methods. It's a shift from account-based 2FA (usually using SMS one-time passcodes, or OTPs, sent to registered phone numbers) to device-aware 2FA. Using device-aware 2FA, the bank, email service or other service provider only accepts attempts coming from a recognized device previously associated with the account.

How Attackers Defeat 2FA with Social Engineering
SMS-based two-factor authentication has been widely adopted by service providers including financial institutions, email services, social networks and online marketplaces. Among consumer websites using any form of 2FA, about 57% use SMS OTPs, according to data derived from a 2019 report by Javelin Strategy & Research.

Websites using SMS-based 2FA send a code by SMS to the registered cellphone number. The user then types or pastes this code into the website. Attackers can obtain that code either by hijacking the cellphone number through SIM-jacking, or by using social engineering to trick the victim into giving the code to the attacker.

In SIM-jacking, with a bit of competent social engineering and persistence a scammer can convince an employee of a wireless carrier to transfer a victim's telephone number to a new SIM card used by the attacker's phone. The attacker then starts receiving all SMS OTPs sent to the victim, putting all of the victim's accounts associated with those SMS passcodes at risk of takeover.

Awareness of SIM-jacking and other threats to multifactor authentication (MFA) is rising, though to date few technical solutions have been identified. In September, the FBI warned that cybercriminals are using social engineering and technical attacks to circumvent MFA. In a widely publicized incident in August, an attacker took over the Twitter account of Twitter CEO Jack Dorsey by SIM-jacking his phone, and then used the account to tweet Nazi propaganda.

In November, Twitter began allowing users to choose to use 2FA methods other than SMS-based 2FA. But the options offered (authenticator apps and security keys) have their own vulnerabilities, including technical or social engineering risks. Rather than solving the problem, Twitter now in effect allows the users to select which vulnerability they face.

Using Device-Aware 2FA to Thwart Account Takeover
Account providers can implement a more secure version of 2FA by switching the method of authentication. Conventional SMS-based 2FA requires the user to prove she has access to the phone number associated with the account. With device-aware 2FA, the user must prove she has access to both the phone number and the actual phone (or other device) associated with the account. (From the user's perspective, no extra step is required.)

With conventional SMS-based 2FA, the website sends an SMS containing the passcode. With device-aware 2FA, the website instead sends an SMS with one or more clickable links, for example, the question "Have you asked to reset your password?" with two clickable answers, representing "Yes" and "No." When the user clicks on the "Yes" link, the device profile is automatically checked by the website.

Unless the attacker has also stolen the victim's phone and unlocked it, the attacker's device won't be recognized as having been previously associated with the account, and the website will deny access. (If the user clicks "No," both the user and the site become aware of the attack and can take actions to restore security.)

Methods for Recognizing Devices
Device-aware 2FA takes advantage of device-identifying technologies that are already widely deployed, but uses them differently. These device-identifying technologies, which can be used in combination, include various types of cookies placed by a website onto a device; "read-only" browser characteristics like the "user agents" and related local data that websites normally check in order to send the correct display instructions for the particular device type; and other characteristics such as network name, carrier name, and geolocation.

Almost all websites already use cookies and other device identifiers, whether for personalization or fraud detection. In fact, 2FA is often activated if a user attempts to log in from an unusual location or a device that is not recognized. Options for identifying devices include standard HTML cookies and variants such as flash cookies or cache cookies.

When a user accesses a website, the website is also able to check the characteristics of the user's web browser, such as browser type and version installed, touch-screen support, system fonts installed, languages installed, screen size, color depth, time zone, and browser plug-in details. While these digital fingerprints aren't unique to each device, there are so many permutations of user hardware and software attributes that it is highly unlikely an attacker's device will share a common fingerprint.

Special Case: New Device
New security measures often impose some friction on normal activity. For device-aware 2FA, the added friction is minimal in most situations. The device used to establish the account (or to set up 2FA for the first time) would be automatically linked to the account. If the user accesses the site from a new device, the site could send a device-aware 2FA message to the old device to obtain authorization. If the authentication succeeds, and the user states that the new device indeed belongs to her, then the new device will be automatically enrolled, and then it can be used to approve future device-aware 2FA verifications. Other options for adding new devices to a user profile include allowing a new device to be authorized by scanning a QR code displayed on the original device, or allowing access from a new device if the device shares browser settings (such as a synchronized Google Chrome account) with the original device.

But what happens if the user replaces his phone and has no other device enrolled? Nearly all institutions provide escalation methods to regain access to accounts even if a user has lost access to the cellphone number or email account used for authentication. Similar escalation procedures can be used with device-aware 2FA if the user replaces or loses his phone. For example, the user might be asked to respond to knowledge-based authentication questions, or to accurately report very small payments made to a checking account already associated with the user.

While device-aware 2FA is more secure than conventional SMS-based 2FA, it is of course no panacea. In the endless game of leapfrog that security professionals play with cybercriminals, nearly every security method can be eventually defeated by a determined and resourceful attacker. All we can do is continue making our leaps smarter and longer.

For more research details, click here.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "7 Steps to IoT Security in 2020."

Markus Jakobsson, chief scientist for ZapFraud, has worked for more than 20 years as a security researcher, scientist, and entrepreneur, studying phishing, crimeware, and mobile security at leading organizations. He leads ZapFraud's security research with a focus on using ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/21/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-24213
PUBLISHED: 2020-09-23
An integer overflow was discovered in YGOPro ygocore v13.51. Attackers can use it to leak the game server thread's memory.
CVE-2020-2279
PUBLISHED: 2020-09-23
A sandbox bypass vulnerability in Jenkins Script Security Plugin 1.74 and earlier allows attackers with permission to define sandboxed scripts to provide crafted return values or script binding content that can result in arbitrary code execution on the Jenkins controller JVM.
CVE-2020-2280
PUBLISHED: 2020-09-23
A cross-site request forgery (CSRF) vulnerability in Jenkins Warnings Plugin 5.0.1 and earlier allows attackers to execute arbitrary code.
CVE-2020-2281
PUBLISHED: 2020-09-23
A cross-site request forgery (CSRF) vulnerability in Jenkins Lockable Resources Plugin 2.8 and earlier allows attackers to reserve, unreserve, unlock, and reset resources.
CVE-2020-2282
PUBLISHED: 2020-09-23
Jenkins Implied Labels Plugin 0.6 and earlier does not perform a permission check in an HTTP endpoint, allowing attackers with Overall/Read permission to configure the plugin.