Trustwave Unveils New Offerings to Maximize Value of Microsoft Security Investments. Learn More

Trustwave Unveils New Offerings to Maximize Value of Microsoft Security Investments. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Bypassing MFA: A Pentest Case Study

When a company implements multifactor authentication, the organization is usually confident that it’s using the best system possible. However, not all MFA is built the same and there are times when the MFA solution being implemented is not delivering the protection required.

Trustwave SpiderLabs teams have come across these situations while conducting penetration tests. This type of exercise, also known as a pentest or ethical hacking, is a simulated attack executed on an organization’s computer systems or physical facility to hunt for and uncover vulnerabilities. This enables security teams to identify weak spots in a company’s security posture before an adversary and one of the most important items to pentest is authentication, which leads us to the MFA problem at hand.

At Trustwave SpiderLabs we’ve found it’s generally a good idea to start in an unauthenticated position and work your way inward.

Authentication is always a good place to start for a few obvious reasons. It is literally the gateway between Internet traffic and the application/instance being assessed. If your engagement has a gaping hole in the authentication, it’s generally a really bad situation and something you’ll want to inform the development team about as soon as possible. Part of the authentication is testing an organization’s multifactor authentication solution if it’s implemented. (And if the subject being tested does not have MFA, it might be a good idea to suggest that this security measure be brought on board.)

Now, there are several very different things we can do to break through an MFA barrier. These include brute-forcing the MFA code with turbo intruder (yes you can also use the normal intruder module within burp) or getting the MFA code sent to an attacker-controlled email address. Here is one instance of a poorly implemented MFA portal that would allow an attacker to force the MFA code to their own inbox.

In the request, if it says something like:

email=client@SpiderLabs.com

you can try changing the request to something like:

email=client@SpiderLabs.com&email=attacker@SpiderLabs.com

or if it’s in a JSON request that looks like:

{“email”:”client@SpiderLabs.com”}

you can attempt to inject another email address:

{“email”:”client@SpiderLabs.com”,“email”:”attacker@SpiderLabs.com”}

There are also other methods like passing it in an array like:

{“email”:”[“client@SpiderLabs.com”,”attacker@SpiderLabs.com”]”}

Though I have had success with these methods, there are times when nothing seems to work. One assessment comes to mind when an organization’s security was hardened sufficiently to prevent these types of injections from manipulating the back end. Then I remembered a key component included with many authentication systems. It's the ability to help a user recover their login credentials. Remembering that the MFA solution had this ability enabled me to discover an MFA flaw. I found that the “Forgot Password” functionality at this organization sent a newly generated temporary password in clear text to the user via email. And… the MFA code was also sent via email.

Why is this an issue? Because in this case, MFA was not being used. This is a clear demonstration of two instances of single-factor authentication. This was clearly an oversight/misunderstanding by the development team. True MFA delivers authentication data via separate means… not using the same medium.

How is this a risk?

Let’s say an attacker gained access to a user’s email account. By having the password sent to the email address, the attacker can obtain valid credentials to trigger the first step in the login process in this application. Since the MFA code is then sent to the same email address, this implementation doesn’t provide any additional security. An attacker can log in, get the MFA code via the compromised e-mail account, and fully authenticate to the application. They can then move forward with any privileged actions (like changing the password) to establish persistence in the application.

Now the issue covered here is not something that I’ve seen often, but it did force me to get away from the technical side of the problem and look at the picture holistically. Sometimes, security issues are just based on logic and not on technical exploitation. Thinking like a hacker is just as important as being able to use tools and scripts like a hacker.

The best way to ensure that your MFA implementation is effective is to have it tested thoroughly. Self-testing does help validate some concerns, but it’s important to have a thorough assessment of the MFA controls by an offensive security team that has the tools and techniques necessary to keep application owners at ease.

Latest SpiderLabs Blogs

Network Isolation for DynamoDB with VPC Endpoint

DynamoDB is a fully managed NoSQL database service offered by Amazon Web Services (AWS). It is renowned for its scalability, dependability, and easy connection with other AWS services....

Read More

The Underdog of Cybersecurity: Uncovering Hidden Value in Threat Intelligence

Threat Intelligence, or just TI, is sometimes criticized for possibly being inaccurate or outdated. However, there are compelling reasons to incorporate it into your cybersecurity defense strategy....

Read More

Clockwork Blue: Automating Security Defenses with SOAR and AI

It’s impractical to operate security operations alone, using manual human processes. Finding opportunities to automate SecOps is an underlying foundation of Zero Trust and an essential architecture...

Read More