3 ms·

The problem with this exploit is it needs something on the device that sends out BLE packets. This is hardly the problem that it's made out to be. Excellent P

by mannyv 2y ago

The problem with this exploit is it needs something on the device that sends out BLE packets. This is hardly the problem that it's made out to be. Excellent PR team - every other site reporting makes it sound like they broke FmF. but with a process on the device the device has already been pwnd.

jeroenhd 2y ago
It's a matter of time before advertising SDKs within any ad-supported apps will start leveraging this to geolocate users without additional permissions. Especially for apps that already have location permissions (something as simple as a weather app) this will hardly be noticed.
- dmitrygr 2y ago
  Won't work on iOS. An app cannot simply get the local MAC address on iOS. Privacy reasons. And trying all the (2^8)^3 options will also not work - for power reasons you'll be quickly throttled.
  - jimiasty 2y ago
    You don't need MAC address - you just need the iPhone to broadcast specific BLE advertising packet/payload. Using Core Bluetooth API it is trivial, but you need to either: a) create an app that does it and user has to download it b) modify SDKs existing in apps (e.g. Ad SDKs) Also turning app/phone into a "BLE beacon" is only possible when app running in the foreground (on iOS).
    - dmitrygr 2y ago
      Please read the original source again. You need to KNOW (or guess) own mac address as it becomes a part of the key.
      - jimiasty 2y ago
        Yes, you are correct! Knowing the MAC makes the attack reasonable - let's say 5 hours compute for 3080Ti. Not knowing the MAC makes it exponentially harder. You can still "guess" it, but the search-space is vast and that would take bazillion-years. So to attack iOS device: - user has to download the app - app has to broadcast fake BLE - some other devices (e.g. Android/RasPi would need to pickup that MAC and pass it to you
  - jeroenhd 2y ago
    Could the 256^3 presets not be pre-calculated? It's not like the intent for these keys is to make them private and secure, so reusing the same key material except for the MAC address itself shouldn't be a problem, should it? Also, 16777216 possibilities really aren't that many these days. With six cores at approximately 3.5GHz, assuming verification costs about 1000 instructions per key, brute-forcing every possibility will take between 4 and 5 seconds at most (half that on average). With appropriate rainbow tables, I think that should be feasible?
    - dmitrygr 2y ago
      The problem is not pre-calculation. The problem is that because you don’t know your MAC address, you need to broadcast all of those things, since you don’t know which one will be valid. Either at once or sequentially. Either way, iOS will not let you set up that much broadcasting.
- gruez 2y ago
  >It's a matter of time before advertising SDKs within any ad-supported apps will start leveraging this to geolocate users without additional permissions. They still need bluetooth permissions, which is going to be sus for your average flashlight/weather/game app. >Especially for apps that already have location permissions (something as simple as a weather app) this will hardly be noticed. If the app already has location permissions, why would they need to pull off this attack? They get the user's location directly.
  - mschuster91 2y ago
    > They still need bluetooth permissions, which is going to be sus for your average flashlight/weather/game app. As if people would care about that...
  - jeroenhd 2y ago
    > They still need bluetooth permissions, which is going to be sus for your average flashlight/weather/game app. Looking at the apps I had to purge from family members' phones, I don't think that will be a problem. > If the app already has location permissions, why would they need to pull off this attack? They get the user's location directly. Accessing geolocation APIs will show an indicator and add an entry to a log (at least on Android). I don't believe accessing BLE APIs do the same.
WatchDog 2y ago
Yeah - you need code execution on the victim device - you need internet connectivity - you need bluetooth permission - if the victim device has GPS itself, then this attack is pointless because you may as well just use that directly.
anigbrowl 2y ago
Not a problem at all depending on what your goal is.

by mannyv 2y ago

jeroenhd 2y ago

It's a matter of time before advertising SDKs within any ad-supported apps will start leveraging this to geolocate users without additional permissions. Especially for apps that already have location permissions (something as simple as a weather app) this will hardly be noticed.

dmitrygr 2y ago
Won't work on iOS. An app cannot simply get the local MAC address on iOS. Privacy reasons. And trying all the (2^8)^3 options will also not work - for power reasons you'll be quickly throttled.
- jimiasty 2y ago
  You don't need MAC address - you just need the iPhone to broadcast specific BLE advertising packet/payload. Using Core Bluetooth API it is trivial, but you need to either: a) create an app that does it and user has to download it b) modify SDKs existing in apps (e.g. Ad SDKs) Also turning app/phone into a "BLE beacon" is only possible when app running in the foreground (on iOS).
  - dmitrygr 2y ago
    Please read the original source again. You need to KNOW (or guess) own mac address as it becomes a part of the key.
    - jimiasty 2y ago
      Yes, you are correct! Knowing the MAC makes the attack reasonable - let's say 5 hours compute for 3080Ti. Not knowing the MAC makes it exponentially harder. You can still "guess" it, but the search-space is vast and that would take bazillion-years. So to attack iOS device: - user has to download the app - app has to broadcast fake BLE - some other devices (e.g. Android/RasPi would need to pickup that MAC and pass it to you
- jeroenhd 2y ago
  Could the 256^3 presets not be pre-calculated? It's not like the intent for these keys is to make them private and secure, so reusing the same key material except for the MAC address itself shouldn't be a problem, should it? Also, 16777216 possibilities really aren't that many these days. With six cores at approximately 3.5GHz, assuming verification costs about 1000 instructions per key, brute-forcing every possibility will take between 4 and 5 seconds at most (half that on average). With appropriate rainbow tables, I think that should be feasible?
  - dmitrygr 2y ago
    The problem is not pre-calculation. The problem is that because you don’t know your MAC address, you need to broadcast all of those things, since you don’t know which one will be valid. Either at once or sequentially. Either way, iOS will not let you set up that much broadcasting.
gruez 2y ago
>It's a matter of time before advertising SDKs within any ad-supported apps will start leveraging this to geolocate users without additional permissions. They still need bluetooth permissions, which is going to be sus for your average flashlight/weather/game app. >Especially for apps that already have location permissions (something as simple as a weather app) this will hardly be noticed. If the app already has location permissions, why would they need to pull off this attack? They get the user's location directly.
- mschuster91 2y ago
  > They still need bluetooth permissions, which is going to be sus for your average flashlight/weather/game app. As if people would care about that...
- jeroenhd 2y ago
  > They still need bluetooth permissions, which is going to be sus for your average flashlight/weather/game app. Looking at the apps I had to purge from family members' phones, I don't think that will be a problem. > If the app already has location permissions, why would they need to pull off this attack? They get the user's location directly. Accessing geolocation APIs will show an indicator and add an entry to a log (at least on Android). I don't believe accessing BLE APIs do the same.

WatchDog 2y ago

Yeah - you need code execution on the victim device - you need internet connectivity - you need bluetooth permission - if the victim device has GPS itself, then this attack is pointless because you may as well just use that directly.

anigbrowl 2y ago

Not a problem at all depending on what your goal is.