У Apple непростая история с исследователями безопасности: она хочет рекламировать свою безопасность превосходно, а это означает пытаться заставить замолчать тех, кто стремится доказать обратное. Но эти попытки бороться с исследователями безопасности, которые продают свою информацию кому-либо, кроме Apple, подрывают идею безопасности компании.
Недавняя статья раскрыла подробности легендарной борьбы Apple с правительством США в 2016 году, когда министерство юстиции подтолкнуло Apple к созданию бэкдора безопасности, связанного с iPhone, использованным террористом во время стрельбы в Сан-Бернардино. Apple отказалась; правительство преследовало его в суде. Затем, когда правительство нашло исследователя безопасности, который предложил способ обойти безопасность Apple, правительство прекратило судебную тяжбу. Эксплойт сработал, и, к сожалению, на устройстве не было обнаружено ничего ценного для правительства.
Все это известно, но в статье подробно описывается эксплойт, купленный правительством за 900 000 долларов. Это связано с дырой в открытом исходном коде от Mozilla, которую Apple использовала, чтобы разрешить подключение аксессуаров к порту молнии iPhone. Это была ахиллесова пята телефона. (Примечание: сейчас не о чем беспокоиться; уязвимость уже давно закрыта Mozilla, что делает эксплойт бесполезным.)
Функция безопасности Apple, которая разочаровала правительство, заключалась в защите от атак грубой силы. iPhone просто удалил все данные после 10 неудачных попыток входа в систему.
Один исследователь угроз «создал эксплойт, который позволил получить первоначальный доступ к телефону — шаг в дверь. Затем он прицепил его к другому подвигу, который позволил увеличить маневренность. А затем он связал это с последним эксплойтом, который другой исследователь Azimuth уже создал для iPhone, что дало ему полный контроль над базовым процессором телефона — мозгом устройства», — говорится в сообщении. «Отсюда он написал программное обеспечение, которое быстро пробовало все комбинации кода доступа, обходя другие функции, такие как стирание данных после 10 неправильных попыток».
Учитывая все это, каков итог для ИТ и безопасности? Это немного сложно.
С одной стороны, вывод заключается в том, что предприятие не может доверять ни одному мобильному устройству потребительского уровня (устройства Android и iOS могут иметь проблемы с безопасностью, но и те и другие имеют существенные проблемы с безопасностью) без использования собственных механизмов безопасности предприятия. С более прагматичной точки зрения, ни одно устройство не обеспечивает идеальной безопасности, а некоторые мобильные устройства — iOS в большей степени, чем Android — неплохо справляются со своей задачей.
Мобильные устройства обеспечивают очень недорогую идентификацию благодаря встроенной биометрии. (Сегодня почти все это распознавание лиц, но я надеюсь на возвращение отпечатков пальцев и — пожалуйста, пожалуйста — добавление сканирования сетчатки глаза, которое является гораздо лучшим биометрическим методом, чем отпечаток пальца или лицо.)
Эти биометрические данные важны, потому что слабым местом как для iOS, так и для Android является авторизованный доступ к устройству, о чем и пойдет речь. Оказавшись внутри телефона, биометрия обеспечивает экономичный дополнительный уровень аутентификации для корпоративных приложений. (Я все еще жду, когда кто-нибудь запустит корпоративную VPN с помощью распознавания лиц; учитывая, что VPN является исходным ключом для сверхчувствительных корпоративных файлов, для нее требуется дополнительная аутентификация.)
Что касается описанного обходного пути, то настоящим виновником здесь является сложность. Телефоны — это очень сложные устройства с множеством сторонних приложений со своими проблемами безопасности. Мне вспоминается колонка семилетней давности, в которой мы рассказали, как приложение Starbucks сохраняет пароли в открытом виде, где их может увидеть любой желающий. Виновником оказалось принадлежащее Twitter приложение для аналитики сбоев, которое зафиксировало все в тот момент, когда обнаружило сбой. Вот откуда взялись текстовые пароли.
Все это поднимает ключевой вопрос: насколько реалистично тестирование мобильной безопасности, будь то на уровне предприятия (в данном примере Starbucks) или на уровне поставщика (Apple). Мы нашли эти ошибки благодаря тестировщику на проникновение, с которым мы работали, и я по-прежнему утверждаю, что должно быть больше пентестов как на уровне предприятия, так и на уровне поставщика. Тем не менее, даже хороший сторонний тестер не все поймает — никто не может.
Это возвращает нас к первоначальному вопросу: что должны делать корпоративные ИТ-администраторы и администраторы безопасности, когда речь идет о мобильной безопасности? Ну, мы можем исключить очевидный вариант, так как не использовать мобильные устройства для корпоративных данных — это не вариант. Их преимущества и массовое распространение (они уже есть в руках почти всех сотрудников/подрядчиков/третьих лиц/клиентов) делают невозможным сопротивление мобильным технологиям.
Но ни одно предприятие не может оправдать доверие безопасности этих устройств. Это означает разделение для корпоративных данных и требование предоставления доступа приложениями безопасности корпоративного уровня.
Извините, люди, но просто слишком много дыр — открытых и еще не обнаруженных — которые можно использовать. Внутри современных телефонов находится код от тысяч программистов, работающих в Apple, многие из которых никогда не разговаривают друг с другом или которые создали сторонние приложения. Всегда нет ни одного человека, который знает все обо всем коде внутри телефона. Это верно для любого сложного устройства. И это напрашивается на неприятности.
© 2021 IDG Communications, Inc.