0•Bytes•1

Now let's discuss the attack "on this and that"

In this attack, the adversary must be in the range of the victim and know in advance the IMSI of the victim, which can be obtained through the IMSI catcher. 

The adversary sends the connection request packets with the IMSI of the victim to the MME via SDR (which is by the way quite cheap, about 300 USD).

To make the victim's UE initiate the switch between VoWiFi and VoLTE, the adversary can use a deauthentication attack to break the WiFi connection.

Our SDR device continues to send a request to join the MME.
When we run the handover procedure on the affected UE, we find that the connection between the UE and the main network is terminated.
The UE does not receive the IKE Delete payload, which is the final message from the core network when the transfer is complete.

When running a handover, the specification expects the handover to be seamless to the user
Using this attack, the adversary can stop the seamless transition from VoWiFi to VoLTE, significantly reducing cellular resilience.
After attacking for about two seconds, the victim reaches a state where the UE disconnects from the main network through both VoWiFi and VoLTE.

The victim can then connect to VoLTE. However, the attack can be run in a loop to keep the UE in a destructive handover state where it cannot connect to the main network.

I think that would be enough
If you want more details you can check the archive below and read lots of cool articles about Wifi Calling and VoLTE, how to practice attacks on them and how to improve their security🔥 .

In the future I can make articles about forensics and mobile networks, simple about phones, thinking of a malicious user and so on. Just now the admin has a lot to do and he does not have time "all at once" 🥲

That's all, thanks for reading. ❤️
Don't forget walking through Wonderland that the Cheshire cat is smiling even when you can't see him🐈🧩
#wifi #lte #mobile #network #traffic_analysis #dos #attacks

WiCA traffic analyzer, which analyzes the identification of the application and information about the device.

Then there's the

UCIA it identifies each phone user's call statistics based on the surveillance camera, using facial recognition and human motion detection techniques. CS-IP2U uses call statistics from WiCA and UCIA to map each phone user to an IP address.
It generates a mapping table with the IP address and user ID as well as each user's call statistics. 

For more on this and on Wifi calls in general, you can look at the article archive below✨.

Now let's talk about VoLTE attacks

Attack on tracking location information of VoLTE phones

To track the location information of VoLTE phones, the attacker first scans the S-CSCF to find the S-CSCF where the VoLTE phone is registered. The attacker then obtains the VoLTE phone's IP address from the S-CSCF.
Finally, the attacker gets the location information of the target VoLTE phone. 

When the VoLTE feature on the VoLTE phone is enabled, the IMS registration process is initiated. At this time, the I-CSCF searches the HSS to identify the S-CSCF and assign it to the VoLTE phone.
The VoLTE phone, the attacker can confirm the S-CSCF IP address assigned to its phone in the "SIP 200 OK" packet during the VoLTE registration process and use it to determine the S-CSCF IP address range. S-CSCF IP address in the "SIP 200 OK" package during the VoLTE registration process
The SIP REFER message can be used to scan the S-CSCF IP address range and analyze reply packets to confirm the S-CSCF IP address where the target VoLTE phone is registered. The attacker sends SIP REFER packets to the P-CSCF, resulting in the From (caller's MSISDN) and P-Preferred-Identity fields being changed to the VoLTE phone's MSISDN(800), the To (caller's MSISDN) and ReferTo fields to the attacker's MSISDN(203), and the Route field to the S-CSCF IP address then P-CSCF receives packets, sent by the attacker and forwards them to the IP address specified in the Route field It then sends the SIP REFER packets to the P-CSCF, resulting in the From (caller MSISDN) and P-Preferred-Identity fields being changed to the target VoLTE phone MSISDN(800) and the To (caller MSISDN) field and the Route field being changed to the S-CSCF IP address .
The P-CSCF then receives the packets sent by the attacker and forwards them to the IP address in the Route field , the attacker receives three types of response packets: error 500 , error 403 , REFER
REFER indicates precisely that the server sending the reply packet is an S-CSCF, where the VoLTE target phone is registered
In this case, since the destination IP address of the scan traffic sent by the attacker is IP P-CSCF, the source IP of the reply packet is also IP P-CSCF.

In other words, the attacker cannot validate the S-CSCF IP on which the target VoLTE is registered with the reply packet source IP. The attacker can validate the S-CSCF IP address on which the target VoLTE phone , by the tag value in the field in the REFER packet . 

The SIP SUBSCRIBE message calls the CSCF for VoLTE phone status information.

In response, the CSCF sends a SIP NOTIFY message containing the current registration data, such as the IP address for the SUBSCRIBE, which is what the attacker needs ! 

After receiving the packets sent by the attacker, the P-CSCF forwards them to the S-CSCF IP address in the Route field, while the S-CSCF sends 200 OK and NOTIFY(which is what it needs) to the attacker in response.
#wifi #lte #mobile #network #traffic_analysis #dos #attacks

Let's talk in more detail about the attacks themselves.⚙️

Preface - then there will be tech details
The VoWiFi attack story will be about a WiFi-based IMSI hijacker that uses an unauthorized WiFi access point to get the personal data of nearby users.
THDoS attacks, which can cause voice service denial for Wi-Fi calling users. Also about Dos attacks and many other vulnerabilities .

About VoLTE attacks we will break down the attacks which mainly involve free data channel, DoS and side channel attacks on IMS etc . The first is to create a free data channel by sending every packet that is forwarded from the 4G gateway directly to the Internet .
Here are some examples of attacks.

Let's start with Wi-Fi Calling.

Let's start by talking about THDOS .
In order to drop certain packets between a device and the network infrastructure, the adversary needs to identify the IPSec encrypted packets. Example: A device user receives an incoming Wi-Fi call, and answers it about 6 seconds after the call, the user has been engaged in a voice conversation for about 12 seconds. What happened during this time? Well what does the user see: 1 receiving the call; 2 answering the call; 3 talking; 4 hanging up. What we see:

1: The first incoming packet, which is intercepted at second 2, is a 1360-byte IPSec packet. We decrypt it on the subscriber side and identify it as a SIP INVITE message, indicating a call attempt. On the 2nd second, the subscriber sends a 180 RING message to the Wi-Fi call server. We then observe that several small IPSec packets as small as 176 bytes are received, but the recipient does not send any packets back.

1 : We detect that these are voice packets in the RTP protocol
2 : The caller answers the call at 8 seconds by sending a 200 OK message to the server, and then receives an acknowledgement at 9 seconds. After that the conversation starts and the subscriber starts to send/receive voice packets.
3: During the call, the subscriber continues to send/receive voice packets to/from the calling Wi-Fi server, but no SIP messages are observed. We further find that the caller receives at least 10 voice packets every two seconds from the server.
4: The caller sends a BYE message at the 20th second after the call was placed on the handset. Incoming packets of the "answering the call" event on the Wi-Fi . No more IPSec packets are observed after the 20th second . Note that if the caller hangs up first, the server must send a BYE message.

Now the attack example itself:
The caller receives several incoming calls from the caller.
There are two approaches. First, the adversary delivers a 183 message about the progress of the session sent by the caller, and then the caller's Wi-Fi device initiates another VoLTE call towards the caller. Second, the attacker delivers a message 180 message , sent by the caller, and then it causes the caller's Wi-Fi device to get stuck on the dial screen. The caller doesn't hear any notification tone, but the caller's device rings and the caller can continue dialing.

Sounds boring - I agree . For that reason, I'll give you an example
Disclosure Attack

WiCA was designed , to determine the call statistics of a Wi-Fi user, including who initiated the call and who hung up first, as well as the time of the call and the conversation. 

Call statistics are widely used to determine a user's personal information including personality, mood (e.g., stressed out), malicious behavior (e.g., dialing spam calls), and so forth. WiCA intercepts from Wi-Fi call packets WiCA extracts call statistics (such as call time and call duration) for each IP address of the device. The remaining packets are sent to a real-time traffic analyzer.
#wifi #lte #mobile #network #traffic_analysis #dos #attacks

Now about Wi-Fi Calling Services 📡

Wi-Fi calling technology, also known as VoWiFi, is supported by 3GPP IMS .

It provides mobile users with cellular calls and text messages over Wi-Fi instead of cellular base stations. It is an alternative voice solution for mobile users who connect to base stations with weak signals.

Wi-Fi calls use the SIP protocol for signaling a call just like regular VoIP services, but differs from them technically. 

Its SIP signaling operation is a 3GPP-specific version. 

For security reasons, both 3GPP and GSMA stipulate that Wi-Fi calls have to use well-established SIM-based security and authentication methods, as in familiar VoLTE.

They basically include secret key protection in the physical SIM card and 3GPP AKA . In addition, all Wi-Fi call packets that can be sent over unsecured networks must be delivered over IPSec channels using ESP tunnel mode between the Wi-Fi call devices and the cellular network . 

Even though the packets are protected by IPSec tunnels, Wi-Fi calling service can still suffer
First, 3GPP WLAN selection mechanisms do not prevent devices from connecting to insecure Wi-Fi networks, which can hamper Wi-Fi calling service. Second, Wi-Fi call traffic, which is protected by IPSec, is vulnerable to side-channel attacks , which can lead to leakage of sensitive information. Third, the service continuity mechanism between Wi-Fi calling and cellular-based voice services may not take effect
Two IETF protocols, IKEv2 and IPSec, are used to maintain and enhance security in Wi-Fi calling.

Although... this network can still successfully exchange spoofed and manipulated packets with the sender and receiver without any identity verification process.
By creating an unauthorized access point equipped with an IPSec server on Wi-Fi networks, user devices can transmit IMSI, which can lead to privacy issues such as location tracking . Moreover, these protocols can be vulnerable to multiple DoS attacks.
#wifi #lte #mobile #network #traffic_analysis #dos #attacks

Good afternoon my bunnies 🐰

Welcome to the wonderland so to speak. The admin wanted to touch mobile communications again
This time VoLTE and VoWiFi, or rather in this post I want to touch on VoLTE and Wi-Fi Calling , and attacks on them.
In their structure these two services are similar. But let us in order, the post will be divided into 5 parts because it is long. As well as an archive of detailed material on this topic will be below.

Let's start with VoLTE..📞

Roughly speaking VoLTE is a voice-over-IP scheme for PS.
But only PS based entirely on LTE . It does away with CS- the traditional solution for calls on 2G/3G networks. Voice messages are transmitted in ip packets on the data plane, not on a dedicated circuit. To facilitate voice communications, each VoLTE each call supports a separate signaling session.
VoLTE offers obvious advantages over traditional 2G/3G including improved quality (e.g., high definition calls), more features (e.g., video calls, voicemail) , and better compatibility (e.g., in mobile networks, wifi).
As VoLTE changes its design paradigm from CS to PS, we are interested in the question of whether such a significant change could be detrimental to the LTE network as well as to the users.

VoLTE uses the architectural structure of IMS

IMS provides ubiquitous media access using a common ip interface. Another important aspect is VoLTE support for UEs that are roaming.
There are two competing technologies for providing VoLTE roaming, namely LBO and S8HR.



The VoLTE architecture is based on 3GPP architecture and principles for VoLTE UE, LTE, EPC and IMS Core Network

It consists of the following features:
VoLTE UE contains functionality to access LTE RAN and EPC to enable mobile broadband connectivity. Access to VoLTE services requires an embedded IMS stack and a VoLTE IMS application;
E-UTRAN radio access network : LTE radio capabilities for FDD LTE, TDD LTE or for FDD and TDD LTE apply to VoLTE as well;
Enhanced packet core : EPC ;
The underlying IMS network in the VoLTE architecture provides the service layer of providing multimedia telephony;
I think the basic structure is clear to you. For more details about the architecture see the articles in the archive below (as well as more details about attacks🙃 )

VoLTE can interfere with other system components, thus creating new loopholes for attackers on the general network . 
PS-based operations for voice and data can enable data transmission over VoLTE . 

Moreover, because ip forwarding is readily available to the mobile OS, VoLTE extends access to CS within the device chipset to more open access to PS in the software.
This likely negates existing security mechanisms and security features for traditional voice transmission.
Finally, unlike conventional data services, VoLTE has a higher priority in resource allocation to ensure better quality. As you understand this can inadvertently serve as a side channel for leaking critical information.
In the absence of VoLTE control packet billing, exploitation leads to malicious data access.

Such "service" is available for both Mobile-to-Internet and Mobile-to-Mobile communications.
VoLTE sessions are not encrypted end-to-end by default, hence it is easy to eavesdrop on the connection, especially from the MNO side.
#wifi #lte #mobile #network #traffic_analysis #dos #attacks

Теперь обсудим атаки "на то и то "

В этой атаке противнику необходимо находиться в радиодиапазоне радиусе действия жертвы и заранее знать IMSI жертвы, который можно получить с помощью IMSI catcher.
Противник посылает пакеты запроса на присоединение с IMSI жертвы в MME через SDR( оно кстати весьма дешёвое где то 300 долларов США).

Чтобы заставить UE жертвы инициировать переход между VoWiFi и VoLTE, противник может использовать атаку деаутентификации , чтобы прервать WiFi-соединение.

Наше SDR-устройство продолжает отправлять запрос на присоединение к MME.
Когда мы запускаем процедуру хэндовера на пострадавшем UE, мы обнаруживаем, что соединение между UE и основной сетью прервано.
UE не получает полезную нагрузку IKE Delete, которая является заключительным сообщением от основной сети, когда передача завершена.

При запуске хэндовера, согласно спецификации, ожидается, что хэндовер должен быть бесшовным для пользователя
Используя эту атаку, противник может остановить бесшовный переход от VoWiFi к VoLTE, что существенно снижает устойчивость сотовой связи.
После атаки в течение около двух секунд жертва достигает состояния, когда UE отключается от основной сети как через VoWiFi, так и через VoLTE.
После этого жертва может подключиться к VoLTE. Однако атака может быть запущена в цикле, чтобы держать UE в разрушительном состоянии хэндовера где оно не может подключиться к основной сети.

Думаю на этом можно заканчивать
Если хотите более подробно то можете заглянуть в архив ниже там много крутого .К примеру статьи про , работу Wifi Calling и VoLTE, про практику атак на них , про улучшение их безопасности🔥 .

В будующим могу сделать статьи про форензику и мобильные сети , просты про телефоны, мышление злоумышлиника и тд тоже будет .Просто сейчас у админа много дел и он не успевает "все и сразу" 🥲

А на этом все спасибо за прочтение . ❤️
Не забывайте идя по стране чудес, что чеширский кот улыбается даже когда вы его не видите🐈🧩
#wifi #lte #mobile #network #traffic_analysis #dos #attacks

WiCA анализатор трафика, который анализирует идентификацию приложения и информацию об устройстве.

Еще есть система

 UCIA она идентифицирует статистику звонков каждого пользователя телефона на основе камеры наблюдения, используя методы распознавания лиц и обнаружения движения человека. CS-IP2U использует статистику вызовов от WiCA и UCIA для соотнесения каждого пользователя телефона с IP-адресом.

Он генерирует таблицу сопоставления с IP-адресом и идентификатором пользователя, а также со статистикой вызовов каждого пользователя.
Более подробно об этом и в целом на звонки по Wifi вы можете глянуть в архиве статей ниже✨.

Теперь поговорим об атаках на VoLTE

Атака на отслеживание информации о местоположении телефонов VoLTE

Чтобы отследить информацию о местоположении телефонов VoLTE, злоумышленник сначала сканирует S-CSCF, чтобы найти S-CSCF, где зарегистрирован телефон VoLTE. После злоумышленник получает IP-адрес телефона VoLTE из S-CSCF.

Наконец, злоумышленник получает информацию о местоположении целевого телефона VoLTE.
Когда функция VoLTE на телефоне VoLTE включена, инициируется процесс регистрации IMS. В это время I-CSCF выполняет поиск в HSS для определения S-CSCF и назначения его телефону VoLTE.
Телефону VoLTE, злоумышленник может подтвердить IP-адрес S-CSCF , назначенный его телефону в пакете "SIP 200 OK" в процессе регистрации VoLTE и по нему определить диапазон IP-адресов S-CSCF. IP-адрес S-CSCF в пакете "SIP 200 OK" в процессе регистрации VoLTE
Сообщение SIP REFER может быть использовано для сканирования диапазона IP-адресов S-CSCF и анализа ответных пакетов для подтверждения IP-адреса S-CSCF, где зарегистрирован целевой VoLTE-телефон. Злоумышленник отправляет SIP REFER-пакеты в P-CSCF, в результате чего в поле From (MSISDN вызывающего абонента) и поля P-Preferred-Identity изменяются на MSISDN(800) VoLTE телефона, поле To (MSISDN абонента) и поле ReferTo на MSISDN(203) злоумышленника, а поле Route на IP-адрес S-CSCF потом P-CSCF получает пакеты, отправленные злоумышленником и пересылает их на IP-адрес, указанный в поле Route После он отправляет пакеты SIP REFER в P-CSCF, в результате чего поле From (MSISDN вызывающего абонента) и поля P-Preferred-Identity изменяются на поля MSISDN(800) целевого VoLTE телефона, а поле To (MSISDN абонента) злоумышленника, а поле Route (изменено) на IP-адрес S-CSCF .
Затем P-CSCF получает пакеты, отправленные злоумышленником, и пересылает их на IP-адрес в поле Route , атакующий получает три типа ответныех пакетов: ошибка 500 , ошибка 403, REFER
REFER указывает как раз на то, что сервер, отправляющий ответный пакет является S-CSCF, где зарегистрирован целевой телефон VoLTE
В этом случае поскольку IP-адрес назначения трафика сканирования, отправленного злоумышленником, является IP P-CSCF, IP источника ответного пакета также является IP P-CSCF.
Другими словами, атакующий не может подтвердить IP S-CSCF, на котором зарегистрирован целевой VoLTE с IP источника ответного пакета. Злоумышленник может подтвердить IP-адрес S-CSCF, на котором зарегистрирован целевой VoLTE-телефон , по значению тега в поле в пакете REFER .
Сообщение SIP SUBSCRIBE вызывает CSCF для получения информации о статусе телефона VoLTE.
В ответ CSCF отправляет сообщение SIP NOTIFY, содержащее текущие регистрационные данные, такие как IP-адрес для SUBSCRIBE что и нужно злоумышленнику !

После получения пакетов, отправленных злоумышленником, P-CSCF пересылает их на IP-адрес S-CSCF в поле Route, в то время как S-CSCF отправляет 200 OK и NOTIFY(он ему и нужен) злоумышленнику в ответ.
#wifi #lte #mobile #network #traffic_analysis #dos #attacks

Давайте более подробно поговорим про сами атаки.⚙️

Предисловие - потом будет тех подробности
В рассказе про VoWiFi атаки будет о перехватчике IMSI на базе WiFi, который использует неавторизованную точку доступа WiFi, чтобы получить личные данные пользователей, находящихся поблизости.
Атаки THDoS, которая может вызвать отказ в голосовом обслуживании для пользователей Wi-Fi звонящих пользователей. Так же про Dos атаки и много других уязвимостей .

Про атаки VoLTE мы разберем атаки которые в основном включают свободный канал передачи данных, DoS и атаки по побочным каналам на IMS и тд . Первый заключается в создании бесплатного канала передачи данных путем отправки каждого пакета который пересылается со шлюза 4G непосредственно в Интернет.
Приведу примеры атак .

Начнем с Wi-Fi Calling

Для начала поговорим про THDOS .
Чтобы бросить определенные пакеты между устройством и сетевой инфраструктурой, противнику необходимо идентифицировать зашифрованные пакеты IPSec. Пример: Пользователь устройства получает входящий Wi-Fi вызов, и отвечает на него примерно через 6 секунд после звонка пользователь ведет голосовой разговор в течение примерно 12 секунд. Что произошло за это время? Ну что видит юзер: 1 получение вызова; 2 ответ на вызов; 3 разговор; 4 вешание трубки. Что видим мы:

1: Первый входящий пакет, который перехватывается на 2-й секунде, представляет собой 1360-байтовый IPSec-пакет. Мы расшифровываем его на стороне абонента и идентифицируем его как сообщение SIP INVITE, что указывает на попытку вызова. На 2-ой секунде, абонент отправляет сообщение 180 RINGING на сервер вызовов Wi-Fi. После этого наблюдается, что несколько небольших IPSec-пакетов размером всего 176 байт получены, но адресат не отправляет никаких пакетов обратно.

1: Мы обнаруживаем, что это голосовые пакеты в протоколе RTP
2 : Абонент отвечает на звонок на 8 секунде, отправив сообщение 200 OK на сервер, а затем получает подтверждение на 9-й секунде. После этого начинается разговор, и абонент начинает отправлять/получать голосовые пакеты.
3: Во время разговора абонент продолжает отправлять/получать голосовые пакеты на/от вызывающего сервера Wi-Fi, но никаких SIP-сообщений не наблюдается. Далее мы обнаружили, что абонент получает по крайней мере 10 голосовых пакетов каждые две секунды от сервера.
4: Вызывающий абонент отправляет сообщение BYE на 20-й секунде после того, как звонок был положен на трубку. Входящие пакеты события "ответ на звонок" на Wi-Fi . После 20-й секунды больше не наблюдается IPSec пакетов . Обратите внимание, что если абонент положит трубку первым, сервер должен отправить сообщение BYE.

Теперь сам пример атаки:
Вызывающий абонент получает несколько входящих звонков от вызывающего абонента.
Существует два подхода. Во-первых, противник досит сообщение 183 сообщение о ходе сеанса, отправленных абонентом, а затем устройство Wi-Fi вызывающего абонента инициирует другой VoLTE вызов в сторону абонента. Во-вторых, злоумышленник досит сообщение 180 сообщение , отправленных абонентом, и затем он заставляет вызывающее устройство Wi-Fi вызывающего абонента застревать на экране набора номера. Звонящий не слышит никакого сигнала оповещения, но устройство вызывающего абонента зазвонит, а вызывающее устройство может продолжать набирать номер.

Звучит скучно - соглашусь . По этому приведу в пример
Атаку раскрытия информации
WiCA был разработан , для определения статистики звонков пользователя Wi-Fi, включая то, что кто инициировал звонок и кто первым повесил трубку, а также время звонка и разговора.
Статистика звонков широко используется для определения личных данных пользователя , включая личность , настроение (например, стрессовое ), вредоносное поведение (например, набор спамерские звонки) и тд . WiCA перехватывает из пакетов Wi-Fi вызовов WiCA извлекает статистику вызовов (например, время звонка и продолжительность вызова) для каждого IP-адреса устройства. Остальные пакеты отправляются на анализатор трафика в реальном времени.
#wifi #lte #mobile #network #traffic_analysis #dos #attacks

Теперь про Wi-Fi Calling Services 📡

Технология звонков по Wi-Fi, также известная как VoWiFi, поддерживается системой 3GPP IMS .
Она обеспечивает мобильных пользователей сотовыми звонками и текстовые сообщеними через Wi-Fi вместо базовых станций сотовой связи. Это альтернативное голосовое решение для мобильных пользователей, которые подключаются к базовым станциям со слабым сигналом.
Wi-Fi звонки используют протокол SIP для сигнализации вызова, как и обычные услуги VoIP ,но отличается от них технически.

Его сигнальная операция SIP представляет собой специфическую для 3GPP версию . 

По соображениям безопасности, и 3GPP, и GSMA предусматривают, что при звонках по Wi-Fi должны использовать хорошо изученные методы безопасности и аутентификации на основе SIM-карты, как и в уже знакомом нам VoLTE.
Они в основном включают защиту секретных ключей в физической SIM-карте и 3GPP AKA . Кроме того, все пакеты вызовов Wi-Fi, которые могут быть отправлены через незащищенные сети, должны доставляться по каналам IPSec с использованием туннельного режима ESP между устройствами вызова Wi-Fi и сотовой сетью .

Несмотря на то, что пакеты защищены IPSec туннелями, услуга Wi-Fi вызовов все равно может пострадать
Во-первых, механизмы выбора беспроводной локальной сети 3GPP WLAN, не предотвращают устройства от подключения к небезопасным сетям Wi-Fi, что может затруднить работу службы вызовов Wi-Fi. Во-вторых, трафик Wi-Fi вызовов, который защищен IPSec, уязвим для атак с использованием побочных каналов , что может привести к утечке конфиденциальной информации. В-третьих, механизм непрерывности услуг между Wi-Fi вызовом и голосовыми услугами на базе сотовой связи может не вступить в силу
Для поддержания и повышения безопасности в Wi-Fi звоночках используются два протокола IETF - IKEv2 и IPSec.

Хотя.. этой сети все равно можно успешно обмениваться поддельными и манипулируемыми пакетами с отправителем и получателем без какого-либо процесса подтверждения личности.
Путем создания неавторизованной точки доступа, оснащенной сервером IPSec, в Wi-Fi сетях, пользовательские устройства могут передавать IMSI, что может привести к проблемам конфиденциальности, таким как отслеживание местоположения . Более того, эти протоколы могут быть уязвимы к нескольким DoS-атакам.
#wifi #lte #mobile #network #traffic_analysis #dos #attacks

Добрый день мои зайчики 🐰

Добро пожаловать в страну чудес так сказать . Админ опять захотел затронуть мобильную связь📱
На этот раз VoLTE и VoWiFi а очнее в этом посте я хочу затронуть тему VoLTE и Wi-Fi Calling , и атак на них.
По свой структуре эти два сервиса схожи . Но давайте по порядку , пост будет разбит на 5 частей ибо он длинный . Так же архив с подробными матерьялами по этой теме будет ниже

Начнем с VoLTE.📞

Грубо говоря VoLTE - это схема передачи голоса поверх ip для PS.
Но только PS, полностью основанная на LTE . Она отказывается от CS- традиционного решения для звонков в сетях 2G/3G. Голосовые сообщения передаются в ip-пакетах на плоскости данных, а не по выделенной цепи. Чтобы облегчить голосовую связь, каждый VoLTE каждый вызов поддерживает отдельный сеанс сигнализации.
VoLTE предлагает очевидные преимущества по сравнению с традиционными 2G/3G включая улучшенное качество (например, звонки высокой четкости), больше возможностей (например, видео звонки, голосовая почта) , а также лучшую совместимость (например, в мобильных сетях, wifi).
Поскольку VoLTE меняет свою парадигму проектирования с CS на PS, нас интересует вопрос о том, могут ли такие существенные изменения могут нанести ущерб сети LTE, а также для пользователей.

VoLTE использует архитектурную структуру IMS

IMS обеспечивает повсеместный доступ к мультимедиа с использованием общего ip-интерфейса. Еще одним важным аспектом является поддержка VoLTE для UE, находящихся в роуминге.
Существуют две конкурирующие технологии для обеспечения роуминга VoLTE, а именно LBO и S8HR.



Архитектура VoLTE основана на 3GPP архитектуре и принципах для VoLTE UE,  LTE, EPC и IMS Core Network

Он состоит из следующих функций:
VoLTE UE содержит функциональные возможности для доступа к LTE RAN и EPC, чтобы обеспечить возможность мобильного широкополосного подключения. Для доступа к услугам VoLTE требуется встроенный стек IMS и приложение VoLTE IMS;
Сеть радио доступа E-UTRAN : Возможности радиосвязи в LTE для FDD LTE, TDD LTE или для FDD и TDD LTE применимы и для VoLTE;
Усовершенствованное пакетное ядро -EPC ;
Базовая сеть IMS в архитектуре VoLTE обеспечивает сервисный уровень обеспечения мультимедийной телефонии;
Думаю базовая структура вам понятна . Более подробно с архитектурой можете ознакомиться в сатьях в архиве ниже(так же там будет более подробно про атаки🙃 . )
VoLTE может вмешиваться в другие компоненты системы, тем самым создавая новые лазейки злоумышленникам в общей сети .
Основанные на PS операции для голоса и данных могут дать возможность для передачи данных по VoLTE..
Более того, поскольку ip-переадресация легко доступна мобильной ОС, VoLTE расширяет доступ к CS в рамках чипсета устройства до более открытого доступа к PS в программном обеспечении.
Это, вероятно, сводит на нет существующие механизмы защиты и средства безопасности для традиционной передачи голоса.
Наконец, в отличие от обычных услуг передачи данных, VoLTE имеет более высокий приоритет в распределении ресурсов для обеспечения лучшего качества. Как вы понимайте это может непреднамеренно послужить побочным каналом для утечки критически информации.
При отсутствии тарификации контрольных пакетов VoLTE, эксплуатация приводит к злонамеренному доступу к данным.

Такая "услуга" доступна как для связи Mobile-to-Internet, так и для связи Mobile-to-Mobile.
Сессии VoLTE по умолчанию не шифруются из конца в конец, следовательно, легко подслушать соединение, особенно со стороны MNO.
#wifi #lte #mobile #network #traffic_analysis #dos #attacks

Hello again Alice 🧩

Interesting utility Codecrypt for those who want to do post quantum cryptography 🔑.
Currently unsupported, but a lot of cool stuff in there nonetheless.

Quantum computers are being actively mined.
In next 10 years they will be widely used. These computers will be very powerful and might break many usual cryptographic algorithms such as RSA. For this reason a new section of cryptography appeared: post-quantum cryptography - a cryptography protecting our systems from hacking by a quantum computer using post-cryptographic algorithms (project NIST ). Already at the moment many systems switch to encryption algorithms of this cryptography .
Now I want to show you a cool tool on this topic Codecrypt🗝

The choice of primitives in it was based on the ease of checking the design, simplicity and security provided.
Its repository contains lots of articles and slides on related topics (cryptography) in doc folder. Therefore, it is suitable for those who want to get into this subject.

Just this project uses many ciphers, for example: 

Stream cipher XSynd, Arcfour, ChaCha20 .

And a variety of encryption algorithms:

MDPC McElice on quasi-cyclic matrices. The implementation uses some techniques to speed up (rather slow) cyclic matrix multiplication (primarily libfftm3 in this version). To fill using the Fujisaki-Okamoto scheme, the cipher requires a stream cipher and CRHF; the ciphers and CRHF used are specified in the algorithm name - for example, MCEQCMDPC128FO-CUBE256-CHACHA20 means that parameters are set to provide 128-bit security, uses CUBE256 hash and the stream cipher ChaCha20. Quadidical McEliece was included in codecrypt as the original algorithm, but now it does not work and displays a warning message whenever it is used.

The codecrypt warning does little to prevent damage from user errors. Be especially careful when managing the keychain, remembering that some operations can rename or remove multiple keys at once. The cryptography used is relatively new, so be sure to check the current state of cryptanalysis before putting your data at risk.

Installation . 

In a lot of linux, you can simply do
sudo apt install codecrypt .
Well, or you can copy the repository

Usage(Examples):

Import Frank's key and rename it
ccr -ia -R friends_pubkeys.asc --name "Friendly Frank"

Send a nice message to Frank (you can also specify it by key ID @12345)
ccr -se -r Frank < Document.doc > Message_to_frank.ccr

Receive answer
ccr -dv -o Decrypted_verified_reply.doc <Reply_from_frank.ccr

Rename foreign keys
cccr -m Frank -N "Unfriendly Frank"

Create (ascii armored) symmetric key and encrypt a big file
ccr -g sha256,chacha20 -aS symkey.asc
ccr -eaS symkey.asc -R big_data.iso -o big_data_encrypted.iso #
decrypt big file
ccr -daS symkey.asc <big_data_encrypted.iso > big_data.iso

Useful Links:
A link with information about maerials 🧩.
Here is a link with documentation and examples of use
Thanks for reading❤️
And remember Alice, if you're abruptly satalnym to die, do not forget the key to the door to the garden on the table🌸🔑
#cryptography #anonymity #linux

Еще раз здравствуйте Алисы 🧩

Интересная утилита Codecrypt для тех кто хочет заняться пост квантовой криптографией 🔑.
В настоящее время не поддерживается, тем не менее там много крутого.

Сейчас активно раздобываются квантовые компьютеры .
В бедующем( в 10 ближайшее лет ) они будут использоваться довольно широко . Эти компьютеры будут отличаться свой большой мощностью, вследствие которой могут разбить многие обычные криптографические алгоритмы типо RSA . По этому появился раздел криптографии, пост квантовая криптография - это такая криптография которая защищает от взлома квантовым компьютером наши системы используя пост криптографические алгоритмы (проект NIST) . Уже на данный момент многие системы переходят на алгоритмы шифрования именно этой криптографии .
Сейчас я хочу вам показать крутой инструмент по этой теме Codecrypt

Выбор примитивов в нем основывался на легкости проверки дизайна, простоте и обеспечиваемой безопасности.
Его репозиторий содержит кучу статей и слайдов по соответствующим темам(криптографии) в папке doc . По этому подойдет для тех кто хочет заняться этой тематикой .

Так же этот проект использует многие шифры , к примеру: 

Поточный шифр XSynd, Arcfour ,ChaCha20 .

И различные алгоритмы шифрование:

MDPC McElice на квазициклических матрицах. Реализация использует некоторые приемы для ускорения (довольно медленного) циклического умножения матриц (в первую очередь libfftm3 в этой версии). Для заполнения с использованием схемы Фуджисаки-Окамото шифр требует потокового шифра и CRHF, используемые шифры и CRHF указаны в имени алгоритма — например, MCEQCMDPC128FO-CUBE256-CHACHA20 означает, что параметры настроены для обеспечения 128-битной безопасности, использует CUBE256 хэш и потоковый шифр ChaCha20. Квазидиадический McEliece был включен в codecrypt в качестве исходного алгоритма, но теперь он не работает и выводит предупреждающее сообщение при любом использовании.

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

Установка . 

Во многих линукс можно просто сделать так
sudo apt install codecrypt .
Ну или вы можете скопировать репозиторий

Использование(Примеры):

Импортируйте ключ Фрэнка и переименуйте его
ccr -ia -R friends_pubkeys.asc --name "Friendly Frank"

Отправить приятное сообщение Фрэнку (также можно указать его по ключевому идентификатору @12345)
ccr -se -r Frank < Document.doc > Message_to_frank.ccr

Получить ответ
ccr -dv -o Decrypted_verified_reply.doc <Reply_from_frank.ccr

Переименовать чужие ключи
cccr -m Frank -N "Unfriendly Frank"

создаем (ascii-бронированный) симметричный ключ и зашифровать большой файл
ccr -g sha256,chacha20 -aS symkey.asc
ccr -eaS symkey.asc -R big_data.iso -o big_data_encrypted.iso #
расшифровать большой файл
ccr -daS symkey.asc <big_data_encrypted.iso > big_data.iso

Полезные ссылки:

Ссылка с информацией о маерьялах .
Вот ссылка с документацией и примерами использования

Спасибо за прочьтение❤️
И помни Алиса если ты резко сатала умельшаться не забудь ключь от дверки в сад на столе🌸🔑
#cryptography #anonymity #linux #tools

Статья про расследования в зашифрованнном трафике Signal мессенжнрах🧩🔑


Article about investigations in Signal messenger encrypted traffic🔑🧩
#traffic_analysis #network #messenger #mobile #forensics

Good afternoon my dear hatter, let's start drinking tea 🧩☕️.

It's been a long time since I've had a post about forensics. 🔎
Today I want to show you a cool article about Signal encrypted traffic analysis 🔑

Since its communication data is encrypted, it becomes difficult or often impossible to get the plaintext because the keys are unknown.
The article below demonstrates how artifacts of potential value can be extracted from analysis of encrypted network traffic .

The Signal application encrypts all messages using the Signal protocol .

Recently, well-known IM applications such as WhatsApp, Facebook Messenger and Skype (in private conversation mode) use the Signal Protocol.
The protocol consists of the Double Ratchet algorithm, XEdDSA and VXEdDSA, X3DH and Sesame.

XEdDSA creates a key pair that is used in elliptic Diffie-Hellman curve and signatures. VXEdDSA is an extension of XEdDSA to turn it into a verifiable random function (VRF) . X3DH (extended Diffie-Hellman) is used for mutual user authentication and provides direct secrecy .

After sharing a shared secret key, messages are transferred between users using the Double Ratchet encryption algorithm . For message session management, Sesame (asynchronous session management) with Double Ratchet and X3DH algorithms is used.

As can be understood , due to the encrypted payload, only packet sizes, packet frequencies and repeating packet patterns can be used. Therefore, certain payload sizes can help to identify specific types of activity
General analysis of packet sizes (patterns, frequencies) can identify "suspicious" application activity. To identify traffic patterns associated with related activities.

Let's understand what data we can, and should, find in general:

User A is the target device on which the actions

His corresponding actions in the application are as follows: 1) Access/open Signal app, 2) Typing patterns on the target device, 3) Typing patterns of User B, 4) Call initiated by User A (caller), 5) Call received by User A (caller), 6) Media messages, 7) Video calls.

In the article below, getting information about each user action item is explained in detail, with clear screenshots in wireshark and a good explanation .

And that's it . I hope you found this article interesting and useful 🎯.

Also, about the "big posts" I have not forgotten about the post about phones or viruses, and so far I am gradually making them, and will release them soon ❤️

And remember , even if the sleepy mouse likes to sleep during tea time , she can still tell you a story✨🐭
#traffic_analysis #network #messenger #mobile #forensics