リモートコード実行（RCE）とは何か、それを防ぐ方法

リモートコード実行（RCE）は、ソフトウェアのセキュリティ上の欠陥/脆弱性の一種です。 RCEの脆弱性により、悪意のあるアクターは、LAN、WAN、またはインターネットを介してリモートマシン上で任意のコードを実行することができます。 RCEは、より広範なクラスの任意のコード実行（ACE）脆弱性に属します。 しかし、インターネットがユビキタスになると、RCEの脆弱性の影響は急速に拡大します。 したがって、Rceはおそらく最も重要な種類のACE脆弱性です。

このように、さまざまな種類のRCE脆弱性と可能な対策について、より詳細に見ていきたいと考えていました。

rce起源による分類

既知のRCE脆弱性のほとんどは、すべてではないにしても、根本的な原因の数が少ないです。

動的コード実行

動的コード実行は、RCEにつながる最も一般的な攻撃ベクトルである傾向があります。 ほとんどのプログラミング言語は、コードを使ってコードを生成し、その場で実行する方法を持っています。 これは、多くの複雑な問題を解決するのに役立つ非常に強力な概念です。 ただし、悪意のある第三者は、RCE機能を得るためにそれを簡単に悪用することができます。

多くの場合、実行時に生成されるコードはユーザーの入力に基づいています。 多くの場合、コードにはその入力が何らかの形で含まれています。 悪意のあるアクターは、動的コード生成が特定の入力を使用することを認識し、アプリケーションを攻撃するための入力として有効なコードを提供する可 ユーザー入力が検証されていない場合、そのコードはターゲットマシン上で実行されます。

大まかに言えば、動的コード実行はRCEの脆弱性の二つの主要なクラスを引き起こします：直接的および間接的。

Direct

直接動的コード実行の場合、悪意のあるアクターは、その入力がコード生成に使用されることを認識しています。

間接的な

間接的なケースは、ユーザー入力を含む動的コード生成に帰着します。 ただし、ユーザー入力は1つ以上のレイヤーを通過します。 一部のレイヤーは、動的コード生成に終わる前にその入力を変換することさえあります。 また、動的コード生成は副作用であり、入力の主な使用法ではない可能性があります。 そのため、入力がリモートマシン上で実行されるコードスニペットの構成要素として使用されることは、入力を提供するユーザーには実際には明らかでは

逆シリアル化

逆シリアル化は、このシナリオの非常に良い例です。 逆シリアル化で動的なコード生成が行われるべきではないように見えます。 これは、シリアル化されたオブジェクトにプリミティブ型またはその種の他のオブジェクトのデータフィールドのみが含まれている場合です。 しかし、オブジェクトのメソッド/関数がシリアル化されると、物事はより複雑になります。 逆シリアル化には、通常、何らかの形式の動的コード生成が含まれます。

関数の直列化が理にかなっているのは、動的言語だけだと思うかもしれません。 問題の範囲は限られています。 しかし、それは静的言語でも便利なシナリオです。 静的言語で達成するのはやや難しいですが、不可能ではありません。

多くの場合、実装は逆シリアル化で生成されたプロキシオブジェクト/関数で構成されています。 実行時にオブジェクト/関数を生成することは、動的コード生成の場合です。 そのため、逆シリアル化されるデータがリモートマシンからの要求に由来する場合、悪意のあるアクターがそれを変更する可能性があります。 慎重に細工されたシリアル化されたコードスニペットを注入して、逆シリアル化の一部として呼び出されたときに動的コード生成を欺くことがで

メモリの安全性

RCEの脆弱性のもう1つの原因はメモリの安全性に関係しています。 メモリの安全性とは、初期化または入力として取得しなかったメモリの部分にコードがアクセスするのを防ぐことを意味します。 直感的には、メモリの安全性が不足すると、不正なデータアクセスが発生することが予想される場合があります。 ただし、オペレーティングシステムと基になるハードウェアは、実際の実行可能コードを格納するためにメモリを使用します。 コード実行に関するメタデータもメモリに格納されます。 この種のメモリへのアクセスを取得すると、ACEおよび場合によってはRCEが発生する可能性があります。 では、メモリの安全性の問題の背後にある主な理由は何ですか？

ソフトウェアの設計上の欠陥

ソフトウェアの設計上の欠陥は、一部の基礎となるコンポーネントに設計エラーがあるメモリ安全性の脆弱性の一種です。 多くの場合、それはコンパイラ、インタプリタ、または仮想マシン、または潜在的にオペレーティングシステムのカーネルまたはライブラ このクラスにはいくつかの異なる欠陥があります。 私たちは、間違いなく最も一般的なものであるものをより詳細に見てみるつもりです。

Buffer overflowまたはbuffer overread

Buffer overflow(buffer overreadとも呼ばれます)は、メモリの安全性に違反する非常に単純でよく知られた技術です。 これは、メモリバッファの実際の終わりに続くメモリセルに書き込むための設計上の欠陥またはバグを悪用します。 バッファ自体は、public APIへの正当な呼び出しから返されます。 ただし、バッファは、オブジェクトまたはプログラムカウンタのプライベートフィールド/メンバ値の物理メモリアドレスを計算する原点としてのみ機能し バッファに対する相対的な位置はよく知られているか、推測される可能性があります。 利用可能な場合はコードを調査したり、実行時にプログラムの実行をデバッグしたりすると、悪意のあるアクターが相対的な位置を取得するのに役立

だから、バッファオーバーフローは、設計上アクセスできないはずのメモリを変更することができます。 そのバッファは別のマシンのアドレス空間に存在し、リモートAPIを呼び出すことによって変更される可能性があります。 これにより、リモートマシンメモリへのアクセスが許可されます。 RCEを計測する際にこのタイプのアクセスを使用するには、さまざまな方法があります。 一般的な前提は、バッファオーバーフローの脆弱性が存在する場合、RCEが可能であるということです。 そのため、コード所有者は、実際のRCE攻撃が発生する前に、バッファオーバーフローをできるだけ早く修正する必要があります。

Scope

多くの場合、これらの言語にはバッファサイズチェックが組み込まれていないため、バッファオーバーフローはC/C++コードを対象としています。 他の多くの一般的なフレームワークや技術は、この種の攻撃に対して自動的に脆弱になるc/C++ライブラリを表面の下に深く使用することになります。

jsは、C/C++に基づいているだけでなく、JavaScriptランタイムではネイティブのC/C++アドオンも使用できるため、これの良い例です。 このため、攻撃者はノードへの要求を慎重に作成することができます。jsサーバーは、バッファオーバーフローを引き起こすため、任意のコードの実行を引き起こし、影響を受けるマシン上のシステムメモリを変更します。

ハードウェア設計上の欠陥

興味深いことに、ハードウェアセキュリティ設計上の欠陥のためにメモリ安全違反が発生する可能性があります。 あまり一般的ではなく、見つけるのが難しいですが、このような脆弱性は通常、非常に大きな影響を与えます。

偏向RCE攻撃

すべてのRCE攻撃の結果は、攻撃者がコードを実行するという点で同じですが、攻撃ベクトルは本質的に非常に異なっています。 それらのすべてをブロックするには多大な労力がかかります。 さらに、努力は技術の積み重ねとともに育つ。 この記事で説明されているすべての攻撃ベクトルは、技術に依存しません。 しかし、すべての実装は技術固有のものであり、防御メカニズムもそうです。

だから、従来の時間を節約する方法は、各エンドポイントを特定の技術で監視するのではなく、疑わしいコンテンツのネットワークトラフィックを監視することです。 通常、web application firewall(WAF)がこのジョブを実行します。 WAFはネットワークパフォーマンスのボトルネックであり、実際のエンドポイントやアプリケーションやユーザーレベルで利用可能なすべての背景情報が欠けています。 したがって、WAFトラフィック分析は完璧ではありませんでした。 ヒューリスティックは完全なデータなしでは避けられないため、すべての脅威が出現するわけではないか、偽陽性が発生するか、ほとんどの場合その両方が発生します。

アプリ内での移動: Sqreenのアプローチ

Sqreenは、アプリケーション内の可視性を移動し、技術固有のRASPとアプリ内WAFでより完全な保護をもたらすことにより、エンドユーザーの開発コ SqreenのRASPおよびWAFは、ネットワークトラフィックを受信する実際のwebアプリケーション、API、またはmicroservice内で実行されます。 ただし、コードの変更は必要ありません。 これは、各技術に固有のインストルメンテーションポイントを使用します（例えば、JAVA用JVM API、ノード用V8API。jsなど)実行時に実行する前にコードを変更する。 したがって、アプリケーション内で発生するすべてのコンテキストを完全に把握しながら、システムイベントやネットワークイベントを監視およ

したがって、Sqreenはアプリが既知のメモリ安全性の問題を持つコンポーネントを使用していることを検出できます。 また、動的コード実行イベントへの実際のユーザー入力を検出することもできます。 当然のことながら、これは、ネットワークトラフィックのみにアクセスできる従来のWAFと比較して、Rceの検出と防止に優れたアプローチです。

ラップアップ

明らかに、RCEは非常に強力な攻撃ベクトルです。 しかし、幸いなことに、それはあまりにも、RCEの攻撃から身を守ることが可能です。 上記の情報は本当にあなたの防衛戦略を構築するのに役立ちます。 他の攻撃方法や詳細に興味がある場合は、SQL injection、XXE、およびLFIに関する以前の投稿をご覧ください。