現代社会を安定化しているのが、産業用制御システム（ICS）です。飲料水の浄化や電力の供給など、私たちが依存する物理インフラストラクチャの実現に ICS は使われています。また ICS は、製造業においても広く普及しており、自動車の製造やテレビの組み立てを行うロボットや、e コマースで購入された商品を出荷するフォークリフトも ICS の 1 つです。工場や公益事業、その他の事業会社が最新の産業インフラストラクチャへとシフトする中、それらのプロセスとデバイスを攻撃者から安全に保つことが必須要件となっています。
その種類を問わず、ICS アーキテクチャにおいては、ICS デバイスと産業用ワイヤレス ネットワーク間の接続を提供するアクセス ポイントが重要な要素の 1 つとなります。筆者らは、「From LOW to PWNED
」に触発され、ある ICS ワイヤレス アクセス ポイントに注目し、2 週間でどれだけ多くの脆弱性が見つかるかを確かめてみることにしました。
デバイス
産業用ワイヤレス アクセス ポイントである AWK-3131A について、製造元の Moxa Americas、Inc. は「あらゆるタイプの産業用ワイヤレス アプリケーション向けの高利便性かつ高信頼性ソリューション」、「AGV（無人搬送車）および AS/RS（自動入出庫）システムに最適」と記しています。さらに、同社は、これらのシステムが堅牢であることもそれとなくアピールしています。
筆者らは、2 週間かけてこのデバイスにどれだけ多くの脆弱性が見つかるかを調べることにしました。Talos の ICS 研究者の目からバグ ハンティングを試みたわけです。
1 日目 – スキャン
Moxa AP で利用できる機能に注目することから、調査を開始しました。これにより、バグ ハンティング全体を通じて、どこに労力を集中させるかを判断するための情報が得られます。これは、リサーチの初期段階に不可欠な作業です。
デバイスをスキャンすると、5 つのポートが開放されていることがわかりました。TCP22（SSH）、TCP23（Telnet）、TCP80（HTTP/Web）、TCP443（HTTPS/Web）と未確認のサービス TCP5801 の 5 つです。さらに調べると、BusyBox のデフォルト SSH サービスである Dropbear が SSH サービスとして使用されていることがわかりました。Telnet サービスでは、デバイスで BusyBox telnetd が実行されていることを確認できます。ポート 80 と 443 サービスは、組み込みデバイスで非常に多用されている GoAhead WebServer です。BusyBox は、広く使われているオペレーティング システムであり、ICS および IoT デバイスに適した小さいフットプリントで UNIX ライクなユーティリティを提供しています。
デバイスのマニュアルによると、デフォルト ユーザは「admin」で、デフォルト パスワードは「root」となっています。これらのクレデンシャルを使うと、SSH または Telnet を経由したログオンが可能ですが、制限された環境にしかアクセスできません。この対策には、改善の余地がありそうです。
2 日目 – Web アプリケーション
セキュリティの脆弱な管理システムがデバイス上でホストされていると、脆弱性を探り出すには絶好の環境となり、OWASP が述べている Top 10 Internet of Things 脆弱性カテゴリに該当することになります。
Web アプリケーション ログイン ページは、平凡なものに見えます。
しかし、コードを調べてみると、パスワード フィールドの最大長が 16 文字であることがわかります。当然、このシステムでは、長いパスワード文字列を使用できません。すでにこの時点で、システム設計に不備があり、ディクショナリ攻撃に対して脆弱である可能性が高いことがわかります。
このフォームの送信時には、ページに JavaScript として組み込まれている SetCookie() 関数が呼び出されます。さらに、/webNonce?time=<value> に対して GET 要求が行われ、Date().getTime() からの応答が time パラメータの <value> として使用されます。
次に例を示します。
これは、暗号化ナンスが cookie に格納されており、再利用されることを意味していました。ナンスを暗号化で再利用するという重大な脆弱性が存在することがすでにわかっていました。これは一見したところわかりにくいシステム脆弱性のようですが、パスワードをハッシュする方法に問題があることから、第三者が cookie を傍受してナンスを発見すれば、パスワードを容易に突き止めることができてしまいます。多くの Web アプリケーション システムがそうであるように、ユーザのセッション データに関連するデータは cookie に保存されます。しかし、ほとんどの Web アプリケーションでは見られないこととして、ユーザがログアウトして cookie を改ざんすると、パスワードを再送信しなくてもユーザが再度ログインできてしまいます。この 2 つの問題があるため、攻撃者がセッション固定攻撃を実行することが可能です（TALOS-2016-0225 / CVE-2016-8712）。
3 日目 – クロスサイト スクリプティング（XSS）
Web フロントエンドには、多くの XSS 脆弱性があります。これらの多くを使うと、認証済みユーザに対して cookie 値を表示することができますが、そこまで深刻な脆弱性ではありません。しかし、認証済みユーザがクリックしたときに cookie 値が攻撃者に送信されるように設計された悪意のある URL を作り出すことも、これらの脆弱性により可能です。
攻撃者がユーザのパスワードを突き止めることができるのは、ナンス値もわかっている場合だけです。しかし、Web ページが少なくとも 300 秒に 1 回ずつデバイスから要求されていれば、ナンスを単一の値に固定することが可能です。このため、盗み出した cookie を悪用する攻撃者は、決して変更されない値にナンスを固定することにより、有効期限切れにならない認証済みセッションを作り出すことができます。
4 日目 – コマンド インジェクション
デバイスには、デバイスの Web インターフェイスからアクセス可能な ping 機能が搭載されています。通常、この機能は認証済みユーザによって使用され、ネットワーク接続デバイスが応答しているかどうかをチェックすることができます。しかし、ping 対象の IP アドレスを指定するときのユーザ入力を検証するようになっていません。先頭にセミコロン（;）が付いた OS コマンドが入力されると、OS はそのコマンドをルート権限付きで実行します。ここにも別の脆弱性があるわけです。しかし、筆者らが責任を持ってこの不備を Moxa に伝えたところ、この脆弱性はすでに報告済みであることがわかりました。それでも、インターフェイスに任意のコマンド インジェクションへの脆弱性が存在することを見出すことができました。
筆者らがこの脆弱性を利用してみると、完全なルート権限付きで筆者らのリモート シェルを開放することにより、デバイスへのフル アクセスを取得できました。
このシェルに Telnet で接続すると、データとバイナリをこっそり抽出したり、パスワード ファイルなどのシステム ファイルを好きなように改ざんしたりすることができてしまいます。
5 日目 – コマンド インジェクションを伴う XSS
上記と同じ脆弱性を攻撃者が異なる方法で悪用すると、認証済みユーザがうっかり訪問するとバックドアが開放される悪意のある Web ページを作り出すことが可能です。
下記の HTML に認証済みユーザがアクセスすると、デバイス上でリモート シェルが起動します。BusyBox の Telnet 実装では、Telnet に ‘-l’ パラメータを含めると、接続ユーザにユーザ名とパスワードを求めるプロンプトが表示されなくなります。認証は、自動的に行われたものとみなされます。
このクロス サイト リクエスト フォージェリ（CSRF）攻撃により、設定変更や、デバイスを出荷時設定に戻すことに至るまで、さまざまなことが可能になります。そして、まだ別の脆弱性があります（TALOS-2016-0232 / CVE-2016-8718）。
6 日目 & 7 日目 – 週末なのでお休み。
土日は、しっかり楽しみました。
8 日目
この日は、重大な脆弱性（TALOS-2016-0231）が見つかりました。現時点では、この不備の詳細を明らかにできません。詳細を公開する前に対応が可能かどうかを Moxa と調整中です。
9 日目 – 構成情報のリーク
本 Web アプリケーションの URL やその他の「機能」には、認証なしでも機密にかかわる可能性のある情報を返す興味深いものがあります。たとえば、ページ /asqc.asp にアクセスすると、システム アップタイム、ファームウェア バージョン、BIOS バージョンなど、攻撃者に利用されかねない詳細情報が明らかになります（TALOS-2016-0236 / CVE-2016-8722）。
また、「systemlog.log」ファイルを認証なしで Web ルートから入手できます（TALOS-2016-0239 / CVE-2016-8725）。
しかし、攻撃者の関心をより引きつけるのは、「onekey」機能でしょう（TALOS-2016-0241 / CVE-2016-8727）。下記の URL に順にアクセスすると、デバイス ログと構成情報が格納されている zip ファイルを入手できます。認証は不要です。
1 番目: http://<Device IP>/makeonekey.gz
2 番目: http://<Device IP>/getonekey.gz
config.ini ファイルには、暗号化パスワードやワイヤレス クレデンシャルのほか、ファイアウォール ルール、MAC アドレス フィルタリングの詳細、SNMP の詳細、ルーティングおよび VLAN 情報が格納されています。
10 日目 – 意図的な情報公開
Moxa が管理者向けに提供している Windows ユーティリティ「Wireless Search Utility」を使うと、デバイス IP アドレスを変更する、デバイスの物理的な所在がわかるように「ビープ音」を鳴らす、構成の詳細をプルする、新しいファームウェアをアップロードするなどの操作が可能です。デバイスとアプリケーション間の通常のネットワーク トラフィックを観察すると、Moxa デバイスを検索するために UDP 5800 に対するブロードキャストが発生していることがわかります。ブロードキャスト ネットワーク上のデバイスは、基本的なデバイス詳細を返して応答します。攻撃者がこのアプリケーションを利用すると、デバイス構成に関する機密情報を入手できてしまいます。このプロトコルは、他のリサーチャーが他のデバイス上で調査した Moxa プロトコル（例）と共通点があり、その内容を探り出すのが比較的容易です。これは、ベンダーが変更する可能性が低い独自プロトコル/サービスであるため、攻撃者の作業負荷を軽減してしまいかねない詳細情報を公開するのは差し控えたく思います。
11 日目 – サービス拒否攻撃
どのような基本的な Web アプリケーション解析ツールであっても、スパイダリング目的を超えるアクションを実行すると、Moxa Web アプリケーションをクラッシュさせてしまいます。たとえば、任意の文字/文字列に対する HTTP GET 要求を送信するときに、その先頭のスラッシュ（/）を省略すると、Web サーバがクラッシュします（seg fault）（TALOS-2016-0237 / CVE-2016-8723）。
12 日目 – 別のコマンド インジェクション脆弱性
上記に加え、/forms/web_runScript 上の filename パラメータにも脆弱性があり、認証済みユーザになりすました悪用が可能です。しかし、攻撃者がこの脆弱性を悪用できるのは攻撃者がすでにファイルをアップロードして実行した場合であると考えられるため、実用上の観点から見ると、この形態の脆弱性は基本的に悪用しても効果がないと思われます。それでも、これが新たな脆弱性であることに変わりはありません。
13 日目 – 古い暗号化
Web サーバで使用している OpenSSL のバージョン（1.0.0d 8 Feb 2011）は、旧式のものであり、一部の攻撃に対して脆弱となる可能性があります。Nmap の示唆によれば、このバージョンは CCS インジェクション（CVE-2014-0224）、POODLE（CVE-2014-3566）、無効化された暗号化の使用（CVE-2015-3197）、DROWN（CVE-2015-3197）に対して脆弱です。
想定内のことかもしれませんが、上記の結果を得た nmap スキャン自体がデバイス上の Web サーバをクラッシュさせました。時間の制約により、これらの脆弱性がデバイス上に存在するかどうかの確認は行っておりません。
まとめ
今回のリサーチにより、デバイスを解析すると、どれだけ多くの脆弱性を迅速に発見できるかがわかりました。このデバイスが他のデバイスより脆弱かどうかに言及する意図はありません。実際のところ、今回発見した脆弱性は、どの ICS デバイスにも見られる脆弱性のタイプと一致しています。
発見した脆弱性を開示するプロセス全体を通じて Moxa Americas, Inc. は筆者らに協力的であり、GPL2 が適用されている同社の BusyBox 実装のソース コードを提供してくれました。ここに示す Moxa の最新パッチでは、これらの脆弱性に対する適切なフィックスがリリースされています。TALOS-2016-0231 に対応する新たなフィックスが近日中にリリースされる予定です。
すべての製造元が Moxa ほど対応が早いとは限りません。製造元の対応が遅く、ソース コードを提供してもらえない場合でも、当社ではデバイスを「ブラック ボックス」として扱いながら、数日のテストを行うだけで、ボックスに対する完全な権限を取得できています。
どのシステムの場合もそうですが、ソフトウェア脆弱性を修正するには、パッチを適用してシステム コードを更新する必要があります。ICS デバイスに関しては、パッチを迅速に適用するのが困難な場合があります。ICS システムの構築にどのようなコンポーネントが使用されているかが明確でないことがあり、通知がシステム マネージャに到達しないことがあります。そして、プロセスの停止が許されず、システムがきわめて大きな役割を担っているため、更新の適用自体が困難な場合もあります。
ICS インフラストラクチャを設計するにあたっては、システム内のコンポーネントの多くに標準装備のごとく脆弱性が付随している可能性があることを考慮する必要があります。Purdue Model for Control Hierarchy は、適切な ICS ネットワーク セグメンテーションのための優秀なリソースであり、悪用を困難にすることができます。セキュアで円滑に稼働する ICS ネットワークを実現するには、データ フローと必要なポートを理解しましょう。
カバレッジ
Talos では、これらの脆弱性に対する悪用の企てを検出するための Snort ルールを作成しています。システム管理者は、これらの脆弱性に関して新規または追加の情報があり次第、これらのルールが変更される可能性があることに注意する必要があります。最新の情報については、ご利用の Defense Center を再確認するか、Snort.org のサイトにアクセスすることをお勧めします。
Snort Rules: 40758、40820-40822、40880、40916、41085、41097、41102-41105、41220-41223、41352
悪意のあるファイルであることが疑われる未知の実行可能ファイルについては、Cisco Advanced Malware Protection（AMP）などのソリューションにより存在の有無を検出できます。
本稿は 2017年4月10日に Talos Group
Authors