1. Sending out an S.O.S. for SMS
10/4/2017 7:12:07 AM
Sending out an S.O.S. for SMS
SMS Exploitation,Bitcoin Wallet Hacking,SMS Security,Two-Factor Authentication
https://news-cdn.moonbeam.co/Sending-Out-An-SOS-for-SMS-App-Developer-Magazine_jg7mg8jq.jpg
App Developer Magazine
Messaging

Sending out an S.O.S. for SMS


Wednesday, October 4, 2017

Will LaSala Will LaSala

How SMS exploitations make it unreliable for two-factor authentication systems for many security experts.

What a difference a year makes. Just one year after the National Institute of Standards and Technology issued guidance that found SMS is insecure and no longer suitable as a strong authentication mechanism, it has walked all of that back.

At the time the original draft was published, it was highly unusual for any US government agency to get out in front of the security industry and take such a hard line stance on something that scores of professionals (and even hackers) had known for years. In this case, that SMS messages are not protected from prying eyes, and there is no assurance that they will actually go to the intended recipient.

When NIST published its most recent draft, in June, however, a special publication entitled "Digital Identity Guidelines: Authentication and Lifecycle Management," the SMS deprecation had been removed.

It's not entirely clear why it was removed or by whom, however, as most security professionals know, it is risky business to continue to allow companies to invest in SMS as a strong form of two-factor authentication. As the recently published draft and NIST Special Publication point out, there are (still) a number of security concerns that must be addressed if you are attempting to use SMS as a second form of authentication. It should also leave many in the industry asking why we should continue to use SMS at all.

This is not a recent development or a sudden seachange in how SMS authentication is perceived. The attacks on SMS and what is commonly referred to as "SIM Swap" date back nearly ten years. Today, the attacks are commonplace and are perpetrated on every carrier in the US, including Verizon, AT&T, T-Mobile, Sprint, and others.

SMS Exploits Go Mainstream


Increasingly, not only tech but also mainstream publications are discussing and detailing emerging attacks caused by these SMS exploits.

For example, in the telecom space, all an attacker has to do to take over a phone is to convince the telecom help desk operator that they are the rightful owner of the phone number in question. Depending on the telecom company, the hacker can do this in person or by phone or even via online chat.

Once the hacker has the new SIM, it's easy to have the SMS sent to the new phone and for the accounts to be compromised. Moreover, once a bad actor controls the phone number, they can also reset the passwords associated with every other account that uses that phone number as a security backup.

But why stop at just bank accounts and corporate accounts? Today's attacks are also focused on virtual assets, which, on balance, may be worth even more than some of the bank accounts that bad actors hack into.

Case in point: a recent article in the New York Times, describing how identity thieves are hijacking cellphone accounts to go after virtual currency. It goes on to describe how a virtual currency investor whose virtual currency wallet was drained of its contents of nearly $150,000 within minutes of hackers having gained control of his phone. And as the Times article points out, virtual currency transactions are designed to be irreversible.

As described in the Times article by other victims of cryptocurrency losses, SMS - required by most financial firms for tying customer online accounts to phone numbers in order to confirm their identity - remains the elephant in the room. The system will allow someone with the right phone number to reset passwords on accounts, even without knowing the original passwords. A hacker merely hits "Forgot Password" and instantly has a new code sent to the phone (and phone number) they've hijacked.

A Stronger Form of Authentication


The Times article underscores the bigger problem at hand, which is that most users rely on SMS authentication as their backup authentication method for allowing secure transactions, such as password changes.

If your organization intends to keep using classic SMS, it's a fine form of two-factor authentication when used for low value transactions (such as login or bill pay). But be warned: if you are considering using it for higher risk transactions (e.g., password or credit card changes, ACH, or wire transfers), maybe think again. The end user should be using (and protected by) a stronger form of authentication.

Not surprisingly, most companies today are using SMS as the second layer in their security approach. This means that if a user is attempting to perform something that's considered to be more risky (like a transaction), they will need to be prompted to meet a higher level of authentication in order to complete the riskier task.

However, the implementation behind most of these "step-up" SMS authentication mechanisms is rudimentary at best, and problematic at worst. Typically, they're randomly generated, stored in the backend and sent on the registered web service. No validation of the phone number occurs, nor is there further validation of who is holding the phone, or even some confirmation that an app on that particular phone actually generated the request that's being processed.

For its part, the NIST Special Publication addresses these issues by stating that the developer should use mechanisms to ensure the messages are encrypted and tied to a specific SIM card. This guidance, however, is extremely difficult for most developers as the native API's to interact with the SIM card require special permissions from the user. Using a product such as VASCO's DIGIPASS for Apps, with Secure Communication, will satisfy the NIST recommendations; however, few are leveraging these capabilities today.

So in summary, even though NIST may have backed down on their strong stance against using SMS as a true two-factor solution, every security team should evaluate their organization's use and reliance on SMS and put into place the proper controls to make sure SMS is not a security hole - either for their environment or for their customers. SMS was designed to allow rapid communications between telecom workers. At the time it was developed, it wasn't intended to be used to transmit secure messages. In fact, security was never the main driver for SMS.

As the Times article strongly suggests and as experience shows, SMS is quickly becoming a mainstream exploit that has extended well beyond hardcore threat hackers. Run of the mill criminals with very little (if any) technical knowledge can, with a smile and a virtual handshake, exploit SMS for monetary gain.

As a community, we have to evaluate how SMS is used and what types of communication should be used with this protocol. Leveraging technologies such as Secure Communication can help ensure the proper implementation of security on an otherwise insecure communication medium such as SMS.

DIGIPASS for Apps is a comprehensive software development kit (SDK) that natively integrates application security, two-factor authentication and electronic signing into mobile applications. To learn more, download VASCO’s product brief here.

This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.

Subscribe to App Developer Magazine

Become a subscriber of App Developer Magazine for just $5.99 a month and take advantage of all these perks.

MEMBERS GET ACCESS TO

  • - Exclusive content from leaders in the industry
  • - Q&A articles from industry leaders
  • - Tips and tricks from the most successful developers weekly
  • - Monthly issues, including all 90+ back-issues since 2012
  • - Event discounts and early-bird signups
  • - Gain insight from top achievers in the app store
  • - Learn what tools to use, what SDK's to use, and more

    Subscribe here