web-dev-qa-db-ja.com

ハッキング:UTF-8でエンコードされたスクリプトは、UTF-8以外の文字を実行できますか?

正直に言うと、この質問に最適なタイトル、またはその全範囲はよくわかりませんが、その背後にある動機は次のとおりです。

動機

サーバーがハッキングされ、UTF-8エンコードされたphpスクリプトを開くと、UTF-8文字セットで「?????????? ???? hacker.ru」

私はこれが何であるかを理解しようとしています:

考えていること

  • おそらく、テキストエディターで選択されたフォントがこれらの文字をサポートしていませんか?
  • おそらく、これらの文字は非UTF-8からUTF-8文書にコピーアンドペーストされました
    • 原油の例:
      • 非UTF-8バイナリ1111-> A
      • UTF-8バイナリ1111-> B
      • 適切にマッピングされないビットを効果的にコピーする
  • これらの文字を適切に表示する方法はありますか?
  • これは、これらの文字に関する私の優先的な質問ですこれらの非マッピング文字は何もしないと仮定できますか?(つまり、それらは別名ダメージを実行しない)
  • プログラミング言語は多言語ですか?
    • ロシア語でphpを書くことはできますか?
    • PHPを英語とロシア語で同じファイルに記述できますか?

仮定:私または誰かがUTF-8でエンコードされたファイルを開いて入力すると、任意の言語または文字で適切にマップされ、適切に表示されます。

誰でもこの主題に光を当てることができますか?

つまり、攻撃チェーンでのUTF-8文字の使用に対する答えは「はい」です。私の道を越えたいくつかのケースがあります。この攻撃方法について私が読んだことは、これが攻撃チェーンの「シェル」をネイティブシステムに「ドロップ」する最後のステップであることです。すぐに「Google」で、この記事は思いつきました。

" 検証ロジックをバイパスするためのUTF-8エンコーディングの使用 "

この記事では、この特定の方法がどのように使用されるかを正確に説明します。エグゼクティブサマリーは次のとおりです。

「この攻撃は、代替エンコーディングを利用して検証ロジックをバイパスする特定のバリエーションです。この攻撃は、潜在的に有害な入力をUTF-8でエンコードし、このエンコーディング標準の検証を期待していない、または有効でないアプリケーションに送信して、入力フィルタリングを困難にする可能性を利用しています。UTF -8(8ビットUCS/Unicode変換フォーマット)は、Unicodeの可変長文字エンコーディングです。正当なUTF-8文字は1〜4バイトの長さです。ただし、UTF-8仕様の初期バージョンでは、一部のエントリが間違っていました(一部のケースでは、長すぎる文字が許可されていました。UTF-8エンコーダは「可能な限り短い」エンコーディングを使用することになっていますが、単純なデコーダは必要以上に長いエンコーディングを受け入れる場合があります。RFC3629によると、この攻撃の特に微妙な形式は入力のUTF-8エンコード形式に対してセキュリティクリティカルな有効性チェックを実行しますが、特定の不正なオクテットシーケンスを文字として解釈するパーサーに対して実行されます。」

この話題は以前に登場しましたが、この執筆中はユースケースは利用できません。後で見つかった場合は、コメントとして追加されます。

覚えられているのは、ネイティブシステムに侵入し、ドーマに座っていた攻撃チェーン方式でした。ファイアウォールを通過して侵入した場合、それ以上のアクセスは拒否されました。その後、プログラムは、セキュリティソフトウェアを通過してアクセスできるようになるまで、UTF-8ファイルに変換されました。穴が開けられると、文字ビットコーディングにより、pythonプログラムはコマンドプロンプトまたは「ドロップシェル」を開くことができました。その後、攻撃者はルートに完全にアクセスできました。その後、待機しているプログラムの別の部分へのゲートウェイを開きました。

これは、「UTF-8エンコーディングを使用して検証ロジックをバイパスする」という調査と非常によく似ています。攻撃の方法は非常に似ています。

攻撃の方法1.注入2.プロトコル操作3. APIの悪用

以前読んだことがあるように、このプログラムの目的は、できる限り深く浸透することでした。ブロックされている場合、それ以外の場合は、UTF-8に変換され、規定された事項で攻撃を実行します。成功した場合、マルウェアの別の部分へのゲートウェイを開いて、攻撃チェーンのさらに下に配置します。

言うことを得た、それは考えることは興味深い。私の見解では、別のシステムの限られた範囲を超えることができるコードを記述できれば、攻撃は成功します。防御するコードに制約があり、攻撃するコードに、防御側のスコープにプログラムされたことのない選択肢とオプションがある場合、それは明らかな損失です。特に、AIまたは機械学習の攻撃者がいる場合。

CAPECコンテンツチームの属性、ザマイターコーポレーション2014-06-23 Internal_CAPEC_Teamの記事。

3
Chukk Chukk