今年初め、周辺機器メーカーのケンジントンは、悪意のあるウェブサイトが被害者のコンピュータを密かに乗っ取るために悪用される可能性のある脆弱性を修正するためにデスクトップソフトウェアにパッチを当てた。
今回、このリモートコード実行の脆弱性を発見し、メーカーに報告したプログラマーは、未だ対処されていない同様に深刻な欠陥を発見した。
火曜日のブログ投稿で、Stripe のソフトウェア エンジニアである Robert Heaton 氏は、2 月に脆弱性を発見し、その後修正されたこと、そしてその後に 2 つ目の問題を発見し、未だに修正されていないことについて語った。
彼は、これらの欠陥は比較的簡単に悪用できると示唆した。攻撃者は、被害者を、Windows PCまたはMacにインストールされているKensingtonWorksソフトウェアを攻撃する悪意のあるJavaScriptを含むウェブページに誘導する必要がある。その結果、コンピュータ上でコードが実行され、ファイルの盗用やデータの改ざんなどが可能になる。
しかし、彼はこのシナリオの可能性を軽視している。なぜなら、かなり珍しいソフトウェアを悪用するよりも、Flash Player のアップデートを装ったマルウェアをユーザーからダウンロードさせて実行させる方が、犯罪者にとっては成功する可能性が高いからだ。
1月にデビューしたKensingtonWorksは、Kensingtonのトラックボールやマウスなどの周辺機器の機能をカスタマイズするためのアプリです。JavaScript、Node.js、その他のWebテクノロジーを用いてクロスプラットフォームのデスクトップアプリを開発できるElectronフレームワークをベースにしています。ソフトウェア開発者にとって比較的使いやすい一方で、セキュリティの確保はやや困難です。
問題は、ローカルWebサーバーを実行していて、それを保護していないことです
Electronアプリは、特に情報セキュリティ調査員によって特定された様々な問題に対処するために最近のリリースで追加された改良点を活用すれば、比較的安全なアプリを作成することは可能です。しかし、このフレームワーク上に構築されたアプリケーションをどのように保護するかは明確ではなく、Electronの初期バージョンを使用して作成されたソフトウェアは、脆弱性の少ないパターンを実装するように書き換えられていない可能性が高いです。
ウェブ技術は、経験やスキルレベルに応じてセキュリティを確保するのが非常に難しいことで知られていますが、ローカルファイルシステムにアクセスできるNode.jsと統合すると、さらに困難になります。Electronの最近のセキュリティ強化の多くは、新しいAPI（contextBridgeなど）やベストプラクティス（preload.jsスクリプトの使用など）に基づいており、ElectronのメインプロセスとNode.js APIへのアクセスを、ウェブコードを実行するElectronのレンダリングプロセスから分離しています。しかし、安全なElectronコードの書き方に関する例は依然として非常に少ないのが現状です。
しかし、ヒートン氏にとって、問題は Electron フレームワークの使用ではなく、ユーザー インターフェイスのクリックを受信するためにセキュリティが不十分なローカル Web サーバーを使用するなど、KensingtonWorks アプリのアーキテクチャにあります。
「根本的な原因はElectronとは関係ないと思います」と彼はThe Registerに語った。「問題はローカルWebサーバーを運用していて、それを保護していないことです。アプリがElectronフロントエンドを使用しているという事実は、この問題には影響しません。2つ目の脆弱性は、ElectronアプリがデータをサニタイズしないとXSS攻撃を受ける可能性があるという事実を悪用していますが、ブラウザでも同様であり、誰もそれについてあまり文句を言いません。」
こうした粗雑な設計の選択により、KensingtonWorks は格好の標的になっていると彼は投稿で主張した。
「このアプリケーションは2つのコンポーネントで構成されています。ユーザーがマウスを設定するためにクリックするUIと、ユーザーのローカルマシンで動作するWebサーバーです」と彼は説明した。「UIはWebサーバーにHTTPリクエストを送信し、Webサーバーはそれに応じてユーザーのマウス設定を更新します。」
CovalenceカンファレンスでElectron開発者が絆を深める: Slack、Visual Code Studioなどのクロスプラットフォーム技術を習得している開発者に話を聞く
続きを読む
ヒートン氏は、ローカルウェブサーバーをポートが開いているマシン上に放置しておくのは不必要なリスクだと主張している。ローカルウェブサーバーを安全に運用することは可能だと認めつつも、そうすることでアプリケーションの攻撃対象領域が拡大し、ケンジントンの開発者がコードミスを犯す機会が増えると主張している。
彼によると、ほとんどのデスクトップアプリケーションは、アプリインターフェース上のユーザークリックの処理にローカルWebサーバーに依存していない。HTTPリクエストを経由せず、バックエンドコマンドを直接実行するだけだ。しかし、ケンジントンの開発者がこのアプローチを選んだのは、Electronを使いたかったからだと彼は推測する。Electronを使えば、macOSとWindowsの両方に対応した1つのアプリを開発・保守でき、OSごとにネイティブアプリを個別に開発する必要がなくなるからだ。
ケンジントンのアプローチの問題点は、アプリのローカルウェブサーバーに認証機能がほとんどないことだと同氏は述べた。
「これは、攻撃者が長くてランダムなAPIキーなどを知らなくても、UIがサーバーに送信するリクエストを簡単に偽装できることを意味します」とヒートン氏は述べた。「おそらくケンジントンが認証を追加しなかったのは、自社の信頼できるUI以外がサーバーと通信しようとするとは考えていなかったからでしょう。」
6月に公開された最初の脆弱性では、悪意のあるウェブページがJavaScriptを使用して、KensingtonWorksがインストールしたウェブサーバー（https://www.kensingtonworks.com/）にバックグラウンドHTTPリクエストを送信し、http://localhost:9090被害者のマシン上で任意のコードを実行できる可能性がありました。認証に使用できるのは5桁のデバイスIDのみだったため、JavaScriptは5分ほどであらゆる数字を試すことができました。
Kensingtonは、悪意のあるコードの実行に悪用される可能性のあるエンドポイントをKensingtonWorksから削除することでこの問題を修正しましたemulatebuttonclick。しかし、アプリ全体のセキュリティモデルは修正されませんでした。
入力内容をクリーンアップする
未修正のバグは、クロスサイトスクリプティング（XSS）の脆弱性に関連しています。ヒートン氏によると、ウェブサイトやElectronアプリは、ユーザー入力をサニタイズすることでXSSを防御できます。例えば、機能コードとして解釈できる文字を、無害なテキストとして読み取れるエンコードされたフォームに置き換えるといったことです。「しかし、KensingtonWorksはこれを行っていません」と彼は言います。
Heaton氏は、攻撃者が悪意のあるJavaScriptを含むウェブページを作成し、KensingtonWorksのエンドポイントである にHTTPリクエストを送信する方法について説明しました/config/apps?device=$DEVICE_ID。このエンドポイントは、アプリ固有のデバイス設定を作成するためのもので、内蔵ウェブサーバー経由でアクセスできます。ユーザーが次にKensingtonWorksアプリを開くと、アプリはこれらの設定を表示しようとし、設定をJavaScriptコードとして解釈して実行します。このコードは以下のようなもので、空のファイルを作成します/tmp/oh-dear。
<script>require('child_process').spawn('touch', ['/tmp/oh-dear']);</script>
「ペイロード内のNode.jsのspawn関数により、攻撃者は任意のシェルコマンドを実行し、直接リモートコード実行が可能になります」とヒートン氏は述べた。彼はさらに、この2つ目の脆弱性について2020年7月6日にケンジントンに報告したが、同社は対応せず、この脆弱性も修正しなかったと付け加えた。
「ケンジントンは私が報告してから1週間ほどで最初の脆弱性を修正しましたが、2つ目の脆弱性はまだ修正されていないのは残念です」と彼はメッセージに記した。「私は通常のサポートメールアドレスにメールを送っていますが、専用のセキュリティメールアドレスがあればもっと楽だったでしょう。そうすれば、メールが受信されたことが分かりますし、返信がない場合はフォローアップもできます。」
周辺機器メーカーは、ヒートン氏の調査結果を調査中だと述べた。「ケンジントン社はこの件を認識しており、ソフトウェアチームが調査中です」と広報担当者は述べた。®
