ARP・RARP
Address Resolution Protocol。アドレス解決プロトコル。
- 仕組み
- ARP要求パケット
ブロードキャストで送られる。（同一セグメント内に送られる。ルータで遮断される）
つまり、同一セグメント内の全てのホストやルータがARP要求パケット解析する事になる。
- ARP応答パケット
ARP要求パケットを受け取り、そのIPアドレスのホストは要求パケットの送信元に自分のMACアドレスを設定したARP応答パケットを送信する。
- ARPキャッシュ
ARPによって取得したMACアドレスは数分間キャッシュされる。
Reverse Address Resolution Protocol。MACアドレスからIPアドレスを解決する。
- Proxy ARP
代理ARP。ルータの機能のひとつ。
HTTP[HTTPS]の基礎(2)
- hiddenフィールド
画面には表示されず，複数のWebページ間でデータの受渡しを行う際に利用されるHTMLフォーム項目である。HTMLコードに記述するだけ。
例：<input type="hidden" name="fruit" value="くだもの" >
- メリット：手軽。
- デメリット：データの受け渡しに使用するのは危険。
危険な理由は、他のデータと同様にブラウザに送信されているから。
つまり、次のページにデータを受け渡す時に一度ユーザのブラウザを経由するため常に改ざん・参照などの危険性が伴う。
が、セッションID程度の情報のやりとりにはちょうどいい。
- セッション変数
Webアプリケーション（PHPやJavaScript、CGIなど）において、サ―バに保持されるセッションごとの記憶領域の事。
セッション変数に設定されたデータはWWWブラウザに流出することがないため，安全にWebページ間のデータ受け渡しを行うことができる。
セッションIDと紐付けられる。
- セッションID
ユーザを識別するための情報。セッション変数と紐付けられる。
セッションIDをブラウザに覚えさせるには、以下の３つ。
- Cookieを使用する。
安全性はCookieを参照。参考：HTTP[HTTPS]の基礎(1) - n0g’s blog
- hiddenフィールドに書く。
第三者に値が流出する事故が起こる要因は少ない。
この中では一番安全。でも実装めんどい。
- URLの後にセッションIDを書く。（URL Rewriting）
危険。原則使用しない。理由はURL Rewritingを参照。
- URL Rewriting
Webサーバがブラウザに送るURLにセッションIDパラメータを付ける機能。
メリットはCookieが使用できない時に使用できる事。
デメリットは履歴に残る、盗聴されるとそのままセッションIDが盗まれるなどなど。。。
Cookieが使用できない時、携帯電話など以外は原則使用するなとIPAは言ってます。
IPA ISEC セキュア・プログラミング講座：Webアプリケーション編 第4章 セッション対策：セッション乗っ取り：#1 セッションIDとセッションID侵害手口
- HTTPとHTTPSの違い
HTTPSはHTTPにセキュリティ機能を追加したもの。HTTP over SSL/TLS
Webページとの通信を暗号化する。
共通鍵暗号方式で暗号化処理を行い、公開鍵暗号方式で共通鍵を送信する。
ざっくりと流れ。全てクライアント目線。
[1]
クライアントがWebサーバにHTTPSでアクセス。この時、利用可能な暗号化アルゴリズムを送信する。
[2]
サーバから電子証明書、Webサーバの公開鍵が送られてくる。
電子証明書を確認、公開鍵がそのサーバのものか確認。
[3]
共通鍵暗号方式の共通鍵を作成し、Webサーバの公開鍵で暗号化してサーバに送信。
[4]
共通鍵暗号方式によって暗号化通信を行えるようになる。
HTTP[HTTPS]の基礎(1)
- ポート番号
HTTP … 80
HTTPS … 443
- やりとりについて
参考：ブラウザとHTTPサーバのやり取り（その1） ネットワーク入門
表示したいページのすべてのアイテム（テキスト、画像）に対して以下を繰り返す。
[1] クライアントからサーバへGET要求
・GET/ index.html HTTP/1.0 ※GETはHTTPのコマンド
・MIMEヘッダ
これらをまとめたパケットのコマンドを送る
[2]サーバからクライアントへHTTP応答
・HTTP/1.0 200 OK ※200は OKという意味の応答
・MIMEヘッダ ／ データ本文
これらをまとめたパケットで応答する。
HTTP 1.0ではコマンドと応答のやり取りの度にTCPコネクションの確立・切断を行っていた。HTTP1.1からは１つのTCPコネクションで複数のコマンドと応答のやりとりができるようになった。
Multipurpose Internet Mail Extensions。
ざっくり言うとWeb専用ファイル拡張子。"Content-Type="の後に指定される。
"Multipart" / "Mixed"の形で指定される。
メールやインターネットはテキストしかやりとりできないので、MIMEを使用して無理やり文字データとして転送する。
Webサーバとブラウザ間で状態を管理するためのプロトコル。
セッション管理・ユーザ識別ができる。
ブラウザはサーバから送られてきたCookieをテキストファイルとして保存しておく。
サーバから要求があればそのテキストファイルを返信する。
Cookieの取得は同一ドメインのサーバのみで他のサーバからは読み出せない。
具体的には、domain属性とpath属性を接続するURLと比較し、条件を満たす時のみサーバに送信される。
「Webからの脅威」を攻略せよ――セッション管理編 - 第1回 まずは「クッキー」を理解すべし：ITpro
- secure属性、expires属性
Cookieに関する属性。
Cookieではユーザ認証を行えるため、Cookieを盗まれるとなりすましなどが危険。
サーバ側では盗まれたものかどうかの判定はできない。
そこで、Cookieにsecure属性やexpire属性を設定する。
- secure属性
- expires属性
Cookieの有効期限を指定する。
この指定がないときは、ブラウザが終了するとCookieは消される。
これが指定されているとブラウザの起動に関係なく有効期限までマシンにCookieが保存される事になり、危険性が高い。
セッションハイジャック(3)
ARP Poisoning
攻撃者のMACアドレスと正規ホストのIPアドレスを設定した偽のARP応答パケットを送信してARPキャッシュの内容を書き換える。
TCPシーケンス番号も偽装する必要がある。
・予防・防止
- ハブを物理的に防ぐ。不正な機器が接続できないようにする。
- 不正PCに対しての接続検知システムを導入する。
セッションフィクセーション（セッションIDの固定化攻撃）
Webアプリケーションにおけるセッションハイジャック。
ターゲットに対して攻撃者が 生成した不正なセッションIDを含むURLを送りつけ、
意図的にセッションを確立させ、そのセッションをハイジャックする攻撃。
フィッシング攻撃で多用される。
つまり、攻撃のために以下の条件が必要。
- 正規のセッションIDが容易に手に入る。
(ログイン画面とログイン後で同じセッションIDを使用している時など)
- Webサーバ側でURL Rewriting機能が有効になっている。
- そのサイトのアカウントをもつユーザにメールを送れる。
- ユーザが騙されてログインする。
・予防・防止
- WebサーバのURL Rewriting機能をOFFにする。
- ユーザのログイン後にセッションIDを再発行する。
対策（共通）
・検知・追跡
- ログから不審なセッションを探す。
- ネットワーク監視型IDS、ホスト監視型IDS,IPS、リバースプロキシサーバ、WAF、不正PC接続検知システムを使用する。
・回復
- 被害状況によって、データの復旧を行う。
- 脆弱性を特定し、対策する。
セッションハイジャック(2)
HTTPセッションハイジャック
Webアプリケーションで行われるセッションハイジャック。
HTTP通信は１つひとつのセッションが単発で終わるため連続性を管理できない。
そこでWebアプリケーションで各セッションを管理するためにセッションIDを生成し、
URLやcookie、hiddenフィールドにセットしてセッション管理する。
この仕組みの実装に以下のような脆弱性があると攻撃の対象になる。
- セッションIDが単純。
- セッション管理情報が丸見え。
- セッション管理情報が暗号化されていない。
- クロスサイトスクリプティングの脆弱性によってcookieにセットしたセッションIDが盗まれる。
攻撃者は、セッションIDを推測するか盗聴によってセッションIDを特定し
セッションをハイジャックする。
・予防・防止
- アプリケーションサーバに実装されている機能でセッション管理する。
- 自社開発する場合は、乱数・ハッシュなどで推測困難なセッションIDにする。
- 脆弱性検査をする。
- Webサーバの全面にリバースプロキシサーバやWAF(Webアプリケーションファイアウォール)を設置する。
認証サーバとクライアント間のセッションハイジャック
認証サーバになりすましてクライアントからのアクセス要求を受けてセッションハイジャックを成立させる。
クライアントがサーバの信頼性を確認すれば問題なし。
・予防・防止
SSL/TLSなどのサーバの正当性を確認でき、パケットの偽装が困難なプロトコルを使用する。
セッションハイジャック(1)
クライアントとサーバ間のセッションに割り込んで、セッションを奪う攻撃。
種類・対策
TCPセッションハイジャック
- TCPはコネクション確立を行う時に、シーケンス番号を交換する。
- コネクション確立後も発信者が送信するデータをオクテット単位で数えて、シーケンス番号に加算して送る。
これによって、受信者は正しくデータが送受信できていることを確認し、信頼性を高めている。
が、シーケンス番号を矛盾なく操作できればセッションを奪う事ができる。
攻撃者は、初期シーケンス番号を推測するか(※)、パケットを盗聴してシーケンス番号を特定する。
※最新のOSのTCPの実装では、初期シーケンス番号に乱数を使用しているが、
古いOSでは一定の規則性があった。
Man-in-the-Middle-Attack [中間者攻撃]
奪われた被攻撃者は、セッションを奪われるとコネクションを保てない。
が、攻撃者がなりすましてセッションをコントロールしコネクションを保っているように見せかけ、盗聴を続ける。
UDPセッションハイジャック
TCPと違い、コネクションの確立がないので単純。
クライアントがサーバに対してUDPで通信したとき、サーバよりも先に応答するだけ。
DNSキャッシュポイズニングに使用される手法。
- 最新のOS、ソフトウェアを使用する。パッチを当てる
- SSL/TLS、IPSec、SSHなどのパケットの偽装が困難な暗号化プロトコルを使用する。
- 脆弱性検査をする。
パスワードクラック
パスワードクラックの種類
推測によるパスワードクラック（類推攻撃）
誕生日やユーザIDなどからパスワードを推測する。
辞書攻撃
辞書ファイル(パスワードに使われそうな単語を登録したもの)を使用した攻撃
総当り攻撃（ブルートフォース）
文字種すべての組み合わせを試す方法。
パスワードリスト攻撃
どこかのサイトから漏洩したユーザIDとパスワードのリストをもって、
他のサイトのログインを試みる方法
事前計算攻撃
盗聴などで入手したハッシュ値に変換されたパスワードを解析する方法。
事前にパスワードとなりうる文字列のハッシュ値を計算しておき、テーブルで保持する。
ハッシュ値に変換されたパスワードと事前計算しておいたテーブルを比較することでパスワードを割り出す攻撃。
膨大なストレージを必要とする。
レインボー攻撃
事前計算攻撃を改善したもの。ストレージがいくらか減らす事ができる。
ハッシュ化関数H()と、ハッシュ値から平文を作り出す関数R()があるとする。
※H()で作成したハッシュをR()に入れても元の平文を得られるものではない。
・以下の手順でテーブル作成を行う。
[1]平文をH()でハッシュ化
[2] [1]で得られたハッシュ値からR()で平文を作り出す。
[3] [1]、[2]を一定回数繰り返す。（これをチェインという。）
[4] 最初の平文と最後の平文をテーブルに保存しておく（レインボーテーブル）
・攻撃は以下の手順。
[1] 対象のハッシュ値からR()で平文求める。
[2] 一致するものをレインボーテーブルから探す。
[3- A] 発見できれば、一致した平文を作成したチェインの中に元の平文が含まれる事になる。チェインの先頭からもう一度計算を行い、一致した平文に対するハッシュ値を計算し、そのハッシュ値に対する平文が求めるパスワードとなる。
[3- B] 発見できなければ、入手した攻撃対象のハッシュ値に対してR()で平文を作成。
さらにH()でハッシュ化し、[1]に戻る。これはチェインの回数分だけ繰り返すだけで済む。(※)
※R()→H()はチェインの作成と同じ。
つまり[3-B]の手順によって、対象のハッシュ値に対してチェインを進めたことになる。
逆に言えば、対象のハッシュ値はチェインの末尾から遡ったといえる。
参考：
レインボーテーブル – パスワード流出への対策を根本から理解する。 ｜ Developers.IO
オンライン攻撃
実際に動作しているサーバや動作中のサービスに認証情報を送って試みる攻撃。
通常、動作しているサーバ／サービスで一定回数以上の認証ミスがあればロックがかかる。
そのため、何十回と試行する必要がある攻撃は実施できない。
以下の攻撃が主なオンライン攻撃。
- 推測によるパスワードクラック
- パスワードリスト攻撃
オフライン攻撃
パスワードファイルやパスワードがかかったファイルを入手し、パスワードクラックを試みる攻撃。サービスではないため、試行回数でのロックはかけられない。
以下の攻撃が主なオフライン攻撃
- 総当り攻撃
- 辞書攻撃
- 類推攻撃
- レインボー攻撃
対策
予防・防止
- ワンタイムパスワード、バイオメトリクス認証などを使用する
- 固定式パスワードの場合、ロックアウトを設定する。
※ロックアウト…一定回数以上の失敗でアカウントを使用不可にする事。
- 脆弱なパスワードを設定しない。 （ツールを使用してチェックする）
- ログインの成否をログに記録する。
- 定期的にパスワードを変更する。
- パスワードファイルなどを盗まれないようにする。（セキュリティホールを対処しておく。）
検知・追跡
- ネットワーク監視型IDS、ホスト監視型IDS、IPSで検知する。
- ログイン失敗のログから攻撃されている事を検知する。
回復
- 攻撃を受けたホストとそのホストからアクセス可能な全てのホストに不正プログラムの埋め込みや、データ改ざん、設定変更がないかを確認・検証する。
問題があれば対処する。最悪はOSをクリーンインストール。
ソルト
レインボー攻撃に対しての対策。
ユーザが設定したパスワードをハッシュ値に変換する際、ランダムな短い文字列（ソルト）を追加した状態で変換する。
ソルトはユーザごとに変え、パスワードともに保管しておく。
これによって、
・同じパスワードでも異なるハッシュ値になる。
・文字列が長くなり、レインボー攻撃の探索を妨げる。
ストレッチング
総当たり攻撃、レインボー攻撃に有効。
ハッシュ関数に時間がかかるものを用意すれば、攻撃されにくくなるが
そのために低速アルゴリズムを開発するには手間がかかる。そのため、高速アルゴリズムを数千回繰り返す事でハッシュ値計算を低速にすること。
