T-Mobile Fixes Man-in-the-Middle Vulnerability in Wi-Fi Calling App - Защита мобильных устройств - Форумы Anti-Malware.ru Перейти к содержанию
Viktor

T-Mobile Fixes Man-in-the-Middle Vulnerability in Wi-Fi Calling App

Recommended Posts

Viktor
The default “Wi-Fi Calling” feature on T-Mobile devices that lets milllions of Android users make phone calls over a wireless Internet connection contained a vulnerability that could have been exploited to perform man-in-the-middle (MiTM) attacks.

Graduate students Jethro Beekman and Christopher Thompson from the Electrical Engineering and Computer Sciences department at the University of California Berkeley uncovered the issue and reported it to T-Mobile’s security team in December. T-Mobile's senior manager for Mobile Assurance and Product Security, Darren Kress, said that as of yesterday the vulnerability had been resolved for all devices.

Beekman and Thompson found that the Wi-Fi Calling feature did not properly validate the transport layer security (TLS) certificate from the server with which it must communicate. Because of this, the researchers claim attackers could potentially forge themselves counterfeit certificates that would allow them to perform MiTM attacks by impersonating the T-Mobile server that handles the Wi-Fi Calling application. Attackers that perform a proper exploit could intercept, spy on, decrypt, and otherwise modify voice calls, text messages, or any other traffic transmitted via T-Mobile’s Wi-Fi Calling feature.

In a technical analysis of the exploit, the Berkeley graduate students examined the certificate chain that T-Mobile’s server was sending to their device. Two anomalies stood out: the name of the first cert was merely the IP address of the server, and the self-signed cert was not included in standard certificate authority distributions (nor was it recognized in various Web searches), which ended up meaning that T-Mobile hadn’t implemented certificate validation correctly and that their certificates could be easily spoofed.

From here they noticed that a session initiation protocol dialogue pops up when a TLS connection is established between T-Mobile and the device. The device authenticates itself by sending its phone number, International Mobile station Equipment Identity (IMEI), and International Mobile Subscriber Identity (IMSI) to the server. The server then responds with an INVITE message containing an encryption key that lets an attacker decrypt the SIP dialogue, which an attacker can use to record incoming and outgoing calls and texts, record, block, and reroute SIP traffic, spoof sender identification or message content, and impersonate incoming and outgoing calls.

The most effective way for an attacker to exploit this vulnerability is by being on the same, open wireless network as his or her victim.

Источник

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

  • Сообщения

    • demkd
      Если версия системы идентичная то скорее всего подойдет, но это не точно, потому что лично я всегда пользовался бэкапом реестра, сперва ERUNT-ом, а когда он стал неактуален сделал свой ABR.
    • santy
      Вообще, в сети мало пишут про то, как восстановить работу безопасного режима, в основном после поискового запроса выводят статьи, как войти в безопасный  режим. (Видно хромает еще ИИ по этому вопросу). По данному, частному случаю как будто все уже перепробовали: точка восстановления есть но с заражением системы, со слов пользователя. Хотя по факту здесь и не нужно восстанавливать систему, достаточно только найти в этой точке файл SYSTEM, откопировать его в другое место и извлечь из него ключ SafeBoot. Возможно, что он и делал восстановление системы из точки восст., но Safe mode не заработал. Других точек восстановления нет, бэкапов реестра нет, так как не работал ранее с uVS, да, и мы вообщем редко практикуем в сложных случаях создавать бэкап реестра. Те функции восстановления ключа, что заложены в uVS, опираются на бэкап реестра. (Которого не оказалось в системе). Твик Зайцева так же не сработал, возможно основан на методе их текста, который RP55 принес сюда. Остается попытаться перенести ключ с чистой аналогичной системы. Возможно ли безболезненно взять ключ Safeboot из другой аналогичной чистой системы? Какие могут возникнуть проблемы? драйвера оборудования могут оказаться различными?  
    • demkd
      "CurrentControlSet" это виртуальный ключ, он указывает на последний рабочий CurrentControlSetXXX, потому копировать там обычно нечего потому что есть лишь CurrentControlSet001, который и есть CurrentControlSet, другое дело когда есть 001 и 002, один из них может быть живым, а может и не быть.
      Но на самом деле не нужно маяться фигней, нужно пользоваться бэкапом и восстановлением реестра, тем более что в uVS есть твик для включения системного бэкапа реестра, так же копии реестра есть в теневых копиях и точках восстановления, где гарантировано можно найти рабочую ветку реестра и восстановить ее либо руками либо через uVS->Реестр->Восстановить из копии ключ SafeBoot
    • PR55.RP55
      " Вот еще в помощь рекомендации от Зайцева Олега:   Цитата Кроме того, есть еще один метод восстановления испорченных ключей. Как известно, в самом реестре есть копии ключа SafeBoot. Они находятся в HKLM\SYSTEM\CurrentControlSet001\Control\SafeBoot и HKLM\SYSTEM\CurrentControlSet002\Control\SafeBoot. Следовательно, можно попробовать следующую операцию:
      1. Экспортировать HKLM\SYSTEM\CurrentControlSet001\Control\SafeBoot
      2. В полученном REG файле заменить "CurrentControlSet001" на "CurrentControlSet" (REG файл текстовый, поэтому заменить несложно)
      3. Импортировать модифицированный файл
      Данная операция может быть успешной сразу после запуска повреждающей ключ реестра вредоносной программы, до перезагрузки. Нарушена загрузка в защищенном режиме (SafeBoot) Изменено 6 часов назад пользователем safety " https://forum.kasperskyclub.ru/topic/466078-privetstvuju-slovil-majner-po-nazvaniem-toolbtcmine2782/page/6/#comments А, что если это будет делать uVS ? т.е. Копировать ключ > модифицировать > производить перезапись.
    • Ego Dekker
      Домашние антивирусы для Windows были обновлены до версии 18.1.10.
×