Internet Infrastructure Review（IIR）Vol.26
2015年2月25日発行

レジストリ登録情報の改ざんによる脅威

インターネットの世界では、ドメイン名が重要な役割を果たしています。例えば、クライアントがwww.example.comにアクセスする際、サーバが属するexample.comゾーンの権威DNSサーバに問い合わせを行い、サーバのIPアドレスを取得します（図-13左）。この一連のやりとりを名前解決と言います。

しかし、名前解決の結果、正規のサーバではなく、攻撃者が用意したサーバにアクセスさせられてしまう攻撃があります。この攻撃はドメインハイジャックと呼ばれ、攻撃手法として、「ドメインの所有者のDNSサーバに不正侵入しレコードを書き換える」「DNSキャッシュポイズニングにより不正なIPアドレスをキャッシュDNSサーバにキャッシュさせる」「BGPに誤った情報を流し、特定のトラフィックを本来のネットワークとは異なるネットワークへルーティングさせる」などが存在します。

このような攻撃手法はISPやサービス提供事業者の対策により影響は少なくなっていますが、異なる攻撃手法によるドメインハイジャックが、国内企業のドメインにおいて、2014年9月以降に複数発生しました。この攻撃手法では、レジストリに登録されているドメイン名に関する登録情報を書き換えることで、名前解決の際に、攻撃者が用意したサーバのIPアドレスを応答させるようにします。この結果、正しいドメイン名を入力しても、攻撃者が用意したサーバにアクセスさせられ、フィッシングやマルウェア感染などの被害に遭ってしまう可能性があります。TLD（Top Level Domain）（※43）の権威DNSサーバに偽の情報が登録されるため、自身のサーバのセキュリティレベルが高くても、攻撃の影響を受けてしまうのが特徴です（図-13右）。なお、偽の情報が登録されるのは、サーバが属するドメインの上位の権威DNSサーバであればよいため、ドメインの階層が深い場合、TLDではなく、SLD（second-level domain）などの権威DNSサーバに偽の情報が登録される場合があります。

拡大する

図-13 www.example.comの名前解決（DNSプロトコルは一部省略）

2014年9月から10月にかけて発生したインシデントでは、国内の複数の企業が保有する「.com」ドメインに対して、Webページの訪問者にマルウェアをダウンロードさせようとする攻撃が行われました（※44）（※45）。また、2014年11月には海外企業が提供するSNS連携サービスを利用している国内外の大手新聞社やニュースサイトなどで、Webページの訪問者に不正なJavaScriptファイルを読み込ませ、SEA（Syrian Electronic Army）の意匠を表示させるインシデントが発生しました。

なお、2014年11月のインシデントでは、すべてのNSレコードが攻撃者のものに改ざんされ、必ず不正なJavaScriptが読み込まされる状態でしたが、9月から10月の国内企業のドメインのインシデントでは、正規のNSレコードは削除されずに攻撃者のNSレコードの追加だけが行われていました。このため、一部のユーザのみが影響を受ける結果となりました。

今回と同様の手法を使った攻撃は、海外においては既に数多く発生しています。例えば、2013年では、多数のレジストリが攻撃対象となり、毎月のように事件が発生しています（※46）。

レジストリ登録情報改ざんの手法

ドメインに関する情報はTLDを運用・管理するレジストリという組織のデータベースに登録されています。ドメインを登録するには、レジストラと呼ばれる仲介業者（またはレジストラのサービスを再販するリセラー）のサービスを利用して、レジストリにドメインの登録申請を行います。ドメインの登録情報は図-14の矢印の順番で受け渡され、レジストリの権威DNSサーバとWHOISサーバに登録されます。

したがって、攻撃者は以下のいずれかのポイントを攻撃することで、レジストリ登録情報の改ざんを行います。

1. 登録者やリセラーになりすまして、レジストラのデータを改ざんする。
2. レジストラになりすまして、レジストリのデータを改ざんする。
3. レジストリやレジストラのシステム上の脆弱性を利用してデータを改ざんする。

なりすましはドメインの登録者に対するフィッシングやマルウェア感染、ソーシャルエンジニアリングなどで得られた情報を基に行われます。また、レジストリやレジストラのアカウント情報流出やリスト型攻撃が原因となることも考えられます。

改ざんされるデータは、レジストリのWHOISサーバに登録されているネームサーバや権威DNSサーバに登録されているNSレコード及びグルーレコードです。

拡大する

図-14 ドメイン情報登録の流れ

対策

以下にレジストリ登録情報の改ざんの対策を説明します。

レジストリ／レジストラ／リセラー

最も基本的なセキュリティ対策として、OSやWebアプリケーション、APIなどの脆弱性の修正やパッチ適用が必要です。組織内のクライアントもパッチ適用やアンチウイルスのインストールなどの対策を行わなければなりません。

次に、なりすましに備え、ユーザアカウントの認証機能の改善を検討します。多くのシステムではパスワードによる認証を行っていると思いますので、複雑なパスワードの設定やパスワードの使い回し防止が必要になります。可能であれば、2段階認証やクライアント証明書による認証の導入も検討してください。

また、ユーザアクティビティの監視・通知機能の実装も検討してください。アカウントのログインや登録情報の変更を通知することで、ユーザが意図しない操作に気付くことができます。また、ログインや登録情報変更の履歴があれば、いつ頃から不正アクセスがあったのかユーザ自身でも確認できます。

実際の攻撃に備え、攻撃の検知と対処の体制を整える必要もあります。セキュリティ機器やシステムの負荷やログから攻撃を検知し、適宜、FWなどで遮断します。

最後に、「レジストリロック」の提供を検討してください。これはレジストリの登録情報の変更を制限する機能で、登録情報を変更する際に登録者に追加の認証が必要となるため、意図しない情報の変更を防ぐことができます。

なお、海外のレジストラではFAXによってメールアドレスやパスワードをリセットするサービスが悪用された例もあります。同様のサービスを提供している場合は、サービスの必要性や本人確認フローを見直した方がよいでしょう。

登録者

先に説明したような対策を実施しているレジストリ／レジストラを選ぶことが重要です。レジストラが提供している認証強化や通知機能、レジストリロックなどを積極的に利用してください。また、OSのパッチを適用し、最新版のソフトウェアを利用します。併せて、アンチウイルスもインストールしてください。また、レジストラのアカウントのパスワードは、使い回しをしてはいけません。

通知機能を使用する場合は、通知メールがスパム判定されないように設定します。このとき、連絡用のメールアドレスは、自身が登録しているドメイン以外のものにしてください。仮にレジストリ登録情報が改ざんされても、レジストラなどと連絡を取ることができます。また、WHOISの公開情報に登録者の情報を表示しないオプションがある場合は、有効にすることを検討してください。

更に、定期的に「WHOISサーバ」と「レジストリの権威DNSサーバ」に登録されている情報が改ざんされていないか確認することで、いち早くレジストリ登録情報の改ざんに気付ける可能性があります。WHOISサーバでは「ネームサーバ」、レジストリの権威DNSサーバでは「ドメインのNSレコード及びグルーレコード」を確認してください。

ただし、これらの情報を監視する標準的なツールは存在しないため、各自で作成する必要があります。有志により、いくつかの監視ツールが公開されていることを確認していますが、特定のレコードのみが監視対象となっていたり、レジストリの権威DNSサーバへ直接問い合わせを行わなかったりするなど、使用する場合は事前に十分な動作確認が必要です。

また、監視を行う場合、レジストリの権威DNSサーバとWHOISサーバに必要以上の問い合わせを行わないようにしてください。過剰に問い合わせを行った場合、レジストリに対する攻撃であると判断され、問い合わせが制限または遮断される可能性があります。

一般ユーザ

一般ユーザがレジストリ登録情報が改ざんされているか否かを見分けることはほとんど不可能です。したがって、攻撃者が用意したサーバにアクセスしてしまっても、脆弱性が利用されないようにOSのパッチ適用や最新版のソフトウェアと併せて、アンチウイルスソフトウェアを使用してください。

なお、レジストリ登録情報の改ざんではサーバのSSL/TLSの秘密鍵を盗むことはできないため、攻撃者はSSL/TLSで暗号化を行うサービスを提供できません。したがって、普段はHTTPSで提供されているサービスにHTTPでアクセスしていたり、SSL/TLSのエラーが発生している場合は、レジストリ登録情報が改ざんされている可能性が考えられますので、サービスの利用を中止したほうがよいでしょう。

まとめ

現時点で最も効果的な対策はレジストリロックですが、この機能を提供していないレジストリもいます。また、万が一、レジストリロックが突破されてしまう事態に備えて、レジストリロックの有無に関わらず、これまで説明した対策を実施することで、レジストリ登録情報の改ざんの防止や早期発見することができます。

ユーザ数が多いサービスを提供するドメインほど、被害が大きくなるため、この機会に対策を実施してください。

実装の背景

これまでIIJでは、OpenIOCとRedlineを活用したマルウェアの早期検出について、検討を行ってきました（※50）。しかしながら、Redlineはクローズドソースのツールであり、機能拡張やバグの修正を自分達で行うことができないという問題がありました。そこで、オープンソースのツールであるVolatility Framework（※51）のプラグインとして、openioc_scan（※52）を実装しました。

openioc_scan

openioc_scanの使用方法について説明します。openioc_scanの解析対象はVista以降のWindows OS（※53）のみで、LinuxやMac OS Xは現在サポートされていません。また、実行にはlxml（※54）、ioc_writer（※55）、colorama（※56）の3つのPythonパッケージが必要です。更に、IOCを事前に定義しておく必要があります。openioc_scanは正規表現や後述するparameterをサポートするため、OpenIOC 1.1のフォーマットを利用します。OpenIOC 1.1の定義が可能なフリーツールは、現状PyIOCe（※57）のみです。よってIOCの定義にはこのツールを利用します。

openioc_scanがサポートしているtermの一覧を表-1に示します。ProcessItemとDriverItemについては、スキャン対象となるプロセスやドライバは、個別にIOCの定義内容に対して真か偽かを評価されます。例えば、先の例のIOCは1つのプロセス内に閉じて評価されることになります。また、カテゴリの異なるtermを組み合わせた定義を行うことも可能ですが、組み合わせによってはパフォーマンスが著しく低下する場合があるので（※60）、定義内容はできるだけ1つのカテゴリのtermのみをシンプルに定義していくほうが良いでしょう。

汎用的なIOCに関する検討

表-2に検討結果をまとめます。汎用的な定義である以上、誤検出を完全に避けることはできないため、誰しもが今回検討したIOCを使って未知の脅威を検出できるわけではありませんが、更なる詳細な解析を行っていくための優先順位づけ（トリアージ）という観点では、ある程度活用できるという感触を得ました。一方、Volatility Framework自体の機能の制約によって、検出漏れが発生しているケースも見受けられました。

拡大する

表-2 汎用的なIOCに関する検討結果

まとめ

本節ではopenioc_scanの紹介と、それを使った汎用的なIOCに関する検討結果について述べました。検討によって、Volatility Frameworkの機能に由来する制約が判明しましたが、Redlineとは異なりオープンソースなので、各ユーザで自由にそれを修正及び拡張することは可能です。

メモリイメージに対してIOCをスキャンするという考え方以前に、IOC自体を活用しているアナリストはまだまだ少ないように思います。今後インシデントレスポンスで解析対象とする端末の数、メモリやディスクの容量は、増加の一途をたどることは容易に推測できますし、経験豊富なアナリストは既に既存の手法の限界を感じているかもしれません。効率的にインシデントレスポンスを行っていくために、openioc_scanを使って脅威の検出やトリアージを試みてはいかがでしょうか。

IDの考え方～実体と識別子

アイデンティティについて非常に多くの考え方・定義・思想があり、これが技術者・利用者を混乱させる原因になっています。そこで本稿ではIDを識別子（Identifier）として捉えるシンプルな考え方を導入します。

現実世界の実体はデジタル世界のエンティティと結び付けられます。現実世界の実体の例としては、何らかのサービスを利用しようとするユーザが挙げられますが、IoT（Internet of Things）に代表されるように能動的に他のノードと繋がろうとする機器もIDを持つことがあります。このとき、デジタル世界のエンティティを識別（identify）するために、ユニークな識別子（Identifier＝ID）が割り当てられます。IDはあるレルム（Realm；領域）ごとに定められる識別子空間（Identifier Space）上の元と捉えることができます。IDのユニーク性は、当該レルムにおいて異なるエンティティであれば、異なるIDが割り振られることを意味します。

現実世界の実体は複数のレルムにおいて、それぞれ異なるIDを持つことが一般的です。また、現実世界の実体が同じレルムにおける複数のIDと結び付けられることもしばしばあります。しかしデジタル世界においては、IDが異なれば、それらは異なるエンティティと認識されます。例えば、現実世界の実体であるAさんは、メールアドレスとしてa@aaa.exampleとa@bbb.exampleのように2つの異なるレルムaaa.example、bbb.exampleにおいてそれぞれのIDを持つことがあります。また、Aさんはレルムaaa.exampleにおいて、a@aaa.exampleだけでなくa1@aaa.exampleのように同じドメインに異なるメールアドレスを持つケースがあります。このように現実世界においては同じ実体に、デジタル世界においては異なるレルムに複数のIDが割り振られることもあることが分かります。

トークン・クレデンシャルと認証（Authentication）

前述したようにデジタル世界においてIDを用いることで異なるエンティティを識別できることが分かります。しかしIDは公開情報であるため、誰でも自分がそのIDを持つエンティティだと言い張っては困ります。そこで、デジタル世界において今アクセスしているエンティティが本当にそのIDが割り振られたエンティティであるかどうかを認証（Authentication）する仕組みが必要となります。そのために当該IDに呼応したパスワードなどの秘密情報が必要となります。

本節ではNIST SP800-63（※73）の定義に沿ってクレデンシャル（※74）とトークンを区別して説明することにします。トークンは"Something you know"、"Something you have"、"Something you are"の3つで代表されるように当該IDが割り当てられたユーザが持つ秘密にすべき情報を指します。トークンとしては例えば、パスワードや公開鍵暗号方式で利用される秘密鍵、ICカードやドングルなどの物理的媒体、指紋や虹彩などバイオメトリクス認証で用いられる身体情報などがあります。一方でクレデンシャルはトークンとIDとの結び付けを指し示す公開情報です。場合により、クレデンシャルは信頼のおけるエンティティからお墨付きを得ており、第三者がその正当性について検証可能な情報となります。トークンの一種であるパスワードに対応するクレデンシャルは、認証子であるIDそのものと捉えることができます。SSL/TLSなどで利用される公開鍵暗号系の認証方式を考えると、X.509証明書（※75）がクレデンシャルであり、証明書に含まれる公開鍵に呼応する秘密鍵がトークンに該当します。また、SSL/TLSサーバ証明書にはFQDNが含まれており、これをIDと捉えることができます。BitcoinアドレスはIDと捉えることができますが、アドレスそのものが公開鍵であり、アドレスだけでトランザクションの署名検証が可能なことから、Bitcoinアドレスはクレデンシャルとも捉えることができます。

1つの｛トークン・クレデンシャル｝の組を用いた認証ではなく、複数の｛トークン・クレデンシャル｝を用いて、あるIDが割り振られたエンティティを認証する方式を多要素認証と呼びます。一般的には並列の多要素認証方式、つまりそれぞれの認証方式において独立したトークンを用いる方法が知られています。一方で直列の多要素認証方式という考え方もあります。例えば、公開鍵暗号方式における秘密鍵をトークンとして使用する場合、秘密鍵ファイルは暗号化しておくことが一般的ですから、復号するためにパスワードの入力が必要になります。このとき、トークンとしてパスワードと秘密鍵の2つを利用する直列の多要素認証方式と捉えることができます。ICカードとPINコードも同様です。また、トークンのうち"Something you have"に属するハードウェアトークンでは、物理的媒体に表記された定期的に表示が更新されるワンタイムパスワードをトークンとして提示し、多要素認証の1つとして利用されることが一般的です。ネットワーク型としてはLamportによるハッシュチェーンを用いたワンタイムパスワード方式（※76）が知られておりS/Keyなどとして仕様（※77）（※78）が策定されています。ワンタイムパスワード方式は、従来のID・パスワード方式の置き換えや併用により、近年のリスト型攻撃への対策案（※79）の1つとして期待されています。

認証と認可（Authorization）の違い

デジタル世界においてユーザがログインする、もしくはサーバがあるIDを持つエンティティを認証することは最終的な目的ではありません。サーバはユーザを識別した後に、しかるべきサービスを提供したり、各種リソースにアクセスできるようにするために認証が行われます。エンティティの確からしさを確認した上で、当該IDを持つエンティティに対して権限を与えることを認可（Authorization）と呼び、認証（Authentication）とは分離して考えます。認可とは、あるIDに対して適切なアクセス権を付与することにほかなりません。その際にはポリシー（Policy）があることが前提となり、ポリシーに基づきあるIDに対して権限を付与するエンティティPDP（Policy Decision Point）とその決定された結果を実際に適用するエンティティPEP（Policy Enforcement Point）の2つに役割を分ける考え方があります（※80）。あるIDに権限を付与するアクセス制御方法にはRBAC（Role-Based Access Control）（※81）やABAC（Attribute-Based Access Control）（※82）などがあります。これらの方式には、IDに対して直接権限を付与するのではなく、IDに紐付けられた属性情報から判断して権限を付与するという考え方が導入されています。これら2方式の大きな違いは、RBACがロールと呼ばれる属性値が固定化されている属性情報を扱うのに対し、ABACではアトリビュートと呼ばれる属性値が定められた範囲の元を取り、その値がどの範囲に属しているかによって権限を変更するという設定方法が採用されています。例えば、役職や性別による判断はRBAC、年齢や期間・時刻による判断はABACの考え方に基づいてアクセス権限が与えられます。認可のために使われる属性情報は、ID付与や認証を行うエンティティが管理する場合もありますが、属性情報を管理するエンティティ（Attribute Authority）がクレデンシャルを発行してIDと属性情報を紐付ける方法もあります。クレデンシャルにして属性情報を流通させるメリットは、アクセス権限を得るためにユーザが開示すべき属性情報のうち、本来ならば不必要な情報までサービス提供者に流れることを防ぎ、最低限の属性情報のみを提示してサービス提供を受けることができるようになる点です（※83）。図-19は、トークンを用いた認証から各種クレデンシャルの流通、アクセス権限付与までの一連の流れを示した概念図を表しています。

ID連携技術

一度の認証で複数のレルムにおけるサービスが利用できるシングルサインオンを実現するためにID連携と呼ばれるフレームワークがいくつか存在しています。今回はSAML（Security Assertion Markup Language）（※84）における考え方を中心に説明します。SAMLにおける役割は（1）ID付与や認証に関する業務を行うIdP（Identity Provider）、（2）IdPが発行するクレデンシャルを信用して受け入れるRP（Relying Party）/SP（Service Provider）、（3）利用者であるEnd Userの3つに分けることができます。End UserはSPのサービスを利用する際にクレデンシャルを提示することでサービスを享受します。このときクレデンシャルを発行するのがIdPであり、SPで定められたポリシーに基づいてアサーション（Assertion）と呼ばれるクレデンシャルが要求されIdPにより発行されます。SAMLではアサーションのデータ形式だけでなくブラウザがEnd Userとして振る舞う場合の動作についてプロトコルが定められています。クレデンシャル（アサーション）の種類としては認証結果に関する情報だけでなく、属性情報を保証する情報や、更に認可決定に関する情報についても流通させることができます。このとき図-19のように、認証に関わるクレデンシャルを発行する機関を狭義のIdPとし、属性情報に関するクレデンシャルを発行するAttribute Authority、認可決定に関するクレデンシャルを発行するPDPと役割を細分化して考えることができます。また、SPがPEPの役割にあたりますが、実装によってはPDPでのアサーション発行を省略しPDPとPEPの両方の役割をSPが担当することも考えられます。

OpenID（※85）もSAMLと似たような考え方に基づくフレームワークであり、前述した狭義IdPやAttribute Authorityの役割としてOpenID Provider（OP）と呼ばれるエンティティが発行したクレデンシャル（Claimと呼ばれます）をRPが検証する仕組みで属性情報の流通を可能にしています。事前にOPとRPが連携しない状況でも運用可能であり、RP・OPがそれぞれ適したOP・RPを発見するディスカバリサービスに関する拡張仕様も用意されています。更に、権限委譲に関する仕様も策定されており、OAuth（※86）はリソースにアクセスするためのトークンを保持している利用者が、秘密情報であるトークンを開示することなく代理人に権限のみを一時的に付与する仕組みを提供しています。技術用語が違うため混乱しますがResource Ownerと呼ばれる利用者がClientと呼ばれる代理人に、秘密情報を渡すことなくAccess tokenと呼ばれる認可情報を含むクレデンシャルをAuthorization Serverと呼ばれるPDPが発行することで代理人がリソースにアクセスすることを可能にしています。

このように、今後も新しいモデルに基づいた様々な仕様が策定されると考えられますが、今回紹介したID・トークン・クレデンシャルと認証・認可・アクセス制御という一般的な考え方を知っておくことで新仕様の理解の一助となれば幸いです。