HOME情報セキュリティ資料・報告書・出版物調査・研究報告書情報セキュリティ技術動向調査(2010 年上期)

本文を印刷する

情報セキュリティ

情報セキュリティ技術動向調査(2010 年上期)

7 Gumblar攻撃に対する技術の現状と課題

宮川 寧夫

1. はじめに

  2009年下期にはGumblarと呼ばれるWeb媒介型の攻撃手法攻撃が注目された [1] が、未だ収束していない様子である。Gumblar攻撃は一連の攻撃であり、その一連の攻撃への対策箇所を下表(表1)に示す。


表1: Gumblar攻撃への対策箇所

  本稿においては、2点の対策技術をとりあげる。

(1) セキュアなWebファイルのアップロード
      意図しないリダイレクトの設定等のWebファイルの改変についての対策として、Webサイトの管理者向けにFTP/SSHにおける本人認証(authentication)機能についてとりあげる。Webコンテンツの管理は、しばしばアウトソーシングされている実態があり、安直なパスワードが流通しているようである、そこで、実質的に必要なエントロピーに関する指針文書を紹介し、より強い本人認証の利用可能性について現状を整理する。なお、Webファイルの改変についての監視等の継続的な対策については本稿においては割愛する。
(2) 出方向のパケットフィルタリング
      Gumblar攻撃においては、エンドユーザが意図しない出方向トラフィックをマルウェアが発生させて、後続のシーケンシャルマルウェアを呼び寄せている構図がある。そこでエンドユーザ環境にも出方向のパケットフィルタリングを配備することが推奨されつつある。エンドユーザがブラウザを操作してアクセスするWebサイトをフィルタリングすることも一種の出方向のフィルタリングではあるが、今般のマルウェアによる外部のサイトへのアクセスは、HTTPのトラフィックに限定されない。

2. セキュアなWebファイルのアップロード

2.1 攻撃対象とされるWebコンテンツ管理者のアカウント

  まず、意図しないWebファイルのアップロードについては、Webサイトのコンテンツ管理者向けの話題となる。
  Webコンテンツ管理用には、各種のWebオーサリングツールやCMS(コンテンツ管理システム)のユーザインタフェィスと連動するFTP画面が用意されていることがある。また、アウトソーシングされている場合、FTPよりは経路を防護されるSSH(Secure Shell)[2]のscpコマンド等が利用されることが望ましい。SSHの代表的な実装と言えばOpenSSH1 が挙げられる。経路が防護されるファイル転送用のプロトコルとしては、他にFTPS(File Transfer Protocol over SSL/TLS)[3] [4] もある。
  Gumblar攻撃において、Webコンテンツ管理者のアカウントが攻撃対象となるが、その際の攻撃ツールとして、FTPやSSH のアカウントに対してブルートフォース攻撃を行うツールの存在が広く知られてしまっている状況にある。FTPやSSHのアカウントについては、通常、パスワードによる認証(authentication)の機能が利用されている。

2.2 運用上の対策項目

  今期のSANSのISC(Internet Storm Center)の日誌に掲げられているSSHの運用管理における対策事項 [5] を手がかりとして検討してみる。この中では、下記の対策事項が掲げられている。

  • TCP 22番以外のポートにSSHサーバを導入する…(1)
  • SSHブルートフォース防止のためのツールを導入する…(2)
  • リモートのルートログインを不許可にする…(3)
  • パスワードによる認証(authentication)を禁止に設定して鍵を利用する…(4)
  • パスワードを使わなければならない場合は複雑なものにする…(5)
  • AllowGroupsを使って特定のユーザーグループのアクセスを制限する…(6)
  • 可能であればSSHにchroot jailを利用する…(7)
  • SSHに接続できるIPレンジを制限する…(8)

(1) ポートスティーリング(ポート番号の変更)
      ポート番号の変更は、FTPにおいても古くから利用可能なテクニックであった [6]。このテクニックは、SSHにおいても有効である。
(2) 対策ツールの導入
      今日的なツールとしてsshdfilter(V1.5.7 ssh brute force attack blocker)2 がある。これは、SSHに対する攻撃のログから ipfilterを作るものである。
(5) パスワードの複雑化
      例えば、MUSTANシステム3 によって観測されるSSHアカウントに対する攻撃は、次のようなアカウント名を対象としている(例:admin、test、oracle、mysql、postgress等)。このように、コンテンツ管理者のアカウント以外にDBMS管理者のアカウントも狙われている。パスワードの選択においては、これらの傾向を反映して一定の「辞書ルール」を適用して安直なパスワードを避けることが必要である。
      今日的なパスワードのエントロピーに関する文書としては、NISTのSP 800-63, “Electronic Authentication Guideline” [6] 中のAppendix A `Information about estimating the entropy of passwords’が良くまとまっている。上述の「辞書ルール」に関しては、パスワードの文字数が長くなるに従って追加的な効果は期待できなくなるが、長くないパスワードが設定される場合には有効であることも示されている。本書自体は、エンドユーザが利用する本人認証機能についての要件を、4つのレベルに分けて規定しているものであり、この詳細については本稿においては説明しないが、その中で「レベル2」については`Passwords shall have at least 10 bits of min-entropy’と規定されているように、エンドユーザ向けのパスワードについては、さほど多くの字数が要件とはされていない。また、ランダムに生成されたパスワードのエントロピーは、ユーザが選択するパスワードのエントロピーよりも高い。
      システム管理用の本人認証については、一般に、より高いレベルの本人認証が要求されることになるが、本書が「レベル3」以上の要件として規定するトークン等のデバイスを利用するようなWebコンテンツ管理用のリモートアクセス手段は見あたらない。後続のシーケンシャルマルウェアの中にクライアントPC内に保存されている正規のFTPもしくはSSHのアカウントのパスワードを探査するものもあるようであるので、トークン等のデバイスに本人認証用の秘密データを待避できることが理想的ではある。当面は「複雑なパスワード」によってエントロピーを高めてしのぐことになろう。
      OpenSSHには、長いパスワードを入力することができ、unix用のものでは128文字までの入力を許容できる。アウトソーシングされている実態のもとで、紙の契約文書と共にオフラインで渡すことができるパスワード方式には有用性があり、必ずしもユーザが選択しなければならない要件は無い場合が多い。
    改ざん後の対策(パスワードの変更)
      ひとたびGumblar攻撃の一環として罠をWebコンテンツの中に埋め込まれてしまうようなインシデントが発生した場合、強制的にパスワードを変更させる必要がある。この際に、強制的にランダムに生成されたパスワードに切り替えることも考慮する価値がある。

2.3 実装についての話題

  SP 800-63における「レベル3」以上に相当するような、トークンを用いる、より強い本人認証機能の可能性を話題としたい。既述のように、シーケンシャルマルウェアの中にはクライアントPC内に保存されている正規のFTPもしくはSSHのアカウントのパスワードを探査する機能が実装されているものもあるようであるので、トークン等のデバイスに本人認証用の秘密データを待避できることが理想的ではある。実際上、PKI(公開鍵インフラストラクチャ)技術に基づくことになるので、PKI環境を構築・配備した環境をもつ組織体であれば導入できる。

(1) SSHについての実装
      OpenSSHにおいてX.509 v3証明書を利用できるようにする実装の試みは、Petrov氏によって行われておりOpenSSHがバージョンアップされるたびに更新されている。4。 証明書管理についてはOpenSSLの証明書ストレージ(X509 Store)に依存した実装となっているので、認証機能も基本的にOpenSSLに依存していることになる。
      本人認証においては、毎回、署名と証明書の検証するのがデフォルトとなっており、本人認証に失敗すると署名が無効になるような記述もある。システム構成において選択する項目は多い(例:暗号アルゴリズムの選択、証明書検証関連の選択、等)。
(2) FTPSについての実装
      FTPSについて、クライアントの実装にもサーバの実装にも多くのもの実装された5。これらの中には、経路の防護のみならず証明書管理についてもOpenSSLに依存しているものが多い。

1 http://www.openssh.org/
2 http://www.csc.liv.ac.uk/~greg/sshdfilter/
3 http://mustan.ipa.go.jp/mustan_web/
4 http://roumenpetrov.info/openssh/
5 http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html

 

3. 出方向のパケットフィルタリング

3.1 出方向のトラフィックへの関心の経緯

  組織のネットワークを防護する際に、とかく外部から内部への入方向(ingress)のトラフィックについての関心事が話題の中心となり、外部からの防護が重視されている。一方、出方向(egress)のトラフィックにも固有のセキュリティ論点がある。例えば、正規のWebサイトを装うフィッシング(phishing)サイトへのアクセスや、マルウェアが掲載されているサイトへのアクセスを抑止するフィルタリング技術のような話題がある。ボットネットが台頭してきたことを受けて2005年頃の対策文書の中に出方向のフィルタリングについての言及は見られる[8]。それ以前は、出方向のフィルタリングは、ISP(インターネットサービスプロバイダ)向けの話題であった[9]。ISP単位の大きなドメインについて論じられていたこの話題は、組織単位で論じられる話題となった。
  今般の関心事は、「いわゆるシーケンシャルマルウェアが、マルウェアを連続的にダウンロードするための外部サイトへのアクセスを抑止できないか?」という関心事であり、ネットワークセキュリティについてのプロフェッショナル向けトレーニングの分野において数年前から重要性が指摘されていた[10]。この関心事においては、Webアクセスを扱うHTTPトラフィック(80番ポート)も含めて扱うが、マルウェアが使う他のポート番号(例:IRCの6660~7000等)のトラフィックも扱うことになる。シーケンシャルマルウェアの挙動は、2008年末のConflicker(Downadup)の蔓延時に注目された。この蔓延を受けて検討された追加的な推奨事項として出方向のトラフィックについてのフィルタリングが挙げられている[11]
  出方向フィルタリングについての要件は、2008年10年に発行されたPCI(Payment Card Industry)-DSS(Data Security Standard)のバージョン1.2 [12] 以降のバージョンの1.2.1節および1.3.5.節にも見られる。

3.2 実装についての話題

  具体的に、多くのブロードバンドルータにおいて出方向のフィルタリングを設定することは、現状では必ずしも容易ではないようである。出方向のフィルタリングを設定し易くすることは課題のひとつと言えよう。
  IPv6環境を構築する際にも、今般、IPv4環境において起きているGumblar攻撃のような脅威を想定して、この出方向のトラフィックの制御のような対策がし易い実装を用意しておくことが期待される。

以上

参考文献

[1] 井上 大介,「Web媒介型攻撃Gumblarの動向調査」
http://www.ipa.go.jp/security/fy21/reports/tech1-tg/b_05.html
[2] RFC 4251, “SSH Protocol Architecture” (2006)
http://tools.ietf.org/html/rfc4251
[3] RFC 2228, “FTP Security Extensions” (1997)
http://tools.ietf.org/html/rfc2228
[4] RFC 4217, “Securing FTP with TLS” (2005)
http://tools.ietf.org/html/rfc4217
[5] SANS, Internet Storm Center Diary,
`Distributed SSH Brute Force Attempts on the rise again’,
Published: 2010-06-18,
http://isc.sans.edu/diary.html?storyid=9031
[6] NIST SP 800-63, “Electronic Authentication Guideline” Version 1.0.2 (2006)
http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
[7] RFC 2577, “FTP Security Considerations” (1999)
http://tools.ietf.org/html/rfc2577
[8] US-CERT Informational Whitepaper, “Malware Threats and Mitigation Strategies” (2005),
http://www.us-cert.gov/reading_room/malware-threats-mitigation.pdf
[9] RFC 3013,「推奨される ISP セキュリティサービスと手順(Recommended Internet Service Provider Security Services and Procedures)」(2000)
http://www.ipa.go.jp/security/rfc/RFC3013JA.html
[10] “Detecting and Preventing Unauthorized Outbound Traffic”, SANS (2007),
http://www.sans.org/reading_room/whitepapers/detection/detecting-preventing-unauthorized-outbound-traffic_1951
[11] SANS Technology Institute. Group Discussion/Written Project GIAC Enterprises Downadup Incident (2009),
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.175.9006&rep=rep1&type=pdf
[12] PCI Security Standards Council, “PCI DSS Version 1.2”,
https://www.pcisecuritystandards.org/

 

目次へ 次へ