セキュリティウィーク33：鍵のかからないドア、難攻不落のMicrosoft、リバースエンジニアリングと苦悩

今回紹介する3つのニュースには、特に関連性がないように思えますが、保護対策を怠ると脆弱性が生まれる、という点が共通しています。ホテルのドアのハッキング、Microsoft製品の複雑な事情、Oracle幹部の不穏当なブログ記事を紹介します。

security-week-33-featured

さてさて、「セキュリティウィーク」最新版をお届けします。前回は、勝手にロックが解除されてしまう車、慢性化するAndroid Stagefrightの欠陥、終わりそうで終わらないWebトラッキングなどの話題を取り上げました。

今回紹介するうち初めの2つのニュースは一見関連がなさそうですが、共通点が1つあります。それは、保護対策を怠るところに脆弱性あり、というところです。3つ目のニュースは、セキュリティとはまったく関係ないのですが、業界内の特殊な利害関係について触れています。3つとも記事の見た目とは裏腹に、十分楽しめる内容です。

ここで改めて「セキュリティウィーク」シリーズがどんな連載なのか、おさらいしましょう。Threatpostの編集者が重要なニュースを3つほどピックアップし、そこに私が解説や辛口コメントを追加していく、という趣向です。本シリーズの記事は、こちらをご覧ください。

ホテルのドアをハッキング

Threatpostの記事。

科学と芸術は相反する関係にあり、これら分野の専門家は互いに相手を理解できない、と言われています。人文系の知識人は科学者や技術者になれない、と根強く信じられています。

security-week-33-wiegand

このステレオタイプを覆したのは、専門教育を受けた音楽家であるジョン・ウィーガント（John Wiegand）氏です。同氏は1930年代、ピアニストであり子供コーラス隊の指揮者でもありましたが、やがて音声増幅器の設計に関心を持つようになりました。1940年代には当時新しかった磁気テープによる録音に取り組み、そして1974年（当時62歳）、大きな発見をしました。ウィーガントワイヤです。

いわゆるウィーガントワイヤは、磁気性のコバルト鉄とバナジウム合金でできたワイヤであり、外側の硬いシェル部分が内側の軟らかいコア部分を囲んでいます。外側のシェルは外部磁界によって簡単に磁化され、外部磁界が取り払われても減磁しにくい特性（高保磁力）があります。一方、柔らかいコア部分は異なる特性を持ち、シェルが十分な磁性を帯びるまで磁化されません。

シェルが完全に磁化され、コアが磁気を吸収するようになると、シェルとコアの極性が反転します。その際に発生する膨大な電圧を利用して動きを感知することができ、ホテルのカードキーなどに応用されています。

最近のカードとは異なり、1と0はチップ内に記録されるのではなく、特殊な埋め込みワイヤのダイレクトシーケンスに記録されます。キーのプログラムを書き換えることは不可能なので、動作原理は今どきの交通機関で利用される近接型カードやクレジットカードよりも、磁気テープカード（信頼性の高い磁気カードに限ります）に近いと言えます。

では、近接型カードをお役御免にした方がよいのでしょうか。いいえ、時期尚早です。ウィーガント氏の名前はウィーガントワイヤ効果のほか、（かなり古い）データ交換プロトコルにも付けられています。このプロトコルは欠点だらけです。1つ目は、厳密に標準化されず、さまざまな形態で実装されていること。

2つ目は、当初のカードIDは16ビット対応で、生成できる組み合わせが非常に少ないこと。そして3つ目は、クレジットカードにコンピューターを搭載する方法が発明される前の近接型カードは、ワイヤが埋め込まれていたため、キー長がちょうど37ビットに制限され、長いキーより信頼性が格段に低いことでした。

先日のBlack Hatカンファレンスで、リサーチャーのエリック・イベンチック（Eric Evenchick）氏とマーク・バセッジオ（Mark Baseggio）氏はカードの認証の際に（暗号化されていない）キーシーケンスを傍受するデバイスを紹介しました。特に興味深かったのは、カードとまったく関係なくキーシーケンスを盗み出せる点です。なぜかと言うと、ウィーガントプロトコルが使われ続けているドアの制御部へカードリーダーからデータが送信される間に情報を窃取するからです。

そのデバイスはBLEkeyといいます。小さなハードウェアで、ホテルのドアなどに付いているカードリーダーにこれを埋め込みます。講演では、数秒で作戦が完了する様子が披露されました。何もかも単純です。キーを読み取り、宿泊者が部屋を出たあとにドアを開けるだけです。もちろん、宿泊者が部屋を出るまで待たなくても、ドアを開けなくてもかまいません。技術的な説明を省くと、ドアとリーダー/ワイヤレスのやり取りはこんな感じになります。

「どちらさまですか？」

「私です」

「どうぞ、お入りください！」

とてもわかりやすい事例ですが、実は含みを持たせています。そう、いつものことですが、すべてのアクセス制御システムがこの攻撃に脆弱というわけではないのです。しかも、脆弱性のあるシステムであったとしても、全取っ替えしなくても保護することができます。というのも、両氏によれば、カードリーダーにはこうした攻撃に対する保護機能が備わっていて、普段は、どうも、無効になっているとのことです。

一部のリーダーは、送信されるキーシーケンスを暗号化できるプロトコル、Open Supervised Device Protocolに対応しています。こうした「機能」が使われないのは、繰り返しますが、対策をしない方が安くて簡単だからです。

このテーマについて2009年にも興味深い調査が行われており、技術的な詳細がまとめられています。どうやら（リーダーではなく）カードの脆弱性はすでに1992年に指摘されており、カードの分解やX線検査が提案されています。そのためには、たとえば所有者からカードを奪う必要がありますが、今やデバイスは小銭サイズになり、この問題は解消されています。これぞ進化というものです！

Microsoftの免責。企業側のWindows Server Update Servicesは複雑

Threatpostの記事。元となったリサーチャーのホワイトペーパー

Windows Server Update Servicesは、外部ソースの代わりに内部サーバーから一括してコンピューターをアップデートする大企業向けのサービスです。信頼性も安全性も非常に高いシステムです。第1に、アップデートプログラムはすべてMicrosoftによる署名が必要です。第2に、企業のアップデートサーバーとMicrosoftのサーバーとの通信はSSLで暗号化されています。

また、非常にシンプルなシステムでもあります。企業側のサーバーはアップデートのリストをXMLファイルで受け取ります。そのリストにはアップデートの内容やダウンロード場所、ダウンロード方法などが記載されています。その最初の通信が、平文で行われていたことが判明しました。こう書くと、語弊があるかもしれません。暗号化は必須です。WSUSの導入時、管理者は暗号化を有効にするよう推奨されます。しかし、暗号化は既定で無効になっていたのです。

「指示」を書き替えるのは難しいため、それほど大変な事態ではありません。とはいえ、攻撃者がトラフィックを傍受可能なら（中間者攻撃がすでに行われている場合など）、書き替えは可能です。リサーチャーのポール・ストーン（Paul Stone）氏とアレックス・チャップマン（Alex Chapman）氏は、指示を書き替え、高いレベルの権限を使って任意のコードをアップデート先のシステムで実行できることを発見しました。Microsoft側はデジタル署名のチェックはしますが、どの企業の証明書でも受け取ります。たとえば、SysInternalsのPsExecツールをこっそり挿入できれば、あとは何でも起動できてしまいます。

なぜこのようなことが起こるのでしょうか。WSUSの展開時に証明書を生成する必要があり、SSLが自動で有効化されないからです。今回のケースでは、Microsoftは導入企業にSSLの有効化を促す以外、何もできないとリサーチャーは述べています。まるで脆弱性がありながら脆弱性がないようなものです。しかも、対応策がありません。管理者だけが責められてしまいます。

別の方法ですが、Kaspersky LabはWindows Updateを利用して感染するスパイウェアFlameを発見しました。偽のプロキシを使ってMicrosoftサーバーへのリクエストが傍受されており、配信される応答ファイルはそれぞれ微妙に異なっていたものの、確かにMicrosoftの署名がありました。

リバースエンジニアリングと苦悩

Threatpostの記事。Oracle CSOによる元記事（Googleのキャッシュと別のコピー – インターネット上の情報は永久に残ります）

先に紹介したBlack Hatの2つの講演と共通する部分があります。講演者であるセキュリティエキスパートが、他人の開発した技術や製品の欠陥を発見したという点です。エキスパートは調査結果を発表し、BLEKeyの例では全コードとハードウェアを誰でもアクセスできるよう公開しています。これは、ITセキュリティ業界が業界外の人とやり取りする際の普通のやり方ですが、誰もがこうした状況を好ましく思っているわけではありません。

批評めいたことは言いたくないので、これは非常にデリケートな問題とだけ述べておきます。他人のコードを解析するのは問題ないのか？何をもって問題ないと言えるのか？被害が出ないよう脆弱性情報を公開するにはどうすればよいのか？脆弱性を発見したら報酬があるのか？法規制、刑法、文書化されていない業界ルールなど、すべてが今回の問題に関係します。

Oracleの最高セキュリティ責任者、アン・デビッドソン（Ann Davidson）氏は最近のブログで暴論を展開しました。『やってはいけない』（No, You Really Can’t）と題したブログ記事は、同社製品で見つかった脆弱性情報を送ってきた（業界ではなく）顧客に向けられていました。

2015年8月10日に投稿されたOracleのブログは、引用すべき箇所がたくさんありますが、重要なのは1つだけ。リバースエンジニアリングでしか得られない脆弱性を見つけた顧客はライセンス契約に違反しているし、不正行為だと述べている点です。

security-week-33-sobchak

以下に、引用します。

製品の利用者は、スキャンツールで検出される攻撃（多くの場合は誤検知です）が防御されるかどうかを調べるために、コードを解析することはできません。利用者は脆弱性に対するパッチを作成することはできません。作成できるのはオラクルに限られます。利用者が（ソースコードに悪影響を及ぼす）静的解析ツールを使った場合、ほぼライセンス契約違反とみなされます。

一般の反応は、次のとおりです。

こんなツイートもありました。

さらにこのような反応まで。

簡単にまとめると、この記事は「顧客との関係に関する（公式）見解と矛盾する」として、1日も経たないうちに取り下げられました（Web上には残っていますが）。思い起こせば、Javaを開発したのはOracleです。そのJavaの脆弱性をエクスプロイトしないのは、よほどの怠け者でしょう。3年前のKaspersky Labの調査では、12か月間で発見されたJavaの脆弱性は160件に上りました！

ソフトウェアベンダーがソフトウェアの脆弱性をすべて検出して修正するのが理想的ですが、現実はそうもいきません。現実世界にこの原則は存在せず、責任者たるべき人々は単に流されているだけなのでは？

しかしながら、別の意見にも耳を傾けてみましょう。

先日、Black Hatの創立者ジェフ・モス（Jeff Moss）氏は、コード内の欠陥の責任はソフトウェアベンダーにあると述べました。同氏は、ソフトウェア利用許諾契約の「当社は顧客に対して一切の責任を負わない」という記載を削除する時期にあると提唱しました。興味深い発言ですが、「逆アセンブラ禁止」などと同じくらい「上から目線」です。今のところはっきりしているのは、利用者（法人と個人）、ベンダー、リサーチャーが互いに理解し合っていれば、大胆な発言やTwitterでの冷やかしなどは出てこないということです。

その他のニュース

また、Black HatではSquareリーダーのハッキングに関する講演がありました。Squareリーダーは、スマートフォンに接続するタイプの決済用デバイスです。ハッキングするには、はんだごてが必要です。

もう1つ、Lenovoのラップトップ（すべてではなく、一部）に、また別のベンダーのルートキットが発見されました。以前の記事は、こちらです。

infosec-digest-32-book

懐かしのあれこれ

「Small」マルウェアファミリー

標準的な常駐型ウイルスであり、メモリに.comファイルがロードされるとファイルの末尾（ただし、Small-114、Small-118、Small-122はファイルの先頭）に追加されます。このウイルスファミリーのほとんどは、80×86プロセッサのコマンドPOPAやPUSHAを使用します。Small-132とSmall-149は、一部のファイルでは正しく感染しません。ウイルスはそれぞれ作成者が異なっています。Smallファミリーの起源は、メモリ内に常駐期間が最も短いMS-DOSのウイルスの対抗馬とみられています。標的の金銭的な価値を判断するためだけに常駐しています。

1992年、ユージン・カスペルスキー著『Computer viruses in MS-DOS』（MS-DOSのコンピューターウイルス）45ページより引用

注意：この記事は著者の個人的見解を反映したものです。これはKaspersky Labの見解と一致していることも、一致していないこともあります。運次第です。

ヒント

ホームセキュリティのセキュリティ

最近では様々な企業が、主にカメラなどのスマートなテクノロジーを活用したホームセキュリティサービスを提供しています。しかし、セキュリティシステムは侵入者からの攻撃に対してどの程度セキュアなのでしょうか？

新着記事をメールでお知らせします