【バグハンターインタビュー】EdOverflow

バグバウンティとはなにか、脆弱性診断の種別などについて詳しく知りたい方は脆弱性診断とは(⾮エンジニア向け)もしくは脆弱性診断とは(エンジニア向け)もぜひご参照ください。

【バグハンターインタビュー】は、バグバウンティ業界のエキスパートが、バグの種類や傾向について光を当てるインタビューシリーズです。

Edwin Foudil(通称EdOverflow)は、伝説的なカエルのプロフィール写真で知られているだけでなく、バグバウンティコミュニティへの積極的な貢献と、Webサイトがセキュリティポリシーを定義できるようにする標準案security.txtの作成でも知られています。

バグバウンティの分野では、Edは通常とは異なる独創的なバグを発見することで知られており、その多くはアプリケーションやそのコンポーネントの基本ロジックに潜んでいます。今回は、彼のワークフローと思考過程を知るために、インタビューにご協力いただきました。

目次

Ed、ようこそ!あなたのことを「学者」あるいは「バグバウンティハンター」などとお呼びすることができると思いますがなんとお呼びしましょうか?

IT分野に関して言えば、私のことは、セキュリティの研究とバグハンティングに情熱を注ぐWebデザイナー兼デベロッパーと呼ぶべきかもしれませんね。

セキュリティ分野での活躍をご存知の方も多いと思いますが、そもそもWebデベロッパーというのは興味深いですね。

私はかなり幅広く関心を持っていますが、サイバーセキュリティはそのうちのひとつです。セキュリティとバグバウンティは、主にオープンソースソフトウェアから入りました。オープンソースプロジェクトに貢献したことが、Web開発のセキュリティ面や安全なコードを書くことに取り組むきっかけになりました。

現在に至るまでを教えてください。

奇妙なことに、すべては”釣り”から始まりました。湖の美しい景色を見て、写真やPhotoshopに興味を持ち、それがWebデザインとWeb開発の道に入るきっかけとなりました。

Web開発からセキュリティへの橋渡しをしたのは、私の深い好奇心からだと思います。

プロジェクトを作るときはいつも、「自分は正しいことをしているのだろうか?」「誰かが私のコードを破ることができないだろうか?」と絶えず自問しています。

そして、メディアで情報漏洩の記事を読むと、どうしてそんなことが起こるのだろうと思うようになります。こうした攻撃に関する記事を読んで、私は倫理的ハッキングを試してみたいと思うようになり、そこで私は、セキュリティに詳しいスイスの地元企業をテストしはじめました。そして、その企業の脆弱性開示プログラムに参加しました。

その後しばらくして、他のバグバウンティプログラムを見つけ、夢中になりました。

Webサイトがセキュリティポリシーを定義するための規格案であるsecurity.txtを共同作成することになったそうですが、その経緯を教えてください。

バグハンターなので、問題を発見して解決するのが好きなんです。実際、高校時代にはプロジェクトのアイデアをまとめたToDoリストを持っていました。やがて夏休みになり、ラスベガスで開催されたDEF CON(セキュリティカンファレンス)に参加する機会がありました。そこで、同じ志を持つ人々と出会い、素晴らしい時間を過ごしました。帰りにニューヨークに立ち寄り、そこでJoel Margolis(@0xteknogeek)と出会いました。私たちは、セキュリティ業界が直面している課題について多くの時間をかけておしゃべりをしました。そこで、インスピレーションを受けホテルの部屋に戻った私は、ToDoリストを手に取り、箇条書きのうちの1つに取り掛かりました。それが security.txt です。一晩かけて最初の仕様書を書き上げ、GitHubで公開し、寝る前に何人かの友人に送りました。

https://twitter.com/EdOverflow/status/896498239368712192?s=20&t=2b8mwNbEupgqhw6OkaIO1w

目が覚めたら、携帯電話が通知でいっぱいでした。

業界の複数の人が「security.txtを実現させたい」と支持を示していたのです。

そこで私は、このコンセプトを正式なインターネットドラフトとして完成させるために数カ月を費やすことにしました。

この「数カ月」が3年になったのです。どのようにしてアイデアがインターネット標準になるのでしょうか?

IETFのメーリングリストに投稿すると、他の人がアイデアに対しコメントし、建設的な批評をすることができます。

これは標準化プロセスの非常に重要な部分であり、仕様を可能な限り良くするために、あらゆる種類のフィードバックを受け入れる必要があります。

中途半端なアイデアでは、インターネット標準になることはできません。

4、5番目のドラフトになったとき、私はロンドンで開かれたIETFの会議に出席し、IETF SecDispatchワーキンググループのためにsecurity.txtについて5分間の講演をする機会を得ました。このようなミーティングでは、自分のアイデアがなぜそれが重要なのか、どのように実装したいのか、そしてなぜIETFが仕事を採用すべきだと思うのかを説明することになるのです。

その後、Hummingにてアイデアをどうすべきか最も望ましい選択肢に同意を得るのです。security.txtの場合は、IETFの中でドキュメントシェパードを決めて、プロジェクトのフォローアップをすることがコンセンサスとなりました。ドキュメントシェパードが提案の準備ができたと思ったら、RFC承認前の最終段階である「Last Call」段階が始まります。Last Callは1月7日に終了したので、今度はRFCエディターに送られ、語彙や文法のダブルチェックを受けた後、インターネット技術運営グループ(IESG)に送られ、RFCにするかどうかが決められました。

一朝一夕にインターネット標準を公開することはできませんよね。

このようなことは何年も前から決まっていることなので、プロセスには多くの段階が存在するのです。私は幸運にも、IETFのプロセスに詳しい共著者のYakov Shafranovich(@nightwatchcyber)のサポートを受けることができました。

過去数年間、security.txtのためにすべての仕事をこなしてきたわけですが、バグバウンティをする時間は残っていたのでしょうか?

私は金銭的にバグバウンティに頼っているわけではないので、暇なときにやっています。週に1時間のときもあれば、それ以上のときもあり、気が向いたときだけです。

多くの人がフルタイムでバグバウンティをやっているのに、どうやってバグを見つけることができるのですか?

私は、バグバウンティの資産に関する情報とメタデータを収集する自動化されたセットアップを持っています。ハッキングする時間を見つけたら、できる限り手動でテストを行います。もちろん、IDOR(Insecure DirectObjectReferenceという脆弱性)やXSSなど、より一般的な問題のテストも行いますが、バグハントをしながら新しいコンセプトを学ぶことが一番の楽しみです。一番良いのは、新しい攻撃ベクトルを考えるのに、携帯電話やノートパソコンが必要ないことです。電車やバスの中でも、ベッドで横になっているときでも、潜在的なロジックの欠陥について考えることができるのです。

アプリケーションのロジック欠陥を発見する方法とは?

ロジックの欠陥を発見する前に、深く掘り下げ、アプリケーションを理解する必要があります。これは、コンポーネントがどのように相互作用するかを視覚的に概観したり理解したりするだけでなく、アプリケーションのコードとコーディングスタイル、特にクライアント側のコードが多く含まれる場合には、そのスタイルも理解することを意味します。開発者が何をしていたか、何を考えていたかを感じ取ることです。「なぜ、このように設計したのでしょうか?」「 なぜ、そのようなことをするのでしょうか? 」「なぜ、彼らは最初の場所でアプリケーションを開発したのでしょうか?」などです。 

私は開発者としての個人的な経験から、何かを書くことに集中していて、アプリケーションの他の場所で開発しているコンポーネントと行われる機能や相互作用に気づいていない可能性があることを知っています。

ロジックの欠陥は通常そこで発生します。

開発者の考え方を知るにはどうしたら良いですか?

私は通常、ターゲットのドキュメントを読んだり、ユーザーとしてそのアプリを使ったりすることから始めます。そして、そのターゲットについてGoogleで検索し、他のユーザーやジャーナリストがその製品についてどのようなことを語っているのか、検索を絞り込みながら読んでいきます。そうすることで、アプリケーションに限定するよりもはるかに多くのことを学ぶことができます。私のアプローチに明確な構造はありませんが、最終的には必ず、機能性とコンポーネントの相互作用をグラフにします。それをホワイトボードや紙を使うなど手作業で行っています。アプリケーションを理解するためには、明確な概要が必要なのです。そうすると、数学の問題を解くように、いくつかの事柄が浮かび上がってきます。そして、データの流れを追いコンポーネントに予期せぬ振る舞いをさせる方法がないかどうかを確認します。このようなことを見抜くには、ある程度の練習と経験が必要ですが、最終的には直感が働くようになります。例えば、企業がどのように金融取引を処理しているかを学べば学ぶほど、より多くの実装や潜在的な間違いに気づくでしょう。常に進化し続ける学習プロセスであり、アプリケーションをテストした数週間後にロジックの欠陥の存在に気づくこともあるので、自分の思考プロセスやアイデアを記録しておくことは重要です。

ロジックの欠陥を探すのに特に興味深い分野を1つ挙げるとすれば、私は「統合」を挙げます。サードパーティのコンポーネントを組み込んだアプリを見かけたら、そのサードパーティを利用し、どのように統合されているのかを学んでください。ほとんどの統合機能は、特定のユースケースを想定して設定されていますが、それを追加する開発者は、その統合機能が可能にする全範囲について知らないかもしれません。サードパーティから送られてくるデータのサニタイズは簡単にテストできますが、その背後にあるロジックを自動化された方法でテストすることはできません。

統合についてですが、あなたのブログの記事「CI knew there would be bugs here」は、@Portswiggerの「best write-up of the year」にノミネートされましたね。どのようにしてそれを思いついたのですか?

私は、これまでバグハンターによって未開拓だった新しく儲かる研究分野を探しており、それを「金鉱」と呼んでいます。です。継続的インテグレーションサービスのバグを探すというアイデアは、オープンソースプロジェクトでの仕事から得ました。Travis CIは、プルリクエストを出すとあちこちで見かけるし、ログが公開されていることも知っていたので、どんな問題が発生するのだろうと考えていたんです。その後、その分野の先行研究を発見したのですが、バグバウンティの文脈で適用している人を見たことがなかったのです。

「金鉱」はいつまで非公開で、いつ公開するのかを決めているのですか?

それは、必ずしもお金に左右されるものではありません。現実には、私は自分の研究を裏付けるために実際の事例を見つける必要があり、必然的に、私が多くの事例を報告すればするほど、多くの人が知ることになります。それに対してできることは迅速な報告なので、可能であれば自動化することを心がけています。継続的インテグレーションの仕事では、5人のグループで、短時間でできるだけ多く報告しました。

また、技術を公開するのはやむを得ないことです。結局のところ、自分の仕事を公開すれば、他の人が参加する機会になり、自分がツールを改善する機会にもなります。それに、自分が培ってきた技術であるということは変わらない事実です。

バグハンターが研究の方法を学び、これらの「金鉱」を発見する最良の方法は何でしょうか?

私が言える最良のアドバイスは、自分のバグハンターとしての経験を書くことです。バグバウンティのブログを立ち上げるのに、世界一のライターである必要はありません。ただ、そうすれば、探索すべき興味深い分野の感触を自然に身につけることができるのです。

他の人の研究を読み、自分の研究と比較すること。

つまり、「自分ならこれを見つけられたか?」「自分ならどうするか?」と、業界を追いかけ、新しい技術が生まれる場所を見つけ、それらの技術について読み、どのように統合されているかを確認します。問題を発見し、それに取り組み、そして最も重要なことは、それについて書くことです。解決策が見つからなくても、書きながら自分の考えを構造化することで、解決策が見つかるかもしれません。

論理的な欠陥の検出を自動化することは可能でしょうか?

ロジックの欠陥の検出は、自動化することは不可能ではないにしても、難しいプロセスです。もし開発者が論理的欠陥のユニットテストを書けないのであれば、ツールやスキャナの結果に論理的欠陥が現れることは、そう遠くない将来にないように思われます。

企業がロジック欠陥を防ぐための最善の方法は何でしょうか?

ツールに頼ることはできないので、開発ライフサイクルの早い段階で発見したり、防止したりする人間が必要です。この分野の仕事をもっと発表することで、人々がその存在にもっと気づいてくれることを期待しています。開発者だけでなく、製品の初期設計段階で不本意ながらロジックの欠陥を導入してしまう意思決定者やビジネスパーソンも同様です。

出典:Intigriti

https://blog.intigriti.com/2020/02/03/bug-business-1-inside-logic-flaws-with-edoverflow/

———————————————

バグバウンティプログラムを活用してみる

スリーシェイクは欧州を代表するバグバウンティプラットフォームを提供するIntigritiと世界で初めて提携。高い技術力を持ったスリーシェイクのセキュリティエンジニアが、専門的なトリアージ・英語でのコミュニケーションなどの運用を代行。セキュリティ領域の専門家がいない、社内のリソースをかけられない企業もバグバウンティプログラムを活用できます。

バグバウンティ運用代行サービス『Bugty』

4万人のバグハンターによる
世界レベルでのセキュリティ・サービス品質を実現
Securify Bugty

ブログ一覧へ戻る

サービスに関するご質問・ご相談など
お気軽にお問い合わせください