雨がざあざあ降ってきて

という童謡（？）が昔あったなーｗ

改ざんパターン2の考察＆訂正追加

ちょっと違うかもしれねえ…というところが出てきたので，補遺と追加を．

昨日，書いたところのうち，以下の記述は多分正しい．

これは改ざんのために，何らかの処理系やコマンドプロセッサに含まれるビルトインコマンドの"echo"を動作させたかったというように見える（実際，スクリプトの終わりに，”キャラクタを確認出来た）．

実際，検証用に（かなり省略したシェルスクリプトを）書いて動作させたら，エスケープ等が取れた形でを表示させることが出来た．

しかし，以下の部分は違う可能性が高い．

これはおそらく，Webアプリ等の脆弱性を突いて内容を送り込んだつもりが，内容を送り込む機能のエスケープ機能が有効に働いた結果，このような中途半端な改ざんに終わったのではないか？と考えている…．

実際は，Webアプリ側での内容を送り込む機能におけるエスケープ処理などは通過しておらず（汗），攻撃者が送り込んだ改ざん「のためのスクリプト／コマンドの内容」がそのまま反映されたようにしか思えない*1．

*1:自分でなんでそんな思い違いをしたのか？というのはあるが…反省

上記の間違いに気付いた結果，さらにおもしろい仮説が…

それは，「改ざんのためのツールを作る側」と「改ざん内容を作る側」の間で意思疎通を取り切れていないのではないか？ということ．例えば以下のような感じ．

• 改ざんのためのツールを作る側：「もらった内容を埋め込むよ」
• 改ざん内容を作る側：「サーバ上で実行して，改ざん内容を反映する内容を作ったよ」
• 改ざん攻撃を実行する側：「ツールとデータ使って改ざんしたよ！でも思うようなことが起きない！」

あと，不幸にして改ざんされてしまったところの内容を見ても，「手当たり次第片っ端から改ざんできそうなところに改ざん内容を反映している」というようにも見える．
それも，改ざんされるコンテンツがどのようにサーバサイドで処理されるかを念頭に置いていないため，JSPコンテンツも通常のHTMLコンテンツも同じように改ざんした結果，同じような効果を得られない，という状態になっている．
これは，「改ざんツールを作る人＝改ざんデータを作る人＝改ざんを実行する人」だったら，まず発生しないはず．というのも，攻撃対象を定めたら，手段を決めて，どのような内容を埋めるか？もあわせてツールを作り，攻撃を実行するであろうことを連想できるから．

でもこれって，おそらく過渡的なものだろうとも取れるので，油断は出来ないわけだ．

可視化で使ったツール

目grep職人推奨ツールｗのStirlingです．
全部英語だと全部真っ赤となるわけですが，日本語がそれなりにあり，かつ改ざん箇所の大きさがだいたい全部いっしょくらいなので，オレみたいなヌルい目grep初心者未満ｗでもアタリを付けられるわけです．

カード情報漏えいのおわびが届いたよ

以下読めばわかるけど，なんというか「最大3000円」という風．とはいえ近日中に出かける出張には，このクーポンの金額範囲だけでは調達は出来ないなー*1．

• クーポンコードの有効期限は、2014年5月31日まで
• 一度に使えるクーポンコードは一つだけ
• 払いだされたクーポンコードを使えるのは一回だけ
• 利用時の金額が3000円に満たない場合はそれで完了
• クーポンコードは、譲渡可能

…使うのにまたカード情報預けるのは嫌だな…．SIMフリーのスマートフォン持ってるので，今回は現地でSIM調達することに決定！

*1:あんだけのことをされて，まだ使いつづけると？ｗ

改ざんを受けた際の対策／改ざんされてないサイトの要確認内容

piyokangoさんのところに書かれている内容でおおよそいいのかな？とも思うけど，なにげに玄人向けなところもあるので，少しだけ観点ごとにひらいてみる．
とはいえ，昔から言われてることばかりなので，書いてて今更感が出てきたのは内緒だｗ

• Webサーバ管理を行う端末の観点
  • OS（Windows）とアプリケーション（Adobe製品，Javaなど）の最新化を行い，Exploit撃たれても感染しづらいようにする
  • ウィルススキャナを最新化しておく
  • できればWebサーバ管理を行う端末は専用のものにする．仮想マシンでもOKかと思うけど，母艦がやられて通信内容パチられる可能性ってのもあるので，できれば独立させておいたほうが吉
• Webサーバ構成の観点
  • OSやOSのパッケージ管理ソフトウェアにより管理されるソフトウェアは最新のものにしておくのは当然として，パッケージ管理ソフトウェアで管理していないものがある場合は，これもアップデートを行う．例えば，Javaアプリケーションサーバの中には，パッケージになっていないものもある（例：Tomcat）．これは，Oracle Javaを使っている場合は同じことが言える．.htaccessを改ざんされるパターンも確認されてるようだけど，これはコンテンツ改ざん可能な状況であれば普通に有り得る．mod_rewriteなどを使っているのであればしょうがないけど，使わないのであれば，無効にしておこう（仮に改ざん成功しても攻撃は失敗するので，不幸は最小限にできる）．
  • アカウント管理はきっちりと．ただ，権限昇格の脆弱性が残存していたりすると，一般ユーザ権限で入られた時点でアウチなので，前述のとおりOS環境の最新化を．
• Webアプリの観点
  • 穴ありのWebアプリはすでに論外．せめてWebアプリケーションのセキュリティ試験はしておこうよ…
  • オープンソースとして配布されているCMSなどを使うのはよいとしても，不要なもの（例：ドキュメント類）などは消しこんでおこうよ…
• コンテンツの観点
  • コンテンツのバックアップ重要．書き戻せるように．
  • コンテンツの保護重要．そもそも書き換えられないように．Webコンテンツを書き換えるだけの権限があっても，システム管理全体を行うのでなければ，アカウントを「コンテンツ更新のために必要最小限の権限を割り振ったものだけを使う」ようにしていれば，無効にしてあるモジュールを有効にするためにはまだ一枚壁がある．めんどくさいから全部rootでとかいうのは勘弁してほしい…．

Gumblarの時と最近のヤツと何が違う？

最近のドライブバイダウンロード攻撃に直結する改ざんは，コンテンツや.htaccessを直接改ざんする手段に加え，例えば以下のような手段を用いることもある．

• 悪意あるカーネルモジュールをinsmodする
• Webサーバに対し，悪意ある機能追加モジュールを追加の上，有効化する

幸い，まだこの2つの手段を併用しているものは（この数日で見られたものの中には）ないようにも見えるが，穴を塞いだつもりが別の扉が開いていた，なんてことも普通にありうるので，油断は禁物．

クレームなり何かを申し立てる際のパターン＆アンチパターン

ほぼ今更ながらという感じはするが，一応自分で実践している範囲のことなので，まぁいいだろう．
だいたいこういう時に思い出すのは，山崎はるかさんの書かれた記事「もちろん本気・はじめてのイタメール犯告発」の中の以下のくだりだ．

郵便局が「口頭」で貯金から現金を引き出せないのと同じように、「警察署への訴え」も当然「所定の書類」が必要である。
すくなくとも、手ぶらで「ギャーギャー」苦情を陳べに行くところではない。

実はこの内容は，警察に何かを訴える以外にも，あらゆるところに応用が効く．
上記の中で「警察署への訴え」に対応して「所定の書類」と書かれているのが，「○○」に対して「××」というコピペ風に入れ替わるくらいのことだとオレは認識している．

なので，「○○」に必要な「××」を準備するということを念頭においておくのがよいだろう．

さらに，たいていの場合「××」の準備にあたって必要となるのが「事実」であり，その事実から合理的に推測される「おこりうること」だったりする．少なくとも「事実」は必要だ．
そして，その事実に対応して「何をしてもらいたいのか」というのも重要である．単に事実を言うだけだと「ご意見拝聴いたしました」というコピペレスポンスが返ってきておしまい，ということにもなりかねない．

せめて「こういう事実があるのだけど，どうしたらいい？（もしくはおたくはどういう対応をとってくれる？）」という質問形式にしておくことをおすすめする．こうすれば，よほどのカスい内容やデムパな内容でもない限りは，（相手の忙しさ等にもよるだろうが）何らかのお返事が返ってくるかもと期待できる．

逆に，やってはいけないこと〜アンチパターンとでもいうか〜は，以下のようなこと．

• 対応相手の人格否定
• 感情に任せて怒鳴る
• 延々ととりとめのない苦情とも愚痴とも付かない内容を並べ立てる

ちゃんとした対応を求めるのであれば，いずれも論外．特にサポート窓口に対してこれをやっては，窓口の人のモチベーションを下げるばかりで何もいいことがない．どうせならば，窓口の人もこちらの味方に付けるくらいの丁寧さがあってもよいくらいだろう．

基本，どんなにひどいことをされたからといって，自分を貶めることはない．いかなる時も冷静に*1．

とはいえ，自身の生命の危険や（物理的な）危害を加えられる予感を感じた時は，「とりあえず逃げろ」としか言いようがないわけだがｗ

*1:もちろん，されたことや受けたしうちにもよるが，感情に任せるばかりではたいていロクなことにならない