Perverse Vulnerability from Interaction between 2-Factor Authentication and iOS AutoFill

Apple is rolling out an iOS security usability feature called Security code AutoFill. The basic idea is that the OS scans incoming SMS messages for security codes and suggests them in AutoFill, so that people can use them without having to memorize or type them.

Sounds like a really good idea, but Andreas Gutmann points out an application where this could become a vulnerability: when authenticating transactions:

Transaction authentication, as opposed to user authentication, is used to attest the correctness of the intention of an action rather than just the identity of a user. It is most widely known from online banking, where it is an essential tool to defend against sophisticated attacks. For example, an adversary can try to trick a victim into transferring money to a different account than the one intended. To achieve this the adversary might use social engineering techniques such as phishing and vishing and/or tools such as Man-in-the-Browser malware.

Transaction authentication is used to defend against these adversaries. Different methods exist but in the one of relevance here—which is among the most common methods currently used—the bank will summarise the salient information of any transaction request, augment this summary with a TAN tailored to that information, and send this data to the registered phone number via SMS. The user, or bank customer in this case, should verify the summary and, if this summary matches with his or her intentions, copy the TAN from the SMS message into the webpage.

This new iOS feature creates problems for the use of SMS in transaction authentication. Applied to 2FA, the user would no longer need to open and read the SMS from which the code has already been conveniently extracted and presented. Unless this feature can reliably distinguish between OTPs in 2FA and TANs in transaction authentication, we can expect that users will also have their TANs extracted and presented without context of the salient information, e.g. amount and destination of the transaction. Yet, precisely the verification of this salient information is essential for security. Examples of where this scenario could apply include a Man-in-the-Middle attack on the user accessing online banking from their mobile browser, or where a malicious website or app on the user’s phone accesses the bank’s legitimate online banking service.

This is an interesting interaction between two security systems. Security code AutoFill eliminates the need for the user to view the SMS or memorize the one-time code. Transaction authentication assumes the user read and approved the additional information in the SMS message before using the one-time code.

Tags: , , , , , ,

Posted on June 20, 2018 at 6:51 AM • 33 Comments

Comments

Albert ARIBAUD • June 20, 2018 7:37 AM

Even autofilling on 2FA OTPs is problematic IMO — just like autofilling website logins and passwords in the browser was (or is? I don’t know if it’s still used). I am fine with replacing one check with another (e.g., does the user know the login and password to this site vs. does the user know the password to the database which contains the login and password to this site) but dropping one check (e.g., the user checks the 2FA OTP and copies it on a web page vs. the system guesses that the 2FA OTP is needed and provides it without any explicit user information and confirmation) is inherently a step in the wrong direction.

James • June 20, 2018 8:03 AM

@Tino

If you’re referring to intercepting texts via the SS7 network, the risk is pretty low (from what I’ve read online).

bttb • June 20, 2018 8:51 AM

OT, but OSX security related and an unnecessary risk:
From Ars Technica, https://arstechnica.com/information-technology/2018/06/reminder-macos-still-leaks-secrets-stored-on-encrypted-drives/ :

“Reminder: macOS still leaks secrets stored on encrypted drives
[…]
“The thumbnails remain even when the original file is deleted or the drive is disconnected or a volume is unmounted. Wardle and Reguła recommend people manually delete the folder that stores the thumbnails each time they disconnect a sensitive drive or volume. The commands: rm -rf $TMPDIR/../C/com.apple.QuickLook.thumbnailcache. Then sudo reboot. Another option is to execute the ‘qlmanage -r cache’ command, which appears to purge the cache without requiring a reboot. Apple representatives didn’t respond to an email seeking comment for this post.”

me • June 20, 2018 10:15 AM

@Albert ARIBAUD
as far as i know multiple password managers attempted autofil and everyone failed badly (even rce in some cases)

@Tino
YES

@James
It’s not only about ss7, think about sim porting scam: i go at shop i say that i want a new sim because X reason, they give me new sim, your is blocked, i receive all the codes i need. (same if i change operator)

@bttb
i don’t know mac, but windows is full of that kind of leaks, take a look at truecrypt/vercacrypt instruction manual

Humdee • June 20, 2018 10:17 AM

I dislike autofill features for an entirely different reason and that is there social conditioning effects. Even if, for example, the iOS feature could be programmed to distinguish the two kinds authentication the fact that users have become habituated to autofill may mean it is far less likely they will actually do the work that transaction authentication requires. We already know that most users will take the easy way out, they will do so here. The will come to see the codes as a hindrance (hell the fact that the programmers have created this feature already tells one that they think authentication is a hindrance) and thus fail to verify the data; they will punch in the code and get it over with.

Löchlein deluxe • June 20, 2018 10:26 AM

Well, if you receive the verification message on the same device your browser is on, you’re already being a bit naughty, aren’t you.

I can only wonder how long it will take until this will sync through Apple’s cloud to the user’s desktop browser’s autofill.

Andreas Gutmann • June 20, 2018 11:04 AM

@Humdee
The blog post on Bentham’s Gaze also discusses how this feature might trigger unreasonable expectations towards other security mechanisms, such as transaction authentication:

Even if the new Security Code AutoFill feature can distinguish between those SMS messages, users will inevitably get used to the convenience of this functionality. They might, very reasonably, expect similar convenience from other security technologies, not realising that this can be unrealistic. This can, in turn, discourage the uptake of more secure technologies, such as dedicated hardware tokens in transaction authentication.

Albert ARIBAUD • June 20, 2018 11:13 AM

@me

I did not say the 2FA autofill is ok if done by a password manager. I said that:

  • removing one count of actual user security confirmation is always bad for security;

  • for instance, the count of actual user security confirmations is not lowered when using a password manager to answer a login/password challenge, so using password managers for this purpose is ok;

  • the count of actual user security confirmations is always lowered when using autofill, irrespective of what does the autofill, even when said autofill would be performed by a password manager.

Anselm • June 20, 2018 11:36 AM

You know what would really be convenient? Autocompletion for passwords at the login prompt!

oliver • June 20, 2018 11:43 AM

Hi Bruce,
there is so much FAIL in there, I am struggling to find the beginning of it.
SMS for sending TAN? YGTBKM!!!!
There is nothing that is secure by using SMS!
The only reliable SECOND FACTOR is another device to authenticate the transaction and then generate a TAN. Such as those devices which you put against the screen and then they interact via flicker code with the browser window.
Here in Germany we call them TAN generators, just for that reason.

Cheers, Oliver

Petre Peter • June 20, 2018 12:45 PM

Is it truly a verification code if verification is done only by one side. It seems that AutoFill turns the verification code into a button.

AM • June 20, 2018 1:01 PM

UGG, this may be the moment where MFA has jumped the shark for me. This is like those fake windows that Gmail uses that aren’t really windows. Which is to say that you have a thing that doesn’t work like it looks like it does. This causes some insidious platform fragmentation issues, and both technical and non-technical users are going to potentially get tripped up by unconscious assumptions that this may violate.

IOS/OSX already can do this with push notifications(Not SMS Based). That means that the primary impact will be to 3rd party MFA solutions, where the 3rd party is likely just as ignorant of Apples tinkering as Apple is of the 3rd party’s implementation or intent.

Nothing bad has ever happened in the history of infosec when two groups start making assumptions on security systems without communicating right?

And can we please stop w SMS based MFA already? They aren’t secure, never were, and both incumbent Telcos and governments are invested in keeping it that way. You don’t control ANY of the SMS infrastructure, why would you use it for a trust based system when you can just implement it in the IP stack and control the process end to end?

Better yet use something like Google Authenticator and you don’t even need a working network connection on the device being used for MFA.

Apple shouldn’t be trying to mess with making SMS based MFA “easier”, they should be taking it out back and putting it down next to Old Yeller.

David Leppik • June 20, 2018 2:17 PM

So far this is all speculation that a feature that looks for phrases like “Your security code is #####” will get confused by “Never share this code… OTP ### MAKE A NEW PAYMENT of £#### to account ending in ####.”

I’m skeptical that this is a real issue. The sample bank message doesn’t contain an easily parsed phrase like “code is ####”.

Even if Apple picked a number from that text, the concern is not that people won’t see the message, but that they won’t read it; Apple continues to display the text message, it just offers it as an auto-complete suggestion.

Andreas Gutmann • June 20, 2018 2:53 PM

@David Leppik

Yes, we haven’t been able to test it as we don’t have an developer account to access the developer beta of iOS 12. The example SMS aren’t crafted to be imaginary prime example but old SMS on my phone (I obviously changed numbers etc though).
Yet, it’ll be challenging for Apple to design an algorithm that won’t confuse any 2FA OTP with a TAN (and vice versa), especially considering the plethora of languages used.
Being inconsistent between different banks and/or 2FA services would probably confuse many people and might be decremental to security in its own way.

The concern here is that people “learn” from this feature that they only need to click or tap an AutoFill suggestion, which is false in the case of transaction authentication. As I wrote in the blog post:

Whether it is justified to place the burden on users who behave as encouraged by the technology is both a philosophical and legal question.

Jesse Thompson • June 20, 2018 3:12 PM

All of the discussion (which I agree with) of the untrustworthiness of the SMS channel just makes me want to work out a protocol that’s hybrid TOTP and SMS based.

Picture this. You have a TOTP generator app on your phone. But the website also sends you an SMS. TOTP app intercepts the SMS, and processes more incoming data than current SMS authentication methods send (more than 6 decimal digits, probably a longer string of base64 or yEnc) that represents some message signed by a key which the TOTP app has a public key of.

Then iff your TOTP app recognizes the signed data, it spits out a 6 digit HMAC built from the SMS information combined with it’s secret TOTP token and with the current time. If the SMS data included some transactional context, then it can display that for the user to review as well.

This should have the following properties:

  1. Not less convenient than TOTP-on-mobile-app combined with SMS. You still have to run a TOTP app, you still have to be on network to receive an SMS. Like SMS and unlike ordinary TOTP the code pops up for you instead of having to go manually open the app.
  2. More secure than either method by itself.
    • Somebody redirecting your SMS can’t get a valid code to enter because they lack your TOTP token.
    • Somebody using a leaked TOTP token needs the extra step of also redirecting your SMS to make use of it.
    • Somebody tricking you into entering a TOTP token via phishing fails unless they can impersonate the webserver by emitting a signed SMS message (eg: steal webserver’s secret key).
    • Somebody trying to MITM the SMS (sounds harder than simple SIM redirection to begin with) is still screwed because the SMS data is signed at the webserver.
    • And of course the TOTP specialty of making the SMS information potentially worthless outside of a certain period of time, no matter what Eve can steal.
  3. Security of TOTP augmented by situational confirmation SMS is capable of, such as the TAN example above.

What do you guys think? Is this a system already practiced or at least discussed elsewhere? I’m invoking the principal of “there are no new ideas, only the Internet which is full of people who had those ideas first” lol. :J

Jesse Thompson • June 20, 2018 3:17 PM

Update to my previous idea:

While going over all of the permutations in my head it sounds as if the SMS information represents an HMAC and thus HOTP would be a better fit than TOTP as the Time element of TOTP only exists as a weak substitute for a provider-issued HMAC to begin with. :J

TruePath • June 20, 2018 5:32 PM

The goal of transaction authentication is to get the user to examine and approve the particular details of the transaction described. A system with authenticates transactions by just including the transaction info in the same message with a security code and only requiring the security code is already broken.

I mean it hardly matters whether the autofill is the result of a digital convenience or it was the user’s own mental laziness that lead them to skim for the code and type it in without reading the message. Both allow the same kind of vulnerability.

They both allow for an easy fix though. Require the user to enter details that can only be learned by reading the transaction details into the confirmation screen. The usual way to do this with bank transfers is for confirmation to require the last 4 digits of the source and dest accounts to be entered, the amount and the verification code.

If that’s too inconvenient you can instead distribute the verification code over the information in the transaction authentication, e.g., all fields, e.g., the msg gives X-acct, Y-amount, Z-dest where XYZ is the TAN.

Ultimately, this isn’t so much a vulnerability but a reminder that if all you have to type in is the TAN at the end of the message you aren’t doing it right.

TruePath • June 20, 2018 6:08 PM

@Jesse Thompson,

That seems like a nice start to the problem of making cell phone based authentication more secure. However, why bother reinventing the wheel when WebAuthn has been standardized and gives you all the benefits you describe more conveniently with the extra bonus of requiring not merely possession of the phone but knowledge of the user’s password or fingerprint.

Also, there is some danger in over-engineering something which is ultimately designed to provide only a modest (but entirely sufficient) level of security. I mean it’s kinda like replacing your home door with a steel vault door. All it does is lead people to feel a false sense of security (potentially dangerously) and send people who want to break in through the window.

I mean your true biggest security threat is probably just having your phone snatched while authenticated or a snatch followed by a password guess.

PeaceHead • June 20, 2018 8:00 PM

It seems like all these annoyances when mixed and matched reveal crossbreeds/hybrids of vulnerabilities every time! I hate SMS/texts and I hate telephone banking and I hate iOS and iPhones and “smart” phones and robo-calls and autofill and unauthorized attempts on my account and non-solicited interactions from institutions and individuals trying to get at my private info or my funds.

These are all combining lately, just like every other vulnerability. I suppose the combinations are exponentially endless if considering the massive numbers of exploits.

So getting back to the bigger context,…

The GOLDEN AGE of Computing is Over!, quit, halted, kaput, abgesagt. 🙁
Now we just sit back and wait for [it] to hit the fan.

sitaram • June 20, 2018 8:25 PM

@Bruce:

I don’t know how you can call autofill a “security system”. It’s a “convenience” system, and we all know that is the opposite of security.

This is not a conflict between two security systems; it is a convenience system undermining a security system.

Peanuts • June 20, 2018 11:09 PM

How nice, Apple so eagerly wanting to become part of the transaction. Now when anyone needs to dispute an authization, Apple will have touched it last. As a result they do have transaction liabilitie where they had less previously.

If you touch it last, you own it Apple

5 • June 21, 2018 6:13 AM

Reason behind 2FA is using two independent devices (or at least 2 independent channels). Even using a single device to make transaction AND to verify it undermines 2FA, but at least you need to exploit browser and SMS at the same time. This new feature makes 2FA totally worthless. It’s not even “convenience system”, it actually removes a security system.

Neeran • June 21, 2018 8:48 AM

My bank’s OTP mechanism has a “feature” along similar lines. When a message is sent for transaction verification, there’s some generic text up front, like “Your four-digit code for adding a beneficiary to your account is…”. Not only does this indicate the purpose of the transaction, it also ensures that the actual OTP isn’t visible in the notification. You’re forced to open the message and remember/copy the OTP.

Clive Robinson • June 21, 2018 1:53 PM

@ All,

In part I am responsible for the use of SMS as a side channel for sending a One Time Code back in the 1990’s. It was an unreliable system back then due to the Mobile Service Providers treating SMS as “delivery of opportunity” that is you might or might not get it in eight hours depending on various back end issues[1].

However I quickly realised[2] that authenticating the comms channel and not the actual transactions was a glaring security hole, and further so was not authenticating “through the human” to move the security end point. This was before “smart phones” which put the internet and SMS channel on the same device with easy security end runs.

Something @Nick P and I had a lengthy conversation on was the issue of what was immutable or not in a token device, and why it should not use USB or a camera etc. A point that is now moot because attackers have used them as attack vectors…

What I realised was that the big big issue is lack of human ability to do security in any meaningful way. Computers can do in uS what humans could take a day or so at, when it comes to crypto algorithms and much else besides. Therefor I tried to find something easy for humans but hard for computers so I looked around and character recognition in large amounts of distortion and noise appeared to fit the bill, so captchas appeared to be the way to go. Turns out I was wrong, the Chinese had groups of very low paid workers happy with just a cent or two to copy type them into computers to quickly solve captchas, which should be a salutary lesson to all of us…

[1] I worked out the only practical solution at the time which was to “Dial Ahead”. That is the problem was that the MSPs would lose location information and only try to find the mobile if a primary service was being used. SMS being at best a “secondary service” they did not bother looking for the mobile on the weak assumption it would be “used or moved” in eight hours. So a quick dial would make the MSP network go on a hunt for the mobile, if found an SMS would get delivered in seconds, not hours. Since then those supplying the MSPs with equipment have upped the game as has the need for data services so SMS are not the problem they once were.

[2] See numerous postings on this blog, having to explain why and how I got a security cheat wrong using captchas.

lurker • June 21, 2018 7:15 PM

I’m assuming this problem is for people who do their banking on their iPhone? then serves ’em right. I’m an old fuddy-duddy, and airgap the two parts of two-factor authentication. The baddies will get me one day, but they shouldn’t need Apple’s help…

Andreas Gutmann • June 22, 2018 5:02 AM

@ lurker

Security Code AutoFill will also work with Safari on your iMac or MacBook (if you synchronised with your iPhone), utilising the Text Message Forwarding feature. There’s a screenshot in the blog post.

eRnie • June 22, 2018 9:16 AM

@ sitaram,

It’s a “convenience” system, and we all know that is the opposite of security.

No, it’s not. They’re often at odds, but not opposites. A classic example is a camera cover on a mobile device. Sliding a cover to open the camera is simple and obvious; if the device detects that you did it, and goes straight to the camera app, you don’t have to go through any menus.

More directly relevant, password autofill systems can improve security and convenience: they let people use more secure passwords, and make it harder to leak the password to a lookalike site. And they often store the password in encrypted form, unlike an ad-hoc “passwords.txt”.

bttb • June 23, 2018 11:19 AM

@me
“i don’t know mac, but windows is full of that kind of leaks”

Thanks for the feedback. It has been pointed out many times on this blog that it is difficult, of course, to get personal or organizational security right. Especially against a formidable competitor (or adversary or threat model).

vas pup • June 26, 2018 9:04 AM

Voices of millions of UK taxpayers stored by HMRC:

https://www.bbc.com/news/technology-44601468

“The Voice ID scheme, which was launched last year, asks callers to repeat the phrase “my voice is my password” to register.

Once this task is complete, they can use the phrase to confirm their identity when managing their taxes.

“These voice IDs could allow ordinary citizens to be identified by government agencies across other areas of their private lives,” said Silkie Carlo, director of Big Brother Watch.”

My take: when Big Brother (government or private) collect you voice information, then you could be identified even when talking over the phone, other voice related applications, moreover using AI to create your voice avatar talking as you (sound/ vocalizations, style, choice of words…). The only sound remedy is to utilize text to voice applications which generate outside not your voice. It’ll be good if you also could specify desired style type to absolutely hide your own identity. By the way, in US as soon as you call to some private company they provide you with notice that all conversation is recorded for quality and (not kidding!) training purposes. So, by default they have your voice print and could share it with other business or government without your knowledge at all. Our ‘wise’ legislators did not grant YOU automatically the same right to conduct recording just for balance of power. Yes, interest of lobbyist is always higher priority than constituents.

JG4 • June 26, 2018 3:00 PM

@vas pup

I share your concern with voice-printing, but the real threat is that they can perfectly spoof your voice and speech patterns. The combined power is full spectrum dominance. You’ll find various descriptions of that threat model with my initials. That is a compelling reason for end-to-end encryption, where you control the endpoints.

William • August 31, 2018 9:11 AM

NIST, the National Institute of Standards and Technology issued guidance that found SMS insecure and no longer suitable as a strong authentication mechanism…

I am using WebADM Multi-Factor Authentication with Hardware Token and Hardware Security Modules (HSM) in order to comply with the highest security requirements…

This Security Solution is like a Swiss Army Knife. So many features, just have a look at https://www.rcdevs.com

It is even free up to 40 users.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.