Categories
News Publication

New SPLICE Paper on Recurring Device Verification

The most common forms of authentication are passwords, potentially used in combination with a second factor such as a hardware token or mobile app (i.e., two-factor authentication). These approaches emphasize a one-time, initial authentication. Recent work has explored how to provide passive, continuous authentication and/or automatic de-authentication by correlating user movements and inputs with actions observed in an application (e.g., a web browser). The issue with indefinite trust goes beyond user authentication; consider devices that pair via Bluetooth.

The increased adoption of IoT devices and reports of inadequacy of their security makes indefinite trust of devices problematic. The reality of ubiquitous connectivity and frequent mobility gives rise to a myriad of opportunities for devices to be compromised. Thus, we argue that one-time, single-factor, device-to-device authentication (i.e., an initial pairing) is not enough, and that there must exist some mechanism to frequently (re-)verify the authenticity of devices and their connections.

In this paper we propose a device-to-device recurring authentication scheme – Verification of Interaction Authenticity (VIA) – that is based on evaluating characteristics of the communications (interactions) between devices. We adapt techniques from wireless traffic analysis and intrusion detection systems to develop behavioral models that capture typical, authentic device interactions (behavior); these models enable recurring verification of device behavior. 

To read more, check out the paper here.

Travis Peters, Timothy J. Pierson, Sougata Sen, José Camacho, and David Kotz. Recurring Verification of Interaction Authenticity Within Bluetooth Networks. Proceedings of the ACM Conference on Security and Privacy in Wireless and Mobile Networks (WiSec 2021), pages 192–203. ACM, June 2021. doi:10.1145/3448300.3468287. ©

Categories
News

Finding and reporting a device vulnerability

*Posted on behalf of Adam Vandenbussche, Dartmouth ’22*

My name is Adam and I’m a Dartmouth undergraduate researcher on the SPLICE project. I first became involved with SPLICE as a student in Professor Kotz’s COSC 89.26 SPLICE seminar course last fall. After spending the term reading and discussing papers considering a variety of security and privacy concerns in IoT, our culminating project was to conduct either a security or privacy analysis of an IoT device or to explore a topic of our choosing in an open-ended research project.

I’ve been curious to learn more about medical IoT, considering the particularly sensitive nature of the data this ecosystem produces and manages. For my project, I decided to analyze a Bluetooth-enabled device that, when paired with an accompanying smartphone app,* helps users monitor their medication adherence. To perform thorough testing of the device and app’s main functionalities, I used PCAP Remote  and Android’s adb utility, two open-source packet sniffers, to capture network and Bluetooth packets, respectively. I then analyzed the intercepted data using Wireshark, a popular open-source packet analysis program. 

I discovered a handful of mostly minor security and privacy vulnerabilities while analyzing the collected data, but one vulnerability particularly troubled me. Although the app’s API served most of its endpoints over the encrypted HTTPS protocol, it served two of them—the image upload and download endpoints—over the unencrypted HTTP protocol. The images transmitted over these endpoints could include user’s faces, such as for their profile picture, or medical information, such as images of documents discussing their medication. This lack of encryption to protect the transmission of highly sensitive information gravely threatened user privacy.

As a novice ethical hacker, I felt it important to alert the vendor of this vulnerability to avoid any further compromises of users’ privacy. I first informed the company over email, but much to my chagrin, my initial message—as well as the follow ups I sent 45 and 75 days later—went unanswered. Unfortunately, 90 days after my initial outreach I still had yet to hear from the company. 

My next step was to inform the vendor in writing by mail. Despite sending a registered letter including a report detailing how to reproduce the issue and the post office confirming its delivery, I still received no response from the company.

My last resort was to report the vulnerability to the Cybersecurity and Infrastructure Security Agency (CISA), a branch of the Department of Homeland Security, and hope that they would have more luck getting through. Within a week of submitting my report to CISA, I heard back from the vendor who acknowledged the vulnerability and disabled the implicated features. A day later, I received confirmation from CISA that they had successfully contacted the vendor who patched the issue.

Overall, I was most impressed with CISA’s quick turnaround time and learned a lot about the responsible disclosure process through this experience. It feels good that my work through the SPLICE project has had a direct, positive impact—however small—on the security of a smart product.

* As the disclosure has not been publicized, I will refrain from identifying the vendor.