Русский
Русский
English
Статистика
Реклама

Мобильные устройства

Безопасность мобильных устройств и приложений пять популярных сценариев атак и способы защиты

06.07.2020 16:22:04 | Автор: admin


Изображение: Unsplash

Современные мобильные устройства очень сложны, и это дает злоумышленникам возможности для проведения атак. Для взлома вашего смартфона может быть использовано буквально все от Wi-Fi и Bluetooth до динамика и микрофона.

Аналитики Positive Technologies опубликовали исследование распространенных сценариев атак на мобильные устройства и приложения. В
нашей статье главные тезисы этого документа.

Как атакуют мобильные устройства и приложения



Существует пять основных сценариев атаки. Среди них:

  • Физический доступ. Если телефон был украден или потерян, владелец отдал его в сервис или подключил к поддельному зарядному устройству по USB все это открывает возможность для атаки.
  • Вредоносное приложение на устройстве. Иногда такие приложения могут попасть на устройство даже из официальных источников, Google Play и App Store (для Android, для iOS).
  • Атакующий в канале связи. Подключившись к недоверенному Wi-Fi, прокси-серверу или VPN, мы становимся уязвимыми для атак в канале связи.
  • Удаленные атаки. Атакующий может действовать при этом удаленно, пользуясь серверами мобильных приложений или иными службами для доставки эксплойта.
  • Атаки на серверную часть. Отдельно от всего можно рассмотреть атаки на серверную часть мобильных приложений, поскольку в этом случае доступ к устройству злоумышленнику не требуется.

Поговорим подробнее о каждом из вариантов и обсудим возможные способы защиты от таких атак.

Атаки с физическим доступом


Есть несколько главных сценариев атак с физическим доступом. Как правило, они подразумевают доступ человека напрямую к смартфону: это происходит в том случае, если устройство украли, владелец его потерял или отнес в сервис. Однако есть и достаточно необычный способ атаки, для которого используется вредоносная зарядная станция. Рассмотрим именно его.

Зарядная станция, к которой вы подключаете свой смартфон по USB, вполне может оказаться не совсем безопасной. Для современных версий ОС Android и iOS при подключении с смартфона к ПК по USB требуется разрешение на доступ к устройству. Однако на Android 4.0 и ниже этого не требовалось. В итоге при подключении таких устройств к скомпрометированным или установленным хакерами зарядным станциям, открывается возможность для атаки. Ее сценарий может выглядеть так:

  • На вашем смартфоне с версией Android 4.0 или ниже доступна отладка по USB.
  • Вы подключаетесь к зарядной станции по USB-кабелю.
  • Вредоносная зарядная станция выполняет команду adb install malware.apk, чтобы установить вредонос на ваше устройство.
  • Вредоносная зарядная станция выполняет команду adb am start com.malware.app/.MainActivity для запуска этого вредоносного приложения.
  • Запущенный троян пробует различные техники повышения привилегий, получает права root и закрепляется в системе. Теперь ему доступны все хранимые данные, включая аутентификационные (логины, пароли, токены) от всех установленных приложений, а также неограниченный доступ к любому приложению во время исполнения.

Как защититься


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

Атаки с помощью вредоносных приложений


Есть несколько источников таких приложений:

  • Официальные магазины приложений Google Play и App Store. Редко, но даже в официальных маркетах можно найти вредоносное приложение, которое может нанести ущерб вам и вашим данным. Часто такие приложения стараются заполучить побольше установок с помощью кликбейтных названий типа Super Battery, Turbo Browser или Virus Cleaner 2019.
  • Неофициальные сайты и магазины приложений (third-party appstore). Для Android-устройств достаточно разрешить установку из недоверенных источников, а затем скачать apk-файл приложения с сайта. Для iOS-устройств достаточно перейти по ссылке в браузере Safari, подтвердить установку сертификата на устройство, после чего любое приложение в этом неофициальном магазине станет доступно для установки прямо из браузера.
  • Пользователь может установить скачанное из интернета приложение с помощью USB-подключения.
  • Для Android-устройств доступна возможность загрузки части приложения при переходе по ссылке механизм Google Play Instant.

При установке на смартфон в зависимости от полученных разрешений вредоносные приложения будут иметь доступ к некоторым хранимым данным, микрофону, камере, геопозиции, контактам и т. п. Также они получат возможность взаимодействия с другими установленными приложениями через механизмы межпроцессного взаимодействия (IPC/XPC). Если установленные приложения содержат уязвимости, которые можно проэксплуатировать через такое взаимодействие, вредоносное приложение сможет этим воспользоваться. Особенно актуально это для Android-устройств.

Помимо этого, вредоносное приложение может попытаться получить повышенные привилегии в системе, проэксплуатировав уязвимости, позволяющие получить root-права или jailbreak.

Как защититься


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

Атаки в канале связи


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

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

Даже если проверка сертификатов происходит корректно, у злоумышленника остается лазейка: под неким предлогом вынудить жертву установить на свое устройство сертификат злоумышленника как доверенный. Кроме того, если приложение само по себе безопасно работает с сервером, но содержит ссылки на сторонние ресурсы, загружаемые по HTTP, это все равно составляет возможность для проведения фишинговых атак.

Если злоумышленнику удастся получить контроль над трафиком между клиентским приложением и сервером, то это даст ему целый ряд возможностей:

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

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

Как защититься


Не подключайтесь к сомнительным точкам доступа, не используйте прокси- и VPN-серверы, которым вы не доверяете свою личную и банковскую информацию. Не устанавливайте сторонние сертификаты на устройство.

Как правило, большинство популярных мессенджеров и приложений соцсетей хорошо защищены от подобных атак; если, например, вдруг какое-то из этих приложений отказывается работать через текущее Wi-Fi-подключение, это может означать, что данная точка доступа небезопасна и лучше от нее отключиться, чтобы не подвергать опасности остальные приложения, в том числе ваш мобильный банк.

Удаленные атаки


Некоторые уязвимости в мобильных приложениях можно проэксплуатировать удаленно, и для этого даже не требуется контролировать передачу данных между приложением и сервером. Многие приложения реализуют функциональность по обработке специальных ссылок, например myapp://. Такие ссылки называются deeplinks, и работают они как на Android, так и на iOS. Переход по такой ссылке в браузере, почтовом приложении или мессенджере может спровоцировать открытие того приложения, которое умеет такие ссылки обрабатывать. Вся ссылка целиком, включая параметры, будет передана приложению-обработчику. Если обработчик ссылки содержит уязвимости, то для их эксплуатации будет достаточно вынудить жертву перейти по вредоносной ссылке.

Аналогичный образом в мобильных устройствах могут обрабатываться более привычные ссылки http:// и https:// они могут быть переданы приложению вместо браузера, в некоторых случаях это может происходить без подтверждения со стороны пользователя.

Для Android-устройств переход по ссылке может спровоцировать загрузку Instant App, что делает возможным удаленную эксплуатацию уязвимостей, связанных с установкой вредоносного приложения.

Как защититься


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

Атаки на серверную часть


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

Зачастую устройство серверной части мобильного приложения ничем не отличается от веб-приложения. Как правило, устроены серверы мобильных приложений еще проще и часто представляют из себя json- или xml-api, редко работают с HTML-разметкой и JavaScript, как это часто делают веб-сайты.

Если сравнивать уязвимости веб-приложений и серверных частей мобильных приложений, то мы видим, что следующие уязвимости преобладают в мобильных приложениях:

  • недостаточная защита от подбора учетных данных: 24% веб-приложений и 58% серверов мобильных приложений содержат такие уязвимости,
  • ошибки бизнес-логики: 2% веб-приложений и 33% серверов мобильных приложений.

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

Как защититься


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

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

Хорошей рекомендацией для разработчиков будет внедрение практики безопасной разработки (security development lifecycle, SDL) и регулярный анализ защищенности приложения. Такие меры не только помогут своевременно выявить потенциальные угрозы, но и повысят уровень знаний разработчиков в вопросах безопасности, что повысит уровень защищенности разрабатываемых приложений в долгосрочной перспективе.

Автор: Николай Анисеня, руководитель группы исследований безопасности мобильных приложений Positive Technologies
Подробнее..

Особенности обновлений прошивки мобильных устройств

18.09.2020 14:13:41 | Автор: admin
Обновлять или не обновлять прошивку на личном телефоне каждый решает самостоятельно.
Кто-то ставит CyanogenMod, кто-то не чувствует себя хозяином устройства без TWRP или jailbreak.
В случае с обновлением корпоративных мобильных телефонов процесс должен быть относительно единообразным, иначе IT-шникам даже Рагнарёк покажется забавой.

О том, как это происходит в корпоративном мире, читайте под катом.

Особенности обновлений прошивки мобильных устройств рисунок 1

Краткий ЛикБез


Мобильные устройства на базе iOS получают регулярные обновления аналогично устройствам на Windows, но при этом:

  • обновления выходят реже;
  • обновления получает большинство устройств, но не все.

Apple выпускает обновление iOS сразу для большинства своих устройств, кроме тех, которые снимаются с поддержки. При этом Apple поддерживает свои устройства достаточно долго. Например, обновление iOS 14 получат даже iPhone 6s, вышедшие в 2015 году. Конечно, не обходится без косяков, типа принудительного замедления старых аппаратов, которое, как утверждается, было сделано не с целью вынудить купить новый телефон, а для продления срока службы старого аккумулятора Но в любом случае это лучше, чем ситуация с Android.

Android это по сути своей франшиза. Оригинальный Android от Google встречается только на устройствах линейки Pixel и бюджетных устройствах, которые участвуют в программе Android One. На других устройствах встречаются только производные от Android EMUI, Flyme OS, MIUI, One UI и т.д. Для безопасности мобильных устройств такое разнообразие большая проблема.
Например, сообщество находит очередную уязвимость в Android или системных компонентах, которые лежат в его основе. Далее уязвимости присваивается номер в базе CVE, нашедший получает вознаграждение по одной из баунти-программ от Google, а уж потом Google выпускает заплатку и включает её в очередной релиз Android.

Получит ли её ваш телефон, если он не Pixel или не участник программы Android One?
Если вы купили новое устройство год назад, то, наверное, да, но не сразу. Производителю вашего устройства ещё нужно будет включить патч Google в свою сборку Android и протестировать её на поддерживаемых моделях устройств. Топовые модели поддерживают чуть дольше. Всем остальным остаётся смириться и не читать по утрам базу CVE, чтобы не портить себе аппетит.

Ситуация с мажорными обновлениями Android, как правило, ещё хуже. В среднем новая мажорная версия докатывается до мобильных устройств с кастомными Android не меньше, чем за квартал, а то и больше. Так обновление Android 10 от Google вышло в сентябре 2019, а устройства разных производителей, которым повезло заслужить возможность обновления, получали его вплоть до лета 2020.

Производителей можно понять. Выпуск и тестирование новых прошивок это затраты и не малые. А так как устройства мы уже купили, то дополнительных денег с нас не получить.
Остаётся вынуждать нас покупать новые устройства.

Особенности обновлений прошивки мобильных устройств, Краткий ЛикБез, картинка 2

Дырявость сборок Android отдельных производителей стала причиной того, что Google изменил архитектуру Android, чтобы доставлять критичные обновления самостоятельно. Проект получил название Google Project Zero, около года назад о нём писали на Хабре. Фича относительно новая, но она встроена во все устройства с 2019 года, где есть сервисы Google. Многие знают, что эти сервисы платные для производителей устройств, которые платят за них роялти в Google, но мало кто знает, что дело не ограничивается коммерцией. Чтобы получить разрешение использовать сервисы Google на конкретном устройстве, производитель должен отдать свою прошивку в Google на проверку. При этом Google не принимает на проверку прошивки с древними Android. Это позволяет Google навязывать рынку свой Project Zero, что, надеемся, сделает Android устройства более безопасными.

Рекомендации корпоративным пользователям


В корпоративном мире используются не только публичные приложения, доступные в Google Play и App Store, но и приложения собственной разработки. Иногда жизненный цикл таких приложений прекращается в момент подписания акта приёма-передачи и оплаты услуг разработчика по договору.

В этом случае установка нового мажорного обновления ОС часто приводит к тому, что такие job-is-done приложения перестают работать. Бизнес-процессы останавливаются, а разработчиков нанимают повторно до возникновения следующего косяка. То же самое случается, когда корпоративные разработчики не успевают вовремя адаптировать свои приложения под новую ОС или новая версия приложения уже доступна, но пользователи её ещё не установили. В том числе для решения таких проблем предназначены системы класса UEM.

UEM системы обеспечивают оперативное управление смартфонами и планшетами, своевременно устанавливая и обновляя приложения на устройствах мобильных сотрудников. Кроме того, они могут откатить версию приложения к предыдущей в случае необходимости. Возможность отката версии назад является эксклюзивной фишкой UEM систем. Ни Google Play, ни App Store такой возможности не предоставляют.

UEM системы могут удалённо заблокировать или отложить обновление прошивки мобильных устройств. Поведение зависит от платформы и производителя устройств. На iOS в режиме supervised (о режиме читайте в нашем FAQ) можно отложить обновление до 90 дней. Для этого достаточно настроить соответствующую политику безопасности.

На Android устройствах производства Samsung можно бесплатно запретить обновление прошивки или воспользоваться дополнительным платным сервисом E-FOTA One, с помощью которого можно указать какие обновления ОС устанавливать на устройства. Это даёт администраторам возможность предварительно проверить поведение корпоративных приложений на новых прошивках своих устройств. Понимая трудоёмкость этого процесса, мы предлагаем своим заказчикам сервис на базе Samsung E-FOTA One, включающий услуги проверки работоспособности целевых бизнес-приложений на используемых у заказчика моделях устройств.

На Android устройствах других производителей аналогичной функциональности, увы, нет.
Запретить или отложить их обновление можно, разве что, с помощью страшилок, типа:
Уважаемые пользователи! Не обновляйте свои устройства. Это может привести к неработоспособности приложений. При нарушении этого правила ваши обращения в службу технической поддержки рассматриваться/выслушиваться НЕ БУ-ДУТ!.

Ещё одна рекомендация


Следите за новостями и корпоративными блогами производителей операционных систем, устройств и платформ UEM. Буквально в этом году Google решил отказаться от поддержки одной из возможных мобильных стратегий, а именно fully managed device with work profile.

За этим длинным названием скрывается следующий сценарий:

До Android 10 UEM-системы полноценно управляли устройством И рабочим профилем (контейнером), в котором содержатся корпоративные приложения и данные.
Начиная с Android 11, возможен полноценный функционал управления только ИЛИ устройством ИЛИ рабочим профилем (контейнером).

Google объясняет нововведения заботой о конфиденциальности данных пользователей и своём кошельке. Если есть контейнер, то данные пользователя должны находиться вне зоны видимости и управления со стороны работодателя.

На практике это означает, что узнать местоположение корпоративных устройств или поставить приложения, необходимые пользователю для работы, но не требующие размещения в контейнере для обеспечения защиты корпоративных данных, отныне невозможно. Либо для этого придётся отказаться от контейнера

Google утверждает, что такой доступ к личному пространству отпугивал 38% процентов пользователей от установки UEM. Теперь UEM-вендорам остаётся кушать что дают.

Особенности обновлений прошивки мобильных устройств, Рекомендации корпоративным пользователям, картинка 3

Мы заранее подготовились к нововведениям и в этом году предложим новую версию SafePhone, которая будет учитывать новые требования Google.

Малоизвестные факты


В завершение еще несколько малоизвестных фактов об обновлении мобильных ОС.

  1. Прошивки на мобильных устройствах иногда можно откатить. Как показывает анализ поисковых фраз, фразу как восстановить Android ищут чаще, чем обновление Android. Казалось бы, фарш нельзя провернуть назад, но иногда всё-таки можно. Технически защита от отката базируется на внутреннем счётчике, который увеличивается не с каждой версией прошивки. В рамках одного значения этого счётчика откат становится возможен. Это то, что касается Android. В iOS ситуация чуть отличается. С сайта производителя (или бесчисленного числа зеркал) можно скачать образ iOS конкретной версии для конкретной модели. Чтобы установить его по проводу с помощью iTunes, Apple должен подписать прошивку. Обычно в первые несколько недель после выхода новой версии iOS Apple подписывает предыдущие версии прошивок, чтобы пользователи, чьи устройства после обновления глючат, могли вернуть себе более стабильный билд.
  2. Во времена, когда jailbreak сообщество ещё не разбежалось по крупным компаниям, можно было изменить версию отображаемую версию iOS в одном из системных plist. Так можно было, например, сделать iOS 6.2 из iOS 6.3 и обратно. Зачем это было нужно, расскажем в одной из следующих статей.
  3. Очевидна всеобщая любовь производителей к программе для прошивки смартфонов Odin. Лучшего инструмента для прошивки ещё не сделали.

Пишите, обсудим, может и поможем.
Подробнее..

Precursor собери сам свое open-source мобильное устройство с криптографической защитой

22.09.2020 20:11:13 | Автор: admin


На днях представлен проект открытой программной платформы для создания мобильных устройств. Он получил название Precursor. По словам автора, это Arduino или Raspberry Pi для мобильной отрасли. На базе платформы можно собрать любой мобильный девайс.

В отличие от тех же одноплатников, Precursor поставляется в корпусе, с готовой клавиатурой и дисплеем. Подробнее о проекте под катом.

Характеристики устройства


Корпус изготовлен из алюминия, его размеры 69 x 138 x 7.2 мм. Есть LCD-экран (336*536), аккумулятор на 110 мА*ч, клавиатура, динамик, вибромотор и акселерометр.

Основа девайса программно-определяемый SoC, FPGA Xilinx XC7S50, на его базе организована эмуляция 32-разрядного CPU RISC-V, работающего на частоте 100MHz. Разработчик утверждает, что эмулировать можно работу широкого спектра процессоров от 6502 и Z-80 до AVR и ARM, а также звуковых чипов и различных контроллеров.

Кроме того, плата включает 16 MB SRAM, 128 MB Flash, Wi-Fi Silicon Labs WF200C, USB type C, SPI, IC, GPIO.

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

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

При необходимости можно добавить цепь саморазрушения и очистки всех данных. Активируется эта опция при помощи AES-ключа.


Для работы с аппаратными модулями используется FHDL-язык Migen (Fragmented Hardware Description Language), основанный на Python. Он входит в состав фреймворка LiteX, предоставляющий инфраструктуру для создания электронных схем. Кроме того, разработчик подготовил эталонный SoC Betrusted, включающий 100 MHz CPU VexRISC-V RV32IMAC, а также встраиваемый контроллер Betrusted-EC с ядром 18 MHz LiteX VexRISC-V RV32I.

Предусмотрен и набор криптографических примитивов, включая AES-128, -192, -256 с режимами ECB, CBC и CTR, SHA-2 и SHA-512, криптодвижок на базе эллиптических кривых Curve25519. Основа движка криптоядра Google OpenTitan.


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

Betrusted не мобильный телефон, а скорее цифровой ассистент, позволяющий повысить безопасность приема и передачи данных.


Автор проекта Эндрю Хуан (Andrew Huang), ранее получивший премию EFF Pioneer Award 2012. Как поклонник open source, он открыл ПО и аппаратное обеспечение как Precursor, так и Betrusted. Используемая лицензия Open Hardware Licence 1.2. Эндрю Хуан открыл схемы, проектную документацию плат, SoC Betrusted и управляющего контроллера. Подготовлены и 3D-модели для желающих распечатать корпус. Готовы прошивки и ОС Xous.

С полным описанием проекта можно ознакомиться здесь.

Подробнее..

Recovery mode Защита удаленного доступа (ЗУД) с мобильных устройств

26.10.2020 14:14:03 | Автор: admin

Как выполнить требования ГОСТ Р 57580 по обеспечению безопасного удаленного доступа с мобильных устройств, не запрещая их использования

Об обязательности требований ГОСТР57580 для финансовых организаций, порядке их внедрения иметодах оценки соответствия написано множество статей, дано много рекомендаций, сделано немало комментариев. Согласно требованиям ЦБ, до 01.01.2021 необходимо не только обеспечить соответствие требованиям стандарта, но ипредоставить регулятору отчет обэтом соответствии. На российском рынке существует немало квалифицированных аудиторских компаний, оказывающих услуги финансовым организациям, но доказательство соответствия порой превращается вполемику встиле: Не читал, но осуждаю!.

Мы хотим поделиться практическим опытом реализации одного из восьми процессов, именованным вГОСТе как Процесс8. Защита информации при осуществлении удаленного логического доступа сиспользованием мобильных (переносных) устройств.

Базовый состав мер по защите информации от раскрытия имодификации при осуществлении удаленного доступа

ЗУД.1. Определение правил удаленного доступа и перечня ресурсов доступа, к которым предоставляется удаленный доступ

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

ЗУД.2. Аутентификация мобильных (переносных) устройств удаленного доступа

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

ЗУД.3. Предоставление удаленного доступа только с использованием мобильных (переносных) устройств доступа, находящихся под контролем системы централизованного управления и мониторинга (системы Mobile Device Management, MDM)

На мобильных устройствах должны применяться политики безопасности по крайней мере вобъеме меры ЗУД.10, атакже должен осуществляться мониторинг этих устройств на предмет выявления признаков программного взлома (root, jailbreak), чтобы скомпрометированные устройства не могли получить доступ вкорпоративную сеть. Для этого нужно использовать системы централизованного управления мобильностью. Внастоящее время их принято называть EMM-системами (от англ. Enterprise Mobility Management управление корпоративной мобильностью), но во времена разработки ГОСТ чаще использовался термин MDM (Mobile Device Management управление мобильными устройствами). Вчасти реализации мер ГОСТР57580 это одно ито же, поэтому далее используется термин MDM.

Реализация меры заключается втом, что на все мобильные устройства, скоторых осуществляется удаленный доступ, должен быть установлен MDM-клиент. Также необходимо регулярно проверять, какие устройства удаленно подключаются ккорпоративным ресурсам, чтобы не допустить ситуации, когда личный смартфон сотрудника без контроля иуправления со стороны MDM получает доступ вкорпоративную сеть. Например, такое может произойти, если пользователь сам поставил себе VPN-клиент сдоменной авторизацией или настроил доступ сличного устройства без MDM квнутренней электронной почте по MS ActiveSync, который остался доступен из интернета вопреки реализации меры ЗУД.6.

Мера обязательна для первых двух уровней защиты, для третьего ее реализация необязательна, хотя мы рекомендуем использовать MDM всегда. Системы управления мобильными устройствами не только компенсируют риски ИБ, но исокращают затраты IT на техническую поддержку мобильных устройств ворганизации.

ЗУД.4. Реализация защиты информации от раскрытия и модификации, применение двухсторонней взаимной аутентификации участников информационного обмена при ее передаче при осуществлении удаленного логического доступа

Меру можно рассматривать как усиление или конкретизацию меры ЗУД.2. Аутентификация мобильных приложений иинформационных ресурсов, ккоторым они получают удаленный доступ, должны быть взаимной. Например, сервер проводит аутентификацию клиента по логину ипаролю или по сертификату, амобильное приложение (клиент) проверяет сертификат сервера. Поскольку вбольшинстве случаев для информационного обмена используется протокол HTTPS, реализация этой меры не составляет большого труда.

Базовый состав мер по защите внутренних вычислительных сетей при осуществлении удаленного доступа

ЗУД.5 Идентификация, двухфакторная аутентификация и авторизация субъектов доступа после установления защищенного сетевого взаимодействия, выполнения аутентификации, предусмотренной мерами ЗУД.2 и ЗУД.4

В дополнение креализации мер ЗУД.2 иЗУД.4 нужно осуществлять авторизацию учетных записей работников (проверять наличие уних полномочий для удаленного доступа). Обычно эта мера реализуется спомощью назначения учетным записям ролей и/или включения их вгруппы безопасности, взависимости от которых учетным записям разрешается обращение ктем или иным информационным ресурсам.

Кроме того, финансовой организации следует использовать двухфакторную аутентификацию. Здесь умобильных устройств есть своя особенность. Если на мобильном устройстве настроена биометрия для доступа кмобильному устройству, аутентификацию нельзя считать двухфакторной, потому что пользователь всегда предъявляет только один фактор или биометрию, или пароль, но не то идругое вместе.

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

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

ЗУД.6 Запрет прямого сетевого взаимодействия мобильных (переносных) устройств доступа и внутренних сетей финансовой организации на уровне выше второго (канальный) по семиуровневой стандартной модели взаимодействия открытых систем.

Для удаленного доступа кресурсам финансовой организации необходимо всегда использовать VPN, втом числе при использовании Wi-Fi-сетей финансовой организации. Мера обязательна для первых двух уровней защиты. Для третьего уровня защиты реализация меры необязательна.

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

ЗУД.7 Реализация доступа к ресурсам интернета только через информационную инфраструктуру финансовой организации после установления защищенного сетевого взаимодействия, выполнения аутентификации, предусмотренной мерами ЗУД.2 и ЗУД.4

Для минимизации угрозы фишинга иограничения доступа кскомпрометированным веб-ресурсам мобильные устройства должны обращаться кинтернету так же, как ирабочие станции внутри периметра финансовой организации через системы URL-фильтрации, потоковые антивирусы идругие средства защиты трафика. Мобильные VPN-клиенты могут быть настроены так, чтобы весь исходящий трафик мобильного устройства направлялся вкорпоративную сеть. Но пользователь может выключить VPN внастройках мобильного устройства, даже если такой возможности не предоставляет интерфейс VPN-приложения. Запретить это можно только на устройствах Android при помощи MDM-политик. Для устройств iOS остается только контролировать подключения на VPN-шлюзе. Если устройство не подключено кVPN-шлюзу, но подключено кMDM, то это значит, что пользователь выключил VPN.

Мера обязательна креализации для первого ивторого уровней защиты информации. Для третьего уровня защиты мера необязательна.

ЗУД.8 Контентный анализ информации, передаваемой мобильными (переносными) устройствами в интернет с использованием информационной инфраструктуры финансовой организации

В дополнение кмере ЗУД.7 уточняется, что для защиты трафика мобильных устройств должны применяться средства контентного анализа. Как иЗУД.7, мера обязательна только для первых двух уровней защиты информации.

ЗУД.9 Реализация и контроль информационного взаимодействия внутренних вычислительных сетей финансовой организации и мобильных (переносных) устройств в соответствии с установленными правилами и протоколами сетевого взаимодействия

В значительной степени это техническая реализация меры ЗУД.1. Пользователи должны получать доступ только кразрешенным ресурсам. Ограничение информационного взаимодействия должно быть реализовано спомощью настройки правил межсетевого экранирования. Правила должны быть настроены по принципу белого списка запрещать все, кроме явно разрешенного. Причем серверные компоненты информационных ресурсов должны быть доступны не целиком, атолько по тем протоколам ипортам, которые нужны для информационного обмена сприложениями на мобильных устройствах.

Базовый состав мер по защите информации от раскрытия имодификации при ее обработке ихранении на мобильных (переносных) устройствах

ЗУД.10 Применение системы централизованного управления и мониторинга (MDM-системы)

Меру необходимо реализовывать для первого ивторого уровней защиты информации. На третьем уровне защиты ее реализация является рекомендуемой, но необязательной. Мера предъявляет всовокупности 12 требований ксистемам MDM.

Шифрование ивозможность дистанционного удаления информации, полученной врезультате взаимодействия синформационными ресурсами финансовой организации

Современные мобильные устройства содержат встроенные средства шифрования. Все устройства сОС Android7 ивыше по умолчанию шифруют свои данные. Для устройств сОС Android6 иниже можно включить шифрование спомощью MDM, но доля таких устройств невелика. На устройствах сiOS шифрование включается автоматически, когда пользователь устанавливает пароль для доступа кустройству, поэтому достаточно спомощью MDM запретить доступ кустройству без пароля.

Дистанционное удаление данных смобильных устройств является базовой функцией любой MDM-системы. Ее используют, если пользователи сообщают опотере или краже мобильных устройств. Функцию дистанционной очистки устройств также используют при подготовке устройства, когда оно передается от одного пользователя другому, например при увольнении. Издесь есть важный нюанс.

Для защиты устройств от кражи Apple иGoogle предлагают пользователям настроить функцию Find My Device, которая после сброса устройства кзаводским настройкам не даст использовать его повторно, если пользователь не введет пароль от своей учетной записи. Первым эту функцию реализовал Apple, что сократило число краж iPhone иiPad внесколько раз.

Представьте, что сотрудник не выключил функцию Find My Device ирешил уволиться. Перед увольнением сотрудника администраторы удаленно сбросили устройство кзаводским настройкам иотдали его на склад, пока оно не понадобится новому сотруднику. Через месяц поступает заявка на подготовку этого устройства, его включают, но не могут настроить, потому что пароль от учетной записи уволенного сотрудника неизвестен, аего самого уже ислед простыл. Остается только списывать устройство как сломанное.

Есть три способа не столкнуться сэтой проблемой:

  1. запрещать сотрудникам использовать функцию Find My Device;

  2. требовать обязательного отключения функции Find My Device на устройстве до увольнения сотрудника;

  3. использовать корпоративные аналоги функции Find My Device всоставе MDM-систем.

Аутентификация пользователей на устройстве доступа

С помощью MDM нужно настроить требование кналичию пароля на мобильных устройствах, чтобы устройство, например, оставленное сотрудником на столе, не смог использовать никто другой. Разнообразие политик безопасности всовременных мобильных операционных системах позволяет потребовать теоретически сколь угодно сложный пароль: например, 27-символьный пароль, вкотором должны содержаться буквы верхнего инижнего регистров, цифры испецсимволы.

Практическая рекомендация: достаточно настроить запрет использования простых паролей, содержащих повторяющиеся символы (1111, 2222) или восходящие/убывающие последовательности символов (1234, 9876), атакже ограничить число ошибок ввода пароля, чтобы сотрудники могли использовать удобные цифровые пароли длиной в46символов ипри этом вероятность подбора пароля оставалась низкой.

На мобильных устройствах превышение числа ошибок ввода пароля приводит ксбросу устройств кзаводским настройкам, ане кблокировке учетной записи, как это реализовано на рабочих станциях сWindows или macOS. Обычно после пятой ошибки мобильная операционная система начинает увеличивать интервалы между вводами пароля, чтобы пользователь наконец убедился втом, что забыл пароль, исмог обратиться кадминистратору MDM, чтобы тот сбросил ему пароль удаленно. Мы рекомендуем устанавливать возможность совершить 810ошибок при вводе пароля.

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

Пользователь может настроить мобильное устройство так, что пароль доступа кнему нужно будет вводить только после перезагрузки. Сточки зрения безопасности это не очень сильно отличается от отсутствия пароля. Чтобы исключить это, нужно спомощью MDM настроить максимальное время неактивности пользователя до блокировки сеанса. Рекомендуется устанавливать от одной до трех минут.

Управление обновлениями системного ПО

Обновления мобильных ОС содержат обновления безопасности, поэтому важно устанавливать их своевременно. Техническая возможность устанавливать обновления мобильных ОС есть только на устройствах сAndroid10 ивыше ина Android-устройствах производства Samsung спомощью сервиса Samsung E-FOTA One. На других устройствах технической возможности своевременно установить обновление ОС нет.

В то же время часто возникает необходимость решить обратную задачу запретить или хотя бы отложить обновление мобильной ОС. Запрет или отсрочка обновления необходимы, например, чтобы разработчики смогли адаптировать мобильные приложения для новой версии ОС. Минорные обновления внутри одной мажорной версии ОС, например сAndroid8.1 на Android8.2, обычно не требуют доработки приложений, но при мажорном обновлении ciOS13 на iOS14, например, они могут понадобиться. Запретить обновление ОС можно только на Android-устройствах Samsung, на других устройствах его можно только отложить.

Управление параметрами настроек безопасности системного ПО устройств доступа

Современные мобильные ОС содержат сотни политик безопасности, которые можно разделить на несколько основных групп.

Управление доступом кинтерфейсам записи ипередачи данных, включая камеру, микрофон, Wi-Fi, мобильный интернет, Bluetooth, режим мобильной точки доступа, когда мобильное устройство предоставляет доступ кмобильному интернету по Wi-Fi, Bluetooth или USB ит.д. Политики этой группы могут применяться во время проведения совещаний или для исключения утечки файлов смобильного устройства сиспользованием Bluetooth.

Ограничение встроенных функций ОС. Самая большая группа по числу возможных политик. Из них наиболее востребованными являются: запрещение загрузки Android-устройства вбезопасном режиме, вкотором непрерывная работа средств защиты информации может быть нарушена пользователем, атакже запрещение использования внешних накопителей (SD-карт), которые могут быть применены для несанкционированного копирования данных финансовой организации. На iOS рекомендуется запрещать пользователям устанавливать конфигурационные профили, спомощью которых они могут изменить действующий набор политик безопасности.

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

Ограничение сервисов телефонии, включая полный или частичный запрет голосовых вызовов или прием/передачу коротких сообщений. Может применяться во время совещаний, переговоров, чтобы пользователи мобильных устройств, например, не отвлекались на входящие сообщения ивызовы.

Управление составом иобновлениями прикладного ПО

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

С точки зрения информационной безопасности необходимо запретить установку мобильных приложений из непроверенных источников, атакже при необходимости впринципе запретить пользователям устанавливать мобильные приложения, распространяя их только из доверенного MDM-хранилища. Более подробно эти запреты рассмотрены ниже, вописании реализации меры ЗУД.11.

Невозможность использования мобильного (переносного) устройства врежиме USB-накопителя, атакже врежиме отладки

Запрет доступа кфайлам мобильного устройства по USB защищает от утечки данные финансовой организации. Вто же время, если эти данные зашифрованы, то их выгрузка смобильного устройства взашифрованном виде не приведет ккомпрометации.

Режим отладки позволяет устанавливать на мобильные устройства приложения вобход системы MDM ипубличных каталогов Google Play иApp Store. Этой возможностью вполне реально воспользоваться, например, когда мобильное устройство сдается перед переговорами. Режим отладки нужен только разработчикам приложений, рядовым пользователям он не требуется, поэтому его следует запретить.

Для iOS режима отладки нет, но при наличии ноутбука под macOS сустановленным XCode изнании пароля доступа кустройству возможна несанкционированная установка на него приложения по USB. Для защиты от этого нужно перевести iOS-устройство врежим supervised иустановить спомощью MDM запрет подключения мобильного устройства ко всем рабочим станциям, кроме той, которую использовал администратор для перевода устройства вsupervised-режим. Этот же запрет ограничит доступ кфайлам iOS-устройства по USB.

Управление ключевой информацией, используемой для организации защищенного сетевого взаимодействия

MDM-системы позволяют автоматизировать выпуск иобеспечить централизованную доставку на мобильные устройства цифровых сертификатов. Сертификаты выписываются на удостоверяющем центре финансовой организации имогут применяться для аутентификации доступа мобильных устройств кWi-Fi-сетям или внутренней электронной почте. Кроме того, эти сертификаты могут применяться для аутентификации доступа кVPN-сети, если используемое VPN-решение использует такой способ аутентификации. Ключевое ограничение этой технологии заключается втом, что она оказывается несовместимой сотечественной криптографией. Удостоверяющие центры, реализующие алгоритмы ГОСТ-шифрования, не содержат прикладных интерфейсов (API), для того чтобы внешняя MDM-система могла выпустить на них сертификат. Если VPN-решение использует симметричную криптографию без цифровых сертификатов, то управление ключевой информацией обычно полностью сосредоточено внутри решения VPN. Вэтом случае MDM-система тоже не может помочь дополнительно автоматизировать или упростить этот процесс.

Возможность определения местонахождения мобильного устройства

MDM-системы позволяют не только управлять смартфонами ипланшетами, устанавливая на них политики безопасности имобильные приложения, но иосуществлять мониторинг корпоративных мобильных активов. Одной из самых востребованных функций мониторинга является определение местонахождения мобильных устройств. Его используют для решения нескольких задач:

  • поиск утерянных устройств. Вэтом случае, как правило, их дистанционно блокируют, после чего производят поиск по последним полученным от устройства координатам;

  • применение политик безопасности взависимости от местоположения устройства, например запрет использования камеры вофисах финансовой организации;

  • контроль выполнения трудовых обязанностей полевого персонала, например фиксация фактов отклонения движения инкассаторов от регламентного маршрута или непосещения подконтрольных отделений супервайзерами;

  • выявление фактов утечки инсайда. Данные оместоположении мобильных устройств всовокупности синформацией окоммуникациях абонентов позволяют выявлять нежелательные социальные связи ипредотвращать утечку инсайда.

Регистрация смены SIM-карты

Необходимо фиксировать факты извлечения исмены SIM-карты мобильного устройства. Делается это для защиты данных при потере или краже устройства. Если устройство украдут, то первое, что сним сделают, это извлекут SIM-карту, чтобы устройство нельзя было отследить. Поэтому дополнительно рекомендуется настроить автоматическую блокировку устройства при извлечении SIM-карты спомощью MDM.

Запрет переноса информации воблачные хранилища данных, расположенные вобщедоступных сетях (например, iCIoud)

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

  1. Запретить доступ кiCloud, DropBox, Яндекс Диск, Google Drive идругим аналогичным сервисам. Спомощью встроенных политик безопасности мобильных ОС можно запретить только доступ кiCloud для iOS ирезервное копирование на серверы Google для Android. Доступ костальным сервисам можно ограничить только спомощью запрета наличия на мобильных устройствах соответствующих мобильных приложений.

  2. Хранить данные на мобильном устройстве взашифрованном виде. Вэтом случае неважно, как икуда смобильного устройства будут выгружены данные. Если они зашифрованы, то утечки не будет. Достаточно обеспечить неизвлекаемость ключа шифрования смобильного устройства.

Обеспечение возможности централизованного управления имониторинга при смене SIM-карты

Требование скорее относится кинформационной инфраструктуре финансовой организации. Смена SIM-карты может повлиять на возможность централизованного управления лишь водном случае если доступ ксерверу системы MDM возможен только сопределенных SIM-карт. Такое возможно, если финансовая организация приобрела усотового оператора специальный тариф, врамках которого трафик скорпоративных SIM-карт маршрутизируется вкорпоративную сеть. Чтобы не терять возможность управления при замене такой SIM-карты на другую, нужно обеспечить доступность сервера системы MDM из интернета. Это позволит осуществлять непрерывное управление мобильными устройствами вне зависимости от работоспособности идоступности VPN-шлюза иустановленной вмобильном устройстве SIM-карты.

ЗУД.11 Обеспечение защиты мобильных (переносных) устройств от воздействий вредоносного кода

На рабочих станциях вирусы обычно содержатся вфайлах, которые при открытии эксплуатируют одну из уязвимостей операционной системы или установленных вней приложений. На мобильных устройствах запустить отдельный файл нельзя, можно запустить только приложение. Поэтому большинство вирусов представляют собой модифицированные версии привычных приложений, которые при установке вобход официальных каталогов Google Play иApp Store, например, могут несанкционированно собирать данные финансовой организации.

Рекомендуем несколько проверенных способов защиты от этого.

  1. Запретить пользователям устанавливать приложения на мобильные устройства иустанавливать все приложения централизованно спомощью MDM, предварительно проверяя дистрибутивы приложений спомощью антивируса.

  2. Запретить пользователям устанавливать приложения из непроверенных источников. Тогда на мобильных устройствах будут только проверенные приложения, установленные спомощью MDM или из официальных каталогов Google Play иApp Store.

  3. Установить на мобильные устройства антивирус ввиде отдельного приложения или всоставе приложения MDM. Вэтом случае все файлы иприложения на мобильном устройстве будут проверяться на наличие вредоносного кода. Это позволить проверять на наличие вирусов приложения, устанавливаемые пользователями из Google Play.

Для iOS антивирусов не бывает. Ни одно приложение на iOS не может получить доступ кфайлам других приложений, поэтому разработать антивирус для iOS невозможно. Врезультате на iOS можно использовать только первые два способа реализации меры ЗУД.11.

ЗУД.12 Стирание информации конфиденциального характера с мобильных (переносных) устройств средствами, обеспечивающими полную перезапись данных, при осуществлении вывода мобильных (переносных) устройств из эксплуатации, а также при необходимости их передачи в сторонние организации, между работниками и (или) структурными подразделениями финансовой организации

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

Надеемся, что статья окажется полезной не только для компаний, которые проходят аудит на соответствие ГОСТР57580, но идля всех компаний, которые активно используют мобильные устройства всвоих бизнес-процессах.

Подробнее..

Непрохождение вызова по номеру 112 на телефоне Xiaomi Redmi Note 5

08.08.2020 00:06:58 | Автор: admin
Я использую (уже довольно старый) телефон Xiaomi Redmi Note 5 и хочу рассказать о том, почему этот телефон (и, возможно, некоторые другие) может довести до трагических последствий.

Примерно месяц назад потребовалось позвонить 112, но вместо ответа оператора я услышал, что номер набран неправильно (в моей стране проживания именно 112 является номером для экстренных вызовов). Поскольку в телефоне используется 2 сим-карты, то сразу попробовал со второй и дозвонился. Но что если бы второй сим-карты не было? Подобные ситуации могут оказаться фатальными.

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

Собстсвенно сам процесс поиска причина происходил следующим образом: был совершён звонок в 112 с телефона супруги (с тем же оператором, что не звонил у меня, но с другой симки), звонок прошёл, значит проблема либо в моём подключении, либо в моём телефоне. Далее, был совершён звонок с той же (проблемной) симки, но в другом телефоне и вызов прошёл. Итого имеем: с проблемного телефона не проходит вызов в 112 с использованием определённого оператора, при этом можно позвонить в 112 с другого оператора с проблемного телефона. Таким образом выясняем: комбинация оператора+телефона даёт непрохожденного звонка в 112.

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

На первый тикет мне просто ответили, что я не совершаю никаких вызовов и проблема в телефоне, сразу же закрыли тикет. Зная внутреннюю кухню операторов связи и наличие штрафов за повторные обращения, тут же открыл второй тикет, в котором указал что обращусь в государственный регулятор, если моей проблемой не займутся. Через несколько дней со мной связались настоящие инженеры (это было понятно по их вопросам и манере общения), попросили сделать пару звонков и тут мне удалось с ними поговорить по сути проблемы. А суть её вот в чём: телефон действительно делал посыл вызова на номер 112, но при этом не указывал категорию emergency из-за чего звонок не передавался в единую службу 112, этому же инженеру сказал что у другого оператора всё работает и он подтвердил мою догадку, что другой оператор скорее всего не делает проверку категории звонка и отправляет все вызовы на 112 в единую службу помощи. Инженеры проблемного оператора исправили проблему в моём регионе (т.е. теперь у этого оператора нет жёсткой проверки категории звонка для экстренных вызовов) и обещали исправить во всех остальных регионах присутсвия.

А теперь то, ради чего была написана эта статья. Покупая новый телефон или меняя оператора, проверьте что вы можете дозвониться в 112/911/другой номер в зависимости от страны. Когда ваш телефон регистрируется в неродной сети (роуминг), тоже очень желательно проверить наличие возможности дозвониться в экстренную службу помощи, т.к. на кривых телефонах, которые не отправляют категорию номера emergency, проблема может не возникать в вашей родной сети и возникнуть в другой (это зависит от настроек сети).

P.S. Телефон ввезён в страну официальным дистрибьютором, регион выставлен корректно, прошивка latest stable от производителя. Никаких экспериментов с прошивками не делалось.
P.P.S. Нашёл три жалобы других пользователей с такой же проблемой с этой моделью телефона (с вероятностью близкой к 100% могу сказать что как минимум одна жалоба из другой страны, т.к. она описана на украинском разделе форуме Xiaomi, т.е. скорее всего абонентом из Украины). Вот они: www.youtube.com/watch?v=r6w8sODG1Fg, c.mi.com/thread-1474364-1-0.html и rozetka.com.ua/ua/xiaomi_redmi_note5_4_64gb_gold/p42432888/comments/page=47
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru