概要 1 ネットワークを介した様々な攻撃 名古屋大学情報基盤センター情報基盤ネットワーク研究部門嶋田創 IP 通信における攻撃 認証突破系 ブルートフォース攻撃系 セッションハイジャック系 経路ハイジャック系 サービス不能攻撃系 L3/L4 レベル アプリケーションレベル インジェクション攻撃系 ウェブサーバへ 空いている TCP/UDP ポートへ 公開サーバへの攻撃 2 公開サーバを攻撃して乗っ取ってどうする? 3 今時の公開サーバに対して攻撃は山ほどある 正規の遠隔操作 (SSH, リモートデスクトップ, など ) への認証ブルートフォース攻撃 ウェブ認証ページへの認証ブルートフォース攻撃 偽サーバへの誘導 大量データの送信により公開サーバを麻痺 (DoS) ウェブサーバに対しての変な URL クエリの送付してインジェクション系攻撃 設定のうっかりミス系を狙うものもある うっかりデフォルト設定 ( 初期設定 ) のパスワードが動いていた そもそも 不要なサービスを動かしていた うっかりテスト用アカウントが残っていた そのサーバの内部の情報を得る そのサーバを踏み台にして 組織内部に浸潤 そのサーバを外部への悪意のあるアクションへの利用 マルウェア配布に利用 マルウェアへの司令 (C&C, C2: Command and Control) サーバへの利用 DDoS 攻撃に参加させる 組み込み機器 (IoT 機器を含む ) の悪用も増えている 4 5 ポート番号と公開の簡単な復習 IP 通信における攻撃 TCP/UDPの通信はお互いのポート (0-65535) へデータを送ることで成立 1023 番までのポートはWell Known Portとして 特定のサービスに紐付けられている 一般的なTCP 接続による通信 1. 適当なポート番号を確保して そこからサーバに接続要求を出す 2. サーバ側は提示されたポートに 要求されたデータを返す 最初の接続要求がうまくいかなければ 通信は成立しない サーバ側はサービスに対応するポートで接続を待ち受ける ウェブページ表示時の動作クライアントウェブサーバ適当なポート ( 例 : ポート12345) ポート80へ要求 空いているポートに不正な応答を誘発するリクエスト 接続を待ち受けているポートに接続できなければ 通信は開始しない 一般的に ファイアウォールは待ち受けているポートへの接続をブロックする 成立した通信は双方向で可能 一般的に クライアント側への接続開始要求はブロック 一般的に サーバ側でも公開を前提とするポート以外への接続開始要求はブロック 攻撃者 サーバポートxxへ不正な応答を誘発するリクエスト ポート 12345 へデータを返す 不正なデータ入りの応答など
6 7 ポートの公開状態の調査 (telnet) ポートの公開状態の調査 (nmap) telnet IP アドレス / ホスト名ポート番号 Windows でもデフォルトで入っている 入っていなかった! 応答を見ればポートで何のサービスが走っているか分かる 間にファイアウォールが入っている時の挙動が 2 種類ある RST を返す 即 connection refused SYN/ACK を返さない 応答が返ってこない 全ポートを調査するツールの 1 つ オプション次第では応答からの情報も提示 攻撃 ( の前の事前調査 ) と間違えられないように注意 ポートが開いているホストを探すサービス 8 Shodan 9 ネット上をクロールして開いているポートを確認してまとめてくれるサイトが複数ある 中には わざわざそのポートから確認できるデータの一部を出している所も 使いようによっては 自組織の穴があるホストのチェックにも https://www.shodan.io/ ポートの公開状態を検索できるサイトの草分け ウェブカム, BEMS(Building Energy Management System), インターネット冷蔵庫 発電所 信号機などのネットワーク接続された機器も発見できる 代表例 Shodan Censis Insecam 10 11 Censis Censis で嶋田サーバを検索した結果 https://www.censys.io/ 最近話題のポートの公開状態を検索できるサイト Shodan よりも検索能力が強化されている 登録されているデータに対して Google と同程度の検索を可能 OS 名 HTTP サーバソフトウェア名 サーバが返す HTTP ヘッダ など 正規表現でもマッチ可能
Censis で色々と検索してみよう 12 Insecam 13 "x.x.x.* FreeBSD" x.x.x.0/24 で OS が FreeBSD なホストが見つかる "x.x.x.* SSH" x.x.x.0/24 で SSH が開いているホストが見つかる "x.x.x.* Apache 2.4.17" x.x.x.0/24 で Apache が動作しているホストが見つかる 残念ながら バージョン指定はうまくいかなかった? わざわざポート番号を変更しても見つけてくれます http: 9000, 8443, 8172, 4004, 20000, など ssh: 6478, 60022, 60122, 60222, 44413, 2222, 22222, 20100, など 詳細は https://www.censys.io/tutorial 倫理的に少しどうかと思うので URL は無し セキュリティの甘い IP カメラの画像をリアルタイムに掲載 初期パスワードのまま パスワードが空 など (*1) http://nlab.itmedia.co.jp/nl/articles/1601/21/news137.html 画像は (*1) より引用 うっかり面倒なものを見たくない ロシアのサイトをアクセスするのはちょっと ThreatCloud 14 ブルートフォース攻撃系 15 逆に怪しい IP アドレスかどうか調べてくれるサービスもある 例 : ランサムウェア Petya の通信先 IP アドレス 他にも CYMON(https://cymon.io/) などいくつかサービスがある Petya の通信先 IP アドレスを ThreatCould に入れた結果 適当な情報を送って認証を突破しようとする 主な対象 : SSH, telnet, www( 認証 ) 余計なポートを公開しない ( パスワードの強度確保 他との共有の禁止 ) 接続元 IP アドレスの制限 時間あたりの認証数の制限 認証失敗回数に応じた無効化 (IP アドレス アカウント ) 最近だと複数の IP アドレスから分散して攻撃してくることもある セッションハイジャック系 16 アップデートハイジャック系 17 認証後のセッションキーなどを奪取 認証後のセッションを奪取して 認証情報を自分に都合の良いように書き換えて永久利用を可能とする 例 : Cookie を奪取 man in the middle 攻撃 telnet, FTP, BASIC 認証のような生パスワードを流れる物も同様 ローカルに保存された Cookie を奪取 (Remote Administration Trojan などのマルウェアで ) https 下のみ cookie を要求するような設定にする リクエストごとに新 cookie を発行する 一応 TCP のシーケンス番号を予測して変なパケットを紛れ込ませる方法もできなくもないが ソフトウェアアップデートの通信先にマルウェアを置く サーバ乗っ取り DNS インジェクション など 例 : EmEditor アップデートハイジャックを利用した攻撃 [1] 以下の様な.htaccess ファイルがアップデート配布ディレクトリに置いてあった 指定した IP アドレスの範囲からアップデート要求があれば別ファイルを配布 SetEnvIf Remote_Addr 106.188.131.[0-9]+ install SetEnvIf Remote_Addr 133.6.94.[0-9]+ install ( 同様に70 行 ) SetEnvIf Remote_Addr 124.248.207.[0-9]+ install RewriteEngine on RewriteCond %{ENV:install} =1 RewriteRule (.*.txt)$ /pub/rabe/editor.txt [L] [1] https://jp.emeditor.com/general/ 今回のハッカーによる攻撃の詳細について /
18 19 偽サーバへの誘導 ドメインハイジャック系 そのサーバに接続に来ていたクライアントに対して攻撃をしかける 大規模なサービスが狙われるだけでなく 水飲み場型攻撃の踏み台として小規模なサービスも狙われる可能性がある DNS インジェクション ドメイン登録情報不正書き換え などで実施 ドメイン登録情報不正書き換え ドメインレジストラを経由した登録において そのドメインを管轄する DNS サーバを変更して自サーバへ誘導 有名サイトと 1 文字違いなど typo 違いもドメインハイジャックの亜種と言えなくもない ネットワーク経路ハイジャック (BGP 経路ハイジャック ) 20 ネットワーク経路ハイジャック (BGP 経路ハイジャック ) 21 BGP(Border Gateway Protocol) の動作 サブネットを運営する組織は Autonomous System(AS) 番号を持つ 名古屋大学の AS 番号は 17687 AS の番号を列挙したものが経路となる ブロードキャストした AS 番号に経由した AS の AS 番号をつなげていく どこに どこまで ブロードキャストするかの制御も可能 現在は IPv4 で 64 万経路ぐらい この BGP に偽の経路を流す 自分が存在する AS の別サーバに誘導 自分が存在する AS の自分が乗っ取ったネットワーク機器を経由するようにルート変更 暗号化されていない通信を見ることができる 暗号化されている通信でも どことどこが どれだけの頻度で どれぐらいの通信量で通信している という情報は得ることができる AS17687 AS17687 22 23 ハイジャック系の実例 サービス不能攻撃 (DoS 攻撃 ) DNS への BGP ハイジャックと偽 DNS サーバによる仮想通貨窃取 (2018/4)[1] BGP ハイジャックで Amazon の DNS サービスである Route 53 への経路をハイジャック Route 53 利用者が偽 DNS サーバに誘導される 偽 DNS が仮想通貨ウォレットサービスを偽サイトに誘導 正規サービス 正規 DNS サーバ 偽 DNS サーバ Denial of Service 攻撃 サーバやネットワークの処理能力を超えた大量のリクエストを送りつけて 処理不能にさせる 攻撃元を分散させると DDoS(Distributed DoS) 攻撃 様々な階層で実行可能 SYN flood(l3) UDP Flood(L4) DNS リフレクションなどのリフレクション系攻撃は主にこれ HTTP GET flood(l5) Slow HTTP DoS(L5) 偽サービス [1] https://japan.zdnet.com/article/35118344/
SYN Flood 24 UDP Flood(1/2) 25 TCP は 3 ウェイハンドシェイクで通信の開始 / 終了 この最初の SYN だけを送りまくる攻撃 サーバ側は新 TCP セッションのために計算機資源を消費 厳密には 偽装 IP アドレスが発信元の SYN を送る ネットワークスイッチによる Ingress/Egress フィルタリング サブネットの入り口で偽装 IP アドレスのパケットを落とす サーバ側では SYN cache などで SYN を一旦待たせるなど サーバクライアント SYN SYN/ACK ACK FIN FIN/ACK ACK いくつかの UDP プロトコルにおいてリクエストに対して応答の方がサイズが大きいことを利用 要求の方は短い問い合わせ 応答の方は多くのデータがあるので データサイズは 応答 > 要求 大抵はリフレクション攻撃も併用する DNS サーバ DNS サーバ DNS サーバ DNS サーバ DNSサーバ DNSサーバ DNS 応答 偽 IP アドレスからの DNS 要求 指令サーバ UDP Flood(2/2) 防衛の面では UDP は送信 / 受信ともに同じポートを使うのがやっかい 例 : NTP リクエストは NTP サーバの UDP 123 ポートへ送信 応答はクライアントの UDP 123 ポートへ返信 ( 攻撃の ) 応答なのか正規の問い合わせの応答なのか分かりにくい DNS/NTP のリフレクション攻撃が有名 最近では マイナーな UDP プロトコルにも攻撃の手は伸びている SSDP(Simple Service Discovery Protocol), chargen(charcter GENerator), SNMP(Simple Network Management Protocol) など 26 UDP Flood 系の増幅率 とりあえず できるだけ多くのデータを送る応答を選択した時 DNS(UDP 53): 8 倍 TFTP(UDP 69): 60 倍 古い組み込み機器で使われる非常にシンプルな FTP( ファームウェア更新など ) NTP(UDP 123): 19-206 倍 SNMP(UDP 161): 650 倍 ネットワーク機器のステータスなどのログ報告 SSDP(UDP 1900):? Universal Plug and Play に必要なデータを送る chargen(udp 19): 無限大? 動作確認などを目的としてひたすら文字列を生成するサービス 27 DDoS Mon: DDoS の様子を見れるサイト https://ddosmon.net/ IP アドレスもしくはドメイン単位で DDoS の履歴を見ることが可能 もちろん CDN 等の観測ポイントを経由している通信のみ 28 HTTP Get Flood HTTP Get 要求を多数送る 要求よりも応答のデータが多い ウェブブラウザのリロードで意図せずに発生することも ウェブページが重くてなかなかデータが来ない とりあえずリロードしてみる F5(Windows におけるブラウザのリロードのショートカット ) 攻撃という話もかつてはあった コンテンツキャッシュサーバの準備 単位 IP アドレスあたりのセッション数の制限 29
30 31 Slow HTTP DoS 他の DoS 攻撃 HTTP セッションが途切れない程度に通信を継続 被害 セッション維持のために HTTP サーバにおけるメモリリソース等の浪費 TCP ポート数が不足することによるサービス不能 タイムアウト時間の短縮 単位 IP アドレスあたりのセッション数の削減 ただ 最近のクライアントは数十セッションを張って高速化したりするので そういう利用で遅くなる弊害 ( サービス悪化 ) 参考 : Google Map は利用可能セッション数 10 以下になると目に見えて表示が遅くなる 参考 : クライアントの多セッション利用は大規模 NAT における 1 グローバル IP アドレスあたりの収容数にも影響する ICMP Flood ping(icmp ECHO) を送りまくる パケットサイズが大きい ping だとなお効果的 あまり効果は無いけど 存在ぐらいは覚えておいても良さそう アプリケーションなどの実装の脆弱性を利用した DoS 攻撃 規格外のサイズのパケットを送ると処理が止まる 規格外のデータを送ると処理が止まる など ping of death など データ窃取が可能な脆弱性だとこちらもできる物が多そう 意図せず実装の脆弱性をついて攻撃に間違われた事例も 岡崎市立図書館事件 : 蔵書検索システムが検索ごとに消費したリソースを解放しない ゆっくりした頻度のクロールでもリソース不足へ 32 33 UDP Flood 対策 UDP Flood 対策 ( 自ネットワーク入口 ) 攻撃参加しないように 要求に応答する範囲を制限する 防衛 基本的に完全な防衛は難しい 全く無意味なパケット でも物理層を埋めることはできる いろいろと対策はあるが 何かを切り捨てる 必要は出てくる ある国からの正規のアクセスは ( 一時的に ) 切り捨てる 自組織外からのアクセスは ( 一時的に ) 切り捨てる 外から来ることが考えられないプロトコルは落とす ステートフルファイアウォールを導入して LAN から出してない要求への応答は落とす 対外接続部で通信を制限する 対外接続の帯域を食われることには変わらないが サーバや内部からのユーザは対応できる UDP Flood 対策 ( 自ネットワーク上流 ) (1/2) 34 UDP Flood 対策 ( 自ネットワーク上流 ) (2/2) 35 Content Delivery Network(CDN) を使って耐える CDN はユーザに近い所にコピーコンテンツを保持して応答 DNS を引くと近い CDN のサーバが返ってくる マスタサーバの負荷低減にもなる ただし お金はかかる (DoS オプションなどもある ) マスタサーバ自体を直接狙われることがある BGP で特定の通信を捨てさせる指示が可能 (Blackhole routing の応用 ) BGP のオプションで 特定の AS に対してのみ捨てさせるよう BGP の広報を行なう 特定の国などからの流入を防ぐ マスタサーバ CDN のサーバ コンテンツのコピー
36 37 DoS についてもっと調べたい方 インジェクション系攻撃 Akamai のレポートが詳しい Akamai: Content Delivery Network(CDN) の最大手 提供するコンテンツをインターネット上のいくつかの場所にキャッシュ可能とし 本サーバの負荷を減らす https://www.akamai.com/us/en/our-thinking/state-of-the-internetreport/ 4 半期ごとに DoS 攻撃の傾向をレポート掲載 攻撃の変遷も見ることが出来る リフレクション攻撃に使われるプロトコルの変遷が面白い ウェブサーバへ クロスサイトスクリプティングやSQLインジェクションは良く話題になる 最近はコンテンツマネジメントシステムが多様されるので それらを狙った攻撃も多い 例 : 2017/1のWordpress 脆弱性の利用 空いているTCP/UDPポートへ 基本は正規のプロトコルを使ったblute force 攻撃が多い ただ 変なリクエストを送ってくる事例はちょこちょこある 攻撃の結果により 情報が流出したり サーバをマルウェア配布などに悪用されたり コンテンツマネージメントシステム (CMS) 38 クライアント側でのウェブのデータ操作 39 コンテンツを登録するだけできれいなページを作成可能 データベースに登録されたコンテンツを フォーマットして表示 代表的な CMS とシェア [1] WordPress 59.2% Joomla 6.9% Drupal 4.7% バックエンドで DB を使っているので SQL インジェクションなどの脆弱性が良く見つかる 本体だけでなく プラグインにも脆弱性が見つかる Pukiwiki などの Wiki エンジンなども CMS 一番重要なこと : 最新の CMS を使いましょう URL を入れると HTTP GET 要求でデータをもらって表示 ウェブページのフォームに入力したデータを HTTP POST や URL クエリでウェブサーバに提供 HTTP POST: HTTP GET の末尾に入力フォームの内容を羅列 URL クエリ : URL の後ろにパラメータと値を列挙する方法 クライアント 待機 HTTP GET www.example.com example.com のページ 待機 HTTP POST www.example.com + データ HTTP GET www.example.com/?search=... サーバ [1] https://w3techs.com/technologies/history_overview/content_management 入力データに対応したページ 待機 40 41 HTTP POST の例 URL クエリ 名大 IT ヘルプデスクの質問入力フォーム HTML の form タグで post が指定されている ( 上の赤線 ) 入力項目には name が指定されている ( 下の赤線 ) URL の末尾に? をつけ それ以降が URL クエリとなる 個々のパラメータと値は " パラメータ名 "=" 値 " で表現 複数のパラメータがある場合は & で区切る例 : 実際の URL では全角文字を扱えないので パーセントエンコーディングされる ( =&? などの記号も同じ ) https://www.google.co.jp/search?q=%e5%b6%8b%e7%94%b0+% E5%89%B5&ie=utf-8&oe=utf-8&hl=ja URL クエリはブラウザのアドレスバーに表示されるため おおっぴらに見えて欲しくない情報が露わになることも
サーバ側でのウェブのデータ操作 クライアントからのアクセス方法により動作を変更可能 静的コンテンツ提示 : 事前に登録しておいたデータを表示するだけ 動的コンテンツ表示 : ウェブサーバ側でクライアントのリクエストに応じてプログラムで処理した結果を提示可能 CGI 方式による外部プログラム呼び出しや PHP 言語 (Hypertext Processor) の利用 クライアント側で JavaScript プログラムを動作させて ユーザの操作に応じたリクエストを出す ( ウェブブラウザ側から ) 物もある Ajax CGI を利用することでクライアントから POST で受けたデータをサーバ内に保存可能 必要に応じて 保存したデータを加工して動的コンテンツとして表示 HTTP Cookie の発行と管理 42 HTTP Cookie サーバ側からクライアント ( のウェブブラウザ ) に記憶させることができる情報 ウェブブラウザは Cookie のドメインに対応するウェブサーバへの再アクセス時には Cookie の情報を送信 攻撃 : Cookie に変な値を設定 シーケンス番号 ID が推測可能だと特に狙われやすい クライアント 初回の GET リスエストの応答で Cookie を設定 Set-Cookie: id=78safdhj87, domain=example.com... 次回に example.com にアクセスする時に HTTP GET の中に以下を追加 Cookie: id=78safdhj87 すでに 1 回アクセス済みの人への対応 サーバ 43 Cookie 関連の情報セキュリティ 44 クロスサイトスクリプティング (1/3) 45 Tracking Cookie: 利用者の追跡を目的とした Cookie 主に広告コンテンツが実施 例 : サイト A に出した広告で Cookie を設定 サイト B に出した広告で設定した Cookie を受け取る 通常は 3rd party Cookie( 閲覧中サイトとは違うドメインの Cookie) となる 気になるならばブラウザで Do not track の設定と 3rd party Cookie の禁止 を実施しておく それでも IP アドレスや User agent 情報などからある程度は追跡できる Supercookie, LSO など HTTP Cookie と同等の物を HTTP とは別の処理の中で実装 例 : Adobe Flash を使った場合に Adobe Flash 用のデータ領域に 他にも Canvas fingerprinting など 利用者追跡の技術は積極的に開発されている ( 有効性の高低はあるが ) フォームなどへの特定の応答により 攻撃者が用意したスクリプト ( プログラム ) が実行される フォームに書いた値や URL クエリの値を表示させる時のミス 基本的に 入力の一部でタグを途中で終了させ その後にスクリプトを挿入 の形 例 : http://.../hoge.cgi?initdata=hoge と入力すると <input initdata="hoge"> となる HTML を動的生成における JavaScript 挿入 入力例 : http://.../hoge.cgi?initdata="><script>alart(1);</script>"<input initdata=" 出力例 : <input initdata=""><script>alart(1);</script>"<input initdata=""> 基本的な対策 : 入力データをエスケープ < < > > " " ' $#39; & & クロスサイトスクリプティング (2/3) 46 クロスサイトスクリプティング (3/3) 47 略称は XSS ウェブ関係で CSS だと Cascading Style Sheet が先にあったため Internet Explorer などがクロスサイトスクリプティングフィルタを搭載 Firefox では NoScript アドオンとかで追加可能 有害なスクリプトをブロックするが たまに誤検出することも クロスサイトスクリプティングを起点として 多種多様な攻撃を実現することが多い サーバのデータ閲覧など : SQLインジェクション LDAPインジェクション ユーザ側の閲覧データ加工 : 強制ブラウズ リモートファイルインクルード その他 : セッションID 固定攻撃 オープンリダイレクタによる誘導 ディレクトリトラバーサル OSコマンドインジェクション Xpathインジェクションメモリ初期化ミスを利用したメモリリク HTTPヘッダインジェ クロスサイトスクリプティングを起点として 多種多様な攻撃を実現することが多い サーバのデータ閲覧など : SQL インジェクション LDAP インジェクション ディレクトリトラバーサル OS コマンドインジェクション Xpath インジェクション メモリ初期化ミスを利用したメモリリーク ユーザ側の閲覧データ加工 : 強制ブラウズ リモートファイルインクルード MITM による ( セッション ) ハイジャック : セッション ID 固定攻撃 HTTP ヘッダインジェクション (iframe など上位のページを設定しての )Cookie の読み出し その他 : オープンリダイレクタを利用した誘導
ディレクトリトラバーサル (1/2) 48 ディレクトリトラバーサル (2/2) 49 本来は見れない範囲にあるデータを見ようとする攻撃 フォーム等でデータを指定する部分などで 本来見れないないデータを指定できてしまったりする 例 : 電子掲示板の書き込み番号など <input type="hidden" name="datafile" value="file645"> hiddenをユーザ側からも見れないと勘違いした非常に初歩的な実装 多くのシステムでは ".." は1つ上のディレクトリに移動を示す 入力にあったとしても処理しないようにシステムを組む 何らかのミスで許してしまうと 本来は見れないパスワードやデータの閲覧が可能に /var/www/htmlなどが外部公開の最上位のはずが それより上のディレクトリも読まれる 使っているソフトウェアが汎用の物ならば データ位置はまず初期名称から変わっていない 例 : 某 Wikiの初期ディレクトリ / ファイル名.../wiki/webroot ( 本来の外部公開の最上位 ).../wiki/wiki-common (auth.iniとかがある).../wiki/wiki-data ルートディレクトリに出るまで.. を繰り返して 例 : /etc/hogeの表示を試みる../etc/hoge../../etc/hoge../../../etc/hoge 以下 繰り返し : 正しく ".." の無害化処理を入れる OS コマンドインジェクション (1/2) 50 OS コマンドインジェクション (2/2) 51 ウェブサーバ側で URL クエリを処理するアプリケーションの設計ミスなどでウェブサーバ側で OS のコマンドを実行 Perl による CGI 等の中から system 関数などで OS( 主に UNIX 系 ) のコマンドを呼び出している所 Windows サーバでも PowerShell を呼び出ししている所で同じことができる やり方は XSS と同じ 例 : perl の system 関数で入力値を引数としたファイルを検索 $files = system "/bin/ls $input" ここで $input に a; /bin/cat /etc/passwd とすると? $files = system "/bin/ls a; /bin/cat /etc/passwd" /bin/ls a と /bin/cat /etc/passwd が連続実行される マルウェアをダウンロードして実行するコマンドのインジェクションが多い テンポラリファイル置き場 ( どのプログラムも書き込み権限がある場所 ) にダウンロードして実行させる : XSS と同じくエスケープ OS コマンド呼び出しを行わない実装を考える SQL インジェクション (1/2) データベース (DB) への SQL(Standard Query Language) によるクエリを追加 XSS と似ているが 認証処理を同時にやっていたりすることもある 例 : SQL の条件文から真が返って来たら認証成功 例 : ログイン処理でフォームのユーザ名とパスワードが一致するか? フォームの入力は inuser と inpasswd とする 条件文例 : user = 'inuser' AND passwd = 'inpasswd' 何も対策されていないと inpasswd に a' OR 'a' = 'a を設定する user = 'inuser' AND passwd = 'a' OR 'a' = 'a' OR に恒真節が入って常に真が返る 認証突破 52 SQL インジェクション (2/2) DB のエントリを表示させて情報流出につながることも DB のテーブルにサーバ内のファイルを指定して サーバ内の別データからの情報流出につながることも いろいろ所で 高機能化のために DB は使われていたりするので ウェブサービスの裏で DB が動いている事例は多い 例 : ファイルサーバでのファイルに関するデータ 例 : チャットシステムでの発言データ : XSS と同じくエスケープ 53
クロスサイトリクエスト偽造 (CSRF: Cross Site Request Forgery) 54 オープンリダイレクタによる誘導 55 ここでのリクエスト : HTTP POST などによるクライアントからサーバへのリクエスト XSS がブラウザ側 偽のリクエストを作り サーバ側のデータを書き換える のがこの攻撃の特徴 認証のあるページでも ユーザが認証終了した後 ( 認証済み Cookie を持っているとか ) していたら書き換え可能 例 : パスワード変更ページに攻撃者側があらかじめ設定したパスワードに変更 例 : 掲示板への悪意のある書き込み データ更新ページの遷移前後で追加のセッションキーを設定 データ更新承認時に再度認証を要求する リダイレクト : 別 URL のウェブページに転送すること HTTP ヘッダの Location ヘッダの設定とか 動的に遷移先ページを 例 : ログインしていなくてももある内容を見れるが 必要に応じて ログイン (or 新規加入 ) ボタンを押してログインしてもらうウェブページ ログイン処理や新規加入処理の後は元のウェブページに戻らせたい リダイレクト先を選択 このリダイレクト先を (URL クエリなどで ) 好きなページに設定できたら? 悪い人が攻撃ページに誘導するのに悪用可能 URL を見ただけでは リダイレクタを準備しているサービスに見える 普通はサービス関連ページのみリダイレクト可能とする クロスサイト系攻撃における iframe の悪用 56 URL からの推測 57 iframe(inline frame): ページの一部にフレームを設定して 別 HTML を表示するフレームワーク 古来の frame と比較して フレームの境目が分かりにくい クロスサイト系攻撃においてよく悪用される 攻撃 ( 詐欺 ) ページの中に iframe で元のページを表示する 元ページの上に背景を塗りつぶした攻撃ページの iframe を置いて 元ページを隠蔽 攻撃 JavaScript を動作させるために透明もしくはサイズ極小の iframe を設定して その中で攻撃 JavaScript を動作させる HTML を表示 他の URL から推測可能な URL に未公開資料を置いてあった 例 : 2016/kessan.pdf をもとに 2017/kessan.pdf( 未公開 ) を発見される ディレクトリインデクスを有効にしていて 2016/ とディレクトリ名でアクセスすると一覧が見えてしまう その中に編集途中の物などの都合の悪い物が : 不必要なファイルをウェブサーバに置かない ディレクトリインデクスはデフォルトで無効に XSS やインジェクション系の攻撃関連よもやま 58 空いているポートへの攻撃 (1/2) 59 Internet Explorer や Google Chrome などの多くのブラウザが搭載 Firefox は搭載していないが NoScript アドオンとかで追加可能 たまに誤検出することも 必要に応じて疑う 余談 : IE が content-type を無視して HTML じゃないものが HTML として解釈されて XSS なるバグがあったりした X-Content-Type-Options: nosniff を追加して解釈を禁止 HTML5 新要素を使った XSS もこれから増えるかも JavaScript で実装できるような機能が HTML5 に取り入れられた Ajax の利用が増えることによって ローカル側で生成した JavaScript による XSS が発生したり (DOM based XSS) 一部 OS で 不要なサービスが動いていることはある さらに デフォルトのユーザ名とパスワードが利用可能だったりする 最近は OS やソフトウェア提供者側が学習してデフォルトをまともな設定にするようになった と思ったら 最近は組み込み機器や IoT 機器で問題が増加 さらに 機器性能から後述の古いプロトコルを利用している物が 空いているポートにデフォルトのユーザ名 / パスワード等による blute force 攻撃 SQL サーバのポートに対して SQL を送りつける物も多い SQL サーバでリクエスト受理する IP アドレスの範囲を間違えたら というか 適当にポートを空けていると色々なリクエストを試みてくる感じ
空いているポートへの攻撃 (2/2) 60 空いているポートへの攻撃 (2/2) 61 あまり古いサービスをインターネットに公開するのはよろしくない 例 : 暗号化されていないパスワードがネット上を流れる telnet, rsh SSH が後継 FTP FTPS, SSH(SSH サブセットの SCP, SFTP) が後継 POP3/IMAP POP3S/IMAPS が後継 例 : そもそも認証が緩すぎる SMTP( クライアントとサーバの間において ) Submission その他 SMB NFS(~v2) Apple Filing Protocol などのファイル共有系も弱い物が多い SMB(v1) は WannCry に使われた点が記憶に新しい AFP も Apple 自体が インターネットに公開するな と言っている 逆に わざと開いているポートを設定して攻撃観測することもある ハニーポット 色々なハニーポットフレームワークがあるので ( 個人で ) 試してみるのも面白い もっと大規模な物では 未割り当て IP アドレス領域 ( ダークネット ) へのリクエストをまとめて観測することも 余談 : 最近 ダークウェブとダークネットをごっちゃにされていることが多くて嫌な感じ