When Convenience Creates Risk: Taking a Deeper Look at Security Code AutoFill on iOS 12 and macOS Mojave

A flaw in Apple’s Security Code AutoFill feature can affect a wide range of services, from online banking to instant messaging.

In June 2018, we reported a problem in the iOS 12 beta. In the previous post, we discussed the associated risks the problem creates for transaction authentication technology used in online banking and elsewhere. We described the underlying issue and that the risk will carry over to macOS Mojave. Since our initial reports, Apple has modified the Security Code AutoFill feature, but the problem is not yet solved.

In this blog post, we publish the results of our extended analysis and demonstrate that the changes made by Apple mitigated one symptom of the problem, but did not address the cause. Security Code AutoFill could leave Apple users in a vulnerable position after upgrading to iOS 12 and macOS Mojave, exposing them to risks beyond the scope of our initial reports.

We describe four example attacks that are intended to demonstrate the risks stemming from the flawed Security Code AutoFill, but intentionally omit the detail necessary to execute them against live systems. Note that supporting screenshots and videos in this article may identify companies whose services we’ve used to test our attacks. We do not infer that those companies’ systems would be affected any more or any less than their competitors.

Flaws in Security Code AutoFill

The Security Code AutoFill feature extracts short security codes (e.g., a one-time password or OTP) from an incoming SMS and allows the user to autofill that code into a web form, webpage, or app when authenticating. This feature is meant to provide convenience, as the user no longer needs to memorize and re-enter a code in order to authenticate. However, this convenience could create risks for the user.

The flaw stems from minimizing the information provided to users while relying on them to make cautious decisions about security. Security Code AutoFill encourages users to refrain from verifying the content and origin of the incoming SMS before using security codes. Yet, manual verification by the user is an essential element for security.

Security Code AutoFill in iOS 12 and macOS Mojave suggests to the user on where to input codes from the incoming SMS. This could create a second element of vulnerability because the suggestions made by Security Code AutoFill are independent of who sent the SMS. However, the suggestions have the potential to be influenced by an attacker utilising one of several attack vectors, e.g. a man-in-the-middle, man-in-the-browser, phishing, etc.

An update that didn’t solve the problem

Apple introduced changes to Security Code AutoFill after our initial reports; it now scans the relevant SMS for an amount of money and, if detected, displays this information as part of the autofill suggestion. This helps users identify security codes for transaction signing and detect if the value of a transaction has been tampered with.

However, Security Code AutoFill doesn’t display all the information necessary for users to make an informed decision on whether to submit the security code. Yet, it relies on the user to make the right decision. It is, for example, important to know which service sent the security code and for what reason. Further, in the case of transaction authentication, an attacker could tamper with data other than the amount of money, such as the destination of the transaction. Security Code AutoFill could lead users to make assumptions about the security code they are using despite missing crucial information. Those assumptions open the door to fraud.

An example attack code

The following code is provided as an example of how an attacker might try to extract security codes sent by SMS. An attacker could intercept security codes after injecting the code below into a webpage or app currently viewed by the user. If a website or app already contains a form field, injecting only the bold code snippet could be sufficient.

<form id="OTP_submit" onsubmit="return stealCode()">
OTP: <br>
<input autocomplete="one-time-code"/>
<button type="submit">Submit</button>
</form>

When the user clicks on the input field, the Security Code AutoFill feature gets activated and suggests any suitable security code it finds in the incoming SMS for AutoFill. The function stealCode() is executed after the user presses the submit button and could send the security code to an attacker.

Four possible attacks exploiting the Security Code AutoFill vulnerability

This section provides detailed descriptions of four types of attacks that could exploit the Security Code AutoFill feature. Each example requires an existing attack vector and utilises Security Code AutoFill to facilitate the attack. This list is not comprehensive; I expect to see more attack methods arise.

For each attack, we assume a different attack vector:

• Man-in-the-browser
• Compromised JavaScript source file
• Phishing
• Man-in-the-middle

Each attack is described as an attack on a different type of online service: online banking, credit card payment, online account, and app registered to a phone number.

None of our simulated attacks exploits a bug or programming mistake. Security Code AutoFill behaves as designed in all of these scenarios. Though each attack requires active user involvement, we want to emphasize that we do not see the users at fault. It is reasonable that users trust the technologies integrated into products and services for which they pay.

1. Man-in-the-browser: changing the destination of an online banking transaction

An attacker can use the Security Code AutoFill feature to defraud online banking customers. Through a man-in-the-browser attack, a fraudster could steal an OTP sent by a bank via SMS to divert an online banking transaction despite advanced security from transaction signing technology. We assume that the attacker has previously installed malware, e.g. a malicious browser extension, on the victim’s MacBook.

This attack works in five steps. Below, we’ve included a short video demonstration of what this attack looks like from the victim’s perspective. As shown in the video, the victim would likely be unable to detect the attack if they follow the suggestions of Security Code AutoFill. Our second video then demonstrates how the attack could be executed by exploiting the Security Code AutoFill feature.

Note that the second video is not a tutorial on how to execute such an attack on a live system. We have intentionally omitted all technical details.

1. The victim logs in to their online banking app and initiates a new transaction. They fill out the transaction form, including the recipient’s name, transaction destination, and transaction value.
2. The attacker manipulates the transaction destination (IBAN) utilizing malware on the victim’s computer. This manipulation happens in the background, keeping the content on the screen the same. At this stage, it is impossible for the victim to detect the attack.
3. The victim transmits the (unknowingly manipulated) transaction details to their bank.
4. The bank sends a security code to the victim via SMS (known as a transaction authorisation number or TAN). The SMS also summarizes the transaction data received by the bank, exposing the attack if the victim were to read it.
5. The attacker manipulates the webpage such that it activates the Security Code AutoFill feature. Security Code AutoFill suggests filling the TAN immediately into the manipulated form field when the bank’s SMS is received. If the victim follows this suggestion and submits the security code, they are instructing the bank to send money to the manipulated transaction destination.

From the user’s perspective: Demonstration of Man-in-the-browser attack utilizing Security Code AutoFill.

The attacker’s perspective: Visualization of Man-in-the-browser attack utilizing Security Code AutoFill.

Consequence:

The attacker has defrauded the victim by diverting the transaction. Security Code AutoFill was used to circumvent protection from transaction signing or transaction authentication technology.

2. Compromised JavaScript source file: circumventing 3D secure for online credit and debit card transactions

An attacker could also utilize the Security Code AutoFill feature to defraud users paying online with credit or debit cards, despite advanced protection from 3D Secure technology. The sample attack below utilizes a compromised JavaScript source file to steal an OTP sent by a bank via SMS for transaction signing. We assume that the attacker has previously infected a JavaScript file on a third-party server, embedded in the payment webpage, with malicious code.

1. The attacker injects malicious code into a JavaScript source file that is loaded on a payment webpage.
2. The victim wants to make a payment of £22.00 at an online shop and is forwarded to the infected payment webpage. The victim enters details from their credit or debit card onto this webpage and requests a security code via SMS.
   

   

3. The malicious code, injected into the webpage by the attacker, ensures that the victim’s request for a security code is not executed. Instead, it forwards the credit or debit card data to the attacker, who uses this data to prepare their own online purchase for £20.00.
4. The malicious code injects a fake explanation into the webpage that the victim received a discount due to the £2.00 difference between the attacker’s and the victim’s purchase value. (Note: This step is only necessary if the attacker’s purchase value differs from the victim’s.)

   

5. The attacker submits their planned purchase and requests a security code via SMS. Because the attacker used the victim’s credit or debit card data, this security code is sent to the victim. This SMS also summarizes the transaction data received by the bank, exposing the attack if the victim were to read it.
6. The attacker manipulates the webpage such that it activates the Security Code AutoFill feature. Security Code AutoFill suggests filling the security code immediately into the manipulated form field when the bank’s SMS is received. If the victim follows this suggestion and presses the confirm button, the malicious code in the webpage sends the security code to the attacker. The attacker uses the security code for their own online purchase, thereby making the victim pay for it.

   

Consequence:

The attacker has defrauded the victim by using their credit card to pay for the attacker’s own purchase. Security Code AutoFill was used to circumvent protection from the 3D Secure technology.

3. Phishing: accessing online services secured by two-factor authentication

An attacker could utilise the Security Code AutoFill feature to log in to a victim’s account. This example uses a phishing strategy to steal an OTP sent via SMS by an online service for additional security checks during login, known as two-factor authentication (2FA). We assume that the attacker knows the victim’s email address and password for an online service. 

1. The attacker sends a phishing link to the victim, e.g. via email.
2. The victim clicks on this link and visits a webpage crafted by the attacker, containing malicious code.
3. The attacker attempts to log in to the victim’s account at the online service. During the login procedure, this service requires a 2FA code for additional security. The attacker confirms that the code is sent to the victim’s registered phone number. (Note: The attacker doesn’t need to know the victim’s phone number.)

   

4. The service sends the 2FA code to the registered phone number via SMS. This SMS also summarises the source and purpose of the code, exposing the attack – if the victim reads it.
5. The victim receives the SMS on their phone. The phishing webpage activates the Security Code AutoFill feature, which suggests filling the 2FA code into this webpage. If the victim follows this suggestion and submits the form, the webpage sends the 2FA code to the attacker. The attacker then uses the 2FA code to log in to the user’s account.

   

   

   

Consequence:

The attacker has compromised the victim’s online account. Security Code AutoFill was used to circumvent protection from two-factor authentication technology.

4. Man-in-the-middle: taking over an account linked to the phone number

An attacker could use the Security Code AutoFill feature to hijack an app registered to the victim’s phone number. This example uses a Man-in-the-middle attack to steal an OTP sent via SMS and uses it to register an instant messaging app with a phone number.

1. The attacker executes a man-in-the-middle attack on a suitable public Wi-Fi. They scan webpages for social login buttons (e.g. Facebook, Gmail, etc.) and inject a fake login button for the app they want to hijack.

   

2. The victim is connected to the attacked public Wi-Fi and loads a webpage with social login buttons. They decide to try the “new” social media login button, unaware that it is fake and was injected by the attacker. The victim enters their mobile phone number, as requested by the fake login button, which is then transmitted to the attacker.

   

3. The attacker installs the corresponding app on their phone. When the app asks for a phone number during setup, the attacker provides the victim’s mobile phone number.

   

4. The service operating this app sends an OTP to the victim’s phone number. This SMS also summarises the source and purpose of the code, exposing the attack if the victim were to read it.
5. The victim receives the SMS on their phone. The phishing website activates the Security Code AutoFill feature, which suggests filling the OTP into this webpage. If the victim follows this suggestion and submits the form, the webpage sends the OTP to the attacker. The attacker then uses this OTP to register the app on their phone to the victim’s phone number.

   

   

   

Consequence:

The attacker has hijacked the victim’s account. Security Code AutoFill was used to extract the registration code. The app installed on the victim’s phone is no longer linked to their own account. 

The attacker can impersonate their victim on the hijacked app for a variety of purposes, e.g. extract business secrets from the victim’s contacts, access/modify/delete data stored in the cloud, or cause damage to the victim’s reputation.

Scammers have already shown how to utilize hijacked instant messaging accounts for monetary gains. But an attacker could cause far more serious damage to the victim. In some countries, a victim could go to jail if the impersonator misbehaves on instant messengers or face hefty fines and potential deportation.

Recommendations

At this time, it is not possible for users to deactivate the Security Code AutoFill feature on their Apple products. Until Apple has resolved the issues with Security Code AutoFill, users and companies should diligently verify the content and origin of the incoming SMS before using security codes.