Page 3 of 5
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.
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
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.
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.
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.
Yet another way two-factor authentication has been bypassed:
For a user to fall prey to Eurograbber, he or she must first be using a computer infected with the trojan. This was typically done by luring the user onto a malicious web page via a round of unfortunate web surfing or email phishing attempts. Once infected, the trojan would monitor that computer’s web browser for banking sessions. When a user visited a banking site, Eurograbber would inject JavaScript and HTML markup into their browser, prompting the user for their phone number under the guise of a “banking software security upgrade”. This is also the key to Eurograbber’s ability to bypass two-factor authentication.
It’s amazing that I wrote about this almost eight years ago. Here’s another example of the same sort of failure.
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.
In 2005, I wrote an essay called “The Failure of Two-Factor Authentication,” where I predicted that attackers would get around multi-factor authentication systems with tools that attack the transactions in real time: man-in-the-middle attacks and Trojan attacks against the client endpoint.
This BBC article describes exactly that:
After logging in to the bank’s real site, account holders are being tricked by the offer of training in a new “upgraded security system”.
Money is then moved out of the account but this is hidden from the user.
[…]
Called a Man in the Browser (MitB) attack, the malware lives in the web browser and can get between the user and the website, altering what is seen and changing details of what is being entered.
The solution is to authenticate the transaction, not the person.
EDITED TO ADD (2/6): Another link.
The company, not the algorithm. Here’s the corporate spin.
Our investigation has led us to believe that the attack is in the category of an Advanced Persistent Threat (APT). Our investigation also revealed that the attack resulted in certain information being extracted from RSA’s systems. Some of that information is specifically related to RSA’s SecurID two-factor authentication products. While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack. We are very actively communicating this situation to RSA customers and providing immediate steps for them to take to strengthen their SecurID implementations.
Here are news articles. The worry is that source code to the company’s SecurID two-factor authentication product was stolen, which would possibly allow hackers to reverse-engineer or otherwise break the system. It’s hard to make any assessments about whether this is possible or likely without knowing 1) how SecurID’s cryptography works, and 2) exactly what was stolen from the company’s servers. We do not know either, and the corporate spin is as short on details as it is long on reassurances.
RSA Data Security, Inc. is probably pretty screwed if SecurID is compromised. Those hardware tokens have no upgrade path, and would have to be replaced. How many of the company’s customers will replace them with competitors’ tokens. Probably a bunch. Hence, it’s in RSA’s best interest for their customers to forget this incident as quickly as possible.
There seems to be two likely scenarios if the attackers have compromised SecurID. One, they are a sophisticated organization who wants the information for a specific purpose. The attackers actually are on RSA’s side in the public-relations spin, and we’re unlikely to see widespread use of this information. Or two, they stole the stuff for conventional criminal purposes and will sell it. In that case, we’re likely to know pretty quickly.
Again, without detailed information—or at least an impartial assessment—it’s impossible to make any recommendations. Security is all about trust, and when trust is lost there is no security. User’s of SecurID trusted RSA Data Security, Inc. to protect the secrets necessary to secure that system. To the extent they did not, the company has lost its customers’ trust.
Sidebar photo of Bruce Schneier by Joe MacInnis.