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.
Posted on June 20, 2018 at 6:51 AM •
Access Now has documented it being used against a Twitter user, but it also works against other social media accounts:
With the Doubleswitch attack, a hijacker takes control of a victim’s account through one of several attack vectors. People who have not enabled an app-based form of multifactor authentication for their accounts are especially vulnerable. For instance, an attacker could trick you into revealing your password through phishing. If you don’t have multifactor authentication, you lack a secondary line of defense. Once in control, the hijacker can then send messages and also subtly change your account information, including your username. The original username for your account is now available, allowing the hijacker to register for an account using that original username, while providing different login credentials.
Three news stories.
Posted on June 19, 2017 at 6:44 AM •
I’ve previously written about the serious vulnerabilities in the SS7 phone routing system. Basically, the system doesn’t authenticate messages. Now, criminals are using it to hack smartphone-based two-factor authentication systems:
In short, the issue with SS7 is that the network believes whatever you tell it. SS7 is especially used for data-roaming: when a phone user goes outside their own provider’s coverage, messages still need to get routed to them. But anyone with SS7 access, which can be purchased for around 1000 Euros according to The Süddeutsche Zeitung, can send a routing request, and the network may not authenticate where the message is coming from.
That allows the attacker to direct a target’s text messages to another device, and, in the case of the bank accounts, steal any codes needed to login or greenlight money transfers (after the hackers obtained victim passwords).
Posted on May 10, 2017 at 6:50 AM •
NIST is no longer recommending two-factor authentication systems that use SMS, because of their many insecurities. In the latest draft of its Digital Authentication Guideline, there’s the line:
[Out of band verification] using SMS is deprecated, and will no longer be allowed in future releases of this guidance.
Posted on August 3, 2016 at 7:11 AM •
CitizenLab is reporting on Iranian hacking attempts against activists, which include a real-time man-in-the-middle attack against Google’s two-factor authentication.
This report describes an elaborate phishing campaign against targets in Iran’s diaspora, and at least one Western activist. The ongoing attacks attempt to circumvent the extra protections conferred by two-factor authentication in Gmail, and rely heavily on phone-call based phishing and “real time” login attempts by the attackers. Most of the attacks begin with a phone call from a UK phone number, with attackers speaking in either English or Farsi.
The attacks point to extensive knowledge of the targets’ activities, and share infrastructure and tactics with campaigns previously linked to Iranian threat actors. We have documented a growing number of these attacks, and have received reports that we cannot confirm of targets and victims of highly similar attacks, including in Iran. The report includes extra detail to help potential targets recognize similar attacks. The report closes with some security suggestions, highlighting the importance of two-factor authentication.
The report quotes my previous writing on the vulnerabilities of two-factor authentication:
As researchers have observed for at least a decade, a range of attacks are available against 2FA. Bruce Schneier anticipated in 2005, for example, that attackers would develop real time attacks using both man-in-the-middle attacks, and attacks against devices. The”real time” phishing against 2FA that Schneier anticipated were reported at least 9 years ago.
Today, researchers regularly point out the rise of “real-time” 2FA phishing, much of it in the context of online fraud. A 2013 academic article provides a systematic overview of several of these vectors. These attacks can take the form of theft of 2FA credentials from devices (e.g. “Man in the Browser” attacks), or by using 2FA login pages. Some of the malware-based campaigns that target 2FA have been tracked for several years, are highly involved, and involve convincing targets to install separate Android apps to capture one-time passwords. Another category of these attacks works by exploiting phone number changes, SIM card registrations, and badly protected voicemail
Boing Boing article. Hacker News thread.
Posted on August 27, 2015 at 12:36 PM •
Man-in-the-middle attack against a Brazilian payment system:
Brazil has an extremely active and talented cybercrime underground, and increasingly Brazilian organized crime gangs are setting their sights on boleto users who bank online. This is typically done through malware that lies in wait until the user of the hacked PC visits their bank’s site and fills out the account information for the recipient of a boleto transaction. In this scenario, the unwitting victim submits the transfer for payment and the malware modifies the request by substituting a recipient account that the attackers control.
This is the sort of attack that bypasses any two-factor authentication system, since it occurs after all authentication has happened. A defense would be to send a confirmation notice to another device the account-owner owns, confirming the details of the transaction.
Posted on July 9, 2014 at 7:30 AM •
Twitter just rolled out a pretty nice two-factor authentication system using your smart phone as the second factor:
The new two-factor system works like this. A user enrolls using the mobile app, which generates a 2048-bit RSA keypair. The private key lives on the phone itself, and the public key is uploaded to Twitter’s server.
When Twitter receives a new login request with a username and password, the server sends a challenge based on a 190-bit, 32 character random nonce, to the mobile app — along with a notification that gives the user the time, location, and browser information associated with the login request. The user can then opt to approve or deny this login request. If approved, the app replies to a challenge with its private key, relays that information back to the server. The server compares that challenge with a request ID, and if it authenticates, the user is automatically logged in.
On the user end, this means there’s no string of numbers to enter, nor do you have to swap to a third party authentication app or carrier. You just use the Twitter client itself. It means that the system isn’t vulnerable to a compromised SMS delivery channel, and moreover, it’s easy.
Posted on August 8, 2013 at 12:20 PM •
This is an interesting article about a new breed of malware that also hijack’s the victim’s phone text messaging system, to intercept one-time passwords sent via that channel.
Posted on June 28, 2013 at 5:31 AM •
Yet another way two-factor authentication has been bypassed:
It’s amazing that I wrote about this almost eight years ago. Here’s another example of the same sort of failure.
Posted on December 10, 2012 at 1:04 PM •
This sort of attack will become more common as banks require two-factor authentication:
Tatanga checks the user account details including the number of accounts, supported currency, balance/limit details. It then chooses the account from which it could steal the highest amount.
Next, it initiates a transfer.
At this point Tatanga uses a Web Inject to trick the user into believing that the bank is performing a chipTAN test. The fake instructions request that the user generate a TAN for the purpose of this “test” and enter the TAN.
Note that the attack relies on tricking the user, which isn’t very hard.
Posted on September 14, 2012 at 11:23 AM •
Sidebar photo of Bruce Schneier by Joe MacInnis.