2017-02-01

例えばこんなSSI

概要

資生堂の子会社「イプサ」が運営する「イプサ公式オンラインショップ」にて、SSIインジェクションによる情報漏えいが発生したことを受けて、改めて「SSI」および「SSIインジェクション」の概要、影響、およびその対策を調査・確認した．
ここではその調査・確認内容を記載している．

背景

2016年12月2日、資生堂の子会社「イプサ」が運営する「イプサ公式オンラインショップ」にて情報漏えいが発生したとのニュースがあった．魚拓
この時点においてリリースPDF（魚拓）では「原因の解明と再発防止に向け社外の有識者を交えた調査を引き続き行い（以下省略）」とあり、はっきりした原因は解明できていなかったが、2017年1月31日、続報として以下の情報が報道された．魚拓
 (公式PDF)株式会社イプサ公式オンラインショップへの不正アクセスに関する調査報告書 (魚拓)

調査報告書を確認したところ、SSI、および原因の分析について以下のような記載があったが、その内容に疑問を覚えたので調査・確認に至った．

SSIについて（「ウェブサーバの操作を正規に行うためのプログラム技術」とは？）

SSI⁴の脆弱性を突かれ、（以下省略）
4: SSI（Server Side Includes）はウェブサーバの操作を正規に行うためのプログラム技術
原因の分析（「当該技術の利用箇所を限りなく少なくするなど」は対策となるのか？）

イプサ公式サイトの開発・運用体制において、SSI 技術の利用に関する脆弱性の認識が甘く、当該技術の利用箇所を限りなく少なくするなどの対策が取られていませんでした。

SSI(Server Side Includes)の概要

代表的な Web Server Software である Apache には以下のような記載がある．

Apache
Apache httpd Tutorial: Introduction to Server Side Includes - Apache HTTP Server Version 2.4

SSI (Server Side Includes) are directives that are placed in HTML pages, and evaluated on the server while the pages are being served. They let you add dynamically generated content to an existing HTML page, without having to serve the entire page via a CGI program, or other dynamic technology.

Google翻訳

SSI（Server Side Includes）は、HTMLページ内に記載され、ページが提供されている間にサーバー上で評価されるディレクティブです。CGIプログラムやその他の動的な技術を使ってページ全体を提供することなく、動的に生成されたコンテンツを既存のHTMLページに追加することができます。

たとえばhtmlソース中に<!–#include file=“header.html” –>と書けば、記載箇所にheader.htmlが、<!–#include file=“footer.php” –>と書けば記載箇所にfooter.phpが読み込まれる、というもの．これは読み込み対象（例で言うとheader.html、footer.php）が動的に変化しても呼び出し元に手を加える必要がないという点で便利な機能である．

実際的な例であれば、企業さんのWebページで、以下のようなどのページにも表示させたいヘッダとフッタがある場合、SSIを使用するとすべてのページに次のように記載をすれば実現可能である．

ヘッダの記述例
<!–#include file=“header.html” –>
表示させたいヘッダ例
フッタの記述例
<!–#include file=“footer.html” –>
表示させたいフッタ例

※例であって、画像の実際のページでSSIは使用されていない．

ヘッダ/フッタに変更を加える場合、呼び出されているheader.html、footer.htmlを変更すれば、呼び出している全ページの表示に変更が適用されるため、メンテナンスコストが少なく済むメリットを持つ．

SSI 設定例

Apache HTTP Server の場合について触れる．
OS : CentOS 6 系
Apache : 2.2.15(yum インストール) ※古いのは脆弱性の検証環境のため

/etc/httpd/conf/httpd.conf

<Directory "/var/www/html">
    〜
    # Options 設定にSSIインクルードを追加
    # "+"がOptionsへの追加宣言、Options設定を〜の箇所で行っていない場合、"+"は不要
    Options +Includes

    # SSI を適用する拡張子の指定（デフォルトは.shtml等特別な拡張子のみ有効）
    # 脆弱性検証のため、.htmlおよび.phpを指定
    AddOutputFilter INCLUDES .html .php
</Directory>

上記のように設定し、指定したディレクトリに以下のようなファイルを用意する．

index.html

<!--#include file="hello.html" -->

hello.html

<html>  
<body>  
Hello, world  
</body>  
</html>

index.html にアクセスすると以下のように表示される

f:id:news-nknskn:20170201040304p:plain

SSIインジェクションの概要

安全なウェブアプリケーションやウェブサービスのセキュリティの改善を目的とした共同研究や関連活動を行っている非営利団体｢OWASP」によると以下の通り．

The Server-Side Includes attack allows the exploitation of a web application by injecting scripts in HTML pages or executing arbitrary codes remotely. It can be exploited through manipulation of SSI in use in the application or force its use through user input fields.(中略)
In any case, the attack will be successful only if the web server permits SSI execution without proper validation. This can lead to access and manipulation of file system and process under the permission of the web server process owner.

The attacker can access sensitive information, such as password files, and execute shell commands. The SSI directives are injected in input fields and they are sent to the web server. The web server parses and executes the directives before supplying the page. Then, the attack result will be viewable the next time that the page is loaded for the user’s browser.

Server-Side Includes (SSI) Injection

ユーザからの入力を適切な検証（HTMLエスケープ、入力値のバリデーション）なしに出力しているWebアプリケーションにおいて、HTMLページに例で示したようなスクリプト（<!–#include file=“hello.html” –>）を挿入された場合に、挿入されたSSIが実行されてしまうという問題である．ここの例ではファイルのインクルードを示しているが、SSIではWebサービス実行ユーザ権限でのOSコマンド実行も可能である．
OSコマンドを実行する場合、<!–#exec cmd=“ls” –> というように記述する．

SSIインジェクションの影響

Webサービス実行ユーザ権限でのOSコマンド実行が可能なため、以下のような影響が考えられる．

不正な外部ファイルの読み込み (ダウンロード後にinclude)
マルウェアのダウンロードおよび実行
サービス実行ユーザで閲覧可能な範囲での情報漏えい

さらに、サーバに権限昇格可能な脆弱性が存在する場合、攻撃者にサーバを乗っ取られる可能性が考えられる．
※余談：WebアプリケーションにSSIインジェクションが存在する場合、そのアプリケーションではそもそも入力値のチェック、入力データを出力する際のHTMLエスケープ処理が行われていない可能性がある．そのためデータベースへ登録処理を行う箇所ではSQLインジェクション、入力確認画面におけるXSS（クロスサイトスクリプティング）も存在する可能性が考えられる．

検証例

1.入力値をエスケープせずに出力

以下のようなデータ送信画面、および入力確認画面があったとする．
- input.html

<html>
<body>
<br>
<h1>データ送信</h1>
<form action="output.php" method="post">
<input type="text" name="data">
<input type="submit" value ="送信">
</form>
</body>
</html>

f:id:news-nknskn:20170201043444p:plain
- output.php

<html>
<body>
<?php
$data = $_POST["data"];
echo $data; // Vuln
?>
</body>
</html>

f:id:news-nknskn:20170201043542p:plain ※input.html において値を"test"として「送信」を押下した際の画面

input.html において、値を「<!–#exec cmd=“curl https://www.google.co.jp” –>」として「送信」を押下すると、以下のように、ブラウザにてサーバ上でcurlコマンドを実行した結果を確認することができる．
f:id:news-nknskn:20170201044216p:plain

2.SQLインジェクションが成功しデータベースにSSIのスクリプトが混入、データをエスケープせずに出力

以下のようなデータ出力画面があったとする．
ここでは簡略化のため「PDO::〜」等を省略して「file_get_contents(‘db.result’);」としている．
~~「$output」~~「$data」にはselect文の結果（SSIスクリプト）が混入していると想定．
- output.php

<html>
<body>
<?php
$data = file_get_contents('db.result');
echo $data; // Vuln
?>
<br>
<a href="input.html">戻る</a>
</body>
</html>

混入しているスクリプトは下記の通り．
- db.result

<!--#exec cmd="cat /etc/passwd" -->

output.php にアクセスすると以下のようになる．（一部マスク） f:id:news-nknskn:20170201050120p:plain

対策

どちらの場合も入力データの出力箇所である"echo $data;“においてエスケープを行うことで、SSIインジェクション対策となる．phpであれば、例えば以下のような記述．

<html>
<body>
<?php
$data = file_get_contents('db.result');
echo htmlspecialchars($data); // Not Vuln
?>
<br>
<a href="input.html">戻る</a>
</body>
</html>

f:id:news-nknskn:20170201051156p:plain

※出力箇所におけるエスケープ処理はXSSの対策にもなる．SQLインジェクション対策にはならない．

2017/2/1 追記
httpd.conf のOptionsにて以下のように設定するとexecを除き、SSIを使用することができる．

Options +IncludeNOEXEC

まとめ

上記の検証例には記載していないものもあるが、SSIインジェクションが存在するアプリケーションにおいて、外部リソースへのアクセス、外部ファイルのダウンロード、およびOSコマンド実行の動作確認を行った．上記の通り、Webサーバを動作させているユーザの権限で実行可能であることを確認した．これによってバックドアページの設置等、今回のインシデントにつながる動作を確認できたと思われる． SSIを利用する上でのSSIインジェクション対策は、ユーザからの入力値を出力する箇所においてエスケープ処理を行うこと、もしくは暫定的な回避策としてIncludeNOEXECを設定することが考えられる．

参考

2016-12-11

SECCON 2016 Writeup(Vigenère, Anti-Debugging)

今回チャレンジした問題（Vigenère, Anti-Debugging）のWriteupです.
2問しかチャレンジしてないのでちょっとした手順も書いてみました.
# 今度はちゃんとSECCONに向けてスケジュールを調整したい...（去年も同じことを呟いたような）

Vigenère

下記のような問題でした。

k: ????????????
p: SECCON{???????????????????????????????????}
c: LMIG}RPEDOEEWKJIQIWKJWMNDTSR}TFVUFWYOCBAJBQ
k=key, p=plain, c=cipher, md5(p)=f528a6ab914c1ecf856a1d93103948fe
|ABCDEFGHIJKLMNOPQRSTUVWXYZ{}
-+----------------------------
A|ABCDEFGHIJKLMNOPQRSTUVWXYZ{}
B|BCDEFGHIJKLMNOPQRSTUVWXYZ{}A
C|CDEFGHIJKLMNOPQRSTUVWXYZ{}AB
D|DEFGHIJKLMNOPQRSTUVWXYZ{}ABC
E|EFGHIJKLMNOPQRSTUVWXYZ{}ABCD
F|FGHIJKLMNOPQRSTUVWXYZ{}ABCDE
G|GHIJKLMNOPQRSTUVWXYZ{}ABCDEF
H|HIJKLMNOPQRSTUVWXYZ{}ABCDEFG
I|IJKLMNOPQRSTUVWXYZ{}ABCDEFGH
J|JKLMNOPQRSTUVWXYZ{}ABCDEFGHI
K|KLMNOPQRSTUVWXYZ{}ABCDEFGHIJ
L|LMNOPQRSTUVWXYZ{}ABCDEFGHIJK
M|MNOPQRSTUVWXYZ{}ABCDEFGHIJKL
N|NOPQRSTUVWXYZ{}ABCDEFGHIJKLM
O|OPQRSTUVWXYZ{}ABCDEFGHIJKLMN
P|PQRSTUVWXYZ{}ABCDEFGHIJKLMNO
Q|QRSTUVWXYZ{}ABCDEFGHIJKLMNOP
R|RSTUVWXYZ{}ABCDEFGHIJKLMNOPQ
S|STUVWXYZ{}ABCDEFGHIJKLMNOPQR
T|TUVWXYZ{}ABCDEFGHIJKLMNOPQRS
U|UVWXYZ{}ABCDEFGHIJKLMNOPQRST
V|VWXYZ{}ABCDEFGHIJKLMNOPQRSTU
W|WXYZ{}ABCDEFGHIJKLMNOPQRSTUV
X|XYZ{}ABCDEFGHIJKLMNOPQRSTUVW
Y|YZ{}ABCDEFGHIJKLMNOPQRSTUVWX
Z|Z{}ABCDEFGHIJKLMNOPQRSTUVWXY
{|{}ABCDEFGHIJKLMNOPQRSTUVWXYZ
}|}ABCDEFGHIJKLMNOPQRSTUVWXYZ{
Vigenere cipher
https://en.wikipedia.org/wiki/Vigen%C3%A8re_cipher

古典暗号の Vigenère Cipher （問題文のリンクを参照）によって暗号化された平文を解読する問題です.
Vigenère Cipher は簡単に言うと、横軸に平文一文字、縦軸に鍵一文字を取り、テーブルを参照したときに該当する文字が暗号化した文字として出力される暗号です（リンクを読んで知った）.
平文長 > 鍵長の場合、暗号化には鍵に用いられた文字列が繰り返し適用されます.
このことから、暗号文の出力は簡易的に以下のように考えることができます.

p[x] = 'plain text'
k[x] = 'key text'
c[x] = 'ciphe text' # 文字数合わせのため、誤字ではありません
table[28] = ABCDEFGHIJKLMNOPQRSTUVWXYZ{}
c[i] = table[(p[i]_index + k[i]_index) mod (table length)]
# ここでは _index は 対象の文字がtableの何文字目か を示しています.

今回の問題だと鍵（k）の長さは ? の数（12）、平文（p）の長さ（=暗号文の長さ）は 43 です.
良い解読手法を知らなかった/思いつかなかったので k は総当りで探し、p が示されている md5(p) と一致した場合に p を出力するスクリプトにします.（圧倒的勉強不足）

事前準備
今回のテーブルは上記の通り 'ABCDEFGHIJKLMNOPQRSTUVWXYZ{}' で、table 長は 28 です.
鍵を完全に総当りをすると 28¹³ （6502111422497947648 = 2⁶² < 28¹³ < 2663）となってちょっとした時間がかかるため、事前準備として分かる箇所を出します.
p = SECCON{
c = LMIG}RP
上記から k = VIGENER (7 文字) であることがわかります.
確認できた内容と問題のタイトルからなんとなく 8 文字目は E っぽい（VIGENER(E) かな？）です.
ひとまず、平文すべてに暗号化を行う際の鍵は以下と仮定します（8文字目(Rの次)の E が不確定）.
k = VIGENERE????VIGENERE????VIGENERE????VIGENER
次に残りの4 文字の ? について総当りします.
脳直スクリプト

% python vigenere_dec.py
SECCON{ABABABCDEDEFGHIJJKLMNOPQRSTTUVWXYYZ}

正解でした.

Anti-Debugging

bin というファイルをダウンロードし、フラグを見つけ出せ、という問題です.
とりあえず file と strings を叩きます.

% file bin
bin: PE32 executable for MS Windows (console) Intel 80386 32-bit

Windows でデバッグですかね.

# 以下はコメントです
% strings bin
!Enjoy CTF! . # 楽しんでますよ
Richw0B
.text
`.rdata
@.data
.rsrc
（中略）
ollydbg.exe
ImmunityDebugger.exe
idaq.exe
Wireshark.exe
Input password >
I have a pen.
Your password is correct.
But detected debugger!
（But 〜系が続くため省略）
But detected Debugged.
;aj&@:JQ7HBOt[h?U8aCBk]OaI38 # flagっぽい
check!
password is wrong.
（中略）
Process32Next
Process32First
CreateToolhelp32Snapshot
（アンチでバッグで使用する関数や DLL とかその他諸々. 以下省略）

「Input password >」「I have a pen.」から、起動したらパスワード入力のルーチンがありそうです.
また、アンチデバッグ機能はある程度含まれている模様.
そのあとに暗号化してある文字列を復号してどこかしらに出力してくれる流れでしょうか.（そうであってくれという願望）
Wireshark を検知しているところを見ると通信も見せたくないのかな？なんてことも頭に入れておきました（意味はありませんでした）.
とりあえず見た感じアンチデバッグには少なくとも IsDebuggerPresent とプロセス名での検知がありそうです.
ひとまずバイナリエディタで見つけた文字列の exe を ex_ と変更しておきます.（要らない）
次に、おもむろに IDA で bin.exe (拡張子 .exe を付加) を開き、デバッグしていそうなところを特定します.
「Input password >」で検索.

f:id:news-nknskn:20161211204300p:plain

OllyDbg で飛ぶとこんな感じです.

f:id:news-nknskn:20161211205255p:plain

下の方にアンチデバッグしている箇所がちょいちょいあり、フラグを書き換えるのがめんどくさいので暗号文を用意しているっぽい箇所に飛んでみます.
# 00401663 に New origin here

f:id:news-nknskn:20161211205335p:plain

ちょっと動かしてみると for で回っていることがわかります.
めんどくさいのでひとまず MessageBoxA の直後にソフトウェアブレークポイントを設定、F9.

f:id:news-nknskn:20161211205807p:plain

出ました.

flag : SECCON{check_Ascii85}

簡単な感想

Webに触れたかった...
あとuncomfortable webは脆弱性のある kernel だったら権限昇格して楽にささっと解けるかもなー、と思ってバージョンとか見てみたけどダメだったので諦めました.
# CentOS 6.8 2.6.32-642.11.1.el6.x86_64、2016/11/19 にリリースなんですよね...くそう.

以上です.