• TL;DR:
  
  Кажется, VoLTE оказался защищён ещё хуже чем первые Wi-Fi клиенты с WEP. Исключительно архитектурный просчет, позволяющий немного поXOR'ить траффик и восстановить ключ. Атака возможна если находиться рядом со звонящим и тот часто делает звонки.
  
  
• Спасибо за наводку и TL;DR Klukonin
  
• Исследователи сделали приложение для определения, уязвим ли ваш оператор, подробнее тут. Поделитесь в комментариях результатами, в моём регионе на Мегафоне VoLTE отключён.
  

Об авторе

SPL
Давненько я не писал пост формата «атака недели», и это меня расстраивало. Не потому, что не было атак, а в основном потому, что не было атаки на что-то достаточно широко используемое, чтобы вывести меня из творческого кризиса.
Но сегодня я наткнулся на интересную атаку под названием ReVoLTE на протоколы, взлом которых меня особенно радует, а именно, протоколы сотовых сетей (voice over) LTE. Я в восторге от именно этих протоколов – и этой новой атаки – потому что очень редко можно наблюдать взлом реальных протоколов и реализаций сотовых сетей. В основном потому, что эти стандарты разработаны в прокуренных комнатах и оформлены в 12000-страничных документах, которые осилит не каждый исследователь. Более того, реализация этих атак заставляет исследователей использовать непростые радио-протоколы.
Таким образом, серьезные криптографические уязвимости могут распространиться по всему миру, и возможно будут использованы только правительствами, прежде чем какой-нибудь исследователь обратит на них внимание. Но время от времени бывают исключения, и сегодняшняя атака – одна из них.
Авторы атаки: Дэвид Руппрехт (David Rupprecht), Катарина Коулс (Katharina Kohls), Торстен Хольц (Thorsten Holz) и Кристина Пеппер (Christina Pöpper) из Рурского университета в Бохуме и Нью-Йоркского университета Абу-Даби. Это прекрасная атака на реинсталляцию ключа в голосовом протоколе, который вы, вероятно, уже используете (если предположить, что вы из старшего поколения, которое всё еще совершает телефонные звонки с помощью мобильного телефона).
Для начала – краткий исторический экскурс.
Что такое LTE и VoLTE?
Основа наших современных стандартов сотовой телефонии была заложена в Европе еще в 80-х годах стандартом Global System for Mobile (Глобальная система мобильной связи). GSM был первым основным стандартом цифровой сотовой телефонии, который ввёл ряд революционных функций, например, использование шифрования для защиты телефонных звонков. Ранний GSM был разработан в первую очередь для голосовой связи, хотя за деньги можно было передавать и другие данные.
По мере того, как в сотовой связи увеличивалась важность передачи данных, были разработаны стандарты Long Term Evolution (LTE) для рационализации этого типа связи. LTE основывается на группе более старых стандартов, таких как GSM, EDGE и HSPA и предназначен для повышения скорости обмена данными. В этой области есть много брендированности и введения в заблуждение неправильными обозначениями, но TL;DR заключается в том, что LTE – это система передачи данных, которая служит мостом между старыми протоколами пакетной передачи данных и будущими технологиями сотовой передачи данных 5G.
Разумеется, история говорит нам о том, что как только будет достаточно (IP) полосы пропускания, такие понятия, как «голос» и «данные» начнут размываться. То же самое относится и к современным сотовым протоколам. Чтобы сделать этот переход более плавным, стандарты LTE определяют Voice-over-LTE (VoLTE), который представляет собой IP-стандарт для передачи голосовых вызовов непосредственно через плоскость передачи данных системы LTE, полностью минуя коммутируемую часть сотовой сети. Как и в случае стандартных VoIP-звонков, VoLTE-звонки могут быть терминированы оператором сотовой связи и подключены к обычной телефонной сети. Или (что становится всё более распространенным явлением) они могут быть маршрутизированы непосредственно от одного сотового клиента к другому, и даже между разными провайдерами.
Как и стандартная VoIP, VoLTE основана на двух популярных протоколах на базе IP: протокол инициирования сеанса (Session Initiation Protocol – SIP) для установки вызова, и транспортный протокол в реальном времени (Real Time Transport Protocol, который должен называться RTTP, но на самом деле называется RTP) для обработки голосовых данных. VoLTE также добавляет некоторые дополнительные оптимизации пропускной способности, такие как сжатие заголовков.
Хорошо, какое отношение это имеет к шифрованию?
LTE, как и GSM, имеет стандартный набор криптографических протоколов для шифрования пакетов во время их передачи по воздуху. Они в основном предназначены для защиты ваших данных во время их перемещения между телефоном (называемым «оборудованием пользователя», или UE) и вышкой сотовой связи (или везде, где ваш провайдер решает терминировать соединение). Это происходит потому, что провайдеры сотовой связи рассматривают внешние устройства подслушивания как врагов. Ну разумеется.
(Однако тот факт, что соединения VoLTE могут происходить непосредственно между клиентами в различных сетях провайдеров, означает, что сам протокол VoLTE имеет некоторые дополнительные и необязательные протоколы шифрования, которые могут происходить на более высоких сетевых уровнях. Это не относится к текущей статье, за исключением того факта, что они могут всё испортить. Мы вкратце поговорим о них далее).
Исторически шифрование в GSM имело множество слабых мест: плохие шифры, протоколы, в которых только телефон аутентифицировался на вышке (это означает, что злоумышленник мог выдать себя за вышку, порождая «Stingray») и так далее. LTE исправил многие из очевидных ошибок, сохранив однако при этом большую часть прежней структуры.
Давайте начнём с самого шифрования. Если предположить, что создание ключа уже произошло — и мы поговорим об этом через минуту — то каждый пакет данных шифруется с помощью потокового режима шифрования с помощью некоего шифра под названием «EEA» (который на практике может быть реализован с помощью таких штук, как AES). По сути, здесь механизмом шифрования является CTR, как показано ниже:

Основной алгоритм шифрования пакетов VoLTE (источник: ReVoLTE). EEA – шифр, «COUNT» – 32-битный счётчик, «BEARER» — уникальный идентификатор сессии, разделяющий соединения VoLTE и обычный интернет-трафик. «DIRECTION» указывает, в каком направлении идёт трафик – от UE к вышке или наоборот.
Так как сам алгоритм шифрования (EEA) может быть реализован с использованием сильного шифра типа AES, то маловероятно, что будет какая-либо прямая атака на сам шифр, как это бывало во времена GSM. Однако, очевидно, что даже при сильном шифре эта схема шифрования представляет собой отличное средство выстрелить себе в ногу.
В частности: в стандарте LTE используется (неаутентифицированный) поточный шифр с режимом, который будет крайне уязвим, если счётчик — и другие входы, такие как «bearer» и «direction» — когда-либо будут использоваться повторно. В современном языке термин для этого понятия – «атака с повторным использованием nonce», но потенциальные риски тут не являются чем-то современным. Они известные и древние, восходящие ко временам глэм-метала и даже диско.

Атаки на переиспользование nonce в CTR-режиме существовали ещё тогда, когда Poison стали известны
Справедливости ради, в стандартах LTE сказано: «Не используйте эти счетчики повторно, ну пожалуйста». Но стандарты LTE занимают около 7000 страниц, и в любом случае, это все равно, что умолять малышей не играть с пистолетом. Они неизбежно это сделают, и произойдут ужасные вещи. В данном случае разряжающимся пистолетом является атака с повторным использованием потока ключа, в которой два разных конфиденциальных сообщения XOR-ят с одними и теми же байтами потока ключа. Известно, что это крайне разрушительно влияет на конфиденциальность сообщений.
Что же такое ReVoLTE?
Атака ReVoLTE демонстрирует, что на практике эта очень уязвимая конструкция шифрования неправильно используется реальным оборудованием. В частности, авторы анализируют реальные звонки VoLTE, сделанные с использованием коммерческого оборудования, и показывают, что они могут использовать нечто, называемое «атакой на переустановку ключа». (Большая заслуга в нахождении этой проблемы принадлежит Рейзе и Лу (Raza & Lu), которые первыми указали на потенциальную уязвимость. Но исследования ReVoLTE превращают её в практическую атаку).
Давайте я покажу вам вкратце суть атаки, хотя вам стоит посмотреть и исходный документ.
Можно предположить, что как только LTE устанавливает соединение пакетной передачи данных, задача передачи голоса по LTE становится лишь вопросом маршрутизации голосовых пакетов по этому соединению вместе со всем остальным вашим трафиком. Другими словами, VoLTE будет концепцией, которая существует только над 2 уровнем [модели OSI – прим пер.]. Это не совсем так.
Фактически, канальный уровень LTE вводит понятие «bearer». Bearer – это отдельные идентификаторы сеансов, которые разделяют различные виды пакетного трафика. Обычный интернет-трафик (ваш Twitter и Snapchat) проходит через один bearer. Сигнализация SIP для VoIP идет через другой, а пакеты голосового трафика обрабатываются на третьем. Я не очень хорошо разбираюсь в механизмах радиоканалов и сетевой маршрутизации LTE, но полагаю, что это сделано именно так, потому что сети LTE хотят обеспечить работу механизмов QoS (качества обслуживания), чтобы различные потоки пакетов обрабатывались с разными уровнями приоритета: т.е. ваши второсортные TCP соединения с Facebook могут иметь более низкий приоритет, чем ваши голосовые звонки в реальном времени.
Это в общем-то не проблема, но последствия этого следующие. Ключи для шифрования LTE создаются отдельно каждый раз при установке нового «bearer». В принципе, это должно происходить заново каждый раз, когда вы делаете новый телефонный звонок. Это приведёт к тому, что для каждого звонка будет использоваться разный ключ шифрования, что исключает возможность повторного использования одного и того же ключа для шифрования двух разных наборов пакетов голосовых вызовов. Действительно, стандарт LTE говорит что-то вроде «вы должны использовать разные ключи каждый раз, когда вы устанавливаете новый bearer для обработки нового телефонного звонка». Но это не значит, что так происходит на самом деле.
На самом деле, в реальных реализациях два разных вызова, происходящих в непосредственной временной близости, будут использовать один и тот же ключ — несмотря на то, что между ними настраиваются новые (одноимённые) bearer. Единственное практическое изменение, которое происходит между этими вызовами, заключается в том, что счётчик шифрования сбрасывается на ноль. В литературе такое иногда называют атакой на переустановку ключа. Можно утверждать, что, по сути, это ошибка реализации, хотя в этом случае риски, как кажется, в значительной степени вытекают из самого стандарта.
На практике эта атака приводит к повторному использованию потока ключа, где злоумышленник может получить зашифрованные пакеты $inline$C_1 = M_1 \oplus KS$inline$ и $inline$C_2 = M_2 \oplus KS$inline$, что позволяет вычислить $inline$C_1 \oplus C_2 = M_1 \oplus M_2$inline$. Ещё лучше, если злоумышленник знает одну из $inline$M_1$inline$ или $inline$M_2$inline$, то он может сразу же восстановить другую. Это дает ему сильный стимул узнать один из двух незашифрованных компонентов.
Это приводит нас к полному и наиболее эффективному сценарию атаки. Рассмотрим атакующего, который может перехватывать радиотрафик между целевым телефоном и сотовой вышкой, и которому каким-то хитрым образом «повезло» записать два разных звонка, где второй происходит сразу после первого. Теперь представьте себе, что он как-то может угадать нешифрованное содержание одного из звонков. При такой счастливой случайности наш злоумышленник может полностью расшифровать первый вызов, используя простой XOR между двумя наборами пакетов.
Разумеется, удача тут ни при чем. Поскольку телефоны предназначены для приёма звонков, злоумышленник, который может подслушать первый звонок, сможет инициировать и второй звонок именно в тот момент, когда закончится первый. Этот второй звонок, в случае повторного использования того же ключа шифрования со счётчиком, сброшенным на ноль, позволит восстановить нешифрованные данные. Более того, так как наш злоумышленник фактически контролирует данные во время второго вызова, он может восстановить содержимое первого вызова – благодаря множеству специфически реализованных мелочей, играющих на его стороне.
Вот изображение общего плана атаки, взятое из исходного документа:

Обзор атаки из документа ReVoLTE. Эта схема предполагает, что происходят два разных вызова с использованием одного и того же ключа. Атакующий контролирует пассивный снифер (вверху слева), а также второй телефон, с помощью которого он может совершить второй звонок на телефон жертвы.
Так атака и правда работает?
С одной стороны, это действительно главный вопрос для статьи о ReVoLTE. Теоретически все вышеперечисленные идеи великолепны, но оставляют массу вопросов. Такие как:

• Возможно ли (академическим исследователям) реально перехватить VoLTE-соединение?
  
• Действительно ли реальные LTE-системы переустанавливают ключи?
  
• Можете ли вы на самом деле инициировать второй звонок достаточно быстро и надёжно, чтобы телефон и вышка повторно использовали ключ?
  
• Даже если системы переустанавливают ключи, можете ли вы на самом деле узнать нешифрованное содержимое второго звонка – учитывая, что такие вещи, как кодеки и перекодировка могут полностью изменить (побитовое) содержимое этого второго звонка, даже если у вас есть доступ к «битам», исходящим из вашего атакующего телефона?

На некоторые из этих вопросов работа ReVoLTE отвечает утвердительно. Авторы используют коммерческий программно-реконфигурируемый сниффер радиопотока под названием Airscope для перехвата звонка VoLTE со стороны нисходящей линии. (Я думаю, что простое овладение ПО и примерное понимание того, как оно работает, отняло месяцы жизни у бедняг-аспирантов – что типично для подобных академических исследований).
Исследователи обнаружили, что для срабатывания повторного использования ключа второй звонок должен произойти достаточно быстро после завершения первого, но не слишком – примерно через десять секунд для операторов, с которыми они экспериментировали. К счастью, не имеет значения, ответит ли пользователь на звонок в течение этого времени – «звонок», т.е. сама SIP-связь заставляет оператора повторно использовать один и тот же ключ.
Таким образом, многие из самых паршивых проблем вращаются вокруг проблемы (4) – получение битов незашифрованного содержимого вызова, инициированного атакующим. Это происходит потому, что с вашим содержимым может много чего произойти по мере того, как он переходит от телефона злоумышленника к телефону жертвы через сотовую сеть. Например, такие пакости, как перекодирование закодированного звукового потока, которое оставляет звук прежним, но полностью изменяет его двоичное представление. В сетях LTE также используется сжатие заголовков RTP, которое может существенно изменить большую часть RTP-пакета.
Наконец, пакеты, отправленные злоумышленником, должны выстраиваться примерно в одну линию с пакетами, которые отправились во время первого телефонного звонка. Это может быть проблематично, так как модификация тишины во время телефонного звонка приводит к более коротким сообщениям (т.н. комфортный шум), которые могут плохо совмещаться с исходным звонком.
Раздел «real world attack» стоит прочитать во всех подробностях. В нем рассматриваются многие из вышеперечисленных проблем – в частности, авторы обнаружили, что некоторые кодеки не перекодированы, и что примерно 89% двоичного представления целевого вызова может быть восстановлено. Это актуально как минимум для двух европейских операторов, которые были протестированы.
Это удивительно высокий уровень успеха, и, откровенно говоря, намного более высокий, чем я ожидал, когда начинал работу над этим документом.
Так что мы можем предпринять для исправления?
Безотлагательный ответ на этот вопрос предельно прост: поскольку суть уязвимости в атаке на переиспользование (реинсталляцию) ключа, просто исправьте эту проблему. Убедитесь, что для каждого телефонного звонка получен новый ключ, и никогда не позволяйте счётчику пакетов сбрасывать счётчик обратно на ноль с помощью того же самого ключа. Проблема решена!
А может, и нет. Для этого потребуется модернизация большого количества оборудования, и, откровенно говоря, сам по себе такой фикс не супернадёжен. Было бы неплохо, если бы стандарты смогли найти более безопасный способ реализации своих режимов шифрования, который не является по умолчанию катастрофически уязвимым для подобных проблем переиспользования ключей.
Одним из возможных вариантов является использование режимов шифрования, при которых нецелевое использование nonce не приводит к катастрофическим последствиям. Это может быть слишком дорого для некоторых современных аппаратных средств, но это, безусловно, направление, о котором проектировщики должны думать в будущем, особенно учитывая то, что стандарты 5G вот-вот захватят мир.
Это новое исследование также поднимает общий вопрос того, почему одни и те же проклятые атаки продолжают возникать в одном стандарте за другим, многие из которых используют очень похожие конструкции и протоколы. Когда вы сталкиваетесь с проблемой реинсталляции одного и того же ключа в нескольких широко распространенных протоколах, таких как WPA2, вам не кажется, что, может быть, таки пришло время сделать ваши спецификации и процедуры тестирования более надёжными? Хватит уже относиться к реализаторам стандартов как к вдумчивым партнёрам, внимательным к вашим предупреждениям. Обращайтесь с ними как с (непреднамеренными) противниками, которые неизбежно собираются внедрить всё неправильно.
Ну или как вариант, мы можем сделать то, что всё чаще делают компании типа Facebook и Apple: сделать так, чтобы шифрование голосовых звонков происходило на более высоком уровне сетевого стека OSI, не полагаясь на производителей оборудования сотовой связи. Мы даже можем продвигать сквозное шифрование голосовых вызовов, как это делают WhatsApp с Signal и FaceTime, предполагая, что правительство США просто перестанет ставить нам подножки. Тогда (за исключением некоторых метаданных) многие из этих проблем попросту бы исчезли. Это решение особенно актуально в мире, где даже правительства не уверены, доверяют ли они своим поставщикам оборудования.
Или же мы можем просто делать то, что уже сделали наши дети: взять и перестать отвечать на эти надоедливые голосовые звонки.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Matthew Green
===========Похожие новости:

• [Информационная безопасность, Сетевые технологии, Сетевое оборудование] Как траблшутить отечественный IPsec VPN. Часть 1
  
• [Информационная безопасность] Безопасна ли ваша банковская карта с чипом? Зависит от банка (перевод)
  
• Атака ReVoLTE, позволяющая перехватить зашифрованные звонки в LTE
  
• [Информационная безопасность, Законодательство в IT, IT-компании] СКБ Контур помогает распространению коронавируса?
  
• [Сетевые технологии, Беспроводные технологии, Стандарты связи] Появились первые предварительные спецификации Wi-Fi 7
  
• [Беспроводные технологии, Разработка систем связи, IT-компании] Пользователи опубликовали первые измерения скорости работы системы Starlink
  
• [Информационная безопасность] ViPNet в деталях: разбираемся с особенностями криптошлюза
  
• [Информационная безопасность, Системное администрирование, Серверное администрирование, DevOps] Как незакрытый Docker API и публичные образы от сообщества используются для распространения майнеров криптовалют (перевод)
  
• [Информационная безопасность, Сетевые технологии, Сетевое оборудование] В Беларуси частично восстановили интернет, неполадки всё так же объясняют DDoS-атаками
  
• [Информационная безопасность, Исследования и прогнозы в IT, Статистика в IT] 3 самых интересных инцидента в области информационной безопасности за июль 2020

Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_besprovodnye_tehnologii (Беспроводные технологии), #_volte, #_revolte, #_lte, #_ujazvimost (уязвимость), #_informatsionnaja_bezopasnost (
Информационная безопасность
), #_besprovodnye_tehnologii (
Беспроводные технологии
)