How I bypassed 2-Factor-Authentication on Google, Facebook, Yahoo, LinkedIn, and many others

I remember fondly two years ago, when 2-Factor-Authentication (2FA) became popular and well used across major web applications (Google, Facebook, Yahoo and others). I found, my naive sixteen year old self unable to come to terms for why the genius idea had not been thought of before. At the time, I felt that 2FA was that golden shield you could cover yourself with and defend against some of the most sophisticated phishing attacks calmly.

Whilst 2FA can still be that golden shield to the critical applications you use in your life, I shall be documenting below - using an array of exploitation methods, how I was able to bypass 2FA for Google, Facebook, Yahoo, LinkedIn and basically any service which sends 2FA tokens to voicemail.

Note: More than 9.59 million Australian Optus mobile subscribers are affected by the voicemail hack I detail below. Anyone from that 9.59 million with 2FA enabled, is vulnerable to the 2FA bypass I document below.

Table of Contents

1. Analysis of 2FA, Concept and Flow of Exploit
2. Disclosure to Google Security Team
3. Disclosure to Facebook Security Team
4. Disclosure to LinkedIn Security Team
5. Disclosure to Yahoo Security Team
6. Disclosure to Authy & Duosecurity - (Universal 2FA Provider) - Not Vulnerable
7. Mitigation Techniques and Disclosures to Telco's
8. Final notes

Analysis of 2FA, Concept and Flow of Exploit

Analysis of 2FA

When looking at 2-Factor-Authentication as a whole, there are only so many things that one can see in the attack scope. In my first analysis of 2FA, I always wondered if it were possible to do the following attacks:

• Bruteforce the 2FA pin (Some services such as Apple, only have a 4 digit pin with hardly any rate limiting).
• Find any exploitation vectors within the flow that could let me do a complete bypass of 2FA.
• Discover a flaw in the generation of pins.
• Somehow steal session tokens, after 2FA occurs, so that the attacker can also log into the account without going through 2FA.

The above techniques are all valid vectors of attack, but they're usually unlikely to be present, as they are so orthodox and already have been defended against.

After I got past this stage of preliminary examination, I enumerated further and realised that there was a definite weak point in all 2FA services which allowed for the complete bypass of 2FA for an attacker. That weak point, is voicemail.

Some readers might see how voicemail is problematic, as they may be aware of the scandal in 2009 in the UK which lead to the hacking of celebrities voicemail accounts. Their method to gain access to voicemail were fairly worrying, being split up into the following: Default voicemail PINs, No voicemail pin set and the method of calling your own phone - all documented by Sophos Security.

In another, very similar incident, the CEO of Cloudflare was also a target of 2FA bypassing via a Voicemail related incident, however in this case, the attack was much more sophisticated and required the attackers to socially engineer AT&T staff to redirect the voicemail of Matthew Prince to a fraudulent voicemail box.

The method I have used to gain access to voicemail accounts (only those I have been permitted to access for testing purposes) has been documented for a very long time and isn't so complex/difficult to execute.

Even though the exploitation method of gaining access to voicemail boxes has had an increasingly high level of attention, it has not been patched in a large majority of networks in a few countries.

Concept and Flow of Exploit

As an attacker, you need four things to break into your victims 2FA protected account. They include:

• The victim's username/email & password.
• The victims's attached mobile number to the 2FA service.
• A mobile number spoofing service
• The mobile networks voicemail number for remote access.

Realistically, as a sophisticated attacker, the above four requirements are not difficult to obtain. Getting the account password can be done through any of the traditional methods, and obtaining the mobile number attached to it, is not so difficult either nowadays.

Mobile number spoofing services, such as Spoofcard only cost $10 for multiple uses and obtaining the mobile networks voicemail endpoint, is also usually only a few google searches away. Additionally, if one wished to avoid signing up for Spoofcard, they could hire a VoIP service which allows Caller ID spoofing, for the very same effect.

The first stage of the exploit:

1. The attacker logs into the victims account on a 2FA enabled web application
2. The attacker engages a call with the victims phone number (only 20-30 seconds needed)
3. Immediately after this, the attacker chooses the alternative 2FA option to send the 2FA code via Phone Call
4. As the victim is engaged in the call by the attacker, the 2FA phone calling service will send the 2FA code to the victims voicemail, immediately.

This is the first flaw. I might be opinionated on this, and people may disagree, but there is no considerable reason that I can think of for why 2-Factor-Authentication codes should go to voicemail. For the very small amount of usability it adds, there is also a considerable amount of risk when doing so. Based on the voicemail hacks done over the past few years, by sending the pins to voicemail - it is likely that you are able to bypass 2FA regardless of the second flaw that I am about to tell you.

The 2FA pin can also be sent to the victims voicemail if the victim does not answer the phone call from the automated 2FA caller.

The second stage of the 2FA bypass actually relies on what is known as voicemail/phone hacking.

The image above applies to Australia and my entire method for part two is corresponding to the above mobile service operators only (until others are found). In it, I show the networks which I am sure are vulnerable to voicemail hacking and those which are partially/not vulnerable.

Additionally, I must note, that the networks Three and EE in the UK are also vulnerable to voicemail hacking via spoofing. This was documented and confirmed recently by The Register in the UK.

Completely vulnerable:

In completely vulnerable telco's the Automatic Number Identification (ANI)/Caller ID is used to determine whether or not the caller is legitimately the voicemail account owner.

If the ANI/Caller ID matches the account holders, the system does NOT ask for a pin code to access the voicemail account.

In USA, there are methods to ask for a pin code regardless of caller IDs, however in Australia, as far as I know there is no way to prevent your voicemail account from spoofing attacks, unless the service providers mitigate this issue on their end.

1. Obtain a ANI/Caller ID spoofing service (either via a VoIP provider) or via a dedicated spoofing provider.
2. For all the services in the above vulnerable list, input the destination number as: +610411000321.
3. Enter the "Caller ID to Display" as the victim's mobile number.
4. If you're using SpoofCard, a number and access code is displayed. Call this number and input the access code.
5. You will be connected to the victims voicemail service providers endpoint. In this, input the victims mobile number and press #.
6. You now have full access to the voicemail of the victim. This includes even being able to change the users pin or personal greeting tone.

Explanation of the destination number being +610411000321:

• Australia has three major mobile service providers: Telstra, Optus and Vodafone
• Telstra, Optus and Vodafone are able to resell their service, and hence branch out to many other providers.
• All reseller's (e.g. those below Optus in the image above) use the exact same main services (such as account information hotlines, voicemail services) as Optus does.
• Hence, if an attacker can exploit any one of the main three telco's services, every branching service provider of that telco is also most likely affected.
• Optus's primary number to call for Voicemail is "321"
• However, when spoofing, we need the remote number to call as we are unable to reach "321"
• Optus provides a remote number to call, in case customers are overseas. This number is: +610411000321 and works as an endpoint for all spoofing providers.

NOTE: All vulnerable endpoints for Optus Voicemail have been fixed. Including the endpoint I used to bypass their initial fix.

Partially/Not vulnerable:

In the picture above, I state that Telstra, Virgin and Vodafone are partially/not vulnerable, as I have not had the chance to fully test the ability to break into voicemail. However I do know that:

• Telstra asks for a pin regardless of Caller ID/ANI spoofing attacks and is hence secure to the exploit I describe above.
• Vodafone will let me set a pin / access your voicemail if you do not already have a pin set, if I call via a spoofing service, impersonating your number.
• Virgin Mobile has not been tested, however it is very likely that it is vulnerable as it is a part of the Optus network in Australia.

If you're not sure what network you're currently using, or if you want to check you are vulnerable, a friend of mine (Aleksa Sarai) has made a script to determine your mobile network based of your mobile number in Australia. Simply put your mobile number in the input below and press check.

You can find the code for the mobile network checker @ Github

Disclosure to Google Security Team

Google were one of the early adopters of 2 Factor Authentication across all of their services. The 2FA system which Google currently uses may be perfectly fine and secure for you if your telco is very strict on voicemail security - but essentially the chance of your 2FA protection on Google being bypassed is surprisingly high.

Assuming you have read the exploit flow, the flaw which allows for me to bypass your 2 factor authentication is that Google, Facebook, Yahoo and other major 2FA enabled services send the 2FA token to your voicemail if you are unavailable. When looking at this alone, it's a very small issue, but when looking at in a security point of view - the flaw is quite unmistakable.

1. Voicemail isn't globally centralised, and nor is its security. Each Telco runs its own voicemail management service.
2. The security of voicemail services aren't managed by Google but rather by the Telco's.
3. Once the 2FA token/OTP is in the voicemail - there are so many vectors of attack, one could use to retreive the token (without tampering with anything on Google's end).

If you wish to see the entire email log of my conversation with Google, you can find it here: google.pdf.

Note: Hijacking Google Accounts via this 2FA bypass technique would not be stealthy, as it's very likely that once logging into a Google 2FA enabled account, a text would be sent to the victim automatically. From there onwards you would have to choose the option to be called via phone and continue the exploit. This would most likely raise flags for the victim.

Their response to my initial disclosure, was the following:

Hey,

Thanks for your bug report. We've taken a look at your submission and can confirm this is not a security vulnerability in a Google product. The attack presupposes a compromised password, and the actual vulnerability appears to lie in the fact that the Telcos provide inadequate protection of their voicemail system. Please report this to the telcos directly.

Regards,  
Jeremy  

Whilst I knew that it was the telco's fault for having insecure voicemail systems, I still felt that a flaw existed in the fact that Google sent the 2FA token to Voicemail - which is a very risky practice and not done by most 2FA providers. Hence, I replied with the following:

Hey Jeremy,

I completely understand and am chasing the Telco's at the moment as I disclose these vulnerabilities.

Regardless of pin protection, a large majority of telco's in Australia and UK require only a 4 digit pin with no lockouts. Essentially, using a VoIP service and some scripts on Asterisk AGI (http://www.voip-info.org/wiki/view/Asterisk+AGI) , it would be possible to break into a voicemail account within a day (concurrent instances of pin guessing).

Essentially, whilst you are right in saying that it is definitely the Telco's problem. Not only does this mean that in the last four years (or more), people using an Optus based service in Australia (a large majority in Australia) were vulnerable to having their 2FA bypassed, it also means that it is very likely that many telco's in many countries are also very vulnerable to the same sort of attack.

I feel as if stating that it is purely a telco issue, is somewhat neglecting the fact that 2FA tokens don't have many good reasons to go to a persons voicemail. Additionally, by doing so, regardless that it is not Google's fault for 2FA being bypassable via an external vulnerability - the fact still remains that Google gives away this sensitive information to a potentially vulnerable end point.

Regardless of this, after doing some research, I was able to talk to the people at Duosecurity and Authy who specialise in 2FA. When I first discovered that Google sent 2FA tokens to voicemail, I was so certain that 2FA providers such as Duosecurity and Authy were also vulnerable. I was wrong. They didn't sent 2FA tokens to voicemail. This is how they mitigated the issue:

- Requirement of some sort of user interaction before PIN/2FA token is issued via voice
- Leave a blank message in Voicemail instead of a pin
- Require a user interaction as a form of validation (2FA Call -> Told to press the number "x" -> On press = verification, else = no verification).

Please do let me know what you think of this and if Google has any plans on mitigating against this. It's quite obvious that the issue is on the Telco's end due to insecure voicemail security - however it's not something which is in either Google's or my control and hence leaves 2FA vulnerable to some extent to such attacks.

2FA is absolutely useless to all Australian's who have linked their Optus number with Google, and has been useless for the last four years at the very minimum (assuming that others have known about the flaw in Optus voicemail security).

Thanks,  
Shubham  

Google soon responded with:

Hi,

Thanks for explaining the potential scope of this issue.

Since it isn't technically a vulnerability in our 2SV system, I'm not sure if there's much we can do to mitigate this, but I've filed a bug a will ask the team to take a look.

Regards,  
Jeremy, Google Security Team  

Until further notice, I assume that this issue won't be fixed and hence the best solution to fix this temporaily is to disable 2FA on Google via texts or phone calls, and enable Google Authenticator based 2FA, if you think your telco may be vulnerable.

This setting can be found at: https://accounts.google.com/b/0/SmsAuthSettings

Additionally, whilst unconfirmed, it may also be possible to recover Google accounts via 2FA as documented here:

https://support.google.com/accounts/answer/183728
https://support.google.com/accounts/answer/152124

I have been unsuccessful in attempting to recover my own, or any of my friends accounts via 2FA - however some time ago, it was possible as it is what happened to Matthew Prince (Cloudflare).

Disclosure to Facebook Security Team

Due to a fault on my end, I only realised it was possible to exploit Facebook the same way as I exploited Google a few days before this disclosure. Facebook calls their 2 Factor Authentication "Login Approvals" which is an "... extra security feature similar to login notifications, but with an extra security step".

Using the same exploit flow as described above, one can also bypass the 2 Factor Authentication on Facebook.

The process of getting Facebook to send the phone call includes the following:

1. Login to the account (1 x SMS with 2FA code is sent to victim).
2. Click "Send me a text with my security code".
3. The option to send a call instead is revealed.
4. Engage the victims phone by calling them, or ensure that the victim is in a call.
5. Click "call you with your security code".
6. The 2FA code will be sent to voicemail.

Alternatively, instead of relying on the security sending modal, it is possible to make a request to "https://www.facebook.com/ajax/login/approvals/send_sms" with the form data "method_requested=phone_requested".

This method would be most effective by intercepting the initial request to send a text message by using a reverse proxy, and simply replacing the method value from "sms_requested" to "phone_requested".

You can find a full copy of my disclosure to facebook here: facebook.pdf. However alternatively, their reply to the vulnerability is detailed below:

Hi Shubham,

We've temporarily disabled sending login approval codes via phone call while we investigate further. Our plan is to re-enable the system when we can prompt users for interaction as part of the phone call, which should prevent us from sending codes to voicemail boxes.

Thanks,

Neal  
Security  
Facebook  

Facebook were extremely swift in closing the 2FA bypass and I commend them for co-ordinating everything so quickly and at least taking action temporarily.

Disclosure to LinkedIn Security Team

Just like Google and Facebook, LinkedIn also sent the 2FA code to the victims voicemail if the vicim missed the automated call or was engaged when the automated call was made.

LinkedIn handled the situation well, by turning off the 2FA authentication via Phone Calls completely until they are able to fix the vulnerability with their third party 2FA provider.

You can find the entire email thread between myself and LinkedIn over here: linkedin.pdf.

Their reply to this issue was the mainly, the following:

Hi Shubham,

Thank you for notifying us of this issue before publicly disclosing it. 

While the potential impact for our members is limited, we have made the decision to temporality turn off the voice option in our Two-Step verification setting.  We are working with the third-party vendor we use for this service to implement a fix. After the fix is in place, we will evaluate turning the voice option back on. 

Thanks,  
David  

Disclosure to Yahoo's Security Team (via HackerOne)

Yahoo's main services which allowed for 2FA were also vulnerable to the exploit I document above. In fact, the exploit to get into Yahoo accounts with 2FA enabled is even more severe as the attacker does not fully risk the victim knowing about account access on login.

Usually web applications with 2FA enabled send a text as soon as someone logs in. However, when logging into a Yahoo account, no precursory text is sent, but rather a choice gets to be made for whether one wants a call or a text.

Since the attacker doesn't risk the victim instantly knowing that 2FA has been triggered, the attacker is more likely to gain access for longer.

14 days from disclosure, Yahoo still hasn't replied, and hence they are still vulnerable to the 2FA bypass.

Feel free to take a look at my entire disclosure to Yahoo and reminders to them on HackerOne here: yahoo.pdf.

Disclosure to Authy & Duosecurity

I was very quick to assume that the services that provide 2FA commercially were bound to be vulnerable. However, I was very incorrect - as they were well informed and had long thought of issues related to pins going to voicemail.

You can read the emails to and from Authy and Duosecurity, here: authy.pdf and here: duosecurity.pdf.

Both services replied to me within 24 hours or so, and both services were extremely helpful with the disclosure.

Authy leaves a blank voicemail on Phone Calls and Duosecurity requires user interaction before verification.

Thanks Authy and Duosecurity!

Mitigation Techniques and Disclosures to Telco's

To all readers of this blog post, I have been able to collate some information below, containing the endpoints of various customer services for various mobile networks around the world.

Since I can't check telco's overseas myself, I know people around the world are also concerned to see if their telco is vulnerable.

To see if you can get into your voicemail service without a pin by spoofing, simply follow the exploit flow, replacing the endpoint number with the one for your telco for voicemail, from the list below.

Please do let me know if your telco is also vulnerable by simply emailing me here or by simply leaving a comment below.

Mitigating this vulnerability isn't quite as straight forward as one would expect as it requires the remodelling of the 2FA Phone Call feature. Here are some of the suggested mitigation techniques (also present in all of my disclosures to companies).

• Requiring user interaction on phone call as verification (recommended)
• Ending call on Voicemail detection (unreliable)

and last but not least:

• Removing the phone call ability completely (decreased user experience)

Disclosure to Optus

I had the pleasure of working with Ben Grubb (Deputy Tech Editor at The Sydney Morning Herald and The Age) who assisted me in disclosing these issues to Optus and along the way was extremely cooperative and helpful in the disclosure of this issue.

When I first found that Optus was vulnerable, my research led me to this article: Is your Voicemail Hackable? Optus, Telstra and Vodafone respond from Australian Business Traveller.

"Optus takes the privacy of our customers very seriously. Customers must set a unique PIN to activate their voicemail system. When their PIN is reset by a customer service representative, they are advised to reset their PIN to something that only they will know.

"With regards to spoofing, we are looking at multiple options to address this emerging industry-wide threat, including technical solutions and customer education."

This article was dated "22 Jul, 2011". It's been almost three years since then, and surprisingly, this issue is still around and a massive privacy risk!

Ben and I first disclosed the issue to Optus on Fri, May 2, 2014. Since then, 7 or so days later Optus fixed the issue.

However, within hours of the fix being issued, I was able to determine an alternate method to access any Optus customers voicemail without a pin, once again. This bypass is currently also being worked on by Optus, but until further notice - please assume that your voicemail is insecure if you're with Optus OR with any of their reseller networks e.g. Vaya, LiveConnected, Amaysim, Exetel, Yatango etc.

Notes

Just like my previous obsessions with captchas, SSRF and rate limiting, I think voicemail and general mobile network security is going to take up a lot of my future time.

Everyone knows that mobile network security is poor, but with nothing being done, we don't know how important it is until we are breached due to it.

If you want to stay up to date on my voicemail security disclosures, I shall be updating my twitter regularly with any responses from Telco's.

The following services below may also be affected by the 2FA bypass, but have not been thoroughly checked:

• Snapchat
• Egnyte (Uses DuoSecurity 2FA and hence is not vuln until further notice)
• Amazon
• Dynadot
• Airbnb
• Elance
• Chase
• Discover
• Fairwinds

Additionally confirmed as vulnerable:

• Zoho.com (Found by David Vo)

Thanks for reading this post, I hope you found it somewhat informative and useful.

Shout out to Aleksa Sarai, Gibson Security and Nathan Wakelam for helping me throughout this disclosure.

This has been featured in Sydney Morning Herald / Sun Herald here: http://www.smh.com.au/it-pro/security-it/optus-left-customers-mobile-voicemail-accounts-exposed-20140517-zraz7.html