XZ Utilsのインシデントを教訓に、ソーシャルエンジニアリングによるオープンソースプロジェクトの乗っ取りに関する注意喚起。OpenSSFとOpenJS Foundationsが共同で
今回は「XZ Utilsのインシデントを教訓に、ソーシャルエンジニアリングによるオープンソースプロジェクトの乗っ取りに関する注意喚起。OpenSSFとOpenJS Foundationsが共同で」についてご紹介します。
関連ワード （不甲斐、細工、難読化等） についても参考にしながら、ぜひ本記事について議論していってくださいね。
本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。
Open Source Security（OpenSSF）とOpen JS Foundationは、先日発生したXZ Utilsのインシデントを教訓に、ソーシャルエンジニアリングによるオープンソースプロジェクトの乗っ取りに関する注意喚起を行っています。
注意喚起の中では、オープンソースプロジェクトの乗っ取りをはかる動きは現在もいくつかのプロジェクトで起きつつある可能性があることが示され、ソーシャルエンジニアリングによる乗っ取りを防ぐためのガイドラインが紹介されています。
XZ Utilsのようなプロジェクトの乗っ取りはいまも起きている
XZ Utilsのインシデントでは、正体不明の人物がメンテナとしてプロジェクトに入り込み、その権限を利用して巧妙なバックドアを仕掛けたと見られています。
この種の攻撃は、ソーシャルエンジニアリングによって築いた信頼を利用しているため、プログラムで検知したり防御したりすることは困難です。
そしてOpenJS Foundation Cross Project Council はある別のプロジェクトで、そのプロジェクトにほとんど関与していないにもかかわらず自分を新しいメンテナに指名することを望む、XZ utilsの手口に似た不審なメールを受け取っていることを明らかにしました。
つまりXZ utilsのようなインシデントはこれ1つではなく、似たようなことが別のプロジェクトでも起こりうるということです。
そこでOpenSSFとOpenJS Foundation はすべてのオープンソースメンテナに対し、ソーシャルエンジニアリングによる乗っ取りの試みに警戒し、兆候となるパターンを認識し、オープンソースプロジェクトを保護するための対策を講じるよう呼びかけています。
プロジェクト乗っ取りの兆候となる不審なパターン
今回説明された、ソーシャルエンジニアリングによるオープンソースプロジェクトの乗っ取りの兆候となる不審なパターンは以下です。
- Friendly yet aggressive and persistent pursuit of maintainer or their hosted entity (foundation or company) by relatively unknown members of the community.
（コミュニティの比較的無名のメンバーが、メンテナやその主催団体（財団や企業）を、友好的でありながら積極的かつ執拗に追求する） - Request to be elevated to maintainer status by new or unknown persons.
（新規または未知の人物によるメンテナへの昇格要求がある） - Endorsement coming from other unknown members of the community who may also be using false identities, also known as “sock puppets.”
（”ソックパペット（靴下人形≒雑に作った人形の意味か）”とも呼ばれる偽のIDを使用している可能性のある、コミュニティの未知のメンバーからの何らかのエンドースメント） - PRs containing blobs as artifacts.
（Blobを成果物とするプルリクエスト） - For example, the XZ backdoor was a cleverly crafted file as part of the test suite that wasn’t human readable, as opposed to source code.
（例として、XZバックドアはソースコードとは対照的に、テストスイートの一部として人間が読めないように巧妙に細工されたファイルであった） - Intentionally obfuscated or difficult to understand source code.
（意図的に難読化された、あるいは理解しにくいソースコード） - Gradually escalating security issues.
（セキュリティの問題が徐々にエスカレートする） - For example, the XZ issue started off with a relatively innocuous replacement of safe_fprintf() with fprintf() to see who would notice.
（例として、XZでは誰かが気づくかどうかを確かめるために、比較的無害なsafe_fprintf()をfprintf()に置き換えることから始まっている） - Deviation from typical project compile, build, and deployment practices that could allow the insertion of external malicious payloads into blobs, zips, or other binary artifacts.
（典型的なプロジェクトのコンパイル、ビルド、デプロイの慣行から逸脱し、外部の悪意のあるペイロードをBlobやzipファイルなどをバイナリの成果物に挿入できる可能性があること） - A false sense of urgency, especially if the implied urgency forces a maintainer to reduce the thoroughness of a review or bypass a control.
（誤った緊急時の認識、特に暗黙的な緊急性によって、メンテナンス担当者がレビューの徹底度を下げたり管理を迂回したりせざるを得なくなる場合）
このようなソーシャル・エンジニアリング攻撃は、メンテナがプロジェクトやコミュニティに対して抱いている義務感を悪用して、彼らを操ろうとしていると説明されています
そのため、メンテナに対して自責の念や、不甲斐なさ、プロジェクトのために十分なことをしていないという感情などを生み出すようなやりとりは、ソーシャルエンジニアリング攻撃の一部かもしれないと警戒すべきとしています。
と同時に、メンテナンス担当者を確実にサポートすることが、このようなソーシャルエンジニアリング攻撃に対する第一の抑止力となるとも説明しています。
プロジェクトのセキュリティを向上させるベストプラクティス
今回の注意喚起では、前述の乗っ取りの兆候の説明に加えて、プロジェクトのセキュリティを向上させることができるベストプラクティスの推奨事項も説明されました。
これらの推奨事項はソーシャルエンジニアリング攻撃を阻止することはできませんが、プロジェクトの全体的なセキュリティ体制を改善するのに役立つ可能性があるとのことです。
- Consider following industry-standard security best practices such as OpenSSF Guides.
（OpenSSF Guideなどの業界標準のセキュリティベストプラクティスに従うことを検討する） - Use strong authentication.
（強力な認証を使用する） - Enable two-factor authentication (2FA) or Multifactor Authentication (MFA).
（二要素認証（2FA）または多要素認証（MFA）を有効にする） - Use a secure password manager.
（セキュアなパスワードマネージャーを使用する） - Preserve your recovery codes in a safe, preferably offline place.
（リカバリーコードを安全な、できればオフラインの場所に保管する） - Do not reuse credentials/passwords across different services.
（異なるサービス間で認証情報／パスワードを再利用しない） - Have a security policy including a “coordinated disclosure” process for reports.
（報告書の「協調的開示」プロセスを含むセキュリティポリシーを持つ） - Use best practices for merging new code.
（新しいコードをマージするためのベストプラクティスを使用する） - Enable branch protections and signed commits.
（ブランチ保護と署名付きコミットを有効にする） - If possible, have a second developer conduct code reviews before merging, even when the PR comes from a maintainer.
（可能であれば、メンテナからのPRであっても、マージする前に二人目の開発者にコードレビューを行ってもらう） - Enforce readability requirements to ensure new PRs are not obfuscated, and use of opaque binaries is minimized.
（新しいプルリクエストが難読化されず、不透明なバイナリの使用が最小化されるように、可読性要件を実施する） - Limit who has npm publish rights.
（npmへの発行権限を持つ人を制限する） - Know your committers and maintainers, and do a periodic review. Have you seen them in your working group meetings or met them at events, for example?
（コミッターやメンテナを把握し、定期的なレビューを行なう。例えば、ワーキンググループのミーティングで彼らを見かけたり、イベントで彼らに会ったりしましたか？） - If you run a repo, consider adopting Principles for Package Repository Security.
（もしあなたがリポジトリを運営しているならば、パッケージリポジトリのセキュリティのための原則の採用を検討してください）