The document provides an overview of multi-factor authentication (MFA) implementation best practices and common mistakes. It discusses both the benefits of MFA in providing an extra layer of security beyond passwords, as well as potential downsides such as false security if not implemented properly. Examples are given of poor implementations, including not enforcing MFA, allowing insecure methods like SMS, and design flaws. Ideal implementations encourage the use of hardware security keys and push notifications with centralized administration and user training. Bypasses of MFA like man-in-the-middle attacks are also mentioned. The document concludes with a demonstration of using AI to assist with social engineering and phishing attacks.
Powerful Google developer tools for immediate impact! (2023-24 C)
CI-ISSA '23 - Bad Multi-Factor
1. Curtis Brazzell | CISSP
Managing Security Consultant @ GuidePoint Security
(My thoughts do not reflect.. blah blah.. Thanks Brad, for the pizza!! )
2. About Me
Local to This Community! (Brownsburg, IN)
Passionate about security since the 90’s
Former DBA/Sys Admin (4-6 years)
Security Consulting for 12+ years
SOC/IR Lead
DFIR Lead (Malware Analysis)
AppSec/Pentesting/Physical/Wireless/Architecture/Social Engineering
Currently an MSC for GuidePoint Security on the AppSec (Tactical) Team
Researcher/Blogger/”Author”
Presenting at BSides Fort Wayne on New Phishing Techniques!
3. Agenda
The Good, the Bad, and the Ugly Side of MFA
Examples of Poor Implementation (so many examples)
Nap
Even More Examples
Ideal Implementations (and their weaknesses)
Summary
Phishing Chat GPT PoC Demo
4. The “Good” Side of MFA
Extra layer of
protection
(something you
“have” or “are”)
Helps supplement
password security
(weak/reused/bre
ached credentials)
One of the
strongest
preventative
measures against
account takeover
5. The “Bad” Side of MFA
Insecure mediums (SMS, still better
than none)
Mobile authentication on mobile
platforms (Mixing “know” and
“have”)
Lost/stolen hardware and recovery
User opt-in (“We support it”)
6. The “Ugly” Side
of MFA
Bad user experience (Balancing user
convenience with security)
False sense of security
Not a silver bullet
User awareness training (locations/IPs, real-time
prompts, alternative methods)
Twitter charging extra for MFA
Poor implementations
7. Examples of Poor Implementation (BMF)
Implemented, But Not Enforced
Sometimes there are friendly reminders
Can jump into an account with only a password
Supporting and enforcing are not the same
Leaves security to the user (opt-in)
User preference of convenience over security
Don’t leave enrollment a choice for critical apps
If you do this, train your users and make MFA simple
Importance of protecting users (data exposure,
increased attack surface, etc)
8. Examples of Poor Implementation (cont.)
Less-Secure Methods Accepted
Recovery codes unsecured on filesystems
PINs/Tokens users’ type
9. Examples of Poor Implementation (cont.)
More PhishAPI (Real-time Phishing Framework)
MFA Requirements
Gamified
10. Examples of Poor Implementation (cont.)
Less-Secure Methods
Accepted
Even if SUPPORTED and
not the default, it’s still
a problem! (path of
least resistance)
Use hardware tokens or
push as the default?
Forms can be set to
only prompt for tokens!
11. Examples of Poor Implementation (cont.)
Less-Secure Methods Accepted
SMS Interception (“SMS ain’t no county I ever heard of!)
Seriously though, why’s this a problem?
No end-to-end encryption
SIM Swapping / Cloning / SE attacks
12. Examples of Poor Implementation (cont.)
Open Enrollment
Enforced, but at the user’s leisure or next login
Beat user to self-enrollment on attacker-owned device
Simply logged in as user and approved as they would
Sessions can be too long, won’t apply until next auth cycle if
already logged in when applied.
Huge security gap (20% of captured creds were not enrolled
yet. Customer was blindsided.)
13. Examples of Poor Implementation (cont.)
Infinite or Overly Long Enrollment Period
Increased risk when combined with Open Enrollment
Can’t assume users will access or within reasonable timeline (PTO, lack of need in roles, VPN, etc)
14. Examples of Poor Implementation (cont.)
Infinite Re-Enrollment (Link Doesn’t Expire After First Use)
Enroll again as attacker
Stale enrollment links in email can be exposed in logs or discovered by attackers
Not really an issue with most current MFA solutions
15. Nap
Anyone awake?
Survey room. If no one is awake grab pizza and quietly slip out. Otherwise, continue.
16. Examples of Poor Implementation Use
Users Accepting Attacker’s Push Requests
Timing is everything! (don’t assume)
Always review IP/Location information! (not all MFA solutions provide this)
Annoyance factor / alert fatigue
Confusion (lack of training, IT must need something, background process, location
with travel or VPN, etc)
Shockingly effective 🙈
17. Examples of Poor Implementation (cont.)
MFA is Disabled After Email Change or Password Reset
If enrollment is optional or not continuously enforced, it can lead to a gap of protection
Shouldn’t be performed automatically but as a centralized admin control (help desk ticket, etc)
18. Examples of Poor Implementation (cont.)
Logic Flaws (Homebrew Bad Design)
Ignoring or canceling MFA prompt still creates session (recent example)
“Forgot PIN” functionality reset with just a username and password (recent example)
PINs in mobile apps might be bypassed by hiding a view (recent example) – Hooking in Objection
Biometrics don’t tie to a specific user of the device (recent example)
Reset instructions go to email instead of phone number
19. Examples of Poor Implementation (cont.)
Insufficient Anti-Automation
Low entropy (last 4 SSN, phone, DoB, etc)
No rate-limiting server-side
No lockout policy
Brute Forcing until valid value is determined
20. Examples of Poor Implementation (cont.)
Security Questions
Security questions by themselves are NOT MFA (just something else you “know”)
Should NOT be Boolean values, years, or other short values (I’ve seen DoB & Last 4 SSN combos)
Should NOT be easily enumerated with wordlists (teacher’s first name, etc)
Should NOT be easily researched (OSINT, Google phone # example!)
Okay if used as an additional piece of user verification (usual login activity, etc)
21. Examples of Poor Implementation (cont.)
Security Questions (Google example)
Wrong way Google to do it (Something you know) A better way of handling it (Something you have)
22. Examples of Poor Implementation (cont.)
MFA Code Reusability
Say the code has high entropy and the server is rate-limiting with account lockouts…
Is the code invalidated after use?
Can I get a token as an attacker and apply it to a victim account?
23. Ideal Implementations
Still not a silver bullet!
My recommendation for best hardening practices?
Forced enrollment for all (when possible)
Short, one-click enrollment period (no first-time login)
Use U2F hardware proximity devices only (BLE, USB, NFC, etc - no tokens/pins/or hardware with tokens)
If implemented properly, some biometric auth is great!
If you can’t use U2F, use mobile push notifications
Central administration
Trusted SSO/MFA Providers (Okta, MS, Duo, OAuth, Auth0, etc)
Employee Training (prompts, backup methods, etc)
Mobile Device Management (for mobile MFA)
Alert on and monitor unsuccessful attempts
Bypass techniques STILL exist:
Machine-in-the-Middle (MitM) Session Hijacking (stealing tokens post-authentication)
Transparent/Reverse Proxies (Attacker’s fake login makes requests on behalf of users to facilitate login)
Assets not protected by MFA (internal, etc) – Don’t give up on password security!
26. Summary
MFA is a GOOD thing overall (don’t
discourage SMS to the point devs or execs
only use creds)
If done properly, it will greatly reduce
successful account takeover attacks (SE,
credential stuffing, brute forcing, cracking,
etc)
If done perfectly, users are still exposed to
some risk. Training is essential!
Sophisticated Phishing (and Vhishing)
attacks are increasingly sophisticated
(Deepfakes, AI, etc)