Hacking Multifactor Authentication

Roger A. Grimes

• Publisher: Wiley
• Year: 2020
• Print ISBN: 9781119650799
• eBook ISBN: 9781119650805
• Edition: 1
• Topic: Informatique
• Subtopic: Cybersécurité

Protect your organization from scandalously easy-to-hack MFA security "solutions"

Multi-Factor Authentication (MFA) isspreading like wildfire across digital environments.However, hundreds of millions of dollars have been stolen from MFA-protected online accounts.How?Mostpeoplewho usemultifactor authentication (MFA)have been told thatitis far less hackablethan other types of authentication, or eventhat it isunhackable. You might beshocked to learnthatall MFA solutions areactually easy to hack.That's right: there is noperfectlysafe MFA solution.In fact, most can be hacked at leastfivedifferent ways. Hacking Multifactor Authentication willshow youhow MFA works behind the scenes and how poorlylinkedmulti-stepauthentication steps allowsMFA to be hacked and compromised.

Thisbook coversovertwodozenwaysthatvarious MFA solutions can be hacked, including the methods (and defenses) common to all MFA solutions.You'll learn about thevarious types of MFA solutions, their strengthens and weaknesses, andhowto pick the best, most defensible MFA solution foryour (or your customers') needs.Finally, this book revealsa simple methodforquickly evaluatingyour existing MFAsolutions.Ifusingor developing a secure MFA solutionis important to you, you need this book.

• Learn how different types of multifactor authentication work behind the scenes
• See howeasy it is to hack MFA security solutions—no matter how secure they seem
• Identify the strengths and weaknesses in your (or yourcustomers') existing MFA securityand how to mitigate

AuthorRoger Grimes is an internationally known security expert whose workon hacking MFA has generated significant buzz in the security world. Read this book to learnwhat decisions and preparationsyourorganization needsto take toprevent losses from MFA hacking.

II
Hacking MFA

• Chapter 5: Hacking MFA in General
• Chapter 6: Access Control Token Tricks
• Chapter 7: Endpoint Attacks
• Chapter 8: SMS Attacks

• Chapter 9: One-Time Password Attacks
• Chapter 10: Subject Hijack Attacks
• Chapter 11: Fake Authentication Attacks
• Chapter 12: Social Engineering Attacks

• Chapter 13: Downgrade/Recovery Attacks
• Chapter 14: Brute-Force Attacks
• Chapter 15: Buggy Software
• Chapter 16: Attacks Against Biometrics

• Chapter 17: Physical Attacks
• Chapter 18: DNS Hijacking
• Chapter 19: API Abuses
• Chapter 20: Miscellaneous MFA Hacks
• Chapter 21: Test: Can You Spot the Vulnerabilities?

5
Hacking MFA in General

Chapter 5 will cover hacking MFA generally, without showing any specific techniques. Anything can be hacked. Anyone telling you that they have something that can't be hacked is lying or naïve. Either way, they shouldn't be trusted. Multifactor authentication (MFA) has many components and supporting infrastructures many of which the MFA solution vendor has no control over, and each can be hacked by various means. This book is dedicated to showing dozens of ways that all, or specific implementations, can be hacked, although this particular chapter just addresses the topic in a generalized way.

This book will not be able to show all the ways MFA can be hacked, although I'll fit as many as I can within these pages. There are ways that I don't know about; I haven't thought of them or encountered them, or I've simply forgotten them. Many MFA vulnerabilities are only known to the potential attacker who is keeping them secret until they are otherwise needed. Or they are used sparingly and rarely in a way that the exploited victim isn't even aware of. The biggest nation-states have thousands of nonpublic vulnerabilities cataloged away, awaiting a specific need. Others are known by their vendors and kept secret because the vendor doesn't know a good way to mitigate the risk.

Many MFA vulnerabilities haven't been discovered yet. The world is full of examples of hacked things that had vulnerabilities that went undetected for decades, until they were finally discovered by a single, curious soul. Vulnerabilities often sit in plain sight for years, until someone reviewing the code or trying a specific action saw a potential weakness and explored it. Many vulnerabilities are found by accident. Someone is trying to do something new, such as extend or automate functionality, and they end up accidentally causing an error that reveals a previously unfound vulnerability.

Many, if not most, vulnerabilities will go undiscovered, without anyone recognizing the vulnerability that could be exploited. Humans are imperfect. Just as we can't stop all programming mistakes, we don't find every mistake or vulnerability. We will always create more vulnerabilities than we will find. It's just the nature of programming. Even the software that we design to specifically find vulnerabilities doesn't find every one; it can only find the vulnerabilities we all already understand and know how to find.

Chapter 5 is not only a generalized look at how MFA vulnerabilities are found, but also summarizes all the different components. This chapter should be used by nonmalicious hackers looking to ensure that an MFA solution they are considering is as secure as possible as well as by MFA developers to ensure that the solution they are delivering is as secure as possible from the start when they offer it to consumers. Nothing is vulnerability free, but by learning and using the lessons of past exploits, the number of future bugs can be minimized. Many of the discussions in this chapter apply to most digital solutions and not necessarily just authentication or MFA. The rest of Part II will cover specific examples of MFA vulnerabilities that illustrate the generalized vulnerabilities covered here.

MFA Dependency Components

No MFA solution is an island. Every MFA solution is just one part of multiple components, relationships, and dependencies, as visually depicted in Figure 5.1, and each of these components is an additional area where an exploitable vulnerability can occur.

Figure 5.1: MFA dependent components

Essentially any component in the entirety of the MFA's life cycle, from provisioning to deprovisioning and everything in between, is subject to having exploitable vulnerabilities and hacking. And like the proverbial chain, it's only strongest as its weakest link. Here is a list of the phases and components involved in MFA:

• Enrollment
• User
• Devices/hardware
• Software
• Authentication factors
• Authentication secrets store
• Cryptography
• Technology
• Network/transmission channel
• Namespace
• Supporting infrastructure
• Relying party
• Federation/proxies
• APIs
• Alternate authentication methods
• Recovery
• Migrations
• Deprovision

The rest of this section will explore these components in more detail. Some of this chapter will repeat terms learned in early chapters, but they are included here again for completeness and redundancy can’t hurt when discussing authentication systems.

Enrollment

Enrollment (also known as provisioning) is the process of a subject being registered and verified to get an authenticated identity (label). An unverified and unregistered subject is known as an applicant. They are applying for an authenticated identity. The credential service provider (CSP) asks for and receives one or more (unique) subject attributes, which can be used to clearly identify the subject. This process is known as identity proofing. The subject can enroll themselves or have another enrollment agent trusted by both the applicant and the CSP do it on their behalf.

A critical part of the process is that the CSP verifies the applicant's submitted attributes. Without the CSP strongly verifying the applicant's submitted attributes and ensuring that the applicant is who they say they are and that the submitted applicant attributes truly belong to the applicant, authentication is nearly worthless. How strongly the CSP verifies the identity and attributes of the applicant determines the level of assurance.

Think of the enrollment process like a person applying for a driver's license. The person must pass a physical driving test to show that they have basic driving skills, answer a set of knowledge-based questions to prove they know the “rules of the road,” and prove they are who they say they are. The latter involves providing sufficient proof to the driver license issuer (the CSP in this example in the United States is the Department of Motor Vehicles [DMV]) to get the official driver's license. The applicant does this by providing multiple forms of acceptable identity attributes, such as a birth certificate, Social Security card, and a bill sent to their home residence to verify the address. Years ago, the DMV didn't require as much assurance as they do now, but previous weak validation allowed serious identity crimes to occur, and so now the DMV requires stronger identity assurance.

But if you get a driver's license issued to you, almost anywhere (e.g., law enforcement, liquor store) that requests proof of your identity will accept the DMV-issued driver's license as proof of your identity. It's the same thing with CSPs. Any relying party that trusts the CSP will trust that a CSP-verified identity submitted by a subject to them is accurate. But if the CSP doesn't do their job and doesn't accurately verify the subject's identity and attributes before issuing a verified identity, then the whole process breaks down.

A good, everyday digital example of this is the use of Pretty Good Privacy (PGP) asymmetric encryption keys. Created in 1981 by Phil Zimmerman, PGP is a very popular encryption program that comes in both open source and commercial versions. Everyone who gets a PGP...

Table of contents

• Cover
• Table of Contents
• Introduction
• I: Introduction
• II: Hacking MFA
• III: Looking Forward
• Appendix: List of MFA Vendors
• Index
• End User License Agreement