How 2FAs are faring in the 2020s?
Author: JP and Team Silence Laboratories.
Chapter 1: 2FAs in deployement are not enough to be trusted for accessing high risk services and transactions.
There has been never a better time to adopt two/multi-factor authentication for the security of our digital interactions. Without going into details of much prevalent statistics on recent attacks on account takeovers, this series of posts will primarily focus on the state of widely used methods of 2FA, suggest remedial strategies, highlight how our Silent Auth MFA framework handles the raised concerns and would lay down a plan for usable and secure architecture.
Phishing attacks have seen 660% rise in 2021 and total loss due to cybercrimes is expected to hit around $6 trillion in 2021.
Mobile devices, smartphones, smartwatches, or other forms of wearables, form the core of contemporary authentication policies and methods. The majority of IAM providers have their own applications enabling different modalities in their authenticators: Approve Push for 2FA or passwordless login, biometrics, and in-app TOTP code generators.
These form part of the core trust and authenticator ecosystem of enterprises, banks, and agencies. The core focus of IAM companies has been on ease of integrations and back-end engineering for higher orders of reliability and network security. Little changes, in past few years, in the way end-users perceive and interact while performing 2FA, are solid proof of the thought processes and the direction of the authentication industry. We investigate how these 2FAs are performing, highlight some key vulnerabilities, and suggest few steering directions. Above all, we suggest how novel authenticators developed by Silence Laboratories fixes these concerns.
- Issues with using SMS Based 2FA: While outdated by NIST [1] back in 2016, SMS OTP codes are still being used dominantly across the geographies and enterprises. SMS OTP-based 2FAs are vulnerable to a) SS7 attacks, b) SIM Swapping, and c) Malwares and Trojans which exploit OS features or trick users to provide permissions for reading messages and hence bypassing 2FAs. Above all, the friction in reading, memorizing, and typing codes, further adds to the usability concerns of potential 2FA adopters.
2. Issues with using TOTP PIN-based 2FA: While little better than the SMS approach in usability (offline code generation), TOTP has been fairly accepted as a more secure way. But lately, several malwares and banking trojans have surfaced which challenges the potential large-scale adoption, other than the friction of reading and typing codes.
Possible Attacks and Vulnerabilities on TOTP based 2FA:
Majorly, TOTP-based authenticators have been challenged by two (individually and hybridized versions) directions of attack: a) Overlay and b) Android Accessibility Service (AAS) Mode.
A. AAS: Accessibility service is turning out to be the Achilles’ heel of the Android-based authentication ecosystem. The Accessibility Service allows, to make smartphones more accessible to users with special needs, such as enabling extension of permissions to an application to read and intercept window content (e.g. for providing text to speech synthesis capability), perform gestures (swiping, tapping buttons, activating/focusing certain areas on the screen, etc.) and receive notification and listen to all the interactions of the user with an application.
As shown in the above figure, AAS gets permission to observer and perform critical interactions. Hence, an application can capture credentials entered by the user on mobile banking apps, read or generate SMS messages, read emails and even read Two-Factor Authentication (2FA) codes generated by authenticator apps!
To make matter worse, AAS is a service and can perform actions in the background. This has led to the design and popularity of multiple malwares are banking trojans such as Cerberus, TrickBot, DEFENSOR ID, TeaBot, Oscorp, Toddler. These malwares listen to all interactions of the user in the background and identifies when the user access the token application, reads the code, and send it to the attacker’s server. They also can grab the contents of an interface such as TOTP PIN codes from the authenticator apps in a programmatic way, send vital information to an attacker-controlled server, bypass 2FAs and perform account takeovers.
Paypal, as reported by ESET, was the victim of such attacks where malwares abused Android’s Accessibility Services to interact with Paypal’s mobile application and mimic a user’s input in order to perform fraudulent transactions on its behalf. Even if the victim has an MFA method enabled, the malicious application can interact with the application, bypassing this protection. PayPal trojans also used the gesture and touch emulations, together with the text field autocompletion, to quickly insert the attacker’s email to the list of payees and proceed through the app’s activities, and executing a transfer.
As reported in [2], AAS is badly exploited to gain access to authenticator codes by Oscorp, which also abuses accessibility permissions to detect events that occur in a specific wallet application, to determine the available balance of different cryptocurrencies, and ultimately tries to send the cryptocurrency to the attacker’s Bitcoin address [2].
B. Overlay with AAS: Cloak & Dagger attack [5] is a sophisticated representation of dangers which hybridization of overlays and AAS can bring in. Even if malware can’t convince the user to give the accessibility permission, the user is tricked by overlay windows as suggested on Cloak and Dagger attacks. While for current versions of Android, it’s not possible to configure accessibility settings in case an overlay is active, or Android automatically disables any overlays when going into the Accessibility settings page, attackers can use malware with social engineering and trick users to install and grant this permission, as proven by numerous baking trojan apps.
3. Issues with using Tap to Approve Push Notification Based 2FA: In the case of the tap to approve method, whenever a user attempts to log in to an application or web service, and enters the correct credentials, the token device receives a push notification. When the user opens/taps on the notification, a screen overlay requests if the user wants to approve or deny the login attempt.
Being more usable than OTP-based TFA, push notification assisted authentication has witnessed growing user adoption as reflected in the success of Duo Security and commercial adoption by software and service giants like Twitter, Yahoo, Google and academic entities.
A. Concurrency Attack: While the approach is much usable and has been gaining popularity, it was proven in recent research at ASIA CCS 2021 [3] (published by collaborators and the author) that the tap to approve method is vulnerable to concurrency attack. An attacker with access to the compromised account (username and password pair), attempts to log in at exact same time as the legitimate user (Alice). The push notification prompts ask the user to tap on the “Yes” or “No” button. The only differentiating information from the login attempt of an attacker is the location name, usually given as coordinates. However, this information is too coarse and gives ample scope of the attack. Also, the attacker can spoof the location. The legitimate user would have no definite way to identify the correct push notification or even the possibility of an adversarial login, and they will most likely approve the attacker’s notification. Eventually, Alice is habituated to click “Yes”/ “Approve”.
Conncunrcy attack on the push-based 2FA is shown in the clip below. The attacker can launch sophisticated versions of concurrency attacks and easily gain access to the victim’s account.
To better understand this attack context, we simulated the situation of concurrent logins with 75 pairs of legitimate users and the attacker. The study set consisted of diverse personas, including undergraduate students of different streams, faculties, corporate employees from both business and information technology(IT) domains, and retired and old users. Statistically, only 5% of people (mostly comprising of IT employees and a few university students) raised doubts when receiving such notifications in the concurrency attack. Most of the people approved both approve attempts of the push notification. We concluded that their action was due to the consistency in the user interface (UI). Regular users of this form of authentication have formed a habitual reflex to tap “Approve” without looking at any other details. This habituation effect is further corroborated by studies conducted in [4], [3] where researchers suggest that most security notifications get unnoticed due to the habituation of users. Some users find it normal to receive multiple near-concurrent push notifications as they are habituated to being stuck in such loops due to mobile network discrepancies and delays. We also conducted automated tests to investigate concurrency attacks on deployed platforms. We noted that the concurrency attacks affect DuoPush, Dropbox, Facebook, LastPass, TransferWise, Authy, Okta and many more services. The above figure demonstrates concurrency attack scenarios for Dropbox, Duo-push and TransferWise. The concurrency attack stems from the fact that the login notification is not explicitly linked to the login session running on the browser in the Just Tap approach to push authentication. Therefore, if the user receives two notifications simultaneously, there is no way to tell which of the two notifications actually correspond to the browser session that the user-initiated.
Solutions: A detailed outline of the solutions, with a special focus on those designed by Silence Laboratories, will be presented in Chapter 2 of the series.
Silence Laboratories has designed a risk adaptive authenticator framework called Silent Auth. We bring in endpoint risk adaptations to further support network and service-based adaptations which are currently in practice. Single modality, as in practice now, for transactions involving 10$ and 100,000$ is not convincing enough and we are owed to empower much granular modalities and feedbacks while performing authentications.
All these, while ensuring frictionless approach.
Chapter 2 will dive deeper into the novelties and how Silent Auth solves the issues mentioned in 2FAs of the 2020S.
Please feel free to contact at info@silencelaboratories.com for further details and discussion.
References:
[1] NIST https://pages.nist.gov/800-63-3/sp800-63b.html
[2] https://www.revelock.com/en/blog/oscorp-android-banking-trojan-to-steal-cryptocurrencies-and-2fa-codes
[3] https://dl.acm.org/doi/10.1145/3433210.3453084, Mohammed Jubur , Prakash Shrestha , Nitesh Saxena , Jay Prakash, ASIA CCS ’21: Proceedings of the 2021 ACM Asia Conference on Computer and Communications SecurityMay 2021
[4] B. B. Anderson, C. B. Kirwan, J. L. Jenkins, D. Eargle, S. Howard, and A. Vance, “How polymorphic warnings reduce habituation in the brain: Insights from an fmri study,” in Proceedings of the 33rd Annual ACM Conference on Human Factors in Computing Systems, 2015
[5] https://www.blackhat.com/docs/us-17/thursday/us-17-Fratantonio-Cloak-And-Dagger-From-Two-Permissions-To-Complete-Control-Of-The-UI-Feedback-Loop.pdf
