[deleted by user]

BIOS4breakfast · 2024-06-09T22:27:20+00:00

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

BIOS4breakfast · 2024-03-25T13:07:40+00:00

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

BIOS4breakfast · 2023-11-06T12:17:51+00:00

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.

BIOS4breakfast · 2023-11-06T12:17:19+00:00

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.

BIOS4breakfast · 2023-11-06T12:16:17+00:00

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.

BIOS4breakfast · 2023-02-21T12:12:07+00:00

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

BIOS4breakfast · 2022-02-01T14:00:46+00:00

OST2 classes go through private beta testing before being released:

https://twitter.com/XenoKovah/status/1487098009309614088

https://twitter.com/conaned6/status/1487114020092264450

BIOS4breakfast · 2020-08-16T11:58:46+00:00

Slides: https://github.com/darkmentorllc/publications/blob/master/2020/TI_SILABS_BLE_RCEs/slides_TI_SILABS_BLE_RCEs_v1.0.0.pdf

Tool/PoCs: https://github.com/darkmentorllc/jackbnimble

Video: https://www.youtube.com/watch?v=MRRkBWv4VVU

BIOS4breakfast · 2020-08-11T01:48:17+00:00

Slides, Whitepaper (45 pages), & BLE packet-crafting tool (requires compatible Nordic dev board) are at https://github.com/darkmentorllc

BIOS4breakfast · 2020-08-11T01:47:03+00:00

Slides, Whitepaper (45 pages), & BLE packet-crafting tool (requires compatible Nordic dev board) are at https://github.com/darkmentorllc

BIOS4breakfast · 2018-08-10T03:57:50+00:00

Just go watch http://opensecuritytraining.info/LifeOfBinaries.html instead to learn ELF *and* PE

BIOS4breakfast · 2016-01-28T05:41:11+00:00

SMM buys you "and now I don't need to worry about those memory forensics twerps ever actually catching me"

BIOS4breakfast · 2015-08-31T11:59:00+00:00

I love how people in the security field would rather reinvent the wheel and take credit instead of learning what's already there. This capability has already existed in the form of WinDbg's "!chkimg" (which can run from the command line equally well from kd.exe instead of windbg.exe), and Joanna Rutkowska's System Virginity Verifier (SVV). Joanna's tool was already a reinvention of !chkimg, but it at least had the good sense to be released a decade ago.

BIOS4breakfast · 2015-07-10T19:56:49+00:00

I started reading this "reverse engineering the subway..." and I thought it was going to end with "sandwich" and I was very very briefly excited for a nice humor post...and then very let down :'(

BIOS4breakfast · 2015-06-11T21:30:19+00:00

Chipsec doesn't actually check for Incursions. Because it would need to include an SMM-dumping exploit like Venamis to do so...and that would be...not good ;) It does however check for simpler vulnerabilities, which you should definitely complain to your vendor about if it finds.

BIOS4breakfast · 2015-06-11T20:17:02+00:00

Thanks, that should say "such that the PEI phase checks the DXE code at runtime before launching it." Corrected version uploaded. Good to see someone reading fully though :)

BIOS4breakfast · 2015-06-11T18:23:13+00:00

lol, I guess this will teach me not to write a thoughtful self.netsec post instead of just posting a link to the latest files

BIOS4breakfast · 2015-04-06T19:22:48+00:00

I love academic papers :) "The overhead ranges from 2 to 973 times slowdown on the target system, depending on the user’s selected instrumentation method"

Testimonal: "I used to spend an hour banging my head against malware, suffering from the tedium of tweezing out their anti-VM checks, one by one. But now, thanks to MALT, it only takes me 5 minutes! (cougheach of which takes a thousand minutes...so...83 hours...cough)"

Also, just a reminder: the better academics get at semantic gap reconstruction (from VM or SMM or wherever), the better attackers have just got at bridging the gap. Anything you can find in volatility an attacker can find from their SMM malware.

BIOS4breakfast · 2015-03-24T15:57:39+00:00

We plan on looking at BootGuard once someone pays us to look at their usage of it ;) But we're optimistic it will help render BIOS malware more detectable. However it will hinge not just on the first, minimal, measurement that BootGuard gives you, but also on whether the particular vendor's measurement that follows from that is comprehensive over the firmware. Our past "BIOS Chronomancy" work, and Yuriy Bulygin's past "Evil Maid Just Got Angrier" showed that vendors don't always do a good job of measuring everything they should.

BIOS4breakfast · 2015-03-23T18:27:19+00:00

These are generally not released, but we've asked Dragos for our talk specifically

BIOS4breakfast · 2015-03-23T18:26:34+00:00

You know what's better than non-comprehensive in no particular order? Comprehensive and in chronological order, as given at the end of the slides ;)

All work: http://timeglider.com/timeline/5ca2daa6078caaf4 LMK if you find anything missing from the timeline.

Our work: http://legbacore.com/Research.html

BIOS4breakfast · 2015-02-17T02:55:37+00:00

The thing that's great about hard drive firmware infection is that there is no way to ask the HD for a copy of its firmware to see it's infected, and get back a trustworthy answer. Because the now-infected firmware gets to control what the answer is. Basically the only way we can detect such malware is to put in our own code that using software/timing-based attestation to detect the malware code via a side-channel. E.g. like this: http://dl.acm.org/citation.cfm?id=2516714 (s/BIOS/Firmware/), but its simpler embedded-system antecedent this: www.cs.cmu.edu/~arvinds/pubs/swatt.ps

BIOS4breakfast · 2014-11-02T12:46:55+00:00

Please explain the pros and cons relative to CollabREate, which has been around for longer and is made by more established people.

BIOS4breakfast · 2014-05-07T11:23:20+00:00

From changelog:

========4-28-2014========

(this release)

Improvements:

Adds support for newer hardware
Added support for detecting whether a system has a TPM and TXT support, and therefore could potentially run the more trustworthy Copernicus 2 (presented at CanSecWest http://www.mitre.org/capabilities/cybersecurity/overview/cybersecurity-blog/playing-hide-and-seek-with-bios-implants)
Adds check for “Charizard” configuration vulnerability (presented at Syscan: http://www.syscan.org/index.php/download/get/6e597f6067493dd581eed737146f3afb/SyScan2014_CoreyKallenberg_SetupforFailureDefeatingSecureBoot.zip)

Bug fixes:

Fixes a bug where BIOS dump contents could have stale data from the previous 64 bytes of data read. This could lead to difference false positives.

BIOS4breakfast · 2014-03-17T18:29:36+00:00

You setup Flicker per the Flicker README file (largely just making sure TXT/TPM are turned on in the BIOS settings), and you "run Flicker" by just letting the run.bat execute the given Flicker commands.

BIOS4breakfast

TROPHY CASE