タクシーハッカー
XZでの事件は間違いなく爪痕を残すだろう それは何年も記憶に残るでしょう、そしてそれは、 当時の言及 事件の続報を共有する記事の 1 つで、«ジア・タンの仕事 es 応用ソーシャル エンジニアリングの最良の例の 1 つ» そしてそれは、将来知られる他の多くの試みや事例の基礎となるでしょう。
この 現時点では、開発者、プロジェクト、財団の両方がこれについて明確に認識していることです。そして、多大な努力と変更が実装されているにもかかわらず、人材が不足し、メンテナが不足しているパッケージやプロジェクトが多くあり、XZ で起こったことと同様の状況に陥る可能性があることを説明しました。
これらのケースはすでに発生し始めており、OpenSSF (Open Source Security Foundation、オープンソース ソフトウェアのセキュリティを向上させるために Linux Foundation の後援の下に設立された団体) あなたはすでにこの種の活動に気づき始めていますが、 最近、人気のオープンソース プロジェクトを支配しようとする試みに関連した懸念すべき活動についてコミュニティに警告を発しました。
En XZ襲撃事件と同様の事件、正体不明の人物が判明 以前はオープンソース開発に携わっていた オープンソース ソフトウェア プロジェクトの操作と制御を試みた。これらの個人は、ソーシャル エンジニアリング手法を使用して運営評議会のメンバーと通信しました。 OpenJS財団から、 JavaScript プロジェクトを開発するための中立的なプラットフォーム。
この人たち 疑わしい実績を持つサードパーティ開発者が含まれていた オープンソース開発において。彼らはメッセージの中で、人気のある JavaScript プロジェクトの 1 つを早急に更新する必要があることについて OpenJS 管理者を説得しようとしていました。彼らは、重大な脆弱性に対する保護を追加するためにアップデートが必要であると主張したが、これらの脆弱性に関する具体的な詳細は明らかにしなかった。
提案された変更を実装するために、容疑者の開発者は、それまで開発において限定的な役割しか果たしていなかったにもかかわらず、プロジェクトのメンテナーに加わることを申し出ました。さらに、OpenJS に関連していない他の 2 つの人気のある JavaScript プロジェクトでも、同様の疑わしいコード試行のケースが検出されました。
これが OpenSSF の理由です （オープンソースセキュリティ財団） と OpenJS (OpenJS財団) 警告を発しました オープンソース プロジェクトのすべての開発者と管理者は、プロジェクトを制御しようとする試みを示す可能性のある次のような不審なパターンに注意する必要があります。
オープンソース プロジェクトを保護するにはどうすればよいでしょうか?
OpenSSF では、オープンソース プロジェクトは協調的な性質を持っているため、攻撃者が利用できる一連の脆弱性が発生しやすいと述べています。そのため、攻撃者がソーシャル セキュリティを適用するために利用する最も一般的な脆弱性のリストを共有しています。エンジニアリング。
疑わしい試みのパターン:
- 古い依存関係: 最も一般的な脆弱性の 1 つは、古い依存関係の使用です。
- フレンドリーだが攻撃的で執拗な行動: 比較的無名なコミュニティのメンバーが、メンテナーまたはコミュニティをホストするエンティティ (財団や企業) を追及しようとします。
- ランクを上げるリクエスト: 新規または無名の人々が、プロジェクトへの重大な貢献歴を持たずに昇進に応募します。
- 他の未知のコミュニティ メンバーからの支持: 攻撃者は偽の ID を使用してリクエストをサポートし、誤った信頼感を生み出す可能性があります。
- プルリクエスト: 悪意のあるファイルはバイナリまたは BLOB 内に隠されているため、検出が困難になる場合があります。
- 意図的に難読化された、または理解しにくいソース コード: 目標は、コードレビューを困難にし、潜在的な脆弱性を隠すことです。
- セキュリティ問題が徐々に拡大: 攻撃者は最初に軽微な脆弱性を導入し、その後より深刻な問題にエスカレートする可能性があります。
- 一般的なプロジェクトのコンパイル、構築、展開の実践からの逸脱: これらの逸脱により、悪意のあるコードがバイナリに挿入される可能性があります。
切迫感の誤り： 攻撃者は、メンテナンス者にコードの大まかなレビューを実行するよう圧力をかける緊急の環境を作り出すことができます。
これらのソーシャル エンジニアリング攻撃は、メンテナーがプロジェクトやコミュニティに対して抱いている使命感を利用して、それらを操作しようとします。なぜなら、変更を導入し、脆弱性を解決し、または非常に執拗にメンバーにさらなる信頼を与えるという圧力を生み出すことで、担当者や担当者は、関連するテストを検証または実行する前に諦めてしまうのです。
あなたが私ならそれについてもっと知りたい、詳細はで確認できます 次のリンク。