2015年もひきつづき「これまでの攻撃の洗練」が継続される～基本行動を忘れずに
ところどころで大きなブレイクスルーはあるものの、防御困難な攻撃方法が何の前触れもなくバンバン使われたりするようなことはありませんでした。しかし、攻撃手法の改善や、これまでの攻撃手法をより洗練されたものにするという試みは、普通のユーザの目には見えない形で多く試みられています。特にこの数年は、Web改ざん時に仕掛けられるExploit Kitがより洗練されてきており、狙われる脆弱性もそのときの流行りに応じたものとなっています。
とは言え、洗練された攻撃に対抗する手段の1つは「当たり前の行動」です。パッチを適用したりウィルススキャナを有効にするというのは当たり前の行動ですが、それ以外でもたとえば何かおかしいと思ったら、すぐに然るべきところに問い合わせるというのも当たり前の行動にあたります。
少し難しい言葉を使うと、こういう当たり前の行動は「基本行動」とも言われます。有事のときに奇をてらった対応をするよりも、まずは基本に忠実に行動を行うようにしてください。パッチをあてる、不審なメールには触らない、わからないときは然るべきところに聞くというのは立派な基本行動です。
2014年は「脆弱性の当たり年」
2014年は、Struts 2（ClassLoader Manipuration）に始まり、NTP脆弱性に終わった、そんな感じがする1年でしたが、それ以外にも「システムに対するインパクトの大きい」多くの脆弱性に見舞われた1年でもありました。総括すると、「脆弱性に追い回された1年」とも言えます。日常的にパッチを適用しているような方からすると「なんで？」とも思われるかと思いますが、パッチを適用するということは、大規模／複雑化したITシステムを動作させる要素に変更を発生させるということにほかならず、動作確認などの手間を考えると、どうしてもパッチ適用を躊躇するシステム管理者が多くなるためです。
ぱっと思い出すだけでもHeartbleed、Shellshock、POODLE、Linuxカーネルの権限昇格、NTPのバッファオーバーフロー、etc……、と枚挙に暇がありません。4月に公開されたStruts 1の脆弱性についても、かなりインパクトが大きかったという認識です。特にShellshockは、2014年9月末に発見されたにもかかわらず、いまもってスキャンが多く、まったく油断できない脆弱性になっています。
たとえば、12月19日に、JPCERT/CCが TCP8080番に対するスキャン増加の警告を出していますが、これはQNAP製NASに対するShellshock脆弱性を探索するものと言われています。攻撃者側からすると、大変使いやすい脆弱性なので、探したくなる気持ちもわからないではないんですが……。
しかし、パッチに相当するアップデートパッケージについては、本連載の第1回で詳しく解説しており、あまり心配する性質のものでないこともおわかりかと思いますので、可能な限り適用をご検討いただければと思います。
2014年は「Web改ざん」も健在だが、新たな手口もやっぱり増えた
Web改ざん自体は2014年より前からもよく見られましたが、2014年はより悪意をもった改ざんが目立つ年となりました。
本連載でも紹介したEmEditorのアップデートサイト改ざんは、そのような改ざんの典型例ですが、本連載が始まる前にも2014年1月に発覚したGOM Playerアップデート時にウィルス感染をさせるような事案が発生していました。また、BUFFALO社製ルータのファームウェアダウンロードサイトから入手したアップデートプログラムが、実はマルウェアだったと言う事案も発生していますし、Webサイト閲覧時に表示される広告を経由してマルウェア感染が引き起こされるという事案も発生しています。
いずれの事案も、2013年以前からもたまに見られた感はあるのですが、今年は全部入り＋新たな特徴を引き連れて攻撃がやってきた、というように見えます。
アップデートサイト改ざんについては、Webサイトを直接改ざんするパターンに加え、Webサイトを直接改ざんするのではなく、コンテンツデリバリネットワーク側に置かれたファイルを改ざんするパターンも見られました。
現在のWebシステムは、アクセスを高速化させるためにさまざまな仕組みが介在するようになっていますが、そのしくみのうち脆弱なもの、もしくは攻略が容易かつ追跡が困難なサービスが狙われる傾向が顕著になっていると言えます。
未然防止はできれば良いが、それでもリスクはゼロにできない
ここまでで述べてきたものは、あくまで2014年に発生した事案等の一部ですが、特徴的なのは「改ざんされたサイトのオーナ」や「脆弱性を持つソフトウェアを使うサービスのオーナ」以外の人たち、たとえば当該サイトを利用する人たちや、製品を使う人たちにもリスクが及ぶ点と言えます。
以前からも見えていたことではありますが、「ただネット使ってただけなのに」「アップデートしようとしたら」という話が真顔で聞こえてきそうな事案が増えてきたと言えます。
筆者の持論の1つに、「システムが保有するリスクをゼロにはできない」というものがあります。極端な話、システムを稼働させるのはリスクにつながりますし、直接／間接を問わずシステムを他者に利用してもらうのもリスクにつながります。アップデートのためにネットワークに接続するのも、今となってはリスクと言っても良いかもしれません。
しかし、システムを稼働させない場合に取りうる代替手段を執行するというのもリスクになりえます。「アップデートしたらウィルスに感染しそうだからアップデートしない」というのは一見正論に聞こえますが、実はアップデートを行わないことによるさらなるリスクを呼びこむ危険性もあります。
いわゆるITシステムを使い続けること自体がリスクと言えますが、実は皆さん、日常生活でも相応のリスクを背負っています。外出時の事故遭遇リスクや各種トラブルに巻き込まれるリスクをはじめとして、さまざまなリスクを背負うことになります。しかし、それらのリスクが現実のものとならないように留意して行動しているからこそリスクを減らせているのです。
ITシステムの場合、そのような行動は適切な設定や修正ファイル、パッチの適用となります。もちろん、もともとのシステムがきっちりと設計・開発されていることが前提ですが、後で攻撃・被害にあって修正したりお詫びなどの対応を行うためのコストよりは、少し手間だと思っても事前に確認・修正を行うほうが全然マシです。
これからのアップデートサイトは堅牢に作り、かつ実在証明を
2014年に発生した事案の中で、個人的に印象に残ったのは、ソフトウェアのアップデートサイトが狙われる事案でした。
「筆者が攻撃者ならば」という考え方を以って、狙って気付かれづらく、かつ効果が高いのは、「よく使われるソフトウェアのアップデートサイト」を狙ってこっそりアップデータを入れ替えることではないかと思い至るようになりましたが、実際にその手口が使われたということになります。
しかし、このような手口が広まった場合、懸念されるのは「アップデートサイト」の信頼性が低下していくことです。ソフトウェアアップデートをかけるとマルウェアに感染するとなったら、そのうち誰も自動アップデートを行わなくなります。自動アップデートを行わないからといって、手動でアップデートをかけるかと言われるとなかなか怪しく、そうなると脆弱性を持つソフトウェアのユーザが被害にあいやすくなる、という構図にはまりこんでいきます。
特に商用ソフトウェアのアップデートサイトについては、堅牢に作ることに加え、SSL等を用いて開発・配布を行っている人／会社が運営するサイトであることを担保するなどのことをやって行っても良いのではないか、と考えています。
脆弱なシステム基盤は、すべての安全を水泡に帰します。どれだけセキュアプログラミング技法を駆使しようとも、どれだけアプリケーションテストを厳密に実施しようとも、それらのアプリケーションが動作するシステム基盤が脆弱だと、それらの努力はなかったも同然になりますし、そもそもユーザが違うシステムに（騙されて）呼び込まれ、かつユーザが騙されたことに気付かないと意味がなくなってきます。
何やってもダメなら、何もしないほうが楽？～やれることはやったほうが格段に良い
管理者泣かせの脆弱性がごろごろ出てくる中で、普通にインターネットを使っているだけでも（いわゆる）マルウェア感染などは普通に起きうる事案になっています。そうなると、「起きうるし構えてても踏んじゃうならば何もしないほうが楽なのでは？」と思われる方もいらっしゃるかもしれません。
しかし、多くのマルウェアは、ちょっと気を付けているだけでもだいぶ防げるものですし、多く出回るマルウェアが悪用する脆弱性は、古めのものが多いとされています。メール等に添付されてくる画像や文書ファイル等に見せかけたマルウェアも、ちょっと気をつけてみると実行ファイルだったり、そもそも自分のところになんで来るのかわからない請求書や受領証、それも日本語以外の言語で書かれたものを模したものだったりします。筆者のところにも、そのようなマルウェアがメールに添付されてぼちぼち送られてきますが、全部スルーしてます。
当たり前のことをきちんとやることで、下げられるリスクも多いです。年が明けて「あらためて」当たり前のことをきちんとやれるようにしましょう。以下は「当たり前のこと」の例になります。
- クライアントPCの場合
- パッチは適用してウィルススキャナは有効にする
- 身に覚えのない人からのメールは開かない
- サーバの場合
- 余計なサービスは動かさず、動かすサービスについてパッチは適用しておく
- ログは保存しておき、適宜確認を行う
それでは、2015年もよろしくお願いします。
