Главная » Пентест » Уязвимость в MacOS High Sierra
mac os high sierra vulnerability

Уязвимость в MacOS High Sierra

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

Такие экстренные обновления — редкость, и выпускают их только по случаю обнаружения особо опасных багов. В прошлый раз апдейт такого типа приходил в 2014 году — в связи с уязвимостью в ntpd.

Рассмотренная в этой статье уязвимость получила номер CVE-2017-13872 и описание «a logic error… in the validation of credentials».

Еще по теме: Уязвимость в процессорах Intel

Уязвимость в MacOS High Sierra

Когда атакующий попытается залогиниться от пользователя, который на данный момент не включен (как root, например), то система услужливо создаст аккаунт с тем паролем, что вы укажите в поле «Пароль» (например, пустой, почему нет). То есть окошко логина по совместительству служит окном установки пароля — очень удобно. Так как аккаунт был изначально не активирован, результат «логина» будет неудачным и потребуется вторая попытка авторизации, которая уже и станет успешной.

Теперь о том, как все это выглядит на более низком уровне. Давайте найдем любое место, где можно указать логин и пароль пользователя. Самый простой вариант — это открыть настройки пользователей и нажать на символ замка для внесения изменений. Тут же выскочит окошко с требованием ввести кредсы. Вбиваем в качестве имени пользователя root, а в качестве пароля что угодно.

Пользователь root присутствует во всех UNIX-подобных системах, и macOS не исключение. Только по умолчанию этот пользователь отключен. Но в наших силах его оживить!

Уязвимость в MacOS High Sierra
Root-пользователь имеется и в macOS

Нажимаем на «Снять защиту» и приступаем к увлекательному отладочному пути, который начинается с демона opendirectoryd (/usr/libexec/opendirectoryd).

Уязвимость в MacOS High Sierra
Присоединяемся к процессу, который отвечает за авторизацию, при помощи отладчика lldb

Это он перехватывает попытку авторизации пользователя в системе.

Уязвимость в MacOS High Sierra
Брейк-пойнт перед вызовом функции проверки пароля

Демон вызывает метод odm_RecordVerifyPassword, который реализован в бандле PlistFile. В macOS есть такое понятие, как bundle (бандл). Бандл представляет собой псевдофайл особой структуры. По сути это папка, которая в графическом интерфейсе отображается как один файл. В частности, приложения — это бандлы.

Бандл PlistFile находится в:

Уязвимость в MacOS High Sierra
Бандл PlistFile — это директория со специальной структурой

Теперь можно загрузить бинарник

в IDA и немного подизассемблировать.

Выполнение метода odm_RecordVerifyPassword начинается с вызова функции без названия (в моем случае это sub_804C) для чтения данных о том юзере, за которого мы пытаемся авторизоваться.

Если аккаунт активен, то функция успешно получает метаданные о нем. Их можно посмотреть, используя консольную команду dscl.

Уязвимость в MacOS High Sierra
Просмотр метаданных активированного пользователя через утилиту dscl

Или посмотреть напрямую, они хранятся в двоичных plist-файлах в папке:

в формате

Поэтому демон и подгружает бандл PlistFile для чтения и парсинга информации из файлов такого типа.

Уязвимость Mac
Метаданные всех пользователей macOS High Sierra в формате plist-файлов

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

Уязвимость Mac
Просмотр метаданных деактивированного пользователя root

При проверке odm_RecordVerifyPassword вернет некорректный результат. Посмотрим на псевдокод условия, в котором выполняется сверка этих данных.

PlistFile.c

Здесь условие перейдет на ветку else. Далее выполнение плавно перетекает в вызов функции od_verify_crypt_password, чтобы сверить переданный пароль пользователя и тот, что хранится в системе. Ее параметры — это * и набранный нами пароль.

Уязвимость Mac
Параметры, которые передаются в функцию od_verify_crypt_password

Функция возвращает 1 в регистре al. Следующая инструкция как раз его проверяет (строка 6309), и выполнение программы продолжается.

CVE-2017-13872
Результат работы od_verify_crypt_password в регистре al
эксплуатация уязвимости mac
Дизассемблированный участок кода с вызовом функции od_verify_crypt_password

Получается, после всех этих проверок система считает, что у пользователя имеется пароль и для его хранения используется устаревшая техника, а так как система заботится о нашей безопасности, то она любезно изменяет тип его хранения в системе. То есть обновляет на securetoken или shadowhash. Да, в логах так и запишется: «found crypt password in user-record — upgrading to shadowhash or securetoken».

CVE-2017-13872
Добавление в лог информации об обновлении пароля
CVE-2017-13872
Информация в журнале о некорректном обращении к атрибутам пользователя и обновлении пароля

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

Эксплуатация уязвимости CVE-2017-13872
Вызов функции обновления пароля пользователя

Теперь мы можем спокойно авторизоваться и гулять с правами суперпользователя.

Выводы

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

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

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

aLLy

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *