ネットワークを介した様々な攻撃

名古屋大学 情報基盤センター

情報基盤ネットワーク研究部門

嶋田 創

概要

公開サーバ一般に対する攻撃ポート公開中のサービスの脆弱性を狙った攻撃

サービス不能(Denial of Service)攻撃

サーバ接続のハイジャック

ウェブサービスの提供者/利用者への攻撃ウェブサービス提供者側への攻撃

ウェブサービス利用者側への攻撃

認証機構と突破の試み

1

ネットワークを介した攻撃の主な狙い

サーバの(管理者)権限を取ってやりたいほうだいサーバ内部のコンテンツを窃取

組織内部への浸潤経路として利用

組織外への攻撃の踏み台として利用

ウェブサーバに悪意のあるコンテンツを設置場合により、ウェブサーバの管理者権限奪取を伴う

ウェブサーバに見れないように設定されているデータを出させる

サーバで提供するサービスを麻痺させる(Denial of Service) ウェブサービスの利用者の認証情報を窃取

他でも同じ認証情報が使われているかもしれない

2

ポート番号とその公開の簡単な復習

TCP/IPおよびUDP/IPの通信はお互いのポート(0-65535)へデータを送ることで成立

1023番までのポートはWell Known Portとして、特定のサービスに紐付けられている

一般的なTCP接続による通信1. 適当なポート番号を確保して、そこからサーバに接続要求を出す

2. サーバ側は提示されたポートに、要求されたデータを返す

初の接続要求がうまくいかなければ、通信は成立しない

サーバ側はサービスに対応するポートで接続を待ち受ける

3

ウェブサーバ

ポート80へ要求

クライアント適当なポート(例: ポート12345)

ウェブページ表示時の動作

ポート12345へデータを返す

公開中のポートに対する攻撃(1/3)

主なパターン公開中のポートに不正な応答を誘発するリクエスト

ポートを公開中のネットワークサービスを妨害するリクエスト

認証を伴う公開中のポートに対して認証破り

接続を待ち受けているポートに接続できなければ、通信は開始しない

→ファイアウォールで不必要なポートへの接続要求をブロック

4

サーバ

ポートxxへ不正な応答を誘発するリクエスト

攻撃者

不正なデータ入りの応答など

公開中のポートに対する攻撃(2/3)

一部OSで、ポート公開を伴う不要なネットワークサービスが動いていることはある さらに、デフォルトのユーザ名とパスワードが利用可能だったりする

近は、OSやソフトウェア提供者側が学習してデフォルトをまともな設定にするようになった

と思ったら、 近は組み込み機器やIoT機器で問題が増加

さらに、機器性能から後述の古いプロトコルを利用している物が…

→空いているポートにデフォルトのユーザ名/パスワード

SQLサーバのポートに対してSQLを送りつける物も多い SQLサーバでリクエスト受理するIPアドレスの範囲を間違えたら…

というか、適当にポートを空けていると色々なリクエストを試みてくる感じ

5

公開中のポートに対する攻撃(3/3)

あまり古いサービスをインターネットに公開するのはよろしくない

例: 暗号化されていないパスワードがネット上を流れる 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自体が「インターネットに公開するな」と言っている

6

ポートの公開状態の調査(telnet)

telnet IPアドレス/ホスト名 ポート番号Windowsでもデフォルトで入っている →入っていなかった!

応答を見ればポートで何のサービスが走っているか分かる

間にファイアウォールが入っている時の挙動が2種類ある RSTを返す →即connection refused SYN/ACKを返さない →応答が返ってこない

7

ポートの公開状態の調査(nmap)

全ポートを調査するツールの1つオプション次第では応答からの情報も提示

攻撃(の前の事前調査)と間違えられないように注意

8

ポートが開いているホストを探すサービス

ネット上をクロールして開いているポートを確認してまとめてくれるサイトが複数ある

中には、わざわざそのポートから確認できるデータの一部を出している所も

自組織が運用中のホストの穴のチェックに活用できる

代表例 Shodan Censis

9

Shodan

https://www.shodan.io/ ポートの公開状態を検索できるサイトの草分け

ウェブカム、BEMS(Building Energy Management System)を始めとする各種EMS、各種IoTデバイス

ac.jpドメインのメールアドレスでユーザ登録するとアカデミックな利用権限になる

10

Shodanで嶋田サーバを検索した結果

IPアドレスの指定は「net:IPアドレス」の形式で CDIR形式で範囲しても可能(例: net:192.168.0.0/24)

SSHサーバ動作中ということがバージョンや公開鍵を含めて分かる

ウェブサーバを動かしていると、ウェブサーバソフトウェアとかHTTPSの公開鍵とかも表示される昨年サーバ更新した時に止めてしまったので…

11

Shodanでいろいろ検索してみよう

動作中サービスに関連して収集された情報をキーワードに検索可能例: OpenSSH, FreeBSD

「hostname:example.com」「country:国名」「org:ネットワーク運用組織名(ISPなど)」な検索可能

複数出てくる場合、右のように統計情報の形でのサマライズも出る

スクレイピングなどをやりたければPythonにshodanライブラリあり

詳細はhttps://help.shodan.io/

12

Censis

https://www.censys.io/ Shodanよりも検索能力が強化されているのが売り

登録されているデータに対してGoogleと同程度の検索を可能

OS名、HTTPサーバソフトウェア名、サーバが返すHTTPヘッダ、など

正規表現でのマッチ可能

https://censys.io/certificates/help

ミシガン大学の研究者が開設

13

Censysで嶋田サーバを検索した結果

SSHの受付Cipher Suiteの提示など、Shodanより細かい

14

Censisで色々と検索してみよう

"192.168.0.0/24 and FreeBSD" 192.168.0.0/24でOSがFreeBSDなホストが見つかる

"192.168.0.0/24 and SSH" 192.168.0.0/24でSSHが開いているホストが見つかる

"192.168.0.0/24 and Apache and 2.4" 192.168.0.0/24でApache 2.4が動いている

ポート番号を変更しても見つけてくれます(ついでにタグ付けしてくれる) http: 9000, 8443, 8172, 4004, 20000, など

ssh: 6478, 60022, 60122, 60222, 44413, 2222, 22222, 20100, など

詳細はhttps://censys.io/ipv4/help

15

公開ポート関係 その他もろもろ

Inscam[1]Webcamに特化した公開ポートリストアップサイト

セキュリティの甘いIPカメラの画像をリアルタイムに掲載

初期パスワードのまま、パスワードが空、など

zmapやmasscan自組織所有のIPアドレスを調査したい場合に使えるツール

他にもZoomEye, FOFA, ONYPHEなど

16

[1] http://nlab.itmedia.co.jp/nl/articles/1601/21/news137.html

ThreatCloud

通信元IPアドレスか怪しいかどうか提示するサービス他に関連する通信先も提示してくれる

例: ランサムウェアPetyaの通信先IPアドレス

他にも、CYMON(https://cymon.io/)などいくつかサービスがある

17

Petyaの通信先IPアドレスをThreatCouldに入れた結果

VirusTotalのURLレピュテーション機能

そのURL(の下)に悪意のあるコンテンツがあるか(あったか)どうか、複数のアンチウィルスエンジンでの結果を提示

18

不正な応答を誘発させるリクエストの事例

基本的に脆弱性として報告されているが… サーバの動作が止まる

例: BIND(DNSサーバ)でサーバ停止の脆弱性(CVE-2016-2848) パケットが処理できなくてDenial of Service状態になる

例: 組み込みシステム用シーケンサでリソース枯渇の脆弱性(CVE-2020-13238)

任意のコードが実行される例: EternalBlueと呼ばれるSMB v1の脆弱性(CVE-2017-0144)

秘匿すべき情報が応答に入る例: フロントパネルのパスコードを返す産業用プリンタ(CVE-2019-

10960)興味がある人はCVE DBなどでmalicious packet/requestなどで検索してみよう

19

公開中のポートへの攻撃観測

ハニーポットという、わざと開いているポートを設定して攻撃観測するサーバやサーバソフトウェアが存在低対話型ハニーポット: 空けたポートへのリクエストのみを収集

高対話型ハニーポット: 空けたポートへのリクエストに対して応答を返して接続者の挙動をより深く観察

攻撃者がシステムに侵入してバックドア設置や配布用マルウェア設置まで観察することも

色々なハニーポットフレームワークがあるので、(個人で)試してみるのも面白い

もっと大規模な物では、未割り当てIPアドレス領域(ダークネット)へのリクエストをまとめて観測することも余談: 近、ダークウェブとダークネットをごっちゃにされていることが

多くて嫌な感じ

20

概要

公開サーバ一般に対する攻撃ポート公開中のサービスの脆弱性を狙った攻撃

サービス不能(Denial of Service)攻撃

サーバ接続のハイジャック

ウェブサービスの提供者/利用者への攻撃ウェブサービス提供者側への攻撃

ウェブサービス利用者側への攻撃

認証機構と突破の試み

21

サービス不能攻撃(DoS攻撃)

Denial of Service(DoS)攻撃

サーバやネットワークの処理能力を超えた大量のリクエストを送りつけて、処理不能にさせる

攻撃元を分散させるとDDoS(Distributed DoS)攻撃

アクセス集中で意図しないDoS攻撃状態になることも

様々な階層で実行可能 SYN flood(L3) UDP Flood(L4)

近ニュースとかで話題になるDoS攻撃はほとんどこれ

DNSリフレクションなどのリフレクション系攻撃が問題を大きくしている

HTTP GET flood(L5) Slow HTTP DoS(L5)

22

SYN Flood

TCPは3ウェイハンドシェイクで通信の開始/終了

この 初のSYNだけを送りまくる攻撃サーバ側は新TCPセッションのために計算機資

源を消費

厳密には、偽装IPアドレスが発信元のSYNを送る

対策ネットワークスイッチによるIngress/Egressフィル

タリング

サブネットの入り口で偽装IPアドレスのパケットを落とす

サーバ側ではSYN cacheなどでSYNを一旦待たせるなど

23

サーバ クライアント

SYN

SYN/ACK

ACK

FIN

FIN/ACK

ACK

UDP Flood(1/2)

大抵はリフレクション攻撃も併用(UDP送りつけだけは稀)いくつかのUDPプロトコルにおいてリクエストに対して応答の方がサ

イズが大きいことを利用

要求の方は短い問い合わせでも、応答の方は多くのデータがあるので、データサイズは「応答>要求」

24

指令サーバ

DNS応答

偽IPアドレスからのDNS要求

DNSサーバ

DNSサーバ

DNSサーバ DNSサーバ

DNSサーバ

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)など

名大では外部にポート公開することは禁止されている

25

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): 無限大?動作確認などを目的としてひたすら文字列を生成するサービス

26

DDoS Mon: DDoSの様子を見れるサイト

https://ddosmon.net/ IPアドレスもしくはドメイン単位でDDoSの履歴を見ることが

可能もちろん、(CDNなどの)観測ポイントを経由している通信のみ

27

HTTP Get Flood

HTTP Get要求を多数送る要求よりも応答のデータが多い

ウェブブラウザのリロードで意図せずに発生することも

ウェブページが重くてなかなかデータが来ない

→とりあえずリロードしてみる

F5(Windowsにおけるブラウザのリロードのショートカット)攻撃という話もかつてはあった

対策コンテンツキャッシュサーバの準備

近だとContent Delivery Network(CDN)に任せる方が手軽

単位IPアドレスあたりのセッション数の制限

28

Slow HTTP DoS

HTTPセッションが途切れない程度に通信を継続

被害セッション維持のためにHTTPサーバにおけるメモリリソース等の浪

費

TCPポート数が不足することによるサービス不能

対策 タイムアウト時間の短縮(ただし、ユーザから不満が出ることも)単位IPアドレスあたりのセッション数の削減

ただ、 近のクライアントは数十セッションを張って高速化したりするので、そういう利用で遅くなる弊害(サービス悪化)

参考: Google Mapは利用可能セッション数10以下になると目に見えて表示が遅くなる

参考: クライアントの多セッション利用は大規模NATにおける1グローバルIPアドレスあたりの収容数にも影響する

29

他のDoS攻撃

ICMP Flood ping(ICMP ECHO)を送りまくる

パケットサイズが大きいpingだとなお効果的

あまり効果は無いけど、存在ぐらいは覚えておいても良さそう

アプリケーションなどの実装の脆弱性を利用したDoS攻撃

規格外のサイズのパケットを送ると処理が止まる、規格外のデータを送ると処理が止まる、など

ping of deathなど

データ窃取が可能な脆弱性だとこちらもできる物が多そう

意図せず実装の脆弱性をついて攻撃に間違われた事例も

岡崎市立図書館事件: 蔵書検索システムが検索ごとに消費したリソースを解放しない

→ゆっくりした頻度のクロールでもリソース不足へ

30

UDP Flood対策

攻撃参加しないように要求に応答する範囲を制限する

防衛基本的に完全な防衛は難しい

「全く無意味なパケット」でも物理層を埋めることはできる

いろいろと対策はあるが、「何かを切り捨てる」必要は出てくる

ある国からの正規のアクセスは(一時的に)切り捨てる

自組織外からのアクセスは(一時的に)切り捨てる

31

UDP Flood対策(自ネットワーク入口)

外から来ることが考えられないプロトコルは落とすステートフルファイアウォールを導入してLANから出してない要求へ

の応答は落とす

対外接続部で通信を制限する

→対外接続の帯域を食われることには変わらないが、サーバや内部からのユーザは対応できる

32

AS....

AS....

AS....

AS....AS....

AS....

UDP Flood対策(自ネットワーク上流) (1/2) Content Delivery Network(CDN)を使って耐える

CDNはユーザに近い所にコピーコンテンツを保持して応答

DNSを引くと近いCDNのサーバが返ってくる

マスタサーバの負荷低減にもなる

ただし、お金はかかる(DoSオプションなどもある)マスタサーバ自体を直接狙われることがある

33

AS....

AS....

AS....

AS....AS....

AS....

CDNのサーバマスタサーバ

コンテンツのコピー

UDP Flood対策(自ネットワーク上流) (2/2) BGPで特定の通信を捨てさせる指示が可能(Blackhole

routingの応用) BGPのオプションで、特定のASに対してのみ捨てさせるよう

BGPの広報を行なう

→特定の国などからの流入を防ぐ

34

AS....

AS....

AS....

AS....AS....

AS....×

DoSについてもっと調べたい方

Akamaiのレポートが詳しい Akamai: Content Delivery Network(CDN)の 大手

提供するコンテンツをインターネット上のいくつかの場所にキャッシュ可能とし、本サーバの負荷を減らす

https://www.akamai.com/us/en/our-thinking/state-of-the-internet-report/

4半期ごとにDoS攻撃の傾向をレポート掲載

攻撃の変遷も見ることが出来る

リフレクション攻撃に使われるプロトコルの変遷が面白い

2020年にはついに2TbpsオーバーのDDoSが観測される 4,5年前にマルウェアMiraiによって500Gbps級のDDoSが話題に

なったばかりなのに…世界の通信量の伸び(年率23%、前資料)よりも早いペースの伸び

35

概要

公開サーバ一般に対する攻撃ポート公開中のサービスの脆弱性を狙った攻撃

サービス不能(Denial of Service)攻撃

サーバ接続のハイジャック

ウェブサービスの提供者/利用者への攻撃ウェブサービス提供者側への攻撃

ウェブサービス利用者側への攻撃

認証機構と突破の試み

36

ネットワーク経路ハイジャック(BGP経路ハイジャック) BGP(Border Gateway Protocol)の動作

サブネットを運営する組織はAutonomous System(AS)番号を持つ

名古屋大学のAS番号は17687 ASの番号を列挙したものが経路となる

ブロードキャストしたAS番号に経由したASのAS番号をつなげていく

「どこに」「どこまで」ブロードキャストするかの制御も可能

現在はIPv4で70万経路ぐらい

37

AS17687

AS....

AS....

AS....AS....

AS....

ネットワーク経路ハイジャック(BGP経路ハイジャック) このBGPに偽の経路を流す

自分が存在するASの別サーバに誘導

自分が存在するASの自分が乗っ取ったネットワーク機器を経由するようにルート変更

暗号化されていない通信を見ることができる

暗号化されている通信でも、「どことどこが、どれだけの頻度で、どれぐらいの通信量で通信している」という情報は得ることができる

38

AS17687

AS....

AS....

AS....AS....

AS....

ハイジャック系の実例

DNSへのBGPハイジャックと偽DNSサーバによる仮想通貨窃取(2018/4)[1] BGPハイジャックでAmazonのDNSサービスであるRoute

53への経路をハイジャック

→Route 53利用者が偽DNSサーバに誘導される

偽DNSが仮想通貨ウォレットサービスを偽サイトに誘導

39

正規DNSサーバ

偽DNSサーバ

偽サービス

正規サービス

[1] https://japan.zdnet.com/article/35118344/

他の偽サーバへの誘導

DNSに偽の名前解決を入れて偽サーバに接続させる偽DNSサーバを指定させたり、DNSサーバが上流DNSサーバに問

い合わせた時に偽の応答を返したり

対策としてDNSSECは提案されているが普及が微妙

HTTPSでDNSを実行して、ブラウザ内部で安全なDNSに接続させるDNS over HTTPの実装が急速に進んでいる(Firefox, Chromeなど) 「この名前解決を行った」というプライバシーの範疇の情報を集中して集めることができるので、プライバシーとの兼ね合いが悩ましい

偽無線LANアクセスポイントを準備して誘導全ての通信を特定サーバに誘導もできるし、DNSで特定のサーバの

み誘導とかもできる

まあ、TLSのサーバ証明書とかで見つけることはできるが…個人的には、Free WiFi系は一旦安全なサーバにVPN通してから使

いたい…

40

ドメインハイジャック系

DNSインジェクション、ドメイン登録情報不正書き換え、などで実施

ドメイン登録情報不正書き換え

ドメインレジストラを経由した登録において、そのドメインを管轄するDNSサーバを変更して自サーバへ誘導

有名サイトと1文字違いなど、typo違いを狙うのもドメインハイジャックの亜種と言えなくもない domain squattingにちなんでtyposquattingと呼ぶ

41

アップデートハイジャック系

ソフトウェアアップデートの通信先にマルウェアを置くサーバ乗っ取り、DNSインジェクション、など

2019/4のASUS Live Updateのハイジャックは記憶に新しい

例: EmEditorアップデートハイジャックを利用した攻撃[1]以下の様な.htaccessファイルがアップデート配布ディレクトリに置い

てあった

指定したIPアドレスの範囲からアップデート要求があれば別ファイルを配布

42

[1] https://jp.emeditor.com/general/今回のハッカーによる攻撃の詳細について/

SetEnvIf Remote_Addr “106¥.188¥.131¥.[0-9]+” installSetEnvIf Remote_Addr “133¥.6¥.94¥.[0-9]+” install(… 同様に70行 …)SetEnvIf Remote_Addr “124¥.248¥.207¥.[0-9]+” installRewriteEngine onRewriteCond %{ENV:install} =1RewriteRule (.*¥.txt)$ /pub/rabe/editor.txt [L]

公開ポートへの認証突破攻撃

ポートを公開しているサービスには認証が付随する物がある例: SSH、RDP、VNC、VPNなどの遠隔接続系のサービス

基本的な対策 (余計なポートを公開しない) (パスワードの強度確保や他との共有禁止、多要素認証、公開鍵認

証)接続元IPアドレスの制限

時間あたりの認証数の制限

認証失敗回数に応じた無効化(IPアドレス、アカウント) 近だと複数のIPアドレスから分散して攻撃してくることも当

たり前になってきている

詳細は後で

43

概要

公開サーバ一般に対する攻撃ポート公開中のサービスの脆弱性を狙った攻撃

サービス不能(Denial of Service)攻撃

サーバ接続のハイジャック

ウェブサービスの提供者/利用者への攻撃ウェブサービス提供者側への攻撃

ウェブサービス利用者側への攻撃

認証機構と突破の試み

44

ウェブサーバへの攻撃

コンテンツ配置の推測をもとにした攻撃 リンクの張られていないURLを推測

CGIやPHPスクリプトなどの外部プログラム呼び出しの実行を狙う攻撃想定範囲外のデータアクセスするHTTP POSTデータやURLクエリを

生成

ディレクトリトラバーサルによるファイルアクセス

サーバのコマンドライン処理呼び出しによるファイルアクセス

Content Management System(CMS)を含めたウェブアプリケーションを狙った攻撃バックエンドで動いているデータベース(DB)を狙った攻撃

45

HTTP GET

HTTP GET: ウェブサーバへのコンテンツ要求言語、ブラウザ、受付可能なメディアタイプ、なども送信

必要に応じて後述するCookieやAuthenticationなどの情報も送信

HTTP GETへのウェブサーバ側の応答コンテンツ(HTMLファイル、mp4動画ファイル、PDFファイル、など)それ以外の情報: 終更新日時、コンテンツのタイプ、など

必要に応じて後述するSet-Cookieなどの情報も送信

46

サーバクライアント

HTTP GET www.example.com

example.comのページ

待機

待機

HTTP POST

質問入力フォームやウェブ掲示板書き込みなど、クライアント側からサーバにデータの塊を送る時に利用一旦、ウェブサーバ側から質問入力フォームをHTTP GETしてから

HTTP GET要求の末尾に「入力フォームの内容」の羅列を追加する感じ各記入項目にはサーバ側で名前(name)が付けられている

47

サーバクライアント

HTTP GET www.example.com

example.comのページ

待機

待機

HTTP POST www.example.com + データHTTP GET www.example.com/?search=...

入力データに対応したページ 待機

HTTP POSTの例

48

名大ITヘルプデスクの質問入力フォーム

HTMLのformタグでpostが指定されている(上の赤線) 入力項目にはnameが指定されている(下の赤線)

URLクエリ

HTTP POSTと同様にウェブブラウザからウェブサーバ側へ情報を渡す方法

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クエリはブラウザのアドレスバーに表示されるため、おおっぴらに見えて欲しくない情報が露わになることも

49

HTTP Cookie

サーバ側からクライアント(のウェブブラウザ)に記憶させることができる情報

ウェブブラウザはCookieのドメインに対応するウェブサーバへの再アクセス時にはCookieの情報を送信

Cookieは変な値が設定されても大丈夫なようにすること!シーケンス番号、IDが推測可能だと特に狙われやすい

50

サーバクライアント 初回のGETリスエストの応答でCookieを設定Set-Cookie: id=78safdhj87, domain=example.com...

次回にexample.comにアクセスする時に、HTTP GETの中に以下を追加Cookie: id=78safdhj87

すでに1回アクセス済みの人への対応

CGIなどによるHTTP POSTやURLクエリの処理

HTTPの仕様には、HTTP POSTやURLクエリで受け取ったデータを処理する機能は無い

ウェブサーバ側のCommon Gateway Interface(CGI)機能を用いて外部プログラムを呼び出して処理よくCGIに使われるプログラミング言語のインタプリタをウェブサーバ

にモジュールとして組み込むこともある

近ではPHP(PHP: Hypertext PreprocessorもしくはPersonal Home Page tools)がよく使われる

受け取ったデータを管理するためのDBも同時に導入することは多い CGIで呼び出すプログラムからデータを直接ファイルシステムに保存

することはできるが、ファイル名管理などがめんどくさい

51

Content Management System (CMS)(1/2) コンテンツを登録するだけできれいなページを作成可能

データベースに登録されたコンテンツを、フォーマットして表示

代表的なCMSとシェア[1]WordPress 59.2% Joomla 6.9% Drupal 4.7%

PukiwikiなどのWikiエンジンもCMSの範疇

EC(Electric Commerce)サイト用のCMSもある EC Cubeがよく使われている印象がある

52

[1] https://w3techs.com/technologies/history_overview/content_management

Content Management System (CMS)(2/2) 本体だけでなく、プラグインにも脆弱性が見つかり、プラグイ

ンから攻撃されることも多々ある

PCのアプリケーションと同様、CMSを含むウェブアプリケーションのバージョンも 新にする CGIを実行するインタプリタやウェブサーバ用モジュールのバージョ

ンも 新にする

自主開発のウェブアプリケーションだと、 新にすると動かなくなったりする物が出てくるのがやっかい(obsoleteなライブラリ利用中とかで)

バックエンドのDBのバージョンもちゃんと 新にする

53

[1] https://w3techs.com/technologies/history_overview/content_management

ウェブサーバ上の本来は見えないデータを露わにする攻撃

ディレクトリトラバーサル

URLからの推測

コマンドインジェクション

SQLインジェクション

サーバサイドリクエスト偽造(SSRF: Server Side Request Forgery)

54

ディレクトリトラバーサル(1/2)

本来は見れない範囲にあるデータを見ようとする攻撃

CGIに値を渡すフォーム等のデータを指定部などで、本来見れないないデータを指定できてしまったりする例: 電子掲示板の書き込み番号など

<input type="hidden" name="datafile" value="file645"> hiddenをユーザ側からも見れないと勘違いした非常に初歩的な実装

多くのシステムでは".."は1つ上のディレクトリに移動を示す

→入力されても処理しないようにサニタイジングする

何らかのミスで処理してしまうと、本来は見れないパスワードやデータの閲覧が可能に /var/www/htmlなどが外部公開の 上位のはずが、それより上の

ディレクトリも読まれる

55

ディレクトリトラバーサル(2/2)

使っているソフトウェアが汎用の物ならば、データ位置はまず初期名称から変わっていない

例: 某Wikiの初期ディレクトリ/ファイル 名

.../wiki/webroot (本来の外部公開の 上位)

.../wiki/wiki-common (auth.iniとかがある)

.../wiki/wiki-dataルートディレクトリに出るまで..を繰り返して、

例: /etc/hogeの表示を試みる

../etc/hoge

../../etc/hoge

../../../etc/hoge以下、繰り返し

基本的な対策: 変な値が入力されても良いよう値をチェックあるいは、".."のサニタイジングを入れる

56

サニタイジング(sanitizing)

sanitize: 衛生的にする、消毒する、「無害にする」

(主にウェブアプリケーションで)入力データにおいて「そのまま処理すると有害」な部分を無害化するプログラミングにおけるエスケープ処理と似た感じ

サニタイジングしない… HTMLのタグを無理矢理閉じた後に、悪意のあるSQL、JavaScriptな

どを挿入される

OSコマンドへの引数の後に区切り文字を入れた後に別コマンド

よくやるサニタイジング HTMLのタグで使われる文字の処理: < → &lt; > →&gt; " →

&quot; ' → $#39; & → &amp; XSSやSQLインジェクション対策にもなる

その他の各種実行系(シェルなど)での区切り文字

57

URLからの推測

他のURLから推測可能なURLに未公開資料を置いてあった例: 「2016/kessan.pdf」をもとに「2017/kessan.pdf(未公開)」を発見

される

ウェブサーバ側でディレクトリインデクスを有効にしていて、全ファイル名&下層ディレクトリ名が閲覧可能だった 「2016/」とディレクトリ名でアクセスすると一覧が見えてしまう

その中に編集途中で公開時には消したデータを含む物などの都合の悪い物が…

対策: 不必要なファイルをウェブサーバに置かない

ディレクトリインデクスはデフォルトで無効に

58

コマンドインジェクション(1/2)

CGIで入力データをOSコマンドの引数にしている所でサニタイジングを忘れる LinuxベースのウェブサーバのCGIでOS(主にUNIX系)のコマンドを

呼び出している所でOSやシェルのコマンドを実行

WindowsベースのウェブサーバでPowerShellを呼び出している所でOSコマンドやPowerShellコマンドを実行

入力値に「シェル上の区切り文字を入れた後、実行にするコマンド入力」で成立例: 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」が連続実行される

59

コマンドインジェクション(2/2)

マルウェアをダウンロードして実行するコマンドのインジェクションも多い設置されるマルウェアもバックドアをしかけるタイプが多い

テンポラリファイル置き場(どのプログラムも書き込み権限がある場所)にダウンロードして実行させるパターンが多い

通常、CGIはユーザ権限で実行されているので、ファイル書き込み制約

他のサーバを操作するコマンドのインジェクションの可能性も外部からは直接アクセスできないサーバへリクエスト出すとか

基本的な対策: 入力された値の範囲のチェック

区切り文字のサニタイジング

CGIを実装したプログラミング言語の機能で実装

perlでファイル操作にはglob関数とかFind::Fileモジュールとか

60

SQLインジェクション(1/2)

引き渡された値をDBにStandard Query Language(SQL)を使って登録する時に発生

SQLを使って認証処理を同時にやっていたりすることもある例: ユーザ名とパスワードを問い合わせるSQL(条件文)を作り、真が

返って来たら認証成功

例: ログイン処理でフォームのユーザ名とパスワードが一致するか?フォームの入力はinuserとinpasswdとする

条件文例: user = 'inuser' AND passwd = 'inpasswd'何も対策されていないと、inpasswdに「a' OR 'a' = 'a」を設定する

→user = 'inuser' AND passwd = 'a' OR 'a' = 'a' ORに恒真節が入って常に真が返る →認証突破

61

SQLインジェクション(2/2)

DBの他のエントリを表示させるSQLを作り、情報流出につながることも

DBのテーブルにサーバ内のファイルを指定して、サーバ内の別データからの情報流出につながることも

データ管理の簡略化や、ウェブアプリケーション高機能化のためにDBが動いている事例は多い

基本的な対策: サニタイジング、値の範囲のチェック

62

サーバサイドリクエスト偽造(SSRF: Server Side Request Forgery) ウェブサーバ側から別ウェブページにGET/POSTなどのリク

エストを強制的に出させる

例: ウェブページプレビュー機能があるウェブアプリケーションにおいて、プレビュー先をURLクエリ/POSTで指定可能 CMSなどで編集後のページのプレビューで、テンポラリのページを生

成してそのURLを返すような実装とかで起こりうる

後述のCSRFのように、外部サービスへ影響を及ぼすことも可能例: ウェブ掲示板に書き込みリクエストを出す

ウェブサーバが組織内専用ネットワークのIPアドレスも持つ場合、組織内専用サーバにリクエストを出すことも例: プライベートIPアドレスを適当に埋め込んだURLを作ったら組織

内専用ウェブページらしきものが見えた

63

Web Application Firewall (WAF)

ウェブアプリケーションへのインジェクション系の攻撃に特化したファイアウォール

URLクエリやPOSTの値に、攻撃でよく見られる書式があったらブロック自分で検知ルールをカスタマイズすることも可能

ソフトウェアアップデートが出ていない新規脆弱性に対し、一時的にカスタムルール追加でブロックする運用とかもあり

設置形態ネットワーク上に設置するネットワークアプライアンス

ウェブサーバ内にウェブサーバと別プロセスとして動作

ウェブサーバソフトウェアにモジュールとして追加

64

概要

公開サーバ一般に対する攻撃ポート公開中のサービスの脆弱性を狙った攻撃

サービス不能(Denial of Service)攻撃

サーバ接続のハイジャック

ウェブサービスの提供者/利用者への攻撃ウェブサービス提供者側への攻撃

ウェブサービス利用者側への攻撃

認証機構と突破の試み

65

クライアント側(ウェブブラウザ側)で悪意のある動作を起こすもの

クロスサイトスクリプティング(XSS) クロスサイトリクエスト偽造(CSRF: Cross Site Request

Forgery) Cookie等を使った利用者追跡

セッションハイジャック認証済み情報(主にCookie)窃取

66

クロスサイトスクリプティング(1/3)

URLクエリやHTTP POSTでフォームへの特定の応答により、攻撃者が用意したスクリプト(プログラム)が実行されるフォームに書いた値や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="">

基本的な対策: 入力データをエスケープ < → &lt; > →&gt; " → &quot; ' → $#39; & → &amp;

67

クロスサイトスクリプティング(2/3)

略称はXSSウェブ関係でCSSだとCascading Style Sheetが先にあったため

Microsoft Edgeなどがクロスサイトスクリプティングフィルタを搭載 FirefoxではNoScriptアドオンとかで追加可能

有害なスクリプトをブロックするが、たまに誤検出することも

そもそも、攻撃者はフィルタにひっかからないかチェックできる

今度はXSSフィルタ悪用する攻撃も出てきたり…→EdgeからXSSフィルタを削除することも検討されたりする

68

クロスサイトスクリプティング(3/3)

クロスサイトスクリプティングを起点として、多種多様な攻撃を実現することが多いサーバのデータ閲覧など: SQLインジェクション、LDAPインジェクショ

ン、ディレクトリトラバーサル、OSコマンドインジェクション、Xpathインジェクション、メモリ初期化ミスを利用したメモリリーク

ユーザ側の閲覧データ加工: 強制ブラウズ、リモートファイルインクルード

MITMによる(セッション)ハイジャック: セッションID固定攻撃、HTTPヘッダインジェクション、(iframeなど上位のページを設定しての)Cookieの読み出し

その他: オープンリダイレクタを利用した誘導

69

クロスサイトリクエスト偽造(CSRF: Cross Site Request Forgery) ここでのリクエスト = HTTP POSTなどによるクライアントか

らサーバへのリクエスト XSSはブラウザ内で完結するが、CSRFは外部に出力

「偽のリクエストを作り、サーバ側のデータを書き換えたりできる」のがこの攻撃の特徴認証のあるページでも、ユーザが認証終了した後(認証済みCookie

を持っているとか)していたら書き換え可能

例: パスワード変更ページに攻撃者側があらかじめ設定したパスワードに変更

例: 掲示板への悪意のある書き込み

対策データ更新ページの遷移前後で追加のセッションキーを設定

データ更新承認時に再度認証を要求する

70

オープンリダイレクタによる外部サイト誘導

リダイレクト: 別URLのウェブページに転送すること HTTPヘッダのLocationヘッダの設定とか

動的に遷移先ページを変更できるウェブページの存在例: ログインしていなくてもある内容を見れるが、必要に応じて、「ログ

イン(or新規加入)」ボタンを押してログインしてもらうウェブページ

ログイン処理や新規加入処理の後は元のウェブページに戻らせたい

→リダイレクト先を呼び出し元ページに設定することで実現

このリダイレクト先を(URLクエリ/POSTなどで)好きなページに設定できたら?

→悪い人が攻撃ページに誘導するのに悪用可能 URLを見ただけでは、リダイレクタを備えたウェブサービスに見える

普通はサービス関連ページのみリダイレクト可能とする

(設定次第で)組織内サービス用のウェブページを見れてしまうことも

71

iframeとXSS併用による悪意のあるページの埋め込み

iframe(inline frame): ページの一部にフレームを設定して、別HTMLを表示するフレームワーク古来のframeと比較して、フレームの境目が分かりにくい

XSS系の攻撃においてよく悪用される攻撃(詐欺)ページの中にiframeで元のページを表示する

元ページの上にXSSで背景を塗りつぶした攻撃ページのiframeを置いて、元ページを隠蔽

攻撃JavaScriptを動作させるために透明もしくはサイズ極小のiframeを設定して、その中で攻撃JavaScriptを動作させるHTMLを表示

72

Cookie等を使った利用者追跡

Tracking Cookie: 利用者の追跡を目的としたCookie主に広告コンテンツが実施

例: サイトAに出した広告でCookieを設定 → サイトBに出した広告で設定したCookieを受け取る

通常は3rd party Cookie(閲覧中サイトとは違うドメインのCookie)となる

気になるならばブラウザで「Do not track」の設定と「3rd party Cookieの禁止」を実施しておく

それでも、IPアドレスやUser agent情報などからある程度は追跡できる

Supercookie HTTP Cookieと同等の物をHTTPとは別の処理の中で実装

例: HTML5のWeb Storage, Adobe FlashのLocal Shared Object 他にも、Canvas fingerprintingなど、利用者追跡の技術は

積極的に開発されている(有効性の高低はあるが) 古典的なWebビーコンもまだまだけっこう使われている

73

セッションハイジャック

認証通過状態IDを盗んで悪用するセッションハイジャック攻撃なる存在 (マルウェアを使って)ブラウザのCookie保存ファイルから盗む

そこまでやるなら、ブラウザに保存されたID/パスワードを盗むのも… (偽サーバ誘導とからめて)偽サイトに対してCookieを送出させる

Man in the Middle攻撃(MITM) BASIC認証のような生パスワードを流れる認証も同様

対策 https下のみcookieを要求するような設定にする

リクエストごとに新cookieを発行する

74

概要

公開サーバ一般に対する攻撃ポート公開中のサービスの脆弱性を狙った攻撃

サービス不能(Denial of Service)攻撃

サーバ接続のハイジャック

ウェブサービスの提供者/利用者への攻撃ウェブサービス提供者側への攻撃

ウェブサービス利用者側への攻撃

認証機構と突破の試み

75

認証への攻撃

多いのは、よくあるIDとよくあるパスワードの組での試行

昔はID側を固定していろいろ試す攻撃が多かったが、 近では、パスワード側を固定することも

認証通過後の状態管理のID(Cookieとか)の窃取もそこそこある認証が高度化するとこちらを狙うことが増えそう

ウェブサーバ側の認証の脆弱性を突く攻撃ももちろんある

「ユーザに他のサービスでのID/パスワードと強要される →他のサービスで流出 →悪用」もある(見た目は一発突破に)基本的に、ユーザの教育しかない

流出したIDの確認サイトなるものはあるが、そういう物の利用が活発になると、そこに情報売る動きが活発化しそうなのでよろしくなさそう

76

良いパスワード作成のヒント(1/2)

基本的な構成のネタ

英語で適当な文を作ってそれの頭文字語から変形固有名詞などの頭文字だけ大文字にするとか

数字や記号と似ているアルファベットを置換(単語の中のアルファベットをそのまま数字/記号に置き換えるのは意味なし)

例: Coronavirus Disease 19 is Quite a Huge Threat → CD19iQaHT (大文字打つの大変なので逆転) → cd19IaAht (必要なら一部を記号に置き換え)

厳密に言えば、年号が入るのは好ましくないが少し妥協

パスワード文字数上限が十分に多ければ、文そのままでもOK 身近な所のアルファベット+数字の羅列で覚えやすい物+α

例: 自分の身近ないろいろな物の型番

77

良いパスワード作成のヒント(2/2)

部分的な構成の強化ネタ

記号や数字は形状や語呂合わせで入れる

ただし、単語の一部を記号や数字に入れ替えるのは、すでにパスワードクラッカー側が対応しているので意味無し

長さ稼ぎに単語等の部分列を作って組み込む

入力しやすさを考えて右手と左手の順番やバランスを考慮素早く入力できるパスワードは入力時の手元覗き見に対して強い

絶対にやるな! IDや名前や単語を含める

3,4文字以上の連続した数字(長さの割に強度が上がらない)

78

パスワード認証

ユーザIDとパスワードで認証する一般的な方法

動作1. パスワード登録時は一方向ハッシュ関数を通した結果をユーザ/パ

スワード表に登録

2. 認証時には入力パスワードを一方向ハッシュ関数に通す

3. 双方の結果が一致すれば認証OK ユーザ/パスワード表が漏れても、基本的にただちに影響は

無い

パスワードがある程度複雑ならば、総当り攻撃などで破られるまでの時間は稼げる

79

ハッシュ

ハッシュ

shimada: 98ukjweruser: shimadapassword: testuser: shimadapassword: pwd

98ukjwer

js6k3asd不一致

パスワード表一致

パスワードのハッシュ化に関する話題

思った以上にパスワードをハッシュ化せずに平文で保存しているサービスは多い例: 宅ふぁいる便の平文パスワードを大量流出(2019/1) 「パスワードを忘れた時」に設定中のパスワードが出てくるサービス

には要注意

「ランダム生成パスワードを提示し、自分で再設定させる」方が良い

パスワードをハッシュ化する時のsaltって?システムごとに入力の末尾に追加する文字(例: hs)パスワードリスト流出時に、saltも手に入っていないとパスワード破り

ができない

80

そのままハッシュ shimada: 19f751a1user: shimadapassword: test

98ukjwer

19f751a1

パスワード表

一致test→tesths

ハッシュ

パスワードへの辞書攻撃

良く行われる辞書攻撃英単語の辞書、よく使われるパスワード一覧、など

“辞書+α(数字、アルファベット、など)”の文字列による攻撃

個人情報と関連した推測

パスワード認証ではユーザID側でも辞書は活用あるソフトウェアをインストールすると作られるユーザID臨時で作って消す忘れることが多いユーザID

近はリモート認証では認証回数制限は一般的

→乗っ取ったコンピュータから分散で認証破りの試みが来る

81

パスワードへのその他の攻撃

偽のパスワード入力欄への入力偽サイトへの誘導やproxyを利用した中間者攻撃など

パスワード入力欄(本物)の上に入力欄を作るXSS 認証連携で認可と勘違いさせて権限を得る

パスワードスプレー攻撃パスワードを固定してユーザID側を入れ替えて攻撃

どれだけセキュリティ啓発しても安易なパスワードを設定する人は一定の割合(某先生の研究では約1%)で残るため

(利用者が限定される)システム管理者側にとって脅威

82

ID: shimada ID: shimadaID: shimamuraID: shimomuraID: shitara

pwd: 123456pwd: qwwertypwd: asfdghpwd: 1q2w3e4r

pwd: 1q2w3e4r

多要素認証

認証時にIDとパスワード以外の要素を要求する認証普通は2要素だが、超重要システムだと3要素以上もありうる

重要: 2要素目は実質パスワードにならないようにすること 「毎回変わらない固定された文字列」はパスワードに他ならない

ダメな例: 電話番号、誕生日、郵便番号、など

2要素目を後から入れるシステムが多いが、ID/パスワードの有効性確認に使えてしまう物は好ましくない ID/パスワードを入れた段階で間違うと「間違いがあります」と言ってく

るシステム

83

認証サーバクライアント IDとパスワード入れて

はい、IDとパスワード

2要素目入れて

はい、2要素目

追加認証要素の例(1/2)

マトリクス認証: 個人ごとに異なる文字換算表を渡して、手元で変換させる例: ほわはぬろをほち→しまだ

ハードウェアトークン等による認証鍵生成

個人ごとに異なるシード値を入れたハードウェアトークンを渡す

時間や生成した回数などでシード値から毎回異なる数字を生成

例: 1234(シード値)×202005180845→162730(下位6桁)

認証サーバ側は前後の値も許容したり

近ではスマホアプリ版などもある(Google Authenticatorなど)

84

ち り ぬ る を わ か

ろ や へ に そ く あ い

わ ゆ ほ ぬ た け い ろ

を よ ま ね ち こ う は

ん ら み の つ さ え に

゛ り む は て し お ほ

゜ る め ひ と す か へ

れ も ふ な せ き と

マトリクス認証用の表

ハードウェアトークン

追加認証要素の例(2/2)

ワンタイムパスワード(OTP: One Time Password)を別の認証を使うサービスを経由して受け取る事前登録したメールアドレスや携帯電話のSMSなど

SMSへの攻撃は増えているので、SMS自体の安全性が微妙に

生体認証ただし、生体認証には「変更できない(しにくい)」という問題点もある

暗号鍵を入れたハードウェアトークン例: USBトークン、カードリーダー+カード

ソフトウェア的に認証サーバとの間で公開鍵認証を行う

利用者側の動きに応じて認証要素数を変える運用も

多要素認証の2要素目を狙った攻撃(シード、SMS)も増えている点には注意(安心しきってはいけない)

85

エセ多要素認証

多要素認証に見せかけて実質1要素認証と変わらない

パズル認証系 「合わせ絵パズルを解いて」「上と同じだけクリックで色を変えて」

認証の答えが同一ページにあるので、認証ですらない

25年前に情報工学科でやった画像処理の演習レベルで自動化可能でロボット避けでも役に立たないレベル

パスワードを2回入力させる長いパスワードを1回入れさせるのと安全性は変わらない

というか、勝手に個人情報を2つ目のパスワードにするのやめろ

認証時にOTP送付先メールアドレスを変更できる攻撃者からすると、自分のメールアドレスに変更すればOKなだけ

(ひょっとして「古いメールアドレスもう使えない」問い合わせ対策?)

86

FIDO(Fast IDentity Online)認証

認証の手間削減+サーバに認証情報を送らせない

公開鍵ベースの認証基盤

FIDO認証器側で秘密鍵と認証先IDを管理 FIDO認証器を入れるデバイスはユーザ側で準備

FIDO認証器利用時に各種認証を求める(閉じた世界で各種認証) サーバ側にはIDと公開鍵を登録(FIDO認証器を通じて) 認証時には、サーバ側がIDに対応した公開鍵で乱数を暗号

化して送りつける(正しく復号して送り返せたらOK)

87

認証サーバクライアント+FIDO認証器

認証OK

IDこれで認証します

秘密鍵でこれを復号して

はい、復号した

多要素認証の増加で認証通過状態の窃取が進む? 多要素認証を使うウェブサービスでも、再認証の面倒を省く

ために長く使える認証済状態Cookieを提供する所も多い酷い所になると、失効期限が(おそらく)無い所もある

→攻撃者からすると認証済状態Cookieを盗んだほうが楽に Cookie窃取だと、中間者攻撃系だけでなく、XSS系も使える

本当にクリティカルなサービスならば、認証済状態Cookieは短時間で失効させる(=短時間で新しいCookieに更新)

88

認証サーバクライアント IDとパスワード入れて

はい、IDとパスワード

2要素目入れて

はい、2要素目

認証OK、認証済状態Cookieはdf4f18dc6...

攻撃者

狙い!