Oracleデータベース：ハッカーがKhuntツールを実行

ハッカーがマルウェアツールをOracleデータベース内部に直接隠蔽するという、極めて危険な新たな攻撃手法が確認されました。TechNoidでは、この手法の仕組みと、アーキテクチャにおいて直ちに変更すべき点について分析します。

SQLインジェクションのメカニズム

Huntressのデータによると、すべてはApache Tomcat上で動作するJavaアプリケーションの、一見無害な検索エンドポイントから始まる。オートコンプリートフィールドの入力検証が不十分なため、攻撃者はSQLペイロードを渡すことができる。ログによると、リクエストは当初IPアドレス178.162.151.229から送信されたものと検出された。公開Webフォームを保護していない場合、そのようなフォームはすべてインフラストラクチャに対するトロイの木馬となる。

マルウェアをJavaオブジェクトとして保存する

この攻撃におけるハッカーたちの真の革新性は、SQLインジェクションそのものではなく、従来の.exeファイルやスクリプトを回避した点にある。Oracleの組み込みJava仮想マシンとCREATE JAVA SOURCE文を利用して、khuntツールをデータベース内のオブジェクトとして直接格納したのだ。OracleがデータベースにおけるJava管理に関する公式ドキュメントで指摘しているように、この機能は開発の容易性を目的として設計されたものであり、攻撃後のツールキットをホストするためのものではない。このツールキットには、オペレーティングシステム呼び出し用のKhuntCmdやコード抽出用のKhuntHashといった構成要素が含まれていた。

システム権限に伴うリスク

このようなシナリオにおける致命的な失敗点は、Webアプリケーションのログインアカウントへの過剰な権限割り当てです。ハッカーがKhuntCmdを使用してコマンドを実行すると、 cmd.exe /c whoamiすると、データベースが完全なSYSTEM権限で実行されていることがわかった。 Windowsこれにより、SAM、SECURITY、SYSTEMなどの重要なWindowsレジストリハイブをコピーして、パスワードハッシュを復元することが可能になりました。企業ネットワークにおける同様の脆弱性は、次のようなレポートで分析されることがよくあります。 Picusのホワイトペーパー 侵害シミュレーションテストに関して。

TechNoidの見解

マルウェアをデータベース内に保存するという事実は、エンドポイント上の従来のEDRツールが、データベース内に潜む脅威に対してしばしば見落としてしまうことを示しています。TechNoidでは、ここでの最大の誤りはSQLインジェクションの脆弱性そのものではなく、Webアプリケーションアカウントに管理者権限を付与する安易なアーキテクチャにあると考えています。直ちに厳格な最小権限ポリシーを導入し、公開データベースアカウントからJavaソースコード作成権限を削除してください。また、エンドポイントを保護するためのクラウドインフラストラクチャセキュリティガイドも併せてお読みください。