A while ago, I was at a friend’s house and he mentioned he had to join a work meeting. He used Google Meet to join. The WiFi was acting weird and he was not able to follow the discussion. Someone suggested that he could “call in” making a regular phone call. I overheard that and immediately found myself wondering if there was a way to join meetings I had not been invited to.
In today’s world and global market it is common to have teams spread all around the world. Corporations have offices everywhere, customers can be located in other countries, vendors operate overseas, and in general we have a need to communicate with people that are not in the same location as us.
Daily meetings are something many in the tech industry can relate to. And with teams, customers and vendors in different physical locations, it is common to use video calls. Many times, sensitive topics are discussed. Security, architectures, all hands, financial results, roadmap plannings, new features… These are only a few of the confidential topics discussed in video calls.
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.
I just achieved one of my career goals, giving a talk at DEF CON. What an incredible experience, I cannot thank enough the amazing people that make this con happen. My talk’s title was “Compromising online accounts by cracking voicemail systems” and I thought I write a blog post about it for people that was not able to attend. The goal of my talk was to demonstrate that the current state of security of voicemail systems is not much better than it was 30 years ago and what exactly is the impact of gaining unauthorized access to a victim’s voicemail today.
Voicemail systems have been with us for a long time and started to become popular in the ’80s. Just like with any other technology, the hackers and phreakers at the time got busy testing the security of these systems. They left us an amazing collection of articles and e-zines with valuable information of the approaches they took to hack them.
With that in mind, as in any other research, we need to start by looking into prior art.
Apple introduced a new set of features in iOS 8 and Yosemite under the name “Continuity”. These features allow iPhones to work with other iDevices such as Macs and iPads in new ways. Handoff, Instant hotspot and Airdrop are some of the new services offered by Continuity. Among these new services is one named “Call Relay”. Essentially, it allows one to make and receive phone calls via iDevices and route them through the iPhone. This is not your typical VOIP service as it’s a P2P connection based on a proprietary protocol.
In order for it to work, both devices (iPhone and the iDevice that makes/takes the call) need to be on the same WiFi. This is what caught my attention. Apple’s security white-paper is short and vague on this particular topic. Only four paragraphs are dedicated to explain how Call Relay works and the only security relevant information is as follows: “The audio will be seamlessly transmitted from your iPhone using a secure peer-to-peer connection between the two devices.”
How it works
The first step is to get a high level understanding of the protocol and how the different actors interact. Wireshark is our friend here. For easy reading, we will take the case of an incoming call from now on. That is, somebody calls the victim, his iPhone rings but he picks up the call on his MacBook.
As part of a Red Team engagement I found myself looking for a way to bypass two-factor authentication (2FA) in Lastpass. Unfortunately this happened before Tavis Ormandy reported multiple 0-days in Lastpass. Would have saved us so much time! Anyway, 2FA is an additional layer of security to protect user accounts from attackers that have already compromised your password. I mention this because it is key to understand the purpose of this post.
When you login into a service using your username and password, you will get an additional challenge before access is granted. Usually it is a 6 digit temporary code that changes every 30 seconds. Google authenticator, Authy and Toopher are just a few of the 2FA solutions Lastpass supports that are based on RFC6238 and RFC4226. There are other types of 2FA but these are the most common.
Venmo is a very popular mobile app which simplifies payments among friends. Once you link your bank account or credit card, you can start sending money to others, instantly.
With Venmo, you are not limited to just make payments. It allows you to charge others as well. Say your friend had no cash for that tasty burrito and you paid for it. You have the option to be proactive and “charge” your friend using Venmo. Charging someone does not mean that the money will be withdraw from his account, it just means that he will get a notification and see the pending payment in his account. Your friend has to accept the charge in order for the payment to happen. And this functionality is what we are going to take advantage of.
I am back from Amsterdam after presenting our research at Blackhat “Even the LastPass Will be Stolen, Deal with It!” together with Alberto Garcia. We had a blast at the conference and we got great feedback from the audience. Many asked for the video, slides, etc. so I though it was worth writing a post with all the details of our talk.
During one of Alberto’s red team pentests, he gained access to several machines and found that all of them had files with references to LastPass. He came to me and told me it would be cool to check how LastPass works and if it was possible to steal LastPass credentials. 10% of our time is for research so we made that our small project.
We found how creds where stored locally and wrote a Metasploit plugin so he could use it to extract vault contents from all the compromised machines. Thanks to the module, he was able to obtain SSH keys to critical servers and the pentest was a success.
Today, LastPass issued a security notice on their blog explaining that they detected some suspicious activity on their network. They believe that “LastPass account email addresses, password reminders, server per user salts, and authentication hashes were compromised” but also that the encrypted passwords (the vault) was not accessed.
What does all this really mean? I found the security notice a little vague and I thought that it is worth writing a post about what the breach exactly means and what the attackers can do with the stolen data.
Based on the LastPass notice, attackers have the following:
Let’s break it down and see what kind of attacks are possible…
As part of the time that my company offers for research, my good friend and talented hacker Alberto Illera (@algillera) and me decided to “checkout” LastPass.
Many of you may already know (or even use) LastPass. It is a pretty well known password manager that stores all your passwords in a “vault” and keeps them secure. Additionally, it can automatically populate the credentials for you when you visit a website in which your are registered making it easy to use more secure, random and unique passwords. You will just have to remember the master password that decrypts the vault and that’s all.
LastPass comes in many forms. As a browser plugin, as a mobile app or even as Webapp.
As you may agree, a service that stores all your passwords sounds like a cool target so we decided to have “A look into LastPass”, understand how it works, check if it really keeps our passwords secure and why not? Try to find vulnerabilities.
online storage, calendars, etc. This allows companies to avoid the hassle of having to manage all these services in house and simply outsource it. One of those services is email. A company can have their personal email domain but still working under the gmail platform.
I realized that when I enter a valid email address from a company using Google Apps, the response code is 302 with the location header containing an internal url. As you may know, 302 is used to indicate
the browser that the resource is in a different place, specifically where the location header points to. Read more