１．脆弱性の概要

■脆弱性とは

情報の取扱いににかかわる様々な構成要素の中にあって、情報の漏えいや紛失、改ざんなどのリスクを発生しやすくしたり、拡大させたりする要因となる弱点や欠陥のこと。

・脆弱性の種類

  • 設備面の脆弱性
    • 建物の構造上の欠陥
    • 設備のメンテナンスの不備
    • 入退室管理の不備
  • 技術面の脆弱性
    • ネットワーク構成における欠陥
    • ソフトウェアのバグ
    • アクセス制御システムの不備
    • 設定ミス、安易なパスワード
    • マルウェア対策の不備
  • 管理面／制度面の脆弱性
    • 情報セキュリティに関する方針規定の不備
    • 教育、マニュアルの不備
    • 監視体制、監査の不備

エクスプロイトコード　⇒　パッチ適用されなければ脆弱性は残ったままになる。それを悪用して攻撃するために作成されたプログラムのこと。

・脆弱性の識別／評価の仕組み

  • JVN(Japan Vulnerability Notes)　⇒　脆弱性関連情報と対策情報を提供するポータルサイト
  • CVE(Common Vulnerabilities and Exposures：共通脆弱性識別子)　⇒　脆弱性を識別するための識別子
  • CWE(Common Weakness Enumeration：共通脆弱性タイプ一覧)　⇒　脆弱性の種類を識別する共通基準。SQLインジェクションやXSSなど、脆弱性タイプの一覧を体系化している。
  • CVSS(Common Vulnerability Scoring System：共通脆弱性評価システム)　⇒　脆弱性の深刻さを評価する仕組み。以下3つの基準がある。
    • 基本評価基準(Base Metrics)　⇒　脆弱性そのものの特性。機密性、完全性、可用性に対する影響を評価し、CVSS基本値(Base Score)を算出
    • 現状評価基準(Temporal Metrics)　⇒　脆弱性の現状の深刻度。エクスプロイトコードの出現有無や対策情報が利用可能であるかどうかなどを評価し、CVSS現状値(Temporal Score)を算出
    • 環境評価基準(Environmental Metrics)　⇒　製品利用者の利用環境も含めた、最終的な脆弱性の深刻度。攻撃による被害の大きさや対象製品の使用状況。CVSS環境値(Environmental Score)を算出

・情報資産、脅威、脆弱性の関係

3つが結びついたときに初めて実害となる。

２．ネットワーク構成における脆弱性と対策

機密性、完全性の侵害につながるもの、可用性の低下につながるものがある。

・機密性、完全性の侵害につながるもの

  • webサーバとファイルサーバがセグメント分割されず、同一セグメントに存在する
  • 社内LANと関連会社のLANが専用線で接続されており、アクセス制限がされていない
  • セグメント間でアクセス制限を行っていない
  • インターネットへの接続口や社内アクセスポイントが必要以上に数多く存在する
  • 十分なセキュリティ対策刺されていない無線LANアクセスポイントが存在する
  • リピータハブが多用されている
  • ハブが会議室などの共有スペースなどに無防備な状態で置かれている

・可用性の低下につながるもの

  • 十分な帯域が確保されていないネットワークや十分な処理能力を有していないネットワーク機器を使用している
  • 回線やネットワーク機器の二重化、冗長化が行われていない
  • 回線やネットワーク機器の負荷分散が適切に行われていない
  • インターネット接続口において帯域制限が行われていない。
  • リピータハブが多用されており、スイッチングハブやレイヤ2スイッチによるLANの論理的分割が行われていない

３．TCP/IPプロトコルの脆弱性と対策

・共通の脆弱性

  • 仕様が公開されている
  • 発信元IPアドレスの偽装が容易
  • パケットの暗号化機能が標準装備されていない（IPv4の場合）
    ⇒IPsecやTLSを用いて、VPN環境を構築するか、個々のアプリケーションで実施する必要がある。IPv6では、IPsecが標準装備されている。

・共通の脆弱性への対策

  • 発信元アドレス偽装への対策
    ⇒　以下は明らかに偽装されているので、ルータやファイアウォールで遮断する

    • 発信元IPアドレスにプライベートアドレスが設定された、インターネットからのインバウンド（内向き）パケット
    • プライベートアドレスを使用しているセグメントにおいて、発信元IPアドレスにグローバルアドレスが設定された合う度バウンド（外向き）パケット
  • パケット秘匿化のための対策
    • IPsec、TLS、SSH、S/MIMEなどの暗号化プロトコルを使用
    • IPv6の導入

４．電子メールの脆弱性と対策

SMTP(Simple Mail Transfer Protocol)と、POP3(Post Office Protocol Version3)の仕様と実装における脆弱性について解説する。

・SMTPの脆弱性

  1. メールの投稿や中継などがすべて同じ仕組みで行われている
    ⇒　旧バージョンのメールサーバソフトウェアでは、MSAは使用されていなく、MUAからのメール送信要求も、メールサーバ間の中継処理も区別なく、MTAが25番ポートで同様に処理している。また標準設定ではドメイン名などの制限がなく、誰からのメール投稿であっても受け付けるようになっている。
  2. メールの投稿に当たってユーザを認証する仕組みがない
    ⇒　発信元メールアドレスの詐称が容易で、組織外の第三者から別の第三者へのメール投稿を受け付けて中継してしまう。（第三者中継、オープンリレー）
    ＃現在普及しているメールサーバソフトウェアでは、SMTP-AUTHが実装されているため、ユーザ認証可能。
    本来は、次の条件にあてはまるメールのみを中継すればよい。第三者中継では、発信元／宛先ともに自分のサイトのドメイン名が含まれていない。
    ・発信元メールアドレスに、自分のサイトのドメイン名が含まれているもの
    ・宛先メールアドレスに、自分のサイトのドメイン名が含まれているもの
    ※NDR(Non-Delivery Report：配送不能通知)メールを悪用した手法
  3. メールの暗号化機能が標準装備されていないため、平文でネットワークを流れる
  4. MTAの実装・設定によって、ユーザのメールアカウント情報が漏えいする可能性がある
    ⇒　VRFY,EXPNなどのコマンドで、メールアカウントの有無やメールの配送先情報を確認することができる
  5. MTAの種類、バージョンによって、BOF攻撃を受ける脆弱性がある

・SMTMP脆弱性への対策

  1. MTAの設定による発信元メールアドレスの制限
    ⇒　第三者中継の禁止
  2. SMTP Authentication(SMTP-AUTH)によるユーザ認証
    ⇒　MTA,MUAの双方が対応する必要がある。SASL(Simple Authentication and Security Layer)に基づく。以下にユーザ認証方式の種類を記載する。
    ・PLAIN：平文のままユーザIDとパスワードを送信する方式。
    ・LOGIN：PLAINとほぼ同じ
    ・CRAM-MD5(Challenge-Response Authentication Mechanism)：メールサーバから受け取った任意の文字列(チャレンジ)とパスワードから生成したMD5のメッセージダイジェストをもとに認証する方式。
    ・DIGEST-MD5：CRAM-MD5のセキュリティ機能強化版。
  3. POP before SMTPによるユーザ認証
    ⇒　メール送信に先立ってPOP3によるユーザ認証を行い、成功した場合に一定時間送信を許可する方式。
  4. Outbound Port25 Blockingによるメール投稿制限(OP25B)
    ⇒　1の対策をしても、送信先メールサーバと直接SMTPコネクションを確立されると防ぐことができない。それを防ぐための対策がOP25B。ISPのメールサーバを経由せずにインターネット方向（外向き）に出ていく25番ポート宛てのパケット(SMTP)を遮断する方法。正当な利用者が自社のメールサーバなどと直接SMTPコネクションを確立してメール送信する場合は、25番ポートではなく投稿専用の587番ポートを使用する。そのために、従来のMTAの機能をMTAとMSAに分離する。
  5. IPアドレス、ディジタル署名による送信ドメイン認証：発信元IPアドレスやディジタル署名によってメール受信側で発信元SMTPサーバを認証する仕組み（送信ドメイン認証）
    1. IPアドレスによる方式
      1. Sender Policy Framework(SPF)
        ⇒　発信元ドメインのDNSサーバに正当なSMTPサーバのIPアドレス(SPFレコード)を登録しておくことで、発信元のSMTPサーバを認証する。
      2. Sender ID Framework(Sender ID)
        ⇒　SPFに加えて、受信メールのヘッダ情報のメールアドレスのドメインの正当性を検証する。
    2. ディジタル署名による方式
      1. DomainKeys
        ⇒　発信元ドメインのDNSサーバに正当なメールサーバの公開鍵を登録しておき、SMTPサーバが付与したディジタル署名によって、発信元のメールサーバの正当性を検証する。
      2. DomainKeys Identified Mail(DKIM)
        ⇒　DomainKeysとほぼ同様
  6. メールフィルタリング
  7. SMTP over TLSによるメールの暗号化およびユーザ認証
    ⇒　暗号化されるのは、クライアント(MUA)～発信元(自分のサイト内)のメールサーバまでの通信のみで、インターネット上では平文となる。
  8. S/MIME,PGP等によるメールの暗号化
  9. MTAの不要なコマンドの無効化
    ⇒　VRFY、EXPNなどの不要コマンドを無効化
  10. その他、MTA実装面の対策
    ⇒　インターネットのSMTPサーバと社内LAN上のSMTPサーバとの間で相互にメールの中継を行う中継専用メールサーバ(外向けSMTPサーバ)をDMZ上に設置する。

・POP3の脆弱性

POP3(Post Office Protocol Version3)：MUAがサーバからメールを受信するための代表的なプロトコル

  1. 認証情報が平文でネットワーク中を流れる
    ⇒　POP3では、USER/PASSコマンドでユーザ認証を行うが、平文のままネットワーク上を流れるため、盗聴により認証情報が盗まれてしまう可能性が高い。
  2. 受信データ（メール）が平文でネットワーク中を流れる
    ⇒　メールの内容自体も平文のままである。情報漏えいや改ざんの可能性がある。

・POP3の脆弱性への対策

  1. APOP(Authentication Post Office Protocol)によるユーザ認証情報の秘匿化
    ⇒　APOPは、メールサーバとMUAとの認証において、チャレンジレスポンス方式によるユーザ認証を行う。サーバから送られてくる文字列（チャレンジ）とパスワードを連結した文字からMD5を用いてメッセージダイジェストを生成し、それをレスポンスとしてサーバに返すことで認証を行う。ただし、メールそのものは平文のままネットワーク中を流れる。
  2. 「POP3 over TLS」(POP3S)による認証情報およびメールの暗号化
    ⇒　暗号化されるのは、直接通信するPOP3サーバ～クライアント(MUA)の通信のみ。995/TCPポートを使用する。
  3. SSHのポートフォワーディング機能による認証情報およびメールの暗号化
    ⇒　SSHポートフォワーディング機能を用いて、POP3通信を暗号化する。暗号化されるのは、直接通信するPOP3サーバ～クライアント(MUA)の通信のみ。22/TCPポートを使用する。

５．DNSの脆弱性と対策

・DNSの脆弱性

  1. ゾーン転送機能によって第三者に登録情報が不正利用される可能性がある
  2. 不正な情報をキャッシュに登録することができる可能性がある(DNSキャッシュポイズニング攻撃)
  3. 不正なリクエストによってサービス不能状態となる可能性がある(BOF攻撃、DoS攻撃)

・DNSの脆弱性への対策

  1. DNSサーバプログラムのバージョンアップ
  2. DNSSEC(DNS Security Extensions)
    ⇒　名前解決要求に対して応答を返すDNSサーバが、自身の秘密鍵を用いて応答レコードにディジタル署名を付加して送信する。これにより、応答を受け取った側は、応答を返したDNSサーバの公開鍵を用いてディジタル署名を検証することで、応答レコードの正当性と完全性を確認する。
  3. 外部向けゾーン情報と内部向けゾーン情報の分離
  4. コンテンツサーバとキャッシュサーバの分離
  5. ゾーン転送の制限
    ⇒　インターネットからのゾーン転送要求を受け付ける必要が無い場合、公開DNSサーバに対する53/TCPのアクセスをファイアウォールでフィルタリングする。
  6. キャッシュサーバを利用可能なホストの範囲を制限
  7. キャッシュサーバへの問合せ数を制限　⇒　DoS攻撃への対策
  8. DNSサーバプログラムのバージョン情報の隠ぺい

・512オクテット制限への対応

  • DNSの名前解決は通常UDP/53を使用するが、1パケットに格納できるデータは512オクテットに制限されている。
  • 超える場合は、DNSサーバはTC(Truncation)ビットをセットして返信し、データが切り捨てられたことを送信元に伝える。
  • その後、TCP/53ポートで再問合わせ　⇒　TCPフォールバック、高負荷で応答時間が遅い
  • 解決策がEDNS0(Extension mechanism for DNS version 0)で、UDPパケットサイズを最大65535オクテットにすることが可能。

６．HTTPおよびWebアプリケーションの脆弱性と対策

・HTTPおよびWebアプリケーションの仕組み

  1. セッション管理の脆弱性と対策
  2. HTTP(プロトコル)の仕様による脆弱性
  3. Webサーバの実装や設定不備による脆弱性
  4. Webアプリケーションの仕様や実装による脆弱性

③：ソフトウェア脆弱性情報を随時確認、パッチを適用する。

①④：脆弱性検査を実施、確実に改修する。

・セッション管理の脆弱性と対策

・脆弱性の種類

  1. パケット盗聴によってセッション管理情報が盗まれる可能性がある(HTTPの場合)
    ⇒　クエリストリング、hiddenフィールド、クッキーいずれにおいても、HTTPで通信している場合は盗聴される可能性がある。
  2. セッションIDが推測・改ざんされ、他社に情報等が漏えいする可能性がある
    ⇒　HTTPSでも推測されればダメ
  3. 詳細なセッション管理情報をWebサーバとクライアント間でやり取りしていることにより、他社に情報等が漏えいする可能性がある
    ⇒　GETメソッドでクエリストリングを使用している場合に特に危険
  4. Referrerのログから他のWebサイト管理者にセッション管理情報が漏えいする可能性がある
    ⇒　3と同様
  5. hiddenフィールドの改ざんにより、不正な処理を実行される可能性がある
    ⇒　HTMLを保存することにより内容の改ざんは容易
  6. XSSの脆弱性により、クッキーにセットされたセッション管理情報が盗まれ、悪用される可能性がある
  7. クッキーの属性設定の問題により、クッキーにセットされたセッション管理情報が盗まれ、悪用される可能性がある
    ⇒　secure属性が設定されていないと、HTTP通信でもクッキーが送出され、盗聴される危険性が高まる。必要以上に長い有効期限、適切でない有効範囲の設定も危険。
  8. Webサーバで「URL Rewriting機能」が有効になっていると、意図的なセッション管理情報をクエリストリングにセットして使用することができる可能性がある
    ⇒　クッキーにセットされたセッション管理情報をクエリストリングとして送ることができる可能性がある。セッションフィクセーションが行われる可能性がある。
  9. セッション管理のバグにより、本来は認証を必要とするWebページに認証プロセスを経ることなくアクセスされる

・脆弱性への対策

  • HTTPS(TLS)によって通信する
  • セッション管理情報はすべてWebサーバ側で管理し、クエリストリング、クッキー、hiddenフィールドには、セッションIDしか含めないようにする
  • セッションIDには十分な長さをもった乱数やハッシュ値を用いる
  • POSTメソッドを用いてセッション管理情報を隠蔽し、GETメソッドではデータを渡せないようにする。ただし、POSTメソッドではWebサーバのアクセスログに入力データが記録されないため、Webアプリケーション側でデータの内容をロギングするようにする。
  • クッキーの有効期限を可能な限り短く、有効範囲は可能な限り狭く。
  • HTTPSでアクセスするWebページでは、必ずクッキーを「secure属性あり」に設定する。
  • HTTPでアクセスするWebページと、HTTPSでアクセスするWebページを跨ってセッション管理する場合は、2つのクッキーを発行し、一方を「secure属性なし」にしてHTTPのページで使用する。もう一方を「secure属性あり」にしてHTTPSのページで使用する。
  • 入力データに含まれるメタキャラクタのエスケープ処理を行い、XSS脆弱性を取り除く。
  • Webサーバの「URL Rewriting」機能を無効に設定する。
  • 認証を必要とするページが直接アクセスされることが無いようセッション管理を確実に行い、検索エンジンやキャッシュに登録されないように設定する(<meta>タグを用いる）
  • セッション管理を自社で開発せず、アプリケーションサーバなどに実装されている機能を使用する。
  • ログイン後に新たなセッションIDを発行するようにする。
  • Webアプリケーションファイアウォール(WAF)を用いて、攻撃を遮断する。

・HTTP（プロトコル）の仕様による脆弱性と対策

・脆弱性の種類

ここではセッション管理に関するもの以外を示す。

  1. HTTPでは通信データが平文でネットワークを流れるため、パケット盗聴によって重要な情報が盗まれたり、改ざんされる可能性がある。
  2. ベーシック認証の脆弱性により、パケット盗聴によって認証情報が盗まれる危険性が高い。
    ⇒　HTTPの基本機能であるベーシック認証では、入力された認証情報（ユーザID／パスワード）がBASE64エンコードされ、ネットワーク中を流れる。BASE64はバイナリデータ⇒テキストデータの変換方式で、でコードは容易。また、ベーシック認証ではHTTPリクエストのたびに認証情報が送出される。
  3. ベーシック認証では、Webサーバで認証情報を管理する必要があるため、漏えいなどの危険性が高まる。
    ⇒　一元管理ができず、管理が煩雑になり、漏えいの危険性も高まる。

・脆弱性への対策

  • HTTPS(TLS)によって通信する。
  • HTTPのベーシック認証は極力使用せず、認証用の入力フォームを用いる（フォーム認証）か、チャレンジレスポンス方式とMD5の採用によって認証情報が秘匿化されるHTTPダイジェスト認証を用いる。
  • フォーム認証では認証情報はWebサーバで管理せず、データベースなどを用いて管理する。

・Webサーバの実装や設定不備による脆弱性と対策

ここではセッション管理に関するもの以外を示す。

・脆弱性の種類

  1. ディレクトリに関する設定不備により、ディレクトリトラバーサル攻撃を受けたり、ディレクトリ参照によって機密情報にアクセスされたりする可能性がある。
    ⇒　ディレクトリのアクセス権の設定不備、ディレクトリ参照が許可されている、デフォルトページが置かれていない（index.htmlなど）
  2. エラーメッセージの出力設定不備により、機密情報が漏えいする可能性がある。
  3. HTTPヘッダ情報からWebサーバプログラムの種類やバージョン情報が知られてしまう可能性がある。
    ⇒　デフォルト設定ではWebサーバプログラムの名前やバージョン情報などをHTTPヘッダにセットして送出するようになっているため、ポートスキャンなどによってそれらの情報が知られてしまう。
  4. Webサーバプログラムの種類、バージョンによってBOF攻撃を受ける脆弱性がある。
  5. コマンドやメソッドの設定不備により、コンテンツの改ざんや管理情報の漏えい等につながる可能性がある。
    ⇒　PUTメソッドが使用可能だと、不正なコンテンツが書き込まれる可能性がある。TRACEメソッドが使用可能かつXSSの脆弱性があると、HTTPヘッダに含まれるクッキー情報や認証情報が取得されてしまう可能性がある（クロスサイトトレーシング）。

・脆弱性への対策

  • Webサーバプログラムのバージョン最新化とパッチ適用
  • 不要な機能やコマンドを無効にするか、使用可能範囲を制限
  • ディレクトリのアクセス権を適切に設定する
  • すべてのディレクトリにデフォルトページを置く
  • ディレクトリ参照を禁止する（デフォルトページを置かない場合）
  • クライアントに詳細なエラーメッセージを送らないよう設定する
  • HTTPヘッダにWebサーバプログラムの詳細情報を含めないように設定する
  • IPSを用いてOSやWebサーバプログラムの脆弱性を突いた攻撃を遮断する

・Webアプリケーションの仕様や実装による脆弱性と対策

ここではセッション管理に関するもの以外を示す。

・脆弱性の種類

  1. XSSの脆弱性により、クライアント環境で悪意あるスクリプトが実行されてしまう可能性がある。
  2. SQLインジェクションの脆弱性により、データベース上のデータが不正に取得、改ざんされたり、データベースが破壊されたりする可能性がある。
  3. OSコマンドインジェクションの脆弱性により、Webサーバ上で任意のファイルの読み出し、変更、削除、パスワードの不正取得などが行われる可能性がある。
  4. HTTPヘッダインジェクションの脆弱性により、クライアントに不正なデータが送られる可能性がある。
  5. メールヘッダインジェクションの脆弱性により、不正なメールが送信される可能性がある。

・脆弱性への対策

  • WebアプリケーションからDBサーバへのリクエスト処理にはバインド機構を優先的に用いる（SQLインジェクション対策）
  • ユーザからの入力データを処理するWebアプリケーションにおいて、入力データ中にスクリプトやコマンドとして意味を持つ文字が存在した場合には、HTMLを生成する際、もしくはコマンドを発行する直前に、エスケープ処理を行う
  • DBサーバ（RDBMS）の設定により、WebアプリケーションからDBに対するクエリを必要最小限の権限のみを持つアカウントで処理するようにする（SQLインジェクション対策）
  • Webアプリケーションの中でOSコマンドの呼び出しが可能な関数を極力使用しないようにする（OSコマンドインジェクション対策）
  • Webアプリケーションファイアウォールを用いてWebアプリケーションの脆弱性を突いた攻撃を遮断する。

Follow me!