Internet Infrastructure Review（IIR）Vol.27
2015年5月27日発行

PUAの定義

PUAの厳密な定義は専門家の間でも分かれます。直訳からも分かるとおり、悪性であるかどうかに関わらずユーザにとって不必要な機能を持つプログラムはすべてPUAとなり得るからです。ユーザにとってどのプログラムが不要であるかは個々の考え方や立場、状況、環境などによって異なります。そこで、ここではユーザがインストールを望んだソフトウェアとは関係がないにも関わらず、追加でインストールされてしまう不要なプログラムをすべてPUAと定義し、その中でもマルウェアと同様の手法を使うものを悪質なPUAと呼ぶことにします。

悪質なPUAの例

侵入経路

PUA導入のフレームワーク

ダウンロードさせられたPUAは単一のアドウェアである場合もありますが、一部のケースではダウンローダ型のプログラムになっており、更に複数のPUAをインストールするものが存在しました。ある事例では、追加でダウンロードされるPUAは多岐にわたり、数や種類は時々刻々と変化していたことから、PUAフレームワークの構築者が、依頼元からの要望に応じて利用者のシステムにPUAをインストールして金銭を得るPay-per-install（※45）が行われていると考えられます。

ダウンローダ型のPUAはインストールされると定期的にC＆Cサーバと通信をし、自己アップデートや新たなPUAをダウンロードします。また多くの場合、PUAはユーザが本来インストールしようとしていたソフトウェアもインストールするため、ユーザが騙されていることに気付きにくくなっています。

インストーラ形式のPUAの場合、利用者に分かりにくいデザインを悪用して、インストール時にPUAのインストールに関するユーザ同意を取り付けている事例も見受けられます。図-14はあるアドウェアのインストーラデザインの一例です。ユーザがインストールを望んでいるソフトウェアのインストーラに見せかけていますが、利用規約の文章はそれとは別のアドウェアに関するものであり、「CONTINUE」をユーザがクリックすると、裏ではそのアドウェアがインストールされます。ユーザは注意深く見てインストールしない限り、アドウェアのインストールに同意したとみなされてしまいます。

一部のPUAは自分自身のインストールに対する同意を取らずにインストールしていました。このようなPUAを実行してしまった場合では、利用者が提示されるソフトウェアの導入を拒否したとしても、本体はPC上に存在しつづけ、新たなPUAのダウンロードや、自身をアップデートしようとする試みが継続して行われます。また、追加ダウンロードされるPUAも、その一部はユーザに同意を取らずにインストールされていました。

Webコンテンツの改ざん

この手法以外として、自己署名されたルート証明書をインストールしておき、PUA自身はHTTP（S）のローカルプロキシとして動作してWebブラウザからの通信をすべて自分宛てにねじ曲げ、Webサーバからの証明書を横取りして改ざんし、自身がインストールしたルート証明書で署名を行う手法があります。これにより、MITM（※48）を行って通信を傍受することで、コンテンツに広告などを挿入して改ざんするタイプも発見されています。

どちらの手法とも暗号化されたHTTP通信のコンテンツであってもユーザに気付かれることなく改ざんすることが可能であり、非常に危険な手法です。また、Webブラウザのツールバーとして動作し、アドウェア業者によって提供される検索エンジンを使用することを強制したり、検索キーワードを盗み出すものも存在します。

Windowsの仕様を悪用

例えばPlugX（※49）やDridex（※50）などのマルウェアはそれぞれ異なる手法を用いてUAC（※51）のポップアップを回避し、自動的に管理者権限を奪取する機能を備えています。今回解析したいくつかのPUAにも、このような特権昇格を行う機能（多くはDridexと同様の方式で特権昇格する）が含まれていました。PUAが管理者権限を奪取するのは、後に複数のPUAを追加ダウンロードした際、ユーザに気付かれずにシステムフォルダにインストールするために必要だからです。

難読化

いくつかのPUAは、追加でダウンロードされるPUAが独自の形式で圧縮、もしくは難読化されており、通信路上では実行ファイル形式になっていないため、IDSやIPSなどで検出しにくくなっていました。また、PUA自体にもコードの難読化や重要な文字列の難読化が施されており、特徴として検出することや解析することが困難になっていました。

Sandbox対策

いくつかのPUAはインストールされた際、スタートアップに登録するだけで終了してしまい、次回PCを再起動するまで実行されないようになっていました。これは動的解析を行って短時間で判定を行うSandbox製品の検出を回避するための行為として、一部のマルウェアが使用していた手法と同様です。インストール直後に手動で実行したりPCの再起動を試みた場合でも、C＆Cサーバへの通信は発生するものの、すぐには新たなPUAがサーバからダウンロードされないようになっており、数日から長い場合で数ヵ月経ってから新たなPUAがダウンロードされるようになっていました。これもSandboxによる検出を回避するための手法の1つだと考えられます。

VM検知

多くのマルウェアにも仮想環境やSandboxでの実行を妨害する機能がついていますが、今回解析したPUAにもこのような機能が含まれていました。特に、執筆者がこれまでマルウェア解析を行った際には見ることのなかったHyper-VやXen、KVMなどの仮想環境も検知されるようになっていました。これは、WMI、WBEM（※52）の機能を使い、BIOSの情報などを取得することで判定を行っています。それ以外の手法も組み合わせ、現存するほぼすべての仮想環境を検知できるようになっており、検出すると実行を停止するなど、その挙動を変更するような仕組みが入っています。これも解析妨害の1つです。

組織がPUAに感染することのリスク

今回紹介したWebブラウザハイジャッカー型のPUAは、ユーザがアクセスしたWebサイトのURLなどをすべて外部に送信します。組織内でこのようなPUAに感染した場合、イントラネットのサーバ名やURLのパス情報、GETパラメータなどが一緒に漏えいします。これは企業などの組織の内部情報を守る観点では好ましくありません。

更に、PUAフレームワークによって追加でインストールされるプログラムにマルウェアが混入する可能性も考えられます。加えて、近年、広告サイト自体が改ざん（※53）され、ドライブバイダウンロード（※54）によってマルウェアがインストールされるケースもあります。アドウェアが表示した広告を閲覧した際に、悪意のあるWebサイトに誘導されて感染するような可能性がないとも言い切れません。このような事態にならないよう、PUAと言えど組織やユーザにとって不必要なソフトウェアがインストールされないように監視を行い、感染を発見した場合は速やかに対処できるような体制を構築しておくべきでしょう。

対策

悪質なPUAに感染しないようにするためには、まずユーザ自身が利用するソフトウェアの公式サイトを普段から把握しておくことでしょう。常に公式サイト、もしくはそこからたどることの可能な正規のミラーサイトのみを利用することで、偽のWebサイトから悪質なPUAをダウンロードすることを防ぐことができます。ダウンロードボタンに模した悪質な広告をクリックしてダウンロードをさせられてしまう可能性もあるため、公式サイトに記載されているハッシュ値と照合することなども、このような手法に騙されることを防ぐ手段の1つとなります（※55）。また、安易に無名な、もしくは出所の分からないソフトウェアをインストールしないように日頃から気をつけるべきです。もしあなたが管理者であれば、ユーザが勝手に任意のソフトウェアをインストールできないように一般ユーザ権限のみを与えることを検討するとよいでしょう。また、ユーザディレクトリ内にインストールするタイプのソフトウェアも存在するため、ソフトウェアの制限ポリシーやAppLockerなどのWindowsの機能を使って、システムディレクトリ内とプログラム置き場以外からのプログラムの実行を禁止することで、勝手にユーザがソフトウェアをダウンロードして使用することを防ぐことができます。

有名なソフトウェアの一部やプレインストールされているソフトウェアであってもインストール、もしくはアップデートの際にPUAをインストールさせようとするものも存在します。説明を読まず、安易に「次へ」ボタンをクリックしないようにしましょう。

また、PCにプリインストールされているソフトウェアにアドウェアが含まれているという事件も発生していることから、PCを調達する際にも注意が必要です。いくつかのメーカーはプリインストールされているソフトウェアの一覧が明示されているため、PCを選択する際の参考になります。また、一部メーカーの法人向けPCではプリインストールされるソフトウェアを出荷時に外せるようにカスタマイズできるものもあります。このようなPCの調達を検討するのも1つの手段になります。

それ以外にも脆弱性を突かれて強制インストールされる可能性もあることから、マルウェアへの対策と同等のことを行っておくことも必要です（※56）。今回紹介したように、UACを回避しようとWindowsの仕様を悪用する悪質なPUAも存在します。そのため、管理者アカウントでPCを管理している方はUACを最高レベルに引き上げておくことも検討してください。

IDとトークンのバリエーション

前号の報告では、IDを持つエンティティが認証されることで、当該IDに属性情報や認可情報が紐付きされ、IDと紐付けされた情報であるクレデンシャルが発行されるという一連の流れを説明しました。このとき認証時には、そのIDを持つエンティティの確からしさを保証するためにトークンが用いられます。認証はレルム（認証や認可が有効な領域）ごとに行われるため、レルムごとにIDとトークンの組を持つことが一般的です。ここで、IDやトークンとして実際に使われている事例を紹介していきます。

認証に関する業務を行うIdP（Identity Provider）がレルムごとに存在し、ユニークなIDがレルムごとに割り振られます。これはインターネット上のサービスを最初に利用する際に、必要事項を入力する利用登録画面を考えると理解できます。登録時には「ユーザID」などの項目でIDを入力する欄があることに加え、他のユーザとIDが被っていないかチェックを行っています。一方でサービス側がランダムにIDを割り振るケースも存在します。いずれの場合も、利用登録時にはメールアドレスや電話番号などのパーソナルデータも入力することが一般的です。これは、この段階では仮登録に過ぎず、入力されたメールアドレスにメールを、もしくは電話番号にショートメッセージを「チャレンジ」と共に通知し、ユーザに当該チャレンジを入力させることで本人確認を行うためです。仮登録時もしくはチャレンジ入力時には、トークンの一種であるパスワードを入力することが一般的です。このようにしてIDとパスワードの組が登録完了した時点でサービスが利用可能になります。

IDをレルム独自に割り振るのではなくメールアドレスで代用するケースも見られるようになりました。レルム独自にIDを管理するためのコストを削減できるため、またユーザが決めたIDや特にIdPが割り振ったランダムなIDを忘れてしまう事態が発生しなくて済むというメリットがあるためです。レルム独自IDを割り振る場合は、本人確認に利用したメールアドレスや電話番号を再度入力させてIDリマインダやパスワードリセットなどを行うWebページを運用する必要が生じ、サービス側の負担が増えることになります。一方でIDとしてメールアドレスを利用した場合には、リスト型攻撃の対象になりうることに留意する必要があります。これはレルムごとに同じIDを使い回している場合にも同じリスクがあると言えます。もちろんパスワードの使い回しをしないことが根本的な対策になりますが、同じIDで漏えいデータの紐付け・名寄せをされてしまうというリスクも存在します（※57）。また、メールアドレスをIDに利用したためにSNSやショッピングサイトにおいてIDを入力させるリマインダページに知人などのメールアドレスを入力することで、プライベートな情報が漏えいしてしまう事例が過去にありました。これらの状況を受けて、レルム独自IDの発行も行うが、メールアドレスもログイン時のIDとしても利用できるかどうか、ユーザに選択権を与えるといったシステムも見受けられるようになりました。

このようにIDはこれまで公開情報と考えられていましたが、秘匿しておくべき状況もありうると認識される事例も存在します。この問題に対する対策として、基本IDと派生IDという考え方について紹介します。各種ポータルサイトやSNSなどをIdPとして利用する場合には、同じIDとトークンの組で多種多用なサービスを利用するケースが存在します。このとき、サービスに応じて立場を変えたい、同じエンティティによる発言や操作であることを知られたくないというシチュエーションが出てきました。そこではじめに割り振られたIDを基本IDとして、実際にIDを利用する場面ではそれぞれのシチュエーションに応じて異なるIDを派生させるというアイデアが登場しています。これは、前述したようにIDが漏えいすること自体が脅威であるという状況を防ぐ単純な解法にあたります。派生IDによるログインを行う場合、基本IDに紐付けされたトークンを利用しますので、派生IDごとに別々のトークンを管理する煩雑さはなくなります。また、再ログイン時にトークンの再入力は必要なく、派生IDの切り替えのみでサービスに応じて異なる派生IDで立ち振る舞いを行うことができるようになります。注意すべき点は、どの派生IDでログインしているかを確認し忘れて、第三者から見て異なるユーザによる2つのアクティビティが紐付けされるケースが発生する可能性があることです。例えばログイン時に表示されているニックネームなどの情報に留意する必要があるでしょう。

IDを派生させるアイデアと同様に派生トークンという概念を考えることもできます。基本トークンとは別に、派生トークンを基本IDと結びつけることで、基本IDと派生トークンの組を認証に用いる手法になります。この派生トークンを1回使いきりのトークンと考えると、ワンタイムパスワードの亜種と考えることもできます。実際の用途としては、例えばスマートフォンのアプリケーションごとに派生トークンを保存（実際にはトークンそのものではなく、マスターパスワードなどを使って暗号化して格納しているケースも考えられます）させておくケースが考えられます。これはスマートフォンなどのパスワード入力が煩雑な環境においては有用な機能と考えられます。また、もし仮に特定のアプリケーションからのパスワード漏えいが発覚した場合でも、被害を限定させると共に、基本パスワードの変更ではなく派生パスワードの無効化のみで済むというメリットもあります。この観点では、権限委譲を行っていると考えることもでき、派生トークンを使った場合の認可範囲を、基本トークンの認可範囲よりも限定しておくことで、トークン漏えい時の影響を最小限に抑えることができます。

このように、ユーザの利便性（ID忘却）と安全性（ID使い回しやトークン漏えい）とのバランスを考慮した運用が望まれています。更に、この派生ID・派生トークンの概念を拡張させることで、図-15のように、基本IDと基本トークンの両方を使わない認証・認可の仕組みも可能となります。このような方式を利用している実際のシステムは現在見受けられませんが、プライバシー保護に留意しているユーザの将来的なニーズに応じて、こうした新しい使い方が今後実装されるかもしれません。

ワンタイムパスワードのバリエーション

このような背景のもと、インターネットバンキングシステムにおいて認証方式の強化が進められています。従来、用紙やカードに記載された乱数表やワンタイムパスワードを表示するハードウェアデバイスが利用されてきました。後者は、ATMなどでも認証に用いられるパスワードに該当する第一暗証番号（数字4桁の番号）と併用して一時的なパスワードも同時に入力することで認証する方式です。第一暗証番号が漏えいしていたとしても、1回ごとに使い捨てるワンタイムパスワードを利用することで、住所変更や多額の送金など特に重要な処理に関して本人確認を強化することができます。

しかし、Man-in-the-Browser攻撃（※61）や中間者攻撃に代表されるように、バンキングシステムにおけるトランザクションのうち、例えば送信先口座番号や送金額の書き換えが行われてしまうと、使い捨てのワンタイムパスワードを利用していたとしても、不正送金が可能となってしまいます。これは認証方式を強化したとしても、ブラウザなどで表示されている情報だけでは、正しいトランザクションかどうかをユーザ自身が明示的に確認することができず、攻撃者によって実際にはトランザクションを書き換えられている可能性を否定できない問題を示しています。この問題に対して、入力デバイスを備えたハードウェアデバイス利用の移行が進められています。

これまでも複数のバンキングシステムにおいて、認証時にハードウェアデバイスを併用する対策が採られていました。しかし、このハードウェアデバイスは入力インタフェースがなく単なるワンタイムパスワード生成器であったため、取引内容とは関係なく、正しいトークンを保持しているユーザかどうかのみを判定するためにしか利用できませんでした。また企業向けのバンキングシステムでは前述したX.509証明書の利用だけでなく、特定のIPアドレスや特定のPCからのトランザクションしか受け付けないなどの副次的な対策もなされていましたが、ユーザが目にするトランザクション自体を書き換えられている場合も考えられるため、根本的なMan-in-the-Browser攻撃対策を行うことはできません。つまり本人確認を強化しても無駄な対策になっていたわけです。

それに対して2015年に入り、金融機関によりワンタイムパスワードカード利用開始のアナウンスがありました。この新しいハードウェアデバイスは従来のデバイスと異なりテンキーなどの入力インタフェースを持つものであり、本人認証と共に書き換えられているかもしれないトランザクションの正しさも確認できる手法が採用されています。このデバイスは、従来のようにハードウェアデバイスからただ単に出力されるワンタイムパスワードのみを認証時に入力するのではありません。どの口座に入金しようとしているのかをユーザ自らが口座番号を入力することで、口座番号の正しさも保証するワンタイムパスワードをデバイスで生成・表示する機能を持ちます。これにより、攻撃者の意図する口座への入金を防ぐことができますが、他にもこのときはじかれたトランザクションのログを蓄積することで、攻撃者の持つ口座のブラックリストを自動的に形成することができるメリットがあります。また、ユーザ利便性を考慮して、入力デバイスを持たない単なるワンタイムパスワード生成器としても利用できます。これはユーザがあらかじめ登録している口座は安全であるという前提のもと、これらの登録済み口座に対する送金においては口座番号の入力を省くという手法です。

現状のこの対策に関して分析してみます。まず1点目は口座番号のみを入力しているため、入金額に関してのトランザクションの正当性を保証することはできません。大多数のユーザが登録している、例えば学校法人の授業料入金口座などの場合、ある特定の短期間にトランザクションの入金額を変更するなどの業務妨害になりかねない攻撃が考えられます。2点目は送金する銀行を指定していない点です。この場合、攻撃対象となる口座に対して、他の銀行の同じ口座番号が攻撃者の管理下にある場合、不正に送金されてしまうリスクがあります。いずれも、口座番号だけをユーザが明示的に確認しているという点が問題になります。トランザクションのうち、例えば入金額や銀行コードなどもユーザが明示的に確認するなど、対策を講じれば講じるほど、ユーザがデバイスに入力するデータが増えることになります。この点については、ユーザがどのくらいトランザクションを書き換えられる可能性を感じているかに応じて、様々な選択肢を与えることが1つの解決策になると考えられます。これはIDとしてメールアドレスを許可するかどうかの選択と同じような考え方に基づきます。この点においても、ユーザの利便性と安全性のバランスを取った運用が望まれています。

更に、FIDO AllianceによるSecond Factor UX（※62）を実装したブラウザも現れました。パスワード入力の代わりに、USBなどのインタフェースを介して小さなハードウェアデバイスを持っていることでパスワード入力を省いて本人認証を行うことができる規格であり、昨年より利用が拡大しています。しかし、実際に利用が広まると以下のような懸念も生まれます。USBフラッシュメモリの持ち運びを禁止する組織があるように、FIDO規格のUSBデバイスの利用が制限される可能性です。そこで、社員証のように居室に入室する際に必ず携帯し、かつ安全に管理することが求められているICカード型のデバイスを併用するなどの製品が今後登場する可能性もあるでしょう。現在、これらの本人認証方式の移行は過渡期にあります。今後、パスワードに代表されるような"Something you know"だけの単体利用ではなく"Something you have"もしくは"Something you are"にカテゴライズされるトークンとの併用が必須となる時期が近づいており、ユーザは重要な通信に対し、多少利便性を損なってでも、強固な本人認証方式を選択できる時代が始まりつつあります。

初期動作の概要

HDDのファームウェアを再プログラミングするモジュール（以下、nls_933w.dll）は、Platform Orchestratorと呼ばれるDLL（mscfg32.dll）によってロードされます。ロード後、mscfg32.dllはnls_933w.dllがエクスポートする関数アドレスを複数呼び出し、文字列の難読化解除、mscfg32.dll側の関数アドレスのコピーなどの初期化処理後に、メインの処理を行う関数を実行します。

nls_933w.dllのメインの処理を行う関数では、まずリソースからドライバ（以下、win32m.sys）がロードされます。その後、DeviceIoControl APIを介してwin32m.sysを制御し、モジュールのバージョンの確認、IOリクエストハンドラのクリア・セットなどの初期化処理が行われ、問題がなければATAコマンドを発行するためのIOリクエストのキューイング処理に移ります。

同キューイング処理では、最初にHDDの情報を取得するためのコマンド（IDENTIFY DEVICE）をwin32m.sysに送信します。取得した情報の中から、シリアル番号、ファームウェアリビジョン、モデル番号などを中心にチェックした後、モデル番号に応じて更なるコマンド（INITIALIZE DEVICE PARAMETERS）を送信することもあります。その後、HDDの情報からファームウェアの再プログラミングが可能なターゲットであることが判明した場合、ファームウェアの更新に関するコマンド（DOWNLOAD MICROCODE）を送信します。

IOCの検討

次に、nls_933w.dllに限らず、同様の動作を行うマルウェアを検出するための汎用的なIOCを検討します。まず思い浮かぶのが、HDDのファームウェアを識別する過程で用いられる、「Maxtor STM」「WDC WD」などのモデル番号ですが、nls_933w.dllの場合それらは難読化されており、難読化解除後の文字列もスタックに積まれるため、事後に有効なメモリ空間内でそれらを見つけることは困難だと言えます。

まとめ

本稿では、HDDのファームウェアを再プログラミングしてデータを隠蔽するマルウェアに対しては、まったく打つ手がないわけではなく、メモリからの検出が有効であることを示しました。今回、このマルウェアに特化して検出するためのIOCと、同様の機能を持つマルウェアを検出するための汎用的なIOCについて検討しましたが（※67）、後者に関して誤検出の少ないものを作るには、十分な解析と検証に基づいた、マルウェアの機能に即した定義が必要になります。よって、対応の緊急度合いに応じて臨機応変にどちらの観点で作るか判断していくと良いと思われます。