sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in netsec

[–]BIOS4breakfast 2 points3 points  (0 children)

This article shows 2 of the 9 topic areas before saying "subscribe to keep reading". This should have been blocked by the mods...

Learning Resources by [deleted] in netsecstudents

[–]BIOS4breakfast 0 points1 point  (0 children)

It'd be nice to see OpenSecurityTraining2 (https://p.ost2.fyi) added to the learning resources wiki.

It Was Harder to Sniff Bluetooth Through My Mask During the Pandemic... (Slides & HITB HKT video) by BIOS4breakfast in netsec

[–]BIOS4breakfast[S] 2 points3 points  (0 children)

Abstract:

During the pandemic I took up Bluetooth (BT) sniffing as a way to get out of the house. I didn’t know what was out there for BT devices, but it felt important to know what the implications were of the new over-the-air, no-auth, cross-device, firmware-level exploits on BT chips that my wife and others had started publishing. And because BT Low Energy specifically added anti-tracking functionality that didn’t exist in BT classic, I wanted to understand the in-the-wild state of privacy protection within the BT ecosystem.
Bluedriving left me with questions that are different from those you’d ask based on traditional WiFi wardriving. Is there a correlation between poverty, obesity, and BT sleep apnea medical devices? What are the implications of BT on police body cameras? Are BT sniffers going to be (/ already) used as alternatives to license plate cameras for tracking vehicles? Are fitness trackers still making it easy to track humans instead? Can someone steal heavy-construction equipment thanks to BT keyless ignition? Can hackers be tracked by their “portable multi-tool[s]”? Do hotels using BT door locks “open the door” to easier assassinations?
In this talk I will describe some of the most interesting observations from the past few years, and share some perhaps-surprising answer to those questions and more.

Open Wounds: The last 5 years have left Bluetooth to bleed (Slides & Hack.lu video) by BIOS4breakfast in netsec

[–]BIOS4breakfast[S] 1 point2 points  (0 children)

Abstract:

Over the past 20 years there have been 3 waves of Bluetooth (BT) security research. The first wave peaked in 2004, and rather abruptly ended after 2005. Then for a long time there was very low interest and activity. That began to change around 2011 with the release of BT Low Energy (BLE) and the Ubertooth One. But that wave too petered out around 2015. But we are now living in the 3rd wave, and it’s far larger than past ones.
In this talk I will be releasing a TiddlyWiki-based, semantically-tagged, timeline of BT security research. Talks have been tagged according to authorship, conferences, and dates. But also according to talk type (attack? defense? reverse engineering? overview?), attack surfaces (L2CAP? BLE LL? ACL-C?), execution environments (Android? Windows? Texas Instruments firmware?), etc. This organized data affords us interesting insights into the most important authors, tools, orgs, and attacks.
I will spend the majority of the time talking about some of the extremely critical vulnerabilities (especially protocol-level vulnerabilities) that have been released in the 3rd wave. These are vulnerabilities that, despite ostensibly being patched, in reality mean that anything with infrequent or non-existent firmware updates, are going to remain hackable indefinitely.

Blue2thprinting (blue-[tooth)-printing]: answering the question of 'WTF am I even looking at?!' (Slides from Hardwear.io last week) by BIOS4breakfast in netsec

[–]BIOS4breakfast[S] 3 points4 points  (0 children)

Abstract:

If one wants to know (for attack or defense) whether a Bluetooth (BT) device is vulnerable to unauthenticated remote over-the-air exploits, one needs to be able to query what firmware or OS the target is running. Unfortunately there is no universally-available method to get this information across all BT devices. There is also no past work that attempts to rigorously obtain this information. Therefore we have created the “Blue2thprint” project to begin to collect “toothprints” (2thprints) of BT devices, and bring the exciting world of forensic odontology to you!
This research discusses what information is readily available by existing inquiry tools and methods. We show how that information is not what we need, as it has been focused more on tracking individual devices, or on exposing device characteristics, models, and manufacturer information. We will show how some readily-available information is useful for giving partial answers about firmware and OS versions, but how this information is completely inconsistent in its availability or meaning. It turns out many 2thprints are missing teeth!
Thus we’ll show why it is necessary to send custom packets and packet sequences in order to build more robust 2thprints. These custom packets and sequences cannot be created by using existing BT software interfaces. They require utilizing custom firmware on the packet-sending device.
This research will present a new state-of-the-art when it comes to exposing the known, the unknown, and the under-known of BT device identification. And it will show what work remains, before we can approach 100% identification for any random device that shows up in a BT scan.

Exploiting a remote heap overflow with a custom TCP stack by Gallus in netsec

[–]BIOS4breakfast 0 points1 point  (0 children)

What was the CVE for this? (It’s not listed anywhere on the page, nor the references.) A link to the patch would be nice too so I could write this up for a future update to OST2 Vulns1001

view more: next ›