Как сообщил разработчик в приватном тикете по двум другим (намного более старым) уязвимостям (CVE-2023-52168, CVE-2023-52169), через три месяца после релиза исправлений:
Probably the problem is unknown still. If we open it now, it will increase the risks for possible attacks as I suppose. I suppose it's not so simple to find problem via source code analys, if you don't know what thing to search. Such good description will show the place to search for attack ways.
There are third-party programs for Windows/Linux that use old 7-zip code. Some programs will update their code for new 7-zip soon. But probably it can get big amount of time for some programs to update source code from latest 7-zip.
I think it's more safer not to open it now. There are many projects (that use 7-zip) that have different speed of moving to new code. But main projects will move to new code at some time without any advisories.
What are your purposes related this bug? Why do you want to open right now?
В Windows создание симлинка - привилегированная операция (непонятно, почему)
Не совсем:
Now in Windows 10 Creators Update, a user (with admin rights) can first enable Developer Mode, and then any user on the machine can run the mklink command without elevating a command-line console.
Уязвимость заключается в том, что при распаковке файлов из скачанного архива на них не проставляется метка Mark-of-the-Web. Поэтому запуск распакованного зловреда не будет блокироваться механизмами безопасности Windows. Если помните, в январе была похожая уязвимость CVE-2025-0411. Там проблема была с запуском файлов из интерфейса архиватора, её пофиксили. А в данном случае проблема с полностью распакованными архивами. И эту проблему ИСПРАВЛЯТЬ НЕ БУДУТ! 🤷♂️
Сколько раз эту "уязвимость" (RCE, не иначе) будут переоткрывать в контексте 7-Zip?
Подсказка: Zone.Identifier — необходимый, но не единственный признак того, что файл был загружен из Интернета. Отсутствие вызовов GetStorageDependencyInformation() и GetZoneFromAlternateDataStreamEx() равно уязвимость, в вашей системе координат. И опять почти все архиваторы "уязвимы", как так! А ведь именно проверка и через GetStorageDependencyInformation() реализована для MotW в Windows (кто не понял: так проверяется MotW в смонтированном контейнере VHD/VHDX, признак наследуется от файла-контейнера, даже если внутри у файла нет ADS)!
Загрузка с накопителя в режиме "read-only" может "перепрыгнуть" на исполнение кода с другого накопителя, который в режиме "read-write".
Вот есть, например, CVE-2023-4001 (GRUB пытается исполнить конфигурационный файл с другого накопителя, а если не находит этот файл — выдает шелл: это в текущем виде есть обход пароля на GRUB при наличии физического доступа, но можно "докрутить" и до исполнения кода при наличии локального, привилегированного доступа — если подложить нужный конфигурационный файл на второй накопитель, перечисляемый до загрузочного). И таких сценариев еще много.
Атака "подобная" потому что, описана вами, в этом заключается все подобие?
Нет. Подобие заключается в том, что появление нового накопителя (с контролируемыми атакующим данными), без какого-либо изменения данных на загрузочном накопителе, приводит к выполнению (в процессе загрузки) конфигурационного файла GRUB с нового накопителя (без изменения порядка загрузки, естественно).
Извините, но я с вами не согласен.
Если я могу перезаписать файлы GRUB, убрав из них проверку электронных подписей, то это значит, что я: либо уже имею права суперпользователя в операционной системе атакуемого компьютера, либо уже могу загрузиться на том же компьютере с другого накопителя, либо могу на время отключить накопитель атакуемого компьютера и подключить его к другому компьютеру.
От этого действительно GRUB (и никакой другой загрузчик) не защищает (но можно, например, вынести проверку целостности загрузчика в BIOS/UEFI, да еще и подключить к этому процессу TPM, но это все уже придумано — см. BitLocker, известные атаки на него в конфигурациях с использованием TPM сложнее сценария "давайте поменяем содержимое файла").
А теперь попробуйте реализовать атаку лишь за счет подключения USB-накопителя, как съемного накопителя (и модель угроз — корпоративный ноутбук, работник без прав суперпользователя, невозможность загрузки со стороннего накопителя, установленный датчик вскрытия корпуса или установленная пломба). В случае с GRUB это возможно — никакие файлы на загрузочном накопителе не меняются, но из-за путаницы с идентификаторами что-то может начать исполняться не из того места, откуда ожидалось.
Механизм атаки и модель угроз совершенно другие. У вас атака начинается с того, что злоумышленник модифицирует файлы на незашифрованном томе.
Хотите подобную атаку от 2018 года? Вот, описана в июле (при загрузке с Live USB GRUB выполняет конфигурационный файл с HDD, все из-за "search.file /conf/bootid.txt root").
В каталогах должны также лежать файлы %Реестр%.LOG1 и %Реестр%.LOG2, для корректного парсинга сырых данных.
Целесообразно исследовать два состояния куста реестра: до и после применения логов. С учетом того, что разница между состояниями может составлять час непрерывной работы ОС — без учета спящего режима (т. е. реально разница между состояниями может быть более суток, особенно с ноутбуками).
Можно еще промежуточные состояния добавлять (т. е. применять записи из логов поэтапно и на каждом этапе парсить куст еще раз), но это уже избыточно в большинстве случаев, куда разумнее смотреть еще на теневые копии и в RegBack.
Запуск RECmd для необходимых файлов реестра, который выгружает только необходимые ветки
Попробуйте сделать from yarp import *. Плюс, у вас "открываются" дополнительные метаданные (вроде "этот ключ реестра ничто не открывало с такой-то даты").
"file.name": "(default)",
А чем строка "(default)", полученная из пустой строки (для значения без имени), отличается от строки "(default)" (значение именно с таким именем)?
Посоветовавшись, мы решили, почему нет, скорее всего, SANS явно вне всех этих политических игр.
Еще в 21 году начались проблемы.
Знающие люди поймут, что знать наизусть изменения всех временных меток в NTFS при различных манипуляциях в разных версиях винды – это задачка не из легких. Когда я решала свой тест, я без задней мысли эти вопросы просто смотрела в Windows Forensic Poster.
Если вдруг в постере исправляют ошибки, то как быстро исправляются соответствующие вопросы? ;-)
Куда хуже, если применяются программы типа BitLocker и выполняется полнодисковое шифрование. Сбор криминалистических артефактов затрудняется. Вся надежда на то, что киберпреступник наследил по оплошности. [...] Или же где-то остались незашифрованные диски. Если же такая атака затронула абсолютно все хосты организации, шансы достать артефакты ничтожно малы.
Шифрование, в случае с BitLocker (и с любым подобным FDE-решением: DiskCryptor, BestCrypt и т. п.), часто не доводится до конца, инициированный злоумышленником ребут его обрывает (ведь без ребута машина продолжит работать как обычно, шифрование же прозрачное). Поэтому логи будут, просто нужно знать, как их достать (если часть файловой системы зашифрована, а часть — нет).
В моей практике удается накарвить нужные события из EVTX в большинстве случаев.
Некоторые клиенты просят лишь восстановить зашифрованные файлы, чтобы не платить выкуп. [...] К тому же большинство современных программ-вымогателей работают так, что шифрование необратимо и без приватного ключа с ним не справится даже гений криптографии. Стараемся объяснить это клиенту, а дальше все зависит от его понимания ситуации и приоритетов.
Вам задают вопрос про восстановление, а вы отвечаете про взлом шифрования (алгоритма или его реализации). Вам могу сказать лишь одно: методы восстановления данных работают, долго, дорого и с малой эффективностью, но какой-то положительный результат без уплаты выкупа клиенты чувствуют.
В моей практике была ситуация, когда одной командой Windows клиент смог "провернуть фарш назад" после DiskCryptor, при стандартных входных данных: пароль и ключ неизвестны, шифрование оборвано ребутом, инцидент начал расследоваться после ребута, EDR-телеметрии с хоста нет (т. е. нельзя, например, посмотреть, с какими аргументами что-то запускалось на хосте).
После этого с https://app-ins-001.amscloudhost[.]com:443/dn01 осуществляется загрузка RedCurl.FSABIN, который сохраняется в папку C:\Users[user]\AppData\Local\VirtualStore</code>с именем [...]
Отслеживайте запуск подозрительных файлов из папки C:\Users[user]\AppData\Local через планировщик заданий Windows.
Довольно странный выбор пути. Вот прямо так — с "</code>" в имени директории? И не "\Users\[user]\" даже?
«Имеется ли на накопительной системе (системном блоке) информация о номере банковской карты № XXXX XXXX XXXX XXXX (номер счета XXXXXXXXXXXXXXXXXXXX)?»
«Имеется ли на накопительной системе (системном блоке) информация об абонентском номере X-XXX-XXX-XX-XX?»
Ответы на эти вопросы не требуют цитирования (указания в заключении или записи на прилагаемый носитель) всех обнаруженных данных. По сути, следователю можно дать и ответ "да, информация о номере банковской карты обнаружена, точка", а в исследовательской части указать только одно вхождение.
Объект представлен в чёрном полимерном пакете.
А как эксперт определил, что пакет именно полимерный? Какие исследования проводил для этого? Это, как бы, не общие, а специальные знания уже. И не в той области.
установлено, что настройки даты/времени системной платы СБ соответствуют текущим значениям
Вот прямо так и соответствуют? Обычно отклонения есть, хотя бы секунд 5. Объект все-таки еще в очереди лежит месяц-другой.
Занято, байт
Это значение зависит от версии драйвера NTFS. Наличие в Windows функции Storage Reserve может искусственно занижать объем свободного пространства в томе (даже если это внешний накопитель).
А где подписка эксперта? По ней вообще иногда можно сразу сказать, что эксперт лжет (статью 57 УПК РФ не читал, либо дал подписку после оформления заключения).
Обязательно еще про баг напишите, который "портил" данные в создаваемой копии. Velociraptor используют многие, баг был довольно легко воспроизводимый, но, видимо, его списывали на "это же работающая система, данные могут меняться".
Очень хорошо, что процесс хорошо воспроизводится на данных, на которых он и должен хорошо воспроизводиться. Особенно, когда речь идет об установленных экземплярах операционных систем, на которые не имитировалось воздействие злоумышленника. Или имитировалось, но не тем способом, а гораздо более простым. "Не работает" — это не значит, что у вас ошибка высвечивается, а значит, что сама концепция настолько ужасна, что ее уже и не исправить.
Ведь я говорю о ситуации, когда контроль целостности проходит успешно, но для данных (файлов или значений ключей реестра), не соответствующих "неизменному" ("доверенному", "эталонному") состоянию. Потому что модуль доверенной загрузки "увидел" ожидаемые данные (значение хеш-функции от них совпало с "эталоном"), а операционная система "увидела" другие данные, хотя исходный набор байтов на накопителе был тот же самый (и будет хуже, если "другие данные" — это контролируемые злоумышленником).
Если модификация структур файловых систем и кустов реестра на низком уровне вообще не рассматривается — это не значит, что проблемы нет. Выше уже была ссылка, где про драйвер FAT в Linux: если вы смонтируете специально подготовленный образ файловой системы в режиме "только чтение" (хотя и в режиме "чтение-запись" можно), то в Linux вы увидите директорию с какими-то файлами (и эти файлы могут иметь именно то содержимое, которое вы ожидаете увидеть), а в Windows это будет уже директория без части файлов (или даже без всех файлов). Цена вопроса — модификация одного байта в индексной записи (в Windows этот байт остановит цикл перечисления индексных записей в директории, в Linux — нет, листинг директории продолжится). Не используете Linux, "залатали" эту возможность? Есть еще десятки других.
Все это верно, но делать после этого вывод о том, что предзагрузочный контроль целостности именно поэтому не работает – очень радикально. На краевых случаях – возможны проблемы, но они выявляются и решаются.
Радикально? Нет. Эти граничные случаи — как раз то, на что может целиться атакующий. Если в повседневной жизни они не возникают, то тут возникнуть вполне могут.
А как решать эти проблемы? Писать парсеры файловых систем NTFS и FAT, реестра Windows, которые бы полностью соответствовали реализациям в Windows, включая все граничные случаи? Когда напишете подобное (скажем, потратив на это пять лет работы, ибо нужно досконально изучить в IDA Pro и WinDbg все эти драйверы и подсистемы ядра), "эталонная" реализация уже изменится (ту же реализацию реестра в ядре Windows регулярно перерабатывают, "подбрасывая" новые граничные случаи).
Масштаб проблемы серьезный, сама проблема носит принципиальный характер, поэтому и пишу, что "не работает".
Журнал транзакций той же NTFS в ViPNet SafeBoot контролируется на непустоту – скорее всего, приведенный сценарий не пройдет (хотя он описан очень поверхностно). Да и непонятно, с чем именно поздравляете :).
Журнал NTFS не может быть пустым при обычной работе операционной системы Windows. В нем всегда что-то есть. Контролировать можно незавершенность транзакций, но в данном случае речь шла про журналы реестра (файлы SYSTEM.LOG1, SYSTEM.LOG2 и т. д.).
Файлы реестра тоже можно контролировать на незавершенность транзакций, вот только умеет ли средство доверенной загрузки делать это корректно? Тут проблемы могут начаться и с реализации расчета контрольной суммы заголовка.
А вот здесь противоречие всему написанному выше – “Все животные равны, но некоторые равнее других”? :)
Как сообщил разработчик в приватном тикете по двум другим (намного более старым) уязвимостям (CVE-2023-52168, CVE-2023-52169), через три месяца после релиза исправлений:
Делайте выводы.
Не совсем:
Есть: FILE_FLAG_OPEN_REPARSE_POINT.
Сколько раз эту "уязвимость" (RCE, не иначе) будут переоткрывать в контексте 7-Zip?
Подсказка: Zone.Identifier — необходимый, но не единственный признак того, что файл был загружен из Интернета. Отсутствие вызовов GetStorageDependencyInformation() и GetZoneFromAlternateDataStreamEx() равно уязвимость, в вашей системе координат. И опять почти все архиваторы "уязвимы", как так! А ведь именно проверка и через GetStorageDependencyInformation() реализована для MotW в Windows (кто не понял: так проверяется MotW в смонтированном контейнере VHD/VHDX, признак наследуется от файла-контейнера, даже если внутри у файла нет ADS)!
Гораздо проще: отсортировать файлы по значениям LSN или USN. Они возрастают вне зависимости от показаний системных часов.
Это не так. Flush — это запись в файл транзакции, все.
NtFreezeRegistry. Или создание теневой копии, под капотом там такой же вызов.
https://github.com/msuhanov/regf/blob/master/Windows registry file format specification.md
Загрузка с накопителя в режиме "read-only" может "перепрыгнуть" на исполнение кода с другого накопителя, который в режиме "read-write".
Вот есть, например, CVE-2023-4001 (GRUB пытается исполнить конфигурационный файл с другого накопителя, а если не находит этот файл — выдает шелл: это в текущем виде есть обход пароля на GRUB при наличии физического доступа, но можно "докрутить" и до исполнения кода при наличии локального, привилегированного доступа — если подложить нужный конфигурационный файл на второй накопитель, перечисляемый до загрузочного). И таких сценариев еще много.
Нет. Подобие заключается в том, что появление нового накопителя (с контролируемыми атакующим данными), без какого-либо изменения данных на загрузочном накопителе, приводит к выполнению (в процессе загрузки) конфигурационного файла GRUB с нового накопителя (без изменения порядка загрузки, естественно).
Если я могу перезаписать файлы GRUB, убрав из них проверку электронных подписей, то это значит, что я: либо уже имею права суперпользователя в операционной системе атакуемого компьютера, либо уже могу загрузиться на том же компьютере с другого накопителя, либо могу на время отключить накопитель атакуемого компьютера и подключить его к другому компьютеру.
От этого действительно GRUB (и никакой другой загрузчик) не защищает (но можно, например, вынести проверку целостности загрузчика в BIOS/UEFI, да еще и подключить к этому процессу TPM, но это все уже придумано — см. BitLocker, известные атаки на него в конфигурациях с использованием TPM сложнее сценария "давайте поменяем содержимое файла").
А теперь попробуйте реализовать атаку лишь за счет подключения USB-накопителя, как съемного накопителя (и модель угроз — корпоративный ноутбук, работник без прав суперпользователя, невозможность загрузки со стороннего накопителя, установленный датчик вскрытия корпуса или установленная пломба). В случае с GRUB это возможно — никакие файлы на загрузочном накопителе не меняются, но из-за путаницы с идентификаторами что-то может начать исполняться не из того места, откуда ожидалось.
Механизм атаки и модель угроз совершенно другие. У вас атака начинается с того, что злоумышленник модифицирует файлы на незашифрованном томе.
Хотите подобную атаку от 2018 года? Вот, описана в июле (при загрузке с Live USB GRUB выполняет конфигурационный файл с HDD, все из-за "search.file /conf/bootid.txt root").
Еще парсер реестра Windows в systemd есть.
https://github.com/systemd/systemd/blob/main/src/boot/efi/bcd.c
Целесообразно исследовать два состояния куста реестра: до и после применения логов. С учетом того, что разница между состояниями может составлять час непрерывной работы ОС — без учета спящего режима (т. е. реально разница между состояниями может быть более суток, особенно с ноутбуками).
Можно еще промежуточные состояния добавлять (т. е. применять записи из логов поэтапно и на каждом этапе парсить куст еще раз), но это уже избыточно в большинстве случаев, куда разумнее смотреть еще на теневые копии и в RegBack.
Но зачем? RECmd и Registry Explorer восстанавливают меньше удаленных данных, чем реально есть.
Попробуйте сделать from yarp import *. Плюс, у вас "открываются" дополнительные метаданные (вроде "этот ключ реестра ничто не открывало с такой-то даты").
А чем строка "(default)", полученная из пустой строки (для значения без имени), отличается от строки "(default)" (значение именно с таким именем)?
Еще в 21 году начались проблемы.
Если вдруг в постере исправляют ошибки, то как быстро исправляются соответствующие вопросы? ;-)
Шифрование, в случае с BitLocker (и с любым подобным FDE-решением: DiskCryptor, BestCrypt и т. п.), часто не доводится до конца, инициированный злоумышленником ребут его обрывает (ведь без ребута машина продолжит работать как обычно, шифрование же прозрачное). Поэтому логи будут, просто нужно знать, как их достать (если часть файловой системы зашифрована, а часть — нет).
В моей практике удается накарвить нужные события из EVTX в большинстве случаев.
Вам задают вопрос про восстановление, а вы отвечаете про взлом шифрования (алгоритма или его реализации). Вам могу сказать лишь одно: методы восстановления данных работают, долго, дорого и с малой эффективностью, но какой-то положительный результат без уплаты выкупа клиенты чувствуют.
В моей практике была ситуация, когда одной командой Windows клиент смог "провернуть фарш назад" после DiskCryptor, при стандартных входных данных: пароль и ключ неизвестны, шифрование оборвано ребутом, инцидент начал расследоваться после ребута, EDR-телеметрии с хоста нет (т. е. нельзя, например, посмотреть, с какими аргументами что-то запускалось на хосте).
Довольно странный выбор пути. Вот прямо так — с "</code>" в имени директории? И не "\Users\[user]\" даже?
Теперь так:
А где "\" между "Users" и "%имя_пользователя%"?
Этот шаблон пути не очень соответствует примеру, что указан ниже.
Ответы на эти вопросы не требуют цитирования (указания в заключении или записи на прилагаемый носитель) всех обнаруженных данных. По сути, следователю можно дать и ответ "да, информация о номере банковской карты обнаружена, точка", а в исследовательской части указать только одно вхождение.
А как эксперт определил, что пакет именно полимерный? Какие исследования проводил для этого? Это, как бы, не общие, а специальные знания уже. И не в той области.
Вот прямо так и соответствуют? Обычно отклонения есть, хотя бы секунд 5. Объект все-таки еще в очереди лежит месяц-другой.
Это значение зависит от версии драйвера NTFS. Наличие в Windows функции Storage Reserve может искусственно занижать объем свободного пространства в томе (даже если это внешний накопитель).
А где подписка эксперта? По ней вообще иногда можно сразу сказать, что эксперт лжет (статью 57 УПК РФ не читал, либо дал подписку после оформления заключения).
Обязательно еще про баг напишите, который "портил" данные в создаваемой копии. Velociraptor используют многие, баг был довольно легко воспроизводимый, но, видимо, его списывали на "это же работающая система, данные могут меняться".
Заблуждения программистов об именах.
Очень хорошо, что процесс хорошо воспроизводится на данных, на которых он и должен хорошо воспроизводиться. Особенно, когда речь идет об установленных экземплярах операционных систем, на которые не имитировалось воздействие злоумышленника. Или имитировалось, но не тем способом, а гораздо более простым. "Не работает" — это не значит, что у вас ошибка высвечивается, а значит, что сама концепция настолько ужасна, что ее уже и не исправить.
Ведь я говорю о ситуации, когда контроль целостности проходит успешно, но для данных (файлов или значений ключей реестра), не соответствующих "неизменному" ("доверенному", "эталонному") состоянию. Потому что модуль доверенной загрузки "увидел" ожидаемые данные (значение хеш-функции от них совпало с "эталоном"), а операционная система "увидела" другие данные, хотя исходный набор байтов на накопителе был тот же самый (и будет хуже, если "другие данные" — это контролируемые злоумышленником).
Если модификация структур файловых систем и кустов реестра на низком уровне вообще не рассматривается — это не значит, что проблемы нет. Выше уже была ссылка, где про драйвер FAT в Linux: если вы смонтируете специально подготовленный образ файловой системы в режиме "только чтение" (хотя и в режиме "чтение-запись" можно), то в Linux вы увидите директорию с какими-то файлами (и эти файлы могут иметь именно то содержимое, которое вы ожидаете увидеть), а в Windows это будет уже директория без части файлов (или даже без всех файлов). Цена вопроса — модификация одного байта в индексной записи (в Windows этот байт остановит цикл перечисления индексных записей в директории, в Linux — нет, листинг директории продолжится). Не используете Linux, "залатали" эту возможность? Есть еще десятки других.
Радикально? Нет. Эти граничные случаи — как раз то, на что может целиться атакующий. Если в повседневной жизни они не возникают, то тут возникнуть вполне могут.
А как решать эти проблемы? Писать парсеры файловых систем NTFS и FAT, реестра Windows, которые бы полностью соответствовали реализациям в Windows, включая все граничные случаи? Когда напишете подобное (скажем, потратив на это пять лет работы, ибо нужно досконально изучить в IDA Pro и WinDbg все эти драйверы и подсистемы ядра), "эталонная" реализация уже изменится (ту же реализацию реестра в ядре Windows регулярно перерабатывают, "подбрасывая" новые граничные случаи).
Масштаб проблемы серьезный, сама проблема носит принципиальный характер, поэтому и пишу, что "не работает".
Журнал NTFS не может быть пустым при обычной работе операционной системы Windows. В нем всегда что-то есть. Контролировать можно незавершенность транзакций, но в данном случае речь шла про журналы реестра (файлы SYSTEM.LOG1, SYSTEM.LOG2 и т. д.).
Файлы реестра тоже можно контролировать на незавершенность транзакций, вот только умеет ли средство доверенной загрузки делать это корректно? Тут проблемы могут начаться и с реализации расчета контрольной суммы заголовка.
Здесь про "теплую ламповость" было.