- Lotusbail パッケージは、正規のWhatsApp Web APIライブラリである Baileys をフォークしたもので、6か月間にnpmで5万6千回以上ダウンロードされた マルウェア混入パッケージ
- 正常に動作するAPI機能を提供しつつ、WhatsAppの認証情報、メッセージ、連絡先、メディアファイル を窃取して攻撃者サーバーへ送信する
- データは RSA、AES、Base-91、LZString など複数の暗号化と難読化の工程を経て送信され、セキュリティ監視の回避 が可能
- パッケージは ハードコードされたペアリングコード を通じて、攻撃者のデバイスをユーザーのWhatsAppアカウントに恒久的に接続する バックドア を設置する
- この事例は サプライチェーン攻撃の高度化 を示しており、静的解析だけでは検知できない 挙動ベースのセキュリティ監視の必要性 を強調している
Lotusbailパッケージ概要
lotusbail は正規の @whiskeysockets/baileys のフォークで、WhatsApp Web API の機能をそのまま提供する
- メッセージの送受信が正常に動作するため、開発者が疑わずにインストールする可能性が高い
- npmに6か月間登録されており、執筆時点でも引き続きダウンロード可能な状態にある
- 実際の機能の裏では、WhatsApp認証情報の窃取、メッセージの傍受、連絡先の収集、バックドアの設置 などの悪意ある動作が隠されている
窃取される情報
- 認証トークンとセッションキー、全メッセージ履歴、電話番号を含む連絡先一覧、メディアファイルと文書、持続的なバックドアアクセス権限 が含まれる
- すべてのデータは攻撃者サーバーへ送信される前に 暗号化処理 される
動作方式
実際に動く偽装機能
- 多くの悪意あるnpmパッケージは誤動作したり不審なコードによって容易に識別できるが、Lotusbailは 正常に動作するAPI を装っている
- 正規のBaileysライブラリをベースとしており、メッセージ送受信機能が完全に実装 されている
- これにより、開発者が「正常に動くコード」であれば悪意ある挙動を疑わなくなる ソーシャルエンジニアリング的手法 が使われている
データ窃取と送信
- パッケージは WhatsAppと通信するWebSocketクライアント をラップする形で動作する
- 認証時に認証情報をキャプチャし、メッセージ受信・送信時に内容をすべて複製する
- 正常機能はそのまま維持され、ただすべてのデータが 攻撃者に二重送信 される
- 窃取されたデータは カスタムRSA実装 によって暗号化されて送信される
- WhatsApp自体のエンドツーエンド暗号化とは別に存在し、ネットワーク監視回避用の暗号化 として使われる
- サーバーアドレスはコード内に直接露出せず、暗号化された設定文字列 の中に隠されている
- Unicode変数操作、LZString圧縮、Base-91エンコード、AES暗号化 など4段階の難読化を適用
バックドアの設置
- WhatsAppの デバイスペアリングコード 機能を悪用して、攻撃者のデバイスをユーザーのアカウントに接続する
- パッケージ内には AESで暗号化されたハードコード済みペアリングコード が含まれている
- ユーザーが認証すると、攻撃者のデバイスも同時に接続され、持続的なアカウントアクセス権限 を獲得する
- 攻撃者はメッセージ閲覧、送信、メディアのダウンロード、連絡先へのアクセスなど アカウント全体を制御 できる
- npmパッケージを削除しても攻撃者のデバイスは依然として接続されたままで、遮断するには WhatsAppの設定ですべてのデバイス接続を手動で解除 する必要がある
解析回避手法
- コードには 27個の無限ループトラップ が含まれており、デバッグツールを検知すると実行が停止する
- デバッガー、プロセス引数、サンドボックス環境などを検知して 動的解析を妨害 する
- 悪意あるコード部分にはコメントが付けられており、体系的な開発管理の痕跡 が存在する
結論とセキュリティ上の示唆
- サプライチェーン攻撃の高度化 が進んでおり、正常に動作するコードの形に偽装した事例が増加している
- 静的解析と評判ベースの検証 だけでは検知が難しく、実行中の挙動分析(behavioral analysis) が必要となる
- Lotusbailの事例は、「コードが動作するという理由で安全だと信じる」セキュリティ上の隙を悪用したもので、ランタイム挙動監視システム構築の重要性 を示している
- Koi Security研究チームは、このようなランタイムベースの検知技術を通じて、既存の検証手順を回避する脅威を特定した
1件のコメント
Hacker Newsの意見
マルウェア事件が起きるたびに、セキュリティチームがデータを過度にロックする方向へ進むのがもどかしい
WhatsAppメッセージの流出がきっかけだったとしても、結局は別のものが盗まれていたはず
アプリを特定の署名しか読めないようにすると、正当なバックアップやデータアクセスまで不可能になる
セキュリティ強化は良いが、何もかもをロックするような過剰防御は別の問題だと思う
ユーザーはWhatsAppアカウントに別のクライアントを接続するのと同じようにアクセスし、その結果、全データへのアクセスが可能になる
WhatsAppがまともな公式APIを提供していれば、こうした事態は減っていたはず
関連ドキュメント: Baileys Wiki
昔はマルウェアも多かったが、そのぶん自由と相互運用性も大きかった
こうした攻撃はもはや予見可能な結果だと思う
NPMのようなパッケージマネージャは、ビルド直前に依存関係を取得する構造なので本質的に脆弱だ
バージョン管理システムを迂回しつつ、膨大な依存関係を検証なしで受け入れる文化が問題だ
NPMだけでなく、Cargo、Docker、CI/CDなど、どのエコシステムも似た問題を抱えている
「名前でインストールして終わり」という仕組みなので、信頼ベースが大きすぎる
解決策もなかなか見つからない — 協業を諦めるわけにもいかないし、かといって完全なセキュリティも不可能だ
結局、怪物はすでに家の中にいる
git URLを直接指定しても結果は同じだろう
結局は依存関係管理そのものの構造的問題だ
言語に依存しない標準化されたパッケージマネージャが必要だと感じる
署名検証、出所保証、API標準化といった機能が必須だ
xz事件のように、感染したパッケージがそのまま配布されることもある
しかもシステムパッケージマネージャは最新版対応が遅く、開発には不向きだ
結局、npm、cargo、pipのようなツールが必要になる理由でもある
パッケージマネージャの問題ではなく、そもそも信用できないコードだった
マルウェア作者が関数名をexfiltrateCredentialsのように露骨に付けていたのは笑える
デバッガ検知まで入れておきながら、肝心のコード難読化はしていなかったのが皮肉だ
マルウェアのテストですら、今や開発の一形態になった時代だ
「開発者が何も考えずにインストールする依存関係」という言葉が不気味だ
セキュリティポリシーが厳格な組織でなければ、現実的に防ぐのは難しい
結局のところ、解決策はnpmをあまり使わないことだけかもしれない
タグ指定にするといつでもサプライチェーン攻撃にさらされうる
業界は思っている以上に多くの盲目的な信頼の上で回っている
自動デプロイシステムには「二度考える」余裕すらない
JavaScriptにもApache Commonsのような信頼できる大規模ライブラリがあればいいのにと思う
Apache Commonsの紹介
lotusbailパッケージは、WhatsApp Web APIを装った悪意あるnpmパッケージだ
6か月間配布され、認証情報の窃取・メッセージ傍受・バックドア設置など多様な攻撃を行った
JSエコシステムに依存する開発者には、現実的にリスク緩和戦略が必要だ
DockerやVMを活用する方法が言及されている
すべての開発環境をコンテナ化し、依存関係は固定バージョンでロックした
グローバルインストール禁止、自動更新禁止、手動検証必須
機密性の高いプロジェクトには専用ワークステーションを用意し、定期的に初期化していた
面倒だが、それが現実的なセキュリティだ
あるいはJSエコシステムを離れるのも一つの方法だ
OSやDockerのレベルでネットワーク接続の許可可否を確認できるべきだ
カーネルは共有するが、JSエコシステムの攻撃を防ぐには十分だ
npmでコンテナ脱出攻撃が出てきたら、その時点でVMへ移るつもりだ
最初は過剰防衛だと思っていたが、今では速度も速く安定している
その間に悪性かどうかが判明するからだ
このパッケージは最初からセキュリティ上の失敗だった
公式APIではないクライアント認証の再実装を使い、ユーザー秘密鍵を第三者が扱っていた
ユーザーも注意すべきだったが、完全に責めるのは難しい
「WhatsApp Business Platform」に登録してはじめてAPIアクセスが可能になる
本当のAPIがあれば、こうしたことは起きなかったはずだ
ただし認証時に秘密鍵を第三者へ渡すのは危険だ
普通は自分のアカウントを自動化したくて、こうしたパッケージをインストールする
最近はLLMが生成したブログ記事であふれている
品質は低いがコストが0なので、マーケター目線では効率的だ
従来の文章執筆は今やレガシーになってしまった
サプライチェーン攻撃が増えているように思う。開発者はどう対処すべきだろうか？
自動スキャンでこうしたパターンを検出し、検証手順を強化すべきだ
コンテナ化、依存関係ロック、セキュリティスキャン、更新の遅延適用が必須だ
npmのグローバルインストールは最悪の選択だ
rootless podmanのようなコンテナやVMを活用してリスクを最小化すべきだ