ランサムウェアWanna Cry、2003年の時のような大騒ぎ

ヤルノ・ニエメラ

ランサムウェアWanna Cry（W32/WCry）に関して分かっていることと、それから学べることについて、少し時間を取って整理してみる。

技術的な観点から見ると、WCry（2つのバイナリコンポーネントを含む）には、次のような特徴があると言える。

• 2つのWindowsバイナリから構成されている。
  • mssecsvc.exe： 拡散を処理し、ペイロードをドロップするワーム。
  • tasksche.exe： ワームによってドロップされるランサムウェア型トロイの木馬。
• これらのWindowsバイナリにはいくつか亜種が見られたが、数は限られており、ポリモーフィズムは用いられていない。
• exploit-db[.]com.で公開されていたMS17-010の脆弱性を悪用し、SMBポート445を介して拡散する。
  • このエクスプロイトは、元々は、「Shadow Brokers」と呼ばれるグループが流出させたNSAのツールを基にして作成された。
  • MS17-010の脆弱性は、Windows Server 2016までのすべてのバージョンのWindowsに存在するものであったため、この攻撃による感染は、Windows XPだけにとどまらなかった。けれども、XP/Server 2003向けの公開アップデートは、5月14日より前には利用可能なものがなかった。
•  拡散を停止させる「キルスイッチ」機能を備えている。www[.]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]comをチェックすることにより機能するようである（このサイトはWannaCryの作成者は登録しておらず、したがって@malwaretechblogによって登録された結果、拡散をくい止めていた可能性がある）。
  • WCryの”hex-edit idiot”亜種がいくつか見つかっている。キルスイッチを無効化したり、機能を変更したりできるかもしれないと考え、ファイルエディタを使って元のマルウェアに対して修正が図られている。
• ローカルネットワークおよびインターネットをスキャンし、新たに感染させるホストを探す。
• 当初はメールを介して拡散されると報じられていたが、SMB以外の感染経路は確認できていない。

全体として、ここまで書いてきて、ふと、今が2017年ではなく、2003年であるかのような錯覚に陥った。理想の世界なら、このマルウェアの大流行は、起こり得なかったはずである。また、今回の大流行がそれ以上ひどくならなかったのは、世界の至る所でパッチを適用したり、ファイアウォール設定を維持管理してくれているIT管理者たちのおかげに他ならない。彼らの働きがなかったとしたら、もっとひどい大流行となっていたことであろう。たとえば、W32/Blasterワームに感染したコンピュータの台数は、少なく見積もって800万台、多ければ1600万台にも上った可能性がある。

ランサムウェアペイロードを除いては、このワームは、2003年に大流行したW32/Blasterワームによく似ている。W32/Blasterワームは、RPC/DCOMの脆弱性を攻撃するものだったが、その他の点はWCryと非常によく似たものだった。概して言えば、攻撃者たちはスーパーハッカーというわけではなかった。攻撃者たちはワームを作成したとき、自分たちが何を行おうとしているのか、きちんとわかっていたわけではなく、見つけたエクスプロイトを使っただけで、これほど大規模に拡散したり、多くの注目を集めたりすることなど予想だにしていなかったようだ。まるでハエたたきの代わりに大型ハンマーを振り回しているかのような印象だ。世界中の警察が連係して追い詰めようとしているのだから、攻撃者たちは今頃、逃げ場のない行き止まりに向かって走っているようなものだ。

WCryの大流行がなぜ起こり得たかという問いに対する答えは、おそらく、2008年から2010年にかけてメールベースの攻撃がいったん下火になり、最近になって再び流行りの感染経路となっている理由と同じであろう。しばらく攻撃されれていないセキュリティシステムは、重要なものとみなされなくなり、衰退していくものだ。ここ何年かの間は、インターネットおよびローカルネットワークワームが大きな問題になることはなかったため、企業はファイアウォール設定のメンテナンスを怠りがちのようである。また、ホストのファイアウォール設定のしかたがずさんなケースもしばしば見受けられる。ワークステーションからファイルサーバへのアウトバウンドとしてSMBポート445が必要とされていて、もしもの場合に備えて、管理者が双方向を許可しているケースもよくある。

WCryの初期流行は現在収まりつつあるが、脆弱なシステムはそのまま残されている。そのため、時間をかけて過去のネットワークワームを退治した方策について振り返ってみることが重要である。

そして、ネットワークワーム退治で最も重要だったのは、推奨されたベストプラクティスに従って行われたホストのファイアウォール設定であった。

簡単に言えば次のようなことだ。

• ワークステーションは、管理用ワークステーションとドメインコントローラーから以外のインバウンドトラフィックを受け入れない。
• サーバは、あくまでサーバとして設定し、必要な場合を除き、ワークステーションまたは他のサーバに対してアウトバウンドトラフィックを送らない。

つまり、ワークステーションは、メンテナンスのためにそれらのサービスの使用が想定されるソース以外のすべてから、インバウンドポート135、137、138、および445をブロックしておく必要があるということだ。そしてサーバは、サービスの提供のために必要となるポートをオープンにしておく必要があることは言うまでもないが、インバウンドトラフィックは許可されていても、アウトバウンドはブロックする必要がある。

このように設定しておけば、たとえネットワークワームに感染したホストがいても、他のワークステーションを感染させることはできないし、たとえサーバを感染させることができたとしも、そのサーバが他のワークステーションへ感染を拡げることはできない。また、このように設定することにより、特に、Windowsリモート管理ポート5985と5986を、管理用ワークステーション以外のすべてからブロックしている場合には、APT攻撃者が侵入を拡大することも難しくなる。

もちろん、病院のMRI装置のような特殊なケースもある。パッチを適用することができないWindows XPで動作し、MRI画像へのアクセスのためにSMBサーバを実行している。それらのシステムには触ることができないため、そうしたリソースへの接続が許可されるすべてのシステムが十分に保護されていることを確認しておくことが極めて重要である。そのようなMRI装置に接続できるすべてのシステムが自分自身のファイアウォールで保護されていれば、WCryやその他の模倣攻撃を受けても感染させられることはないし、保護できないデバイスへ感染を拡げてしまうこともないのだ。