macOS High Sierra хранит зашифрованные пароли APFS-томов в открытом виде

macOS High Sierra хранит зашифрованные пароли APFS-томов в открытом виде

macOS High Sierra хранит зашифрованные пароли APFS-томов в открытом виде

Пользователи macOS High Sierra опять столкнулись с багом APFS. На этот раз эксперты выяснили, что последняя версия macOS регистрирует пароли шифрования для внешних дисков, отформатированных в APFS, причем хранит их в простом текстовом виде в лог-файлах.

Если злоумышленник использует этот недочет, он сможет легко получить доступ к паролю зашифрованных внешних томов APFS, например, USB-накопителей, переносных жестких дисков и других внешних носителей.

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

Брешь затрагивает macOS High Sierra с версии 10.13 до версии 10.13.3. На каждую из версий этот баг распространяется по-разному.

Обнаруживший проблему эксперт говорит, что всякий раз, когда пользователь создает новый том APFS и выбирает пароль шифрования, приложение Disk Utility будет записывать этот пароль в единый журнал. Этот недочет актуален для версий 10.13 и 10.13.1.

Что касается версии 10.13.3, пароль шифрования также будет записываться, но когда пользователь шифрует уже существующий внешний том в формате APFS (вместо его создания).

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

В прошлом году мы сообщали о том, что в macOS High Sierra обнаружена критическая уязвимость — злоумышленник может получить права суперпользователя без ввода пароля. О бреше сообщил эксперт из Турции Леми Орхан Эргин (Lemi Orhan Ergin).

В HoneyCorn нашли способ устранить недостатки IoC

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

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

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

Один из ключевых инструментов защиты сегодня — индикаторы компрометации (IoC). Это машиночитаемые признаки атак: IP-адреса, хеши файлов, сигнатуры, домены, параметры фишинговых писем и другие технические артефакты. В идеале они должны быстро собираться при обнаружении новой атаки и распространяться по экосистеме, чтобы остальные компании могли заранее принять меры.

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

Давайте разберём почему.

  1. В классическом TI не собираются необходимые индикаторы компрометации в требуемом виде (базы паролей, используемых при брутфорсе, полные параметры фишинговых писем, семплы файлов, а также YARA-правила и хеши для инжектов и т. д.).
  2. Нет быстрой верификации индикаторов компрометации, в связи с этим — большое количество ложных срабатываний.
  3. Нет общепринятой классификации индикаторов компрометации по целевым спискам для решения всех необходимых задач и тюнинга количества ложных срабатываний.
  4. Нет единой унифицированной шины распространения индикаторов компрометации.
  5. Нет профессионального сообщества, обмена индикаторами компрометации для повышения базы сбора.
  6. Сейчас нет действенных механизмов сбора новых индикаторов без взлома реальных заказчиков.
  7. Не происходит автоматический реверс угроз нулевого дня.

И это только вершина айсберга – крутая технология становится посредственной из-за ряда практических недочётов.

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

RSS: Новости на портале Anti-Malware.ru