Безопасность в ос windows вызовы api защиты

§ 7.1. Технологии безопасности, реализованные в Windows

Ранее указывалось, что ОС Windows линейки
9x является незащищенной, в отли-

чие от Windows линейки NT, системой. Поэтому
рассмотренный далее материал будет в

основном
посвящен средствам защиты, реализованным
в NT. Но следует отметить, что

некоторые элементы безопасности в
Windows 98 все же были добавлены [4]:

• поддержка защищенных каналов;

• поддержка интеллектуальных карточек
(smart cards);

• встроенная поддержка
API-функций, предназначенных для выполнения операций

шифрования;

• встроенная поддержка алгоритма
Authenticode;

• встроенная поддержка программы
Microsoft Wallet (бумажник Microsoft).

Поддержка защищенных каналов осуществляется с помощью протокола РРТР

(Point to Point Tunneling
Protocol), который позволяет устанавливать безопасное
соеди-

нение с удаленной
сетью даже посредством незащищенной
сети. Такая связь устанавли-

вается с помощью
зашифрованных инкапсулированных пакетов
и обеспечивает возмож-

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

может подключиться
к Internet с помощью протоколов TCP/IP и
установить защищенное

IPX-соединение со своей офисной сетью. Обеспечивается поддержка
SSL 3.0, новой

версии протокола
SSL (Secured Sockets Layer), что повышает
степень безопасности при

обмене данными по сетям Internet и intranet.

Поддержка операций
с интеллектуальными карточками реализована
в виде двух-

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

бор API-функций,
предназначенных для аутентификации,
записи и чтения данных. Ин-

теллектуальные карточки выполняют, по крайней мере, три важные функции:

аутентификацию
пользователей при входе в систему
(вместо паролей или в сочетании с

ними); проведение финансовых операций
по Internet и другим сетям;

хранение информации о человеке, например индивидуальные противопоказания к ле-

карствам или история болезни.

Поддержка
API криптографии, технологии
Authenticode и программы Microsoft

Wallet реализована
в виде модулей, которые инсталлируются
при установке Internet Ex-

plorer.

В табл. 7.1 перечислены возможности
подсистем безопасности, реализованные
в

Windows 95, Windows 98 и Windows NT.

Таблица
7.1

Технология

Windows 95

Windows 98 Windows 2000

Authenticode

PPTP-клиент

Надстройка (IE4) Есть

Надстройка (IE4) Есть

Есть

Есть

PPTP-сервер

Нет

Есть

Есть

Интеллектуальные карточки

API криптографии

Microsoft Wallet

Надстройка (IE4) Есть

Надстройка (IE4) Есть

Надстройка (IE4) Есть

Есть

Есть

Есть

Безопасность на уровне групп

Частично

Частично

Есть

Безопасность на уровне файлов Нет

Нет

Есть

Права и привилегии доступа для

отдельных объектов

Нет

152

Нет

Есть

Как показано в табл. 7.1, Windows NT и Windows 98
имеют много общих техноло-

гий безопасности, в частности технологии,
связанные с Internet. Однако в Windows NT

они реализованы на более высоком уровне.

Хорошим примером
различия между уровнями безопасности
Windows NT и Win-

dows 98 является
доступ к файлам. В Windows 98 (и Windows 95) защита
обеспечивается

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

индивидуальные
права доступа к отдельным файлам. Отчасти
это обусловлено тем, что

в среде Windows 98
существует много различных способов
доступа к файлу: посредст-

вом DOS-прерываний,
функций BIOS, функций Windows API, а также средств
различ-

ных языков
программирования (Pascal, C++ и т.д.). Из-за
такого изобилия возможностей

доступа к файлам
возникает множество «лазеек» в
системе защиты, которые очень слож-

но предусмотреть и устранить, не прерывая
работу текущих приложений [1, 7].

Технологии безопасности реализуются с помощью специального набора
API-

функций,
который называется API безопасности.
Хотя этот набор входит в состав под-

системы Win32
API, он полностью реализован только в
Windows NT. С точки зрения

программистов, это означает, что полная
безопасность может быть обеспечена
лишь в

этой системе. Такой
вывод никого не удивит, ведь всем
известно, что основное преиму-

щество Windows NT перед
Windows 98 — это встроенная разветвленная
система безопас-

ности.

В настоящее время в операционной системе
Windows NT имеется около 80 API-

функций, предназначенных для обеспечения
безопасности (исключая API-функции для

шифрования данных).
Тем не менее API-функции, хотя бы частично
способные работать

в среде Windows
98, можно пересчитать по пальцам. Как правило, со всеми
API-

функциями безопасности системы
Windows NT связаны функции-заглушки, которые

расположены в соответствующих DLL-файлах.
Поэтому приложение, разработанное для

Windows NT, загружается в
среде Windows 98 без ошибок компоновки.
Следовательно,

разрабатывая
приложение для Windows NT, вы самостоятельно
должны определить, ка-

кие из его
возможностей должны использоваться
при работе в среде Windows 98 (если

приложение вообще сможет работать в
этой среде).

Для каких приложений
действительно необходимо обеспечить
безопасность уров-

ня системы Windows
NT? Первоочередными кандидатами являются
программы, выпол-

няемые на
сервере.
Кроме того, безопасность на уровне
Windows NT необходима при-

ложениям, имеющим доступ к собственным защищенным объектам
(совместно

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

приложений, применяемых в
качестве сервисов.

Для предотвращения операции несанкционированного доступа к определенным

возможностям приложения или к определенным
разделам базы данных, программисту

необходимо самостоятельно организовывать
специальную проверку безопасности про-

граммы в следующей последовательности
[1].

• Подготовка
списка всех информационных объектов
и/или операций, доступ к кото-

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

• Разработка логической схемы специальных прав и привилегий доступа, которые

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

плуатирующим вашу программу.

• Задание в своей
программе проверки безопасности везде,
где осуществляется доступ

к защищенным объектам или операциям.

• Ограничение доступа к защищенным объектам извне
(например, с помощью стан-

дартных функций
доступа к файлам). Обычно это достигается
путем установки атри-

бута доступа к
объекту «Только для администратора»
и запуска приложения с приви-

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

153

Система безопасности в
Windows NT основана на модели безопасности
для
каж-

дого
пользователя.
При выполнении всех операций, которые
активизируются пользова-

телем после входа
в систему (запуск приложений, доступ к
принтерам и дискам, откры-

тие и закрытие файлов), производится проверка того, обладает ли пользователь

соответствующими правами и привилегиями
[1, 7].

API-функции безопасности в
Windows NT предоставляют возможность регистри-

ровать
события на системном уровне и на
уровне приложений. Это позволяет опреде-

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

зователь вошел на защищенный сервер, ему автоматически присваивается маркер

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

Windows
NT. С другой стороны, каждому
системному объекту соответствует
дескрип-

тор
безопасности
(security descriptor — SD), который содержит различную
информацию,

связанную с
безопасностью данного объекта. С помощью
маркера доступа и дескрипто-

ра безопасности
система защиты Windows NT проверяет при
обращении к объекту, име-

ет ли пользователь право работать с
данным объектом.

В Windows NT встроенные
средства безопасности реализованы
только для объек-

тов ядра операционной
системы (подсистема Kernel). Поэтому,
создавая такие объекты,

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

торы окон, вы не
должны принимать меры по обеспечению
их защиты (с помощью API-

функций безопасности).
Но при создании или обращении к
объектам ядра (файлы, пап-

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

ты, разделы реестра,
консольные устройства и принтеры)
необходимо предоставлять, по

крайней мере,
дескриптор безопасности (или указывать
вместо соответствующего пара-

метра значение NULL).

В среде
Win32 постоянно приходится сталкиваться с
API-функциями, предназна-

ченными для
манипулирования объектами ядра. Эти
функции в качестве аргумента все-

гда принимают указатель на структуру
SECURITY_ATTRIBUTES. Подобные функции

мы уже рассматривали ранее,
например при создании потоков и процессов,
например

CreateThread().

HANDLE CreateThread (

LPSECURITY_ATTRIBUTES lpThreadAttributes,// привилегии
доступа

DWORD dwStackSize,

// по умолчанию равен 0

LPTHREAD_START_ROUTINE lpStartAddress, // указатель на
стартовую

// функцию

LPVOID lpParameter,

DWORD dwCreationFlags,

LPDWORD lpThreadId );

// значение, передаваемое

// функции

// активное состояние или

//состояние ожидания

// здесь система возвращает

// идентификатор потока

Чаще всего программист применяет данную функцию, просто задав значение

NULL в качестве аргумента
lpSecurityAttributes. Такой подход является удачным при

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

дании значения
NULL используется набор параметров структуры
SECURI-

TY_ATTRIBUTES, который задан по умолчанию.

Если необходимо
нечто большее, чем атрибуты, заданные
по умолчанию посредст-

вом значения NULL
для структуры SECURITY_ATTRIBUTES, нужно вручную
сформи-

ровать эту структуру.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

00c04fc297eb, реализованный в библиотеке psbase.dll.

Настройка шифрования осуществляется изменением соответствующего значения в ключе реестра

HKLM/Software/Microsoft/Cryptography/Protect/Providers/%GUID%

Где %GUID% является уникальным идентификатором поставщика услуг. По умолчанию ключ с настройками DPAPI соответствует

HKLM/Software/Microsoft/Cryptography/Protect/Providers/df9d8cd0-1501-11d1-8c7a-00c04fc297eb

Доступ для изменения этой ветки реестра имеют только пользователи с правами Администратора. Ниже даны описания некоторых значений этого ключа.

Значение:   MasterKeyIterationCount
Тип данных: REG_DWORD
Описание:   Счетчик итераций в функции PBKDF2, не может быть меньше, чем значение, установленное
            по-умолчанию. Алгоритм генерации ключа используется в шифровании Мастер Ключа и
            истории паролей пользователя.

Значение:   MasterKeyLegacyCompliance
Тип данных: REG_DWORD
Описание:   Установка этого значения в 1 включает режим совместимости с Windows 2000 во время
            резервирования и восстановления Мастер Ключей.

Значение:   MasterKeyLegacyNt4Domain
Тип данных: REG_DWORD
Описание:   Поскольку резервирование и восстановление DPAPI не поддерживается в Windows NT4,
            установите параметр MasterKeyLegacyNt4Domain в 1, чтобы использовать режим
            совместимости с Windows 2000 и избежания потери данных во время резервирования/
            восстановления.

Значение:   DistributeBackupKey
Тип данных: REG_DWORD
Описание:   Ключ, отвечающий за совместимость при резервировании и восстановлении ключа домена.
            Например, если уровень функционирования домена установлен как Windows 2000.

Значение:   Recovery Version
Тип данных: REG_DWORD
Описание:   Параметр, используемый для совместимости при создании резервных копий и восстановлении
            локальных копий Мастер Ключей. По умолчанию используется версия 2, Windows 7 и Windows
            Server 2008 R2 могут быть настроены для работы в версии 3, путем установки этого DWORD
            значения реестра в 3.

Значение:   ProtectionPolicy
Тип данных: REG_DWORD
Описание:   Флаг политики безопасности, используемый по умолчанию. Соответствует флагу dwPolicy в
            заголовке Мастер Ключа.

Значение:   Encr Alg, Encr Alg Key Size
Тип данных: REG_DWORD
Описание:   Пара значений, манипулирующих типом алгоритма шифрования, который применяется в DPAPI,
            и размером ключа этого алгоритма.

Значение:   MAC Alg, MAC Alg Key Size
Тип данных: REG_DWORD
Описание:   Ключи для установки алгоритма контроля целостности данных в DPAPI.

Описание функций CryptProtectData и CryptUnprotectData

Параметры этих функций практически одинаковы, поэтому рассмотрим только CryptProtectData, декларация которой для C++ выглядит следующим образом:

BOOL WINAPI CryptProtectData(
  __in      DATA_BLOB *pDataIn,
  __in      LPCWSTR szDataDescr,
  __in      DATA_BLOB *pOptionalEntropy,
  __in      PVOID pvReserved,
  __in_opt  CRYPTPROTECT_PROMPTSTRUCT *pPromptStruct,
  __in      DWORD dwFlags,
  __out     DATA_BLOB *pDataOut
);

Описание полей функции:

DATA_BLOB *pDataIn	— указатель на структуру DATA_BLOB, ссылающийся на исходные данные, которые необходимо зашифровать.
LPCWSTR szDataDescr	— описатель данных, хранится в открытом виде в DPAPI объекте. Этот опциональный параметр носит информационный характер, его можно не задавать при вызове функции.
DATA_BLOB *pOptionalEntropy	— аналогично предыдущему, является опциональным параметром. Однако в отличие от описателя, энтропия напрямую влияет на безопасность данных, поэтому не хранится в объекте DPAPI. Пользователь сам должен обеспечить надлежащее управление этим секретом. Некоторые сторонние приложения (например, GTalk) хранят этот секрет в реестре, другие компоненты Windows (например, .Net Passport или WININET) в качестве секрета используют жестко прописанную константу, третьи используют переменное значение. Например, встроенный FTP клиент Windows Vista создает энтропию на основе имени сервера. Так или иначе, потенциального взломщика это может, в крайнем случае, позабавить. На наш взгляд, самый удачный пример использования энтропии реализован в механизме хранения паролей Internet Explorer, при котором секрет вообще нигде не хранится.
PVOID pvReserved	— в настоящий момент не используется.
CRYPTPROTECT_PROMPTSTRUCT *pPromptStruct	— структура, задав которую, необходимо будет ввести дополнительный пароль для шифрования объекта DPAPI. Скажем так, используется очень нечасто ввиду того, что запрос пароля происходит в интерактивном режиме.
DWORD dwFlags	— флаги, управляющие процессом шифрования. Вот описание наиболее интересных из них: CRYPTPROTECT_UI_FORBIDDEN (0x1) Используется, когда интерфейс пользователя недоступен. Например, при удаленном доступе. CRYPTPROTECT_LOCAL_MACHINE (0x4) Защита данных происходит с использованием учетной записи локального компьютера. Любой пользователь системы сможет расшифровать их. CRYPTPROTECT_CRED_SYNC (0x8) Позволяет принудительно выполнить синхронизацию паролей. Обычно эта операция автоматически выполняется после смены пароля пользователя. CRYPTPROTECT_AUDIT (0x10) При шифровании/расшифровки будет происходить аудит. CRYPTPROTECT_VERIFY_PROTECTION (0x40) Этот флаг проверяет защиту объекта DPAPI. Если уровень защиты, установленный по умолчанию, выше уровня защиты для данного объекта, функция вернет ошибку CRYPT_I_NEW_PROTECTION_REQUIRED как совет того, что желательно по-новому выполнить защиту исходных данных. CRYPTPROTECT_CRED_REGENERATE (0x80) Регенерация паролей локальной машины. CRYPTPROTECT_SYSTEM (x20000000) Индикатор того, что только системные процессы смогут выполнить шифрование/расшифровку данных.
DATA_BLOB *pDataOut	— объект DPAPI, который получается в результате вызова функции

Пример использования CryptProtectData/ CryptUnprotectData

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

Исходный код программы CryptProtectData

// CryptProtectData.cpp : Defines the entry point for the console application.
#include "stdafx.h"
#include <windows.h>
#include <stdio.h>
#pragma comment (lib, "Crypt32")
int _tmain(int argc, _TCHAR* argv[])
{
     	if ( argc<3 || argc>5 )
     	{
     		_tprintf(TEXT("Syntax: %s secret output_filename [entropy_string] [flags]n"),argv[0]);
		return 1;
     	}
          	//Declare variables
     	DATA_BLOB DataIn;
     	DATA_BLOB DataOut;
     	DATA_BLOB DataEntropy;
     	DWORD dwFlags;
     	LPTSTR pFoo;
          	//Initialize the structure
     	DataOut.pbData=NULL;
     	DataOut.cbData=0;
     	//
     	DataIn.pbData=(LPBYTE)(argv[1]);
     	DataIn.cbData=(lstrlen(argv[1])+1) * sizeof(TCHAR) ;
     	//
     	if ( argc>=4 )
     	{
     		DataEntropy.pbData=(LPBYTE)(argv[3]);
     		DataEntropy.cbData=(lstrlen(argv[3])+1) * sizeof(TCHAR) ;
     	}
     	//
     	if ( argc==5 )
     		dwFlags=_tcstoul(argv[4],&pFoo,10);
     	else
     		dwFlags=0;
          	//Protect the secret
     	if ( !CryptProtectData(
     		&DataIn,
     		TEXT("CryptProtectData by Passcape Software"),	//description string to be included
     		argc>=4?&DataEntropy:NULL,			//Optional entropy
     		NULL,						//reserved
     		NULL,						//prompt structure, not used
     		dwFlags,					//flags
     		&DataOut) )
     	{
     		dwFlags=GetLastError();
     		_tprintf(TEXT("CryptProtectData failed with the following error code: %lun"),dwFlags);
     		exit(1); 
     	}
          	//save the output blob
     	FILE *f=NULL;
     	_tfopen_s(&f,argv[2],TEXT("wb"));
     	if ( !f )
     	{
     		if ( DataOut.pbData )
     		{
     			LocalFree(DataOut.pbData);
     			DataOut.pbData=NULL;
     		}
     		_tprintf(TEXT("Can't open output file for writingn"));
     		exit(2); 
     	}
          	//write
     	if ( DataOut.pbData )
     	{
     		size_t written=fwrite(DataOut.pbData,DataOut.cbData,1,f);
     		LocalFree(DataOut.pbData);
     		DataOut.pbData=NULL;
     		if ( written!=1 )
     		{
     			_tprintf(TEXT("Can't write %lu bytes to output filen"),DataOut.cbData);
     			exit(3);
     		}
     	}
          	fclose(f);
     	return 0;
}

Шифрование данных в DPAPI

Шифрование персональных данных пользователя в DPAPI происходит в три этапа:

1. Первоначально приложение вызывает функцию CryptProtectData, указывая исходный материал для защиты и необязательный параметр энтропии. Если последний не задан, любая другая программа в контексте текущего пользователя может выполнить обратную расшифровку, получив физический доступ к объекту DPAPI.
2. Функция CryptProtectData относится к семейству CryptoAPI и находится в Crypt32.dll, откуда запрос на дальнейшую обработку через защищенный RPC канал перенаправляется в системный процесс Local Security Authority (LSA), и переходит смена контекста текущего пользователя на системный. Все дальнейшие манипуляции производятся в контексте локальной системы.
3. В LSA происходит сам процесс шифрования данных и отправка их обратно по каналу RPC в Crypt32.dll, откуда они благополучно возвращаются в исходное приложение.

CryptProtectData и CryptUnprotectData по сути являются простыми функциями-обертками, т.к. реальное шифрование данных протекает в контексте системы. Вся магия DPAPI происходит в LSA и скрыта от глаз сторонних наблюдателей.

Процесс шифрования долгий и скучный, напоминает супружеский долг после 20 лет совместного проживания. Вначале из пароля пользователя при помощи криптографического стандарта PBKDB2 получается ключ шифрования Мастер Ключа. Этот ключ шифрования используется для расшифровки Мастер Ключа. Если расшифровка прошла неудачно, пароль пользователя расшифровывает первый хэш истории паролей CREDHIST, из которого в свою очередь опять получается ключ шифрования Мастер Ключа и делается очередная попытка расшифровки. Если и она потерпела неудачу, расшифровывается следующий хэш истории паролей. Операция повторяется до тех пор, пока Mастер Kлюч не будет расшифрован, либо не закончится вся цепочка хэшей истории.

Чтобы не спрашивать пароль каждый раз при вызове CryptProtectData / CryptUnprotectData, Windows кэширует его, храня в недрах LSA на протяжении всей жизни профиля пользователя. Вот почему DPAPI работает исключительно в режиме онлайн, только после входа пользователя в систему.

В 2005 году Passcape Software впервые представила работающий в своих продуктах алгоритм, имитирующий офлайн работу DPAPI. Иными словами, для расшифровки DPAPI объектов не нужна загрузка контекста пользователя, хотя наличие пароля – обязательно. Офлайн расшифровка DPAPI нисколько не делает эту систему более уязвимой, в тоже время, оставаясь полезной исследователям, экспертам и криминалистам.

Итак, Мастер Ключ пользователя находится в специальном файле-контейнере, в котором могут храниться дополнительные, резервные копии Мастер Ключа. Резервная копия Мастер Ключа используется в том случае, если основная копия по той или иной причине не была расшифрована. Например, после принудительного сброса пароля. Мастер Ключ является критическим элементом в криптографии DPAPI, поэтому его длина составляет 512 бит, и при его шифровании применяются проверенные алгоритмы. Смотрите таблицу 1.

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

После того, как Мастер Ключ успешно декодирован, его исходный 512-битный материал участвует в получении симметричного ключа шифрования объекта DPAPI. Для этого Мастер Ключ «перемешивается» со случайными данными (которые будут потом храниться в DPAPI объекте) и энтропией, если она задана. Таким образом, достигается тройная уникальность, если можно так выразиться, ключа шифрования для каждого объекта DPAPI.

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

Кстати, немногие знают, что в первых версиях Windows 7 имели место быть серьезные проблемы с шифрованием AES. Попросту говоря, этот тип шифрования не работал вообще. К счастью, проблему быстро устранили.

После того, как данные зашифрованы, они группируются в единую структуру вместе с остальной служебной информацией и отправляются назад приложению в виде объекта DPAPI. Структура объекта DPAPI недокументирована, но исследователям из Passcape удалось полностью ее реверсить (смотрите рис. 3).

 

Рис 3. Недокументированная структура двоичного объекта DPAPI.

Что такое Мастер Ключ DPAPI

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

 

Рис 4. Структура Мастер Ключа

Структура Мастер Ключа

Как показано на рисунке 4, файл с Мастер Ключом состоит из 5 частей:

1. Заголовок и служебная информация
2. Мастер Ключ пользователя
3. Ключ шифрования локальной резервной копии
4. Уникальный идентификатор файла CREDHIST
5. Резервная копия Мастер Ключа домена

В Windows 2000 вместо идентификатора CREDHIST, могла храниться резервная локальная копия Мастер Ключа. Именно это делало систему DPAPI чрезвычайно уязвимой. Например, программа Windows Password Recovery может расшифровывать Мастер Ключ из его локальной резервной копии, для этого не требуется знание пароля пользователя.

В заголовке файла с Мастер Ключом находится следующая информация (приведен синтаксис C++, ниже дано описание каждого поля):

typedef struct _tagMasterKey
{
	DWORD dwVersion;
	DWORD dwReserved1;
	DWORD dwReserved2;
	WCHAR szGuid[0x24];
	DWORD dwUnused1;
	DWORD dwUnused2;
	DWORD dwPolicy;
	DWORD dwUserKeySize;
	DWORD dwLocalEncKeySize;
	DWORD dwLocalKeySize;
	DWORD dwDomainKeySize;
} MASTERKEY, *PMASTERKEY;

DWORD dwVersion	— версия файла с Мастер Ключом, используемая для проверки совместимости. В Windows 2000 значение этого поля было равно 1, для остальных операционных систем – 2.
WCHAR szGuid[0x24]	— строковое значение с уникальным идентификатором Мастер Ключа, обычно совпадающим с именем файла. Любой объект DPAPI хранит этот идентификатор, привязывающий его к определенному (и только одному) Мастер Ключу.
DWORD dwPolicy	— поле с различными флагами. Например, если установлен бит 3 в этом поле, то для создания ключа расшифровки Мастер Ключа (из пароля пользователя) будет применен алгоритм SHA1. В Windows 2000 этот флаг всегда сброшен, т.е. используется NTLM хэш.
DWORD dwUserKeySize	— содержит размер Мастер Ключа пользователя
DWORD dwLocalEncKeySize	— размер ключа шифрования резервных копий
DWORD dwLocalKeySize	— размер локального резервного ключа или поля с CREDHIST GUID
DWORD dwDomainKeySize	— резервная копия Мастер Ключа домена

После заголовка последовательно идут 4 слота с Мастер Ключами. Каждый слот содержит свой собственный заголовок и непосредственно сам ключ.

Структура заголовка общая для всех слотов. Для версии 1 (Windows 2000) она выглядит следующим образом:

typedef struct _tagMasterKey1Base
{
	DWORD dwVersion;
	BYTE pSalt[0x10];
	BYTE pKey[];
} MASTERKEY1BASE, *PMASTERKEY1BASE;

В остальных версиях ОС, структура дополнена новыми полями:

typedef struct _tagMasterKey2Base
{
	DWORD dwVersion;
	BYTE pSalt[0x10];
	DWORD dwPBKDF2IterationCount;
	ALG_ID HMACAlgId;
	ALG_ID CryptAlgId;
	BYTE pKey[];
} MASTERKEY2BASE, *PMASTERKEY2BASE;

typedef struct _tagMasterKey3Base
{
	DWORD dwVersion;
	GUID guidCredhist;
} MASTERKEY3BASE, *PMASTERKEY3BASE;

Описание полей заголовка слотов:

DWORD dwVersion	—  версия слота
BYTE pSalt[0x10]	—  соль, т.е. набор случайных данных для унификации Мастер Ключа и исключения возможной атаки по радужным таблицам
DWORD dwPBKDF2IterationCount	—  счетчик итераций в алгоритме генерации ключа PBKDF2
ALG_ID HMACAlgId	—  алгоритм проверки целостности данных
ALG_ID CryptAlgId	—  идентификатор алгоритма шифрования слота
BYTE pKey[]	—  зашифрованный Мастер Ключ или данные слота
GUID guidCredhist	—  уникальный идентификатор файла с историей паролей

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

ОС	CryptAlgId	HMACAlgId	dwPBKDF2IterationCount	Скорость подбора (п/с)
Windows2000	RC4	SHA1	1	95000
WindowsXP	3DES	SHA1	4000	76
WindowsVista	3DES	SHA1	24000	12
Windows7	AES256	SHA512	5600	10

Таблица 2. Алгоритмы шифрования Мастер Ключа

Процесс создания нового Мастер Ключа

Рассмотрим подробнее процесс создания и шифрования нового Мастер Ключа пользователя:

• Сначала вызывается API функция RtlGenRandom, возвращающая 64 псевдо-случайно сгенерированных байт. Это и есть исходный материал Мастер Ключа, с помощью которого будут шифроваться объекты DPAPI.
• Исходный материал Мастер Ключа необходимо защитить. Для этого происходит шифрование с использованием пароля на вход пользователя, описателя безопасности (SID) и еще 16 байт случайных данных (т.н. «соль»). Процесс шифрования Мастер Ключа состоит из двух этапов: сначала с помощью функции PBKDF2 (криптографического стандарта, описанного в PKCS #5), из пароля, SID и соли получается ключ. Затем этот ключ используется для получения симметричного ключа шифрования Мастер Ключа. Разные версии Windows, защищают Мастер Ключ по-разному. Если в Windows 2000 по умолчанию применяется криптологический алгоритм RC4, то в Windows XP и Windows 2003 – 3DES, а в Windows Vista и выше – AES256.
• Мастер Ключу присваивается уникальное имя – GUID. Каждый объект DPAPI хранит этот уникальный идентификатор, с которым его связывают теплые дружеские отношения. Иными словами, GUID Мастер Ключа является его «привязкой» к объекту DPAPI.
• Созданный и зашифрованный с помощью пароля пользователя Мастер Ключ вместе с другими служебными данными сохраняется в отдельный файл в папке для хранения Мастер Ключей (Master Key Storage Folder). Master Key Storage Folder – это специальное место на диске, где хранятся и складируются Мастер Ключи. Мастер Ключи пользователя хранятся в каталоге %APPDATA%/Microsoft/Protect/%SID%, где %APPDATA% — каталог Application Data. Например, C:/ Users/ John/ AppData/ Roaming/ Microsoft/ Protect/ S-1-5-21-2893984454-3019278361-1452863341-1003, а %SID% — текстовый описатель безопасности пользователя. В приведенном выше примере это S-1-5-21-2893984454-3019278361-1452863341-1003. Мастер Ключи системы хранятся в каталоге %WINDIR%/System32/Microsoft/Protect и используются для расшифровки DPAPI объектов, защищенных из-под учетной записи локального компьютера. Все DPAPI объекты, во время создания которых в функции CryptProtectData был установлен флаг CRYPTPROTECT_LOCAL_MACHINE, защищены Мастер Ключами системы.
• Создание, шифрование или расшифровка Мастер Ключа может занять очень много времени по меркам операционной системы. Например, в Windows 7 расшифровка Мастер Ключа занимает более 0,1 секунды на современном ПК. Однако внутри DPAPI существует кэширование. Однажды расшифрованный, Мастер Ключ помещается в кэш так, что последующий доступ к нему не требует повторной расшифровки.

Регенерация Мастер Ключей

Если вы откроете Master Key Storage Folder у себя на диске, предварительно разрешив системе показ спрятанных папок и файлов (файлы с Мастер Ключом имеют атрибут Скрытый), то наверняка увидите несколько файлов с Мастер Ключами. Почему несколько? А потому что DPAPI в целях безопасности принудительно создает новый Мастер Ключ примерно каждые 90 дней, поэтому любая учетная запись пользователя имеет, как правило, несколько Мастер Ключей, количество которых зависит от даты создания профиля пользователя.

Период регенерации Мастер Ключа жестко прописан в системе. Подразумевается, что его нельзя изменить. Однако есть одно «Но»… В каталоге с Мастер Ключами находится 18 байтовый файл с именем Preferred, содержащий имя последнего созданного системой Мастер Ключа, а также дату его создания.

Структура файла Preferred

typedef struct _tagPreferredMasterKey
{
	GUID guidMasterKey;
	FILETIME ftCreated;
} PREFERREDMASTERKEY, *PPREFERREDMASTERKEY;

Каждый раз, при вызове одной из функций DPAPI, система проверяет дату создания последнего Мастер Ключа в Preferred и, если прошло более 90 дней, создает новый Мастер Ключ, обновляя при этом и Preferred. Регенерацией Мастер Ключей можно управлять принудительно. Для этого вызовите функцию CryptProtectData с установленным флагом CRYPTPROTECT_CRED_SYNC. Система выполнит перешифровку всех Мастер Ключей и обновит их на диске. Обычно эта операция выполняется после смены пароля пользователя. Для предотвращения необязательного обновления Мастер Ключей в Windows 7 был введен механизм синхронизации Мастер Ключей, о котором будет сказано ниже.

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

Теперь прикиньте самостоятельно, сколько сможет занять времени обработка, допустим, 1000 Мастер Ключей в Windows 7, если на один Мастер Ключ затрачивается более 0.3 секунды. Итак, на наш взгляд, процесс регенерации Мастер Ключей требует небольшой доработки. В идеале, достаточно контроля целостности данных, отсутствие которого является едва ли единственной большой уязвимостью DPAPI, да и уязвимостью это вряд ли можно назвать. В целом, вся система DPAPI очень хорошо сбалансирована и продумана.

Резервирование Мастер Ключей восстановление их из резервных копий

Резервирование Мастер Ключей на ПК, являющихся членами домена

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

Резервирование Мастер Ключей на автономных ПК под руководством Windows XP — Windows 7

Когда речь идет об автономных компьютерах домашних пользователей, DPAPI задействует другой механизм восстановления на основе дискеты сброса паролей. Дискета сброса пароля, которую пользователь может создать в любой момент из панели управления, позволяет восстановить забытый им пароль. Ключевое слово в предыдущем предложении – может. Забота о восстановлении данных целиком лежит на плечах пользователя.

А что будет, если пользователь сменил пароль после того, как была создана дискета сброса пароля? Все будет нормально. Процесс одновременно продуман и прост, как деревенский клозет. При создании дискеты сброса пароля, система создает пару из публичного и 2048 бит приватного ключа шифрования RSA. Текущий пароль пользователя шифруется при помощи публичного ключа и сохраняется в ключе реестре пользователя HKEY_LOCAL_MACHINE/SECURITY/Recovery/%SID% (в Windows XP – Windows Vista), либо в ключе реестра HKEY_LOCAL_MACHINE/C80ED86A-0D28-40dc-B379-BB594E14EA1B (Windows 7). В любом случае, доступ к этим ключам запрещен всем пользователям системы, включая Администраторов. А приватный ключ, который требуется при расшифровке пароля, записывается на дискету. Таким образом, если после создания дискеты сброса пароля, пользователь сменил пароль, его новый пароль шифруется публичным ключом RSA и сохраняется в реестре вместо старого. Поскольку публичный RSA ключ соответствует приватному ключу, хранимому на дискете, то с помощью приватного ключа можно восстановить и вновь созданный, хранящийся в реестре пароль. В одной из последних версий программа Windows Password Recovery может расшифровывать пароль пользователя при наличии дискеты сброса пароля.

Резервирование Мастер Ключей на автономных ПК под руководством Windows 2000

Но система сброса пароля появилась только в Windows XP. А до этого? Действительно, несмотря на то, что в ОС Windows 2000 не было дискеты сброса пароля, на автономных компьютерах также осуществлялось резервное хранение Мастер Ключа пользователя. При этом и сам ключ шифрования и резервная копия Мастер Ключа хранились в одном файле с основным Мастер Ключом (смотрите рисунок 5). Это значит, что любые данные, зашифрованные при помощи DPAPI, могли быть расшифрованы потенциальным злоумышленником БЕЗ знания пароля пользователя (при условии физического доступа к системе). Что можно сказать о первой реализации DPAPI в Windows 2000? “Понять и простить”.

 

Рис 5. Структура файла с Мастер Ключом на ОС Windows 2000

Компания Microsoft настоятельно рекомендует обновить Windows 2000 до более актуальной версии. Однако если у вас имеются веские причины для работы с Win2K, не спешите делать это. Мы расскажем вам, как максимально обезопасить старую добрую Win2K от потенциального компрометирования системы. Для этого рассмотрим алгоритм создания локальной резервной копии Мастер Ключа. Файл с Мастер Ключом в Win2K условно состоит из 5 частей (рис. 5):

1. Заголовок и служебная информация
2. Мастер Ключ пользователя
3. Ключ шифрования локальной резервной копии
4. Локальная резервная копия Мастер Ключа
5. Резервная копия Мастер Ключа домена

Восстановление локальной резервной копии Мастер Ключа пользователя начинается с декодирования ключа шифрования локальной резервной копии. В расшифровке используется пароль учетной записи локального компьютера (да, да, есть и такая), который хранится в LSA секрете с именем DPAPI_SYSTEM. После того, как получен ключ шифрования локальной резервной копии, им расшифровывается локальная резервная копия Мастер Ключа. Все просто, как 1-2-3.

С этой точки зрения, система Win2K более дружелюбна пользователю, поскольку если даже пароль пользователя будет принудительно стерт, DPAPI всегда сможет восстановить Мастер Ключ из локальной резервной копии. Каким путем достигается такая дружелюбность, объяснять, наверное, не надо:

Чтобы частично воспрепятствовать такому безобразию, нужно изменить режим функционирования SYSKEY. Запустите утилиту SYSKEY (нажмите одновременно клавиши WIN + R, введите syskey.exe и нажмите ОК), сменив место хранения SYSKEY. Тогда для того, чтобы расшифровать LSA секрет DPAPI_SYSTEM, потенциальному злоумышленнику необходимо будет знать либо пароль SYSKEY (SYSKEY bootup password), либо иметь дискету загрузки SYSKEY (SYSKEY startup disk).

История паролей DPAPI

Корректное функционирование DPAPI подразумевает хранение всех предыдущих паролей пользователя. Все предыдущие пароли хранятся в виде хэшей в специальном файле-контейнере, который называется CREDHIST и находится в каталоге %APPDATA%/Microsoft/Protect.

Структура CREDHIST

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

typedef struct _tagCREDENTIAL_HISTORY
{
	DWORD dwVersion;
	GUID guidLink;
	DWORD dwNextLinkSize;
	DWORD dwCredLinkType;
	ALG_ID algHash;
	DWORD dwPbkdf2IterationCount;
	DWORD dwSidSize;
	ALG_ID algCrypt;
	DWORD dwShaHashSize;
	DWORD dwNtHashSize;
	BYTE pSalt[0x10];
} CREDENTIAL_HISTORY, *PCREDENTIAL_HISTORY;

   Описание полей структуры:

DWORD dwVersion	—  версия текущего звена цепочки истории паролей
GUID guidLink	—  уникальный идентификатор звена
DWORD dwNextLinkSize	—  размер следующего звена
DWORD dwCredLinkType	—  тип пароля, который используется в расшифровке текущего звена
ALG_ID algHash	—  идентификатор алгоритма хэширования в функции PBKDF2
DWORD dwPbkdf2IterationCount	—  количество итераций в PBKDF2
DWORD dwSidSize	—  размер идентификатора безопасности владельца
ALG_ID algCrypt	— используемый алгоритм шифрования данных
DWORD dwShaHashSize	— размер SHA1 хэша
DWORD dwNtHashSize	— размер NTLM хэша
BYTE pSalt[0x10]	— случайный набор данных, используемый при шифровании
BYTE pSid[]	— SID владельца
BYTE pShaHash[]	— SHA hash
BYTE pNtHash[]	— NTLM hash

На рисунке 6 схематично представлена структура хранения хэшей истории в CREDHIST.

 

Рис 6. Структура файла CREDHIST

Шифрование CREDHIST

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

 

Рис 7. Схема расшифровки хэшей истории паролей DPAPI

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

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

ОС	Алгоритм шифрования	Алгоритм хэширования	Счетчик PBKDF2	Скорость перебора (п/с)
WindowsXP	3DES	SHA1	4000	76
WindowsVista	3DES	SHA1	24000	12
Windows7	AES256	SHA512	5600	10

Таблица 3. Алгоритмы шифрования истории паролей в различных ОС

Недостатки CREDHIST

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

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

Смена пароля пользователя и DPAPI

Смену пароля в Windows условно можно разделить на несколько критических этапов. Вначале происходит проверка валидности старого пароля, проверка нового на соответствие политики безопасности и физическое изменение пароля в базах SAM или NTDS.DIT. На втором этапе, если все прошло удачно, происходит обновление внутреннего кэша паролей. Затем отрабатывает процедура смены пароля в DPAPI. И, наконец, обновляется биометрический пароль текущего пользователя (Windows 7 и выше).

Система DPAPI достаточно умна, чтобы обрабатывать различные сценарии изменения пароля пользователя. Рассмотрим, что происходит при этом в DPAPI. Вот типичные сценарии:

• Обычное изменение пароля пользователя с указанием старого пароля (автономные ПК под руководством Windows XP — Windows 7)
• Сброс или перезаписывание пароля, например, администратором, без указания старого (автономные ПК под руководством Windows XP — Windows 7)
• Сброс пароля пользователя домена (Windows 2000-2008)
• Сброс пароля пользователя автономного ПК в Windows 2000

Обычная смена пароля

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

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

Перешифровка всех Мастер Ключей может занять очень много времени, поэтому она выполняется в отдельном потоке внутри LSA. В Windows 7 был также добавлен интересный механизм синхронизации Мастер Ключей: DPAPI хэширует все Мастер Ключи в профиле пользователя и записывает полученный в результате этого процесса хэш в файл SYNCHIST. В следующий раз, чтобы определить, были ли произведены к.л. изменения, DPAPI снова хэширует всю пачку Мастер Ключей и сравнивает полученный хэш с тем, что хранится в SYNCHIST, предотвращая таким образом ненужную и времязатратную операцию повторной перешифровки.

Предвосхищает операцию синхронизации Мастер Ключей обновление файла CREDHIST. Старый хэш пароля пользователя шифруется новым и помещается в начало цепочки истории хэшей в CREDHIST. Если история паролей пустая, то создается первое звено в цепи хэшей.

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

Сброс пароля на автономных ПК (Windows XP — Windows 7)

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

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

Восстановить полноценный доступ к системе (после принудительного сброса пароля) можно только при помощи ранее созданной дискеты сброса пароля.

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

Принудительный сброс пароля пользователя домена

Если DPAPI используется в среде Active Directory (Windows 2000-2008), Мастер Ключи хранят две свои копии. Первая копия защищена текущим паролем пользователя, а вторая зашифрована публичным RSA ключом, принадлежащим контроллеру домена.

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

Сброс пароля на автономном ПК под управлением Windows 2000

На автономных компьютерах с установленной Win2K, дискета сброса пароля не используется. В файле с Мастер Ключом находятся две копии. Первая зашифрована при помощи пароля пользователя, а вторая c помощью LSA секрета DPAPI_SYSTEM, хранящегося в реестре и доступного только системной учетной записи.

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

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

Восстановление данных из объектов DPAPI

Набор утилит в программе Windows Password Recovery для работы с DPAPI впервые предоставляет широкие возможности в восстановлении данных, зашифрованных при помощи DPAPI, в режиме офлайн, т.е. без загрузки профиля пользователя. Ниже описаны типичные сценарии работы с программой при восстановлении паролей.

Поиск DPAPI объектов на диске

DPAPI объекты в Windows могут храниться где угодно: в двоичных и текстовых файлах, в базах данных, реестре, Active Directory и т.д. Перед тем, как приступить к расшифровке объекта DPAPI, его необходимо «вытащить» и привести в надлежащий вид. Для этого нам понадобится утилита поиска объектов DPAPI на диске.

Запускаем утилиту и выбираем исходный каталог, в котором будет происводиться поиск (рисунок 8). Допустим, пусть исходным каталогом будет C:/ProgramData/Microsoft/Wlansvc. В нем находятся пароли соединений беспроводной сети Windows 7.

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

Обнаруженные объекты DPAPI будут сохранены в целевой каталог под соответствующими именами. Например, если программа обнаружила DPAPI объект в файле xxx.xml, он будет приведен в двоичный вид и сохранен в целевом каталоге под именем xxx.xml.001. Если в файле yyy.xml обнаружится два объекта, они будут записаны под именами yyy.xml.002 и yyy.xml.003.

 

Рис 8. Поиск паролей WiFi

Поиск DPAPI объектов в реестре и Active Directory

Поиск DPAPI объектов на диске не представляет особого труда. Но как быть, если необходимо просканировать реестр текущего пользователя или базу данных Active Directory? Ведь доступ к этим файлам запрещен всем, даже администраторам.

Затруднительно, но к счастью, не невозможно. В этом нам пригодится инструмент для резервного копирования реестра и Active Directory, работа с которым не представляет особого труда даже начинающим пользователям.

Запустив его, выбираем куда и что именно нам нужно зарезервировать: реестр или Active Directory. Учтите, обработка базы данных Active Directory может занять много времени. Теперь можно переходить к утилите поиска DPAPI объектов с указанием пути к каталогу, в котором были сохранены реестр или база ntds.dit.

Восстановление паролей соединений беспроводной сети

Расшифровке паролей беспроводной сети предшествует поиск соответствующих объектов DPAPI в каталоге C:/ProgramData/Microsoft/Wlansvc, описанный выше. Поэтому опустим здесь его повторное описание.

Запускаем утилиту расшифровки DPAPI и указываем путь к извлеченному объекту DPAPI. Пароли беспроводных соединений защищены при помощи флага CRYPTPROTECT_LOCAL_MACHINE, поэтому для их восстановления потребуется системный Мастер Ключ из каталога C:/Windows/System32/Microsoft/Protect/S-1-5-18/User.

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

После перехода к третьему шагу мастера программы отмечаем, что пароль пользователя не нужен. Вместо него нам понадобятся два файла реестра: SYSTEM и SECURITY. Что ж, указываем и их. Учтите, текущие файлы реестра необходимо предварительно разблокировать (т.е. выполнить их резервное копирование). В поле с SID пользователя программа автоматически подставляет SID системы: S-1-5-18. Оставляем это поле и завершаем расшифровку, получив оригинальный текстовый пароль беспроводной сети Windows 7.

Просто? Тогда идем дальше.

Восстановление пароля Facebook, сохраненного в Internet Explorer

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

Пароли автозаполнения IE хранятся в ветке реестра HKEY_CURRENT_USER/Software/Microsoft/Internet Explorer/IntelliForms/Storage2. Запускаем Regedit и открываем эту ветку. Там вы наверняка увидите несколько двоичных записей. Нам нужна только одна из них с именем F6FFE33B9EF4D7CB8F5A2F41F3222D21E131ED787A.

Если такой записи у вас нет, попробуйте создать тестовый пароль на Facebook: откройте страницу http://www.facebook.com/ (обязательно с www), введите любой адрес электронной почты, тестовый пароль и нажмите кнопку войти (рисунок 9). После того, как Internet Explorer любезно предложит сохранить новый пароль, согласитесь. Естественно, сайт Facebook выдаст ошибку, но это уже неважно – пароль был сохранен.

 

Рис 9. Создание тестового пароля Facebook

Переключитесь обратно на regedit и нажмите F5, чтобы обновить данные. В ключе реестра с паролями Internet Explorer должна появиться новая запись с именем F6FFE33B9EF4D7CB8F5A2F41F3222D21E131ED787A. Такое интересное название есть не что иное, как SHA хэш названия сайта.

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

REG QUERY «HKCU/Software/Microsoft/Internet Explorer/IntelliForms/Storage2» /v F6FFE33B9EF4D7CB8F5A2F41F3222D21E131ED787A > c:/test/fb.txt

Кавычки обязательны! Наш пароль будет сохранен в ASCII виде в каталог c:/test, Можете задать любой другой, не суть важно. Теперь, все, что нам осталось, это вытащить из ASCII файла fb.txt интересуемый нас двоичный объект DPAPI.

Запускаем утилиту поиска, указываем исходный каталог c:/test, устанавливаем опцию поиска в текстовых файлах и получаем на выходе двоичный файл fb.txt.001. Ну наконец можно приступить непосредственно к восстановлению пароля.

Открываем соответствующую утилиту и задаем путь к fb.txt.001. На втором шаге указываем Мастер Файл, которым был зашифрован этот объект. Все Мастер Ключи пользователя хранятся в каталоге %AppData%/Roaming/Microsoft/Protect/%SID%. На один уровень выше страдает от своего одиночества файл CREDHIST. Он нам тоже может пригодиться.

Самое интересное начинается при переходе к третьему шагу мастера программы. Для расшифровки пароля Facebook, нам необходимо корректно выставить три параметра: SID пользователя, его пароль на вход и секрет, которым был зашифрован DPAPI объект. SID пользователя программа обычно извлекает сама из пути к Мастер Ключу. Если этого не произошло, вам придется добыть этот параметр самостоятельно (например, путем анализа файла CREDHIST). С паролем на вход пользователя тоже все понятно. А как быть с секретом?

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

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

 

Рис 10. Расшифрованный пароль Facebook

Аналогичным образом, проявив чуточку фантазии, можно восстанавливать пароли Internet Explorer из незагружаемой машины.

Восстановление пароля пользователя без загрузки хэшей SAM/NTDS.DIT

Впервые в мире программа Windows Password Recovery предоставяет возможность восстановления пароля на вход без загрузки хэшей пользователя из SAM или NTDS.DIT. Это стало возможным благодаря тому, что шифрование Мастер Ключа происходит при участии пароля пользователя. Следовательно, Мастер Ключ можно использовать для проверки валидности пароля.

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

Несмотря на свою революционность, восстановление пароля пользователя из Мастер Ключа практической пользы не несет. Например, в Windows 7 проверка паролей идет со скоростью около 10 п/с (рисунок 11). Теоретически, эту скорость можно повысить на пару порядков путем оптимизации алгоритмов шифрования и задействованием GPU при проверке. Но даже после этого, скорость подбора пароля по Мастер Ключу в сравнении с NTLM хэшем будет казаться смехотворной. В плане безопасности, у DPAPI все в порядке.

 

Рис 11. Восстановление пароля пользователя анализом Мастер Ключа DPAPI в Windows Vista

Расшифровка хэшей истории паролей DPAPI

Откройте утилиту дампа истории паролей, указав путь к файлу CREDHIST, который находится в каталоге %AppData%/Roaming/Microsoft/Protect. В случае, если этот файл хранит предыдущие пароли пользователя, то в поле «CREDHIST key chains» должно быть значение, отличное от нуля.

Предыдущие пароли пользователя хранятся в виде SHA1 и NTLM хэшей. В утилите имеется соответствующий переключатель (рисунок 12). Если вы выбрали файл CREDHIST текущего пользователя, пароль на вход вводить не обязательно, программа сама вытащит его из кэша Windows. Для этого просто установите соответствующую опцию. Иначе придется ввести текущий пароль владельца.

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

 

Рис 12. Дамп хэшей истории паролей DPAPI

Заключение

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

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

Первый блин, как известно, всегда комом. Во всех последующих операционных системах, начиная с Windows XP, эти уязвимости были не только устранены, но и вся система DPAPI подверглась серьезной ревизии. В частности, были применены новые алгоритмы шифрования, благодаря которым скорость подбора пароля к Мастер Ключам уменьшилась приблизительно в 1000 (!) раз. Были исправлены ошибки шифрования Мастер Ключей, которые приводили к тому, что любой пользователь мог получить доступ к любым файлам, зашифрованным EFS. Система локального резервирования Мастер Ключей была заменена дискетой сброса пароля и др.

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

Закрепление (Persistence)

Ссылки на все части:
Часть 1. Получение первоначального доступа (Initial Access)
Часть 2. Выполнение (Execution)
Часть 3. Закрепление (Persistence)
Часть 4. Повышение привилегий (Privilege Escalation)
Часть 5. Обход защиты (Defense Evasion)
Часть 6. Получение учетных данных (Credential Access)
Часть 7. Обнаружение (Discovery)
Часть 8. Боковое перемещение (Lateral Movement)

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

Автор не несет ответственности за возможные последствия применения изложенной в статье информации, а также просит прощения за возможные неточности, допущенные в некоторых формулировках и терминах. Публикуемая информация является свободным пересказом содержания MITRE ATT&CK.

Методы обеспечения постоянства в системе можно условно разделить на 3 категории:

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

Далее, представлены техники закрепления доступа, предлагаемые ATT&CK.

Модификация файлов ~/.bash_profile и ~/.bashrc

Система: Linux, macOS
Права: Пользователь, администратор
Описание: Злоумышленники могут вставлять код в файлы ~/.bash_profile и ~/.bashrc (предназначены для создания пользовательской среды в ОС), который будет выполнятся когда пользователь войдёт в систему или запустит новую оболочку. Файл ~/.bash_profile выполняется при входе пользователя в систему, ~/.bashrc выполняется при интерактивном открытии оболочек. Когда пользователь входит в систему (локально или удаленно, например по SSH) с помощью имени пользователя и пароля ~/.bash_profile выполняется до того, как будет возвращено пользовательское приглашение. После этого, каждый раз когда открывается новая оболочка выполняется ~/.bashrc.
В macOS Terminal.app немного отличается тем, что он запускает оболочку входа по умолчанию при каждом открытии окна терминала, тем самым каждый раз вызывая ~/.bash_profile.

Рекомендации по защите: Предоставление прав на изменение файлов ~/.bash_profile и ~/.bashrc только для уполномоченных администраторов.

Модификация исполняемых файлов приложений «специальные возможности Windows» (Accessibility Features)

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

• C:WindowsSystem32sethc.exe — запускается 5-кратным нажатием клавиши Shift;
• C:WindowsSystem32utilman.exe — запускается нажатием комбинации Win+U.

В WinXP и более поздних версиях sethc.exe и utilman.exe могут быть заменены, например, на cmd.exe, впоследствии при нажатии нужной комбинации клавиш cmd.exe запуститься до входа в Windows с привилегиями System.
В Vista и более поздних версиях нужно изменить ключ реестра, который настраивает cmd.exe или другую программу в качестве отладчика, например, для ultiman.exe. После правки реестра и нажатии нужной комбинации клавиш на экране входа в систему или при подключении к хосту по RDP выполнится cmd.exe с правами System.
Есть ещё программы Windows, которые могут использоваться при реализации данной техники атаки:

• C:WindowsSystem32osk.exe;
• C:WindowsSystem32Magnify.exe;
• C:WindowsSystem32Narrator.exe;
• C:WindowsSystem32DisplaySwitch.exe;
• C:WindowsSystem32AtBroker.exe.

Рекомендации по защите: Настройте запуск обязательной сетевой аутентификации удаленных пользователей до создания RDP-сеанса и отображения экрана входа в систему (включено по умолчанию в Windows Vista и более поздних версиях). Используйте Remote Desktop Gateway для управления соединениями и настройкой безопасности RDP.

Модификация ключа AppCert DLLs

Система: Windows
Права: Администратор, System
Описание: Библиотеки DLL, указанные в значении ключа AppCertDLLs загружаются в каждый процесс, который вызывает часто используемые функции API: CreateProcess, CreateProcessAsUser, CreateProcessWithLoginW, CreateProcessWithTokenW, WinExec. Значением ключа AppCertDLLs можно злоупотреблять, вызвав загрузку вредоносной DLL и запустив определенные процессы. AppCertDLLs хранится в следующем разделе реестра:
HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession Manager.

Рекомендации по защите: Применяйте всевозможные средства блокировки потенциально-опасного программного обеспечения и загрузки неизвестных DLL-библиотек, например AppLocker и DeviceGuard.

Модификация ключа AppInit DLLs

Система: Windows
Права: Администратор, System
Описание: DLL-библиотеки, указанные в значении ключа AppInit_DLLs, загружаются в каждый процесс, который загружает user32.dll. На практике, это почти каждая программа.
AppInit_DLLs хранится в следующих разделах реестра:

• HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionWindows;
• HKEY_LOCAL_MACHINESoftwareWow6432NodeMicrosoftWindows NTCurrentVersionWindows.

Значением ключа AppInit_DLLs можно злоупотреблять для превышения привилегий, загружая вредоносные DLL и запуская определенные процессы. Функциональность AppInit_DLLs отключена в Windows 8 и более поздних версиях, когда активирована безопасная загрузка.

Рекомендации по защите: Рассмотрите возможность использования ОС версии не ранее Windows 8 и включения безопасной загрузки. Применяйте всевозможные средства блокировки потенциально-опасного программного обеспечения и загрузки неизвестных DLL-библиотек, например AppLocker и DeviceGuard.

Злоупотребление подсистемой совместимости приложений (Application Shimming)

Система: Windows
Права: Администратор
Описание: Microsoft Windows Application Compatibility Infrastructure/Framework создана для обеспечения совместимости программ с обновлениями Windows и изменениями кода ОС. Система совместимости использует так называемые shim («прокладки») — библиотеки, выступающие в качестве буфера между программой и ОС. С помощью shim-кэша система определяет необходимость использования shim-прокладок (хранятся в виде БД типа .sdb). В файлах .sdb хранятся различные процедуры для перехвата кода приложения, его обработки и дальнейшего перенаправления в ОС. Перечень всех shim-прокладок, установленных установщиком (sdbinst.exe) по умолчанию храниться в:

• %WINDIR%AppPatchsysmain.sdb;
• HKLMSoftwareMicrosoftWindows NTCurrentVersionAppCompatFlagsInstalledSDB.

Кастомные shim-базы хранятся в:

• %WINDIR%AppPatch[64]Custom;
• HKLMSoftwareMicrosoftWindows NTCurrentVersionAppCompatFlagsCustom.

Для обеспечения защиты в пользовательском режиме исключена возможность изменения ядра ОС c помощью shim-прокладок, а для их установки необходимы права администратора. Однако некоторые shim-прокладки могут использоваться для обхода контроля учетных записей (UAC), DLL-инъекций, отключения Data Execution Prevention и Srtucture Exception Handling, а так же перехвата адресов памяти. Использование злоумышленником shim-прокладок позволяет повысить привилегии, установить бэкдоры, отключить защиту ОС, например Защитник Windows.

Рекомендации по защите: Способов предотвращения Application shiming не так много. Отключение совместимости приложений не рекомендуется во избежание проблем со стабильностью работы ОС. Microsoft выпустила KB3045645, которое удалит флаг «auto-elevate» в файле sdbinst.exe для предотвращения использования shim-системы для обхода UAC.

Модификация компонентов Windows Authentication Package

Система: Windows
Права: Администратор
Описание: DLL-библиотеки Windows Authentification Pack загружаются процессом Local Security Authority (LSA) при запуске системы и обеспечивают поддержку нескольких процессов входа в систему и нескольких протоколов безопасности ОС. Злоумышленники могут использовать механизм автозапуска LSA помещая ссылку на двоичный файл в следующий ключ реестра:
HKLMSYSTEMCurrentControlSetControlLsaAuthentication Packages:[целевой бинарник].
[Целевой бинарник] будет запущен системой при загрузке пакетов Authentication Pack.

Рекомендации по защите: В Windows 8.1, Windows Server 2012 R2 и более поздних версиях LSA можно заставить работать как защищенный процесс (PPL) c помощью ключа реестра:
HKLMSYSTEMCurrentControlSetControlLsaRunAsPPL = DWORD:00000001,
который требует, чтобы все DLL, загруженные LSA были подписаны цифровым сертификатом Microsoft.

Создание заданий BITS (BITS Jobs)

Система: Windows
Права: Пользователь, Администратор, System
Описание: Windows Background Intelligent Transfer Service (BITS) — это механизм асинхронной передачи файлов через Component Object Model (COM) с использованием низкой пропускной способности. BITS обычно используется программами обновления, мессенджерами и другими приложениями, предпочитающими работать в фоновом режиме без прерывания работы других сетевых приложений. Задачи по передаче файлов представляются как BITS-задания, которые содержат очередь из одной или нескольких операций с файлами. Интерфейс для создания и управления BITS-заданиями доступен в PowerShell и BITSAdmin tool. Злоумышленники могут использовать BITS для загрузки, запуска и последующей очистки после выполнения вредоносного кода. BITS-задания автономно хранятся в базе данных BITS, при этом в системе не создаются новые файлы или записи в реестре, зачастую BITS разрешен брандмауэром. С помощью BITS-заданий можно закрепиться в системе, создавая длительные задания (по умолчанию 90 дней) или вызывая произвольную программу после завершения BITS-задания или ошибки (в том числе после перезагрузки ОС).

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

• HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsBITSJobInactivityTimeout;
• HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsBITSMaxDownloadTime.

Буткиты (Bootkit)

Система: Linux, Windows
Права: Администратор, система
Описание: Bootkit — это разновидность вредоносного ПО, которое может менять загрузочные секторы жесткого диска, включая Master Boot Record (MBR) и Volume Boot Record (VBR). Злоумышленники могут использовать Bootkit для закрепления в системах на уровне ниже ОС. MBR — раздел ЖД, который загружается сразу после завершения аппаратной инициализации Bios. Злоумышленник, имеющий доступ на перезапись MBR, может заменить код загрузчика ОС на вредоносный. VBR — раздел жесткого диска, который получает управление процессом загрузки от MBR. По аналогии с вариантом перезаписи MBR, злоумышленник может запустить вредоносной код на этапе загрузки системы.

Рекомендации по защите: Использование средств контроля целостности MBR и VBR. Применение Trusted Platform Module (TPM) и безопасной загрузки (Secure Boot).

Расширения браузеров (Browser Extensions)

Система: Windows, Linux, macOS
Права: Пользователь
Описание: Как правило, плагины имеют все доступы и права, которые может получить браузер. Вредоносные плагины могут быть установлены через загрузку вредоносных приложений, замаскированных под законные программы посредством применения техник социальной инженерии, фишинга или злоумышленником, который уже скомпрометировал систему. Вредоносные плагины могут в фоновом режиме открывать веб-сайты, красть информацию, которую пользователь вводит в браузере, включая учетные данные, использоваться как установщики средств удаленного администрирования (RAT) и закрепления в системе.

Рекомендации по защите: Установка плагинов только из надежных источников. Контроль устанавливаемых плагинов с помощью групповой политики. Запрет установки плагинов обычными пользователями. Инвентаризация и мониторинг установленных плагинов.

Модификация параметров ассоциаций файлов (Change Default File Association)

Система: Windows
Права: Пользователь, администратор, system
Описание: Злоумышленники могут изменять ассоциации файлов для запуска произвольных команд. Выбор ассоциации файлов с приложениями храниться в реестре Windows и может быть отредактирован пользователями, администраторами и программами, имеющими доступ к реестру. Приложения могут модифицировать ассоциации для вызова произвольных программ. Параметры системных ассоциаций хранятся в реестре: HKEY_CLASSES_ROOT.[extension], например, HKEY_CLASSES_ROOT.txt. Различные команды перечисляются как подразделы: HKEY_CLASSES_ROOT[handler]shell[action][command], например:

• HKEY_CLASSES_ROOTtxtfileshellopen[command];
• HKEY_CLASSES_ROOTtxtfileshellprint[command];
• HKEY_CLASSES_ROOTtxtfileshellprintto[command];

где [command] — это команда, которая будет выполнена при открытии файла с заданным расширением.

Рекомендации по защите: Следуйте рекомендациям Microsoft в отношении файловых ассоциаций. Применяйте всевозможные средства блокировки потенциально-опасного программного обеспечения, например AppLocker и DeviceGuard.

Прошивка компонентов (Component Firmware)

Система: Windows
Права: System
Описание: Некоторые злоумышленники могут применять сложные средства для компрометации компонентов компьютера и установки на них вредоносной прошивки, которая будет запускать вредоносный код вне операционной системы или даже главной системной прошивки (Bios). Техника заключается в прошивке компонентов компьютера, которые не имеют встроенной системы проверки целостности, например, жестких дисков. Устройство с вредоносной прошивкой может обеспечивать постоянный доступ к атакуемой системе несмотря на сбои и перезапись жесткого диска. Техника рассчитана на преодоление программной защиты и контроля целостности.

Перехват ссылок и связей Component Object Model Hijacking

Система: Windows
Права: Пользователь
Описание: Microsoft Component Object Model (COM) — это технология создания ПО на основе взаимодействующих компонентов объекта, каждый из которых может использоваться во многих программах одновременно. Злоумышленники могут использовать COM для вставки вредоносного кода, который может быть выполнен вместо легитимного через захват COM-ссылок и связей. Для перехвата COM-объекта необходимо заменить в реестре Windows ссылку на легитимный системный компонент. При дальнейшем вызове этого компонента будет выполняться вредоносный код.

Рекомендации по защите: Превентивные меры предотвращения данной атаки не рекомендуются, поскольку COM-объекты являются частью ОС и установленного в системе ПО. Блокировка изменений COM-объектов может влиять на стабильность работы ОС и ПО. Вектор защиты рекомендуется направить на блокирование вредоносного и потенциально-опасного ПО.

Создание учетных записей (Create Account)

Система: Windows, Linux, macOS
Права: Администратор
Описание: Злоумышленники, получившие достаточный доступ могут создавать локальные или доменные учетные записи для дальнейшего закрепления в системе. Сетевые пользовательские команды так же могут использоваться для создания учетных записей.

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

Перехват поиска DLL (DLL Search Order Hijacking)

Система: Windows
Права: Пользователь, Администратор, System
Описание: Техника заключается в эксплуатации уязвимостей алгоритма поиска приложениями файлов DLL, необходимых им для работы (MSA2269637). Зачастую директорией поиска DLL является рабочий каталог программы, поэтому злоумышленники могут подменять исходную DLL на вредоносную с тем же именем файла.
Удаленные атаки на поиск DLL могут проводиться когда программа устанавливает свой текущий каталог в удаленной директории, например, сетевую шару. Также злоумышленники могут напрямую менять способ поиска и загрузки DLL заменяя файлы .manifest или .local, в которых описываются параметры поиска DLL. Если атакуемая программа работает с высоким уровнем привилегий, то подгруженная ею вредоносная DLL также будет выполняться с высокими правами. В этом случае техника может использоваться для повышения привилегий от пользователя до администратора или System.

Рекомендации по защите: Запрет удаленной загрузки DLL (включено по умолчанию в Windows Server 2012+ и доступно с обновлениями для XP+ и Server 2003+). Включение безопасного режима поиска DLL, который ограничит каталоги поиска директориями типа %SYSTEMROOT% до выполнения поиска DLL в текущей директории приложения.
Включение режима безопасного поиска DLL:
Computer Configuration > [Policies] > Administrative Templates > MSS (Legacy): MSS: (SafeDllSearchMode) Enable Safe DLL search mode.
Соответствующий ключ реестра:
HKLMSYSTEMCurrentControlSetControlSession ManagerSafeDLLSearchMode.
Рассмотрите целесообразность аудита защищаемой системы для устранения недостатков DLL с помощью таких инструментов как модуль PowerUP в PowerSploit. Не забывайте про блокировку вредоносного и потенциально-опасного ПО, а так же выполнение рекомендаций Microsoft.

Перехват поиска Dylib (Dylib Hijacking)

Система: macOS
Права: Пользователь
Описание: Техника основана на уязвимостях алгоритмов поиска динамических библиотек dylib в macOS и OS X. Суть заключается в определении dylib, которые подгружает атакуемое приложение и последующем размещении вредоносной версии dylib с тем же именем в рабочей директории приложения. Это приведёт к загрузке приложением dylib, которая размещена в рабочем каталоге программы. При этом вредоносная Dylib будет выполнятся с правами доступа атакуемого приложения.

Рекомендации по защите: Запрет записи пользователями файлов в каталоги поиска dylib. Аудит уязвимостей с помощью Dylib Hijacking Scanner от Objective-See.

Внешние удаленные сервисы (External Remote Services)

Система: Windows
Права: Пользователь
Описание: Злоумышленники могут использовать внешние удаленные сервисы организации, такие как VPN, Citrix и WinRM для закрепления в пределах атакуемой сети. Доступ к сервисам может осуществляться с помощью валидных аккаунтов, полученных с помощью техник перенаправления пользователей на ложные сайты (pharming), или на этапе компрометации сети.

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

Недостатки разрешений на уровне файловой системы (File System Permissions Weakness)

Система: Windows
Права: Пользователь, Администратор
Описание: Суть техники заключается в подмене исполняемых файлов, которые автоматически запускаются различными процессами (например, при загрузке ОС или в определенное время, в случае если права на исполняемые файлы настроены неверно). После подмены вредоносный файл будет запущен с правами процесса, таким образом если процесс имеет более высокий уровень доступа злоумышленник сможет осуществить эскалацию привилегий. В рамках данной техники злоумышленники могут пытаться манипулировать двоичными файлами служб Windows.
Другой вариант атаки связан с недостатками алгоритмов в работе самораспаковывающихся установщиков. В процессе инсталляции ПО, установщики зачастую распаковывают различные полезные файлы, в том числе .dll и .exe, в каталог %TEMP%, при этом они могут не устанавливать соответствующие разрешения для ограничения доступа к распаковываемым файлам, что позволяет злоумышленникам совершать подмену файлов и, как следствие, повысить привилегии или обойти контроль учетных записей, т.к. некоторые установщики выполняются с расширенными правами.

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

• [HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem].

Для автоматического отклонения запросов на повышение привилегий необходимо добавить ключ:

• «ConsentPromptBehaviorUser»=dword:00000000.

Для контроля работы установщиков необходимо добавить ключ:

• «EnableInstallerDetection»=dword:00000001, который будет требовать ввода пароля для установки программ.

Скрытые файлы и папки (Hidden Files and Directories)

Система: Windows, Linux, macOS
Права: Пользователь
Описание: Злоумышленники могут использовать возможность скрытия файлов и папок, чтобы не привлекать внимания пользователей. В Windows пользователи могут скрывать файлы с помощью команды attrib. Достаточно указать атрибут +h <имя файла>, чтобы скрыть файл или «+s», чтобы отметить файл как системный. Добавив параметр «/S» утилита attrib применит изменения рекурсивно. В Linux/Mac пользователи могут скрывать файлы и папки просто указав в начале имени файла символ «.». После этого файлы и папки будут скрыты от приложения Finder и таких как утилита «ls». В macOS файлы могут быть отмечены флагом UF_HIDDEN, который включит запрет на их видимость в Finder.app, но не запретит видеть скрытые файлы в Terminal.app. Многие приложения создают скрытые файлы и папки, чтобы не загромождать рабочее пространство пользователя. Например, утилиты SSH создают скрытую папку .ssh, в которой хранится список известных хостов и ключи пользователя.

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

Перехват вызовов функций Windows API (Hooking)

Система: Windows
Права: Администратор, System
Описание: API функции Windows обычно хранятся в DLL-библиотеках. Техника Hooking заключается в перенаправлении вызовов API-функций посредством:

• Hook-процедур — встроенных в ОС процедур, которые выполняют код при вызове различных событий, например, нажатие клавиш или перемещение мыши;
• Модификации адресной таблицы (IAT), в которой хранятся указатели на API-функции. Это позволит «обмануть» атакуемое приложение, заставив его запустить вредоносную функцию;
• Непосредственного изменения функции (сплайсинг), в ходе которого меняются первые 5 байт функции, вместо которых вставляется переход на вредоносную или иную функцию, определенную злоумышленником.

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

Рекомендации по защите: Перехват событий в ОС является частью нормальной работы системы, поэтому какое либо ограничение данной функциональности может негативно влиять на стабильность работы законных приложений, например антивирусного ПО. Усилия по предотвращению применения техник перехвата необходимо сосредоточить на более ранних этапах цепочки атаки. Обнаружить вредоносную hooking-активность можно с помощью мониторинга вызовов функций SetWindowsHookEx и SetWinEventHook, использования детекторов руткитов, анализа аномального поведения процессов.

Гипервизор (Hypervisor)

Система: Windows
Права: Администратор, System
Описание: Гипервизор может быть скомпрометирован злоумышленником и иметь руткиты, скрытые от гостевых систем.
Рекомендации по защите: Предотвращение доступа злоумышленников к привилегированным учетным записям, необходимым для установки и конфигурирования гипервизора.

IFEO-инъекции (Image File Execution Options Injection)

Система: Windows
Права: Администратор, System
Описание: Механизм Image File Execution Options (IFEO) позволяет запускать вместо программы её отладчик, заранее указанный разработчиком в реестре:

• HKLMSoftwareMicrosoftWindows NTCurrentVersionImage File Execution Options/[executable]
• HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionImage File Execution Options[executable],, где [executable] — это исполняемый двоичный файл отладчика.

Подобно инъекциям, значением [executable] можно злоупотреблять запуская произвольный код, чтобы повысить привилегии или закрепиться в системе. Вредоносные программы могут использовать IFEO на для обхода защиты, регистрируя отладчики, которые перенаправляют и отклоняют различные системные приложения и приложения безопасности.

Рекомендации по защите: Описываемая техника основана на злоупотреблении штатными средствами разработки ОС, поэтому какие-либо ограничения могут вызвать нестабильность работы законного ПО, например, приложений безопасности. Усилия по предотвращению применения техники IFEO-инъекций необходимо сосредоточить на более ранних этапах цепочки атаки. Обнаружить подобную атаку можно с помощью мониторинга процессов с флагами Debug_process и Debug_only_this_process.

Расширения и загружаемые модули ядра (Kernel Modules and Extensions)

Система: Linux, macOS
Права: Root
Описание: Загружаемые модули ядра (LKM) — это специальные программы, которые могут загружаться и выгружаться из ядра без необходимости полной перезагрузки системы. Например, к LKM относятся драйверы устройств. Злоумышленники могут подгружать вредоносные LKM с помощью различных rootkit. Как правило, такие руткиты срывают себя, файлы, процессы, сетевую активность, фальсифицируют журналы аудита, предоставляют бэкдоры. Подобно LKM в macOS существуют так называемые KEXT, которые загружаются и выгружаются командами kextload и kextunload.

Рекомендации по защите: Используйте инструменты обнаружения руткитов в Linux: rkhunter, chrootkit. Ограничивайте доступ к учетной записи root, которая необходима для загрузки модулей в ядро. Применяйте систему принудительного контроля доступа SELinux.

Модификация заголовка LC_LOAD_DYLIB Addition в файлах Mach-O (LC_LOAD_DYLIB Addition)

Система: macOS
Права: Пользователь
Описание: Файлы Mach-O содержат ряд заголовков, которые используются для выполнения определенных операций при загрузке двоичного файла. Заголовок LC_LOAD_DYLIB в бинарниках Mach-O указывает ОС какие dylib-библиотеки нужно подгружать. Изменения заголовков приведут к аннулированию цифровой подписи, однако злоумышленник может удалить из двоичного файла команду LC_CODE_SIGNATURE и система не будет проверять корректность подписи во время его загрузки.

Рекомендации по защите: Все двоичные файлы должны быть подписаны корректными Apple Developer IDs, а белые списки приложений составлены по известным хешам.

Драйверы Local Security Authority (LSASS Driver)

Система: Windows
Права: Администратор, system
Описание: Local Security Authority (LSA) — подсистема Windows, обеспечивающая аутентификацию пользователя. LSA включает несколько динамических взаимосвязанных библиотек DLL, которые выполняются в процессе LSASS.exe. Злоумышленники могут атаковать LSASS.exe путем замены или добавления нелегитимных драйверов LSA с последующим выполнением произвольного кода. Техника реализована во вредоносных программах Pasam и Wingbird, которые «подбрасывают» модифицированные DLL, используемые при загрузке LSASS. При этом вредоносный код выполняется до того, как нелегитимная DLL вызовет сбой и последующее падение службы LSASS.

Рекомендации по защите: В Windows 8.1 и Server 2012 R2 включите защиту LSA путём активации указанного ключа:

• HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaRunAsPPL=dword:00000001.

Эта защита гарантирует, что загружаемые LSA плагины и драйверы будут подписаны цифровой подписью Microsoft. В Windows 10 и Server 16 включите Windows Defender Credential Guard для запуска lsass.exe в изолированной виртуальной среде. В целях снижения риска загрузки в lsass.exe вредоносных библиотек включите режим безопасного поиска DLL:

• HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession ManagerSafeDllSearchMode.

Агенты запуска (Launch Agent)

Система: macOS
Права: Пользователь, администратор
Описание: Техника заключается в злоупотреблении функционалом создания и запуска пользователями Агентов запуска (Launch Agent) — автозапускаемых сервисов на уровне пользователя. При входе каждого пользователя в систему launchd загружает параметры Агентов запуска из файлов *.plist. Plist-файлы имеют XML-структуру и содержат инструкции, которые указывают launchd какие исполняемые файлы и когда запускать. Plist-файлы можно найти в следующих директориях:

• /System/Library/LaunchAgents;
• /Library/LauncAgents;
• $Home/Library/LaunchAgents.

Злоумышленники могут также маскировать имена вредоносных Агентов запуска с использованием названий легитимных программ. Например, троян Komplex создаёт агент запуска: $HOME/Library/LaunchAgents/com.apple.updates.plist.

Рекомендации по защите: С помощью групповой политики настройте ограничение создания пользователями Агентов запуска. Создание Агентов запуска предполагает загрузку или создание plist-файлов на диск, поэтому сосредоточьте усилия по защите на более ранних этапах атаки.

Запуск демонов (Launch Daemon)

Система: macOS
Права: Администратор
Описание: Техника заключается в изменении злоумышленником параметров сервисов системного уровня запуска — Launch Daemon, указанных в plist-файлах. При загрузке системы процесс Launchd загружает параметры сервисов (демонов) из plist-файлов расположенных в следующих директориях:

• /System/Library/LaunchDeamons;
• /Library/LaunchDeamons.

Launch Daemon могут создаваться с администраторскими привилегиями, но выполнятся под учетной записью root, таким образом злоумышленник может реализовать эскалацию привилегий. Разрешения plist-файлов должны быть root:while, однако сценарий или программа, указанные в нём, могут иметь менее строгие разрешения. Поэтому злоумышленник может изменить исполняемые файлы, указанные в plist, и, таким образом, модифицировать текущие системные сервисы для закрепления в системе или эскалации привилегий.

Рекомендации по защите: Ограничьте привилегии пользователей, чтобы только авторизованные администраторы могли создавать Launch Daemon. Рассмотрите возможность мониторинга создания в системе plist-файлов с помощью таких приложений как KnockKnock.

Утилита Launchctl

Система: macOS
Права: Пользователь, Администратор
Описание: Launchctl — утилита для управления сервисом Launchd. C помощью Launchctl можно управлять системными и пользовательскими сервисами (LaunchDeamons и LaunchAgents), а также выполнять команды и программы. Launchctl поддерживает подкоманды в командной строке, интерактивные или перенаправленные со стандартного ввода:
launchctl submit -l [labelname] — /Path/to/thing/to/execute »arg» »arg» »arg».
Запуская и перезапуская сервисы и демоны, злоумышленники могут выполнить код и даже обойти белый список, если launchctl является разрешенным процессом, однако загрузка, выгрузка и перезагрузка сервисов и демонов может требовать повышенных привилегий.

Рекомендации по защите: Ограничение прав пользователей на создание Launch Agents и запуск Launch Deamons с помощью групповой политики. С помощью приложения KnockKnock можно обнаружить программы, которые используют launchctl для управления Launch Agents и Launch Deamons.

Локальное планирование задач (Local Job Scheduling)

Система: Linux, macOS
Права: Пользователь, администратор, root
Описание: Злоумышленники могут создать в атакуемых системах задания для несанкционированного запуска программ при загрузке системы или по расписанию. В системах Linux и Apple поддерживается несколько методов планирования запуска периодических фоновых задач: cron, at, launchd. В отличие от Планировщика задач Windows, планирование заданий в Linux-системах невозможно осуществить удаленно, за исключением использования удаленных сеансов типа SSH.

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

Элементы входа (Login Item)

Система: macOS
Права: Пользователь
Описание: Злоумышленники в целях закрепления в системе могут настроить автозапуск своего кода с помощью элементов входа (login Item) — пользовательских настроек автозапуска приложений при каждом входе в систему. Login Item, созданные с помощью Service Management Framework, не отображаются в системных настройках и могут быть удалены только через приложение, в котором они были созданы. Пользователи могут управлять только теми Login Item, которые отображаются в системных настройках. Настройки таких Login Item хранятся в plist-файле в пользовательской директории:
~/Library/Preferences/com.apple.loginitems.plist.
Приложения, входящие в состав Login Item, при запуске могут отображать видимые пользователю окна, но с помощью опции «Hide» их можно скрыть.

Рекомендации по защите: Ограничивайте права пользователей на создание Login Item. Стоит отметить, что удержание клавиши shift во время входа в систему запрещает автоматический запуск приложений. Контролируйте настройки Login Item (Системные настройки → Пользователи и группы → Элементы входа).

Logon-скрипты (Logon Scripts)

Система: Windows, macOS
Описание: В целях закрепления в системе атакующий может использовать возможность создания новых или изменения существующих logon-скриптов — сценариев которые выполняются всякий раз когда конкретный пользователь или группа пользователей выполняет вход в систему. Если злоумышленник получил доступ к logon-скрипту на контроллере домена Windows, то он может модифицировать его для исполнения кода во всех системах домена в целях «бокового перемещения» по сети. В зависимости от настроек прав доступа к файлам сценариев входа в систему (обычно такие сценарии хранятся в \[DC]NETLOGON) атакующему могут потребоваться локальные или административные учетные данные.

В Mac, logon-скрипты (Login/Logout Hook), в отличие от Login Item, которые запускаются в контексте пользователя, могут запускаться от имени root.

Рекомендации по защите: Ограничение прав администраторов на создание сценариев входа в систему. Идентификация и блокирование потенциально-опасного ПО, которое может использоваться для модификации сценариев входа.

Модификация существующих служб (Modify Existing Service)

Система: Windows
Права: Администратор, System
Описание: Для многократного запуска вредоносного кода в системе, атакующий может изменять конфигурацию существующих служб с помощью системных утилит или инструментов взаимодействия с Windows API. Злоумышленники могут преднамеренно повредить или убить службу для последующего вызова модифицированной программы или команды восстановления службы. Использование существующих служб — это один из приёмов маскарадинга, который затрудняет обнаружение вредоносной активности. Информация о конфигурации служб Windows, включая путь к программам и командам запуска и восстановления службы, хранится в реестре:

• HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservices.

Конфигурацию служб можно менять с помощью консольных утилит sc.exe и Reg.

Рекомендации по защите: Ограничение привилегий пользователей и групп на изменение конфигураций служб, предоставив права только уполномоченным администраторам. Блокирование потенциально-опасного ПО. Для исследования изменений в системных службах с целью выявления попыток закрепления атакующего в системе можно применять утилиту Sysinternals Autoruns.

Вспомогательные DLL утилиты Netsh (Netsh Helper DLL)

Система: Windows
Права: Администратор, System
Описание: Атакующие могут выполнить код с помощью встроенной консольной утилиты Netsh, которая для расширения функционала позволяет подгружать вспомогательные DLL:
netsh> add helper [Путь к DLL]
Информация о зарегистрированных библиотеках, используемых netsh, хранится в реестре:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftNetSh
Некоторые корпоративные VPN-клиенты и сетевые утилиты могут использовать netsh.exe, запуская его от имени System, в такой ситуации атакующий может зарегистрировать или модифицировать вспомогательную DLL, которая будет выполняться при использовании netsh VPN-клиентом. Инструменты для реализации данного типа атаки включены в состав CobaltStrike (фреймворк для проведения тестов на проникновение).

Рекомендации по защите: Блокирование потенциально-опасного ПО с помощью таких средств, как AppLocker.

Новые службы (New Service)

Система: Windows
Права: Администратор, System
Описание: Имя доступ в систему, злоумышленники могут создавать новые службы и настраивать их автоматический запуск. Имя службы может быть замаскировано с использованием имён, характерных для операционной системы. Службы могут быть созданы с привилегиями администратора, но запускаться от имени System. Сервисы могут создаваться из командной строки, с помощью средств удаленного доступа с функциями взаимодействия с Windows API или с помощью стандартных средств управления Windows и PowerShell.

Рекомендации по защите: Ограничьте права пользователей на создание новых служб, чтобы только уполномоченные администраторы могли это делать. Применяйте AppLocker и Software Restriction Policy.

Автозапуск в офисных приложениях (Office Application Startup)

Система: Windows
Права: Пользователь, администратор
Описание: Некоторые механизмы работы MS Office могут использоваться для выполнения кода при запуске офисных приложений и, как следствие, для обеспечения атакующим своего постоянства в системе:
• Встраивание вредоносных VBA-макросов в базовые шаблоны Office. Word использует шаблон Normal.dotm:
C:Users[Username]AppDataRoamingMicrosoftTemplatesNormal.dotm.
В Excel нет шаблона по умолчанию, однако его можно добавить вручную, и он будет автоматически загружаться:
C:Users[Username]AppDataRoamingMicrosoftExcelXLSTARTPersonal.xls.
Реализация атаки возможна только при включенном параметре «Запуск всех макросов» в Центре управления безопасностью Office:
HKEY_CURRENT_USERSoftwareMicrosoftOffice[Версия][Приложение]SecurityVBAWarnings: 1;
• Размещение ссылки на DLL в разделе Office test в реестре Windows приводит к выполнению указанной DLL при каждом запуске приложения Office:
HKEY_CURRENT_USERSoftwareMicrosoftOffice TestSpecialPerf[Default]:[Указываем путь к DLL];
• Добавление в приложение Office надстройки с вредоносным кодом, который будет выполнятся при запуске атакуемого приложения.

Рекомендации по защите: Следуйте рекомендациям Microsoft при настройке параметров безопасности макросов. Для предотвращения эксплуатации механизма Office Test создайте указанный раздел в реестре и установите на него разрешения «Только чтение», чтобы предотвратить к нему доступ без прав администратора. По возможности отключите надстройки Office, если они нужны, то следуйте рекомендациям Microsoft при организации их работы.

Перехват пути (Path Interception)

Система: Windows
Права: Пользователь, администратор, system
Описание: Техника перехвата пути заключается в помещении исполняемого файла в директорию, из которой приложение запустит его вместо целевого файла. Атакующий может использовать следующие методы:

• Несуществующие пути. Пути к исполняемым файлам служб хранятся в ключах реестра и могут иметь один или несколько пробелов, например, C:Program Filesservice.exe, если атакующий создаст в системе файл C:Program.exe, то Windows при обработке пути запустит его вместо целевого файла службы.
• Неправильная конфигурация переменных окружения. Если в переменной PATH путь C:example предшествует c:WindowsSystem32 и существует файл C:examplenet.exe, то при вызове команды net, будет выполнен C:examplenet.exe, а не c:WindowsSystem32net.exe.
• Перехват порядка поиска (Search order hijacking). Когда не задан полный путь к исполняемому файлу, Windows, как правило, ищет файл с указанным именем в текущем каталоге, затем осуществляет поиск в системных каталогах. Например, файл «example.exe» при выполнении запускает cmd.exe с аргументами для выполнения команды net use. Атакующий может поместить в каталог расположения example.exe файл net.exe и он будет запущен вместо утилиты c:WindowsSystem32net.exe. Кроме того, если атакующий поместит файл net.com в каталог с файлом net.exe, то Windows выполнит net.com в соответствии с порядком исполнения, определенном в системной переменной PATHEXT.

Перехват порядка поиска файлов также применяется для выполнения DLL с помощью техники DLL Search Hijacking.

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

Модификация файлов Plist (Plist Modification)

Система: macOS
Права: Пользователь, Администратор
Описание: Злоумышленники могут модифицировать plist-файлы, указывая в них собственный код для его исполнения в контексте другого пользователя. Файлы свойств plist, расположенные в /Library/Preferences выполняются с повышенными привилегиями, а plist из ~/Library/Preferences выполняются с привилегиями пользователя.

Рекомендации по защите: Предотвратите изменение файлов plist, сделав их доступными только на чтение.

Port Knocking

Система: Linux, macOS
Права: Пользователь
Описание: Злоумышленники могут применять методы Port Knocking для скрытия открытых портов, которые они используют для соединения с системой.

Рекомендации по защите: Применение stateful-брандмауэров может предотвратить реализацию некоторых вариантов Port Knocking.

Модификация Port Monitors в Диспетчере печати (Port Monitors)

Система: Windows
Права: Администратор, System
Описание: Атакующий может организовать выполнение произвольной DLL от имени System при каждой загрузке Windows с помощью злоупотребления настройками Диспетчера печати (Spoolsv.exe). Для взаимодействия с устройствами печати Spoolsv.exe использует так называемые мониторы порта (port monitor) — это DLL-библиотеки, с помощью которых посредством LAN, USB, LPT или COM-интерфейса на устройства печати передаются низкоуровневые команды. Вышеописанные DLL хранятся в C:windowssystem32 и регистрируются в реестре:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlPrintMonitors.
Port Monitor можно установить с помощью API функции AddMonitor или напрямую через редактирование вышеуказанного раздела реестра.

Рекомендации по защите: Организуйте блокирование потенциально-опасного ПО и применяйте инструменты контроля запуска приложений.

Rc.common

Система: macOS
Права: root
Описание: Атакующий может добавить в файл /etc/rc.common код, который будет выполнятся при каждой загрузке системы с правами root. Rc.common — это сценарий, который выполняется во время загрузки OC, является предшественником Launch Agents и Launh Deamons. Это устаревшая технология автозапуска программ, но она до сих пор поддерживается в macOS и OS X.

Рекомендации по защите: Ограничение привилегий пользователей на редактирование файла rc.common.

Повторный запуск приложений (Re-opened Applications)

Система: macOS
Права: Пользователь
Описание: В системах, начиная с OS X 10.7 (Lion), атакующий может организовать выполнение вредоносного файла при каждой перезагрузке ОС. Техника основывается на злоупотреблении функцией повторного запуска приложений после перезагрузки системы. Пользователь с помощью инструментов, встроенных в GUI, может указывать системе какие приложения необходимо повторно запустить в случае перезагрузки ОС. Эти настройки хранятся в plist-файлах:

• ~/Library/Preferences/com.apple.loginwindow.plist;
• ~/Library/Preferences/ByHost/com.apple.loginwindows.*.plist.

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

Рекомендации по защите: Функцию перезапуска приложений можно отключить с помощью консольной команды: defaults write -g ApplePersistence -bool no.
Кроме того, удерживание клавиши shift во время загрузки предотвращает автоматический запуск приложений.

Резервный доступ (Redundant Access)

Система: Windows, Linux, macOS
Права: Пользователь, администратор, System
Описание: Злоумышленники могут одновременно использовать несколько средств удаленного доступа с различными протоколами управления с целью диверсификации рисков обнаружения. Так, если один из инструментов удаленного доступа обнаружен и заблокирован, но защищающая сторона не выявила всех инструментов злоумышленника, то удаленный доступ в атакуемую сеть будет по-прежнему сохранен. Атакующие так же могут пытаться получить доступ к валидным учетным записям удаленных корпоративных сервисов, типа VPN, для получения альтернативного доступа в систему в случае блокировки основных инструментов удаленного доступа. Использование web-shell так же является одним из способов удаленного доступа в сеть через web-сервер.

Рекомендации по защите: Осуществляйте мониторинг наличия и блокирование запуска в вашей сети известных средств удаленного доступа (AmmyAdmin, Radmin, RemotePC, VNC и т.п.), применяйте инструменты контроля запуска приложений и блокирования потенциально-опасного ПО. Внедрение IDS и IPS систем, которые с помощью сигнатур выявляют конкретные вредоносные программы, снизит вероятность успешной атаки, однако со временем злоумышленники будут модифицировать свои инструменты для изменения сигнатуры и, как следствия, обхода IDS и IPS систем.

Автозапуск с помощью ключа Run Keys и папки «Автозагрузка» (Registry Run Keys / Start Folder)

Система: Windows
Права: Пользователь, администратор
Описание: Атакующий может добавить в реестре Windows «ключ запуска (run keys)» или ссылку в папку «Автозагрузка» для запуска вредоносного файла при входе пользователя в систему. Программа будет выполняться с правами текущего пользователя. Злоумышленники могут замаскировать ключи запуска в реестре, чтобы они выглядели как часть законных программ.
Ключи запуска (run keys) хранятся в следующих разделах реестра:

• HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun;
• HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRunOnce;
• HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun;
• HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRunOnce.

Рекомендации по защите: Идентификация и блокирование потенциально-опасного ПО, мониторинг изменений папки «Автозагрузка» и вышеперечисленных веток реестра.

Захват SIP и Trust Provider (SIP and Trust Provider Hijacking), Subverting Trust in Windows

Система: Windows
Права: Администратор, System
Описание: Злоумышленники могут модифицировать компоненты архитектуры подписания и проверки цифровой подписи кода Windows, чтобы обойти средства контроля запуска программ, которые разрешают запускать только подписанный код. Для создания, подписания и проверки подписи файлов различных форматов в Windows используются так называемые Subject Interface Package (SIP) — уникальные для каждого типа файла программные спецификации, с помощью которых обеспечивается взаимодействие между API-функциями, которые инициируют создание, вычисление и проверку подписей и непосредственно файлами. Валидность же подписи подтверждается с помощью так называемых Trust Provider — это программные компоненты ОС, осуществляющие различные процедуры, связанные с вычислением и проверкой цифровых подписей.
Популярные методы совершения атаки:

• Модификация ключей DLL и FuncName в разделе CryptSIPDllGetSignedDataMsg:
  HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyOIDEncodingType 0CryptSIPDllGetSignedDataMsg[SIP_GUID].
  Выполняется с целью подмены DLL-библиотеки, предоставляющей функцию CryptSIPDllGetSignedDataMSG, которая возвращает закодированный цифровой сертификат из подписанного файла. Подложная функция может всегда возвращать заранее известное валидное значение сигнатуры (например, подпись Microsoft для исполняемых системных файлов) при использовании модифицированного SIP. Атакующий может пытаться применять одну валидную сигнатуру для всех файлов, однако, вероятнее всего, это приведёт к недействительности сигнатуры, так как хэш, возвращаемый функцией, не будет совпадать с хэшем, вычисленным из файла.
• Модификация ключей DLL и FuncName в разделе:
  HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyOIDEncodingType 0CryptSIPDllVerifyIndirectData/[SIP_GUID].
  Выполняется с целью подмены DLL-библиотеки, предоставляющей функцию CryptSIPDllVerifyIndirectData, которая выполняет сверку хэша, вычисленного из файла, с хэшем, указанным в цифровой подписи, и возвращает результат сверки (True/False). Таким образом, атакующий может обеспечить успешную проверку любого файла c использованием модифицированного SIP. Вышеуказанные значения ключей могут перенаправлять на подходящую функцию из уже существующей библиотеки, таким образом исключая необходимость создания на диске нового DLL-файла.
• Модификация ключей DLL и FuncName в разделе:
  HKEY_LOCAL_MACHINESOFTWAREMicrosoftCryptographyProvidersTrustFinalPolicy/[Trust Provider GUID].
  Выполняется с целью подмены DLL-библиотеки, предоставляющей функцию FinalPolicy для определенного Trust Provider, которая декодирует, анализирует подпись и принимает решение о доверии. По аналогии с CryptSIPDllVerifyIndirectData, значение вышеуказанных ключей может перенаправлять на уже существующую DLL-библиотеку.

Важно отметить, что описанную атаку на механизм доверия Windows можно осуществить с помощью техники перехвата поиска DLL (DLL Search Order Hijacking).

Рекомендации по защите: Убедитесь, что пользователи защищаемой системы не могут изменять ключи реестра, относящиеся к компонентам SIP и Trust Provider. Рассмотрите возможность удаления ненужных и устаревших SIP. Используйте всевозможные средства блокирования загрузки вредоносных DLL, например, встроенные в Windows AppLocker и DeviceGuard.

Планирование задач (Scheduled Task)

Система: Windows
Права: Пользователь, администратор, система
Описание: Такие утилиты как at, schtasks и Планировщик задач Windows могут использоваться для планирования запуска программ и сценариев, которые будут выполнятся в определенную дату и время. Задачу можно запланировать в удаленной системе, при условии, что для проверки подлинности используется RPC, и включен общий доступ к принтерам и файлам. Планирование задач в удаленной системе требует прав администратора. Злоумышленник может использовать удаленное выполнение кода для получения прав System или для запуска процесса под определенной учетной записью.

Рекомендации по защите: Ограничение привилегий пользователей. Применение инструментов, таких как модуль PowerUP в PowerSploit, которые могут использоваться для поиска слабых мест в разрешениях запланированных задач. Отключение возможности запуска задач от имени System, отключение в политике безопасности параметра «Разрешить операторам сервера планировать задачи» и включение параметра «Назначение прав пользователя: Увеличить приоритет планирования«.

Экранная заставка (Screensaver)

Система: Windows
Права: Пользователь
Описание: Злоумышленники могут использовать настройки экранной заставки для запуска вредоносного ПО после определенного периода бездействия пользователя.
Приложение Windows Screensaver (scrnsave.exe) располагается в C:WindowsSystem32, вместе с другими заставками, включенными в базовую сборку ОС. Атакующий может манипулировать параметрами заставки в разделе реестра HKEY_CURRENT_USERControl PanelDesktop:

• SCRNSAVE.EXE — указать путь к вредоносному исполняемому файлу;
• ScreenSaveActivr — установить значение «1», чтобы активировать заставку;
• ScreenSaverISSecure — установить значение «0», чтобы система не требовала пароль для разблокировки рабочего стола Windows после отключения заставки;
• ScreenSaverTimeout — установить период бездействия перед запуском заставки.

Рекомендации по защите: Блокируйте возможность запуска файлов *.scr из нестандартных мест. Управляйте параметрами заставки с помощью групповой политики, запрещающей локальное изменение параметров заставки.

Security Support Provider (SPP)

Система: Windows
Права: Администратор
Описание: Злоумышленники могут настроить выполнение вредоносного кода при каждой загрузке системы или вызове API-функции AddSecurityPackage с помощью добавления в конфигурацию Local Security Authority (LSA) фиктивного провайдера поддержки безопасности — Security Support Provider (SSP). SSP — программные модули (DLL), содержащие одну или несколько схем аутентификации и криптографии, которые загружаются в процесс LSASS при запуске системы. DLL-библиотеки SPP имеют доступ к зашифрованным и открытым текстовым паролям, которые хранятся в Windows. Конфигурация SPP хранится в двух ключах реестра:

• HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaSecurity Packages;
• HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaOSConfigSecurity Packages.

Рекомендации по защите: В Windows 8.1, Windows Server R2 и более поздних версиях ОС необходимо активировать защищенный режим работы LSA (Process Protect Light — PPL), в котором все DLL-файлы SPP должны быть подписаны цифровой подписью Microsoft:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaRunAsPPL=dword:00000001

Слабости разрешений параметров служб в реестре (Service Registry Permissions Weakness)

Система: Windows
Права: Администратор, System
Описание: Если разрешения пользователей и групп позволяют изменять в реестре Windows значения ключей, в которых хранятся параметры служб, то злоумышленники могут напрямую модифицировать ключи, в которых хранятся пути к исполняемым файлам запуска служб или использовать различные инструменты управления службами — sc.exe, PowerShell или Reg. Атакующие так же могут менять параметры, связанные с отказом служб, например, FailureCommand, указывающие команду, которая будет выполнятся в случае отказа или преднамеренного повреждения службы. Параметры служб хранятся в HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservices.

Рекомендации по защите: Убедитесь, что пользователи защищаемой системы не могут изменять в реестре ключи, хранящие параметры системных компонентов. Используйте всевозможные средства блокирования потенциально-опасного ПО, например, Windows AppLocker.

Модификация ярлыков (Shortcut Modification)

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

Рекомендации по защите: Ограничьте права пользователей и групп, таких как Администраторы, на создание символических ссылок с помощью GPO:
Computer Configuration > [Policies] > Windows Settings > Security Settings > Local Policies > User Rights Assignment: Create symbolic links.
Применяйте средства блокирования потенциально-опасного ПО и политики ограничения ПО (Software Restriction Policy).

Элементы автозапуска (Startup Items)

Система: macOS
Права: Администратор
Описание: Атакующий может использовать устаревший, но до сих пор работающий в macOS Sierra, механизм автозапуска приложений с помощью StartupItems для настройки запуска своего кода с правами root во время загрузки ОС. StartupItems — это каталог в /Library/Startupitems, командный сценарий и файл свойств StartupParameters.plist. Сценарий и файл свойств должны находится на верхнем уровне иерархии: /Library/Startupitems/[MyStartupItem].

Рекомендации по защите: Поскольку механизм StartupItems является устаревшим, то запрет записи в каталоге /Library/Startupitems/ позволит избежать создания элементов автозагрузки.

Системная прошивка (System Firmware)

Система: Windows
Права: Администратор, System
Описание: Особо изощрённые злоумышленники могут модифицировать или перепрошить Bios, UIFI или UFI, для того что бы обеспечить возможность установки вредоносных обновлений прошивки и закрепления в системе.

Рекомендации по защите: Направьте вектор защиты на предотвращение доступа атакующего к привилегированным учетным записям, которые необходимы для реализации описываемой техники. Рассмотрите необходимость и возможность применения в защищаемой системе Trusted Platform Module (TPM). Рассмотрите необходимость применения внешних инструментов контроля и анализа защищенности системной прошивки, например, CHIPSEC Framework.

Провайдеры времени (Time Providers)

Система: Windows
Права: Администратор, System
Описание: Атакующие могут регистрировать в качестве поставщика времени (Time Provider) вредоносную DLL, которая будет выполнятся при запуске системы или изменении конфигурации Windows Time Server (W32Time). Параметры поставщиков времени хранятся в реестре:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesW32TimeTimeProviders.
Для регистрации поставщика времени потребуются права администратора, но его выполнение будет происходит в контексте учетной записи локальной службы.

Рекомендации по защите: Рассмотрите возможность использования GPO для настройки блокирования изменений параметров W32Time. Используйте всевозможные средства блокирования загрузки вредоносных DLL, например, встроенные в Windows AppLocker и DeviceGuard.

Команда Trap

Система: Linux, macOS
Права: Пользователь, администратор
Описание: Команда trap служит для защиты скрипта от прерываний (ctrl+c, ctrl+d, ctrl+z и т.п.). Если скрипт получает сигнал о прерывании, указанном в аргументах команды trap, то он обрабатывает сигнал прерывания самостоятельно, при этом командная оболочка такой сигнал обрабатывать не будет. Злоумышленники могут использовать trap для регистрации кода, который будет выполняться при получении командной оболочкой определенных сигналов прерываний.

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

Действующие учетные записи (Valid Accounts)

Описание: Злоумышленники могут украсть учетные данные определенного пользователя или учетную запись службы с помощью техник доступа к учетным данным, захватить учетные данные в процессе разведки с помощью социальной инженерии. Скомпрометированные учетные данные могут использоваться для обхода систем управления доступом и получения доступа к удаленным системам и внешним службам, таким как VPN, OWA, удаленный рабочий стол или получения повышенных привилегий в определенных системах и областях сети. В случае успешной реализации сценария злоумышленники могут отказаться от вредоносных программ, чтобы затруднить своё обнаружение. Так же злоумышленники могут создавать учетные записи используя заранее определенные имена и пароли для сохранения резервного доступа в случае неудачных попыток использования других средств.

Рекомендации по защите: Применение парольной политики, следование рекомендациям по проектированию и администрированию корпоративной сети для ограничения использования привилегированных учетных записей на всех административных уровнях. Регулярные проверки доменных, локальных учетных записей и их прав с целью выявления тех, которые могут позволить злоумышленнику получить широкий доступ. Мониторинг активности учетных записей с помощью SIEM-систем.

Web Shell

Система: Windows, Linux, macOS
Описание: Web Shell может использоваться злоумышленником в качестве шлюза доступа в вашу сеть или избыточного доступа в атакуемую систему, как резервного механизма закрепления в случае обнаружения и блокирования основных каналов доступа в атакуемую среду.

Рекомендации по защите: Убедитесь, что ваши внешние веб-серверы регулярно обновляются и не имеют известных уязвимостей, которые позволяют злоумышленникам загрузить на сервер файл или сценарий с последующим исполнением. Проверьте, что разрешения учетных записей и групп с правами управления серверами не совпадают с учетными записями внутренней сети, которые могут быть использованы для входа на веб-сервер, запуска Web shell или закрепления на Web-сервере. Web Shell трудно обнаружить, т.к. они не инициируют подключения и их серверная часть может быть маленькой и безобидной, например, PHP-версия оболочки China Chopper Web выглядит как строчка:
[?php eval($_POST [‘password’]);]

Windows Management Instrumentation Event Subscription

Система: Windows
Права: Администратор, System
Описание: WMI Event Subscription — это функциональность, которая позволяет администратору настроить получение извещений о событиях (Event), в том числе произошедших в удаленных системах, с последующим автоматическим выполнением каких-либо действий (запуск скрипта, приложения и т.п.). Злоумышленники, в целях закрепления в системе, могут злоупотреблять вышеописанной функциональностью, настраивая подписку на такие события, как время системных часов или время работы компьютера, с последующим выполнением кода при возникновения этого события.

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

Winlogon Helper DLL

Система: Windows
Права: Администратор, System
Описание: Модифицируя в реестре параметры вспомогательных DLL, используемых Winlogon.exe, атакующий может обеспечить многократное выполнение вредоносных DLL для закрепления в системе. Параметры Winlogon хранятся в разделах:

• • HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionWinlogon
• • HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

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

• WinlogonNotify — указывает DLL, обрабатывающие события Windows
• WinlogonUserinit — указывает на файл userinit.exe, программу инициализации пользователя, выполняемую при входе пользователя в систему;
• WinlogonShell — указывает на файл explorer.exe, системную оболочку, выполняемую при входе пользователя в систему.

Рекомендации по защите: Убедитесь, что параметры Winlogon могут менять только уполномоченные администраторы. Применяйте всевозможные средства блокирования загрузки вредоносных DLL и потенциально-опасных программ, например, встроенные в Windows AppLocker и DeviceGuard.

Ограничение доступа, права пользователей… Эти слова звучат сладкой музыкой для любого системного администратора, который заботится о безопасности сети, равно как и для пользователя, который следит за конфиденциальностью своей информации. К счастью, в операционных системах Windows NT и Windows 2000 реализованы специальные средства, позволяющие решать многие проблемы защиты информации.

Какие же механизмы включаются, когда мы выбираем пункт меню «Безопасность» из диалогового окна свойств файла? В данной статье я постараюсь ответить на этот вопрос. В качестве примера возьмем технологии получения списка логических дисковых разделов, локальных разделяемых ресурсов, а также рассмотрим две удобные утилиты, одна из которых входит в поставку NT, а вторая — в Resource Kit.

В операционной системe NT существует понятие «защищенный объект» (securable object). Это объект, доступ к которому контролируется и ограничивается операционной системой. В семействе операционных систем производства Microsoft лишь NT и Windows 2000 обеспечивают подобный сервис. К таким объектам относятся: файлы и каталоги файловой системы NTFS; каналы (pipes); процессы и потоки (Process and threads); файлы, спроецированные в память (mapped files); маркеры доступа (access tokens); объекты управления окнами (Window-management objects); разделы реестра (registry keys); службы Win32 (services); принтеры (Printers); разделенные сетевые ресурсы (Network shares); объекты синхронизации процессов (Interprocess synchronization objects — events, mutexes, semaphores, waitable timers); задачи (Job objects).

В модели ограничения доступа Win32 существует два базовых понятия:

Access tokens — маркеры доступа (МД), содержащие информацию о пользователе;

Security descriptors — описатели защиты, содержащие информацию о правах тех или иных учетных записей на доступ к объекту.

При регистрации пользователя в системе после успешной проверки имени и пароля создается маркер доступа. Для каждого процесса, выполняемого далее в контексте этого пользователя, создается копия МД. Маркер доступа содержит множество идентификаторов защиты (security identifiers, SID), определяющих учетные записи пользователя и тех групп, в которые он входит. Кроме того, МД содержит список привилегий (privilege) — прав на доступ к тем или иным объектам, предоставляемых той или иной учетной записи. С помощью этой информации операционная система определяет возможности доступа пользователя к ресурсам.

При создании защищенного объекта ОС присваивает ему описатель защиты (security descriptor, SD) — той защиты, которая имеется у пользователя, создающего объект, или же той, что задана по умолчанию. Приложения Win32 могут использовать функции API как для получения, так и для изменения информации о доступе к объектам.

Security descriptor содержит информацию о владельце объекта, а также может включать следующие списки контроля доступа Access-Contol List (ACL):

Discretionary access-control list (DACL) — разграничительные списки контроля доступа, в которых содержатся пользователи и группы с соответствующими правами на доступ к объекту;

System access-control list (SACL) — системные списки контроля доступа, которые определяют, как осуществляется аудит попыток доступа к объекту.

Список контроля доступа содержит список записей контроля доступа (access-control entries, ACEs). Каждая запись содержит набор битовых флагов и идентификатор SID попечителя (trustee) — пользователя или группы, к которой эти права применены.

Остановимся на упомянутых объектах более подробно.

Security Descriptor

Эти объекты содержат информацию о безопасности, соотнесенную с тем или иным защищенным объектом. Физически этот объект представляет собой структуру SECURITY_DESCRIPTOR, описанную в файле Windows.h:

typedef struct _SECURITY_DESCRIPTOR {
 BYTE Revision;
 BYTE Sbz1;
 SECURITY_DESCRIPTOR_CONTROL Control;
 PSID Owner;
 PSID Group;
 PACL Sacl;
 PACL Dacl;
} SECURITY_DESCRIPTOR, *PISECURITY_DESCRIPTOR;

Структура SECURITY_DESCRIPTOR используется для доступа к информации о безопасности объектов. Но изменять поля непосредственно в данной структуре невозможно. Для этого необходимо использовать специальные функции (например, SetSecurityDescriptorOwner(…)). Кроме того, Win32 API предоставляет интерфейс для создания и инициализации описателя SD для новых объектов.

Access token

Access token (маркер доступа) — это объект операционной системы, который описывает контекст ограничения доступа к процессу или потоку. Он содержит привилегии, соответствующие учетной записи пользователя, ассоциированного с процессом или потоком. Маркер доступа создается после успешной идентификации пользователя в системе. После этого каждый процесс, который так или иначе запускается данным пользователем, сопровождается копией его маркера.

Идентификатор защиты SID

Уникальный параметр переменной длины, определяющий учетную запись (account) и хранящийся в базе данных системы безопасности Windows NT, — вот что такое SID. В начале каждого сеанса, как только пользователь идентифицирован в системе, его SID извлекается из БД и помещается в маркер доступа. Далее это значение используется операционной системой при всех действиях пользователя с защищенными объектами.

Существует несколько стандартных SID, применяемых для учетных записей:

NULL — S-1-0-0 — SID группы, в которую не входят пользователи. Используется лишь тогда, когда SID неизвестен;

World — S-1-1-0 — группа, включающая в себя всех пользователей;

Local — S-1-2-0 — пользователи, имеющие непосредственный, физический доступ к системе;

Creator Owner ID — S-1-3-0 — SID, которым заменяется SID пользователя, создавшего объект. Этот SID используется для унаследованных записей ACE (см. ниже);

Creator Group ID — S-1-3-1 — значение, заменяющее SID основной группы, к которой принадлежит пользователь, создавший объект. Этот SID, как и предыдущий, используется для унаследованных записей ACE.

Список управления доступом ACL

ACL представлен структурой, описанной в Windows.h:

typedef struct _ACL { 
 BYTE AclRevision; 
 BYTE Sbz1; 
 WORD AclSize; 
 WORD AceCount; 
 WORD Sbz2; 
} ACL;

Для Windows NT версий 3.5, 3.51, 4.0 определено максимальное число записей управления доступом, задаваемых списком управления доступом (см. статью Q166348 в базе знаний Microsoft). Оно равно 1820.

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

Система ограничения доступа Windows NT/2000 использует несколько типов записей ACE, которые перечислены в Таблице 1, содержащей, кроме того, и названия соответствующих этим типам структур данных.

Вполне вероятно, что в следующих версиях операционной системы появятся новые типы ACE, да и из приведенных в Таблице 1 некоторые поддерживаются только Windows 2000. Для того чтобы унифицировать процедуру анализа структур ACE, разработчики включили во все структуры _ACE одинаковую последовательность полей, которая отображается в структуре ACE_HEADER:

typedef struct _ACE_HEADER { 
 BYTE AceType; 
 BYTE AceFlags; 
 WORD AceSize; 
} ACE_HEADER; 
typedef ACE_HEADER *PACE_HEADER;

Первое поле AceType определяет тип структуры. Очевидно, что указатель на любую структуру _ACE можно преобразовать в указатель на ACE_HEAER, получить тип ACE, после чего этот указатель преобразовать в указатель на соответствующую полученному типу структуру данных. Замечу, что такой прием широко используется в различных API продуктов Microsoft.

Теперь мы имеем общее представление о том, как устроена система безопасности объектов Windows NT. Попробуем применить эти сведения на практике и написать небольшую программу. В качестве примера используется программа, позволяющая выбрать один или несколько разделов диска, которые будут отсканированы, после чего на основе собранной информации будет создан командный файл, устанавливающий права на объекты выбранного раздела. В сценарий также включается список локальных разделяемых ресурсов с правами доступа к ним. После запуска сценария создаются разделяемые ресурсы, восстанавливаются права доступа к ним и параметры безопасности для объектов файловой системы. Ниже я расскажу лишь о ключевых моментах проекта, относящихся, впрочем, не только к API системы безопасности. Полный текст программы можно найти на http://members.xoom.com/alex_ep/NTSec/sec.zip, а соответствующий дистрибутив, в который входят дополнительные модули и файл справки — на сайте http://members.xoom.com/alex_ep/NTSec/RTPermScan.zip.

Список разделов дисковых устройств

На Листинге 1 показано, как получить список логических дисков. Для этого используется функция Win-API NetServerDiskEnum. Ее первый параметр определяет сетевое имя компьютера, список накопителей которого нас интересует. Если этот параметр NULL, то берется локальный компьютер. Список дисковых накопителей возвращается в параметре lpBuf. Он имеет вид последовательности из 3 байт. Каждая последовательность содержит букву — символ диска, двоеточие и разделитель NULL. Количество прочитанных накопителей возвращается в параметре dwReded, а общее количество дисков — в dwTotal. После обработки буфер lpBuf необходимо освободить вызовом функции NetApi-BufferFree(lpBuf).

В коде Листинга 1 вызывается написанная мной функция GetParti-tionTypeEx. Она получает параметры дискового накопителя, возвращает наименование файловой системы, на нем установленной, и проверяет, поддерживает ли файловая система контроль ограничения доступа (cм. Листинг 2).

В Win32 API для получения информации о дисковом разделе используется функция

BOOL GetVolumeInformation( LPCTSTR
lpRootPathName, LPTSTR lpVolumeNameBuf-fer,
 ВWORD nVolumeNameSize, LPDWORD
 lpVolumeSerialNumber, LPDWORD
 lpMaximumComponent-Length, LPDWORD
 lpFileSystem-Flags, LPTSTR lpFileSystemName-
Buffer, DWORD nFileSystem-NameSize ).

Ее параметры описаны в Таблице 2. Чуть подробнее рассмотрим параметр lpFileSystemFlags. Это набор битовых флагов. Среди прочих определен флаг FS_PERSISTENT_ACLS. Наличие этого флага означает, что папки и файлы раздела являются охраняемыми объектами. Перед тем как получать списки ACE для того или иного объекта, неплохо убедиться, что файловая система их поддерживает. Теперь мы знаем, как это делается.

Более подробное описание данной функции можно найти в MSDN по адресу: http://msdn.microsoft.com/library/psdk/winbase/fsys_6wfi.htm.

Список записей управления доступом для защищенных объектов

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

Чтобы получить структуру ACL для именованного объекта, нужно задействовать функцию GetNmedSe-curityInfo. Среди прочих значений она возвращает указатели на DACL и SACL. Нас интересует первый из них. Теперь у нас есть вся информация для создания списка ACE. Функция GetAce позволяет пройти по всему списку заголовков ACE_HEADER, соответствующих ACL. Этой функции передаются три параметра. Первый — указатель на ACL, второй — порядковый номер ACE, указатель на который возвращается в третьем параметре (cм. Листинг 3).

Список разделяемых ресурсов и прав для них

Последний вопрос, который я хочу подробно рассмотреть, касается получения списка локальных ресурсов общего доступа (shares) и прав доступа к ним. Процедура получения прав на объекты идентична описанной процедуре получения прав на доступ к файловым объектам. Поэтому реализующий ее код включен в код процедуры, представленной в Листинге 4, и отдельно не обсуждается. Это характерно для API системы безопасности, которая предоставляет обобщенный интерфейс ко всем защищенным объектам. Действительно, с точки зрения системы ограничения доступа Windows разделяемый ресурс — такой же именованный объект, как, например, и файл. Поэтому алгоритмы работы с ними одни и те же.

Список разделяемых ресурсов предоставляется функцией

Win32 API NET_API_STATUS 
NetShareEnum( LPWSTR servername, DWORD level, LPBYTE *
bufptr, DWORD prefmaxlen, DWORD entriesread, LPDWORD
 totalentries, LPDWORD resume_handle )

возвращающей в параметре bufptr указатель на массив структур, который нужно освободить вызовом функции NetBufferFree. Подробное описание этой функции можно найти по адресу: http://msdn.microsoft.com/library/psdk/network/ntlmapi2_4l2l.htm.

Для получения SD ресурса используется функция

NET_API_STATUS NetShareGetInfo( LPWSTR 
servername, LPWSTR netname, DWORD level,
 LPBYTE *bufptr ),

описание которой находится по адресу: http://msdn.microsoft.com/library/psdk/network/ntlmapi2_18bz.htm. В параметре level передается необходимый уровень детализации информации. В соответствии с этим параметром в параметре bufptr возвращается указатель на ту или иную структуру. Уровню детализации 502 соответствует структура SHARE_INFO_502, описанная в файле Lmshare.h:

typedef struct _SHARE_INFO_502 {
 LPWSTR shi502_netname;
 DWORD shi502_type;
 LPWSTR shi502_remark;
 DWORD shi502_permissions;
 DWORD shi502_max_uses;
 DWORD shi502_current_uses;
 LPWSTR shi502_path;
 LPWSTR shi502_passwd;
 DWORD shi502_reserved;
 PSECURITY_DESCRIPTOR shi502_security_descriptor;
} SHARE_INFO_502, *PSHARE_INFO_502, *LPSHARE_INFO_502;

Для получения списка ACE используется поле shi502_security_descriptor, содержащее необходимый Security Descriptor.

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

Результатом работы утилиты, которую можно загрузить по указанному адресу, является командный файл. Прекрасно, скажете вы, а что дальше? Вообще говоря, наш файл состоит из двух частей: в первой создаются и устанавливаются права доступа к разделяемым файлам и каталогам, а во второй выясняются параметры безопасности для объектов файловой системы. Для работы с разделяемыми ресурсами из командной строки в Microsoft WindowsNT (R) Resource Kit есть небольшая программа — RMTSHARE.EXE. Сценарий создан с использованием этой программы.

Параметры команды такие:

Rmtshare.exe 
serversharename=drive:path
 [/USERS:number | /UNLIMITED]
    [/REMARK:"text"]
    [/GRANT [user[:perm][ /GRANT
 user[:perm]]]]
    [/REMOVE user]

Для просмотра и установки параметров доступа к объектам NTFS используется утилита cacls.exe, входящая в WinNT.

Cacls.exe filename [/T][/E][/C][/G 
user:perm][/R user [...]][/P user:perm
 [...]] [/D user [...]]

Filename — без других параметров выводит на экран список пользователей и их прав на доступ к объекту Filename.

/T — изменяет список записей управления доступом к объекту, а если это папка, то ко всем вложенным папкам.

/E — заменяет список записей управления доступом.

/C — позволяет продолжить работу в случае ошибки отказа в доступе.

/G user:perm — устанавливает для пользователя, определяемого параметром user, права на доступ к объекту, определяемые параметром perm:

N — нет; R — чтение; W — запись; C — изменение; F — полный контроль.

/R user — удаляет для указанного пользователя права на доступ к объекту.

/P user:perm — изменяет для указанного в параметре user пользователя права на доступ к объекту, которые описываются параметром perm и могут быть следующими:

N — нет; R — чтение; W — запись; C — изменение; F — полный контроль.

/D user — запрещает применять пользователю доступ к указанному объекту.

Утилита позволяет применять маски, например *.*, в именах файлов и папок, а также указывать в одной команде несколько пользователей. В Knowledge Base описан метод использования утилиты cacls.exe для изменения прав доступа не только пользователей, но и групп к объектам файловой системы. В этом случае синтаксис сохраняется, но имена групп берутся в кавычки (Q162786).

Active Directory и доступ к информации о безопасности

В Windows 2000 реализована новая служба качественно меняющая, кроме всего прочего, и механизмы работы с объектами файловой системы. Это Active Directory. Программный интерфейс к ней называется Active Directory Service Interfaces (ADSI). ADSI представляет собой набор COM-объектов, обеспечивающий программный интерфейс к функциям службы Active Directory. Базовые объекты системы безопасности (ACL, SID, ACE и т. д.) в ADSI те же, что и описанные выше. Существенные изменения коснулись лишь механизмов манипуляции с ними. Подробнее об ADSI я планирую рассказать в следующей статье.

Александр ЭПШТЕЙН — разработчик коммерческого и свободно распространяемого ПО для Windows и UNIX. Начальник отдела разработки ПО компании «КиберПлат.КОМ». С ним можно связаться по адресу: alex_ep@hotmail.com.