В Dropbox нашли уязвимость нулевого дня, патча для которой пока нет

Еще в сентябре текущего года исследователи Decoder и Крис Даниели (Chris Danieli) обнаружили в Dropbox для Windows уязвимость нулевого дня, о чем тут же уведомили разработчиков, и те пообещали подготовить патчи до конца октября. Так как отведенные на исправление проблемы 90 дней уже истекли, а патча по-прежнему нет, специалисты раскрыли информацию о проблеме, хотя пока не стали обнародовать в открытом доступе PoC-эксплоит.

Исследователи объясняют, что проблема связана с механизмом обновления Dropbox, который работает как служба и отвечает за поддержание приложения в актуальном состоянии. Дело в том, что служба dropboxupdate записывает логи в C:\ProgramData\Dropbox\Update\Log, где обычный пользователь также может добавлять, перезаписывать и удалять файлы. Кроме того, учетная запись SYSTEM выполняет вызов SetSecurity для расположенных там файлов, что открывает возможность эксплуатации через hard-ссылки.

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

Для эксплуатации проблемы атакующему придется выяснить имя файла журнала, включая точное время (до миллисекунды) и PID процесса обновления. Однако исследователям удалось обойти это ограничение, использовав инструменты, созданные специалистами Google Poject Zero. Видео, демонстрирующее успешную атаку, можно увидеть ниже.

Как уже было сказано выше, официального патча для этой проблемы пока нет, но разработчики компании Acros Security, создавшие 0Patch, уже выпустили временную «заплатку». Фактически они сочли, что наиболее надежным решением проблемы будет временное отключение ведения логов DropBox Updater. Это никак не сказывается ни на функциональности DropBox, ни на работе процесс обновления, просто журнал остается пустым.

Мария Нефёдова: Блондинка, гик, книжный червь, синефил. Редактор ленты новостей; иногда автор Сцены.

Комментарии (4)

  • Насовсем понятно как все таки выполняется повышение привилегий. Если папка Log содержит только логи, то зачем угадывать имя файла и как это поможет. А если есть возможность просто скопировать вредоносный экзешник в папку, заменив имя на что-то вроде «Dropbox_Updater”, который полом выполниться от «system процесса», то опять же зачем угадывать имя лог файла?

    • Ничего там не выполняется. Апдейтер сохраняет свои логи в этой папке с именем в формате, грубо говоря, "дропбокс-час-минута-секунда-миллисекунда-ПИД.лог", потом на этот файл ставит определенные права. Так вот, создав вместо этого файла жесткую ссылку на любой другой файл мы можем переписать ACL на любом другом файле в системе (так как апдейтер выполняется под SYSTEM). ПИД определить можно, а миллисекунды как бы брутятся, путем создания 1000 жестких ссылок со значением миллисекунд от 000 до 999.

  • Казалось бы, 21 век, а уязвимость такая-же банальная как и раньше ... через стороннюю службу с повышенными привилегиями... Это же классика жанра!

    • Кто же думал, что удастся вычислить время журнала с точностью до миллисекунд и вычислить PID процесса. Ну а далее - классика... )