Лабораторная работа № 11. Оценка защищенности nt-системы: политика безопасности в области паролей и аудита

1. Цель работы

Получить навыки в исследовании защищенности заданной конфигурации ОС, изучить особенности организации NT-подобных операционных систем.

2. Теоретические сведения

I. Пароли

Операционные системы Windows NT/2000/XP хранят пароли в зашифрованном виде, называемом хэшами паролей (hash (англ.) — смесь, мешанина). Пароли не могут быть получены непосредственно из хэшей. Восстановление паролей заключается в вычислении хэшей по возможным паролям и сравнении их с имеющимися хэшами паролей. Аудит паролей включает в себя проверку возможных путей получения информации об учетных записях пользователей, результатом восстановления паролей является их представление в явном виде с учетом регистра.

II. Получение хэшей паролей

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

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

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

NET_API_STATUS nModalsStatus;

LPUSER_MODALS_INFO_0 UMI_0;

nModalsStatus = NetUserModalsGet(NULL,0,(LPBYTE *)&UMI_0);

if(nModalsStatus == NERR_Success)

{

//Минимальная длина пароля, символы

//UMI_0->usrmod0_min_passwd_len;

//Максимальное время жизни пароля, сек;

//UMI_0->usrmod0_max_passwd_age;

//Минимальное время жизни пароля, сек;

//UMI_0->usrmod0_min_passwd_age;

//Количество хранимых паролей для уменьшения их повторяемости";

//UMI_0->usrmod0_password_hist_len;

}

LPUSER_MODALS_INFO_3 UMI_3;

nModalsStatus = NetUserModalsGet(NULL,3,(LPBYTE *)&UMI_3);

if(nModalsStatus == NERR_Success)

{

//Сброс счётчика блокировки, сек

//UMI_3->usrmod3_lockout_observation_window;

//Количество попыток (порог) ввода пароля до блокировки;

//UMI_3->usrmod3_lockout_threshold;

//Период блокировки учётной записи, сек";

//UMI_3->usrmod3_lockout_duration;

}

III. Системный аудит

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

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

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

Параметры аудита объектов Windows хранятся в системных списках контроля доступа SACL, в отличие от прав доступа, которые располагаются в дискреционных списках контроля доступа DACL.

Следует обратить внимание на то, что в отличие от обращения к DACL, обращение к SACL требует наличия определённых типов привилегий (SE_SECURITY_NAME) у клиента. Ниже приведена функция установки заданных привилегий текущему процессу. Данная функция включает или выключает заданную привилегию у текущего процесса, возвращает нулевое значение при успешном выполнении.

bool EnabledPrivilege(LPCSTR lpcsPrivilegeName, bool bEnabled)

{

DWORD FuncRes;

//получим токен доступа по дескриптору текущего процесса

HANDLE hToken = NULL;

FuncRes = OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY|TOKEN_ADJUST_PRIVILEGES, &hToken);

if(!FuncRes) return true;

//структура привилегий

TOKEN_PRIVILEGES NewPrivilegeStruct;

//установим количество привилегий - 1

NewPrivilegeStruct.PrivilegeCount = 1;

//переведём машинное имя привилегии в уникальный идентификатор LUID - LocalUniqueIdetifier

LUID luid;

LookupPrivilegeValue(NULL, lpcsPrivilegeName, &luid);

NewPrivilegeStruct.Privileges[0].Luid = luid;

//включим привилегию

NewPrivilegeStruct.Privileges[0].Attributes = bEnabled?SE_PRIVILEGE_ENABLED:0;

FuncRes = AdjustTokenPrivileges(hToken, false, &NewPrivilegeStruct, sizeof(TOKEN_PRIVILEGES), NULL,NULL);

if(!FuncRes)

{

CloseHandle(hToken);

return true;

}

CloseHandle(hToken);

return false;

}

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

Следует добавить, что информация о каждом событии журнала аудита хранится в структуре типа EVENTLOGRECORD, сразу за которой содержатся дополнительные недокументированные данные о событии: информация об источнике, дескриптор безопасности и т.д. Дата и время генерации события в такой структуре отличается от принятого в Win32 API. Это время измеряется в секундах, прошедших с 00:00:00 (по всемирному координированному времени, UCT) 1 января 1970 года. Ниже приведён код функции EventTimeToLocalSystemTime для перевода такого типа времени в стандартное время, описанного структурой SYSTEMTIME.

void EventTimeToLocalSystemTime(DWORD dwEventTime, SYSTEMTIME* pstTime)

{

SYSTEMTIME st1970;

// Create a FILETIME for 00:00:00 January 1, 1970

st1970.wYear = 1970;

st1970.wMonth = 1;

st1970.wDay = 1;

st1970.wHour = 0;

st1970.wMinute = 0;

st1970.wSecond = 0;

st1970.wMilliseconds = 0;

union {

FILETIME ft;

LONGLONG ll;

} u1970;

SystemTimeToFileTime(&st1970, &u1970.ft);

union {

FILETIME ft;

LONGLONG ll;

} uUCT;

// Scale from seconds to 100-nanoseconds

uUCT.ll = 0;

uUCT.ft.dwLowDateTime = dwEventTime;

uUCT.ll *= 10000000;

uUCT.ll += u1970.ll;

FILETIME ftLocal;

FileTimeToLocalFileTime(&uUCT.ft, &ftLocal);

FileTimeToSystemTime(&ftLocal, pstTime);

}

Также приведём фрагмент кода, выдающий установки политики системного аудита, т.е. тех событий, аудитирование которых производит система:

NTSTATUS ntsResult;

//Дескриптор объекта LSA

LSA_HANDLE lsahPolicyHandle;

//Reserved, must be NULL

LSA_OBJECT_ATTRIBUTES ObjectAttributes;

ZeroMemory(&ObjectAttributes, sizeof(ObjectAttributes));

//Открытие объекта LSA

ntsResult = LsaOpenPolicy(NULL,&ObjectAttributes,POLICY_ALL_ACCESS,&lsahPolicyHandle);

if(ntsResult)

{

//обработка ошибки

return;

}

//структура с инф. о событиях аудита

PVOID AuditEvents;

ntsResult = LsaQueryInformationPolicy(lsahPolicyHandle,PolicyAuditEventsInformation,&AuditEvents);

if(ntsResult)

{

//обработка ошибки

return;

}

LsaClose(lsahPolicyHandle);

//Выделим необходимую информацию из полученной структуры

DWORD dwAuditMask;

for(DWORD i = 0;i<(((PPOLICY_AUDIT_EVENTS_INFO)AuditEvents)->MaximumAuditEventCount);i++)

{

switch(i)

{

case AuditCategorySystem:

//"Аудит системных событий";

break;

case AuditCategoryLogon:

//"Аудит входа в систему";

break;

...

}

LsaFreeMemory(AuditEvents);

}