Verification Code Forwarding Attack Extended Version
?
Hossein Siadati, Toan Nguyen, and Nasir Memon New York University Tandon School of Engineering {hossein,toan.v.nguyen,memon}@nyu.edu Abstract. Major Internet service providers deploy SMS-based verification mechanisms to fortify the security of users’ accounts for critical actions such as password reset and logging in from a new computer. In this paper, we describe a new type of phishing attack where an attacker triggers the delivery of a verification code from a service provider to a user and lures the user to forward the code to him so that he can bypass the SMS verification process. We call this a Verification Code Forwarding Attack (VCFA). The attacker can use VCFA to reset a password of a user’s account or to get access to a 2-factor enabled account which he already knows its password (e.g., through leaked databases). We attribute the success of this attack to the lack of an effective and usable means for users to verify the service provider, the lack of context for the message sent, and an assumption about users’ understanding of the authentication process. To show the susceptibility of the users to such an attack, we conducted an experiment with 20 mobile phone users and found that more than 25% of users were vulnerable against this type of attack. A semi-structured interview with the subjects of the experiment and a survey of 100 subjects on Amazon Mechanical Turk were done to explore possible causes for the success of this type of attack. We also discuss possible remediation.
1
Introduction
Guessable passwords [?], reusing passwords for different accounts [?,?], breaches of password databases [?,?], an abundance of malware and the ease of which the devices get infected by trojans and key-loggers easily give attackers access to passwords. As a result, for critical actions such as password recovery and high risk authentication (e.g., log in from a new device) an auxiliary factor is needed to make the system more secure. One prevalent approach adopted by service providers leverages a resource assumed to be in control of the user, such as a phone number or an email address. In one such example of the scheme, advertised as a 2-step or 2-factor verification, the service provider sends a nonce in the form of a verification code to the user. The user presents this verification code back to the service provider via a channel requested by the service provider. Since the user who is being authenticated is assumed to be in control of this resource, ?
A short version of this paper is published at Passwords 2015, University of Cambridge, United Kingdom.
2
Hossein Siadati, Toan Nguyen, and Nasir Memon
the address of the resource is likely to be unknown to an attacker, and the nonce is random, the requested authentication is then completed. The rationale is that to circumvent such a mechanism, an attacker has to be in control of this auxiliary channel or resource. In this work, we show that authentication schemes that utilize such an auxiliary resource can be potentially circumvented without gaining control of the channel but by other means such as social engineering. For example, we show that a commonly used authentication scheme where a verification code is sent to the user’s mobile phone by an SMS message can potentially be compromised by luring the user to send the code to the attacker. We call this a Verification Code Forwarding Attack (VCFA). In a VCFA attack, the attacker triggers the delivery of a verification code to a victim and shortly after that, the attacker sends a direct SMS to the victim and phishes him or her to forward the code. If the victim forwards the code, the attacker can successfully bypass the SMS verification and get access to the victim’s account. Attackers can use VCFA in three attack scenarios. The first scenario is password reset. In this attack, the attacker initiates a password recovery request on a service provider website by entering victim’s username or email address and chooses to receive a verification code via SMS message. Shortly after the verification code is sent to the victim, the attacker will phish the victim to steal the verification code and complete the password reset. The attacker needs to know the phone number of the victim in order to phish him or her. For this, the attacker can easily search the public records, social networking websites, data from leaked databases of information or employ social engineering techniques. In a second scenario, the attacker knows the username and password of a victim (perhaps through leaked databases or other hacking techniques), logs into the victim’s account from a new machine and then lures the victim to forward the verification code. The access to the victim’s account as a result of this attack is at least for one session, but also can be permanent depending on the victim’s account settings. The last scenario belongs to spam account creation where a fraudster or spammer creates a verified account without giving out any traceable information. In this attack, the spammer enters a random phone number as his verification number at the time of account creation. Then he follows the described steps to phish the verification code. In this paper, we study this new type of phishing attack and the root causes of why it is successful. In particular, these are our contributions in this research: – Using a small scale experiment on 20 subjects, we show that more than 25% of users are susceptible to VCFA. – By conducting a semi-structured interview, we systematically study the reasons why people fall or do not fall for this attack. – Using a survey on about 100 Amazon Mechanical Turk workers that have enabled SMS-based verification for their Gmail accounts, we validate our findings on a larger and more diverse pool of subjects. Paper organization: After introducing background in Section ??, we describe the attack scenarios in Section ??. We detail our study procedures and
Verification Code Forwarding Attack
3
findings in Section ??, and conclude the paper and suggest possible remediations in Section ??.
2
Background
2.1 Two-Factor Authentication (2FA) Two-factor authentication schemes (2FA) strengthen authentication mechanisms by requiring users to provide two identification means (factors) to prove their identity. Paired factors are usually different types of authentication: Something you know (e.g., password or PIN) in combination with something you have (e.g., token, mobile device, access card) or with something you are (e.g. fingerprint, voice, etc.), with different combinations compose a 2-factor authentication mechanism. Using two factors instead of one can be cumbersome for users and unnecessary for some systems. Therefore, some deployment of the 2FA only use it for higher risk actions such as logging in from a new computer, password recovery, and adding a payee to a banking account. One category of 2FA schemes use a pair of a user-chosen password and a onetime-password (OTP). We refer to this type of 2FA as OTP-2FA in this paper. OTP is a random number generated by a device that user has, or is generated by server and delivered to a device that user owns but different from what she is using to interact with the website, and via a channel independent from the channel that she uses to interact with the website. These independent devices and channels are less likely to be compromised at the same time by an attacker, and this makes the system more resilient against credential theft attacks. In the device generated OTPs, an entity that generates OTPs can be a hardware token (e.g., RSA token) or a software token (e.g., Google authenticator). Tokens are either time synchronized with a server or are counter-based. Using the same random seed for both server and tokens, they server and tokens are able to generate the same sequence of random numbers independently without the need to communicate. In the server generated OTPs, server generates OTPs and delivers them by several means including voice and SMS channels to the user. In a voice and SMS-based 2FA (SMS-2FA) system, the server sends the OTP, also knows as verification code, to users’ phones whenever the authentication is required. Figure ?? depicts a typical architecture of a SMS-2FA system. Each of these variations has its own security and usability advantages. Hardware tokens are more difficult to compromise and less vulnerable against malware because of their limited communication channels, but users need to carry a separate device for each account. Carrying tokens will quickly become unmanageable for users, even for a handful of accounts. In comparison, software tokens are installed on general-purpose devices with rich communication channels, and so, users do not need to carry an extra hardware to be able to login to their account. General purpose devices, however, are able to install a piece of software easily, have numerous softwares installed on them, and have the capability to communicate with other devices, leaving them vulnerable to malware. SMS-2FA is also vulnerable against channel compromise by an attacker that intercept the verification codes.
4
Hossein Siadati, Toan Nguyen, and Nasir Memon
Several banking systems and Internet service providers utilize some sort of 2FA. The most prevalent type of 2FA is the SMS-2FA. Particularly, Internet service providers with hundreds of million users use this scheme as a cost-effective way to harden their authentication mechanisms and password recovery procedure. They also benefit from a user-in-loop security mechanism since the user will be notified of attackers’ attempts to recover their password and to log into their account. In addition, they use the SMS-2FA for account verification for their campaign to combat spam accounts. We will explain how an attacker can lure users to bypass these mechanisms.
Fig. 1. General architecture of the 2FA.
2.2
Security of SMS-2FA
OTP-2FA is not able to provide security against a phishing attack [?]. The reason, is that in a successful phishing attack, the attacker will lure a victim to enter the OTP as well as the password. However, it should be emphasized that a successful phishing attack may not be persistent in particular account settings where it is protected by 2FA, because the attacker needs to gain access to a new OTP for the next session he wants to use the compromised account. For example, in a setting where a user chooses to use 2FA every time she wants to login to her account, the attacker who needs persistent access to the account needs to phish the user again and gets access to a new OTP for every new session. In contrary, a user may opt to use the 2FA only when she wants to login from a new computer. In this case, the attacker can leverage the first successful login in
Verification Code Forwarding Attack
5
order to keep his access to the account (he only needs to use the stolen password for the next sessions). This attack is deployed by attackers in the wild [?] OTP-2FA does not provide protection against malware attacks. In a malware attack where the victim’s machine is infected by a malware capable of logging key strokes or migrating to processes including a browser that user uses to enter her credentials, the attacker can capture the OTP as well as password. Moreover, the malware can wait until the victim authenticates herself to an account and then uses the established session to do the stealthy activities on compromised account. The vulnerability of OTP-2FA protected accounts to malware attack is demonstrated by attacks on several online banking systems in Australia, Japan, Sweden, and Switzerland [?,?]. Dmitrienko et. al [?] have studied the vulnerabilities of the SMS-2FA systems of top internet service providers including Google, Dropbox, Twitter, and Facebook. They demonstrated the ease with which a traditional attacker with a single-machine infection can bypass the OTP verification. For example, some websites including Google and Facebook allow users to disable the 2FA mechanism without any extra verification. Therefore, malware running on a victim’s machine can disable the verification codes and bypass it. In addition, most of the websites have some mechanism to allow the users to be able to login in cases such as traveling abroad when user can not receive the OTP by SMS. For example, Dropbox provides a 16-digit recovery password that can be used by users to bypass the 2-factor verification. Facebook and Google allow the user to pre-generate a list of up to 10 OTPs that can be used independently from the SMS-based OTPs. In all these cases, an infected machine gives way to the malware to get access to the account without the need to access the code user receives on phone. In the existence of a more advanced adversary and cross device infection by malware, an attacker can steal the credentials from the computer and verification code from the device, and therefore authenticate itself into user’s account. The SMS-2FA verification, however, provides protection against known-passwordattack. In a known-password-attack, the attacker has access to user-chose password either by guessing or using stolen credentials from leaked databases or any other means. For a SMS-2FA enabled account, such an attacker will not be able to login to the victim’s account because he does not have access to the verification code. The adversary in this paper is an attacker who knows the password and tries to gain access to the verification code using social engineering techniques. Such an attacker can launch a type of phishing attack we name Verification Code Forwarding Attack (VCFA) to get the user to forward the verification codes. Several research works have previously studied social engineering techniques and phishing attacks [?,?,?,?]. Dhamija et.al [?] have studied the reasons why phishing is successful. Major reasons are visual techniques that the attackers use to deceive users into believing that the URL and the webpage are authentic. In comparison, VCFA attack does not use URL and websites to deceive users; The attacker exploits the service provider to send a verification code to the victim, and then ask her to forward a seemingly benign verification code to the attacker
6
Hossein Siadati, Toan Nguyen, and Nasir Memon
for a seemingly legitimate reason. These differences clarify the need to study the elements of this attack and the reasons for its success independent from traditional phishing attacks. In addition, users’ perception about 2FA also contributes to the success of VCFA attack. In the absence of a research work studying the extent of the susceptibility of users against VCFA attack and the reasons they fall for it, this work studies VCFA and sheds light on different aspect of SMS-2FA using several techniques including experiment, interview, and survey.
3
Attack Scenarios
Fig. 2. Verification Code Forwarding Attack Scenario
An attacker can leverage the VCFA attack for three different use cases of One-Time-Login, Account Takeover, and Spam Account Generation attacks. One-Time-Login. Goal of the attacker in the first attack is to get access to the victim’s account and use it parasitically without locking out the original user. In this attack, the attacker knows the username and gains access to password of the victim using malware, guessing attack, or via database of leaked passwords. Next, the attacker finds the phone number of the victim via public records and yellow pages (e.g., websites such as http://www.instantcheckmate.com and http://www.411.com/), social networking websites (e.g. Facebook, dating websites), data from leaked databases of information or employing active attack techniques such as social engineering. The access to the user’s account by this attack is at least once, but can be permanent, depending on the user account’s SMS-2FA settings. In the most prevalent account settings, user needs to enter a
Verification Code Forwarding Attack
7
2FA verification code only the first time she logins from a new device. In such settings, this attack delivers permanent access to the victim’s account. The attacker initiates a login process using acquired username and password. Upon submitting the credentials to the website by the attacker, the service provider sends a verification code to the owner of the account (i.e., victim) via SMS. Next, the attacker waits a few seconds to make sure that the victim has received the verification code. Followed by that, the attacker sends a deceptive message to her asking her to forward the verification code.If the victim forwards the verification code to attacker, the attacker can complete the login process and access to victim’s account. The steps and scenario for this attack is depicted in the Figure ??. Account Takeover. The second attack scenario is when the attacker aims to recover the password of an account. For this, the attacker initiates the password recovery process without knowing the password for the account. Service providers usually provide several options for password recovery including password recovery using a verification code sent via SMS. By choosing this option, service provider sends a verification code to the user (i.e., victim). Next, the attacker lures the victim to forward the verification code to him. Using the stolen verification code, the attacker completes the password recovery process, changes the password, and takes over the account. This attack does not need the attacker to know the password of the victim. What attacker needs is a pair of email address and the phone number connected to that account. The information related to username and phone numbers can be obtained by one of the techniques described in the first scenario. Spam Account Generation. Goal of the attacker in the third scenario of attack is to create a verified spam account. Creating a verified account on most of reliable internet service provider needs a form of verification by server in form of a CAPTCHA, verification by a primary email account, or via a verification code as is used in the SMS-2FA. This verification is done by service providers to make sure that this is an authentic user who wants to create an account and use their service. In this attack scenario, the attacker times to create an fully functional account on services that need phone verification for registration or full functionality of accounts, without acquiring a valid phone number. Instead, the attacker uses other peoples’ phone to complete the account verification. In this attack, the attacker starts by creating a new account and filling out the registration forms of a service provider online, as he wishes. Next, he enters the phone number of a person (i.e., victim) as the verification number. When the form is processed, the service provider sends a verification code to the victim via SMS. The attacker then deceives the victim to forward the verification code, and uses the code to verify his account. Although the attacker does not takeover an account in this scenario, he builds a valid account that he can use for sending spam messages and other deceptive activities. What is common among above scenarios is that a user receives a verification code and the attacker lures her to forward the verification code. In this paper, we
8
Hossein Siadati, Toan Nguyen, and Nasir Memon
focused on the mechanics of the attack and do not consider any specific scenario, as the success of the attack is orthogonal to the goal of the attacker.
4
Study Procedure
We conducted this research in three phases. The first phase was a small scale experiment on 20 subjects we randomly selected from our contact list. We imitated a VCFA attack and measure the success rate. Next, we interviewed the subjects; those who fell for phishing as well as those who did not, by semi-structured interview approach. In the third phase, we extracted a handful of hypotheses from the interviews and evaluated them in larger scale by surveying subjects on Amazon Mechanical Turk (MTurk). The following subsections detail the three phases of this research project. 4.1 Experiment For the sake of the experiment, we imitated a VCFA attack on the Gmail service, using similar messages as Google sends to its user to deliver the verification code. Phone numbers setup. We bought two 10-digit U.S.A phone numbers, one for imitating the role of service provider (e.g., Google) in our experiment (i.e. sending the verification code to subjects) and the other one for imitating the role of the attacker (i.e., sending phishing message to subjects). The first number was used to send verification codes (a random 6 digits number) to subjects. The second number was used to send phishing messages and also to receive the responses from the subjects. We did not really get Gmail to send the verification code to subjects for several reasons. First, we wanted to eliminate any potential harm to the subjects, and therefore, we decided not to interact with their Gmail accounts. Secondly, for some of the subjects, we even did not know whether or not they had a Gmail account since we chose them randomly from our phone contact list . The area code for the phone numbers were Mountain View, CA (area code for Google’s headquarter) to make the first message to appear more legit and the second one more deceptive. Even though it turned out later that most users did not pay attention to the phone numbers they received a verification code from or communicated with. These numbers were prepaid SIMs and could be easily purchased from any mobile carrier store. Two numbers had the same six digits in the beginning (e.g., 650-666-XXXX). Subject selection. We randomly selected 10 people from contact list of two experimenters and chose a total of 20 subjects for our experiment. The subjects were not contacted beforehand. We only reached out to them for interviewing after we already conducted the phishing on them. We were granted an IRB exemption from our institution for this research. Demographics of the subjects are presented in Table ??. Message I. This message was sent to all subjects in the form of: “Your Google verification code is [6-digit code].” The style of the message exactly followed the Google’s message for verification code. Google’s messages are general and do not include username or any customer identifying information. It also does not include the reason why the
Verification Code Forwarding Attack
9
Table 1. Demographics of subjects in our experiment. Gender
Male Female 10 (50%) 10 (50%) Total 20 Age Percentage 18-25 1 (5%) 26-30 15 (75%) 31-35 4 (20%) Occupation Percentage Student 14 (70%) Realtor 2 (10%) Administration 2 (10%) Free agent 2 (10%)
user is receiving this message. The verification codes we generated were 6 digits and were chosen uniquely so we can match a response with a user and check its correctness. Message II. A few seconds (about 30 seconds) later, we used the second phone number to play the attacker’s role and to see if we can lure the subject to forward the verification code. We sent this message: “Please verify that your phone is still associated with your Gmail account by replying to this message with the code we have just sent to you.” Several other variations of such messages also are possible. The main principle, however, was to send a message that urge the users to forward the verification code (in comparison with clicking on a link and entering the verification code there), and to use the same language as the service provider uses to communicate with users. We sent the message a few seconds after the first message to confuse the receiver into believing that they were communicating with the same entity. Experiment in motion. Following were the main steps for the experiment: A. Sending Message I to subjects using phone number 1. B. Waiting for 30 seconds. C. Sending Message II to subjects using phone number 2. D. Taking note of responses and time if the subjects reply. All messages were sent between 4-5pm on a weekday. Experimental results. Among the 20 phone numbers that we selected and sent the messages to, 5 subjects forwarded the verification codes. This is translated to a minimum of 25% success for the VCFA attack. 6 subjects did not forward the verification code, even though they did receive and notice the messages. One of them reported that he wanted to but forgot to forward the verification code. For 4 subjects, we were sure that they did not receive our messages because of problem in SMS system or the fact that some of them had changed the phone number. This translates the
10
Hossein Siadati, Toan Nguyen, and Nasir Memon
success rate of the attack to about 31%. For 5 remaining subjects, we were not sure if they received and noticed the messages since we chose the phone numbers randomly from our contact list, and did not check if the receivers have changed the phone numbers or if the phone numbers were personal or work phones. We also were not sure that they basically have a Google account or using Gmail or not. The average response time for the subject to forward the verification code was 59.4 minutes (Median=20, STD=65.3). The detailed response timed are listed in Table ??. 3 out of 5 forwarded the message in less than 1 hour (the Google verification code validation period is one hour), meaning a completely successful attack. For other cases, the fact that they forwarded the message late is potentially related to the time we sent the message. Table 2. Response times of subjects who forwarded verification codes (who were phished). Subject Response time 1 2 minutes 2 14 minutes 3 20 minutes 4 1 hour 45 minutes 5 2 hours 16 minutes
4.2 Semi-structured interview Most of the subjects who received our messages but did not reply think that somebody was trying to deceive them. The day after the experiment, we reached out to the subjects to setup a time for interview. We could not reach out to all of the subjects as described in the experiment section mostly because some had changed their phone number. The goal of the interview was to figure out why people fell or did not fall for VCFA. We successfully interviewed 10 out of 20 subjects, 5 of those who fell for phishing and 5 who did not. We asked a number of demographic and background questions such as their usage of SMS, knowledge about the computer and computer security. Other questions were focused on the users’ interaction with the messages they received during the experiment, their perception about the messages and possible doubt and trust on them, the situation in which they received the message, and their reaction. The list of messages are listed in the Appendix ??. We interviewed the subjects in person, by phone, and by email if the first two options were not applicable. Findings from interviews After we completed the interviews, we documented the responses and analyzed them to find themes and significant experiences. We categorized these items as follows: Reasons for enabling the 2FA. Subjects listed different reasons for enabling the 2FA. The common theme was improving security of their accounts
Verification Code Forwarding Attack
11
because for most of them Gmail was the primary contact point for their online presence. One subject mentioned that she has enabled the 2FA because she needs to log in to her account from untrusted machines from public computers in laboratory and library, and using 2FA gives her confidence to reveal her password on potentially insecure computers since she owns the phone and so she only has access to the verification code. Phone number validation. 7 out of 10 subjects that we interviewed mentioned that they did not validate the phone number that sent the Message I. Indeed, they believed that the message was sent by Google. Apart from two subjects who did not fall for VCFA, other subjects did not notice that the phone number that was used for Message II was different from the first phone number. One subject, however, reported that she searched the phone numbers on Internet. She did not find any scam alert related to the number. She also found that the numbers had Mountain View area code, where Google’s headquarters are located, and so she trusted the phone number. Upon receiving the first message, one subject tried to log in her Gmail account from a different computer to receive a verification code and compare against this number. When she figured that the numbers were different, she did not forward the message. Other interesting finding was that the subjects have seen Google using different phone numbers with different lengths (i.e., short codes vs. 10-digit numbers) for sending the verification codes. So they did not have a clear understanding what a Google phone number looks like. These demonstrated a core problem with SMS-2FA since it does not provide any usable identifier for users to verify the sender of the codes. Message Credibility. Subjects who fell for phishing were convinced that the Google may need to verify their phone number by sending a SMS to them. One subject searched the Internet to make sure that Google does this, and found that one of the reasons that Google uses 2FA is to limit the fake accounts. Finally, she was convinced the phishing message was credible and related to Google’s account verification mechanisms. Some subjects not only did not find the second message deceptive but they found it assuring that nobody was hacking their account. Indeed, they thought that this was part of Google’s periodic security checking to make sure everything is fine. Two subjects reported that they found the style of the second message inconsistent with what Google usually sends. Particularly, they found the second message more detailed and longer in comparison with the messages from Google. Still, one of these subjects fell for phishing because the overall process and reason for verification request was convincing. Unwanted verification code. For most of the subjects, the first message that was unwanted and triggered without them doing anything meant that somebody was messing around with their account so they reported that this made them worried. However, for one of the subjects who had experienced unwanted messages while she wanted to connect her smartphone to her Gmail account using an email application, receiving unwanted message wasn’t a surprise and did not make her worried. Reasons for forwarding code. While being deceived, victims were thinking that they were participating in a verification process by Google and did not
12
Hossein Siadati, Toan Nguyen, and Nasir Memon
perceive their action of sending the verification code as forwarding it to some third entity. Indeed, one of the subjects reported that she would have not sent the code if she was asked to forward the code. She perceived her action as replying to a verification message by Google. Most of the users sent the code because their Google account is the primary point of contact for them. They did not want any interruption or problem with their primary account. Awareness. This specific attack was not widespread and was unknown to our subjects at the time of the experiment. They also did not know about the harm of forwarding a verification code. Moreover, Google did not provide enough awareness for users not to forward the messages. However, one of the subjects pointed out that upon receiving these messages, she consulted with his friends who warned her about a possible attack. 4.3 Survey Following the interviews, we formed a survey in order to measure the extent and prevalence of the insights we gained from the interviews. Our questionnaire was composed of questions in the following categories: Demographics Age and gender of the subjects. 2FA usage. Percentage of the users who use 2FA of different service providers. The service providers we listed were Facebook, Hotmail/Outlook, Yahoo, Dropbox, and banking services in general. We also asked users about the extent they use 2FA. Options included “Every log in”, “log in from a new computer”, “For password recovery”. Reasons for using 2FA. We studied two main reasons that people enable 2FA namely “Log in from insecure computers” and “Account being hacked before.” Flawed experience with 2FA systems. We asked about two main flaws that contributes to deceptiveness of the VCFA namely “Problem in receiving Verification codes” and “Receiving unwanted verification code.“ Phone number verification. We asked users to learn what they remember from the phone number sending the verification code. We also explicitly asked if they check the phone number or not. Forwarding verification code. We asked two different questions to figure out the perceptions of the users about a VCFA attack in different stages of the attack. Firstly, we asked the users perception if they get an unwanted verification code. Then, we asked them to consider a hypothetical scenario in which Google asks them to forward a verification code. Using these questions, we measured the success rate of the VCFA attack in a larger scale. We ran the survey on MTurk. We asked MTurkers to take survey only if they have enabled SMS-based 2-step verification for their Gmail account. A total of 113 subjects participated in the survey. We cleaned the results after the survey and that resulted in 98 reliable responses. The demographics of the participants is given in Table ??. Most of the questions were multiple choices and Yes/No selection. Exact wordings of the questions is given in the Appendix ??. Survey result By cleaning the result of the survey, we removed those participants who mentioned that they do not have 2FA for their Gmail account (even
Verification Code Forwarding Attack
13
Table 3. Demographic of participants in our survey. Gender
Male Female 65 (66%) 33 (34%) Total 98 Age Percentage 18-25 34 (35%) 26-30 25 (25%) 31-35 21 (22%) 36-40 8 (8%) 41-50 9 (9%) 51+ 1 (1%)
Table 4. Percentage of subjects who use 2FA for other services. Service Percentage of Users Facebook 35 (33%) Hotmail/Outlook 14 (13%) Yahoo 13 (12%) Dropbox 14 (13%) Banking accounts 71 (64%)
though the task explicitly mentioned that only 2FA users of Gmail accounts should participate, we put a question asking them to explicitly confirm that. We removed those who said they do not use 2FA. However, we paid all the participants.). This resulted in 98 participants out of 113 who filled out the survey initially. We analyzed the answers to the survey. We present the result in the same categories of the questions. 2FA usage. The statistics about the usage of the 2FA from other service providers is given in the Table ??. The result shows that noticeable number of users who use 2FA on Gmail, also use 2FA for their banking. The statistics on Facebook and other service providers is also interesting, even though it might not be representative of the actual percentage of users for each service that uses the 2FA since we do not know the proportion of the users in our survey who uses each listed services. The extent that the users use 2FA for Google is shown in Table ??. Most of the users use the 2FA for the cases where they need to log in from a new machine or for the case of password recovery. This is not a frequent process, and so, users do not receive the verification code very often. We are not sure about the security consequences of this behavior. What is important, however, is that users do not get exposed to these messages to practice the security advice given to them. One possible conclusion is that the security advice should follow these low frequency messages. Reasons for using 2FA. We asked users why they choose to use the 2FA for their account. 62% of the users mentioned that they enabled the 2FA because
14
Hossein Siadati, Toan Nguyen, and Nasir Memon Table 5. Percentage of subjects who use 2FA for other services. Usage Every log in For log in from a new computer For password recovery Never
Percentage 8 (8.2%) 65 (66.3%) 22 (22.4%) 3 (3.1%)
they log in from insecure computers, and 22% of the users have enabled the 2FA because their account has been hacked before. Flawed experience with 2FA systems. About 5% of the subjects reported that they have experienced receiving 2FA messages from Google without initiating a log in, password recovery, or any other process. We did not ask further questions to see if this is because somebody has been trying to hack them or just a problem in the 2FA messaging systems. Also 11% of the users mentioned that they had problem receiving a verification code from Google. These flaws may lead to being indifferent in future when users receive a 2FA message without requesting one. Phone number verification. We asked the users if they check the phone number of the sender of 2FA messages. 38% of the users said that they check the phone number to make sure it comes from Google. However, 30% of the users did not have any idea about what a Google message look like regarding the number of digits in it. 41% of the users remembered it as a 10 digits number, while 24% others remembered it as a 6 digit number. Interestingly, 4% thinked that it is sometimes a 10 digits and sometimes a 6 digits number. 58% of the users believed that they received the verification code from the same number whereas others thought Google uses different numbers to send a verification code. 78% of users who mentioned that they check the phone number of sender of the 2FA verification code, believed that Google uses the same number to send the verification codes. All in all, even a noticeable number of users mentioned that they check the number, there is no common perception of what the Google number looks like or even if it is a fixed number or not, demonstrating the lack of a handle for users to verify the sender of messages. Forwarding verification code. To have a better understanding of the extent in which the users are vulnerable to the VCFA attack of the types described before, we asked questions concerning the two messages that users receive during such an attack. The first situation that a victim encounters during the simple VCFA attack is receiving an unwanted verification code. It is important to notice this is may not be the case for all variations of the VCFA attack. For example, in an spear phishing attack, the attacker can wait until the time that user is receiving a verification code in an authentication process she initiated. Then the attacker can bypass the first phase and just ask her to forward the code. In other variation similar to one before, the attacker initiates a verification process almost at the same time and the user gets two verification codes and one request
Verification Code Forwarding Attack
15
from the attacker to forward the code. In these two cases, the user does not experience an unwanted verification code similar to the scenario that we described. In the question we asked in the survey, we asked users about their opinion on the simple scenario. In such scenario, 67% of users thought that somebody was hacking their account, 11% believed this is because of a flaw in the Google’s system, 21% of the users did not know why this may happen, and 4% of users just ignored messages. For the next phase in which the attacker asks the user to forward the verification code, we asked what users will do if Google asks them to forward a verification code. Given the fact that Google would never do that, people who forward are those who fall for VCFA. 20% of the user marked that they will forward the verification code, meaning that they fall for this attack. It is important to notice that we warn the user about the possibility of an attack given the last option in the answers “I think somebody is hacking me”, so the expected amount of victims is more than 20%. For other options, 18% mentioned that they do not care about this message, and 61% said that they will conclude that somebody is hacking through their account.
5
Conclusion
A noticeable number of the users are susceptible to VCFA attack. We attribute the success of this attack to the lack of an effective and usable means for users to verify the service provider and the lack of context for the message sent. Another reason is the assumption about users’ understanding of how this authentication process works and their awareness of the possibility of a misuse based on verification codes. A potential quick fix by service providers would be to use a list of publicly announced phone numbers that users should expect to get their messages from. Possible long-term remediation would be to augment a naming system to SMS system so users can see the name of a service provider who sends a message. Another simple fix is to add context to verification code messages indicating why the user received a verification code. Another fix includes appending a warning text such as “DO NOT FORWARD THE VERIFICATION CODE” to remind the importance of the code. Users enable SMS-2FA for different reasons, and noticeable number of users enable it because they login from insecure computers. Example of insecure computers that the user do not own including those in libraries and public places. Even though this is a legit scenario for using 2FA, the fact that most of the users use very similar passwords for different accounts, and also the ease with which the mobile devices are infected by malware accessing the verification code, suggest that such use cases are less secure than what users believe. We hypothesize that this perception may also contribute in creating less secure passwords because users rely on security of 2FA. This is one of the aspect of the problem that we have under study. The number of subjects in our experiment and the process of recruiting the subjects in this experiment only suit a pilot study. We are conducting a larger scale study to verify our results and to measure the success of suggested list of potential remediation.
16
6
Hossein Siadati, Toan Nguyen, and Nasir Memon
Acknowledgments
We thank all the participants in our experiment for their time and extraordinary insights that they gave us in the interviews. We owe Payas Gupta a debt of thanks for encouraging us to follow up the initial ideas about the project. We thank Trishank Kuppasumy, Seda Gurse, and Markus Jakobsson for inspiring discussions.
A
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
B
Semi-structured interview questions
Your age range? Your gender? Your occupation? How often do you send/receive SMS messages? How do rate your computer skills? (from 1 to 10; 1 means not skilled and 10 means very skilled) Scale your computer security knowledge? (from 1 to 10; 1 means no knowledge and 10 means very skilled) Do you have a Gmail account? Do you use 2-step verification with your Gmail account? Why? Do you use SMS to receive verification code or use an app to generate onetime code? What were you doing when you received the messages? Why did you reply fast/late? What do you think about the messages you received? Did they look familiar? convincing? or suspicious? Did you believe that the first message was from Google? Did you think that the second message was from Google? Did you check the phone numbers that sent you these messages? Did you notice that the phone numbers were different? Did you check if the beginning of the numbers were the same? any effect on you believing the messages? Why did you forward the code? (Or why did you ignore the messages?) What do you think about the phone numbers that sent you the messages? What did you do after you forwarded the code? Do you use any other service with 2-factor authentication? Any question? Suggestion?
Survey questionnaire
1. Gender 2. Age 3. For which other services do you use their 2-step verification (Mark all that apply) (a. Facebook, b. Hotmail/Outlook, c. Yahoo, d. Dropbox, e. Some of my banking accounts) 4. How do you rate the security of your Gmail account? (a. Very Insecure, b. Insecure, c. I Have no idea, d. Secure, e. Very secure )
Verification Code Forwarding Attack
17
5. Sometimes I have difficulty receiving Google verification codes. (a. Yes, b. No) 6. Sometimes I receive verification code without doing anything. (a. Yes, b. No) 7. When do you receive verification code? (a. Every time I want to log in to my account, b. Only if I log in to to my account from a new computer, c. Only if I forget my password and request a password reset, d. I never receive a verification code) 8. The phone number that I receive the verification codes from is: (a. A 6digit phone number, b. A 10-digit phone number, c. Sometimes 6 digits and sometimes 10 digits, d. I have no idea about it) 9. The verification codes: (a. Are always sent from the same phone number to me, b. Are sent from different phone numbers to me) 10. When I receive a verification code, I check the sender’s number to make sure that it is from Google. (a. Yes, b. No) 11. I have activated the Google 2-step verification because I log in to my account from insecure computers. (a. Yes, b. No) 12. I have activated the Google 2-step verification because my account was hacked before. (a. Yes, b. No) 13. If I receive a verification code without doing anything. (a. I think that somebody is hacking my account, b. I think that Google has screwed up somewhere, c. I do not care, d. I have no idea why this may happen) 14. If Google asks me to forward a verification code via SMS to verify my phone number. (a. I will reply to their message and forward the code, b. I do not care about their message, c. I think somebody is hacking me)
