There are more mobile devices than actual people on this planet. These contain loads of personal information, private files and sensitive data. We carry them everywhere at all times and as such, we are prone to lose them or leave them unattended. What are the real consequences of doing so?

News like the Apple vs FBI case help spread the idea that if a mobile device is locked, encrypted and protected with a PIN or biometrics, it is secure. The truth is, major OS including iOS and Android help and encourage you to downgrade security on locked devices through certain features and insecure settings. Personal assistants on mobile devices are very popular. Siri, OK Google and Cortana are just a few of them. They can perform multiple tasks including calls, sending emails and reading SMS among other sensitive actions. How secure are they? Can we trust our personal assistants to keep our data safe? How about displaying your notifications on the lock screen?

Let’s explore how secure mobile devices are when locked.

SMS is not secure

For years, the security community has been talking about the insecurities of SMS and why it should not be used as a secure channel for security purposes. I read over and over again how insecure 2FA over SMS is yet it seems that no one is listening. Using Google to search for articles on this matter, I used the year filter to see how far back in time I could go and find an article talking about it.

I was able to find articles discussing the issues of providing 2FA over SMS since 2014. Four years later, SMS is still the default method to deliver 2FA codes, or at least the fallback option. I guess it should not be a surprise given that today we still find even older vulnerabilities like buffer overflows and SQL injections. It seems that we struggle to get rid of attack vectors we know very well. There are different reasons and opinions for this but we will not get into that. What we can agree on though is that one effective method that makes the industry move forward in terms of security is awareness. Whether it’s through academic research, responsible disclosure or getting press by giving a cool name to a new type of vulnerability, if everyone talks about it, the industry tends to react.

With this in mind, I prepared a talk given in August at BSides Las Vegas titled “Ransombile, yet another reason to ditch SMS“. My goal? To bring yet again the issues with SMS to the table and help create awareness, like many others did before me.

2FA is the least of our problems

The articles I point out above have something in common, they all talk about 2FA. For some reason, everytime we discuss the insecurities of the SMS protocol we focus on 2FA. But there are other sensitive actions we do over SMS that are far worst than 2FA. For example, password reset.

We are accustomed to resetting passwords by receiving an email with a link to click. But there are other ways that you, or an attacker that knows your email, can choose to reset your password. That is, password reset over SMS or even automated phone call. Password reset over phone call is what I abused in my recent DEF CON talk “Compromising online accounts by cracking voicemail systems” but in this article we will focus on password reset over SMS.

So you get an idea of how common password reset over SMS is, Facebook, Google, Twitter, WordPress, LinkedIn, Paypal, Instagram, Netflix and Ebay are just a small subset of Alexa’s Top 100 websites that support it. Who cares about 2FA if we can directly reset the password?

Attack vector

If we agree that SMS is insecure, and we know that web services support password reset over this channel, what would the attack vector look like?

1. Obtain victim’s email
2. Use it to initiate password reset in all websites
3. Obtain secret codes from SMS
4. Use them to complete password reset process in all websites
5. Set new passwords

If we can do all this, we can hijack anyone’s accounts. There are already many, very good articles talking about attack vectors for SMS in different scenarios. I’ll show you how to do it in a situation in which an attacker has physical access to the victim’s mobile device for a short period of time, while it’s locked, protected with PIN or biometrics and encrypted. Locked means secured right?

Obtain victim’s email

An email address is not exactly a secret but for the purposes of this research, let’s assume it’s unknown.

In the proposed scenario, we have physical access to the device but it is locked. In the past one could simply ask “Who am I” and it would display information about the owner, including the email. Nowadays the information is limited to the phone number, probably for privacy reasons. We need to circumvent that limitation.

We can leverage the assistant and ask it to send an email to a specific email address we control. That way, when the email is received, we can look at the sender and determine the email address of the mobile device owner.

Did you know that anyone can send emails from your mobile device even if it’s locked?

Obtain secret codes from SMS

The most important information needed is the temp codes required to complete the password reset process. How can we obtain them if the device is locked? While I don’t have empirical evidence, I can tell you from my observations that most people have the notifications on lock screen enabled.

What does this mean? It means that for convenience, users not only enable mobile assistants when the device is locked, but also they like to look at notifications, including SMS, without having to unlock it and open the specific app.

Anybody with physical access to the mobile device can look at the notification’s content without unlocking the device. I blogged about the dangers of having this feature enabled last year. Check my post “How to steal $2,999.99 in less than 2 minutes with Venmo and Siri“.

The three missing steps

Now that we know how to obtain the email address of the victim and can read the temp codes right off the lock screen, we just need to complete the missing steps of our attack vector: “initiate password reset in all websites” using the email, “complete password reset process in all websites” using the temp codes and “set new passwords”.

Asking the mobile assistant to send an email and read codes is something that we can do in seconds. The other three steps missing however require more time. If our aim is to compromise someone’s digital life, we want to hijack not one, but as many online accounts as we can. Time is limited though. Our victim may just have left the phone unattended on the desk while going to the bathroom. Or maybe the victim lost the phone and is rushing to the next computer to remotely wipe it. Sounds like we need automation…

Ransombile

Ransombile is a tool I wrote that automates the password reset process and allows you to perform the entire flow automatically for multiple sites at the same time. The aim is to automate the three steps that take the longest in our proposed attack vector.

Ransombile monitors the attacker’s email inbox for incoming emails and automatically populates the email address of the victim to initiate the password reset process for all websites. After doing so, the tool waits for the attacker to enter the temp codes for the different sites to complete the process by setting the attacker’s chosen password.

 

While developing the tool, I started to study APIs of popular services like Paypal and Facebook to understand the password reset flow and implement it so that the tool could do it automatically. It did not take long to realize that there are several problems with this approach. It takes time, it is tedious and I found that I was challenged with captchas more often than not when it was the tool resetting passwords. Also, my ultimate goal was to write a tool that could be easily expanded to support more online services that allow password reset over SMS. Having to implement password reset APIs yourself did not help the cause. That’s how I came up with the idea of using Selenium.

Selenium is a library that lets you interact with browsers at a UI level programatically. It is used by developers to test graphical interfaces as it mirrors user’s interaction. It basically simulates a human clicking buttons, filling up forms and generally navigating through the site. Turns out, Selenium was the perfect solution to the issues I was facing when implementing the APIs myself:

• Easy: Selenium’s API is pretty straightforward and simple. You reference items like you do with CSS
• Fast: There are browser extensions that record your interaction with a website and generates Selenium code automatically! A few tweaks and you just added support for a new site
• Convenient: I found that I wasn’t challenged as much with captchas when using Selenium to automate the password reset process as websites can’t tell it’s not a human clicking around

You can get Ransombile from my Github repo

Demo

This demo shows how Ransombile works and how it can be used to compromise someone’s digital life in less than 3 minutes of physical access to the locked device.

Ransombile can be found in my Github repo. My hope is that this tool can be used by security teams to demo yet another attack vector for SMS and help companies move away from supporting SMS for security purposes in favor of more secure channels.

Can we do better?

You may be thinking… this is fine but you require physical access to the device so it’s not that big of a deal. Well, that just means that it is a targeted attack but I still wanted to explore what would be required to be able to pull this off without physical access to the device.

If we go back to our five step attack vector, we see that just two of them require physical access to the device:

• Obtain victim’s email: We need to tell the personal assistant to send an email to obtain the victim’s email address. While an email address is not difficult to obtain, let’s just assume that we don’t know it
• Obtain secret codes from SMS: We need to look at the incoming SMSs to get the temp codes to complete the password reset

Let’s look at the state of the art and see if we can use previous research for our purposes.

Obtain victim’s email

How can we trigger personal assistance commands without having to interact physically with the device and without the victim noticing it?

“Hidden Voice Commands” by Nicholas Carlini, Pratyush Mishra, Tavish Vaidya, Yuankai Zhang, Micah Sherr, Clay Shields, David Wagner & Wenchao Zhou

These researchers found a way to mix commands for personal assistance with garble sounds. The idea is that you could play “noise” next to the victim and trigger commands without the victim realizing it. It reminded me of the great Burger King commercial that had people thinking twice about having a device always listening.

“DolphinAtack: Inaudible Voice Commands” by Guoming Zhang, Chen Yan, Xiaoyu Ji, Taimin Zhang, Tianchen Zhang, Wenyuan Xu

A great twist to the previous attack. In these case, the researchers send commands to mobile devices by sending audio at a low frequency that humans cannot hear. This is better than the previous attack as no one will be able to hear anything yet mobile devices can and will happily obey as the demo video demonstrates.

“Remote Command Injection on Modern Smartphones” by Chaouki Kasmi & Jose Lopes Esteves

My favorite one. These guys showed how they could craft voice commands as electromagnetic waves and have mobile devices receive and convert them to electrical signals through the headphone’s coil or even the charging cable. This research work is brilliant and you should read the paper.

Obtain secret codes from SMS

We need the temp codes to be able to reset passwords. How can we read SMSs that are sent to the victim without access to the device?

SS7: Locate. Track. Manipulate by Tobias Engel at CCC

Signaling System No. 7 are a number of protocols that could be abused to track and eavesdrop on victims calls among other attack vectors.

Practical Cellphone Spying by Kristin Paget at DEF CON 18

By jamming GSM frequencies corresponding to 3G, 4G and LTE it is possible to perform a downgrade attack and force mobile devices to use 2G. 2G networks may use the A5/1 cipher which was proven to be broken. Encrypted data like SMS can be decrypted by using specific rainbow tables.

Traffic Interception and Remote Mobile Phone Cloning with a Compromised CDMA Femtocell by Doug Deperry & Tom Ritter at DEF CON 21

Femtocells are small cellular base stations that can be used to improve coverage, specially indoors. Just like any other computer, it can be hacked giving the attacker a MiTM position between the attacker’s mobile device and the carrier.

SIM Swapping

SIM swapping is very popular lately. It consists of convincing an employee working for the victim’s carrier to “swap” his number to a new, attacker controlled, SIM card. It has been reported that this has been achieved not only through social engineering but also by working with rogue employees.

POC || GTFO

My proposal to use Ransombile without physical access to the victim’s device is purely theoretical. This is me just sharing an idea and you should not think it is possible just because I think it is. I have no demo to back my claims up and you should always demand that. Talk is cheap. Unfortunately, doing GSM stuff comes with many legal problems so I decided not to pursue this theory. I still think it is worth sharing in case you may want to look into it. I can picture an attacker next to the victim in an elevator for example, with a backpack containing a raspberry pi running Ransombile in conjunction with SDR hardware to trigger voice commands and intercept SMSs.

Recommendations

To wrap up, here is a list of recommendations I have for you:

• Don’t leave your mobile device unattended
• Disable the assistant in the lock screen
• Disable notifications preview in the lock screen
• Use apps for 2FA
• Don’t provide your phone number if not required
  • unless it’s the only way to get 2FA
  • use a virtual number to prevent OSINT and SIM swapping attacks
• Check the settings to disable security challenges over SMS

Media

• Ransombile source code
• BSides Las Vegas talk slides
• BSides Las Vegas talk Video