Атака на UPLINK пакет Measurement Report
/* Статус материала - удалить перед прочтением. Совершенно секретно. ) */
Введение
Measurement Report - сообщение, передаваемое мобильным телефоном на частоте Uplink канала - в ответ на запросы базовой станции в SACCH канале. Сообщение содержит информацию о том, с каким уровнем абонентское устройство (телефон или модем) принимает базовую станцию, открывшую dedicated канал, а так же уровни сигналов "соседей" - БСок, которые присутствуют в neighbour list, передаваемом обслуживающей БС. Следует заметить что neighbour list может меняться, таким образом оператор может запрашивать у телефона измерения уровня сигнала любой из БС, но только в пределах своей сети, определяемой идентификатором PLMN - MCC/MNC. Данные отчеты необходимы инфраструктуре сети для регулирования мощности передатчиков, планирования handover'ов при перемещении абонентского устройства (MS) между LACами, и конечно же сливания информации в СОРМ для локализации абонента на местности. Такое же сообщение присутствует в более новых сетях поколениях 3G/4G, и там иногда даже присутствуют GPS координаты телефона.
Цель атаки: извлечь гамму генератора А5/1 для обращения регистров с линейной обратной связью в начальное состояние, соответствующее моменту окончания загрузки Kc и номера фрейма в регистры шифр.машины А5/1, для последующего извлечения ключа сессии (КС).
Характеристики сообщения
- Идентификатор сообщения - 0x15
- Телефон должен находится в режиме IDLE и при этом быть активен режим Dedicated Channel, т.е. БС должна производить обмен данными с абонентским устройством в целях установки режима ciphering mode или регистрации в сети.
- Сообщение передается телефоном в UPLINK канале SACCH каждые 480мсек.
- Сообщение передается по интерфейсу A-bis от BTS в контроллер BSC практически без изменений
- Сообщение передается как до, так и после включения режима шифрования
Так как мы знаем что сообщение передается каждые 480мсек, т.е. раз в 102 TDMA фрейма канала SDCCH - мы можем предсказывать номера Frame Number сообщения Measurement Report, просто прибавляя к известному plaintext сообщению номера 102, 204, 306 и так далее.
При помощи сниффера записываем непрерывно все Meas Report'ы до момента возникновения сообщения Ciphering Mode Command. Выделять их можем по идентификатору типа фрейма 0x15 . Нас интересует самый последний report перед включением шифрования командой C.M.Command. Выглядит он так:
Запишем номер GSM Frame Number = 347166, и зная что месседж передается с интервалом в 480мсек - вычислим номера фреймов после включения шифрования:
Код:
347166 + 102 = 347268
347166 + 204 = 347370
347166 + 306 = 347472Предположительно, это будут те же самые фреймы Meas Report, но уже шифрованные. Поэтому, после срабатывания шифрования - пишем эти номера фреймов.
Для примера, шифрованный фрейм MeasReport (после декодирования заранее известным ключем сессии) выглядит так:
Как видно, номер кадра - 347370, то есть предположение по поводу кратности номеров фреймов, числу 102 - работает.
К сожалению, фрейм после включения C.M. - несколько отличается от такого же plaintext, и мы не можем получить гамму выполнив операцию XOR между этими фреймами. Но...
Оптимизация атаки
0x01 В MeasReport телефон передает свою излучаемую мощность и режим управления мощности. Биты сообщения MS power Level (значение от 0 до 15, 15 - макс мощность), и режимы FPC (Fast Power Control). Нам нужно хорошо слышать телефон, поэтому заранее, аж до момента запроса идентификаторов imsi и imei - включаем ему принудительно FPC и передаем команду своей БСкой на запрос максимального уровня мощности (15). Таким образом мы убиваем 2 проблемы. 1 - получаем хороший уровень сигнала от телефона. 2- биты power level и fpc темерь нам точно известны.
Есть нюанс - телефон на режиме мощности 15 очень быстро высаживает батарею. Это следует учитывать. Обычно владелец телефона сам заботится о том чтобы держать свой "жучек" в работоспособном и заряженном состоянии. При атаках ночью - телефон как правило подключен к зарядному устройству, тоже не проблема. Но если владелец находится вдали от цивилизации - мы рискуем посадить батарею телефона, и лишиться возможности коннекта с ним.
0x02 Телефон передает измеренную дистанцию до базовой станции . Биты Actual Timing Advance. Но, со стороны базовой станции - есть возможность сформировать такой пакет измерения TA, что телефон будет думать что дистанция всегда равна TA=0 или TA=1. Т.е. мы уменьшили пространство вариантов с 255 бит до 2.
0x03 Телефон измеряет уровни сигналов только до тех станций, которые перечислены в списке neighbour list , передаваемом базовой станцией в сообщениях SIB5, SIB6. Если мы передаем пустой список соседей - то убиваем 2 проблемы. Первое - телефон не захочет соскакивать на другую базу с нашей, т.к. он теперь просто не знает про их существование. Второй положительный момент - последние 13 байт сообщения meas report теперь равны нулю (и это не 2b паддинги, т.е. телефон их не имеет право рандомизировать, тут именно чистый эталонный 0x00!!!) . А так же еще 3 бита стали известными - NO-NCELL-M приняли значение 0 0 0.
0x04 RXLEV-FULL-SERVING-CELL и SUB-SERVING-CELL. Тут все плохо. Это уровень сигнала с которым телефон слышит нашу БСку. Нужно обеспечить ему стабильный сигнал, и надеяться на то что за 480 миллисекунд этот уровень сигнала не поменяется больше чем на 3...5децибелл (требует уточнения, надо глянуть стандарт - какая там градация в этом сообщении). В общем, усилитель на 20-50вт, направленная антенна и почти всегда это сообщение не вызывает проблем. Полезно оценивать насколько скачет уровень сигнала используя предыдущие measreportы . Если сильно скачет, то нужно подойти к цели поближе или выкрутить мощность передатчиков на полную.
0х05 BER - процент ошибок в обмене с БСкой. Опять же, см. пункт 4- тут такие же принципы. Но, если мы не можем обеспечить хорошее качество сигнала для мобильного устройства, тут есть полезный прием - искажаем сигнал выдаваемый кодером Витерби, для сообщения C.M.Command таким образом чтобы BER стал максимальным - сообщение проходит со 2-3 попытки и теперь мы знаем что BER стал равен максимально возможному значению.
0x06 Гипотеза от //вырезано цензурой - интервал сообщения (102, 204 или 306) - можно померить перед включением шифрования непосредственно для того baseband процессора мобильного устройства, с которым в настоящий момент времени установлена связь. Данное значение следует использовать для предсказания где будет находиться следующий ciphertext фрейм, что в 3 раза уменьшает сложность атаки. Гипотеза требует проверки.
Другие возможности использования этого фрейма в целях причинения добра владельцу абонентского устройства
1. Манипулируя мощностью телефона, можно упрощать задачу пеленгации. Когда мы далеко от цели - используем максимальный уровень 15 (1вт мощности). По мере приближения к цели с локатором (переносное устройство, показывающее уровень сигнала и иногда направление на телефон цели) - уменьшаем мощность его передатчика, улучшая таким образом точность пеленгации.
2. Мы можем использовать 2..3 шт своих базовых станций с известным уровнем сигнала, разнеся их в пространстве и соединив в единую сеть на уровне BSC/A-bis (например по wifi). Отправляем ARFCNы этих БСок в SIB5 и таргет шлет нам их уровни сигнала в meas report'е. Таким образом, сидя на одном месте - мы можем наблюдать за передвижениями цели, анализируя изменения уровеня сигнала БСок которое оно принимает.
3. В целях анонимности - при использовании своего опенсорс телефона, мы можем формировать для оператора любой произвольный Meas.Report и заставлять оператора думать что мы находимся в другом месте (но не сильно далеко, т.к. БСки тоже имеют свойство анализировать уровень сигнала от телефона).
4. ГИПОТЕЗА от //null Возможно, если в список соседей добавить "чужую" вышку - например если sim-карта у цели - Мегафон, а ARFCN вышки в списке соседей принадлежит Билайну - ВОЗМОЖНО, телефон измерит ее уровень сигнала но при этом не сможет сделать реселект на нее т.к. имеет место быть "чужой" plmn. Если это так, то можно увеличить точность локализации абонента на местности - вышек много и их координаты известны. Надо проверять.
Самый простой метод извлечения гаммы из MeasReport
0b01 БСкой включаем телефону FPC, на 15 уровень мощности передатчика
0b10 Пишем 3 пары plaintext + ciphertext руководствуясь гипотезой "+102"
0b11 Примерно таким методом генерируем 16 возможных вариантов пакета
C:
//эта функция генерирует возможные ciphertext фреймы на основе
//последней plaintext строки (перед включением ciphering mode command) meas report
//тут мы перебираем варианты связанные с разным error rate
//(8шт и первым байтом в строке 0х05, 0х45 и т.д.)
//после этого КАЖДЫЙ из фреймов нужно будет разложить на
//бурсты и сделать xor каждого из бурстов с нужным plaintext бурстом
//так мы получим несколько десятков вариантов криптографической гаммы,
//которые можно будет передать в дешифратор
//возможно еще нужно посмотреть в сторону изменения уровня сигнала и т.п.
//обратите внимание что для наглядности процесса, каждый бит записан
//в отдельный элемент массива из char'ов.
static char guess_frame[16][23];
void gen_cipherframe(char *xp)
{
static unsigned char tmp_string[23]; //временная строка в которую копируем string_etalon[23];
//копируем данные в локальную временную переменную
char n=23;
while(n){
n--;
tmp_string[n]=xp[n];
}
//9 байт массива - это текущее значение байт еррор!
// байт еррор записывается ввиде .111 111.
//бит .......0 является частью байта в котором указаны есть ли соседи БСки!
static unsigned char error_byte[8] = {0b00000000,
0b00010010,
0b00100100,
0b00110110,
0b01001000,
0b01011010,
0b01101100,
0b01111110}; //варианты байт для значения BYTE ERROR RATE. Всего семь
n=8;
while(n)
{
n--;
memcpy(guess_frame[n],tmp_string,sizeof(char)*23); //скопировали образец в выходной массив
guess_frame[n][9]|=error_byte[n]; //поменяли 9 элемент на сгенерированный нами
guess_frame[n][0]=0b01001111;
}
n=8;
while(n)
{
n--;
memcpy(guess_frame[n+8],tmp_string,sizeof(char)*23); //скопировали образец в выходной массив
guess_frame[n+8][9]|=error_byte[n]; //поменяли 9 элемент на сгенерированный нами
guess_frame[n+8][0]=0b00001111;
}
}То есть, для каждого из meas report мы получаем 16 вариантов. Раскладываем их на BURSTы - получаем 4*16 = 64 вариант. А так как вариантов +102 у нас три, то всего на дешифратор отправляется 64*3 = 192 строки. Из этих строк нам нужно восстановить начальное состояние генератора шифра А5/1, что в итоге даст возможность определить ключ сессии, использованный для генерации гаммы.
Устройство для обращения функции А5/1, собранное на ПЛИС - решает эту задачу практически в масштабе реального времени. Но, про создание такого устройства - как нибудь в другой раз )
Вопросы - как обычно, в паблик, предложения по сотрудничеству - в личку
Литература
1. Спецификация GSM 05.08 version 8.5.0 Release 1999 . Раздел 8 -Radio Link Measurements, включая главу 8.4 .2. Документация фирмы Agilent (Keysight)
3. GSM Frame Structure