i have no idea

I have no idea

bibouroku

やる気の出ない情報セキュリティ10 「Webセキュリティ」

Webセキュリティ

Webの基本的な構成要素

WebページはHTMLという言語によって、文書の論理構造を記述します。

Webにおけるデータ転送には、HTTPという通信プロトコルが用いられています。

Webクライアントは、HTTPを使ってWebサーバーからHTMLファイルや画像ファイルなどをダウンロードし、Webページのレイアウトを解析して、表示・再生します。(IE,Firefox,Google Chrome等)

Webサーバは、Webブラウザからのリクエストに応じて、HTML等で記載されたデータをWebページとして返信します。(Apache, IIS等)

Webアプリケーションサーバは、Webサーバに付随し連携するもので、Webクライアントからのリクエストを受け付け、「動的にWebページを作成するシステム」のことを指します。

f:id:yabicon:20210516012709p:plain
Webの基本的な構成要素

Webブラウザで静的なページを参照する際は、Webサーバ上にあるHTMLファイルがHTTP通信によりダウンロードされますが、動的なWebページを参照する際は、Webサーバを経由してWebアプリケーションサーバにより動的に生成されるWebページがHTTP通信によりダウンロードされます。
Webブラウザは、HTTPを利用して、Webサーバにユーザネームなどのデータをアップロードすることも可能です。

WebブラウザからWebアプリケーションサーバへデータを送信する際は、GETメソッドやPOSTメソッドを使います。
GETでは、URIの一部として送信するデータを末尾に追加する(クエリ文字列)という手法もあります。
( http://XXXXXXX/search.php?usename=taro みたいなかんじで)
セキュリティの観点からクエリ文字列を使うのはあまりよろしくないみたいです。


Webアプリケーションサーバは、Webブラウザユーザインタフェースや画面デザインを提供するソフトウェア(フロントエンド)と、DBMS(Data Base Management System)等のソフトウェア(バックエンド)、その中間に配置されてロジックと呼ばれるふるまいを記述したソフトウェアから構成されます。(3階層システム)

Webアプリケーションサーバーには、サーバー上で実装するCGI(Common Gateway Interface)、PHPJava ServletJSP(Java Server Pages)、ASP(Active Servcer Pages)や、
スクリプト(javascript, Flash, Java Applet)等のクライアント上で実行されるプログラムを配信するサーバも含まれます。

上で述べたように実現方式には、いろいろあります。
PHPでの実行方式と、javascriptでの実行方式を図で示します。

f:id:yabicon:20210516012749p:plain
PHP

f:id:yabicon:20210516012813p:plain
Javascript

Webにおける認証

認証している状態をWebサーバやWebアプリケーションサーバに伝える方法はいくつかありますが、
古典的な方法は、HTTPにおけるBasic認証もしくはDigest認証です。また、cookie(クッキー)なと呼ばれる技術を用いる方法があります。

  • Basic/Digest認証
    Basic/Digest認証は、認証が要求されるページにアクセスするたびに、WebサーバもしくはWebアプリケーションサーバにあらかじめ登録しておいたユーザ名、パスワードを
    Webブラウザからのリクエストの際のHTTPヘッダに埋め込む方式です。

  • クッキーを用いるセッション管理と認証
    クッキーは、ユーザーの識別やセッション管理などを行うための最大4キロバイト程度の情報です。

    クッキーは、Webアプリケーションサーバ上で作成された後、Webブラウザに発行され保存されます。
    そのあとのHTTP通信において、Webブラウザから当該のWebアプリケーションサーバへ アクセスする際には、毎回、このクッキーがHTTPヘッダに含まれた形で送信されます。

    Webアプリケーションサーバは戻ってきたクッキーを用いて、WebブラウザとWebアプリケーションサーバ間のセッションを管理することができます。
    クッキーを用いることで、WebクライアントとWebアプリケーションサーバとの通信で状態を持てるので、その状態に応じたWebページを動的に作成することができます。

    クッキーが第3者に漏れることで「なりすまし」をされる可能性があります。そのため、クッキーを用いて認証されたセッションを管理する場合は、SSL/TLSにより通信路を保護する必要があります。

    またクッキーにsecure属性を付与し、SSL/TLSで保護されたHTTP通信でしかクッキーを送信しないようにするようにすることが必要です。

XSS攻撃とその対策

Webアプリケーションサーバの実装における代表的な脆弱性のうちにXSS(Crosss Site Scripting, クロスサイトスクリプティング)があります。

XSSとは、動的にWebページを生成するWebアプリケーションサーバにおいて、利用者からの入力に対して必要な入出力チェックをしていないことが原因で、そのWebアプリケーションサーバ上で 悪意あるスクリプトが送信されてしまうこと、もしくは、その脆弱性のことをいいます。

XSS脆弱性を悪用すると、任意のスクリプトを被害者のWebブラウザ上で実行させることができます。XSS攻撃により、改変したページを閲覧させたり、入力情報を攻撃者のもとへ送信させるように 仕組んだりすることも可能になります。

XSS攻撃の最大の驚異の一つは、認証されたセッションの管理を行うクッキーを盗み出すことが可能になることです。

XSSの対策をしていないWebアプリケーションを考えます。ユーザーネームを入力すると、ユーザが存在するかどうかを調べ、結果を返すというシステムの場合、
ユーザーネームの入力部分にスクリプトを追加することで、XSS攻撃を仕掛けることができます。

f:id:yabicon:20210516012911p:plain
XSS攻撃の例


Webブラウザからのリクエストに含まれるスクリプトコードをWebアプリケーションサーバが元のWebブラウザに送り返すものを反射型XSS攻撃、

XSS脆弱性のあるサイトに攻撃用のスクリプトコードを埋め込んで置き、利用者をそのサイトへ誘導するタイプの攻撃を格納型XSS攻撃といいます。

XSS脆弱性は、静的なページでは基本的に起こりません。利用者がWebページを通して値を入力し、Webアプリケーションサーバが何かしらの処理をして出力する際に、発生します。
なので対策としては、入力チェック、エスケープ処理があげられます。

入力チェックでは、文字長や英数字であるかなどの判断を行います。
エスケープ処理は、「>」「&」などのメタ文字を「<」「&」などに変換させてしまうということです。
そうすることで、scriptのコードが実行させることはなく、そのままの文字列で表示されます。


SQLインジェクションとその対策

SQLインジェクションとは、Webアプリケーションサーバにおけるセキュリティ上の不備を悪用して、Webアプリケーションサーバの開発者が想定しないSQL文を構成して実行させることにより、 Webアプリケーションサーバ、もしくは接続されたDBMSを不正に操作する攻撃方法のことを言います。また、その攻撃を可能とする脆弱性を指す場合もあります。

SQLインジェクションが及ぼす脅威は以下の通り大きく3つあります

  • 機密情報の漏洩
    DBに含まれるデータがすべて抜き取られる可能性があります。アクセス制御が適切でない場合、DBMSが動いているサーバのファイルへのアクセスも可能となります。

  • 重要情報の改ざん
    DBをもとにしてWebページを作成している場合、DBやそこから作成されるWebページを攻撃者の意図通りに書き換えることが可能となります。
    DBやそこから作成されるWebページにウイルスやワームを埋め込むことがあります。

  • 認証処理のバイパス(不正な迂回)
    利用者からのIDとパスワードをDBと突き合わせることで認証を行っている場合、SQLインジェクションにより認証を回避することが可能となります。

SQLインジェクションの仕組みを見てみます。

① 利用者が検索したいユーザーネームとしてtaroを入力して検索ボタンを押すと、URIのリクエストが検索サイトであるWebアプリケーションサーバへ送信されます。
② それを受け取ったWebアプリケーションサーバは、クエリパラメータのusernameから検索する文字列であるtaroを取り出し、それを用いてSQL文を構成してバックエンドのDBMSに発行する
DBMSSQL文を実行し、検索結果を返信します。

f:id:yabicon:20210516012943p:plain
SQLインジェクションの例

SQLインジェクションではブラウザで入力する文字列をtaroではなく、taro ' or 'A' = 'A みたいに悪意あるコードを付け足します。

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

SQLインジェクション脆弱性の原因は、XSS脆弱性と同じように、攻撃者が、Webアプリケーションサーバの作成者が想定しない値を送信することにあります。

それにより、Webアプリケーションサーバの設計者の意図と違った動きをすることになります。
よって対策法は、SQL文を組み立てる際に、Webアプリケーションサーバの設計者が想定しない分にならないようにすることです。以下の方法があります

バインドメカニズムでは、Webアプリケーションサーバにおいて、利用者からの入力を埋め込んでSQL文を組み立てる際、プリペアドステートメント(準備されたSQL文) を使用します。プリペアドステートメントとは、各種プログラム言語に用意された値埋め込み用APIからなる、解析済みのSQL文のひな形です。

プリペアドステートメントはあらかじめDBMSに登録され、ユーザが入力した値は、SQL文としてではなく値としてDBMSに送信され、DBMSプレースホルダにバインドします。

f:id:yabicon:20210516013023p:plain
プリペア度ステートメント

エスケープ処理は、想定外のSQL文を構成しないようにエスケープ処理をすることにより、SQLインジェクションを防ぐ方法です。
ユーザが入力した値の特殊文字SQL文としてではなく、普通の文字列として送信されます。


CSRF攻撃とその対策

CSRF(Cross Site Request Forgeries)とは、攻撃者が用意したドメインのWebサイトの閲覧中に、Webブラウザの利用者の意図に関係なく、別のドメインのWebサイト上で何らかの操作(掲示板への書き込みなど)を行わせる攻撃のことです
被害例としては以下のようなケースが想定できます。

  • 会員制サイトの退会処理
  • 会員制サイトへの意図しない書き込み
  • Webインターフェースを持つ機器の設定変更
CSRF攻撃の仕組み

会員制サイトでは、認証を行うWebアプリケーションサーバにあらかじめ利用者のIDとパスワードが登録されています。
① 会員制サイトへログインし、ページを閲覧します
② ページを閲覧します
③ 会員制サイトからログアウトします。

CSRF攻撃では、会員制サイトとの間でセッションが張られた状態で、 攻撃者は、会員制サイト上で悪意あるアクションを引き起こす罠サイトのページに利用者を誘導します。
利用者が、会員制サイトにログインしたままの状態で罠サイトのWebページをダウンロードすると、会員制サイトでの不正な処理を行われる可能性があります。

f:id:yabicon:20210516013058p:plain
CSRF攻撃

CSRF攻撃を防ぐには、Webアプリケーションサーバー側で、当該のリクエストが利用者が意図したアクションによるものか否かを確認する必要があります。以下の対策方法があります。

  • リクエストに秘密情報を埋め込む
  • 利用者のアクションに対してパスワードなどの入力を求める
  • WebブラウザからのリクエストのRefererをチェックする

秘密情報を埋め込む方法

f:id:yabicon:20210516013120p:plain
秘密情報を埋め込む対策

パスワードを入力させる方法
CAPTCHAなどが使われます

f:id:yabicon:20210516013145p:plain
パスワードを入力させる方法

Web2.0技術のセキュリティ

Web技術は登場した当初から進化してきました。Web2.0技術とは、新しいWeb技術ということです。

従来のWebページは単純なHTMLによる情報構造のみで作成されていたため、脆弱性が入り込む余地はWebサーバかWebアプリケーションサーバだけになかったのですが、Web2.0では、 Ajaxに代表されるような高度な技術の集合体となっています。

それまでサーバ側だけの開発だったのが、Webブラウザ上のコードと合わせた開発が当たり前となり、特にクライアント側ではサーバ側とは異なる技術が注目される場合もあります。

結果としてサーバ側だけでなくWebブラウザ側にも脆弱性が入り込みやすくなっています。

さらにWebAPIと呼ばれる技術の進化によって、Webサイトの構築において様々な外部のサービスを利用することが一般化しました。
開発者にとって外部サービスという新たばブラックボックスが増えただけでなく、様々な要素技術が複雑に絡み合うことでWebセキュリティの範囲も広がりました。


Web2.0における特徴的なセキュリティの事例として、DOM Based XSSという脆弱性があります。

DOM Based XSS とは、DOM(Document Object Model)を通じたHTML操作の結果として、意図しないスクリプトが実行されることや、それを許す脆弱性を指します。
※ DOMとは、プログラム(スクリプト)からWebページの文書の内容や構造、スタイルに動的にアクセス・更新できるインターフェースのことを言います。

Ajaxなど、Webアプリケーションサーバと連携して、Webページを動的に更新する機能において、その脆弱性が入り込みます。
DOM Based XSS脆弱性は、JavaScriptによるWebページへの出力処理に不備があることが原因のケースと、JavaScriptライブラリに起因するケースとがあります。

例として、javaScriptのプログラムコードの中の変数dataに対して値を動的に代入し、document.write(data)というコードを使用するWebページへの攻撃について考えます。

ここで、document.write(data)関数は、呼び出されるとWebページのリロードなしで動的に追記されます。攻撃のためのスクリプトを含むデータが悪意のあるWebサイトからdataに格納され、それを契機にDOMを用いた攻撃が成立するといった可能性があります。

このようなDOMを用いることによるXSS攻撃をDOM Based XSSと呼びます。これは、Webブラウザ上で実行されるJavaScriptのプログラムコードの脆弱性です。
document.writeのほかにも注意が必要な関数があります。


同一生成元ポリシー

インターネット上で公開されているWebサイトのコンテンツを用いて自前のWebコンテンツを作成する手法(マッシュアップ技術)を用いたWebページが数多くあります。

マッシュアップ技術は単にリンク、iframeを用いたWebページの作成だけではなく、JavaScript、XHR(XMLHttpRequest)を用いたWebコンテンツの実現も特徴です。
※XHRは、JavascriptのHTTP通信機能で、標準的なブラウザに実装されているAPIの一つです。

XHRのコードが組み込まれたWebページの読み込み後、WebブラウザからXHRを用いて、HTMLなどのデータをWebアプリケーションサーバと送受信することができます。

XHRには一つ制約があって、それは同一生成元ポリシー(same origin policy )です。
これは、スクリプトを取得したドメイン(オリジン)と、オリジンと異なるドメイン(クロスオリジン)との通信を認めないという考えのことを指します。
これは一方が悪意のあるサイトの場合の攻撃を防ぐために定められます。

f:id:yabicon:20210516013230p:plain
同一生成元ポリシー

最近では、クロスオリジンの場合でも一定の条件の下で通信を可能とするXHR2という技術も利用されています。

やる気の出ない情報セキュリティ9 「ネットワークセキュリティ」

ネットワークセキュリティ

イントラネットの構成要素

インターネットとイントラネット(組織内のネットワーク)を分けて、インターネット側からの不正なアクセスを防ぐネットワーク機器に、ファイアウォール(FW)があります。
インターネットとの境界にはルーターが設置されますが、FWはその内側に設置されます。

イントラネットのセキュリティ機能を構成する機器はいろんなものがあります。

  • FW
    FWはネットワーク環境下において、ポリシーもしくはフィルタリングルールに基づき、パケットの通過・拒否・破棄を行うネットワーク機器もしくはソフトウェアです。
    OSI参照モデルにおけるネットワーク層トランスポート層に相当するパケットの通信を制御します。

    FWは、フィルタリング機能と監査用ログ機能が主に用意されています。フィルタリング機能では、宛先及び送信元のIPアドレス、ポート番号を用いてパケットを選別します。
    監査用ログ機能はそれらのパケットへの処置内容をログに保存する機能です。
    NATやNAPTの機能、VPNの機能を持つものもあります。

    また、VPNだけではなく、IDS/IPS等の機能をFWと一体化した、UTM(Unified Threat Management)と呼ばれるアプライアンスも登場しています。

    FWのフィルタリング機能では、パケットフルインスペクションという機能があります。これは、イントラネットからインターネットに出る通信に伴って、 インターネットからイントラネットに入ってくる通信用のポートを動的に開放・閉鎖する仕組みです。

f:id:yabicon:20210515205744p:plain
パケットフルインスペクション

  • 侵入検知システム(IDS)、侵入防御システム(IPS)
    通信路を監視し、攻撃パターンもしくはシグネチャ(攻撃の特長)のデータベースに基づいてネットワーク上の攻撃を検知するシステムのことを、侵入検知システム(IDS : Intrusion Detection System)といいます。

    IDSの機能に加え、検知したものを遮断する機能を持つシステムを、侵入防御システム(IPS : Intrusion Prevention System)といいます。

    IDS/IPSの検知方法は、シグネチャをデータベース化したものを利用する単純なパターンマッチングによる方式と、通常とは異なる状態を検知するアノマリ検知があります。

    また、設置体系によって、NIDS(Network IDS)、HIDS(Host IDS)があります。
    各ホストと独立して稼働して、ネットワークセグメント内のパケットを収集して不正を検知するタイプがNIDS、対象とするホスト上で稼働するタイプがHIDSです。

    IDS/IPSはOSやミドルウェアなどのプラットフォーム層を防御します。

  • WAF(Web Application Firewall)
    FWやIDS/IPSでは、近年増加しているWebアプリケーションサーバーに対するサーバーに対する攻撃は防ぐことができません。

f:id:yabicon:20210515205859p:plain
こんな時にはWAFだ!!

そこで登場したのがWAFです。WAFでは、Webアプリケーション層の通信プロトコルであるHTTP等の通信内容を分析し、SQLインジェクションクロスサイトスクリプティングといった攻撃を検知し、防御します。

Webアプリケーションへの攻撃は、Webアプリケーションサーバー側で対処する方法もありますが、Webアプリケーションサーバの開発とセキュリティを切り離したい場合等にWAFが導入されます。

  • VPN(Virtual Private Network)
    VPNは、接続するVPNサーバが設置されているネットワークと同じセグメントに、IPパケットをトンネリングする技術です。

    VPNを利用すると、VPNクライアントからVPNサーバー迄接続する回線が、あたかも専用回線であるかのように利用できるので、安全です。

    現在VPNには、インターネットを介して自前でVPNを構築するインターネットVPNや、プロバイダが提供するIP網を利用するIP-VPNの2種類があります。
    インターネットVPNは、インターネット網を経由し、IPsec等のプロトコルを利用してVPNを実現します
    IP-VPNは、プロバイダが独自に用意する閉域網を経由して、VPNを実現します。

  • ログサーバとモニタリング
    組織内のネットワークをリアルタイムで監視したり、一定期間ごとに解析して以上や攻撃を検出したりするために、ログ(記録)を取得します。

    ログのことを監査証跡(audit trail)ともいい、ログの取得を監査と呼ぶこともあります。
    ログメッセージをネットワークで転送するために。Syslogという標準仕様があります。

    様々な状況を監視し制御するためのプロトコルに、SNMP(Simple Network Management Protocol)があります。

  • 時刻同期サーバー
    複数のホスト間のログを解析して以上や攻撃を検出するためには、各ホストの時間が正確である必要があります。

    時刻の同期をとるためのプロトコルに、NTP(Network Time Protocol)があります。
    NTPを利用して正確な時刻情報を取得し、イントラネットの各ホストの時刻を合わせます。

  • DNS (Domain Name System)
    インターネット上のドメイン名に対応するIPアドレスを提示するシステムです。
    FQDN (Fully Qualified Domain Name)からIPアドレスを参照する場合を「正引き」、その逆を「逆引き」といいます。

  • メールサーバ
    電子メールを配信・受信するサーバです。SMTP(Simple Main Transfer Protocol)を用いて、目的地のメールサーバーに電子メールを配信します。
    SMTP(Simple Mail Transfer Protocol)を用いて目的地のメールサーバに電子メールを配信します。

  • Webサーバ
    組織の内外に向けて情報発信を行うサーバーです。動的なページを配信するWebアプリケーションサーバも含まれます。

  • Webプロキシサーバ
    HTTP/HTTPS通信で用いられるWebプロキシサーバは、イントラネットからインターネットへ接続する際に、データのキャッシュによる高速なアクセスや、フィルタリングによる安全な通信の確保等を目的とした中継サーバのことを示します。


FWを用いたネットワーク構成例

様々なものがあります

  • 公開サーバー群をFWの外に置く構成
    インターネットからイントラネットへの直接接続は一切禁止されます。
    外に置く公開サーバ群のセキュリティ強化が必要不可欠です。

f:id:yabicon:20210515205953p:plain
公開サーバ群をFWの中に置く構成

  • 公開サーバー群をFWの中に置く構成
    FWでフィルタリングルールを作ります。
    安全性は高まりますが、サーバーなどに万が一侵入を許すと大変です。

f:id:yabicon:20210515210050p:plain
公開サーバ群をFWの中に置く構成

  • 公開サーバ群をFWの別ポートに設置する構成(DMZ)
    インターネット、イントラネット、およびDMZを構成します。
    DMZは、インターネットとイントラネットの通信を直接行わずに各種サーバ群を経由するネットワーク構成とする際に、それらのサーバー群のネットワークセグメントをイントラネットと分離したものです。
    安全性は高まります。欠点をあえて挙げると、トラフィックが集中し、FWが単一障害店になることです。

f:id:yabicon:20210515210142p:plain
公開サーバ群をFWの別ポートに設置する構成

  • FWによって公開サーバ群を挟む構成
    2台のFWを用意し、その間にDMZを配置します。
    イントラネットとインターネットとの直接の通信は禁止し、DMZのサーバ群を経由させます。

f:id:yabicon:20210515210217p:plain
FWによって公開サーバ群を挟む構成


ネットワークスキャン

  • ドメイン情報の取得
    攻撃者は組織のネットワークを攻撃するにあたって、まず攻撃対象とする組織のネットワークに関する様々な情報を収集します。

    まず、ドメイン名登録情報検索サービスであるwhoisを利用して、攻撃対象組織のネットワーク管理者を割り出すことが考えられます。

    次にnslookupというコマンドを駆使して、攻撃対象とする組織のネットワークに関する情報の取得を試みることが考えられます。nslookupは、DNSへ接続し、FQDNからIPアドレスを取得するコマンドツールです。

    nslookupコマンドに対応するためにも、DNSサーバは以下のような運用をすることが望ましいとされています。

    • 不要な情報をDNSに保管しない
    • ゾーン転送を制限する
    • ドメイン名・サーバー名に必要以上の情報を与えない
    • 社外DNSは社内DNSに問い合わせに行かない。
    • 外部への問い合わせは社外DNSのみにする。
  • ホストへのスキャン
    攻撃者はドメイン情報をもとに、攻撃対象組織のネットワークの大まかな構成を獲得します。

    そして次は、各ホストに関する情報を収集し、特定のホストの攻撃に移ります。
    まず攻撃者は、ICMP(Internet Control Message Protocol)を用いたスキャニングを行うことが想定されます。
    そこで知りえたホストの存否に基づいて、対象とするホストに対してポートスキャンを実施します。攻撃者はOSやソフトウェアの情報を得て、脆弱性等を知ることができます。
    現在では、FWによってインターネット側からのスキャンは遮断されていることが一般的です。

    ICMPを用いたスキャンは、pingコマンドを用いて到達可能性を確かめます。
    また、traceroute/tracertコマンドを用いて、攻撃対象のネットワークセグメントの構成を取得する可能性もあります。
    なので外からのICMPやtracerouteが使用するUDP33434番ポートあてのパケットはFWで破棄する必要があります。

    ポートスキャンは、攻撃対象とするホストで稼働中のサービスを特定することを試みます。
    ホストのポートに様々なパケットを送信し、応答パケットを利用して稼働中のサービスを調査します。
    TCPスキャニングとステルススキャニングという手法があります。
    nmapコマンドでえ様々なスキャン方法が実装されています。

    ポートスキャン対策は、開いているポートへのアクセスをブロックすることが挙げられます。FWのフィルタリング設定を行います。
    また、不要なサービスを停止することも重要です。

  • パスワードの奪取
    ホストを特定した攻撃者が次に行うのは、パスワードのダッシュが考えられます。
    以下の3つのアプローチが考えられます。

    ブルートフォース攻撃は、利用者IDもしくはパスワードのいずれかを固定して、他方を無作為に総当たりで試す方法です。

    アカウント管理ファイルの奪取は、何らかの方法でOSの外部からアカウントを管理しているファイルを奪い取ることです。Windowsでは、SAMファイルに。Linuxではpasswordファイル等にアカウント情報が格納されています。
    ファイルはハッシュ値で保存されていますが、攻撃者は解読ツールにより解読します。

    ネットワーク上のパスワード奪取は、遠隔からログインを試みる利用者からパスワードを奪うことを指します。
    古い認証方式を使っている場合は、パスワードの解析を試みられる可能性があります。


セッションハイジャック

攻撃者は、イントラネットに侵入後、さらなる攻撃としてイントラネット内での通信を奪うことが想定されます。
正規の2者間の通信におけるセッションを乗っ取ることを、セッションハイジャックと呼びます。

セッションハイジャックの例としてARP Poisoning攻撃があります。
ARP Poisoning攻撃は、通信ホストのARPテーブルを攻撃者の都合の良いように書き換えて、正規の2者間の通信をすべて取得する攻撃です。

f:id:yabicon:20210515210311p:plain
ARP Poisoningをしちゃう


マルウェア対策

コンピュータウイルスやワームといったマルウェアの脅威は甚大です。基本的な対策は、セキュリティパッチをあてるなどした最新のOS、ライブラリ等を利用するということです。

コンピュータウイルスとは、プログラムなどに規制したり紛れ込んだりして、自分自身の複製を作成するプログラムであり、多くの場合、利用者に不利益をもたらします。
以下の機能を1つ以上有するとしています。

  • 自己伝染機能 : 自己を複製しほかのコンピュータに感染を広げる機能
  • 潜伏機能 : 特定の条件になるまで、活動を待機する機能
  • 発病機能 : 破壊等の活動を行う機能

ワームは、コンピュータウイルスとは区別されており、以下のような特徴を持ちます。

  • 単独で侵入、感染し、活動を行うプログラム
  • 攻撃対象のセキュリティホールを利用して侵入する
  • 宿主となるプログラムが必要なものは、ワームウイルスという。

ワームは単独で攻撃ができるってことですね。

そのほかにも、コンピュータを外部から操ることを目的として感染させるプログラムをボットといったり、 その他トロイの木馬とか、スパイウェア等のプログラムを総称してマルウェアと呼ばれます。

マルウェアはどんどん発展していって、ウイルス対策ソフトから検知されることを逃れようとしています。例えば以下があります。


コンピュータウイルス対策ソフトも進化していってます。
対策ソフトの手法には以下のものがあります。

  • コンペア手法
    マルウェアに感染する前のオリジナルのファイルの情報をあらかじめ取得して起き、検査においてオリジナルのファイルと比較して、差異があれば感染を疑うという方式です。
    ハッシュ値で比較するのは、チェックサム法と呼ばれます。

  • パターンマッチング手法
    パターンマッチング手法では、マルウェアの特徴情報を保存したデータベース(パターンファイル)を用いて対象となるファイルとパターンファイルの内容を比較してマルウェアを検知します。
    この手法では、パターンファイルを常に最新のものにしておく必要があります。

  • ヒューリスティック手法
    ヒューリスティック法は、検査対象のプログラムを実際のOS上で動作させずに検査する手法です。
    ウィルス対策ソフトの中で隔離された仮想マシンを起動し、そこで検査対象のファイルを実行する手法を動的ヒューリスティック手法といい、ポリモーフィックマルウェアとかでも検出できます。

  • ビヘイビア手法
    ビヘイビア手法は、実行しているアプリケーションプログラムをリアルタイムに監視し、「不正な動さを要求するシステムコールの実行」や「ファイルの不正な削除・変更の実行」を検出し、阻止する手法です。

やる気の出ない情報セキュリティ8 「ホストのセキュリティ」

ホストのセキュリティ

バッファーオーバーフロー

バッファーオーバーフローとは、プログラミング言語のCやC++アセンブリなどで作成されたプログラムに対し、入力の処理に関する バグを悪用することで、遠隔もしくはローカルから対象とするコンピュータのメモリに不正なデータや実行コードを書き込み、不正に権限を取得したりシステムへの侵入を引き起こしたりする事象もしくは脆弱性のことです。

コンピュータプログラムのほとんどは、プログラムの実行中、データを保存するための場所をメモリ空間上に確保します。
これらの連続した塊のデータの保存領域(スタック領域、ヒープ領域等)をバッファーと呼びます。

C/C++等のプログラムを実行する際、用意されたバッファーの容量を超えてデータを入れようとすると、メモリ空間上でバッファーの境界を越えて後ろに続く部分にそのデータが上書き されてしまうことがあります。これがバッファーオーバーフローです。

f:id:yabicon:20210515060406p:plain
バッファーがオーバーフロー

一般的にバッファーオーバーフローが起こると、プログラムが誤作動する等ですが、悪意を持った攻撃者がバッファーオーバーフローを悪用する場合には、プログラマの想定外の事象が起こりえます。

例えばバッファーオーバーフローを起こして、次に呼び出されるアドレスを指定することなどができれば、攻撃者が用意した悪意あるプログラムコードを実行させることができます


バッファーオーバーフローを用いた攻撃例

通常、攻撃者はバッファーオーバーフローを悪用して、そのコンピュータ上でshellコード等を実行することを目指します。攻撃例は大きく分けて以下の2つに分けられます。

  • ローカルでの攻撃
  • リモートからの攻撃

ローカルでの攻撃の目的は、高い管理者権限(root権限)の取得だといえます。
root権限でプログラムが実行されており、ローカル上でスタックオーバーフローを悪用する個音ができれば、root権限で悪意のあるshellコードを実行することができます
攻撃のターゲットとしては、ネットワークサーバープログラム(?)等が想定できます(管理者権限を用いてプログラムを使用する必要があるため)

f:id:yabicon:20210515060540p:plain
~root権限さえあれば~

リモートからの攻撃でも、目的の一つはroot権限の取得です。最終的な目的は、ターゲットのサーバープログラムを攻撃者が操作したり、マルウェアをダウンロードさせて実行させることです。
攻撃例を示します。
① バッファーオーバーフローを悪用するためのデータを送り込みます、またはターゲットとなるマシン側からダウンロードさせます。
② バッファーオーバーフローによりshellコードを実行させます。
③ 別に用意したサイトからマルウェアをダウンロードさせます
④ ダウンロードしたマルウェア本体を実行させます。

f:id:yabicon:20210515060614p:plain
リモート攻撃1

または、 ③ shellコードにより攻撃者のホストに接続し返します(connect-back)
④ 攻撃者は遠隔端末ツールを用いてターゲットのホストを操作します。

f:id:yabicon:20210515060645p:plain
リモート攻撃2

connect-backとは、対象のシステム側から攻撃者側へ接続させることを言うので、ファイアウォールなどでも、内側からの接続が制限されていない場合は、有効になります。


バッファーオーバーフローの詳細と対策

C/C++などによるプログラムの実行単位をプロセスといいます
プロセスが実行されているときのアドレス空間を見てみると、プログラムが実行されると、下位アドレスの「テキストセグメント」部分に実行コードが入ります。初期値を持つ静的変数とグローバル変数は「データセグメント」部分に入り、 初期値を持たない変数は、初期値0として、「BSS(Block Started by Symbol)」に入ります。

ヒープ領域には、Cのmalloc関数などで動的に確保された領域が入り、その上位に「共有ライブラリ」のコードがメモリマッピングされます。
最高位アドレス側から割り当てられる領域がスタックになります。

f:id:yabicon:20210515060728p:plain
メモリマッピング

スタックでは、プログラムのコードを順番に積んでいきます。(int a、等)
文字列変数をchar c[24]などでメモリを24しか確保していないところに、strcpy関数(文字列のコピー)で32バイトなどの文字列をc[24]に上書きするときなどに、 スタックオーバーフローが起こります。悪意のある利用で、リターンアドレスを書き換えたりされることもあります。

f:id:yabicon:20210515060812p:plain
プログラムのコードがスタックに積まれます


ヒープオーバーフローもありますが、簡単に悪用はできないとされています。
ヒープオーバーフローでは、あらかじめ確保していたメモリ領域をオーバーする際に発生します


バッファーオーバーフローを対策するには、まずバッファーオーバーフローを招く関数を使わないことです。

バッファーオーバーフローを招く可能性がある関数は、自動で境界領域をチェックすることをしないので、もし使う場合は、プログラマ自身が境界領域をチェックする必要があります。

他には、セキュリティパッチをOSやアプリケーションにあてること、C/C++などのアセンブリ以外のプログラミング言語を使うこと(Javaスクリプト言語は問題ない)、バッファーオーバーフロー対策機能が付くコンパイラを用いる等があります

ほかにもデータ実行防止(DEP)や、アドレス空間配置のランダム化(ASLR)等の技術があるらしいですよ。

セキュアOSとセキュアブート

セキュアOSとは、セキュリティ機能を強化したOS、及びその機能のことです。

セキュアOSの定義は主に強制アクセス制御(MAC : Mandatory Access Control)機能及び最小特権を実現する機能を実装したOSのことを指す場合が多いようです。

強制アクセス制御とは、操作する主体と操作される対象をそれぞれレベルわけし、それぞれのレベルに応じてシステムが強制的にアクセス権限を決定する方式です。
管理者がファイルシステムなどでアクセス制御をするのは、任意アクセス制御(DAC : Discretionary Access Control)といいます。

セキュアOSでは、プロセス実行時、最小特権機能により必要最小限しか権限が割り当てられないうえに、強制アクセス制御機能によって定められた範囲の行動しかできないので、攻撃された場合も、被害が拡大する可能性が低くなります。

セキュアOSの例として、Linuxでは、OSSSELinuxや、AppArmor、TOMOYO Linux等があるみたいです。


攻撃者の悪意の手はシステムコールなどのカーネル自体や、共有ライブラリを書き換える行為に及びます。このような技術をツール化したものをルートキットと呼び、広く普及しています。

攻撃者がルートキットのインストールを成功させてしまうと、セキュアOSでも対処ができなくなります。

そこで提案されたのがセキュアブートと呼ばれる技術です。これは、許可されていないOSやドライバーが起動時に実行されないようにする仕組みです。

セキュアブートは、ファームウェアとOS間のインターフェースの機能を定めたUEFI(Unified Extensible Firmware Interface)と呼ばれる使用の一部として規格化されており、 起動を許可するソフトウェアのハッシュ値等をUEFIモジュールに登録しておくことで実現されます。

UEFIが起動後にOSローダーを読み込み、マルウェア対策ソフトを読み込みます。この際、読み込まれるソフトウェアを、ディジタル署名などを用いて検証します。そのあとで各種ドライバを読み込み、アプリケーションを初期化します。

通常の起動ではOSローダーの後にドライバーが読み込まれますが、セキュアブートでは、検証を伴うためより安全な起動が実現できます。

f:id:yabicon:20210515060859p:plain
セキュアブート

やる気の出ない情報セキュリティ7 「セキュリティプロトコル」

セキュリティプロトコル

セキュリティプロトコルとは、

データを暗号化して通信するだけでは、通信のセキュリティは万全とは言えません。
暗号化だけではなく、なりすましや改ざんなどの脅威への対抗策を実現するための通信技術が必要となります。
それがセキュリティプロトコルです。
セキュリティプロトコルの例は、SSL/TLSIPsecSSHS/MIME等が挙げられます。

セキュリティプロトコルは、公開鍵暗号化方式、共通鍵暗号化方式、ハッシュ関数ディジタル署名といった要素技術を組み合わせることで実現されています。
よってセキュリティプロトコルを設計し実装するうえでは、要素技術と、それらをどう組み合わせるかという、2つの観点から安全性についての議論が必要です。

利用する要素技術の安全性については、要素技術の安全性が脅かされた場合、それを用いて構成されるセキュリティプロトコルの安全性も損なわれます。
また、安全な要素技術を用いたところで、それらを組み合わせる設計に間違いがあれば、セキュリティプロトコル自体の安全性は損なわれます。

SSL/TLS

SSLは、WebサーバとブラウザのベンダーであったNetscape社によって、主にWeb通信の安全性の確保を目指して設計・実装されました。
それにいろいろ改善を加えていったのがTLSとなります。
SSL/TLSは、TCP上でのセキュリティプロトコルとして、設計されてきました。が、IP電話などで利用されるSIP等でも利用できるようにUDP上でTLSを実現するDTLSなどが現在は策定されています。

SSL/TLSは、「Record」、「Handshake」、「ChangeCipherSpec」および「Alert」という4つのプロトコルから構成されています。

SSL/TLSを利用して暗号化された通信を行う際には、まずHandshakeプロトコルで通信相手とのセッションを確立します。
ここで、SSLクライアントとSSLサーバ間で、相手の特定、利用する暗号アルゴリズムの情報、通信データの圧縮方式の情報、暗号鍵の情報などを交換し、合意した状態を持つことを指します。
SSL/TLSの通信中は、セッションIDという識別子によって、セッションが一意に特定されます。

セッションを確立した後、ChangeCipherSpecプロトコルにより、平文の通信から、Handshakeプロトコルで合意した暗号アルゴリズムを用いて暗号通信に切り替えることを通知します。

SSLクライアントとSSLサーバ上で稼働するアプリケーションは、そのあと、Recordプロトコルを通して、アプリケーションデータのやり取りを通信相手と行います。

その間に何らかの異常が発生した場合には、Alertプロトコルによりその異常が通信相手に通知されます。

SSL/TLSは、TCP/IPで利用するので、SSL/TLSの通信に先駆けてTCPにおけるコネクションを張ってからSSL/TLSのHandshakeを行います。
暗号化された通信を行い、SSL/TLSの終了を行った後で、TCPの接続を終了します。

f:id:yabicon:20210515030448p:plain
SSL/TLSの簡易例

  • Recordプロトコル
    SSL/TLSのすべての通信は、送信するデータを最大214バイト以下に分割し、圧縮した後、暗号化などをして受信側に送ります。その手順を定義しているのがRecordプロトコルになります。
    送信側では、送信するデータについてMAC(Message Authentication Code)値を計算し、添付、Recordヘッダを追加してデータを送信します。
    Recordヘッダには、サイズ、SSLのバージョン、コンテントタイプ(メッセージの種類)の情報を含みます。

  • Handshakeプロトコル
    Handshakeプロトコルの目的は、保護するデータの送受信に必要な情報の共有状態を確立することです。共有状態とは、SSLサーバとSSLクライアントが、暗号鍵やアプリケーションデータの暗号アルゴリズムなどの情報(暗号スイート)を、お互い意図通りに等しく保持している状態です。

    SSL/TLSのHandshakeにはいくつかのバリエーションがあり、RSAやDSSを用いてサーバーを認証する「サーバー認証モード」と サーバとクライアントが相互に認証する「クライアント認証モード」などがあげられます。

    サーバー認証モードとは、SSLクライアント(Webブラウザ)がSSLサーバー(Webサーバー)を一方向で認証するものを言います。
    SSLサーバーからは、SSLクライアントが何者かわかりませんが、クレジットカードの情報などをサーバへ送信する場合においては、これでもよいといえます。
    Webサーバー側で利用者を認証したいときには、サーバー認証モードでのSSL通信路上でパスワードにより利用者を認証するBasic/Digest認証(apacheなどのWebサーバの機能)を行うか、 Webアプリケーションで認証(Form認証)を行います。

    RSAを用いたサーバ認証モードでは、ClientHello、ServerHello、Certificate、ServerHelloDone、       ClientKeyExchange、Finishedなどのメッセージを順番にやり取りして接続を行います。

f:id:yabicon:20210515030524p:plain
こんな感じで

クライアント認証モードは、SSLクライアントとSSLサーバーがHandshakeにおいて互いに認証するものを言います。
ただSSL/TLSでは、サーバー認証モードに比べると利用が多くありません。クライアントに証明書の提示を求めるので、一般的な利用者やWebサイトの管理者にとって負担が大きいからです。

  • 鍵の生成
    SSL/TLSで暗号化やMACに使う暗号鍵は、クライアントとサーバーがそれぞれ、Handshakeでやり取りした同じ素材から、同じ関数を使って作ります。
    このような鍵の生成に使う関数をKDF(Key Derivation Function)と呼びます。

  • DTLSの概要
    順番が入れ替わったり、パケットが通信中消えたりするUDP上でTLSをそのまま実現しようとすると、問題があります。

    • レコードの順番が入れ替わったり消えたりすると、MACのエラーとなり、通信が遮断される
    • Handshakeはメッセージが順序通りすべて届くことを前提としているのでHandshakeが成立しなくなる。

    そこでDTLSでは、UDPに対応するように変更を加えています。
    例えば、Handshakeの修正(確認用メッセージの追加、再送機能の追加)、レコードにシーケンス番号などのフィールドを追加 など
    また再送攻撃対策や、DoS攻撃対策もしているみたいです。。強い


IPsec

IPsecIETF(Internet Engineering Task Force)において策定されたセキュリティプロトコルです。
ホストやルーターといったゲートウェイに導入、設定することによって、ホスト間やゲートウェイ間のIP通信を安全にする技術です。
具体的には以下の機能を提供します。

  • アクセス制御
    セキュリティポリシーに従ったパケットのフィルタリング
  • データの完全性確保
    MAC(メッセージ認証コード)によるデータの完全性確保
  • データの送信元の認証
    MAC(メッセージ認証コード)によるヘッダを含めたパケットの真正性の確保
  • 再送攻撃の防御
    シーケンス番号を用いた再送攻撃の防御
  • DoS攻撃の防御
    ステートレスクッキーを用いた、送信元偽装パケットの判別
  • データの機密性
    データの暗号化による機密性の確保
  • トラフィック情報の機密性
    IPより上位の層のヘッダを暗号化することによる機密性確保

IPsecはIPパケットを暗号化するので、OSI参照モデルネットワーク層より上位の通信プロトコルを利用するアプリケーションソフトは安全な通信を利用出ます。

IPsecは、AH(Authentication Header)およびESP(Encapsulating Security Payload)という2つのプロトコルから主に構成されます。
AHはIPパケットの真正性と、IPパケットの完全性を確保します。
ESPは、IPパケットの機密性を確保します。

IPsecとともに使用されることが多いほかのプロトコルとして、IPComp(IP Payload Compression Protocol)やIKE(Internet Key Exchange)があります。
IPCompはIPsecパケットの圧縮に関するプロトコル、IKEはAHやESPに先立って行われる鍵の共有、および暗号方式などの合意のためのプロトコルです。
これらは組み合わせて利用することが多いので、AH、ESP、IPComp、IKEをまとめてIPsecと呼ぶ場合もあります。


IPsecでは、トランスポートモードとトンネルモードという2つの方式が用意されています。

トランスポートモードは、ホスト間で接続し、IPヘッダおよびペイロード部のセキュリティを確保します。

f:id:yabicon:20210515030620p:plain
トランスポートモードって普通

トンネルモードは、主にIPsecを実装したルーター(セキュリティゲートウェイ)間で、IPパケット全体のセキュリティを確保します。
トンネルモードでは、転送されるパケットにセキュリティゲートウェイが新たにIPヘッダを追加して、相手側のセキュリティゲートウェイに転送します。これでVPN(Virtual Private Network)を実現し、通信を保護します。

f:id:yabicon:20210515030658p:plain
最近よく聞くVPNですか?


IPsecの処理の概要

IPsecでは、単方向のコネクションごとに、AHのケース、ESPのケース、もしくはその両方のケースで、コネクションをそれぞれ確立します。
IPsecでは様々なパラメータを伴う一方向のコネクションのことをSA(Security Association)と呼んでいます。SAのパラメータには、暗号化アルゴリズム、暗号化カギ、IV、MACアルゴリズムなどが含まれます

  • IPsecの送信側処理
    IPsecパケットがホストやセキュリティゲートウェイから送信される際には、以下のような処理が行われます

    ① 対象となるIPパケットの始点IPアドレス、終点IPアドレス、上位層プロトコル、ポート番号などの情報(これらをセレクタという)に応じて対応する処理(セキュリティポリシー)を決めます。
    SPD(Security Policy Database)を検索して、「破棄」だった場合は、当該パケットを破棄します。「IPsecを適用しない」であった場合は、通常のパケット処理をします。 「IPsecを適用」であった場合は、IPsecの処理に進みます
    ③ 送信用SAD(security Assosciation Database)から該当するSAの情報を検索します
    ④ SADを検索した結果該当するSAがない場合は次に進みます。SAが存在する場合、SAに関する情報を取り出します。
    ⑤ IKEの利用が設定されている場合、IKEを用いて新しいSAを作成します。
    ⑥ 受信側のIKEモジュールとのネゴの後、SAを確定させます。AHとESPの両方を利用する場合は、ESPのSAのネゴを先に行い、AHのネゴを行います。確立したSAはSADに登録します。

f:id:yabicon:20210515030726p:plain
なんだこの図!?

  • IPsecの受信側処理
    IPsecパケットがホストやセキュリティゲートウェイで受信される際には、以下のように処理されます。
    ① 受信したIPsecパケットに含まれるSPI(Security Parameter Index)により、受信側用SADから該当するSAの情報を検索します。
    ② 該当するSAが存在しない場合、IPsecパケットを破棄します。該当するSAがある場合、次の処理に進みます。
    ③ 暗号アルゴリズムや暗号かぎの情報を取り出して、AH、ESPの受信処理を行います。
    ④ IPパケットの始点IPアドレス、終点IPアドレスなど(セレクタ)を検索キーとして、受信側用SPDからセキュリティポリシーを検索します。 選択して得られたセキュリティポリシーの内容と、適用されていたIPsec処理の内容が合致していることを確認します。

f:id:yabicon:20210515030759p:plain
難しいね。よくわかんないです


  • AH
    AHはIPsecパケットの送信元の真正性と完全性を確保するプロトコルです。
    ICV(Integrity Check Value)と呼ばれるMAC(メッセージ認証コード)を用いて転送パケットの送信元の真正性と完全性を確保します。
    AHの処理ではICV値をAHヘッダに埋め込みます。

f:id:yabicon:20210515030841p:plain
AHヘッダを付与 しちゃうぞ

  • ESP
    ESPは、IPsecパケットの機密性を暗号化によって確保するセキュリティプロトコルです。オプションで、IPsecパケットのメッセージ認証(MAC)の機能も提供します。
    ESPのメッセージ認証機能は、AHと同じ手法が採用されており、メッセージ認証機能を有効にすると、パケットの真正性と完全性を確保できます。

f:id:yabicon:20210515030908p:plain
ESPヘッダ付けたらお尻に変なのがついてきたゾ

  • IKE
    IPsecによる通信は、SA単位で行われますが、IPsec SAが管理する情報には、暗号化アルゴリズムなどのIPsecのセキュリティに関する情報もふくまれます。
    同じIPsecSAを長時間使い続けることは安全性が不安です。そこで、「相手の認証」および「共有秘密鍵(セッション鍵)を含むSAのネゴシエーションと管理」を自動行うプロトコルがIKEとなります。

やる気の出ない情報セキュリティ6 「PKI(公開鍵暗号基盤)」

PKI

会社で情報セキュリティをやることになったので、勉強がてらメモ
文献は「マスタリングTCP/IP 情報セキュリティ編」

PKIの基礎

PKI(Public Key Infrastructure)とは、「公開鍵暗号基盤」と呼ばれます。
PKI公開鍵暗号化方式やディジタル署名といった技術を組み合わせて利用する複合技術のフレームワークです。
インターネットなどのネットワークにおいて公開鍵の配布をするうえで有効な手段となります。実装例にはHTTPS等があります。

  • PKIが必要となる理由
    インターネットを使って、Webページにアクセスするようにするためには、公開鍵を配布する必要があります。
    しかし、実際の運用では公開鍵を安全な方法で配布することが必要となってきます。
    電子メールなどに添付して公開鍵を送る手法では、間で攻撃者によって情報が盗まれた場合に問題となってきます。なので、公開鍵のすりかえなどを防止するためにもPKIが必要となってきます。

トラストモデル

誰かが本物であるかを確認する仕組みには、様々な様式があります。そのような信頼のための様式をトラストモデルと呼びます。
インターネットなどの公開鍵を配布する際に、公開鍵の所有者を確認する仕組み、には以下の2つのトラストモデルがあります

Web of Trust モデルは、公開鍵の所有者を、自身が信頼できる人物に保証してもらう仕組みです。
RFC 4880によって策定されているOpenPGPという規格に準拠したソフトウェアで採用されています。
Web of Trustモデルは、個人レベルでの信頼関係がベースとなり、全体を集中して管理する主体が存在しないので、企業などの組織での運用に適用することは難しい場合もあります。
ですが、全体を集中して管理する主体が存在しないことは、利点として考えられることもできます。

f:id:yabicon:20210511222306p:plain
Web of trust モデルの例

認証局モデルでは、Web of Trust モデルとは違い、全体を集中して管理する主体を用意します。
信頼できる第三者機関(TTP)に、公開鍵の所有者を保証してもらう仕組みです。
TTPは、公開鍵の所有者の本人性を確認し、公開鍵とその所有者を証明する情報を持つ証明書(公開鍵証明書)を発行します。改竄を防ぐためにTTPの署名も施されます

f:id:yabicon:20210511222345p:plain
認証局モデルの例

公開鍵証明書

証明書には、公開鍵とその所有者を証明する公開鍵証明書(public key certificate)や、公開鍵証明書で証明された人に対して所有する権限や役割を証明する属性証明書(attribute certificate)があります
一般的にPKIでの証明書は公開鍵証明書のことを言います。


公開鍵証明書の標準フォーマットとして、ITU-Tが策定したX.509証明書があります。
証明書は、主に以下によって構成されます。

  • 署名前証明書(tbsCertificate)
  • 署名アルゴリズム(signatureAlgorithm)
  • 署名値(signatureValue)

証明書の所有者、公開鍵の有効期間等の情報は、「署名前証明書」に記載され、署名前証明書に対する署名が、「署名アルゴリズム」によって施され、その値が「署名値」となります。
署名前証明書にはそのほかにも拡張領域があって、鍵の利用目的やポリシー等を含めることができます。

Youtubeとかでは、こんな証明書がみれますね... !

f:id:yabicon:20210511214335p:plain
youtubeの証明書

認証局

PKI認証局モデルでは、TTPである認証局によって発行された証明書を用いて、公開鍵の安全な配布を実現しています。

PKIを構成する主体には、以下のものがあります

  • 認証局(CA Certification Authority)
    認証局は、証明書利用者や証明書所有者に対して、公開鍵とそれに対応する秘密鍵の所有者を対応付ける証明書を発行します。また、発行した証明書の信頼性が失われた場合、その証明書を 失効させ、執行情報を載せたCRL(証明書失効リスト)を発行します。
    さらに、証明書と証明書失効リストを、証明書利用者が取得できるように後述のリポジトリに公開します。

  • 登録局(RA Registration Authority)
    主として登録業務を行う機関で、証明書所有者から証明書の申請がなされたとき、申請者の本人性の審査・確認を行います。
    認証局に対して証明書の発行や執行を要求します。

  • リポジトリ
    証明書及び証明書失効リストを格納し、証明書所有者や証明書利用者へ公開します。

  • 証明書所有者
    証明書が発行される主体を指します。証明書では、主体者(subject)や加入者(subscriber)と呼ばれます。
    証明書及び対応する秘密鍵を用いて、暗号文の複合や電子文書への署名を行います。

  • 証明書利用者
    証明書所有者の証明書を入手し、それを利用してデータの暗号化や署名の検証を行う主体です。

f:id:yabicon:20210511222418p:plain
認証局モデルの例2

認証局は、運営形態により2種類に分類できます。

  • パブリック認証局
    公的な位置づけという意味です。パブリック認証局が発行する証明書の一部は、一般的なOSやWebブラウザにあらかじめ同梱されているケースがあり、その場合は証明書の配布やインストールが不要です
    パブリック認証局は、その運営ポリシーを、証明書ポリシー(CP Certificate Policy)または、認証業務実施規定(CPS : Certification Practice Statement)として公表しています。
    認証局がどのような目的であるのか、証明書失効リストの更新頻度、設備の安全性に関することも記載されます。
    パブリック認証局を運営する会社は、COMODO社、GlobalSign社、VeriSign社など多数あります。

  • プライベート認証局
    企業や組織内で独自の運用基準を設けて設立し運営する認証局です。
    証明書の配布や設定などに手間がかかりますが、運用規定を組織の中で自由に設定できるため、限られたネットワークの半家で証明書を利用する場合は、プライベート認証局を設立し電子証明書を発行するほうが便利であることもあります。


登録局における厳格な認証プロセスを経て発酵されるEV SSL証明書というものもあります。
EV SSL証明書を発行する認証局は、認証プロセスなどがガイドラインに従って正しく運営されているか、1年ごとに外部監査を受けます。

EV SSLでは、会社名がアドレスに表示されます。

f:id:yabicon:20210511220046p:plain
こんな感じ EV SSL

証明書の利用

HTTPSにおける証明書の利用例
HTTPS通信において、認証局が発行する証明書は、その利用形態によって以下の3種類に分類できます

サーバ証明書はサーバを識別するための証明書で、SSL/TLSサーバーが証明書のSubject(証明書所有者)となります。なのでSSLサーバ証明書とも呼ばれます
サーバー証明書には、Webサイトの所有者の情報、SSL/TLS通信における暗号化に必要な公開鍵などの情報を含み、認証局によって署名されます。
HTTPS通信におけるサーバ証明書の主な目的は、証明書に示されたWebサイトのFQDNが含まれる公開鍵の所有者であることを証明することです。
サーバ証明書とその秘密鍵は、Webサーバの稼働するOS上で管理されます

クライアント証明書はクライアントを識別するための証明書で、クライアント(Webブラウザ、ユーザ、端末等)がSubject(証明書所有者)となります。
HTTPSで利用するケースでは、SSLサーバがクライアントを認証するときに使います。
クライアント証明書とその秘密鍵Webブラウザなどにインストールして利用することが多いです。

ルート証明書は、各種証明書を発行する認証局が、発行する証明書の署名の正当性を示すために自ら署名して発行する証明書のことです。
認証局が自らの秘密鍵で署名することから、自己署名証明書とも呼びます。
ルート証明書は、SSL/TLSサーバ及びWebブラウザ、もしくはそれらのOSにインストールします。
ルート証明書の正当性により認証局が信頼の起点となり、それにより、サーバー証明書およびクライアント証明書の真正性を検証できます。

f:id:yabicon:20210511222510p:plain
HTTPSの例


PKIの運用

証明書の運用という観点からPKIを見ると、「証明書の発行」「利用の際の検証」そして「失効の確認」という一連の流れであるといえます

  • 証明書の発行
    証明書を必要とする主体は、公開鍵暗号化方式における公開鍵ペアを作成します。
    次にCSR (Certificate Signing Request)を作成し、それを証明書発行機関に提出します。その際登録局で本人性を確認します CSRには署名前証明書の情報が含まれます。
    登録局は、提出されたCSRとともに本人性の確認後、認証局CSRを提出します。認証局は、認証局の署名をして、証明書を作成します。
    発行された証明書は、証明書所有者に私、認証局を通して配布されます。

    f:id:yabicon:20210511222535p:plain
    証明書の発行の流れ

  • 証明書の検証
    証明書があっても、公開鍵が真正か確かめなければ、中間者攻撃によって証明書をすり替えられる可能性があります。ので、検証が必要となります。
    証明書を信頼できる認証局が発行したものであるということを、認証局が発行したルート証明書を検証して、確かめることができます。

  • 証明書の失効
    証明書は有効期間内であっても、以下のような事象があったときに証明書を破棄する必要が生じます

    • 証明書に含まれる公開鍵に対応する秘密鍵が紛失もしくは漏洩した場合
    • 証明書に記載した事項が変化したなどの場合

    証明書が失効したことを知らしめる手段には、「CRLモデル」「OCSPモデル」の2つの方式があります。

    CRLモデル
    認証局が失効された証明書のリストを定期的に公開する方式です。このリストのことを証明書失効リスト(CRL : Certificate Revocation List)と呼びます。
    証明書失効リストには、失効した証明書のシリアル番号、発行日時などを掲載し、署名を施します。
    CRLモデルはややリアルタイム性に欠ける仕組みでありますが、非常にシンプルで使いやすい手法となります。

    OCSPモデル
    OCSP(Online Certificate Status Protocol)モデルは、証明書の正当性をリアルタイムで確認するプロトコルのことです。
    証明書の失効情報を保持したサーバ(OCSPサーバ)が。証明書利用者からの証明書の失効情報の問い合わせに対して、指定された証明書について応答を署名付きで返すというものです。

やる気の出ない情報セキュリティ5 「認証技術」

認証技術

会社で情報セキュリティをやることになったので、勉強がてらメモ
文献は「マスタリングTCP/IP 情報セキュリティ編」

認証技術は大事そうなので、頑張っていきたいところ。
Authとかよくいわれてますよね。それが全然わかんなくて、知ったかぶりをしています。

認証技術の基礎

「誰」に「どの」情報、リソースにアクセスさせるのかをあらかじめ決めておくことが重要です。
「誰」にアクセスさせるのかを決めて、確認することを「認証(Authentication)」
「どの」情報、リソースにどのようにアクセスさせるのかポリシーを決めることを「認可(Authorization)」といいます。
実際に作成したポリシー(ACL(Access Control List))にしたがってアクセス制御等を行います。

認証で一番身近なものは、IDとパスワードを用いるパスワード認証です。 サービスを使うときには誰もが使用するものであると言えますよね。
目の前のPC等にログインする際、パスワードは単純に目の前のPCに保存されます。が、
Amazon等のWebサービスの場合は、パスワードに対する脅威に対して、 注意を払う必要があります。それらへの対策をした認証を、認証プロトコルによる認証といいます。

認証

認証の実現方式には、以下の3つのカテゴリーがあります。

  • 主体の知識による認証
  • 主体の所持するものによる認証
  • 主体の身体的な特性による認証
    これらのカテゴリーを複数使って認証を行うことを、2要素認証、多要素認証と言ったりします。

主体の知識による認証は、パスワード認証、PIN(Personal Identification Number)を用いたものが上げられます。
パスワードデータは、認証する側のシステムにハッシュ化されて保存されます。パスワードが同じ人がいる場合の対策として、 UNIX OSでは利用者ごとに、塩(salt)という乱数値を用意し、それと併せてハッシュ化したりします。おいしそうですね。

Windows方式では、LM(LAN Manager)方式、NTLM方式という認証方式があります。NTLM方式では、大文字小文字の区別があったり安全性が高いのでそっちのほうが推奨されます。
パスワードクラックツール等が数多く存在するので、気をつけましょう。パスワードは単純な単語等にしないようにしなければ。

他にもよく使用される手法にワンタイムパスワード(OTP)があります。
ワンタイムパスワードは認証の際に一度だけ使用されるパスワードになります。
これはPFS(Perfect Forward Secrity)という、攻撃者に情報が奪われても、影響が少ないという考えを実現しているみたいです

ワンタイムパスワードシステムの代表格には、ハッシュ関数みたいな一方向性関数を用いたもの、時刻同期型のもの、2つがあります(むずかしいので詳細は省く)。
AWS等のMFAに使うGoogleの認証アプリみたいなやつは、時刻同期型に入るんですかね。。。?


主体の所持するものによる認証は、ICカード等の物理的デバイスを利用するものです。
ICチップにいろんな情報が記録されています。ICチップすげぇ。。

物理的デバイスは、紛失や盗難の可能性があるので、カードを拾った人が勝手に利用できないように、利用時にPIN等を打ち込むことで対策をします。


主体の身体的な特性による認証では、指紋や虹彩などを用いたものがあります。(生体認証・バイオメトリクス認証

指紋認証は、意外と低コストで実装でき広く普及されていますが、けがなどのトラブルへの対応が難しいことや、樹脂などを使って偽装ができてしまうこと等のデメリットがあります。

虹彩や静脈パターンなどを用いた認証も注目されています。

生体認証は、忘れることやなくすことへの心配がないですが、複製されると変更が難しいことなどが問題点として挙げられます。
また、他人を本人として受け入れてしまう「他人受け入れ」や、本人を拒否してしまう「本人拒否」が問題となり、評価指標としてこの2つの精度を評価するみたいです。


認証プロトコルの基礎

インターネット等の通信路での認証は、以下のような脅威が考えられます。

  • 盗聴
  • 改ざん、ハイジャック
  • なりすまし(スプーフィング)
  • 捏造
  • 再送

それらの脅威に対応するには、認証だけではなく暗号技術などを使う必要があります。そのために必要な複雑な手順を認証プロトコルといいます。

サーバとクライアント間のパスワード認証を考えたとき、まず平文でIDとパスワードをやり取りすることは、安全ではありません。盗聴されたりする恐れがあります。
なので、IDとパスワードをハッシュ関数でハッシュ化してやり取りするという考えがあります。

攻撃者はIDとパスワードはわかりませんが、ハッシュ化された値を盗むことで、次からそのハッシュ値を使って簡単にログインできてしまいます。(再送攻撃)

そこでさらに改善し、認証の際にサーバから毎回変わる乱数をクライアントに送信して、それをハッシュ値に含めるという考えがあります。(Challenge/Response方式)

毎回、変わる乱数値を使うことで、再送攻撃ができなくなります。IDパスワードも盗まれることはありません。これで安全な認証となります。(Challenge/Response認証と呼ばれる、CHAP(Challenge Handshake Authentication Protocol)と呼ばれることもある)

f:id:yabicon:20210511211049p:plain
Challenge/Response認証

一方向に認証するものであると、偽サーバにつながれる可能性もあるので、相互にChallenge/Responseで認証するという方法もあります


公開鍵のペアを用いて認証プロトコルを実現することもできます。認証に使う情報を相手の公開鍵で暗号化して送付する方法と、自分の秘密鍵ディジタル署名して送付する方法の、2つが考えられます。

サーバとクライアント間の相互認証を考えたとき、Challenge/Responseと同じように、クライアントが乱数を生成して、乱数とメッセージを相手の公開鍵で暗号化します。サーバは自分の秘密鍵で復号して 相手(クライアント)の共通鍵で暗号化したメッセージを返すといった内容となります。

f:id:yabicon:20210511211133p:plain
共通鍵を使うChallenge/Response

ディジタル署名を使って認証することもできます。ディジタル署名を用いた方法だと、メッセージが第3者に読み取られる可能性がありますので、DH鍵共有アルゴリズムを使用します。。。

ID連携

ID連携は、利用者のID情報及びそれに付随する属性情報を、別々のITサービス間で、連携して交換する仕組みのことを言います。
つまり、一つのIDでいろんなITサービスが使える用にする仕組みのことを言います。Twitterのアカウントでいろんなサービスを連携できるみたいな感じ?

複数のサービスに対して、各々のアカウント情報を入力してログインするのって不便ですが、それを解消するのにID連携を用いたシングルサインオン(SSO)というものがあります。
SSOでは、一つのサービスにログインすると、ほかの連携しているサービスでも一定時間ログアウトせずに認証操作なしに利用できるようになるというものです。

同様なことを実現する手段としては、各サーバのアカウント情報を同期させたり、LDAP(Lightweight Directory Access Protocol)を用いた認証や、Radiusを用いた認証を行う方法もありますが、 この方法では、各サーバにログイン作業が発生します。

そこで出てきたのがSSOです、SSOにもリバースプロキシ方式や、エージェント方式等が実現方式として挙げられていましたが、異なる組織をまたいだSSOの実現などは困難でした。
そこで出てきたのがID連携という技術です。

ID連携に基づくSSOの基本的な考え方は、連携する組織間であらかじめ連携のための情報を交換して置き、ある組織のITサービスにログインすると別の組織のITサービスも利用できる用にするというものです。


ID連携の標準技術には、主流なものとして、SAML(Security Assertion Markup Language)とOpenIDがあります。どちらもOSSです(誰でも使える)

SAMLは認証認可のプロトコルと、そこで利用する情報の表現についての標準仕様です。
じっそうには、ShibbolethやOpenSAMLというものがあるらしいです。

SAMLでは認証情報の交換によって、連携するWebサービス間での安全なSSOを実現することができます。また、2つのタイプの認可が実現されています。
1つめは属性情報(Authorization Assertion)の交換によるもの。2つめはアクセス制御情報(Authorization Decision Assertion)の交換によるものです。Assertionは利用者の認証情報、属性情報、リソースに関する認可権限情報のことを指します。

SAMLの構成要素には以下があります

  • IdP(identity Probider)
  • SP(service Provider)
  • トラストサークル
  • メタデータ
  • Name Identifier

具体的にやり取りされるメッセージ(SAMLリクエスト、SAMLレスポンス)はXMLアサーションという形で実現されます。

SAMLを用いたSSOのシーケンスには2種類あります。WebブラウザによるSPへのアクセスをトリガーとするもの、IdPへのアクセスをトリガーとするもの

SPへのアクセスをトリガーとするものの実施例
① 利用者がSPへアクセスする
② SPはSAMLリクエストを生成、IdPへHTTPリダイレクトします
③IdPはSAMLリクエストを検証し、利用者を認証します
④ 利用者が認証に成功すると、IdPはSAMLレスポンスを生成し、SPに転送します
⑤ SPはSAMLレスポンスをもとにアクセス制御を行いサービスを展開します。

f:id:yabicon:20210511211239p:plain
SAML

OpenIDは、インターネット上の様々なWebサイトにおける認証を一つのIDで実現します。
URL形式のIDを用いているのが特徴です。。。
認可を目的としたOAuthの機能を含めた次世代版としてOpenID Connectがあります。

構成要素には以下があります

  • OP(OpenID Provider)
  • RP(Relying Party)
  • User-Supplied Identifier
  • Claimed Identifier
  • OpenID AX(Attribute eXchange)(拡張仕様)

OpenIDを用いたSSOは以下の手順です
① 利用者はRPにアクセスし、User-Supplied Identifierとして、CClaimed Identifierを入力するか、OPIdentifierを入力します
② RPは、利用者より入力されたUser-Supplied Identifer からOPを決定し、アクセスします。
③ RPはDH鍵共有アルゴリズムを用いて、OPと暗号鍵を共有します。この暗号鍵はメッセージへの署名に使用されます
④ RPは利用者をOPにリダイレクトして認証を要求します
⑤ OPは利用者を認証します
⑥ OPは認証結果と利用者の情報をRPへリダイレクトします。
⑦ 認証が成功した場合、RPは利用者にサービスを提供します。

f:id:yabicon:20210511211302p:plain
OpenID

やる気の出ない情報セキュリティ4 「暗号技術~公開鍵暗号化技術~」

会社で情報セキュリティをやることになったので勉強がてらメモ
参考書籍は「マスタリングTCP/IP 情報セキュリティ編」

公開鍵暗号化技術

公開鍵暗号化技術の代表はRSAと呼ばれるものがあげられます。

公開鍵暗号化技術では、公開鍵と秘密鍵を用います。   公開鍵は、鍵の生成者が多くの人に配布するもので、それを用いて暗号化するための暗号化鍵となります。
秘密鍵は、公開鍵で暗号化された暗号文を復号できる唯一の復号鍵です。所有者がこっそり管理するので秘密鍵と呼ばれます。

RSAとは

RSAは巨大な数の素因数分解が困難なことを安全性の根拠とした暗号化アルゴリズムです...(?)
RSAでは次の手順により公開鍵ペアを生成します。
① 大きな素数pとqをランダムに選びます。
② n=pqを求めます(nの長さが鍵長となります)
③ (p-1)(q-1)と互いに素な正の整数eを選びます。
④ ed = 1 (mod (p-1)(q-1)) となる正の整数dを求めます。
⑤ 公開鍵(暗号化鍵)として、eとnを公開します
⑥ dは秘密鍵として、安全に管理します。pとqは破棄します。

(暗号化) C = Me mod n
(復号) D = Cd mod n

復号演算は、鍵の生成時に利用した素因数p,qを知らないと演算するのが困難らしいです。
よくわからないので、必要になったときに理解しましょう!

RSA以外の公開鍵暗号化方式には、エルガマル暗号や楕円曲線暗号(ECC)といったアルゴリズムが利用されています
エルガマル暗号は、離散対数問題の困難さを安全性の根拠としたもので、楕円曲線暗号は、楕円曲線状の離散対数問題の困難さを安全性の根拠とした暗号技術です。
(ちんぷんかんぷんですが、数学的に立証が困難な問題を安全性の根拠としているんですね。。。)


また、公開鍵暗号化技術は、ディジタル署名でも使われており、それで利用可能なDSA(Digital Signature Algorithm)等のアルゴリズムがあります。

RSA共通鍵暗号化方式と比較すると処理速度が遅いので、一般的には暗号化したい平文はAES等の共通鍵暗号化方式で暗号化し、その暗号化鍵をRSAで暗号化する。 ハイブリッド暗号と呼ばれる方式がとられることが多い見たいです。

鍵共有アルゴリズム

ハイブリッド暗号方式も暗号鍵を安全に共有する仕組みですが、ほかにも鍵を共有するアルゴリズムがあります

Diffie-Hellman鍵共有アルゴリズム (DH鍵共有アルゴリズム) は、盗聴者がいることが想定されるインターネット等の通信路で、暗号化鍵を交換するための技術です。
SSL/TLSIPsec等でも利用されています。

DH鍵共有アルゴリズムをインターネットで利用する際は、中間者攻撃(MITM攻撃)攻撃に対して脆弱であることを知り、メッセージにディジタル署名を施すなどの対策する必要があります。

f:id:yabicon:20210511193703p:plain
DH鍵共有アルゴリズム

ハッシュ関数ディジタル署名

ハッシュ関数とは、任意の長さのデータを固定長のデータに圧縮する関数hashのことを指します。以下の性質を持ちます

  • 一方向性
  • 第2現像計算困難性
  • 衝突困難性

一方向性は、出力値から入力値を算出するのが困難であるということです。

第2現像計算困難性とは、同じハッシュ値となるような別の入力を求めることが困難であるということ

衝突困難性とは、同じ出力値を生成する2つの入力値を発見することが困難であるということです。


ハッシュ値はメッセージダイジェストとかフィンガープリントとも呼ばれます。
ハッシュ関数は、基本的に、任意の長さのメッセージを決められた長さへと拡張し、それを入力として非線形関数などで構成される処理を複数のラウンドにわたって繰り返すという処理を行っていて、
MD4、MD5、SHA、SHA-1、SHA-2、SHA-3等の種類があります。SHA-3以外はすでに安全性が疑問視されているので利用を避けることになってます...!

情報セキュリティではハッシュ関数は秘密情報の保存や、改ざんの検知で利用されます。

f:id:yabicon:20210511193739p:plain
ハッシュ関数でパスワードを保存するおとこ


ディジタル署名とは、メッセージに対するハッシュ値秘密鍵で暗号化し、メッセージの改ざん検知、及び否認防止を実現する仕組みのことです。

ディジタル署名の流れ
① 署名者(文書作成者)は公開鍵Pと秘密鍵Sを用意し、公開鍵を署名の検証者に安全に渡しておきます。
ハッシュ関数を用いて、送信したい平文Mのハッシュ値Hを求めます
③ 署名者は、あらかじめ用意しておいた秘密鍵Sを用いて、ハッシュ値Hを暗号化します。→署名値Hs
④ 平文であるメッセージMと署名値Hsをセットで検証者に送ります。
⑤ 検証者は平文Mからハッシュ値H'を求めます。
⑥ 署名者の発行した公開鍵Pを用いてHsを復号し、ハッシュ値Hを求めます。
⑦ 検証者は、署名から求めたハッシュ値Hと、メッセージMから求めたH'が一致するかどうかを確認します
⑧ 一致した場合、メッセージMは署名者によって作成されたことを確認できます

f:id:yabicon:20210511193823p:plain
ディジタル署名

ディジタル署名では、公開鍵暗号化方式として何を使い、ハッシュ関数として何を使うかで、組み合わせがいくつか想定できます。

暗号技術における安全性

様々な異なる種類の暗号技術に対して、同一の尺度で安全性を評価するために、等価安全性という概念がNISTによって定義されています
各暗号技術に対して、最も効率的な攻撃を行った際に、解読に必要となる計算量を評価値とします。(計算量が2xの場合、xビット安全性)

また、暗号アルゴリズムがどんなに協力でも、利用する際に何らかの誤りがあると、簡単に解読されてしまうケースもあります。

  • 独自に発明した暗号アルゴリズムを使用してはいけません。できるだけ安全とされている暗号アルゴリズムを選定します
  • 安全性を損なう可能性があることを考慮して設計する。鍵長128はでかいから64でええやろ。。とかはしない
  • 実装のみすで安全性が損なわれる可能性があることを考慮する。

アルゴリズムの安全性だけでなく、設計、実装の安全性を考慮します。