[インターンレポ] 脆弱性診断をやってみた

こんにちは。
インターンの田邉です。
マネーフォワードのセキュリティを支えている「CISO室」にて、脆弱性診断を担当しています。

この度、社内で脆弱性診断を実施し無事に報告まで終えることができたので、その気づきとまとめを投稿します。

注意!

脆弱性診断の手法のなかには攻撃行為となるものも含まれています。
自分の管理下にないシステムに対しては脆弱性診断を行わないでください。
 

インターンをすることになったきっかけ

私は大学で情報セキュリティを専攻しています。

日本で毎年行われているCODE BLUEという情報セキュリティの国際会議に、昨年、学生スタッフとして参加しました。

その時のアフターパーティーで、スポンサー参加していたマネーフォワード@ken5scalさんと出会い、マネーフォワードのインターンに誘っていただきました。
 

脆弱性診断について

脆弱性診断とは?

「システムに攻撃を行い、悪いところがないか調べること。」
多少の語弊はあるかもしれませんが、一言で言えばこのようなイメージです。
もちろん、ただ攻撃して終わりではなく、攻撃した後に検証を行ってリスクを分析し、報告するまでが脆弱性診断です。

脆弱性診断の種類

脆弱性診断は、診断の対象とするシステムによっていくつかの種類に分類されます。

  • Webアプリケーション脆弱性診断 ・・・ Webアプリケーションの脆弱性有無を調査する
  • プラットフォーム脆弱性診断 ・・・ サーバーやサーバー上で動作するミドルウェアの脆弱性有無を調査する
  • ペネトレーションテスト ・・・ 組織内(たとえばオフィス)のネットワークに侵入できるか、ネットワークに侵入された場合にどのような脅威があるのかを調査する

この中で、私がインターンで行っているのはWebアプリケーション脆弱性診断(これ以降、診断と呼びます)です。
 

診断の流れ

診断には以下の3つのフェーズがあります。

  1. 自動診断
    • 診断ツールを使用して行う
    • ツールによって自動的に攻撃、リスク分析、報告書の作成が行われる
  2. 手動診断
    • 手動診断ツールを使用して行われることが多い
    • 自動診断で発見が困難な脆弱性を見つけるために行われる
    • 診断対象サーバに対して手動で攻撃コードを実行する
  3. 報告
    • 報告書を作成する
    • 報告会を開催する

以降では、各フェーズで私が行った内容について書いていきます。
(参考にした書籍については後述します。)

1.自動診断

今回は、私が参考にした書籍で紹介されていた「OWASP ZAP」という診断ツールを使用しました。

適切な設定を行い、診断のボタンを押すだけで、報告書まで作成してくれるのでとても便利です。しかし一方で、診断結果が間違っていることも考えられるので、しっかりと検証する必要があります。

今回の診断でも検証した結果、適切に処理されているにも関わらず脆弱性として報告されたものがありました。

OWASP ZAPの操作画面

上図では、すでに設定を終えているので、「動的スキャン」をクリックするだけで診断がスタートします。

2.手動診断

今回は、私が参考にした書籍で紹介されていた「Burp Suite」という診断ツールを使用しました。

Burp Suiteを使用することで、通信内容を確認することや同じ内容のパケットを複数回送信することなどができます。
また、パケットを攻撃コードに細工して送信することもできます。

Burp Suiteを使用することで、自動診断ツールでは検知できない脆弱性を効率的に調べることができます。
自動診断ツールで検知できない脆弱性の例として、以下の2点が挙げられます。

  1. 攻撃用のパラメータを送信しても、すぐにその影響がでない脆弱性(例:データベースに保存された文字列が別のタイミングで表示されるときに攻撃が成功してしまう)
  2. 仕様の段階で生じる脆弱性(例:ユーザから入力されたクレジットカードの番号を全桁表示してしまっている)

3.報告

報告にはgithubのissueを活用し、脆弱性を見つけた時には、その脆弱性に対するリスクの高い低いに関係なくいったんissueとして報告しました。
これにより、報告会での議論の結果、必要なものだけをissueに残すことができます。また、簡単に修正できそうなものに関してはプルリクエストを出しました。
 

診断の中での気づき

診断を行う上で注意したこと

診断はテスト環境で行いました。
しかし、テスト環境だったとしても、リンクをたどった先が本番環境だったり、外部のWebサイトだったりします。
今回は診断ツールの設定を行い、診断対象外のドメインが宛先となっているパケットは破棄するようにしました。

上図の設定を行うことで、指定したURL以外のパケットは破棄されるようになります。

ユーザ企業が社内で診断することのメリット

ここでは、診断をアウトソーシングではなく社内で行うことのメリットについて私の意見を書かせていただきます。

私は以下の4つの理由があると考えています。

  • コスト面
    • 診断を行うには専門的な知識が必要となるので、診断をアウトソーシングすると相当なコストがかかる
    • 社内で診断を行うことで、コストを低く抑えることができる
  • リスク分析面
    • 社内システムを理解した上で診断を行うことができる
    • 社内システムを考慮して各脆弱性のリスク分析を行うことができる
    • プロダクトオーナーとの議論の場が設けやすい
  • 社内セキュリティの向上
    • 診断によって、攻撃技術についての知見を社内に蓄積することができる
    • 蓄積された知見によって診断の技術がさらに向上する
    • 社内に知見を共有することで、社内全体のセキュリティ意識が向上する
  • プロダクトへのコミット
    • githubのプルリクエストによる修正依頼をだすことができる

上記の理由から、マネーフォワードは積極的に社内で診断を実施していきます。

今回学んだこと

プロダクトオーナーと密に連携を取りながら、脆弱性診断の一通りの流れを体験することができました。
そして、報告フェーズでは、プロダクトにプルリクエストという形でコミットすることができました。

今後の行うこと

今回得た知見を活かして、MFクラウドの別のサービスの診断を行う予定です。
今回の診断では、リスク分析が甘かったり、検証に時間がかかってしまったりすることがあったので、次回の診断ではスピーディーに診断を行っていきたいです。

今後気をつけること

今回の診断における決定的なミスは、作業ログを取っていなかったことです。
エンジニアとしては当然のことなのかもしれませんが、作業ログを残すことの大切さに気づけていませんでした。

また、社内の情報共有ツールでの報告が疎かになってしまっており、自分のやっていることがブラックボックス化してしまっていました。
今後は、積極的にアウトプットして、社内での情報共有に努めていきたいと考えております。

参考にした書籍

最後にどうしても伝えたいこと

プロダクトオーナーの方と密に連携を取りながら診断を進めることができた点が、今回の診断の最大の収穫だったと考えています。

私をランチに誘っていただき直接コミュニケーションをとる機会を多くとることができました。
その結果、報告するだけの一方向の診断ではなく、報告に対する議論が活発に行われる双方向な診断をすることができました。

今後も双方向の診断を目指し、プロダクトオーナーの方と連携しながら診断を行っていきたいと思います。

 

マネーフォワードでは、エンジニアインターンを募集しています。
ご応募お待ちしています。

【採用サイト】
マネーフォワード採用サイト
Wantedly | マネーフォワード

【プロダクト一覧】
自動家計簿・資産管理サービス『マネーフォワード』
Web
iPhone,iPad
Android

ビジネス向けクラウドサービス『MFクラウドシリーズ』
会計ソフト『MFクラウド会計』
確定申告ソフト『MFクラウド確定申告』
請求書管理ソフト『MFクラウド請求書』
給与計算ソフト『MFクラウド給与』
経費精算ソフト『MFクラウド経費』
入金消込ソフト『MFクラウド消込』
マイナンバー管理ソフト『MFクラウドマイナンバー』
資金調達サービス『MFクラウドファイナンス』

メディア
くらしの経済メディア『MONEY PLUS』

Pocket