The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

BlueBorne - опаснейшая удалённая уязвимость в Bluetooth-стек..., opennews (??), 12-Сен-17, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


99. "BlueBorne - опаснейшая удалённая уязвимость в Bluetooth-стек..."  +1 +/
Сообщение от zanswer CCNA RS and S (?), 13-Сен-17, 09:09 
Могу предположить, что речь вот об этом:

Bluetooth Specification Core Version 4.2

"9.2.2 Non-Discoverable Mode

9.2.2.1 Description

A device configured in non-discoverable mode will not be discovered by any
device that is performing either the general discovery procedure or the limited
discovery procedure.

9.2.2.2 Conditions

A device in the non-discoverable mode that sends advertising events shall not
set the ‘LE General Discoverable Mode’ flag or ‘LE Limited Discoverable Mode’
flag in the Flags AD type (see [Core Specification Supplement], Part A, Section
1.3). A Peripheral device in the non-connectable mode may send nonconnectable
undirected advertising events or scannable undirected advertising
events or may not send advertising packets."

"2.3.1.3 ADV_NONCONN_IND

The ADV_NONCONN_IND PDU has the Payload as shown in Figure 2.6. The
PDU shall be used in non-connectable undirected advertising events. The TxAdd
in the advertising channel PDU header indicates whether the advertiser’s
address in the AdvA field is public (TxAdd = 0) or random (TxAdd = 1).

The Payload field consists of AdvA and AdvData fields. The AdvA field shall
contain the advertiser’s public or random device address as indicated by
TxAdd. The AdvData field may contain Advertising Data from the advertiser’s
Host."

И так, слушая такие кадры можно узнать AdvA - данное поле может содержать два типа адреса:

"1.3 DEVICE ADDRESS

Devices are identified using a device address. Device addresses may be either
a public device address or a random device address. A public device address
and a random device address are both 48 bits in length.

A device shall use at least one type of device address and may contain both.
If a device is using Resolvable Private Addresses, it shall also have an Identity
Address that is either a Public Device Address or Random Static Device
Address type."

То есть, очевидно, что в ряде случаев устройство даже находясь в режиме предотвращающем его обнаружение, всё равно посылает кадры, которые содержат его адрес.

Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

102. "BlueBorne - опаснейшая удалённая уязвимость в Bluetooth-стек..."  +/
Сообщение от YetAnotherOnanym (ok), 13-Сен-17, 09:47 
> A device in the non-discoverable mode that sends advertising events

Хммм... прятаться и при этом махать флажком - какая интересная идеология у синезубых...

Ответить | Правка | Наверх | Cообщить модератору

104. "BlueBorne - опаснейшая удалённая уязвимость в Bluetooth-стек..."  +/
Сообщение от zanswer CCNA RS and S (?), 13-Сен-17, 09:52 
Данное поведение характерно и для 802.11, beacon frame отправляются всегда, даже когда активирован режим предотвращающий объявление SSID.
Ответить | Правка | Наверх | Cообщить модератору

152. "BlueBorne - опаснейшая удалённая уязвимость в Bluetooth-стек..."  +/
Сообщение от Аноним (-), 14-Сен-17, 02:15 
> Данное поведение характерно и для 802.11, beacon frame отправляются всегда, даже когда
> активирован режим предотвращающий объявление SSID.

У вафли есть ряд режимов где это не так. Они не очень массовые, но так можно.

Ответить | Правка | Наверх | Cообщить модератору

153. "BlueBorne - опаснейшая удалённая уязвимость в Bluetooth-стек..."  +/
Сообщение от zanswer CCNA RS and S (?), 14-Сен-17, 05:46 
Например, приведите для примера такой режим.
Ответить | Правка | Наверх | Cообщить модератору

171. "BlueBorne - опаснейшая удалённая уязвимость в Bluetooth-стек..."  +/
Сообщение от Аноним (-), 14-Сен-17, 22:52 
> Например, приведите для примера такой режим.

Monitor mode с packet injection. OCB вроде бы. Может и еще что.

Ответить | Правка | Наверх | Cообщить модератору

173. "BlueBorne - опаснейшая удалённая уязвимость в Bluetooth-стек..."  +/
Сообщение от zanswer CCNA RS and S (?), 15-Сен-17, 07:52 
Мне не удалось найти в спецификации IEEE 802.11-2016 monitor mode режима работы STA. Могу предположить, что он полностью или частично, может опираться на данный механизм.

IEEE Std 802.11™-2016 (Revision of IEEE Std 802.11-2012)

"4.3.11 Wireless LAN radio measurements

4.3.11.1 General

Wireless LAN (WLAN) radio measurements enable STAs to understand the radio environment in which they exist. WLAN radio measurements enable STAs to observe and gather data on radio link performance and on the radio environment. A STA can choose to make measurements locally, request a measurement from another STA, or be requested by another STA to make one or more measurements and return the results. Radio measurement data is made available to STA management and upper protocol layers where it might be used for a range of applications. The measurements enable adjustment of STA operation to better suit the radio environment. The radio measurement service includes measurements that extend the capability, reliability, and maintainability of WLANs by providing standard measurements across vendors, and the service provides the resulting measurement data to upper layers in the communications stack."

Но, тем не менее, как такового стандартизированного спецификацией режима STA, я не нашёл, можно предположить, что в данном не установленном спецификацией режиме работы STA является non-AP/non-PCP STA и может не отправлять Beacon frames, поскольку согласно спецификации:

"11.1.2 Basic approach

11.1.2.1 TSF for an infrastructure BSS or a PBSS

In an infrastructure BSS or in a PBSS, the AP in the infrastructure BSS or the PCP in the PBSS shall be the timing master for the TSF. In a non-DMG BSS, the AP shall periodically transmit frames called Beacon frames. In a DMG BSS, the AP or PCP shall periodically transmit frames called DMG Beacon frames and Announce frames, which provide a similar function to the Beacon frame in a non-DMG BSS. Beacon, DMG Beacon, and Announce frames contain the value of the AP’s or PCP’s TSF timer in order to synchronize the TSF timers of other STAs in a BSS. A receiving STA shall accept the timing information in Beacon, DMG Beacon, and Announce frames sent from the AP or PCP servicing its BSS. If a STA’s TSF timer is different from the timestamp in the received Beacon, DMG Beacon, or Announce frame, the receiving STA shall set
its local TSF timer to the received timestamp value."

Иными словами, если наш STA является non-AP и non-PCP, то отправлять Beacon frames он не обязан, кроме случая когда STA является участником IBSS. Что собственно говоря не противоречит сказанному мною ранее, что AP и PCP, всегда отправляют Beacon frames.

Что касается OCB, - STA transmission of Data frames outside the context of a BSS, то спецификация говорит следующее:

"4.3.16 STA transmission of Data frames outside the context of a BSS

In addition to defining procedures for STA communication within a BSS, this standard also defines procedures for a STA that is not a member of a BSS to transmit Data frames. Such Data frames are defined as being transmitted outside the context of a BSS (OCB). A STA transmits a Data frame outside the context of a BSS only if dot11OCBActivated is true.

...

When dot11OCBActivated is true, a sending STA sets the BSSID field to the wildcard BSSID value (see 9.2.4.3.4).

9.2.4.3.4 BSSID field

The BSSID field is a 48-bit field of the same format as an IEEE 802 MAC address. When
dot11OCBActivated is false, the value of this field uniquely identifies each BSS. The value of this field, in an infrastructure BSS, is the MAC address currently in use by the STA in the AP of the BSS.

...

The value of all 1s is used to indicate the wildcard BSSID. The wildcard value is not used in the BSSID field except where explicitly permitted in this standard. When dot11OCBActivated is true, the wildcard value is used in the BSSID field. When dot11OCBActivated is false and the BSSID field contains the wildcard value, the Address 1 (DA) field is also set to all 1s to indicate the broadcast address."

Я пропустил часть взяв главное, в случае OCB, BSSID поле не позволяет уникально идентифицировать STA в принципе. Относительно Beacon frames прямого указания я не нашёл, но согласен с вашей точкой зрения, что они не отправляются, исходя из общего смысла спецификации.

То есть относительно OCB вы правы, хотя должен заметить, что учитывая, что даже в Data frames поле содержит wildcard BSSID, а значит, даже если бы Beacon frames и отправлялись бы, это бы погоды не сделало, определить BSSID всё равно бы не удалось.

P/S/ Других режимов когда Beacon frames не отправляются я не нашёл, размер спецификации огромен, более 3 500 страниц, в любом случае наличие даже одного OCB режима делает ваше утверждение на 100% верным. :)

Ответить | Правка | Наверх | Cообщить модератору

106. "BlueBorne - опаснейшая удалённая уязвимость в Bluetooth-стек..."  +6 +/
Сообщение от Michael Shigorinemail (ok), 13-Сен-17, 10:08 
>> A device in the non-discoverable mode that sends advertising events
> Хммм... прятаться и при этом махать флажком - какая интересная идеология
> у синезубых...

Вспомнилась старая характеристика: "чёрный шнур надёжнее, чем красный глаз и синий зуб".

Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру