トロイの木馬ソースとは何か、そしてどのようにソースコードに侵入するのか
11月の初めに、ケンブリッジ大学はそれらをリリースしました トロイの木馬ソースと呼ばれる研究。この研究は、方向性のあるフォーマット文字を使用して、ソースコードやコメントにバックドアを隠す方法に焦点を当てました。これらを使うと、コンパイラが人間のコードレビュー担当者とは異なる方法でロジックを解釈するコードを作成できます。
この脆弱性は新しいものです。ただし、Unicodeは過去に不正に使用されていました。たとえば、ファイルの実際のファイル拡張子を次のように隠すなど、Unicodeが使用されていました。 ファイル名の最後の部分の方向を逆にする。最近の調査により、多くのコンパイラが警告なしにソースコード内の Unicode 文字を無視するのに対し、コードエディタを含むテキストエディタは、コメントやそれに基づくコードを含む行をリフローする可能性があることが明らかになりました。そのため、エディターはコードやコメントを、コンパイラーが解析する方法とは異なったり、異なる順序で表示したりすることがあります。コードやコメントを交換する場合でも同様です。
詳細については以下をお読みください。または、Trojan Sourceの模擬ハッキングを試してみたい場合は、無料で試してみてください。 パブリックミッション 自分で体験してください。
双方向テキスト
これらのトロイの木馬ソース攻撃の1つは、英語（左から右）やアラビア語（右から左）などの異なる表示順序でテキストをまとめる方法を処理するUnicode Bidi（双方向）アルゴリズムを利用します。方向指定形式の文字を使用すると、グループを再編成したり、文字の順序を表示したりできます。
上の表には、攻撃に関連するBidiオーバーライド文字の一部が含まれています。例えば、
RLI 私たちはcに行きます PDI
RLIの略語は 右から左に分離。テキストをコンテキスト (PDI で区切られる) から分離します。 ポップ・ディレクショナル・アイソレート)、右から左に読み上げます。結果は以下のようになります。
c o d e
ただし、コンパイラーとインタープリターは通常、ソースコードを解析する前に、Bidiオーバーライドを含むフォーマット制御文字を処理しません。方向指定のフォーマット文字を単純に無視すると、以下の内容が解析されます。
私たちはcに行きます
古いワインを新しいボトルに？
もちろん、これは太陽の下では目新しいことではありません。これまで、方向指定フォーマットの文字は ファイル名に挿入 彼らの悪質さを隠すためだ電子メールの添付ファイルが 'myspecialexe.doc' として表示されても、RLO 用でなければ、十分に無害に見えるかもしれません (右から左へのオーバーライド) 本名が「myspecialcod.exe」であることがわかるキャラクタープレゼント
トロイの木馬ソース攻撃は、構文エラーやコンパイルエラーを生成しないため、ソースコードに存在するコメントや文字列に方向形式の文字を挿入します。これらの制御文字はコードのロジックの表示順序を変更し、コンパイラに人間とはまったく異なるものを読み取らせます。
たとえば、次のバイトを次の順序で含むファイル。
方向フォーマット文字によって次のように並べ替えられます
方向指定文字が明示的に呼び出されない場合、コードは次のようにレンダリングされます。
RLO は、最後の行で閉じ括弧を開中括弧に切り替えます。その逆も同様です。このコードを実行すると、「あなたは管理者です」という結果になります。管理者チェックはコメントアウトされていますが、制御文字はそれがまだ存在していたような印象を与えます。
(ソース:https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
これはあなたにどのような影響を与えますか？
C、C++、C#、JavaScript、Java、Rust、Go、Pythonなど、多くの言語が攻撃に対して脆弱であり、他にもあると想定されています。さて、平均的な開発者はソースコードに方向指定フォーマット文字があることに眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないほうがいいかもしれません。さらに、これらの文字の視覚化は IDE に大きく依存しているため、必ず見つかる保証はありません。
しかし、そもそもこの脆弱性がどのようにしてソースコードに侵入するのでしょうか。何よりもまず、悪意のあるコードの寄与が見過ごされてきた、信頼できないソースからのソースコードを使用した場合にこの問題が発生する可能性があります。第二に、インターネットで見つかったコードからコピーして貼り付けるだけで、ほとんどの開発者が以前行っていたことがある、ということが起こり得ます。ほとんどの組織は、複数のベンダーのソフトウェアコンポーネントに依存しています。そこで、このコードをどの程度完全に信頼し、信頼できるかという疑問が生じます。隠れたバックドアを含むソースコードをスクリーニングするにはどうすればよいか。
誰の問題なの？
一方では、コンパイラとビルドパイプラインは、一方向が文字列とコメントに厳密に限定されていない限り、複数の方向のソースコード行を許可しないべきです。文字列やコメント内の方向フォーマット文字は、ポップされない限り、方向転換を行末まで延長する可能性があることに注意してください。一般に、コードエディターはホモグリフや方向フォーマット文字など、疑わしい Unicode 文字を明示的にレンダリングして強調表示する必要があります。11 月以降、GitHub は双方向の Unicode テキストを含むコードのすべての行に警告記号とメッセージを追加するようになりました。ただし、これらの文字が行のどこにあるかは強調していません。これでも、悪意のない方向変更とともに、悪意のある方向変更が忍び寄る可能性があります。
開発者とコードレビュー担当者の認識が不可欠です。そのため、脆弱性を説明するウォークスルーを作成しました。現在、このウォークスルーは Java、C#、Python、GO、および PHP で利用できます。
だからもっと知りたいなら、私たちを試してみてください トロイの木馬ソースのシミュレーション（公開ミッション）、そして読んでください トロイの木馬ソース調査。
11月の初めに、ケンブリッジ大学はそれらをリリースしました トロイの木馬ソースと呼ばれる研究。この研究は、方向性のあるフォーマット文字を使用して、ソースコードやコメントにバックドアを隠す方法に焦点を当てました。これらを使うと、コンパイラが人間のコードレビュー担当者とは異なる方法でロジックを解釈するコードを作成できます。
この脆弱性は新しいものです。ただし、Unicodeは過去に不正に使用されていました。たとえば、ファイルの実際のファイル拡張子を次のように隠すなど、Unicodeが使用されていました。 ファイル名の最後の部分の方向を逆にする。最近の調査により、多くのコンパイラが警告なしにソースコード内の Unicode 文字を無視するのに対し、コードエディタを含むテキストエディタは、コメントやそれに基づくコードを含む行をリフローする可能性があることが明らかになりました。そのため、エディターはコードやコメントを、コンパイラーが解析する方法とは異なったり、異なる順序で表示したりすることがあります。コードやコメントを交換する場合でも同様です。
詳細については以下をお読みください。または、Trojan Sourceの模擬ハッキングを試してみたい場合は、無料で試してみてください。 パブリックミッション 自分で体験してください。
双方向テキスト
これらのトロイの木馬ソース攻撃の1つは、英語（左から右）やアラビア語（右から左）などの異なる表示順序でテキストをまとめる方法を処理するUnicode Bidi（双方向）アルゴリズムを利用します。方向指定形式の文字を使用すると、グループを再編成したり、文字の順序を表示したりできます。
上の表には、攻撃に関連するBidiオーバーライド文字の一部が含まれています。例えば、
RLI 私たちはcに行きます PDI
RLIの略語は 右から左に分離。テキストをコンテキスト (PDI で区切られる) から分離します。 ポップ・ディレクショナル・アイソレート)、右から左に読み上げます。結果は以下のようになります。
c o d e
ただし、コンパイラーとインタープリターは通常、ソースコードを解析する前に、Bidiオーバーライドを含むフォーマット制御文字を処理しません。方向指定のフォーマット文字を単純に無視すると、以下の内容が解析されます。
私たちはcに行きます
古いワインを新しいボトルに？
もちろん、これは太陽の下では目新しいことではありません。これまで、方向指定フォーマットの文字は ファイル名に挿入 彼らの悪質さを隠すためだ電子メールの添付ファイルが 'myspecialexe.doc' として表示されても、RLO 用でなければ、十分に無害に見えるかもしれません (右から左へのオーバーライド) 本名が「myspecialcod.exe」であることがわかるキャラクタープレゼント
トロイの木馬ソース攻撃は、構文エラーやコンパイルエラーを生成しないため、ソースコードに存在するコメントや文字列に方向形式の文字を挿入します。これらの制御文字はコードのロジックの表示順序を変更し、コンパイラに人間とはまったく異なるものを読み取らせます。
たとえば、次のバイトを次の順序で含むファイル。
方向フォーマット文字によって次のように並べ替えられます
方向指定文字が明示的に呼び出されない場合、コードは次のようにレンダリングされます。
RLO は、最後の行で閉じ括弧を開中括弧に切り替えます。その逆も同様です。このコードを実行すると、「あなたは管理者です」という結果になります。管理者チェックはコメントアウトされていますが、制御文字はそれがまだ存在していたような印象を与えます。
(ソース:https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
これはあなたにどのような影響を与えますか？
C、C++、C#、JavaScript、Java、Rust、Go、Pythonなど、多くの言語が攻撃に対して脆弱であり、他にもあると想定されています。さて、平均的な開発者はソースコードに方向指定フォーマット文字があることに眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないほうがいいかもしれません。さらに、これらの文字の視覚化は IDE に大きく依存しているため、必ず見つかる保証はありません。
しかし、そもそもこの脆弱性がどのようにしてソースコードに侵入するのでしょうか。何よりもまず、悪意のあるコードの寄与が見過ごされてきた、信頼できないソースからのソースコードを使用した場合にこの問題が発生する可能性があります。第二に、インターネットで見つかったコードからコピーして貼り付けるだけで、ほとんどの開発者が以前行っていたことがある、ということが起こり得ます。ほとんどの組織は、複数のベンダーのソフトウェアコンポーネントに依存しています。そこで、このコードをどの程度完全に信頼し、信頼できるかという疑問が生じます。隠れたバックドアを含むソースコードをスクリーニングするにはどうすればよいか。
誰の問題なの？
一方では、コンパイラとビルドパイプラインは、一方向が文字列とコメントに厳密に限定されていない限り、複数の方向のソースコード行を許可しないべきです。文字列やコメント内の方向フォーマット文字は、ポップされない限り、方向転換を行末まで延長する可能性があることに注意してください。一般に、コードエディターはホモグリフや方向フォーマット文字など、疑わしい Unicode 文字を明示的にレンダリングして強調表示する必要があります。11 月以降、GitHub は双方向の Unicode テキストを含むコードのすべての行に警告記号とメッセージを追加するようになりました。ただし、これらの文字が行のどこにあるかは強調していません。これでも、悪意のない方向変更とともに、悪意のある方向変更が忍び寄る可能性があります。
開発者とコードレビュー担当者の認識が不可欠です。そのため、脆弱性を説明するウォークスルーを作成しました。現在、このウォークスルーは Java、C#、Python、GO、および PHP で利用できます。
だからもっと知りたいなら、私たちを試してみてください トロイの木馬ソースのシミュレーション（公開ミッション）、そして読んでください トロイの木馬ソース調査。
11月の初めに、ケンブリッジ大学はそれらをリリースしました トロイの木馬ソースと呼ばれる研究。この研究は、方向性のあるフォーマット文字を使用して、ソースコードやコメントにバックドアを隠す方法に焦点を当てました。これらを使うと、コンパイラが人間のコードレビュー担当者とは異なる方法でロジックを解釈するコードを作成できます。
この脆弱性は新しいものです。ただし、Unicodeは過去に不正に使用されていました。たとえば、ファイルの実際のファイル拡張子を次のように隠すなど、Unicodeが使用されていました。 ファイル名の最後の部分の方向を逆にする。最近の調査により、多くのコンパイラが警告なしにソースコード内の Unicode 文字を無視するのに対し、コードエディタを含むテキストエディタは、コメントやそれに基づくコードを含む行をリフローする可能性があることが明らかになりました。そのため、エディターはコードやコメントを、コンパイラーが解析する方法とは異なったり、異なる順序で表示したりすることがあります。コードやコメントを交換する場合でも同様です。
詳細については以下をお読みください。または、Trojan Sourceの模擬ハッキングを試してみたい場合は、無料で試してみてください。 パブリックミッション 自分で体験してください。
双方向テキスト
これらのトロイの木馬ソース攻撃の1つは、英語（左から右）やアラビア語（右から左）などの異なる表示順序でテキストをまとめる方法を処理するUnicode Bidi（双方向）アルゴリズムを利用します。方向指定形式の文字を使用すると、グループを再編成したり、文字の順序を表示したりできます。
上の表には、攻撃に関連するBidiオーバーライド文字の一部が含まれています。例えば、
RLI 私たちはcに行きます PDI
RLIの略語は 右から左に分離。テキストをコンテキスト (PDI で区切られる) から分離します。 ポップ・ディレクショナル・アイソレート)、右から左に読み上げます。結果は以下のようになります。
c o d e
ただし、コンパイラーとインタープリターは通常、ソースコードを解析する前に、Bidiオーバーライドを含むフォーマット制御文字を処理しません。方向指定のフォーマット文字を単純に無視すると、以下の内容が解析されます。
私たちはcに行きます
古いワインを新しいボトルに？
もちろん、これは太陽の下では目新しいことではありません。これまで、方向指定フォーマットの文字は ファイル名に挿入 彼らの悪質さを隠すためだ電子メールの添付ファイルが 'myspecialexe.doc' として表示されても、RLO 用でなければ、十分に無害に見えるかもしれません (右から左へのオーバーライド) 本名が「myspecialcod.exe」であることがわかるキャラクタープレゼント
トロイの木馬ソース攻撃は、構文エラーやコンパイルエラーを生成しないため、ソースコードに存在するコメントや文字列に方向形式の文字を挿入します。これらの制御文字はコードのロジックの表示順序を変更し、コンパイラに人間とはまったく異なるものを読み取らせます。
たとえば、次のバイトを次の順序で含むファイル。
方向フォーマット文字によって次のように並べ替えられます
方向指定文字が明示的に呼び出されない場合、コードは次のようにレンダリングされます。
RLO は、最後の行で閉じ括弧を開中括弧に切り替えます。その逆も同様です。このコードを実行すると、「あなたは管理者です」という結果になります。管理者チェックはコメントアウトされていますが、制御文字はそれがまだ存在していたような印象を与えます。
(ソース:https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
これはあなたにどのような影響を与えますか？
C、C++、C#、JavaScript、Java、Rust、Go、Pythonなど、多くの言語が攻撃に対して脆弱であり、他にもあると想定されています。さて、平均的な開発者はソースコードに方向指定フォーマット文字があることに眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないほうがいいかもしれません。さらに、これらの文字の視覚化は IDE に大きく依存しているため、必ず見つかる保証はありません。
しかし、そもそもこの脆弱性がどのようにしてソースコードに侵入するのでしょうか。何よりもまず、悪意のあるコードの寄与が見過ごされてきた、信頼できないソースからのソースコードを使用した場合にこの問題が発生する可能性があります。第二に、インターネットで見つかったコードからコピーして貼り付けるだけで、ほとんどの開発者が以前行っていたことがある、ということが起こり得ます。ほとんどの組織は、複数のベンダーのソフトウェアコンポーネントに依存しています。そこで、このコードをどの程度完全に信頼し、信頼できるかという疑問が生じます。隠れたバックドアを含むソースコードをスクリーニングするにはどうすればよいか。
誰の問題なの？
一方では、コンパイラとビルドパイプラインは、一方向が文字列とコメントに厳密に限定されていない限り、複数の方向のソースコード行を許可しないべきです。文字列やコメント内の方向フォーマット文字は、ポップされない限り、方向転換を行末まで延長する可能性があることに注意してください。一般に、コードエディターはホモグリフや方向フォーマット文字など、疑わしい Unicode 文字を明示的にレンダリングして強調表示する必要があります。11 月以降、GitHub は双方向の Unicode テキストを含むコードのすべての行に警告記号とメッセージを追加するようになりました。ただし、これらの文字が行のどこにあるかは強調していません。これでも、悪意のない方向変更とともに、悪意のある方向変更が忍び寄る可能性があります。
開発者とコードレビュー担当者の認識が不可欠です。そのため、脆弱性を説明するウォークスルーを作成しました。現在、このウォークスルーは Java、C#、Python、GO、および PHP で利用できます。
だからもっと知りたいなら、私たちを試してみてください トロイの木馬ソースのシミュレーション（公開ミッション）、そして読んでください トロイの木馬ソース調査。
以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャ、開発者、CISO、またはセキュリティ関係者のいずれであっても、安全でないコードに関連するリスクを軽減するお手伝いをします。
レポートを表示デモを予約
Laura Verheydeは、Secure Code Warriorのソフトウェア開発者で、ミッションラボとコーディングラボ向けの脆弱性の調査とコンテンツの作成に注力しています。
11月の初めに、ケンブリッジ大学はそれらをリリースしました トロイの木馬ソースと呼ばれる研究。この研究は、方向性のあるフォーマット文字を使用して、ソースコードやコメントにバックドアを隠す方法に焦点を当てました。これらを使うと、コンパイラが人間のコードレビュー担当者とは異なる方法でロジックを解釈するコードを作成できます。
この脆弱性は新しいものです。ただし、Unicodeは過去に不正に使用されていました。たとえば、ファイルの実際のファイル拡張子を次のように隠すなど、Unicodeが使用されていました。 ファイル名の最後の部分の方向を逆にする。最近の調査により、多くのコンパイラが警告なしにソースコード内の Unicode 文字を無視するのに対し、コードエディタを含むテキストエディタは、コメントやそれに基づくコードを含む行をリフローする可能性があることが明らかになりました。そのため、エディターはコードやコメントを、コンパイラーが解析する方法とは異なったり、異なる順序で表示したりすることがあります。コードやコメントを交換する場合でも同様です。
詳細については以下をお読みください。または、Trojan Sourceの模擬ハッキングを試してみたい場合は、無料で試してみてください。 パブリックミッション 自分で体験してください。
双方向テキスト
これらのトロイの木馬ソース攻撃の1つは、英語（左から右）やアラビア語（右から左）などの異なる表示順序でテキストをまとめる方法を処理するUnicode Bidi（双方向）アルゴリズムを利用します。方向指定形式の文字を使用すると、グループを再編成したり、文字の順序を表示したりできます。
上の表には、攻撃に関連するBidiオーバーライド文字の一部が含まれています。例えば、
RLI 私たちはcに行きます PDI
RLIの略語は 右から左に分離。テキストをコンテキスト (PDI で区切られる) から分離します。 ポップ・ディレクショナル・アイソレート)、右から左に読み上げます。結果は以下のようになります。
c o d e
ただし、コンパイラーとインタープリターは通常、ソースコードを解析する前に、Bidiオーバーライドを含むフォーマット制御文字を処理しません。方向指定のフォーマット文字を単純に無視すると、以下の内容が解析されます。
私たちはcに行きます
古いワインを新しいボトルに？
もちろん、これは太陽の下では目新しいことではありません。これまで、方向指定フォーマットの文字は ファイル名に挿入 彼らの悪質さを隠すためだ電子メールの添付ファイルが 'myspecialexe.doc' として表示されても、RLO 用でなければ、十分に無害に見えるかもしれません (右から左へのオーバーライド) 本名が「myspecialcod.exe」であることがわかるキャラクタープレゼント
トロイの木馬ソース攻撃は、構文エラーやコンパイルエラーを生成しないため、ソースコードに存在するコメントや文字列に方向形式の文字を挿入します。これらの制御文字はコードのロジックの表示順序を変更し、コンパイラに人間とはまったく異なるものを読み取らせます。
たとえば、次のバイトを次の順序で含むファイル。
方向フォーマット文字によって次のように並べ替えられます
方向指定文字が明示的に呼び出されない場合、コードは次のようにレンダリングされます。
RLO は、最後の行で閉じ括弧を開中括弧に切り替えます。その逆も同様です。このコードを実行すると、「あなたは管理者です」という結果になります。管理者チェックはコメントアウトされていますが、制御文字はそれがまだ存在していたような印象を与えます。
(ソース:https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
これはあなたにどのような影響を与えますか？
C、C++、C#、JavaScript、Java、Rust、Go、Pythonなど、多くの言語が攻撃に対して脆弱であり、他にもあると想定されています。さて、平均的な開発者はソースコードに方向指定フォーマット文字があることに眉をひそめるかもしれませんが、初心者は肩をすくめて何も考えないほうがいいかもしれません。さらに、これらの文字の視覚化は IDE に大きく依存しているため、必ず見つかる保証はありません。
しかし、そもそもこの脆弱性がどのようにしてソースコードに侵入するのでしょうか。何よりもまず、悪意のあるコードの寄与が見過ごされてきた、信頼できないソースからのソースコードを使用した場合にこの問題が発生する可能性があります。第二に、インターネットで見つかったコードからコピーして貼り付けるだけで、ほとんどの開発者が以前行っていたことがある、ということが起こり得ます。ほとんどの組織は、複数のベンダーのソフトウェアコンポーネントに依存しています。そこで、このコードをどの程度完全に信頼し、信頼できるかという疑問が生じます。隠れたバックドアを含むソースコードをスクリーニングするにはどうすればよいか。
誰の問題なの？
一方では、コンパイラとビルドパイプラインは、一方向が文字列とコメントに厳密に限定されていない限り、複数の方向のソースコード行を許可しないべきです。文字列やコメント内の方向フォーマット文字は、ポップされない限り、方向転換を行末まで延長する可能性があることに注意してください。一般に、コードエディターはホモグリフや方向フォーマット文字など、疑わしい Unicode 文字を明示的にレンダリングして強調表示する必要があります。11 月以降、GitHub は双方向の Unicode テキストを含むコードのすべての行に警告記号とメッセージを追加するようになりました。ただし、これらの文字が行のどこにあるかは強調していません。これでも、悪意のない方向変更とともに、悪意のある方向変更が忍び寄る可能性があります。
開発者とコードレビュー担当者の認識が不可欠です。そのため、脆弱性を説明するウォークスルーを作成しました。現在、このウォークスルーは Java、C#、Python、GO、および PHP で利用できます。
だからもっと知りたいなら、私たちを試してみてください トロイの木馬ソースのシミュレーション（公開ミッション）、そして読んでください トロイの木馬ソース調査。
始めるためのリソース
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
