Порт 62078 iphone что это

Question: Q: TCP Port 62078 on my iPad is open

TCP Port 62078 on my iPad is open with tcpwrappers — also UDP Port 5353 is open/filtered — is this normal? How can I close these ports? On my Macbook Pro they are closed. I do not like having open ports on my network.

iPad, iOS 6.1.3, iPad gen4

Posted on Apr 24, 2013 8:30 AM

Helpful answers

There is no firewall on the iPad, at least nothing accessible to a user other than as part of the Settings interface that activates and deactivates functions in the iPad, and and hence no way to custom-close any ports.

Apple doesn’t list use of any ports in the 62xxx range in their documentation, so I have no idea what that might be used for. 5353 is the Multicast DNS port used for Bonjour, AirPlay, Home Sharing, and printer discovery and is normal to be open. You can shut those ports off in your WiFi router or at your firewall for your WiFi system, but that may break functions in the iPad.

Apr 24, 2013 9:31 AM

The only thing I could find out about TCP Port 62078 is that it is referred to as iphone-sync and is used with the iTunes sync and is some how secured. UDP 5353 comes up in my nmap scan as open/filtered — also what UPD Port 5353 is used for on iPad is limited to the local network for mDNS. Also when my iPad is at home my Verizon FiOS Actiontec Router has a firewall, which I have turned on, so the iPad is fairly secure.

Apr 24, 2013 10:01 AM

There’s more to the conversation

Loading page content

Page content loaded

There is no firewall on the iPad, at least nothing accessible to a user other than as part of the Settings interface that activates and deactivates functions in the iPad, and and hence no way to custom-close any ports.

Apple doesn’t list use of any ports in the 62xxx range in their documentation, so I have no idea what that might be used for. 5353 is the Multicast DNS port used for Bonjour, AirPlay, Home Sharing, and printer discovery and is normal to be open. You can shut those ports off in your WiFi router or at your firewall for your WiFi system, but that may break functions in the iPad.

Apr 24, 2013 9:31 AM

The only thing I could find out about TCP Port 62078 is that it is referred to as iphone-sync and is used with the iTunes sync and is some how secured. UDP 5353 comes up in my nmap scan as open/filtered — also what UPD Port 5353 is used for on iPad is limited to the local network for mDNS. Also when my iPad is at home my Verizon FiOS Actiontec Router has a firewall, which I have turned on, so the iPad is fairly secure.

Apr 24, 2013 10:01 AM

Also when my I turn off WIFI and turn on Cellular on my iPad — TCP Port 62078 is stealth and so is UDP Port 5353.

Apr 24, 2013 10:13 AM

Same problem notified here on my ipad mini with IOS7.

62078 tcp open ttcpwrapped..

I will pay more attention with Firewall iP application for iphone/ipad

Jan 29, 2014 5:22 PM

The port is a back door for the NSA so they can stream corrupt boot images for not only your idevices, but your other equipment too. Port 8021 on 127.0.0.1 is also always listening which allows sip commands to be diverted to localhost. That is why you won’t find documentation.

Jul 24, 2014 12:11 AM

Hahaha, you must be American, fella!!

Jul 28, 2014 1:07 PM

I maintain a firewall for our corporate network and management asked for a mDNS proxy so that their iPhones on our Wi-Fi network could see our Airprint printers on the Ethernet LAN. I regularly see firewall log entries for traffic from desktops on the LAN to iPhones on the Wi-Fi network. At first it seemed random, but then I realised that the desktops and the iPhones were assigned to the same user in each case. The iPhones have presumably been paired with the desktop (iTunes) in the past and the iPhones are using mDNS / Bonjour to look for desktops that they have been previously paired with. The desktops are communicating from ports in the range of 60289 to 62089 and always direct to port 62078 on the iPhone. We don’t have iPads on our network (as far as I know!), but from the Original Poster, it appears that this may also be the case with iPads.

A little bit of digging found an article about Juice Jacking : http://www.zdziarski.com/blog/?p=2345

So this port is used for iPhone or iPad Wi-Fi synching, as mentioned by rjw1678. Once a pairing has been established with a computer, then your iPhone or iPad will always try to pair with this device until such time as you perform a factory restore on the iPhone / iPad.

Nov 10, 2014 1:55 AM

If you download a software or application that allows you to ‘scan services’ like Fing and scan services on your apple device, you will find a site that dislays a messages sent by someone called ‘Zibri’. What is this?

Jun 25, 2015 4:31 PM

Question: Q: TCP Port 62078 on my iPad is open More Less

Источник

iPhone. Находим уязвимости

Примечание: ниже представлен перевод заметки «Exploiting the iPhone», в которой раскрываются некоторые детали не так давно обнаруженных и уже исправленных уязвимостей в iPhone и предлагается пара практических советов по избежанию их в будущем.

Обновление: Apple выпустила обновление, которое устраняет обнаруженные уязвимости. Чтобы узнать подробности обнаружения одной из уязвимостей, просто зайдите в наш блог.

Подробности на BlackHat: Charlie Miller представил детали эксплоита на BlackHat, прошедшей в Лас-Вегасе 2 августа. Эта презентация также доступна по этому адресу.

Предварительное техническое описание: предварительный документ, описывающий атаку, доступен по этому адресу. Полная версия ожидается после 2 августа (прим.: по всей видимости, ее так и не выложили).

Статья в New York Times: история о проделанной работе была опубликована в New York Times.

Добро пожаловать

Вскоре после того, как был выпущен iPhone, группа исследователей вопросов безопасности из Independent Security Evaluators решила проверить, как сложно будет удаленному злоумышленнику получить доступ к приватной информации, хранимой на этом устройстве. В течение двух недель работы при частичной нагрузке мы смогли обнаружить уязвимость, разработать набор инструментов (Toolchain) для взаимодействия с архитектурой iPhone (в том числе, часть утилит была позаимствована из сообщества #iphone-dev) и создать опытный образец эксплоита, который был способен передавать файлы из пользовательского iPhone к удаленному злоумышленнику. Мы уведомили Apple об обнаруженной уязвимости и предложили обновление для программного обеспечения. В данный момент Apple рассматривает это предложение (прим.: как заявлено выше, Apple-таки выпустила официальную версию обновления).

Член нашей группы, Charlie Miller, представил все подробности обнаружения уязвимости и создания эксплоита на BlackHat 2 августа. Информация на сайте будет обновлена, чтобы учесть все изменения, пока опубликована только общая информация по поводу эксплоита для iPhone.

Как это работает

Эксплоит передается через вредоносную веб-страницу, открытую в Safari на iPhone. Существует несколько потенциальных возможностей, которые может использовать злоумышленник, чтобы заставить жертву открыть такую веб-страницы. Рассмотрим следующие примеры.

• Злоумышленник контролирует беспроводную точку доступа. Поскольку iPhone узнают точки доступа по их имени (SSID), то для пользователя достаточно находиться рядом с точкой доступа, контролируемой злоумышленником. Если она имеет то же имя (и тип шифрования), что и точка доступа, которой пользователь доверяет и добавил ранее, тогда iPhone автоматически использует эту вредоносную точку доступа. Это позволит злоумышленнику добавить код эксплоита к произвольной странице, просматриваемой пользователем, просто заменив запрошенную страницу на страницу с эксплоитом.
• Недостаточные настройки безопасности на форуме. Если код программного обеспечения на форуме не обеспечивает должного уровня обработки данных, поступающих от пользователей, то они могут загрузить потенциально вредоносный код в их сообщения. Таким образом, злоумышленник может вызвать выполнение эксплоита в любом браузере на iPhone, когда в нем открыта страница сообщения. (Однако, это потребует некоторых незначительных изменений в нашем опытном образце эксплоита.)
• Ссылка, отправленная в письме или по SMS. Если злоумышленник может обманом заставить пользователя открыть какой-либо веб-сайт, то злоумышленнику достаточно просто включить код эксплоита на главную страницу этого сайта.

Когда Safari на iPhone открывает вредоносную страницу, то произвольный код, включенный в эксплоит, выполняется с правами администратора. В нашем опытном образце этот код читает лог сообщений SMS, адресную книгу, историю звонков, и данные голосовой почты. Затем он отправляет всю эту информацию злоумышленнику. Однако, на месте этого кода может быть достаточно произвольный вариант, который способен использовать любые возможности iPhone. Например, он может переслать пользовательские пароли от электронной почты, отправлять текстовые сообщения, которые подписывают пользователя на платные сервисы, или сделать аудио-запись, которая будет передана злоумышленнику.

Советы

Мы уведомили Apple об этой уязвимости и предложили исправление для нее. Будем надеяться, что они включат его в будущее обновления для iPhone. В целях собственной защиты от этой и других подобных уязвимостей в будущем, стоит придерживаться следующих правил (как для iPhone, так и для других устройств).

• Заходите только на те сайты, которым вы доверяете. Если вы не зайдете на сайт злоумышленника, вы исключите одну из потенциальных возможностей самой атаки.
• Пользуйтесь только теми WiFi-сетями, которым вы доверяете. Если злоумышленники контролируют ваше интернет-соединение, они могут добавить вредоносный код на любой сайт, который вы посещаете.
• Не открывайте ссылок из писем. Многие из известных в настоящее время вирусов рассылают ссылки на вредоносные сайты в письмах, которые могут выглядеть как отправленные от имени знакомых, которым вы доверяете.

Ссылки по теме

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

Источник

Так ли безопасен ваш iPhone? Обзор уязвимостей и тайных ходов в iOS

Пользовательские данные не являются разменной монетой. Компания Apple потратила значительные усилия для того, чтобы заслужить себе репутацию, стойко отбиваясь от ФБР и прочих представителей силовых структур, ищущих возможность произвольного сбора данных владельцев iPhone.

В 2016 г. Apple отказалась ослабить защиту iOS для того, чтобы ФБР могла разблокировать iPhone стрелка из Сан-Бернардино. Завладев смартфоном Сайеда Фарука и промахнувшись десять раз с набором четырехзначного PIN кода, правоохранители тем самым заблокировали смартфон. Тогда в ФБР потребовали, чтобы Apple создала специальную ОС, в которой возможно подобрать код безопасности методом перебора.

Поначалу все складывалось не в пользу Apple, окружной суд Соединенных Штатов по Калифорнии встал на сторону силовых ведомств. Apple подала апелляцию, началась волокита, и в итоге заседания судебное разбирательство на этом прекратилось по инициативе ФБР.

В конце концов, федералы добились своего с помощью Cellebrite — частной израильской компании, специализирующейся в цифровой криминалистике, заплатив за это дело более миллиона долларов США. К слову, в смартфоне ничего не нашли.

Странным образом четыре года спустя история повторилась почти точь-в-точь. В январе 2020 г. не абы кто, а Генеральный Прокурор США Уильям Барр попросил компанию помочь следователям получить доступ к содержимому двух iPhone, использованных во время стрельбы в военно-морской авиабазе в Пенсаколе, штат Флорида, в декабре 2019 года. Не удивительно, что из Apple последовал очередной отказ.

Стоит подчеркнуть, что в обоих случаях речь шла не об одноразовой передаче информации со стороны Apple. С этим как раз все в порядке, компания передает метаданные, резервные копии с iCloud при официальных и санкционированных запросах правоохранительных органов. Отказ встречают требования создать и предоставить универсальную отмычку, особую прошивку iOS, позволяющей разблокировать конфискованные смартфоны.

Именно это обстоятельство вызывает наибольшее противодействие руководства Apple и лично CEO Тима Кука, которые резонно полагают, что нет и не может быть доброкачественных бэкдоров, и что комплексная защита своей мобильной платформы бывает лишь первой свежести. Отмычка в хороших руках очень скоро становится отмычкой в руках сомнительных, а возможно, она там будет и с самого первого дня.
Итак, мы теперь знаем, что iOS не имеет специальных лазеек, созданных для силовых структур. Означает ли это, что iPhone неуязвим для проникновения и кражи данных?

BootROM уязвимость checkm8

В конце сентября 2019 г. исследователь информационной безопасности с ником axi0mX опубликовал на Github ресурсе код эксплойта практически для всех устройств производства Apple с чипами версий A5 — A11. Особенность найденной уязвимости состоит в том, что она находится на аппаратном уровне и никакими обновлениями ПО её невозможно устранить, так как она прячется в самом механизме защиты безопасной загрузки BootROM, a. k. a. SecureROM.

Модель загрузки iOS с презентации Apple на WWDC 2016 г.

В момент холодной загрузки первым из read-only памяти запускается SecureROM, причем это самый доверенный код в Application Processor и поэтому он выполняется без каких-либо проверок. В этом кроется причина того, что патчи iOS тут бессильны. И также крайне важно, что SecureROM отвечает за переход устройства в режим восстановления (Device Firmware Update) через интерфейс USB при нажатии специальной комбинации клавиш.

Переход iOS в режим DFU.

Уязвимость Use-after-Free возникает, когда вы ссылаетесь на память после того, как она была освобождена. Это может привести к неприятным последствиям, таким как сбой программы, непредсказуемые значения, или как в данном случае — выполнение стороннего кода.

Для начала, чтобы понять механизм эксплойта, нам нужно понять, как работает системный режим восстановления. При переходе смартфона в режим DFU в момент инициализации выделяется буфер I/O и создается USB-интерфейс для обработки запросов к DFU. Когда установочный пакет 0x21, 1 поступает по USB-интерфейсу на этапе USB Control Transfer, код DFU после определения адреса и размера блока копирует данные буфера I/O в загрузочную область памяти.

Структура USB Control Transfer Setup Packet.

Соединение по USB остается активным до тех пор, пока длится загрузка образа прошивки, после чего оно завершается в штатном режиме. Однако существует и нештатный сценарий выхода из режима DFU, для этого нужно отправить сигнал DFU abort по коду bmRequestType=0x21, bRequest=4. При этом сохраняется глобальный контекст указателя на буфер данных и размер блока, тем самым возникает классическая ситуация уязвимости Use-after-Free.

Checkm8 по существу эксплуатирует уязвимость Use-after-Free в процессе DFU, чтобы разрешить выполнение произвольного кода. Этот процесс состоит из нескольких этапов, но один из самых важных известен, как фэн-шуй кучи, который тасует кучу специальным образом, чтобы облегчить эксплуатацию уязвимости.

Запуск команды ./ipwndfu -p на MacOS.

В практическом плане все сводится к переводу iPhone в режим DFU и запуску простой команды ./ipwndfu -p. Результат действия Python скрипта состоит в снятии блокирования с несанкционированным доступом ко всей файловой системе смартфона. Это дает возможность устанавливать ПО для iOS из сторонних источников. Так злоумышленники и правоохранители могут получить доступ ко всему содержимому украденного или изъятого смартфона.

Хорошая новость состоит в том, что для взлома и установки стороннего ПО, требуется физический доступ к телефону от Apple и кроме того, после перезагрузки все вернется на место и iPhone будет в безопасности — это т. н. привязанный джейлбрейк. Если у вас на границе отобрали смартфон и затем вернули его, лучше лишний раз не испытывать судьбу и перезагрузиться.

iCloud и почти защищенные бэкапы

Выше уже было сказано, что в последнем противостоянии FBI с Apple из-за перестрелки в Пенсаколе, компания отдала в руки правоохранителей, резервные копии iCloud с телефонов подозреваемых. Тот факт, что в ФБР не стали воротить носом говорит о том, что эти данные, в отличие от заблокированного iPhone, были вполне пригодны для исследования.

Наивно полагать, что это единичный случай. Только за первое полугодие 2019 г. следователи 1568 раз получали доступ к почти 6000 полновесных резервных копий iCloud пользователей яблочных смартфонов. В 90% обращений из гос. структур компания предоставляла некоторые данные из iCloud, а таких обращений всего было около 18 тыс. за тот же период.

Это стало возможным после того, как Apple без лишнего шума два года назад свернула проект по обеспечению сквозного шифрования пользовательских резервных копий iCloud. Есть свидетельства в пользу того, что это было сделано после давления со стороны ФБР. Впрочем, есть также основания полагать, что отказ мотивирован желанием избежать ситуации, когда пользователи из-за забытого пароля не могут получить доступ к собственным данным iCloud.

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

• Домашние данные.
• Медицинские данные.
• Связка ключей iCloud (включая сохраненные учетные записи и пароли).
• Платежные данные.
• Накопленный словарный запас QuickType Keyboard (необходима iOS v.11).
• Screen Time.
• Данные Siri.
• Пароли Wi-Fi.

Все же остальное, включая Messages, возможно, могут прочитать сотрудники Apple и компетентные органы.

Новая уязвимость на аппаратном уровне

Китайская команда разработчиков Pangu Team неделю назад сообщила о найденной неустранимой неисправности, на этот раз в чипе SEP (Secure Enclave Processor). В зоне риска находятся все устройства iPhone процессорах А7-А11.

SEP хранит ключевую, в буквальном смысле слова, информацию. К ним относятся криптографические функции, ключи аутентификации, биометрические данные и профиль Apple Pay. Он делит часть оперативной памяти с Application Processor, но другая ее часть (известная, как TZ0) зашифрована.

Последовательность загрузки SEP.

Сам SEP представляет собой стираемое 4MB процессорное ядро AKF (вероятно, Apple Kingfisher), патент № 20130308838. Используемая технология аналогична ARM TrustZone / SecurCore, но в отличие от нее содержит проприетарный код для ядер Apple KF в целом и SEP в частности. Он также отвечает за генерацию ключей UID на А9 и более новых чипах, для защиты пользовательских данных в статике.

SEP имеет собственный загрузочный ROM и он так же, как и SecureROM / BootROM защищен от записи. То есть уязвимость в SEPROM будет иметь такие же неприятные и неустранимые последствия. Комбинируя дыру в SEPROM с эксплойтом checkm8, о котором уже выше было сказано, можно изменить регистр отображения I/O для обхода защиты изоляции памяти. В практическом плане это дает возможность злоумышленникам заблокировать телефон без возможности его разблокировать.

Хакеры Pangu продемонстрировали, что они могут использовать ошибку в контроллере памяти, управляющем содержимым регистра TZ0. Всех деталей и исходного кода они не стали раскрывать, надеясь продать свою находку компании Apple.

Известный уже нам исследователь ИБ axi0mX написал в Твиттере, что уязвимостью в SEPROM можно воспользоваться лишь при физическом доступе к смартфону, как и в случае с checkm8. Точнее сама возможность манипуляций с содержимым регистра TZ0 зависит от наличия дыры в SecureROM / BootROM, так как после штатной загрузки iPhone изменить значение регистра TZ0уже нельзя. Новые модели iPhone с SoC A12/A13 не подвержены новой уязвимости.

Источник