[監査のアイデア] SQLMS インジェクションの脆弱性をすばやく特定する方法は?

0x00 序文

MCMS は、政府、教育、その他の業界で一般的に使用されている CMS であり、広く使用されていますが、基になるコードにはまだ多くの問題が残っています。この記事では、主に SQL インジェクションの監査に焦点を当て、SQL インジェクションの脆弱性と他のツールの適用を迅速に特定する方法について説明します。

MCMS は、完全なオープン ソース Java CMS です。SpringBoot 2 アーキテクチャに基づいて、フロント エンドは vue と要素の ui に基づいています。問題を収集して 2 か月ごとにバージョンを更新し、開発者に数百の無料テンプレートを提供し、適用可能なプラグイン (記事、モール、WeChat、フォーラム、メンバー、コメント、支払い、ポイント、ワークフロー、タスク スケジューリングなど) を提供します。 )、シンプルで使いやすいオープン ソース システムのセット、および高品質のオープン ソースのエコロジカル コンテンツ システムの完全なセット。Mingfei の使命は、開発コストを削減し、開発効率を向上させ、あらゆる種類のエンタープライズ レベルの開発ソリューションを提供することです。

0x01 監査環境

Mingsoft MCMS v5.2.8
Mysql 8.0.29
Openjdk 19.0.1

0x02 監査のアイデア

市場には、最新のコード監査用のツールがすでに数多くありますが、ソース コードを取得したら、もちろん、最初にツールを使用してスキャンし、作業時間を節約する必要があります。fortify や Qi Anxin Code Guard などのツールはありますが、いくつかのミスを回避するには、やはり人間の経験が必要です。

自動化されたコード監査ツールを活用する

ここでは、fortify ツールを使用してソース コードをスキャンし、発生した 2 つの問題を記録します。fortify ツールは有料ツールであり、この記事ではクラックされたバージョンをダウンロードする方法は提供していません。

[セキュリティについて学び、すべてのリソースを 1 つずつ入手する場所]
① ネットワーク セキュリティの学習ルート
② 20 の侵入テスト電子ブック
③ セキュリティの攻撃と防御 357 ページのノート
④ 50 のセキュリティの攻撃と防御のインタビュー ガイド
⑤セキュリティ レッド チーム ペネトレーション ツールキット
⑥ ネットワーク セキュリティ エッセンシャル ブック
⑦ 脆弱性との戦いの実例 100 件
⑧ 主要セキュリティ企業の内部ビデオ リソース
⑨ 過去の CTF キャプチャ フラグ コンテストの質問の分析

1. jar パッケージを逆コンパイルします。

コード監査のために fortify を使用して MCMS ソース コードをインポートしますが、多くの場合、その効果は不十分です。このソース コード セットは依存関係管理を含むプロジェクト管理ツール ソフトウェアとして Maven を使用するため、MCMS プロジェクトが依存する jar パッケージはすべてリモートで取得されます。その中で、net.mingsoft.ms-base、ms-basic、および ms-mdiy は、基礎となるロジック コードです。プルすると、jar パッケージの形式で存在し、自動ツールは jar パッケージをスキャンしません。

画像.png

jar パッケージの名前を zip に変更し、それを解凍してクラス ファイルを取得できます。ただし、fortify もクラス ファイルをスキャンしないため、さらに逆コンパイルする必要があります。ここで、jadx を使用して逆コンパイルできます。
画像.png

jar ファイルを直接開き、ショートカット キー Control+S を使用して逆コンパイルされたリソースを保存できます。

画像.png

エクスポート後は、スキャン可能なファイル タイプである Java ファイルです。

画像.png

2. JS ファイルをスキャンしない

コードをスキャンしているときに、あまりにも多くの JS ファイルに遭遇したため、全体的なスキャンの進行が大幅に長くなりました。これは私が望んでいたことではありません。
fortify/Core/config ディレクトリで fortify-sca.properties を見つけます

画像.png

これらの 1 つは、com.fortify.sca.DefaultFileTypes スキャンするドキュメントの種類を指定します。削除できます ,js

画像.png

手動監査 SQL インジェクションの考え方

一般に、SQL インジェクションは次の 2 つの条件を満たす必要があります。
(1) 入力パラメーターの内容がユーザーによって制御可能であること。
(2) SQL ステートメントの実行に直接的または間接的に綴られる。
また、SQL ステートメントを実行するにはさまざまな方法があります。
(1) JDBC クラス メソッドを直接使用する。
この方法で SQL ステートメントを実行するには、SELECT、DELETE、UPDATE などの SQL キーワードをグローバルに検索するか、Statement および PreparedStatement メソッド名を検索して、ステートメントが実行される場所を特定します。
(2) SQL文の実行エージェントとしてMyBatisの永続層を利用する。
MyBatis の永続化レイヤーは、通常、 #{} プリコンパイルされたメカニズムである、基になる実装のプレースホルダーとして "?" を使用します。実際には、order by一重引用符を使用できない同様の場所ではプリコンパイルを使用できず、代わりに ${}SQL ステートメントへの直接スプライシングを使用します。通常、これにはコンテンツを手動で追加する厳密なフィルタリング手順が必要です。したがって、プリコンパイルは非常に強力ですが、役に立たない場所があり、これらの場所は私たちのブレークスルーです。

0x03 監査プロセス

${}上記の説明から、使用されている場所に SQL インジェクションのリスクがある可能性があることがわかるため 、監査プロセス中にグローバルに直接検索できます${}

1. 基礎となるマッピングにインジェクションの脆弱性があり、複数のフォアグラウンド インジェクションが発生する

理由

SQL 永続層ファイルでは 、バインディング ID を sqlWhere として Sql マッピングを使用すると 、SQL インジェクションのリスクが生じることがIBaseDao.xml わかります 。${}
画像.png

最初の GET タイプ

の マッピング ステートメントをIDictDao.xml 紹介します IBaseDao.xml 。

画像.png

IDictBiz このビジネス層 では 、IBaseBiz 戻り値の型が DictEntity であることを判別するクエリがあるように継承されます。

画像.png

制御層 web/DictAction.class では、ここでリクエストパケットのデータが実体化され、直接渡されていることがわかります dictBiz.query 。
画像.png

このインターフェースをリクエストすると、渡されたすべてのパラメーターと値が DictEntity として扱われるため、ここで直接渡すことができます sqlWhere 。

画像.png

sqlWhere的值为 [{"action":"","field":"extractvalue(0x7e,concat(0x7e,(database())))","el":"eq","model":"contentTitle","name":"文章标题","type":"input","value":"a"}]

2 番目の GET タイプ

の マッピング ステートメントをIDictDao.xml 紹介します IBaseDao.xml 。idは queryExcludeApp

画像.png

制御層web/DictAction.classでは ここで要求パケットのデータが実体になり、直接渡されていることがわかりますdictBiz.queryExcludeApp

画像.png

同様に、ここで渡されたすべてのパラメーターと値は DictEntity として扱われず、同じ問題が存在します。
画像.png

3 番目の POST タイプ

の マッピング ステートメントをICategoryDao.xml 紹介します IBaseDao.xml 。
画像.png

制御層web/CategoryAction.java ではここで要求パケットのデータが実体になり、直接渡されていることがわかりますcategoryBiz.query 。

画像.png

sqlWhereここでのエンティティ タイプは変更されていますが、脆弱性を引き起こす実行を渡すことを妨げるものではありません 。

画像.png

4 番目の POST タイプ

の マッピング ステートメントをIContentDao.xml 紹介します IBaseDao.xml 。

画像.png

制御層web/ContentAction.javaではここで要求パケットのデータが実体になり、直接渡されていることがわかりますcontentBiz.query 。

画像.png

導入している限り、フィルタリングがないと抜け穴があります。

2. バックグラウンド カスタム モデルで任意の SQL ステートメントを実行する

永続層 IBaseDao.xml に id でバインドされた excuteSql SQL 操作ステートメントがあります。この場所は、受信した SQL ステートメントを直接実行します。

画像.png

永続層プロキシ IBaseDao.class は、IBaseDao.xml に対応するインターフェースを作成しました。
画像.png

IModelDao.class は IBaseDao を継承し、型を ModelEntity として決定します

画像.png

画像.png

ビジネス層 IModelBiz.class はいくつかのインターフェースを定義します

画像.png

業務実装層 ModelBizImpl.class は IModelBiz.class インターフェースを実装しており、コードを読むと IModelDao.class の excuteSql メソッドが実際に importModel 関数で使用されていることがわかります。

画像.png

ModelBizImpl.class の importModel 関数は、コントロール層の ModelAction.class の importJson 関数で呼び出されます。

画像.png

この脆弱性が発生する場所は、バックグラウンド カスタム モデルのインポート機能であり、この機能を使用するには、 https://code.mingsoft.net/ コードを生成する必要があります。

画像.png

新しいビジネス フォームを作成する --> フォーム コンポーネントをドラッグする --> フィールド名とデフォルト値を入力する --> コードを生成する

画像.png

生成されたカスタム モデル コードを確認できます。それをコピーして、sql フィールドの値をカスタム コードに変更します。

画像.png

任意の行はフィルタリングおよび制限されず、ステートメントの行は split(';')で分割されます。

画像.png

これは実際には MCMS のコア ビジネスであり、避けることはできません. したがって、MCMS を使用し、カスタム モデルをインポートする権限を持っている限り、SQL インジェクションを使用してデータまたはシステムの権限を取得できます。

3. パラメータ インターフェイスのフォアグラウンド SQL インジェクションを確認する

ここでは mybatis フレームワークが使用されているため、グローバル検索ではスプライシングに $ を使用します。/net/mingsoft/ms-base/2.1.13/ms-base-2.1.13.jar!/net/mingsoft/base/dao/IBaseDao.xml

画像.png

さらにフォローアップ queryBySQL

画像.png

対応するインターフェースで実装方法を表示

画像.png

次に/net/mingsoft/base/biz/impl/BaseBizImpl.java、ここで queryBySQL を書き直してから呼び出しますgetDao().queryBySQL

画像.png

/net/mingsoft/basic/action/BaseAction.class#validated すると、確認中に電話がかかってきたことが判明
画像.png

この時点で、検証済みのメソッドをフロントエンド ルートで呼び出すことができることを確認してから、/net/mingsoft/ms-mdiy/2.1.13.1/ms-mdiy-2.1.13.1-sources.jar!/net/mingsoft/mdiy/action/PageAction.java#verify
検証済みのメソッドが次のルートで呼び出されることを確認します。

画像.png

GetMapping を分析し、パラメーター fieldName、fieldValue、id、idName をさりげなく構築することにより、ルートを探します。最初に見たキーは、フロントエンドから渡された fieldName に対応します。

画像.png

http://127.0.0.1:8008/ms/mdiy/page/verify.do?fieldName=1;select/**/if(substring((select/**/database()),1,4)='mcms',sleep(5),1)/**/and/**/1&fieldValue=b&id=c&idName=1
fieldName`是传入了 `${key}直接拼接到SQL语句导致SQL注入。

画像.png

0x04 まとめ

コード監査は、プリコンパイルが万能薬ではないことを示しています。それ以外の場合、SQL インジェクションの脆弱性はそれほど多くありません。パラメータ値の処理にプリコンパイルが使えず、スプライシングでしか操作できないところは、危険な文字にマッチするフィルタ関数を手動で書く以外に方法はありますか? また、渡されるパラメータの型を厳密にrequireすることもできます.例えば数値の代わりに、ユーザーが入力した内容を強制的にint型に変換し、失敗するとエラーを報告する.これをフォームフィルタと呼びます.層。コードが大きすぎて脆弱性のトラブルシューティングに多くの人手を費やせない場合は、セキュリティ会社からコード監査サービスと WAF ファイアウォール製品を購入できます。

0x05 リファレンス

*   [https://gitee.com/mingSoft/MCMS/issues/I5OWGU](https://gitee.com/mingSoft/MCMS/issues/I5OWGU)
*   [https://gitee.com/mingSoft/MCMS/issues/I5X1U2](https://gitee.com/mingSoft/MCMS/issues/I5X1U2)

おすすめ

転載: blog.csdn.net/kali_Ma/article/details/128345013