ИИтог

Исследователи Silent Signal разобрали шифр API IBM i QSYRUPWD

безопасностьРедакция ИИтогHacker News🔥51Рейтинг ИИтог51Влияние45Новизна70Релевантность55Неожиданность35Участники30Достоверность82

IBM i (бывший AS/400), корпоративная платформа, на которой до сих пор держат критичные для бизнеса системы: ERP, финансы, логистику, производство. У неё есть системный API QSYRUPWD (Retrieve Encrypted User Password), который отдаёт авторизованному вызывающему коду связанные с паролем данные пользователя в зашифрованном виде; IBM описывает его как часть набора security-API для работы с шифрованными паролями, нужного, например, для синхронизации и миграции паролей между системами.

Во время одного из пентестов IBM i исследователь Silent Signal обнаружил на клиентском сервере системное значение QPWDLVL = 2. Этот параметр определяет одновременно правила паролей и формат хранимых верификаторов: по документации IBM, уровни 0 и 1 используют старую схему на основе DES, уровни 2 и 3, схему на основе SHA-1, а уровень 4 вводит модель верификатора на основе PBKDF2. При QPWDLVL = 2 система, по тем же документам IBM, сохраняет совместимость сразу с несколькими форматами верификаторов, а не удаляет старые.

Инструмент John the Ripper умеет взламывать пароли IBM i, под старые DES- и SHA-1-варианты в нём есть отдельные форматы as400_des и as400_ssha1. Но в тестах автора данные, которые возвращал QSYRUPWD на системах с QPWDLVL 2, 4, не совпадали по структуре с тем, что ждут эти форматы John the Ripper, тогда как для устаревшего QPWDLVL 0, 1 материал от QSYRUPWD этими же форматами читался нормально. Автор подчёркивает: это эмпирическое наблюдение по итогам его тестов и разбора инструментов, а не утверждение, что IBM где-то публично документирует точную структуру вывода для уровней 2, 4. В итоге даже при наличии специальных полномочий *ALLOBJ и *SECADM, обязательных для вызова QSYRUPWD, использовать API для практической проверки стойкости паролей стало нельзя.

После этого пентеста автор решил разобрать QSYRUPWD подробно. Сначала он написал небольшую CL-программу (PWDDUMP), которая вызывает QSYRUPWD с форматом UPWD0100 и печатает содержимое возвращаемого буфера, просто чтобы увидеть, какие данные API реально отдаёт при разных QPWDLVL. Затем с помощью системной команды STRTRC он снял трассировку вызовов внутри QSYRUPWD во время работы PWDDUMP и написал свой скрипт, чтобы превратить сырой спул-файл трассировки в читаемую цепочку вызовов. В этой цепочке среди прочего обнаружились функции QSYMIUTLS/QSYCIPHER (qsy_cipher) и QSYCODEUTL/QSYAESFNC (qsy_aes_decrypt), их названия прямо указывали на криптографические операции, включая, судя по имени функции, работу с AES.

Дальше в ход пошёл дизассемблер: через System Service Tools (SST), сервисный интерфейс IBM i для низкоуровневой диагностики, автор выгрузил ассемблерный код сервисных программ QSYMIUTLS, QSYCODEUTL, QZLSRTPW и QSYRUPWD. Для доступа к SST профилю пользователя нужны отдельные полномочия *SERVICE и отдельные, независимые от ОС учётные данные внутри самой SST. В дизассемблированном коде функций qsy_cipher и qsy_aes_decrypt автор искал явные криптографические операции, узнаваемую реализацию раундов блочного шифра, генерацию ключевого расписания или прямые вызовы задокументированных крипто-API, но не нашёл: код, судя по всему, передаёт эту работу более низкоуровневым процедурам. Захваченный текст статьи обрывается на разборе очередного фрагмента ассемблерного листинга функции qsy_cipher, не дойдя до итогового вывода о том, куда именно делегируется шифрование и удалось ли в итоге получить рабочий метод взлома паролей уровня QPWDLVL 2, 4.

Ключевые факты

  • На IBM i системное значение QPWDLVL определяет формат хранения паролей: уровни 0, 1, DES, 2, 3, SHA-1, уровень 4, PBKDF2 (по документации IBM).
  • На серверах с QPWDLVL 2 вывод API QSYRUPWD перестал совпадать с форматами as400_des и as400_ssha1 в John the Ripper, практическая проверка стойкости паролей через этот API стала невозможна даже при полномочиях *ALLOBJ и *SECADM.
  • Автор написал CL-программу PWDDUMP (формат UPWD0100), снял трассировку вызовов через STRTRC и дизассемблировал сервисные программы QSYMIUTLS/QSYCODEUTL/QZLSRTPW/QSYRUPWD через System Service Tools (требует полномочий *SERVICE).
  • В трассировке нашлись функции с говорящими именами qsy_cipher и qsy_aes_decrypt, но их дизассемблированный код явных криптографических операций не содержит, работа делегируется более низкоуровневым процедурам.
  • Захваченный текст обрывается посреди разбора ассемблерного листинга, итоговый вывод о механизме шифрования и об успехе взлома паролей QPWDLVL 2, 4 в материале не зафиксирован.

Почему это важно

IBM i остаётся рабочей лошадкой для критичных бизнес-систем, ERP, финансов, логистики, производства, и штатный API для работы с зашифрованными паролями там до сих пор не полностью описан документацией IBM в части внутреннего формата вывода. Материал показывает, что даже официальный, задокументированный API для администраторов может менять внутренний формат данных между версиями системного значения QPWDLVL так, что существующие инструменты для проверки стойкости паролей перестают его понимать, при этом никакого объявления об этом изменении в статье не упомянуто.

Кому это важно

В первую очередь администраторам и специалистам по безопасности IBM i, которые пользуются QSYRUPWD для миграции или синхронизации паролей и проверки их стойкости, а также разработчикам и мейнтейнерам инструментов вроде John the Ripper, чьи форматы as400_des и as400_ssha1 рассчитаны на устаревшую структуру данных и не покрывают вывод QPWDLVL 2, 4.

Как это применить

Разбор API на IBM i, по описанию автора, идёт в три шага: сначала пишется собственная CL-программа, которая вызывает нужный API (в этом случае QSYRUPWD с форматом UPWD0100) и печатает возвращаемый буфер; затем системной командой STRTRC снимается трассировка вызовов внутри API во время работы этой программы, а спул-файл трассировки конвертируется в читаемую цепочку вызовов; наконец через System Service Tools (SST, доступ требует полномочий *SERVICE и отдельных SST-учётных данных) дизассемблируются интересующие сервисные программы для изучения конкретных функций.

Можно ли доверять

Источник, технический блог компании Silent Signal, специализирующейся на исследованиях безопасности; материал подробно документирует каждый шаг (код CL-программы, команды STRTRC, путь через меню SST, цепочку трассировки вызовов) и опирается на собственные наблюдения автора, а не на догадки, при этом сам автор прямо оговаривает, что несовпадение форматов на QPWDLVL 2, 4 это его эмпирическое наблюдение, а не задокументированный IBM факт. У материала, однако, есть ограничения: в захваченном тексте не указаны имя и должность автора, не назван клиент или отрасль, где проводился пентест, не упомянуты CVE или официальная реакция IBM, а сам текст обрывается до финального вывода исследования.

Риски и подводные камни

Главный практический риск, для тестировщиков и администраторов, которые полагались на связку QSYRUPWD и John the Ripper для проверки стойкости паролей: на системах с QPWDLVL 2, 4 эта проверка больше не работает так, как раньше, и требует либо обновления инструментов, либо иного метода. С точки зрения самого исследования риск в том, что доступный фрагмент текста не подтверждает и не опровергает, был ли в итоге раскрыт полный механизм шифрования пароля или найден способ извлечь пароли на QPWDLVL 2, 4, код функций qsy_cipher и qsy_aes_decrypt, судя по названию и по отсутствию найденных в дизассемблированном коде явных крипто-операций, лишь передаёт работу дальше, а куда именно, в обрезанном тексте не сказано.