トロイの木馬ソースとは何か、そしてどのようにソースコードに侵入するのか
11月初旬、ケンブリッジ大学は 「Trojan-Source」と題する研究を発表した。この研究は、方向指定文字を用いてソースコードやコメント内にバックドアを隠蔽する手法に焦点を当てた。これにより、コンパイラと人間のコードレビュー担当者が異なる解釈を行うロジックを持つコードを作成することが可能となる。
この脆弱性は新たなものですが、Unicodeは過去に悪用された実績があります。例えば、ファイル名の末尾部分を反転させることで、ファイル名の真の拡張子を隠蔽する手法が用いられてきました。 最近の調査により、多くのコンパイラがソースコード内のUnicode文字を予告なく無視する一方、テキストエディタ（コードエディタを含む）はコメントを含む行やそれに基づくコードを再編成する可能性があることが明らかになった。したがって、エディタがコードとコメントを表示する形式や順序がコンパイラが解析するものと異なり、コードとコメントが入れ替わる可能性さえある。
詳細については読み進めてください。または、すぐに始めてトロイの木馬ソースの模擬ハッキングを試してみたい場合は、無料ページと公開ミッションにアクセスして、ご自身で体験してください。
双方向テキスト
トロイの木馬型ソースの攻撃の一つは、Unicode Bidi（双方向）アルゴリズムを利用しています。このアルゴリズムは、英語（左から右）やアラビア語（右から左）など、異なる表示順序を持つテキストの結合方法を管理します。方向指定フォーマット文字は、文字のグループ化と表示順序を再編成するために使用できます。
上記の表には、攻撃に関連するBidiの無効化されたキャラクターの一部が含まれています。例えば、
RLIe d a cPDI
RLIの略語は「右から左へ分離」を意味します。テキストをその文脈（PDI、方向性分離ポップで区切られた部分）から分離し、右から左へ読み取ります。その結果：
c a d e
ただし、コンパイラやインタプリタは通常、ソースコードを解析する前に、Bidiの無効化を含む書式制御文字を処理しません。方向指定の書式文字を単に無視すると、以下のように解析されます：
e d a c
古いワインを新しい瓶に？
もちろん、これは決して目新しいことではありません。過去には、ファイル名に方向性のあるフォーマット文字を挿入して、その悪意のある性質を偽装する手法が用いられてきました。 例えば「myspecialexe.doc」というメール添付ファイルは、RLO（右から左への置換）文字が存在しなければ一見無害に見えますが、これが真の名前の「myspecialcod.exe」を暴露するのです。
トロイの木馬攻撃「Source」は、ソースコード内のコメントや文字列に方向制御文字を挿入します。これらは構文エラーやコンパイルエラーを引き起こさないため、検出が困難です。これらの制御文字はコードロジックの表示順序を変更し、コンパイラが人間が読むものとは全く異なる内容を読み取るように仕向けます。
例えば、以下のバイトをこの順序で含むファイル：
方向指定フォーマット文字に従い、以下の順序で再配置されます
方向指定フォーマット文字が明示的に呼び出されない場合、コードは次のように表現される:
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向けに提供されています。
もっと知りたいなら、トロイアンソースのシミュレーション（公開ミッション）を試してみて、トロイアンソースの調査を読んでみてください。
Secure Code Warrior ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先事項とする文化を構築するために、貴組織をSecure Code Warrior 。AppSec管理者、開発者、CISO、セキュリティ関連担当者など、あらゆる立場の方々に対し、不安全なコードに関連するリスクを軽減するお手伝いをいたします。
デモを予約する
Laura Verheyde はSecure Code Warrior のソフトウェア開発者で、脆弱性のリサーチとMissions および Coding labs のコンテンツ作成に注力している。
11月初旬、ケンブリッジ大学は 「Trojan-Source」と題する研究を発表した。この研究は、方向指定文字を用いてソースコードやコメント内にバックドアを隠蔽する手法に焦点を当てた。これにより、コンパイラと人間のコードレビュー担当者が異なる解釈を行うロジックを持つコードを作成することが可能となる。
この脆弱性は新たなものですが、Unicodeは過去に悪用された実績があります。例えば、ファイル名の末尾部分を反転させることで、ファイル名の真の拡張子を隠蔽する手法が用いられてきました。 最近の調査により、多くのコンパイラがソースコード内のUnicode文字を予告なく無視する一方、テキストエディタ（コードエディタを含む）はコメントを含む行やそれに基づくコードを再編成する可能性があることが明らかになった。したがって、エディタがコードとコメントを表示する形式や順序がコンパイラが解析するものと異なり、コードとコメントが入れ替わる可能性さえある。
詳細については読み進めてください。または、すぐに始めてトロイの木馬ソースの模擬ハッキングを試してみたい場合は、無料ページと公開ミッションにアクセスして、ご自身で体験してください。
双方向テキスト
トロイの木馬型ソースの攻撃の一つは、Unicode Bidi（双方向）アルゴリズムを利用しています。このアルゴリズムは、英語（左から右）やアラビア語（右から左）など、異なる表示順序を持つテキストの結合方法を管理します。方向指定フォーマット文字は、文字のグループ化と表示順序を再編成するために使用できます。
上記の表には、攻撃に関連するBidiの無効化されたキャラクターの一部が含まれています。例えば、
RLIe d a cPDI
RLIの略語は「右から左へ分離」を意味します。テキストをその文脈（PDI、方向性分離ポップで区切られた部分）から分離し、右から左へ読み取ります。その結果：
c a d e
ただし、コンパイラやインタプリタは通常、ソースコードを解析する前に、Bidiの無効化を含む書式制御文字を処理しません。方向指定の書式文字を単に無視すると、以下のように解析されます：
e d a c
古いワインを新しい瓶に？
もちろん、これは決して目新しいことではありません。過去には、ファイル名に方向性のあるフォーマット文字を挿入して、その悪意のある性質を偽装する手法が用いられてきました。 例えば「myspecialexe.doc」というメール添付ファイルは、RLO（右から左への置換）文字が存在しなければ一見無害に見えますが、これが真の名前の「myspecialcod.exe」を暴露するのです。
トロイの木馬攻撃「Source」は、ソースコード内のコメントや文字列に方向制御文字を挿入します。これらは構文エラーやコンパイルエラーを引き起こさないため、検出が困難です。これらの制御文字はコードロジックの表示順序を変更し、コンパイラが人間が読むものとは全く異なる内容を読み取るように仕向けます。
例えば、以下のバイトをこの順序で含むファイル：
方向指定フォーマット文字に従い、以下の順序で再配置されます
方向指定フォーマット文字が明示的に呼び出されない場合、コードは次のように表現される:
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月初旬、ケンブリッジ大学は 「Trojan-Source」と題する研究を発表した。この研究は、方向指定文字を用いてソースコードやコメント内にバックドアを隠蔽する手法に焦点を当てた。これにより、コンパイラと人間のコードレビュー担当者が異なる解釈を行うロジックを持つコードを作成することが可能となる。
この脆弱性は新たなものですが、Unicodeは過去に悪用された実績があります。例えば、ファイル名の末尾部分を反転させることで、ファイル名の真の拡張子を隠蔽する手法が用いられてきました。 最近の調査により、多くのコンパイラがソースコード内のUnicode文字を予告なく無視する一方、テキストエディタ（コードエディタを含む）はコメントを含む行やそれに基づくコードを再編成する可能性があることが明らかになった。したがって、エディタがコードとコメントを表示する形式や順序がコンパイラが解析するものと異なり、コードとコメントが入れ替わる可能性さえある。
詳細については読み進めてください。または、すぐに始めてトロイの木馬ソースの模擬ハッキングを試してみたい場合は、無料ページと公開ミッションにアクセスして、ご自身で体験してください。
双方向テキスト
トロイの木馬型ソースの攻撃の一つは、Unicode Bidi（双方向）アルゴリズムを利用しています。このアルゴリズムは、英語（左から右）やアラビア語（右から左）など、異なる表示順序を持つテキストの結合方法を管理します。方向指定フォーマット文字は、文字のグループ化と表示順序を再編成するために使用できます。
上記の表には、攻撃に関連するBidiの無効化されたキャラクターの一部が含まれています。例えば、
RLIe d a cPDI
RLIの略語は「右から左へ分離」を意味します。テキストをその文脈（PDI、方向性分離ポップで区切られた部分）から分離し、右から左へ読み取ります。その結果：
c a d e
ただし、コンパイラやインタプリタは通常、ソースコードを解析する前に、Bidiの無効化を含む書式制御文字を処理しません。方向指定の書式文字を単に無視すると、以下のように解析されます：
e d a c
古いワインを新しい瓶に？
もちろん、これは決して目新しいことではありません。過去には、ファイル名に方向性のあるフォーマット文字を挿入して、その悪意のある性質を偽装する手法が用いられてきました。 例えば「myspecialexe.doc」というメール添付ファイルは、RLO（右から左への置換）文字が存在しなければ一見無害に見えますが、これが真の名前の「myspecialcod.exe」を暴露するのです。
トロイの木馬攻撃「Source」は、ソースコード内のコメントや文字列に方向制御文字を挿入します。これらは構文エラーやコンパイルエラーを引き起こさないため、検出が困難です。これらの制御文字はコードロジックの表示順序を変更し、コンパイラが人間が読むものとは全く異なる内容を読み取るように仕向けます。
例えば、以下のバイトをこの順序で含むファイル：
方向指定フォーマット文字に従い、以下の順序で再配置されます
方向指定フォーマット文字が明示的に呼び出されない場合、コードは次のように表現される:
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 ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先事項とする文化を構築するために、貴組織をSecure Code Warrior 。AppSec管理者、開発者、CISO、セキュリティ関連担当者など、あらゆる立場の方々に対し、不安全なコードに関連するリスクを軽減するお手伝いをいたします。
報告書を見るデモを予約する
Laura Verheyde はSecure Code Warrior のソフトウェア開発者で、脆弱性のリサーチとMissions および Coding labs のコンテンツ作成に注力している。
11月初旬、ケンブリッジ大学は 「Trojan-Source」と題する研究を発表した。この研究は、方向指定文字を用いてソースコードやコメント内にバックドアを隠蔽する手法に焦点を当てた。これにより、コンパイラと人間のコードレビュー担当者が異なる解釈を行うロジックを持つコードを作成することが可能となる。
この脆弱性は新たなものですが、Unicodeは過去に悪用された実績があります。例えば、ファイル名の末尾部分を反転させることで、ファイル名の真の拡張子を隠蔽する手法が用いられてきました。 最近の調査により、多くのコンパイラがソースコード内のUnicode文字を予告なく無視する一方、テキストエディタ（コードエディタを含む）はコメントを含む行やそれに基づくコードを再編成する可能性があることが明らかになった。したがって、エディタがコードとコメントを表示する形式や順序がコンパイラが解析するものと異なり、コードとコメントが入れ替わる可能性さえある。
詳細については読み進めてください。または、すぐに始めてトロイの木馬ソースの模擬ハッキングを試してみたい場合は、無料ページと公開ミッションにアクセスして、ご自身で体験してください。
双方向テキスト
トロイの木馬型ソースの攻撃の一つは、Unicode Bidi（双方向）アルゴリズムを利用しています。このアルゴリズムは、英語（左から右）やアラビア語（右から左）など、異なる表示順序を持つテキストの結合方法を管理します。方向指定フォーマット文字は、文字のグループ化と表示順序を再編成するために使用できます。
上記の表には、攻撃に関連するBidiの無効化されたキャラクターの一部が含まれています。例えば、
RLIe d a cPDI
RLIの略語は「右から左へ分離」を意味します。テキストをその文脈（PDI、方向性分離ポップで区切られた部分）から分離し、右から左へ読み取ります。その結果：
c a d e
ただし、コンパイラやインタプリタは通常、ソースコードを解析する前に、Bidiの無効化を含む書式制御文字を処理しません。方向指定の書式文字を単に無視すると、以下のように解析されます：
e d a c
古いワインを新しい瓶に？
もちろん、これは決して目新しいことではありません。過去には、ファイル名に方向性のあるフォーマット文字を挿入して、その悪意のある性質を偽装する手法が用いられてきました。 例えば「myspecialexe.doc」というメール添付ファイルは、RLO（右から左への置換）文字が存在しなければ一見無害に見えますが、これが真の名前の「myspecialcod.exe」を暴露するのです。
トロイの木馬攻撃「Source」は、ソースコード内のコメントや文字列に方向制御文字を挿入します。これらは構文エラーやコンパイルエラーを引き起こさないため、検出が困難です。これらの制御文字はコードロジックの表示順序を変更し、コンパイラが人間が読むものとは全く異なる内容を読み取るように仕向けます。
例えば、以下のバイトをこの順序で含むファイル：
方向指定フォーマット文字に従い、以下の順序で再配置されます
方向指定フォーマット文字が明示的に呼び出されない場合、コードは次のように表現される:
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)
