Подход к тестированию на проникновение мейнфреймов на базе z/OS. Погружение в RACF

В предыдущей статье мы разобрали техники по тестированию на проникновение мейнфреймов компании IBM на базе z/OS с пакетом безопасности Resource Access Control Facility (RACF). Во второй части исследования мы более детально погрузимся в структуру RACF: изучим логику принятия решения, структуру базы данных и взаимодействия сущностей этой подсистемы друг с другом. Для автономного анализа базы данных RACF мы создали собственную утилиту — racfudit, с помощью которой выполним возможные проверки и оценку безопасности конфигурации RACF. В ходе исследования мы также опишем цепочки взаимосвязей сущностей RACF (пользователей, ресурсов, датасетов), используя которые можно определить способы повышения привилегий пользователя z/OS.

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

Внутреннее устройство RACF

Общая роль

Для подробного анализа RACF вспомним роль этой подсистемы и ее компонентов в общей архитектуре z/OS. Как показано на рисунке выше, в общем случае RACF можно разделить на сервисную часть и базу данных. Существуют и другие компоненты, например утилиты для администрирования RACF и управления этим пакетом или решение RACF Auditing and Reporting, отвечающее за логирование событий и подготовку отчетов по ним. Но для общего понимания процесса, на наш взгляд, эти компоненты необязательны. База данных RACF используется для хранения информации об имеющихся в z/OS пользователях и ресурсах, для которых настроен контроль доступа. На основе этой информации сервисная часть RACF, в свою очередь, выполняет все необходимые проверки безопасности по запросу от других компонентов и подсистем z/OS. Взаимодействие RACF с другими подсистемами происходит, как правило, через интерфейс System Authority Facility (SAF): к нему обращаются различные компоненты z/OS, чтобы авторизовать пользователя для доступа к необходимым ресурсам или выполнить запрошенную пользователем операцию. Отметим, что в этом исследовании мы разберем принцип работы стандартного пакета безопасности, RACF, однако в z/OS могут использоваться и другие пакеты безопасности, например ACF2 или Top Secret.

Рассмотрим пример авторизации пользователя в подсистеме Time Sharing Options (TSO — аналог командной строки в мире z/OS). Для подключения к мейнфрейму мы будем использовать эмулятор терминала x3270. После успешной аутентификации пользователя в z/OS подсистема TSO через SAF обращается к пакету безопасности RACF, чтобы проверить, имеет ли пользователь права доступа к менеджеру ресурсов TSO. Сервис RACF запрашивает в базе данных информацию о пользователе, которая хранится в пользовательском профиле (User Profile). Если в БД имеется запись о нужных правах доступа, пользователь проходит авторизацию, и информация из пользовательского профиля помещается в адресное пространство созданной TSO-сессии в блок управления ACEE (Accessor Environment Element). При последующих обращениях к другим ресурсам z/OS в рамках этой TSO-сессии решение о предоставлении доступа пользователю принимается на основе информации в ACEE. SAF считывает данные из ACEE и передает их в сервис RACF, где, в зависимости от информации из соответствующего профиля запрашиваемого ресурса, хранящегося в базе данных, принимается решение о предоставлении доступа или отказе в нем. Затем это решение отправляется в SAF, и на его основании обрабатывается пользовательский запрос. При последующих попытках пользователя получить доступ к другим ресурсам или выполнить команды в рамках TSO-сессии процесс обращения к RACF повторяется.

Таким образом, RACF отвечает за идентификацию, аутентификацию и авторизацию пользователей, а также получение ими привилегий в рамках системы z/OS.

Компоненты базы данных RACF

Как было отмечено выше, решение о предоставлении доступа пользователям к ресурсам внутри z/OS принимается на основании информации из базы данных RACF. Такая информация хранится в виде записей или, если использовать терминологию RACF, профилей, в которых содержатся сведения о конкретном объекте z/OS. Существуют четыре основных типа профиля, которые представляют наибольший интерес с точки зрения исследования безопасности, хотя в базе данных RACF могут присутствовать и другие типы.

1. Пользовательский профиль (User Profile) содержит информацию о пользователе: логин, хэш пароля, список специальных атрибутов, группы, в которых состоит пользователь, и т. д.
2. Групповой профиль (Group Profile) содержит информацию о группе: участниках, владельце, специальных атрибутах, списках подгрупп, правах доступа участников группы по отношению к ней.
3. Профиль датасета (Data Set Profile) содержит информацию о датасете: правах доступа к датасету, атрибутах, политике аудита и т. д.
4. Основной профиль (General Profile) содержит информацию о ресурсе или ресурсном классе: держателях ресурса, их правах на ресурс, политике аудита, владельце ресурса и т. д.

Экземпляров профилей в базе данных RACF большое множество, и в совокупности они образуют достаточно сложную структуру взаимосвязей между объектами и субъектами внутри z/OS, на основе которой и принимается решение о предоставлении доступа.

Логическая структура профилей базы данных RACF

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

• BASE — основная информация о пользователе в RACF (обязательный сегмент);
• TSO — параметры TSO-сессии пользователя;
• OMVS — параметры сессии пользователя в подсистеме z/OS UNIX;
• KERB — данные о службе z/OS Network Authentication Service, которые необходимы для работы с протоколом Kerberos;
• и другие.

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

• PASSWORD — хэш пароля пользователя;
• PHRASE — хэш парольной фразы пользователя;
• LOGIN — логин пользователя;
• OWNER — владелец пользовательского профиля;
• AUTHDATE — дата создания учетной записи в базе данных RACF;
• и другие.

Особый интерес для исследования представляют поля PASSWORD и PHRASE, о которых мы подробнее расскажем далее.

Структура базы данных RACF

Стоит отметить, что база данных RACF хранится в виде специального датасета с определенным форматом, понимание которого очень помогает при анализе БД и определении взаимосвязей между объектами и субъектами z/OS.

Как мы рассказывали в предыдущей статье, датасет — это аналог файла внутри мейнфрейма, который состоит из набора блоков.

На рисунке выше приведена структура базы данных RACF, которая описывает используемые в ней блоки данных со смещениями. Наиболее интересными среди них, с точки зрения анализа БД RACF и последующего определения взаимосвязей между объектами и субъектами z/OS, являются следующие:

• Заголовок (Inventory Control Block, ICB), который содержит различную метаинформацию и указатели на все остальные блоки данных в базе данных RACF. Прочитав заголовок, можно получить доступ к остальным блокам данных.
• Индекс-блоки (Index Blocks), образующие однонаправленный список, который содержит указатели на все профили и их сегменты в базе данных RACF, то есть на информацию обо всех пользователях, группах, датасетах и ресурсах.
• Шаблоны (Templates) — очень интересный и важный блок данных, который содержит шаблоны всех типов профилей (пользовательский, групповой, профиль датасета, основной). В шаблонах перечислены поля с указанием формата для каждого возможного типа сегмента внутри соответствующего типа профиля.

Разобравшись в структуре базы данных RACF, мы определили потребность в утилите, которая позволила бы извлечь всю интересующую нас информацию о профилях из БД, независимо от ее версии, а также сохранить полученные сведения в удобном виде для дальнейшего анализа в автономном режиме. Проведение такого анализа формирует полную картину взаимосвязей между всеми объектами и субъектами для конкретной инсталляции z/OS и помогает найти потенциальные проблемы безопасности, позволяющие выполнить повышение привилегий или горизонтальное перемещение.

Утилиты для анализа БД RACF

Итак, на предыдущем этапе мы определили следующие требования к функциональности утилиты:

1. Возможность автономного анализа профилей RACF без необходимости запуска команд на мейнфрейме.
2. Получение исчерпывающей информации о профилях RACF, хранящихся в БД.
3. Поддержка различных версий БД RACF.
4. Удобный механизм навигации в полученных данных и возможность их представления в разном формате (plain text, JSON, SQL и т. д.).

Обзор существующих решений для анализа БД RACF

Сначала мы проанализировали готовые инструменты и оценили возможность их применения для наших задач.

• Racf2john — позволяет извлечь из базы данных RACF хэши пользовательских паролей (поле PASSWORD), зашифрованные алгоритмами DES и KDFAES. Неплохо для начала, но, помимо PASSWORD, нам необходимо получить содержимое и других полей профилей, в частности PHRASE.
• Racf2sql — принимает на вход дамп БД RACF и конвертирует его в БД SQLite, к которой можно обращаться через SQL-запросы. Это удобно, но в процессе конвертации могут потеряться данные, важные для анализа защищенности z/OS и поиска ее мисконфигураций. К тому же утилите необходимо на вход предоставлять не исходную базу данных, а ее дамп, полученный с помощью утилиты z/OS IRRDBU00, входящей в состав пакета безопасности RACF.
• IRRXUTIL — позволяет создавать запросы к БД RACF и извлекать из нее информацию. Эта утилита также входит в состав пакета безопасности RACF. Для работы с этим инструментом удобно использовать набор скриптов на языке REXX (интерпретируемый язык, используемый в z/OS). Однако такие скрипты требуют расширенных привилегий: доступ к одному или нескольким ресурсам IRR.RADMIN.** в ресурсном классе FACILITY, а также они должны запускаться на самом мейнфрейме, что не подойдет для наших задач.
• Racf_debug_cleanup.c — анализирует БД RACF напрямую из копии датасета. Однако у этой утилиты есть существенные недостатки: она разбирает только сегменты типа BASE и выдает результат в текстовом виде.

Как видно, существующие инструменты не удовлетворяют нашим потребностям. Часть утилит требует запуска непосредственно на мейнфрейме. Другие работают с копией датасета и извлекают неполную информацию из БД; кроме того, они построены на заданных в коде смещениях и сигнатурах внутри сегментов профилей, которые могут отличаться в разных версиях RACF. Поэтому мы решили создать собственную утилиту для анализа базы данных RACF.

Описание утилиты racfudit

Мы написали собственную платформонезависимую утилиту racfudit на Golang и протестировали ее на разных версиях z/OS (1.13, 2.02, 3.1). Далее мы подробно расскажем о принципе работы, возможностях и преимуществах нашего инструмента.

Получение данных из БД RACF

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

• На первом этапе выполняется анализ шаблонов (Templates), хранящихся внутри БД. Каждый шаблон описывает соответствующий ему тип профиля, входящие в него сегменты, а также поля этих сегментов с указанием их типа и размера. В результате независимо от версии RACF мы можем получить актуальный список типов профилей и используемых в них сегментов со списком полей.
• На втором этапе выполняется проход по всему списку индекс-блоков (Index Blocks) и извлечение всех профилей с их содержимым из БД RACF. После этого собранные профили обрабатываются и разбираются на основе ранее полученных шаблонов.

Следует отметить важность первого этапа, так как профили в БД RACF хранятся как массив байтов, не имеющих какой-либо структуры, и именно шаблоны определяют способ обработки каждого конкретного профиля (массива) в зависимости от его типа.

Таким образом мы определили алгоритм работы утилиты для извлечения структурированных данных из БД RACF, представленный на рисунке ниже:

1. Из мейнфрейма выгружается БД RACF, считывается ее заголовок (ICB), при помощи которого определяется местоположение шаблонов.
2. На основе шаблона каждого типа профиля определяется алгоритм, по которому будут в дальнейшем структурироваться конкретные экземпляры профилей в зависимости от типа.
3. В содержимом заголовка определяется местоположение индекс-блоков, которые хранят указатели на все экземпляры профилей.
4. Последовательно читаются все экземпляры профилей и их сегменты из списка индекс-блоков.
5. Для каждого прочитанного экземпляра профиля и его сегментов применяется алгоритм обработки на основе соответствующего шаблона.
6. Все обработанные экземпляры профилей сохраняются в промежуточном состоянии для возможности их дальнейшего сохранения в различном виде (plain text, SQLite).

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

Анализ полученной информации из БД RACF

Утилита racfudit позволяет представить собранную информацию из БД RACF в виде базы данных SQLite или файла с данными в формате plain text.

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

Сбор хэшей паролей

Одной из основных первичных задач в тестировании на проникновение является получение списка администраторов и возможности авторизоваться с их учетными данными. Это может быть полезно для закрепления на текущем мейнфрейме, горизонтального перемещения на другие мейнфреймы или даже на серверы с другой операционной системой. Администраторы находятся в группе SYS1, а также ее подгруппах. Пример ниже описывает запрос на получение хэшей паролей (PASSWORD) и парольных фраз (PHRASE) привилегированных пользователей, находящихся в группе SYS1.

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

Поиск недостаточного контроля в настройке UACC в датасетах

Universal Access Authority (UACC) — это права доступа к датасету по умолчанию. Этот параметр описывает уровень доступа к датасету для всех пользователей, для которых не настроены особые права доступа. Недостаточный контроль значений UACC может представлять опасность, если высокие права доступа (UPDATE или выше) настроены для датасета с чувствительными данными или для APF-библиотеки, что позволит повысить привилегии. С помощью запроса ниже можно найти датасеты, для которых по умолчанию установлены права доступа ALTER, позволяющие читать, удалять и вносить изменения в датасет.

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

Взаимосвязи профилей RACF

Как было упомянуто ранее, между различными сущностями в RACF существуют взаимосвязи. Какие-то определены явно, к примеру, имя пользователя может содержаться в групповом профиле в поле участников группы (поля USERID). Но есть и неявные связи. Например, группа пользователей обладает правом доступа UPDATE на определенный датасет. В таком случае каждый участник группы неявно имеет право на запись в этот датасет. Это простой пример неявных связей. Далее мы рассмотрим более сложные и специфичные связи в базе данных RACF, которые могут использоваться пентестером.

Поля профилей RACF

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

Поля пользовательского профиля:

• SPECIAL — определяет, что пользователь имеет привилегии выполнять любые команды RACF, и дает ему полный контроль над всеми профилями в базе данных RACF.
• OPERATIONS — определяет, что пользователь имеет авторизационный доступ ко всем защищенным в RACF ресурсам классов DATASET, DASDVOL, GDASDVOL, PSFMPL, TAPEVOL, VMBATCH, VMCMD, VMMDISK, VMNODE и VMRDR. Несмотря на то что действия пользователя, для которого указано это поле, ограничены рядом исключений, в контексте тестирования на проникновение поле OPERATIONS свидетельствует о полном доступе к датасетам.
• AUDITOR — определяет, что пользователь имеет права на доступ к информации об аудите.
• AUTHOR — создатель пользователя. Имеет определенные привилегии по отношению к пользователю, к примеру может сменить пароль.
• REVOKE — определяет, имеет ли пользователь права на вход в систему.
• Password TYPE — определяет тип хэша пароля и парольной фразы (DES, KDFAES). Такого поля нет в пользовательском профиле, но его можно создать, опираясь на особенности хранения разных типов паролей и парольных фраз.
• Group-SPECIAL — определяет, что пользователь обладает полным контролем над всеми профилями в области влияния (scope), указанной в поле группы или групп. Довольно интересное поле, о котором мы расскажем подробнее.
• Group-OPERATIONS — определяет, что пользователь имеет авторизационный доступ ко всем защищенным в RACF ресурсам классов DATASET, DASDVOL, GDASDVOL, PSFMPL, TAPEVOL, VMBATCH, VMCMD, VMMDISK, VMNODE и VMRDR в области влияния, указанной в поле группы или групп.
• Group-AUDITOR — определяет, что пользователь имеет права на доступ к информации об аудите в области влияния, указанной в поле группы или групп.
• CLAUTH (Class Authority) — позволяет пользователю создавать профили в указанном классе или классах. Это поле позволяет делегировать привилегии на управление отдельными классами.
• GROUPIDS — содержит список групп, в которые входит пользователь.
• UACC (Universal Access Authority) — определяет значение UACC для новых профилей, которые создает пользователь.

Поля группового профиля:

• UACC (Universal Access Authority) — определяет значение UACC для новых профилей, которые создает пользователь при подключении к группе.
• OWNER — создатель группы. Имеет определенные привилегии по отношению к текущей группе и ее подгруппам.
• USERIDS — список пользователей, входящих в группу. Порядок важен.
• USERACS — список пользователей — участников группы с указанием прав доступа по отношению к ней. Порядок важен.
• SUPGROUP — название родительской группы.

Поля основного профиля и профиля датасета:

• UACC (Universal Access Authority) — определяет права доступа к конкретному ресурсу или датасету по умолчанию.
• OWNER — создатель ресурса или датасета. Имеет определенные привилегии по отношению к нему.
• WARNING — определяет, находится ли ресурс или датасет в режиме WARNING.
• USERID — список идентификаторов пользователей, которые имеют отношение к конкретному ресурсу или датасету. Порядок важен.
• USERACS — список пользователей, имеющих права доступа к этому ресурсу или датасету. Порядок важен.

Цепочки взаимосвязей профилей RACF

Перечисленные выше поля свидетельствуют о наличии взаимосвязей между профилями RACF. Мы решили присвоить названия этим взаимосвязям по аналогии с использующимися в BloodHound — популярном инструменте для анализа недостатков в конфигурации в Active Directory. Далее представлены некоторые примеры взаимосвязей (список не исчерпывающий):

• Owner — субъект является владельцем объекта.
• MemberOf — субъект входит в состав объекта.
• AllowJoin — субъект обладает правом добавить себя в состав объекта.
• AllowConnect — субъект обладает правом добавить другой объект в состав указанного объекта.
• AllowCreate — субъект обладает правом создавать экземпляр объекта.
• AllowAlter — субъект обладает привилегией ALTER по отношению к объекту.
• AllowUpdate — субъект обладает привилегией UPDATE по отношению к объекту.
• AllowRead — субъект обладает привилегией READ по отношению к объекту.
• CLAuthTo — субъект обладает правом создавать экземпляры объекта (прописано в поле CLAUTH).
• GroupSpecial — субъект обладает полным контролем над всеми профилями в области влияния объекта (прописано в поле Group-SPECIAL).
• GroupOperations — субъект обладает правами по отношению к объекту, прописанными в поле Group-OPERATIONS.
• ImpersonateTo — субъект дает привилегию объекту выполнять определенные операции от имени субъекта.
• ResetPassword — субъект дает привилегию другому объекту сбросить пароль или парольную фразу указанного объекта.
• UnixAdmin — субъект предоставляет привилегии суперпользователя объекту в z/OS UNIX.
• SetAPF — субъект дает привилегию другому объекту назначать флаг APF на указанный объект.

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

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

Неявные взаимосвязи профилей RACF

Мы заметили довольно интересное свойство полей group-SPECIAL, group-OPERATIONS и group-AUDITOR из пользовательского профиля. Если в одном из этих полей для пользователя указана какая-либо группа, область влияния этой группы будет расширять область влияния пользователя.

К примеру, для пользователя USER1 задано поле group-SPECIAL, в котором указана группа GROUP1. GROUP1 является владельцем группы GROUP2, а та, в свою очередь, — владельцем пользователя USER5. Это означает, что пользователь USER1 имеет привилегии по отношению к пользователю USER5, причем не только получает доступ к его данным, но и фактически является его владельцем. Такие права доступа позволяют USER1, к примеру, сменить пароль пользователя USER5, даже если последний обладает привилегированными правами (SPECIAL, OPERATIONS, ROAUDIT, AUDITOR, PROTECTED) — это особенность z/OS.

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

Запрос на поиск пользователей, владельцы (AUTHOR) которых не являются стандартно заданными администраторами:

Рассмотрим повышение привилегий пользователя за счет неявной взаимосвязи профилей на примере.

Для пользователя TESTUSR задано поле group-Special, в котором указана группа PASSADM. Эта группа является владельцем пользователя OPERATOR. Область влияния пользователя TESTUSR расширяется областью влияния группы PASSADM, а значит, он получает права над пользователем OPERATOR. Таким образом, при компрометации учетных данных TESTUSR мы получим доступ и к пользователю OPERATOR. Он, в свою очередь, обладает правом READ по отношению к ресурсу IRR.PASSWORD.RESET, что позволяет назначить пароль любому пользователю, не обладающему привилегированными правами.

Для компрометации мейнфрейма достаточно иметь высокие привилегии в z/OS UNIX. Их можно получить несколькими способами:

• назначить пользователю права READ к ресурсу BPX.SUPERUSER класса FACILITY;
• назначить пользователю права READ к ресурсам UNIXPRIV.SUPERUSER.* класса UNIXPRIV;
• назначить для поля UID значение 0 в сегменте OMVS пользовательского профиля.

Так, пользователь DFSOPER обладает правом READ для ресурса BPX.SUPERUSER и является привилегированным в z/OS UNIX, а следовательно, и во всем мейнфрейме. При этом для DFSOPER не заданы привилегированные поля SPECIAL, OPERATIONS, AUDITOR, ROAUDIT и PROTECTED, а значит, пользователь OPERATOR может изменить его пароль. Таким образом мы определили следующую последовательность действий для получения высоких привилегий в мейнфрейме:

1. получить учетные данные пользователя TESTUSR и выполнить вход с их помощью;
2. изменить пароль пользователя OPERATOR и выполнить вход с его учетными данными;
3. изменить пароль пользователя DFSOPER и выполнить вход с его учетными данными;
4. перейти в z/OS UNIX Shell с высокими привилегиями.

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

Во втором примере пользователь TESTUSR имеет доступ READ к ресурсу OPERSMS.SUBMIT в классе SURROGAT. Это означает, что при помощи взаимосвязи ImpersonateTo пользователь TESTUSR может создать задачу от имени пользователя OPERSMS. Последний состоит в группе HFSADMIN, которая, в свою очередь, имеет права READ на ресурс TESTAUTH в классе TSOAUTH. Этот ресурс определяет, может ли пользователь запускать программу или библиотеку как APF-авторизованную, причем для этого достаточно прав READ. Следовательно, пользователь OPERSMS имеет возможность повысить свои текущие привилегии до максимальных в случае неправильной конфигурации доступа к APF. Таким образом мы получаем путь от низкопривилегированного пользователя TESTUSR до получения максимальных привилегий в мейнфрейме.

На текущем этапе утилита racfudit позволяет определить подобные связи только «в ручном режиме» последовательностью запросов к базе данных SQLite. Однако мы планируем добавить в racfudit поддержку еще одного выходного формата с поддержкой СУБД Neo4j, чтобы автоматически показывать описанные выше цепочки взаимосвязей.

Хэши паролей в RACF

Итак, для повышения привилегий и получения доступа к мейнфрейму нам нужны учетные данные привилегированных пользователей. Ранее при помощи нашей утилиты мы извлекли хэши их паролей. Далее мы подробно разберем принципы парольной политики в z/OS и опишем методы восстановления паролей из собранных хэшей.

Основные методы парольной аутентификации в z/OS на базе RACF — это PASSWORD и PASSPHRASE. PASSWORD — это пароль, который по умолчанию состоит из символов ASCII: латинских букв верхнего регистра, цифр и спецсимволов (@#$). При этом длина пароля не превышает 8 символов. PASSPHRASE имеет более сложную политику: от 14 до 100 символов ASCII, включающих буквы латинского алфавита любого регистра, цифры и расширенный набор спецсимволов (@#$&*{}[]()=,.;’+/). Хэши паролей PASSWORD и PASSPHRASE сохраняются в пользовательском профиле в сегменте BASE в полях PASSWORD и PHRASE соответственно. Для получения их значений применяются два алгоритма: DES и KDFAES.

Следует отметить, что мы используем словосочетания «хэш пароля» и «хэш парольной фразы» для удобства восприятия. При использовании алгоритмов DES и KDFAES учетные данные пользователя будут храниться в БД RACF в виде зашифрованного текста, а не в виде хэш-суммы в ее классическом понимании. Тем не менее мы продолжим использовать словосочетания «хэш пароля» и «хэш парольной фразы», как это принято в документации IBM.

Поговорим чуть подробнее о принципах работы и особенностях алгоритмов DES и KDFAES.

DES

При использовании алгоритма DES вычисление значений PASSWORD и PHRASE, хранящихся в БД RACF, представляет собой классическое DES-шифрование, где блоком данных в формате plain text является имя пользователя (c дополнением до 8 символов, если его длина меньше), а ключом — пароль (также с дополнением до 8 символов, если пароль имеет меньшую длину).

PASSWORD

Имя пользователя шифруется ключом PASSWORD при помощи алгоритма DES, а результат размером 8 байт помещается в пользовательский профиль в поле PASSWORD.

Здесь следует учитывать, что имя пользователя и пароль закодированы с помощью кодировки EBCDIC. Например, имя пользователя USR1, согласно этой кодировке, будет выглядеть следующим образом: e4e2d9f140404040. Байт 0x40 является дополнением открытого текста до 8 байт.

Восстановление такого пароля производится довольно быстро, учитывая малое пространство ключей (keyspace) и низкую вычислительную сложность DES. Например, на кластере из видеокарт NVIDIA 4090 время полного перебора занимает менее 5 минут.

В ПО hashcat доступен модуль для перебора пароля RACF по алгоритму DES с номером 8500.

PASSPHRASE

Шифрование PASSPHRASE несколько сложнее. Детальное описание этого алгоритма в открытом доступе нам найти не удалось, однако в ходе исследования мы обнаружили некоторые интересные особенности.

Во-первых, итоговая длина хэша в поле PHRASE соответствует длине исходного значения парольной фразы: зашифрованные данные, получаемые на выходе DES, обрезаются до длины входного открытого текста без дополнения. Очевидно, при определенных обстоятельствах это способно приводить к коллизиям и ошибочной аутентификации. Например, если исходная длина парольной фразы равна 17 символам (байтам), то шифроваться она будет тремя блоками, последний из которых дополняется 7 байтами, — после шифрования они будут обрезаны. В таком случае правильным будет считаться любой пароль, первые 17 байт которого в зашифрованном виде совпадают с зашифрованной парольной фразой PASSPHRASE.

Вторая интересная особенность — значение поля PHRASE также вычисляется на основе алгоритма DES, однако в этом случае используется проприетарный режим сцепления блоков (назовем его условно IBM-custom mode).

Учитывая это ограничение, мы можем восстановить первые 8 символов парольной фразы по первому блоку зашифрованных данных из поля PHRASE при помощи модуля hashcat для RACF DES. В некоторых случаях на практике восстановление начала парольной фразы позволяло нам угадать оставшуюся ее часть, если использовались слабые словарные пароли. К примеру, если при восстановлении хэша PASSPHRASE из 15 байт мы подобрали ключ для первого блока и восстановили из него 8 символов Admin123, то вполне возможно, что полная парольная фраза имеет вид Admin1234567890.

KDFAES

Вычисление значений паролей и парольных фраз, созданных при помощи алгоритма KDFAES, гораздо сложнее, чем DES. KDFAES — это проприетарный алгоритм IBM с применением AES-шифрования, ключ для которого генерируется на основе пароля при помощи функции PBKDF2 с определенным числом итераций хэширования.

PASSWORD

Алгоритм шифрования PASSWORD на базе KDFAES схематично представлен на рисунке ниже и состоит из нескольких этапов.

Первый этап аналогичен алгоритму вычисления значения PASSWORD на базе DES: имя пользователя в формате plain text шифруется алгоритмом DES с ключом PASSWORD (USERNAME также предварительно кодируется при помощи EBCDIC с дополнением, если размер имени менее 8 байт). Полученные данные длиной 8 байт являются ключом для второго этапа, хэширования: для него используется проприетарный алгоритм IBM, в основе которого лежит алгоритм PBKDF2-SHA256-HMAC. На вход вместе с 8-байтным ключом с предыдущего этапа также подается сгенерированная случайным образом 16-байтная строка (соль), которая многократно хэшируется с использованием PBKDF2-SHA256-HMAC. Количество итераций определяется двумя параметрами, устанавливаемыми в настройках RACF, — факторами памяти (memory factor) и повторений (repetition factor). Выходным значением второго этапа является 32-байтный хэш, который далее используется как ключ для AES-шифрования имени пользователя в рамках третьего этапа.

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

Поле PWDX в сегменте BASE имеет следующую структуру:

Смещение	Размер	Поле	Комментарий
0–3	4 байта	Магическое число	В исследованных профилях мы отмечали только значение E7D7E66D
4–7	4 байта	Тип хэша	В исследованных профилях мы отмечали только два значения: 00180000 для хэшей PASSWORD и 00140000 для хэшей PASSPHRASE
8–9	2 байта	Фактор памяти	Значение, определяющее число итераций на этапе хэширования
10–11	2 байта	Фактор повторений	Значение, определяющее число итераций на этапе хэширования
12–15	4 байта	Неизвестное значение	В исследованных профилях мы отмечали только значение 00100010
16–31	16 байт	Соль	Сгенерированная случайным образом 16-байтная строка, используемая на этапе хэширования
32–39	8 байт	Первая половина хэша пароля	Первые 8 байт итоговых зашифрованных данных

Для автономного подбора значения пароля по хэшу можно использовать соответствующий модуль утилиты John the Ripper. В открытом доступе также находится модуль IBM KDFAES для старой версии hashcat, но он так и не был добавлен в основную ветку, поэтому мы написали собственный модуль RACF KDFAES, который можно использовать с текущей версией hashcat.

Конечно, время подбора хэша RACF KDFAES значительно увеличилось по сравнению с RACF DES, в частности, за счет использования PBKDF2. Например, если факторы памяти (memory factor) и повторений (repetition factor) равны 0x08 и 0x32 соответственно, число итераций хэширования на втором этапе достигает 40 000, а время подбора пароля может достигать нескольких месяцев или даже лет.

PASSPHRASE

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

Кроме того, при использовании парольной фразы для хранения итогового хэша задействуются поля PHRASE и PHRASEX вместо PASSWORD и PWDX соответственно, при этом хранящееся во PHRASEX значение имеет схожую структуру.

Заключение

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

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

В заключение хотелось бы отметить, что структура базы данных RACF изучена лишь на небольшой процент. Всестороннее исследование подразумевает поиск дополнительных взаимоотношений между сущностями базы данных, дальнейшее изучение привилегий и возможностей при владении ими, а также инструментов, которые бы эксплуатировали избыточные привилегии. Не покрыта полностью тема восстановления паролей, потому что алгоритмы шифрования до конца не изучены. У исследователей мейнфреймов IBM на базе z/OS есть огромный потенциал для анализа. Мы же постараемся и дальше проливать свет на темные, неизученные стороны этих устройств, помогая избегать возможных недостатков в инфраструктуре мейнфреймов и предотвращать связанные с ними инциденты безопасности.