Этой записью в блог мы начинаем цикл постов о паролях в SAP-системах: о том, как различные пароли хранятся в системе, как защищаются и передаются.
На первый взгляд все просто — хранить пароли нужно в базе данных. Конечно, в случае обычных пользователей так и есть: пароли хранятся в виде хешей в БД. Однако для служебных пользователей SAP-системы не все так просто.
Ввиду сложных архитектурных особенностей ERP-системы, разработчикам из компании SAP приходится использовать различные типы хранилищ для такой критичной информации, как пароли системных пользователей.
Что ж, обсудим, как надежно реализованы эти хранилища и может ли атакующий использовать их недостатки в своих целях.
Рассмотрим ABAP стек SAP-систем, как наиболее распространенный среди внедрений.
В ABAP-стеке такая критичная информация, как пароли, обычно хранится в сущности, которая называется ABAP Secure Storage.
ABAP Secure Storage бывает 2 типов:
1) ABAP Secure Storage
2) ABAP Secure Storage in the File System
Начнем с ABAP Secure Storage. Данный вид хранилища представлен в виде таблицы RSECTAB в БД, которая хранит в себе информацию о паролях из:
– RFC destinations
– Exchange Infrastructure (XI)
– LDAP system users
– SAPphone
– SAPconnect
– CCMS (Generic Request and Message Generator)
Информация в данной табличке клиентозависимая: используя стандартную SAP-транзакцию SE16, не удастся увидеть записи других клиентов, более того, не будут отображаться и зашифрованные данные вашего номера клиента.
Используя транзакцию SECSTORE, можно узнать, зашифрованные данные каких сущностей хранятся в Secure Storage. Сами зашифрованные значения увидеть также не удастся.
Однако если заглянуть в табличку напрямую, используя SQL-запросы, то можно увидеть всю хранимую в ней информацию:
Непосредственно зашифрованная полезная нагрузка хранится в колонке DATA.
Результат работы SQL-запроса: select IDENT,rawtohex(DATA) from RSECTAB
Давайте разберемся, какие типы шифрования, ключи и формат хранения применяются в ABAP Secure Storage.
Для хранения зашифрованных данных используются два формата: rsec_data_v2 и rsec_data_v3. Отличаются они незначительно:
Рассмотрим третью версию данной структуры. Как можно заметить, кроме непосредственно полезной нагрузки в ней присутствует информация о системе (SID), сигнатуры и несколько служебных полей, которые используются в процессе шифрования.
Незашифрованная структура выглядит примерно следующим образом:
Для шифрования используется 3DES mode: DES-EDE3. В данной конфигурации настроен ключ длиной 24 байта и последовательность операций encrypt-decrypt-encrypt с 3 различными ключами на основе 24-байтового ключа. Первый ключ — байты с 1 по 8, второй ключ — байты с 9 по 16, третий ключ — байты с 17 по 24.
Применяются 2 этапа шифрования.
На первом этапе SAP шифрует только часть данных из структуры rsec_data_v3. Шифруются следующие поля:
– char randomPrefix[2];
– char payload[109];
– char payloadLength;
– char magicLocal[4];
– char magicGlobalSalted[4];
– char recordIdenti?erA7Hash[16];
Ключ для первого этапа шифрования генерируется на основе стандартного системного ключа. Ключ для первого этапа вычисляется следующим образом:
Key’def[1] = Keydef[1] ^ (Hsup[0] & 0xF0)
Key’def[6] = Keydef[6] ^ (Hsup[0] & 0x0F)
Key’def[7] = Keydef[7] ^ (Hsup[3] & 0xF0)
Key’def[10] = Keydef[10] ^ (Hsup[1] & 0xF0)
Key’def[13] = Keydef[13] ^ (Hsup[1] & 0x0F)
Key’def[16] = Keydef[16] ^ (Hsup[4] & 0x0F)
Key’def[19] = Keydef[19] ^ (Hsup[2] & 0xF0)
Key’def[20] = Keydef[20] ^ (Hsup[2] & 0x0F)
, где:
Key’def — ключ для первого этапа шифрования
Hsup — md5(sidA7[3]+insnoA7[10])
Keydef — стандартный системный ключ. Откуда берется его значение, описано чуть ниже
Итак, после первого этапа шифрования наша структура стала выглядеть примерно так:
Можно заметить, что не все ее значения зашифрованы. Так как значения sidA7 и insnoA7 использовались для генерации ключа первого этапа, они остались пока не защищенными. Именно для их шифрования и предназначен второй этап.
На втором этапе шифрованию подвергается вся структура целиком. В качестве ключа используется Keydef — стандартный системный ключ.
После второго этапа шифрования мы получаем значение, которое и записывается в поле DATA таблицы RSECTAB:
Во всем механизме остался только один неясный момент — значение стандартного ключа, на основе которого генерируется ключ для первого этапа шифрования и который используется в чистом виде для второго этапа.
Оказывается, значение стандартного ключа захардкожено в одном из приложений SAP-системы. Правда, в зашифрованном виде. Алгоритм шифрования – 3DES-EDE2.
Чтобы узнать ключ для шифрования, нужно его сначала расшифровать. Для данной операции опять же нужен ключ (надеюсь, что вы все еще читаете этот текст и понимаете его :) ).
Как ни странно, ключ для расшифровки стандартного ключа также захардкожен в коде одного из приложений SAP-системы, однако уже в чистом виде.
Keyrsec — ключ для расшифровки стандартного ключа
Keydef — стандартный системный ключ
Вот теперь все элементы механизма известны. Процесс расшифрования выполняется в обратном порядке.
Какие же недостатки у такого механизма? Дело в том, что значение стандартного ключа шифрования одинаково на всех SAP-инсталляциях. Таким образом, атакующий, однажды получив стандартный ключ (это несложно, ведь все данные, как вы поняли, вшиты в код программ), может использовать его для расшифровки данных из ABAP Secure Storage. А так как большая часть данных в Secure Storage — это пароли из RFC destinations, то, узнав их, атакующий может получить доступ и на соседние SAP-системы.
Пример работы программы, которая позволяет расшифровать данные из ABAP Secure Storage:
Защита
Как же не допустить компрометации данных из ABAP Secure Storage?
1) В первую очередь необходимо сменить стандартный ключ шифрования. Текущий статус ключа можно узнать в транзакции SECSTORE.
Для того чтобы изменить стандартный ключ, необходимо выполнить транзакцию SECSTORE и в соответствующей секции ввести значение нового ключа для шифрования Secure Storage. Также вы можете выбрать опцию, где новый ключ будет сгенерирован случайным образом.
После того как ключ будет изменен, его значение будет храниться в файле SecStoreDBKey.pse
Полный путь до файла будет определен в SAP-параметре rsec/securestorage/keyfile
2) Ограничить доступ к файлу индивидуального ключа SecStoreDBKey.pse
Получив доступ к данному файлу, атакующий узнает ключ шифрования и сможет расшифровать данные из Secure Storage.
3) Установить SAP Notes 1902258, 1902611 и 1922423.
Ссылки по теме:
2) All your SAP P@$$w0ЯdZ belong to us
Автор: chipik
