В коммуникационном стандарте LTE (4G), применяемом в современных сетях мобильной связи, выявлено (https://www.alter-attack.net/media/breaking_lte_on_layer_two... несколько уязвимостей, дающих возможность анализировать трафик абонента и манипулировать данными, отправляемыми на устройство пользователя. Исследователями разработано три варианта атаки на LTE. Две атаки проводятся в пассивном режиме и позволяют собирать метаданные о трафике, например, идентифицировать определённые виды трафика и определять какие сайты посещает пользователь.
Третья атака, представленная под кодовом именем aLTEr (https://alter-attack.net/), позволяет организовать отправку подставных ответов на устройство пользователя и может применяться, например, для перенаправления на вредоносные сайты путём замены IP-адреса DNS-сервера в DNS-пакетах. Атака требует физического присутствия поблизости от жертвы и основана на инициировании подключения устройства жертвы к фиктивной базовой станции, трафик с которой перенаправляется к настоящей базовой станции (MITM-атака, напоминающая IMSI-catcher (https://en.wikipedia.org/wiki/IMSI-catcher), но позволяющая не только прослушивать трафик, но и модифицировать пакеты).Возможность манипуляции трафиком вызвана недоработками в механизмах шифрования, применяемых на уровне данных LTE ("data layer"). В частности, данные в LTE шифруются с использованием алгоритма AES-CTR, работающего в режиме счётчика (https://ru.wikipedia.org/wiki/%D0%A0%D0%... но без применения средств для контроля целостности блоков. Отсутствие контроля целостности позволяет подменить шифротекст. Примечательно, что проблема частично затрагивает и ещё не принятый стандарт 5G, в котором введён дополнительный режим надёжного шифрования передаваемых данных с контролем целостности, но проблема в том, что данный режим не обязателен и предложен в виде опции.
Атаки могут быть проведены при нахождении в радиусе примерно километра от жертвы и требуют наличия специального SDR-оборудования (Software-Defined Radio), общей стоимостью примерно 4000 долларов, и применения модифицированного LTE-стека (https://github.com/srsLTE/srsLTE). В лабораторных условиях для демонстрации стабильной атаки в помещении использовались специальные экраны, которые помогали избавиться от шумов и добиться поддержания устойчивого подключения. По мнению исследователей для проведения атаки в реальных условиях потребуется разработка дополнительных инженерных решений.
Чтобы дать операторам связи и производителям оборудования время на устранение уязвимости (проблема заложена в спецификации LTE и её так просто не устранить), исследователями опубликована лишь общая концепция атак, а некоторые детали, необходимые для практической реализации, планируется опубликовать только в мае следующего года на конференции "IEEE Symposium on Security and Privacy 2019". Для защиты от подмены DNS-пакетов, продемонстрированной в практической реализации атаки на LTE, пользователям рекомендуется применять методы зашиты DNS-трафика, такие как DNS-SEC и DNS over TLS/HTTPS.
URL: https://arstechnica.com/information-technology/2018/06/lte-w.../
Новость: https://www.opennet.me/opennews/art.shtml?num=48883
Я всегда с собой беру Orbot. Удачи в анализе моего трафика.
ты так переживаешь, что кто-то увидит твоих котиков?
Молодец! Я тоже так делаю. И родственникам настроил.
А его настраивать нужно? Я включил режим VPN и всё завелось само.
Даже для старого доброго GSM с 64-битным шифрованием(у нас в стране 54-битное с известной солью) не нашли способа дешифровывать его рил-тайм. А тут про 4g сказки рассказывают.
> Даже для старого доброго GSM с 64-битным шифрованием(у нас в стране 54-битное
> с известной солью) не нашли способа дешифровывать его рил-тайм.Вариант что нашли, но не доложили об этом анониму, не рассматривается?
А зачем вам немедленно? Пара минут ничего не изменят. А это уже очень давно сделано.
> Даже для старого доброго GSM с 64-битным шифрованием(у нас в стране 54-битное
> с известной солью) не нашли способа дешифровывать его рил-тайм. А тут
> про 4g сказки рассказывают.Это не не нашли способ, а намеренно оставленная дыра ;) Впрочем, всё и так теперь сохраняется на серверах.
Впрочем, им Конституция вообще не указ.
"
Статья 23.
1. Каждый имеет право на неприкосновенность частной жизни, личную и семейную тайну, защиту своей чести и доброго имени.
2. Каждый имеет право на тайну переписки, телефонных переговоров, почтовых, телеграфных и иных сообщений. Ограничение этого права допускается только на основании судебного решения.
Статья 24.
1. Сбор, хранение, использование и распространение информации о частной жизни лица без его согласия не допускаются".
> Статья 23.
> 1. Каждый имеет право на неприкосновенность частной жизни, личную и семейную тайну,
> защиту своей чести и доброго имени.
> 2. Каждый имеет право на тайну переписки, телефонных переговоров, почтовых, телеграфных
> и иных сообщений. Ограничение этого права допускается только на основании судебного
> решения.Хранение трафика и (как показывает практика Гугля) и даже "машинная" обработка его этот пункт не нарушает.
> Статья 24.
> 1. Сбор, хранение, использование и распространение информации о частной жизни лица без
> его согласия не допускаются".А вот тут интересно. Потому как сбор и хранение происходят с одной стороны без согласия, с другой без судебного решения. А вот использование и распространение будут происходить на совершенно законных основаниях.
Теперь остаётся выяснить, является ли мешок с письмами и открытками на почте сбором и хранением информации о частной жизни лиц.
кто-то, похоже, неплохо башляет кому ни попадя за пропихивание вредных и ненужных "dns-over-https" идей.
Я даже не знаю что сказать. Принаться я шокирован подобным невежеством.
Тов. майор, перелогиньтесь!
вам же нечего скрывать.. не забивайте себе голову всякой глупостью
+1
Тут никто не думает что это мегакостыль и что через это избранные тов майоры будут всё знать.
Вот вообще никого не волнует что большинство IT сервисов сосредоточено в одной стране и она пока только смотрит, а скоро уже и отключать начнёт. (Крым уже отключило)
Да вооопче! Все все отрубят!! И тебя отрубят!!
>такие как DNS-SEC и DNS over TLS/HTTPS.хмм, а dnscrypt не?
Рискну вызвать гнев адептов DNSCrypt (хотя, это смешно, адепты софтины, лол), но DNSCrypt в сравнении с DoH, это как SPDY в сравнении с HTTP/2.То есть, он показал, в каком направлении надо двигаться, свою важную роль сыграл, став родителем стандарта. Но дальше уже рекомендуется использовать стандартизированный протокол.
Даже автор DNSCrypt с этим согласился, добавив поддержку DoH в DNSCrypt 2.
Ничего страшного в этом нет, все так же будут доступны сервера, поднятые энтузиастами и можно поднять свой. Просто время именно DNSCrypt уходит.
Гнева нет, но есть рекомендации посмотреть различия повнимательнее..
хотя бы на том же сайте dnscrypt
Что взамен?
Какой клиент будет шифровать?
На моём роутере - https-dns-proxy или unbound.
А при работе через сотовую сеть всё равно настоятельно рекомендуется завернуть трафик в VPN, поскольку опсосы уже вовсю вставляют в код страниц свои JS-скрипты.
Тут вопрос вот в чем, роутер здорово если он мобильный и есть возможность поставить туда все это хозяйство. У вас так?
Вопрос только зачем.
Для простого юзера и даже админа всё закончится на проверке TLS сертификата или SSH ключа сервера.
На сайтах без TLS и так ничего ценного нет.
Остаётся только обход примитивных блокировок на местах где днс запросы завёрнуты на свой днс сервер а IP адреса заблоченых хостов не фильтруются никак.
> На сайтах без TLS и так ничего ценного нет.Крепко. Напоминаю, что веб вторичен, а первичен всё же контент.
Сайтик с котиками или новостями не несёт ничего что стоит защищать используя TLS.
Даже если там платная подписка.
> даже если там платная подпискаНу да, что уж там, можно везде хеши-токенцы клиртекстом передавать, они же не несут никакой ценности.
На мой взгляд, конечно, даже ридонли сайт без авторизации нужно заворачивать в тлс, чтобы исключить всякую возможность анализа со стороны посредника
> DNS-SEC и DNS over TLS/HTTPSА как там с этим делом в Android?
В новом андроиде есть. Покупай новый смартфон.
> В новом андроиде есть. Покупай новый смартфон.Достаточно иметь смартфон с поддержкой treble, чтобы без проблем накатить новую версию Android. Хочешь чистый от васянов с xda, а хочешь - десятки кастомных прошивок а-ля Lineage.
А бывают не новые смартфоны с поддержкой treble?
Для старых девайсов есть Magisk с модулем DNSCrypt (возможно, кто-то соорудит и с поддержкой DoH).
Ну так dnscrypt-proxy умеет в DoH. В чем проблема?
Только смартфон не умеет root по умолчанию ))
Не покупайте вендорлоченную каку и будет Вам рут и прочее щастье.
Т.е. вот так вот все китайцы, сертифицированные ФСБ, имеют root?
Купи Pixel и перепрошей наконец.
В Firefox и Chromium уже есть DoH.
Что в новом андроиде есть?
Нужен root
Или dns over vpn - таких приложений в маркете вагон
Проверил, нормально все с этим в андроид.
>В частности, данные в LTE шифруются с использованием алгоритма AES-CTR, работающего в режиме счётчика, но без применения средств для контроля целостности блоков.ОМГ, детский сад. Я по такое шифрование у студента первого курса ревьювил, а тут целый стандарт написан студентами походу
Та же первая реакция. По нынешним временам шифровать без проверки целостности - это какая-то совершенно примитивная ошибка, о которую уже сотни раз бились
В следующий раз употребите слово "рецензировал".
Thanks, Qualcomm!
Мобильные девайсы: История о том, как мы клали и ложили.
нормальные такие себе заложенные изначально бекдоры.
> нормальные такие себе заложенные изначально бекдоры.Не стоит искать умысел фбр там, где достаточно тупости электриков с патентами. ©эрнест хемингуей
Не стоит искать глупость электриков - где касается контроля трафика в США :)
Помоем достаточно документов об этом.
На каждую уязвимость и ограничение найдётся свой способ шифрования.
Может быть найдется, а может быть и нет.
Обратно тоже актуально.
>основана на инициировании подключения устройства жертвы к фиктивной базовой станцииhaha, classic
>ещё не принятый стандарт 5GА китайцы рапортуют то что уже произвели тестирование и выкатывают в продакшен. WAT?
P.S. А смс-ки открытым текстом передаются, бида-бида...
А ты больше верь узкоглазым демонам.
Уязвимость выглядит как то не очень правдоподобно.В LTE на радиоканале и на участке между ENB и MME используется механизм Integrity protection, который осуществляется с применением сессионного ключа(который базируется на зашитом в симке базовом ключе), и кстати говоря довольно часто меняется, в случае если для осущствления вызова используется CSFB то после каждого звонка. В сообщениях передаваемых от MME на ENB и на UE есть 4х байтовое поле Message Authentication Code(MAC), которое является результатом выполнения механизма Integrity Protection. Принимающая сторона по заголовку сообщения(где указан MAC) и по телу сообщения сама высчитывает MAC с применением сессионного ключа, и если переданный MAC не совпадает c вычисленным, то сообщение просто игнорируется. Для актуализации значения поля MAC необходимо знать полный сессионный ключ. В новости речь идет о вычислении только части keystream, который генерируется из сессионного ключа + несколько статических блоков, и изменяемые параметры NAS sequence number и NAS overflow(не передается в сообщениях вабще, каждая сторона сама актуализирует). Соответствено даже если вычислить часть keystream и подменить кусок зашифрованных данных, то актуализировать MAC не получится без полного сессионного ключа и значений изменяемых частей keystream.
К тому же, алгоритм EEA2 не едиенсвенный, есть более старый EEA1 и более продвинутый но слабо обкатанный EEA3.
Больше похоже на проблемы в реализации конкретного вендора или проблемы в настройке конкретного оператора, а не на проблемы стандарта. Посмотрим что в марте выкатят.
Хотя наверно я погорячился, для User Plane действительно осуществлятеся только шифование, в отличие от Control Plane, где есть еще и Integrity Protection.
СМС, кстати говоря, ходят в Control Plane
> СМС, кстати говоря, ходят в Control PlaneЕсть варианты, SMS могут ходитьт и внутри SIP сообщений. Зависит от того что у себя оператор надеплоил. Но там SIP завернут в IPsec.
>> СМС, кстати говоря, ходят в Control Plane
> Есть варианты, SMS могут ходитьт и внутри SIP сообщений.До абонента-то?
Да, если абонент умеет IMS
Да и кстати, даже если шифрование делается через xor c keystream, как понять, что перед тобой вабще запрос к DNS серверу? Если только по размеру...
Более реалистичным выглядит вариант, где dst ip подменяется на адрес какогонибудь DPI, который оценивает что это за трафик и что с ним стоит сделать, в соответсвии с целями злого дяди с SDR. А точнее решает кем именно прикинуться для мобилы.
IP заголовок будет всегда, DST IP по известному смещению лежит. Остается только найти мобильные приложения, которые не чекают сертификаты, или каким либо образоим имеют возможность отключения проверки сертификатов и можно идти стрич аккаунты людей пачками.
У телефонистов как всегда: безопасность через неизвестность и кучу костылей.
Как только кто то с мозгами и своими инструментами влезает то там сразу становится видно дыры и бэкдоры.Давно бы признали что все их GSM, 3G, 4G, 5G просто фуфел в плане безопасности и перешли на IP стёк, с IPSec хотя бы, а весь L2 и всё что ниже предельно кастрировали, чтобы стал примерно как WiFi - просто транспорт без мозгов.
Ну и дальше SS7 нафик задепрекейтить, и юзають уже обычный SIP.Тут вот неплохая подборка (менее техническая): https://kiwibyrd.org/tag/%d1%82%d0%b5�.../
Защищенность обычного SIP тоже от идеала далека, и не совсем ясно, станет ли значительно лучше при использовании того, что сейчас принято называть secure sip.
Сейчас телефония внутри - полный треш: куча слоёв, куча не пойми чего.
Может на заре GSM вариантов и не было, но как минимум в 3G уже можно было сделать нормально.
Проводная телефония тоже уже много где по факту сип шлюз.
Так что SS7 и прочее скорее пережитки.Что до типа атаки - так не стоит считать что беспроводная связь чего то там защищает, в случае с WiFi ещё как то понятно что происходит при том же WPA2-PSK-AES, и работ исследовательских много, а тут проще считать что всё открыто и при необходимости гонять всё в туннеле с криптой.
Ага, так они и убрали заложенные дыры
Так я про то и говорю, что убрать всё вместе с дырами.
Говорят там лучше чем в WiFi сделан приём/передача в физике, временное разделение и тп, вот это оставить а дальше хоть эзернет с ip пустить и далее на привычных технологиях, которым есть доверие и понимание.
> Так я про то и говорю, что убрать всё вместе с дырами.
> Говорят там лучше чем в WiFi сделан приём/передача в физике, временное разделение
> и тп, вот это оставить а дальше хоть эзернет с ip
> пустить и далее на привычных технологиях, которым есть доверие и понимание.Внезапно, LTE - вполне себе IP сеть
В LTE SS7 уже нет ни в каком виде, в 3G используется Sigtran
SS7 это было не конкретно к LTE а ко всей телефонии в целом.
Эксплуатировать SS7 внутри лте было бы странно, его как снаружи оператора юзают.
Да и ваш любимый SIP в LTE таки используется во всю. Для менеджмента мобильности, аутентификации, управления каналами передачи данных используется S1AP поверх SCTP, а для звонков SIP, прямо от мобильной трубки, если конечно не используется CSFB.
>Да и ваш любимый SIP в LTE таки используется во всюОн стандартиизирован во всю. Но почти не используется - операторы не спешат переходитьна IMS. Может быть лет через пять.
Не спешат потому, что скорее всего еще СОРМ IMS удовлетворяющий всем требованиям не могут разработать/сдать в эксплуатацию
> Не спешат потому, что скорее всего еще СОРМ IMS удовлетворяющий всем требованиям
> не могут разработать/сдать в эксплуатациюЯ не про Россию - про весь мир.
>В частности, данные в LTE шифруются с использованием алгоритма >AES-CTR, работающего в режиме счётчика, но без применения средств для >контроля целостности блоков. Отсутствие контроля целостности позволяет >подменить шифротекст. В частности, в AES-CTR шифротекст формируется >путём применения операции XOR между ключевой последовательностью >keystream) и исходными данными.Это шутка такая что ли ????
>>В частности, данные в LTE шифруются с использованием алгоритма >AES-CTR, работающего в режиме счётчика, но без применения средств для >контроля целостности блоков. Отсутствие контроля целостности позволяет >подменить шифротекст. В частности, в AES-CTR шифротекст формируется >путём применения операции XOR между ключевой последовательностью >keystream) и исходными данными.
> Это шутка такая что ли ????А в чем проблема. Рсзмуеется малограмотный ОП забыл добавить что keystream для каждого пакета имеет свой собственный вектор инициализации.
Ну от описанного вектора атаки уникальность keystream не спасает. Суть в том, что если ты знаешь что конкретно в этом сообщении запрос к DNS, например по размеру, то выполнив XOR для четырех байт по смещению где DST IP лежит и известного адреса DNS, получишь значение 4х байт keystream, которые использовались для шифрования блока с DST IP, что дает возможность взять адрес подставного DNS, выполнить с ним XOR используя вычисленный кусок keystream, и вставить в сообщение. Такая схема прокатит так как в User Plane не используется Integrity Protection.
> Ну от описанного вектора атаки уникальность keystream не спасает. Суть в том,
> что если ты знаешь что конкретно в этом сообщении запрос к
> DNS, например по размеру, то выполнив XOR для четырех байт по
> смещению где DST IP лежит и известного адреса DNS, получишь значение
> 4х байт keystream, которые использовались для шифрования блока с DST IP,
> что дает возможность взять адрес подставного DNS, выполнить с ним XOR
> используя вычисленный кусок keystream, и вставить в сообщение. Такая схема прокатит
> так как в User Plane не используется Integrity Protection.Это если они смогут фейковую БСку сначала настроить правильно, я ниже уже писал - им надо угадывать конфигурацию. К тому-же эту атаку можно митигировать включив RoHC. Впрочем - никто и не почешется, ибо в реальных условиях неприменимо.
Бэкдор встроили, все как обычно.
Безопасность через неясность - все что можно сказать про современные мобильные сети. Сколько там еще дыр, которые втихую эксплуатируются или считаются операторами "несущественными" знают только эксплуататоры этих дыр и верхушки it отделов операторов.
> Безопасность через неясность - все что можно сказать про современные мобильные сети.
> Сколько там еще дыр, которые втихую эксплуатируются или считаются операторами "несущественными"
> знают только эксплуататоры этих дыр и верхушки it отделов операторов.Мля, ничего что все спецификации открыты - бери да читай.
Что толку от твоих спецификаций, ламер, если все оборудование у опсосов, а СВОЕ тебе поставить никто не даст, потому-то опсос должен перехватывать твой трындеж и трафик?
Лол, интересно а производители оборудования для опсосов - они по каким-то другим секретным спецификациям делают?
Фейковая базовая танция в LTE? Какой-то лютый 4.2
А чего, низя что ли?
Законы физики или математики это запрещают?На практике они скорее всего просто сделали ретранслятор, который мог выборочно изменять отдельные пакеты, остальное просто анализировал и отправлял дальше.
Им не требовалось в таком сценарии ломать крипту в лоб чтобы стать полноценной БС.Если что, наши глушилки GPS примерно так же и работают: принимают сигнал и ретранслируют с задержкой. Им пофик на крипту и прочее, главное что приёмник получает типа валидный сигнал но время там поехавшее из за задержки.
Им нужно в таком сценарии уметь читать назначенную БСкой конфигурацию радио линка. Которая шифрована и подписана. Я знаю openAir eNB - он не умеет нихрена, им там надо угдадать два параметра. В случае хоть-сколько-нибудь промышленной базовой станции - их больше десятка. При любом несовпадении - БСка выкинет такую мобилу из сети.ю
Не очень разбираюсь в RRC. Но почему не возможен такой вариант, где SDR ловит трубку и фиксирует все параметры радиоканала с которыми трубка ломилась в эфир, а затем использует зафиксированные ранее параметры для ретранслирования на ENB?
> Не очень разбираюсь в RRC. Но почему не возможен такой вариант, где
> SDR ловит трубку и фиксирует все параметры радиоканала с которыми трубка
> ломилась в эфир, а затем использует зафиксированные ранее параметры для ретранслирования
> на ENB?Нереально ИМХО - там хрен разберешь где какие сигналы и куда и когда их мобила должна класть.
А что, нельзя просто принять от трубки а потом передать дальше, и с ответом так же?
Чтобы принять сигнал от трубки надо знать где, когда и что она будет передавать. К тому-же рассинхрон на 1мс, и все, не примет ничего у тебя БС.
Норм тема) я вифи точку поднял публичную дома. Радиус на 150 метров. подключаются даже гoпники на соседних лавочках во дворе. с одной стороны шифрование, чтоб от провайдера чего не прилетело, с другой стороны лазейка для перехвата всего трафика, который проходит через мою точку, с автоматическим разграничением потоков и логированием ссылок. в основном ничего интересного, но иногда попадается такое... неговоря о том, скольков сего нового узнаешь о соседях!