脆弱性

WPA2のWiFi脆弱性から身を守る方法――KRACK攻撃の内容と対策

今日(米国時間10/16 )、セキュリティー専門家のMathy VanhoefはWPA2暗号化プロトコルにおける深刻な脆弱性を公表した。現在利用されているほとんどのルーターその他のデバイスはWiFi接続を保護するためにWPA2暗号化を用いている。つまりきわめて多くのユーザーがこの問題の影響を受ける。

このKRACK〔Key Reinstallation AttaCKs=キー再インストール攻撃〕脆弱性を利用してハッカーができること、できないことをはっきりさせておこう。攻撃者はユーザーのコンピューターとルーターの間のWiFi通信の一部に割り込むことが可能だ。ただしそのトラフィックがHTTPSを用いて適切に暗号化されている場合、攻撃者は内容を知ることはできない。また攻撃者はKRACK脆弱性を用いてWi-Fiパスワードを盗むことはできない。しかし〔再インストールしたWPA2キーを用いて〕トラフィックを復号化して読むことができる。

一部のデバイスの場合、攻撃者はパケット・インジェクション攻撃が可能で、この場合は深刻な結果をもたらす。空港はカフェのWiFiなどのルーターもこの脆弱性を持つ可能性が高い。

次に攻撃者はWiFiネットワークに接続できる場所にいる必要がある。何キロも遠く離れた場所からこの脆弱性を利用した攻撃をしかけることはできない。しかし攻撃者はユーザーの近くですでにゾンビー・コンピューターとなっているデバイスを利用する可能もある。しかしコンピューターをゾンビー化するのはKRACK攻撃にくらべてさらに高度なテクニックが必要だろう。ほとんどの攻撃者は今日初めてこの脆弱性について知ったはずだから、ルーターなどデバイスのメーカーは一刻も早く修正パッチを発表すべきだ。

理論的にいえば、攻撃者は将来この脆弱性をさらに拡大する可能性がある。たとえばこの脆弱性を利用してデバイスを乗っ取るワームを開発し、無防備なIoTデバイスなどに次々に拡散させ、ゾンビー・ボットネットを構築するなどだ。しかしこれはあくまで可能性であり、現在はそういうことはできない。

そこでWPA2プロトコルの脆弱性に対する現在の対策はこうだ。

ワイヤレス関連のデバイスをすべてアップデートする

グッドニュースはKRACK攻撃を防げるアップデートが比較的容易に開発できるということだ。パッチは後方互換性があるので、同じネットワークにアップデート版のデバイスとアップデートされていないデバイスが併存しても差し支えない。

なんにせよWi-Fi機能を持つすべてのデバイス(ノートパソコン、スマートフォン、タブレット等)をアップデートしてセキュリティー・パッチをインストールする。この種の脆弱性の発見はこれが最後ではないはずだから、まだそのように設定していないなら自動アップデートを選択することを考えるべきだ。最新のOSは自動アップデートを非常に手際よく実行できる。一部のデバイス(というのは一部メーカーのAndroidだが)は頻繁にアップデートが行われず、これらは引き続きリスクとなる。

KRACK攻撃にはさまざまな手法が想定されるので、WiFiルーターそのものとクライアント・デバイス双方のセキュリティー・アップデートが必要だという点が重要な点はだ。

ルーターに注目

すべてのルーターのファームウェアはアップデートが必要だ。使用しているルーターがキャリヤが設置したキット製品であれば、キャリヤにいつパッチが出るのか問い合わせるべきだた。分からないというなら繰り返し問い合わせる。ルーターの管理ダッシュボードを開き最新の状態であるかチェックする。キャリヤ・ブランドのルーターであればユーザーガイドを探し、管理者ページへのアクセス方法を調べる。

キャリヤがいつまでもKRACK対策のファームウェアのアップデートを出さないようならキャリヤを乗り換えることを検討すべきだろう。それほどドラスティックな手段を取りたくない場合は、信頼できるメーカーからすでにKRACK対策ずみのWiFiルーターを購入する。購入したWiFiルーターをキャリヤのルーターに接続し、キャリヤのWiFiを無効にしておく。

一部のルーター・メーカー(Ubiquiti、Microtik、Meraki、Aruba、FortiNet等)はすでにパッチを公開している。ここからリストを確認できる

有線接続に切り替える

KRACK脆弱性にキャリヤが対応せず、対応済みWiFiルーターも入手できない状況の場合、ユーザーはデバイスをルーターにEthernetケーブルで接続し、WiFi機能を無効にする(そうできる場合)という方法が考えられる。デバイス側のWiFi機能も無効にしておく必要がある。トラフィックがEthernetケーブル内を流れていれば安心だ。

仮にすべてのデバイスについて上記のような対策を取れない場合でも主要なデバイスは有線接続に切り替えるべきだ。読者が毎日パソコンを長時間使い、インターネットと大量のデータをやり取りしているならこのコンピューターだけでも有線接続にする。Ethernetケーブルを持っていないなら買ってくること。

モバイルデバイスのWiFi機能を無効にする

スマートフォンやタブレットには通常Ethernetポートがない。データを盗み見されたくない場合、 デバイスのWiFi機能を無効にし、セルラー網だけを利用して接続するという方法がある。これはセルラー網のスピードが遅かったり、データ通信プランが高額だったりする場合、理想的な方法とはいえない。またモバイル・キャリヤの信頼性が低い場合もある。

Android 6.0以降を利用するデバイスは特に脆弱性が深刻だ。AndroidデバイスではWiFi利用時のハンドシェイク・メカニズムに欠陥があるためキー再インストール攻撃はきわめて容易だ。つまりAndroidユーザーはいっそうの注意が必要だ。

IoT(Internet-of-Things)デバイスへの影響は?

IoTデバイスを数多く所有している場合、トラフィックの内容が盗まれた場合のダメージが大きいデバイスはどれかを考えてみる必要がある。たとえば室内監視用にセキュリティー・カメラを設置しているが、このカメラのビデオデータが暗号化されていなかったとしよう。WiFiネットワークに攻撃者がアクセスできるなら室内の様子を撮影したビデオが丸見えになってしまう。えらいことだ。

想定されるダメージによって対応を考えるのがいいだろう。つまりハッキングによるダメージの大きいデバイスから順にWiFiネットワークから外す。メーカーがセキュリティーパッチを発行するのを待って接続を戻す。また家庭のネットワークにどんな機器が接続されているのかチェックしておくことをお勧めする。

もちろんスマート照明の電球とルーターの間のトラフィックが攻撃者の手にわたってもさして実害はない。そんな情報は通常の場合役に立たない。エドワード・スノーデンなら自分の照明の点灯状況が外部に漏れることを嫌うだろう。しかしほとんどユーザーはそこまで高度なセキュリティーを必要としていない。リスクはユーザーが個々に判断すべきだ。

ただしIoTデバイスはことセキュリティーに関してこれまでもホラー・ストーリーを何度も提供してきた。これを機会にIoTを始めとするデバイスのセキュリティーを見直し、パッチを出すのが遅いメーカーのデバイスは捨てることを考えるべきだ。パッチ対応が遅いメーカーのデバイスは今後もセキュリティー上の懸念となる可能性が高い。

HTTPS Everywhere拡張機能を利用する

上述のようにインターネットとやり取りするデータそのものを暗号化すればセキュリティーは大きく高まる。EFF(電子フロンティア財団)はHTTPS Everywhereというブラウザー拡張機能(extension)を提供している。ユーザーがGoogle Chrome、Firefox、 Operaを利用しているのであればこの拡張機能をインストールすることを考えてもよい。ユーザー側での設定変更等は不要で、他の拡張機能同様、単にインストールボタンを押すだけでよい。

この拡張機能はサイトがHTTPSとHTTPの双方のプロトコルを利用している場合、自動的にHTTPSでブラウザーを接続させる。しかしHTTPSを使っておらずHTTP接続しか利用できないサイトの場合はHTTPS Everywhereは役に立たない。またサイトのHTTPSの実装に欠陥がある場合も補完してはくれない。そうではあってもHTTPS Everywhereはないよりは増しだ。

VPNは解決法ではない

理論上はVPNサーバーを利用するのは有効に思える。しかしわれわれはこの点についてはすでに調査ずみだ。VPNサービスについては最大限の注意を払う必要がある。無条件に信頼できるサービスではない。

VPNサービスを利用した場合、ユーザーのすべてのインターネット・トラフィックはどこかのデータセンターにあるVPNサーバーに向かう。 この場合KRACK攻撃者はトラフィックの内容を見ることはできない。しかしVPNサービスはトラフィックをログに取っている可能性があり、このログにアクセスできるものはこれをユーザーの不利益になるように利用できる。

たとえば、先週のThe Registerが報じたFBI捜査官の宣誓証言の文書によれば、PureVPNは容疑者を逮捕するために重要な情報を当局に引き渡したという。しかしPureVPNのウェブサイトには「われわれは一切ログを記録しない」と書かれていた。VPN企業を信頼するのは考えものだ。自分で独自のVPNサーバーを開発するのであれば別だが、VPNサービスは解決法ではない。

最大限のWiFiセキュリティーが欲しければ僻地に引っ越す

ユーザーが種々の事情でWiFi接続を止めるわけにいかないが、トラフィックの内容を絶対に人に知られたくないというパラノイドの場合、人跡稀な山の奥深くの小屋に引っ越すのがいい。実際、マーク・ザッカーバーグはセキュリティーを強化するために近所の家を買って取り壊したが、こういう戦略は非常に金がかかるのが難点だ。

画像: wackystuff/Flickr UNDER A CC BY-SA 2.0 LICENSE

[原文へ]

(翻訳:滑川海彦@Facebook Google+

DNAに書き込まれた悪意あるコードがそれを読み込んだコンピューターに感染した

驚くべきことに、生物学者とセキュリティ研究者のチームが、DNA鎖上にコード化された悪意のあるプログラムを、コンピューターに感染させることに成功した。

まるでサイエンスフィクションのように聞こえるかもしれないが、これは本当の話だ。とはいえこの特定の脅威にすぐに怯えなければならないというわけではない。ともあれ、このプロジェクトが示唆する可能性は、魅力的でありまた同時に恐ろしいものでもある。

ワシントン大学の学際チームは、目立つニュースを目指していたわけではないが、結果としてそれを成し遂げた。彼らは世界中の研究室で使用されているオープンソースソフトウェアの基本的な脆弱性を発見し、DNA転写と解析に関するセキュリティ基盤が不適切であることを懸念していた。通常扱われているデータの性質を考えると、これは今後深刻な問題になる可能性がある。

確かに、彼らは通常のマルウェアやリモートアクセスツールを使ってシステムの弱点を提示することができた。それは有能な攻撃者たちがシステムへ対してとる方法だ。しかし、違いの分かるセキュリティ専門家は、そうしたゲームに対して常に先手を打っておくことを好む。

「コンピュータセキュリティコミュニティで我々がしようとしている大きなことの1つは、『どうしよう、敵が私たちのドアをノックしているのに準備ができていない』という状況を避けることです」と河野忠義(Tadayoshi Kohno)教授は語る。彼はこれまで、ペースメーカーのような埋め込み型でニッチな電気製品のための、不測の攻撃ベクターに関する追求を行ってきた人物だ。

左から:ワシントン大学の分子情報システム研究所の、Lee Organick、Karl Koscher、そしてPeter Ney。セキュリティとプライバシー研究室では、DNAシーケンシングへの脅威に対する研究をしている

「このように分子と電子の世界が近づくにつれて、私たちがこれまで考慮する必要のなかった潜在的な相互作用が生み出されています」と、同研究の共著者の1人であるLuis Cezeは付け加えた。

その結果、彼らは過去に多くのSF作家たちが書いてきたような飛躍を経験しているところだ。そして私たちは現在CRISPRのようなツールを用いて探究している最中でもある:DNAは基本的に生命のファイルシステムなのだ。解析プログラムは、DNA鎖の塩基(シトシン、チミンなど、我々がA、T、G、そしてCなどとして知っているもの)を読み取り、バイナリデータに変換している。もしそれらのヌクレオチドが元々別のバイナリデータをコード化していたものだとしたらどうだろう?実のところ、それは既に行われているのだ ― すぐそこで

マッドサイエンス登場

彼らのとった方法は次のようなものだ。転写アプリケーションについて本当に知る必要があることは、それが転写プロセスから生データを読み込み、整列させ、パターンを探し、見つかった塩基配列をバイナリコードに変換するということだ。

「ASCIIによるA、T、G、Cそれぞれの文字からからビットストリームへの変換は、妥当と思われる最大読取り長を前提とした固定サイズのバッファーの中で行われます」と説明するのは、より多くの技術情報を求めた私に答えてくれた共同著者のKarl Koscherだ。

これにより、プログラムが任意のコードを実行することができる基本的なバッファオーバーフロー攻撃のチャンスが生まれる。なぜなら想定外の事態が引き起こされるからだ。(彼らはデモをわかりやすくするために、特定の脆弱性をわざとソフトウェア自身の中に仕込んでいたが、こうした脆弱性は実際にはデモ向きの分かりやすい形ではなく、色々な場所に埋め込まれていることも指摘した)。

実行可能なコードを基本シーケンスに含める方法を開発した後、彼らはそれを使った攻撃コードを研究した。皮肉なことに、これをウイルスと呼ぶのは間違いだが、今までに書かれたどんな悪質なコードよりも「本当の」ウイルスに近いものだ。

「この攻撃コードの長さは176塩基長でした」とKoscherは言った。「圧縮プログラムが、各塩基を2ビット長に変換します。これらは共にパックされ変換の結果44バイト長の攻撃コードとなりました」。

塩基が4種類あることから、それぞれを2つのビットで表現することは理に適っている。Koscherはこれが実際に行われたことであると答えた(もし私のように興味があるのなら、それらは具体的には、A = 00、C = 01、G = 10、T = 11だ)。

「これらのバイトのほとんどは、ASCIIコードで書かれたシェルコマンドをエンコードするために使用されます」と彼は続けた。「4バイトが、シェルコマンドを実行するC標準ライブラリのsystem()関数を呼び出すための変換関数に使われ、更に4バイトが、その実行するコマンドがメモリ内のどこにあるかを指定します」。

本質的に、DNA内のコードは、ACGT群から00011011群に変換されるとすぐに、プログラムとして機能し、システム内でいくつかのコマンドを実行する(system()を介してDNA内に書き込まれた任意のOSコマンドが実行されることになる)。脅威ベクトルの存在を証明するには十分だ。また、アプリケーションを分離する以上のことをしたい場合でも、十分にコードできる余地が残されている。

この攻撃コードを含むDNA鎖の176塩基という長さは「ほとんどの生物学的標準から見て、とても小さいものです」と、このプロジェクトに取り組んでいる研究者のLee Organickは述べている。

バイオパンクの未来がやってくる

興味深いニュースを人類への現実的な脅威と捉える、全ての科学ジャーナリストを駆り立てる性根を発揮して、私はチームに対してより多くの質問を行った。

「ひょっとして」私はこれはあくまでも仮定の話だがと断りながら尋ねた「そうした攻撃コードを、改竄された血液サンプルや、場合によっては誰かの体から直接配布することも可能なのでしょうか?本質的にセキュリティに弱点を抱えるコンピュータに致命的であるようなDNAを持つ人物を想像することができますが」。

困ったことに、Organickは私の恐怖心を煽った。

「シーケンシングのあと、処理をさせて悪意あるコードの実行をさせるために、改竄された生物学的試料を悪意あるDNAのベクターとして利用することは可能です」と彼女は言う。

「とは言え、改竄されたサンプルから悪意のあるDNA鎖をシーケンサーに送り込むためには多くの技術的困難が待ち構えています」と彼女は続けた。「たとえシーケンシングのためにシーケンサにうまく送り込めたとしても、利用可能な形になっていないかもしれません(例えば役に立つ形で読み込むためには細かく断片化されすぎているかも)」。

それは私が想像したバイオパンク黙示録の世界ではないが、研究者たちは少なくとも皆に、潜在的な攻撃パスとしてこのようなものがあることを考えて欲しいと思っている。

「科学者たちがこのことを考慮して、彼らの書くDNA解析ソフトウェアに適切なセキュリティ標準を適用して、潜在的な最初の攻撃ベクターになることが決してないようにして欲しいと思います」とOrganickは語る。

「私はどのような入力も、信用できずアプリケーションに害を与える可能性のあるものとして扱っています」とKoscherは付け加えた。「攻撃コードによってもたらされる可能性のある被害を抑えるために、こうしたアプリケーションは何らかの隔離環境(コンテナ、VMなど)の中で実行することが賢明でしょう。これらのアプリケーションの多くは、公開されたクラウドサービスとしても動作しますが、私はこれらのインスタンスを積極的に分離します」。

このような攻撃のが実際に起きる可能性はほんの僅かだが、デジタルと生物学の重なりが増えたことを示す象徴的なマイルストーンだ。

研究者たちは来週、バンクーバーで開催されるUSENIXセキュリティカンファレンスで、研究結果とプロセス(PDF)を発表する。

[ 原文へ ] (翻訳:Sako)

WordPressの管理画面で更新日一覧を出しソートする方法

WordPress4.7系の脆弱性を利用した攻撃が多数報告されており、対応におわれております。

脆弱性の詳細はこちら。 WordPress の脆弱性対策について (IPA)

また、対応まで含め、こちらのページにわかりやすくまとめられています。 WordPressへの攻撃でてんやわんやの昨日と対処法(アプデだけじゃダメよ) (More Access! More Fun!)

この脆弱性の情報はあちこちで書かれているため詳細は省略しますが、永江さんの記事を参考に、改ざんされていないかどうかをチェックするために更新日を記事や固定ページ一覧に出してソートできるようにしました。

管理画面に更新日を追加する方法として紹介されているページがこちら… WordPressの管理画面に「最終更新日」の項目を増やし、ソートで並び替えたい! (ヒカリカ)

ですが、一部好みに合わない部分やhtmlのエスケープが過剰な部分(なぜ?)がありましたので、以下のように書き換えて使いました。 ついでに固定ページにも対応しています。

// 最終更新日を表示させてソートもさせる ------------------------------------------------------- add_filter( 'manage_edit-post_columns', 'aco_last_modified_admin_column' ); add_filter( 'manage_edit-page_columns', 'aco_last_modified_admin_column' ); // Create the last modified column function aco_last_modified_admin_column( $columns ) { $columns['modified-last'] =__( '最終更新日', 'aco' ); return $columns; } add_filter( 'manage_edit-post_sortable_columns', 'aco_sortable_last_modified_column' ); add_filter( 'manage_edit-page_sortable_columns', 'aco_sortable_last_modified_column' ); // Allow that content to be sortable by modified time information function aco_sortable_last_modified_column( $columns ) { $columns['modified-last'] = 'modified'; return $columns; } add_action( 'manage_pages_custom_column', 'aco_last_modified_admin_column_content', 10, 2 ); add_action( 'manage_posts_custom_column', 'aco_last_modified_admin_column_content', 10, 2 ); // Format the output function aco_last_modified_admin_column_content( $column_name, $post_id ) { // Do not continue if this is not the modified column if ( 'modified-last' != $column_name ) return; $modified_date = the_modified_date( 'Y年Md日H時i分' ); //24時間表記に変更 $modified_author = get_the_modified_author(); echo $modified_date; echo '<br>'; //htmlエスケープの必要なし echo '<strong>' . $modified_author . '</strong>'; //htmlエスケープの必要なし }

echo文の下2行は更新者を表示するためのものですので不要な場合はこの2行と$modified_authorを定義している行も削ってしまって構いません。

最近すっかりブログを書くという習慣がなくなってきているので情報としては後出し感がありますが、いろいろな情報を素早く提供してくれている各サイトオーナーに感謝しつつ、細かな改修ポイントや追加部分を紹介させていただきました。

Heartbleedが自分の範疇外だと思っているアプリエンジニアたちへ

いまさらHeartbleedの話題?とお思いの方もいらっしゃるかと思いますが、自分の周りで、opensslはインフラ担当の範疇だから自分の業務とは無関係だと思っているアプリケーションエンジニアが多い事に危機感を感じ、この記事を書くことにしました。

使っているサーバーにインストールされているopensslのバージョンを細かく調査したり、Windowsサーバーでしか動作させていないとの理由で自分は関係ないと言うならばまだしも、本当にインフラの問題だから…と言い切ってしまって良いのでしょうか? アプリケーションというものがApacheやopensslと言ったミドルウェア(いわゆるインフラ)の上で動いている以上、私はこの判断はNOだと思っています。 Heartbleedは、簡単に言うと脆弱性が存在するサーバーのSSLで使われるメモリ上のデータを読み取ることができるというものです。 このメモリ上には当然ユーザーのアカウントやパスワードも含まれます。 (技術的な解説はDeNAさんのMobage Developers Blogにわかりやすく書かれていました)

これでもまだインフラのことだから無関係だと言えますか?

たしかに漏洩する原因はopensslに起因するものかもしれません。 でも実際にそのパスワード等を管理しているのはアプリケーションであり、悪用されるのはアプリケーションレイヤーの話です。

今、アプリケーションエンジニアがとるべき対応としては、まずはインフラを担当するエンジニアにopensslのバージョンアップとSSLの再発行およびインストールを一刻も早くやってもらうよう促すこと。 並行して、SSL更新前に作成されたパスワードではログインできないようにアプリケーションを改修し、強制的にユーザーにパスワードを再発行させるようなロジックを組み込みましょう。(パスワード漏洩に対する対策の一例です)

このHeartbleedの問題で、カナダでは納税者約900人の社会保障番号が削除されるという大きな被害が出ていたりもします。 自分はアプリケーション担当だからとか、インフラ担当だからのような縦割りの仕事の仕方、もう辞めにしませんか?