Позвони мне, позвони: прослушка звонков через баг в технологии VoLTE

Помните, в феврале мы уже писали про атаку на LTE и о том, что этот протокол не так уж и безопасен, как считалось ранее. С тех пор исследователи, стоящие за обнаружением уязвимостей в LTE опубликовали PoC код и видео с демонстрацией атаки.

Но на этом история не заканчивается.

Несколько дней назад те же специалисты из университета Рура рассказали о новой уязвимости в LTE, которую они назвали revoLTE.

Для начала – краткий исторический экскурс.

LTE и VoLTE

Основа для современных стандартов сотовой телефонии была заложена в 80-х годах с приходом Global System for Mobile (Глобальная система мобильной связи). GSM стал первым основным стандартом цифровой сотовой телефонии, который ввёл ряд передовых на то время функций, таких, как, использование шифрования для защиты телефонных звонков. GSM был разработан в первую очередь для голосовой связи, хотя позволял передавать и другие данные.

С увеличением важности передачи данных, были разработаны стандарты Long Term Evolution (LTE) для рационализации этого типа связи. LTE основывается на группе более старых стандартов, таких как GSM, EDGE и HSPA и предназначен для повышения скорости обмена данными. В этой области есть много брендированности и введения в заблуждение неправильными обозначениями, но смысл заключается в том, что 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) и антеной сотовой связи. Это происходит потому, что провайдеры сотовой связи рассматривают внешние устройства подслушивания как врагов.

Шифрование в GSM имело множество слабых мест: плохие шифры, протоколы, в которых только телефон аутентифицировался на вышке (это означает, что злоумышленник мог выдать себя за вышку, например, как в атаке Stingray) и так далее. LTE исправил многие из очевидных ошибок, сохранив однако при этом большую часть прежней структуры.

Начнём с самого шифрования. Если предположить, что создание ключа уже произошло — и мы поговорим об этом через минуту — то каждый пакет данных шифруется с помощью потокового режима шифрования с помощью некоего шифра под названием «EEA» (который на практике может быть реализован с помощью таких штук, как AES). По сути, здесь механизмом шифрования является CTR, как показано ниже:

Основной алгоритм шифрования пакетов VoLTE (источник: ReVoLTE). EEA – шифр, «COUNT» – 32-битный счётчик, «BEARER» — уникальный идентификатор сессии, разделяющий соединения VoLTE и обычный интернет-трафик. «DIRECTION» указывает, в каком направлении идёт трафик – от UE к вышке или наоборот.

Так как сам алгоритм шифрования (EEA) может быть реализован с использованием сильного шифра типа AES, то маловероятно, что будет какая-либо прямая атака на сам шифр, как это бывало во времена GSM. Однако, очевидно, что даже при сильном шифре эта схема шифрования представляет собой отличное средство выстрелить себе в ногу.

В LTE используется (неаутентифицированный) поточный шифр с режимом, который будет крайне уязвим, если счётчик — и другие входы, такие как «bearer» и «direction» — когда-либо будут использоваться повторно. В современном языке термин для этого понятия – «атака с повторным использованием nonce», но потенциальные риски тут не являются чем-то современным. Они известные и древние, восходящие ко временам глэм-метала и даже диско.

Справедливости ради, в стандартах LTE сказано: «Не используйте эти счетчики повторно, ну пожалуйста». Но стандарты LTE занимают около 7000 страниц, и в любом случае, это все равно, что умолять малышей не играть с пистолетом. Они неизбежно это сделают, и произойдут ужасные вещи. В данном случае разряжающимся пистолетом является атака с повторным использованием потока ключа, в которой два разных конфиденциальных сообщения XOR-ят с одними и теми же байтами потока ключа. Известно, что это крайне разрушительно влияет на конфиденциальность сообщений.

Что же такое ReVoLTE?

Атака ReVoLTE демонстрирует, что на практике эта очень уязвимая конструкция шифрования неправильно используется реальным оборудованием. В частности, авторы анализируют реальные звонки VoLTE, сделанные с использованием коммерческого оборудования, и показывают, что они могут использовать нечто, называемое «атакой на переустановку ключа». (Большая заслуга в нахождении этой проблемы принадлежит Рейзе и Лу (Raza & Lu), которые первыми указали на потенциальную уязвимость. Но исследования ReVoLTE превращают её в практическую атаку).

Давайте я покажу вам вкратце суть атаки, хотя вам стоит посмотреть и исходный документ.

Можно предположить, что как только LTE устанавливает соединение пакетной передачи данных, задача передачи голоса по LTE становится лишь вопросом маршрутизации голосовых пакетов по этому соединению вместе со всем остальным вашим трафиком. Другими словами, VoLTE будет концепцией, которая существует только над 2 уровнем. Это не совсем так.

Фактически, канальный уровень LTE вводит понятие «bearer». Bearer – это отдельные идентификаторы сеансов, которые разделяют различные виды пакетного трафика. Обычный интернет-трафик (ваш Twitter и Snapchat) проходит через один bearer. Сигнализация SIP для VoIP идет через другой, а пакеты голосового трафика обрабатываются на третьем. Я не очень хорошо разбираюсь в механизмах радиоканалов и сетевой маршрутизации LTE, но полагаю, что это сделано именно так, потому что сети LTE хотят обеспечить работу механизмов QoS (качества обслуживания), чтобы различные потоки пакетов обрабатывались с разными уровнями приоритета: т.е. ваши второсортные TCP соединения с Facebook могут иметь более низкий приоритет, чем ваши голосовые звонки в реальном времени.

Это в общем-то не проблема, но последствия этого следующие. Ключи для шифрования LTE создаются отдельно каждый раз при установке нового «bearer». В принципе, это должно происходить заново каждый раз, когда вы делаете новый телефонный звонок. Это приведёт к тому, что для каждого звонка будет использоваться разный ключ шифрования, что исключает возможность повторного использования одного и того же ключа для шифрования двух разных наборов пакетов голосовых вызовов. Действительно, стандарт LTE говорит что-то вроде «вы должны использовать разные ключи каждый раз, когда вы устанавливаете новый bearer для обработки нового телефонного звонка». Но это не значит, что так происходит на самом деле.

На самом деле, в реальных реализациях два разных вызова, происходящих в непосредственной временной близости, будут использовать один и тот же ключ — несмотря на то, что между ними настраиваются новые (одноимённые) bearer. Единственное практическое изменение, которое происходит между этими вызовами, заключается в том, что счётчик шифрования сбрасывается на ноль. В литературе такое иногда называют атакой на переустановку ключа. Можно утверждать, что, по сути, это ошибка реализации, хотя в этом случае риски, как кажется, в значительной степени вытекают из самого стандарта.

На практике эта атака приводит к повторному использованию потока ключа, где злоумышленник может получить зашифрованные пакеты C1=M1⊕KS и C2=M2⊕KS, что позволяет вычислить C1⊕C2=M1⊕M2. Ещё лучше, если злоумышленник знает одну из M1 или M2, то он может сразу же восстановить другую. Это дает ему сильный стимул узнать один из двух незашифрованных компонентов.

Это приводит нас к полному и наиболее эффективному сценарию атаки. Рассмотрим атакующего, который может перехватывать радиотрафик между целевым телефоном и сотовой вышкой, и которому каким-то хитрым образом «повезло» записать два разных звонка, где второй происходит сразу после первого. Теперь представьте себе, что он как-то может угадать нешифрованное содержание одного из звонков. При такой счастливой случайности наш злоумышленник может полностью расшифровать первый вызов, используя простой XOR между двумя наборами пакетов.

Разумеется, удача тут ни при чем. Поскольку телефоны предназначены для приёма звонков, злоумышленник, который может подслушать первый звонок, сможет инициировать и второй звонок именно в тот момент, когда закончится первый. Этот второй звонок, в случае повторного использования того же ключа шифрования со счётчиком, сброшенным на ноль, позволит восстановить нешифрованные данные. Более того, так как наш злоумышленник фактически контролирует данные во время второго вызова, он может восстановить содержимое первого вызова – благодаря множеству специфически реализованных мелочей, играющих на его стороне.

Вот изображение общего плана атаки, взятое из исходного документа:

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

Так атака и правда работает?

С одной стороны, это действительно главный вопрос для статьи о ReVoLTE. Теоретически все вышеперечисленные идеи великолепны, но оставляют массу вопросов. Такие как:

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

На некоторые из этих вопросов работа ReVoLTE отвечает утвердительно. Авторы используют коммерческий программно-реконфигурируемый сниффер радиопотока под названием Airscope для перехвата звонка VoLTE со стороны нисходящей линии. (Я думаю, что простое овладение ПО и примерное понимание того, как оно работает, отняло месяцы жизни у бедняг-аспирантов – что типично для подобных академических исследований).

Исследователи обнаружили, что для срабатывания повторного использования ключа второй звонок должен произойти достаточно быстро после завершения первого, но не слишком – примерно через десять секунд для операторов, с которыми они экспериментировали. К счастью, не имеет значения, ответит ли пользователь на звонок в течение этого времени – «звонок», т.е. сама SIP-связь заставляет оператора повторно использовать один и тот же ключ.

Таким образом, многие из самых паршивых проблем вращаются вокруг проблемы (4) – получение битов незашифрованного содержимого вызова, инициированного атакующим. Это происходит потому, что с вашим содержимым может много чего произойти по мере того, как он переходит от телефона злоумышленника к телефону жертвы через сотовую сеть. Например, перекодирование закодированного звукового потока, которое оставляет звук прежним, но полностью изменяет его двоичное представление. В сетях LTE также используется сжатие заголовков RTP, которое может существенно изменить большую часть RTP-пакета.

Наконец, пакеты, отправленные злоумышленником, должны выстраиваться примерно в одну линию с пакетами, которые отправились во время первого телефонного звонка. Это может быть проблематично, так как модификация тишины во время телефонного звонка приводит к более коротким сообщениям (т.н. комфортный шум), которые могут плохо совмещаться с исходным звонком.

Раздел «real world attack» стоит прочитать во всех подробностях. В нем рассматриваются многие из вышеперечисленных проблем – в частности, авторы обнаружили, что некоторые кодеки не перекодированы, и что примерно 89% двоичного представления целевого вызова может быть восстановлено. Это актуально как минимум для двух европейских операторов, которые были протестированы.

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

Также авторы опубликовали видео с демонстрацией:

Так что мы можем предпринять для исправления?

Безотлагательный ответ на этот вопрос предельно прост: поскольку суть уязвимости в атаке на переиспользование (реинсталляцию) ключа, просто исправьте эту проблему. Убедитесь, что для каждого телефонного звонка получен новый ключ, и никогда не позволяйте счётчику пакетов сбрасывать счётчик обратно на ноль с помощью того же самого ключа. Проблема решена!

А может, и нет. Для этого потребуется модернизация большого количества оборудования, и, откровенно говоря, сам по себе такой фикс не супернадёжен. Было бы неплохо, если бы стандарты смогли найти более безопасный способ реализации своих режимов шифрования, который не является по умолчанию катастрофически уязвимым для подобных проблем переиспользования ключей.

Одним из возможных вариантов является использование режимов шифрования, при которых нецелевое использование nonce не приводит к катастрофическим последствиям. Это может быть слишком дорого для некоторых современных аппаратных средств, но это, безусловно, направление, о котором проектировщики должны думать в будущем, особенно учитывая то, что стандарты 5G вот-вот захватят мир.

Это новое исследование также поднимает общий вопрос того, почему одни и те же проклятые атаки продолжают возникать в одном стандарте за другим, многие из которых используют очень похожие конструкции и протоколы. Когда вы сталкиваетесь с проблемой реинсталляции одного и того же ключа в нескольких широко распространенных протоколах, таких как WPA2, вам не кажется, что, может быть, таки пришло время сделать ваши спецификации и процедуры тестирования более надёжными? Хватит уже относиться к реализаторам стандартов как к вдумчивым партнёрам, внимательным к вашим предупреждениям. Обращайтесь с ними как с (непреднамеренными) противниками, которые неизбежно собираются внедрить всё неправильно.

Ну или как вариант, мы можем сделать то, что всё чаще делают компании типа Facebook и Apple: сделать так, чтобы шифрование голосовых звонков происходило на более высоком уровне сетевого стека OSI, не полагаясь на производителей оборудования сотовой связи. Мы даже можем продвигать сквозное шифрование голосовых вызовов, как это делают WhatsApp с Signal и FaceTime, предполагая, что правительство США просто перестанет ставить нам подножки. Тогда (за исключением некоторых метаданных) многие из этих проблем попросту бы исчезли. Это решение особенно актуально в мире, где даже правительства не уверены, доверяют ли они своим поставщикам оборудования.

Или же мы можем просто делать то, что уже делает новое поколение: взять и перестать отвечать на эти надоедливые голосовые звонки.