一見、すべてが簡単です-パスワードをデータベースに保存する必要があります。 もちろん、通常のユーザーの場合、これは事実です。パスワードはハッシュとしてデータベースに保存されます。 ただし、SAPシステムのビジネスユーザーにとってはそれほど単純ではありません。
ERPシステムの複雑なアーキテクチャ機能により、SAP開発者は、システムユーザーパスワードなどの重要な情報にさまざまなタイプのストレージを使用する必要があります。
さて、これらのリポジトリが確実に実装される方法と、攻撃者が自分の目的のために欠点を使用できるかどうかについて説明します。
SAPシステムのABAPスタックが実装の中で最も一般的であると考えてください。
ABAPスタックでは、パスワードなどの重要な情報は通常、ABAPセキュアストレージと呼ばれるエンティティに保存されます。
ABAPセキュアストレージには2つのタイプがあります。
1）ABAPセキュアストレージ
2）ファイルシステムのABAPセキュアストレージ
ABAPセキュアストレージから始めましょう。 このタイプのストレージは、データベース内のRSECTABテーブルの形式で提供され、次のパスワードに関する情報を保存します。
-RFC宛先
-Exchangeインフラストラクチャ（XI）
-LDAPシステムユーザー
-SAPphone
-SAPconnect
-CCMS（汎用要求およびメッセージジェネレーター）
このプレートの情報はクライアントに依存します。標準のSAPトランザクションSE16を使用すると、他のクライアントのレコードを表示できなくなり、さらにクライアント番号の暗号化されたデータが表示されなくなります。
SECSTOREトランザクションを使用すると、どのエンティティのどの暗号化データがセキュアストレージに保存されているかを確認できます。 暗号化された値自体も表示されません。
ただし、SQLクエリを使用してプレートを直接見ると、そこに保存されているすべての情報を確認できます。
直接暗号化されたペイロードは、DATA列に保存されます。
SQLクエリ結果：RSECTABからIDENT、rawtohex（DATA）を選択します
ABAPセキュアストレージで使用される暗号化、キー、およびストレージ形式の種類を見てみましょう。
暗号化されたデータの保存には、rsec_data_v2とrsec_data_v3の2つの形式が使用されます。 それらはわずかに異なります：
この構造の3番目のバージョンを検討してください。 ご覧のとおり、直接ペイロードに加えて、システム（SID）、署名、および暗号化プロセスで使用されるいくつかのサービスフィールドに関する情報が含まれています。
暗号化されていない構造は次のようになります。
暗号化には、3DESモード：DES-EDE3が使用されます。 この構成では、24バイトのキーと、24バイトのキーに基づく3つの異なるキーを使用した暗号化/復号化/暗号化操作シーケンスが構成されます。 最初のキーはバイト1〜8、2番目のキーはバイト9〜16、3番目のキーはバイト17〜24です。
暗号化の2段階が適用されます。
最初の段階で、SAPはrsec_data_v3構造からのデータの一部のみを暗号化します。 次のフィールドは暗号化されます。
-char randomPrefix [2];
-文字ペイロード[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は第1段階のキーを生成するために使用されていたため、これまでのところ保護されていません。 暗号化のために、第2段階が意図されています。
第2段階では、構造全体が暗号化されます。 キーは、標準システムキーであるKeydefです。
暗号化の第2段階の後、RSECTABテーブルのDATAフィールドに書き込まれる値を取得します。
メカニズム全体には不明確な瞬間が1つだけあります。標準キーの値です。これに基づいて、キーは最初の暗号化段階で生成され、2番目の段階で純粋な形式で使用されます。
標準キー値は、SAPシステムのアプリケーションの1つにハードコーディングされていることがわかります。 真、暗号化された形式。 暗号化アルゴリズムは3DES-EDE2です。
暗号化のキーを見つけるには、最初にそれを解読する必要があります。 この操作でも、キーが必要です（まだこのテキストを読んで理解してください:)）。
奇妙なことに、標準キーを復号化するためのキーも、SAPシステムのアプリケーションの1つのコードにハードコーディングされていますが、純粋な形式です。
Keyrsec-標準キーを復号化するためのキー
Keydef-標準システムキー
これで、メカニズムのすべての要素がわかりました。 復号化プロセスは逆の順序で実行されます。
そのようなメカニズムの欠点は何ですか？ 実際、標準暗号化キーの値はすべてのSAPインストールで同じです。 したがって、攻撃者は、標準キーを受信すると（これは難しくありません。理解できるように、すべてのデータがプログラムコードに埋め込まれているため）、それを使用してABAPセキュアストレージからデータを解読できます。 セキュアストレージ内のデータのほとんどはRFC宛先からのパスワードであるため、それらを認識すると、攻撃者は近隣のSAPシステムにアクセスできます。
ABAPセキュアストレージからデータを復号化できるプログラムの例：
保護
データがABAPセキュアストレージから侵害されるのを防ぐ方法
1）まず、標準暗号化キーを変更する必要があります。 現在のキーステータスは、トランザクションSECSTOREで確認できます。
標準キーを変更するには、SECSTOREトランザクションを完了し、対応するセクションにセキュアストレージ暗号化の新しいキーの値を入力する必要があります。 新しいキーがランダムに生成されるオプションを選択することもできます。
キーが変更されると、その値はSecStoreDBKey.pseファイルに保存されます
ファイルへのフルパスは、rsec / securestorage / keyfile SAPパラメーターで定義されます
2）秘密鍵ファイルSecStoreDBKey.pseへのアクセスを制限する
このファイルにアクセスすると、攻撃者は暗号化キーを認識し、セキュアストレージからデータを復号化できます。
3）SAP Notes 1902258、1902611、および1922423をインストールします。
関連リンク：
1） セキュアストレージ（ABAP）
2） すべてのSAP P @ $$w0dZは私たちのものです