Як влаштований ABAP Secure Storage SAP

Цим записом в блозі ми починаємо цикл постів про паролі в 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.

Посилання по темі:

1) Secure Storage (ABAP)

2) All your SAP P@$$w0ЯdZ belong to us

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.