MBSD Cybersecurity Challenges 2018で優勝した【2連覇】

![公式ロゴ](img/win-the-1st-in-mbsd-cybersecurity-challenges-2018/mbsd_cybersecurity_challenges_2018_logo.png)

こんにちは、[8ayac](https://twitter.com/8ayac)です。先日、[MBSD Cybersecurity Challenges 2018](http://setten.sgec.or.jp/cooperation/060.html)というコンテストで優勝しました。[去年](https://twitter.com/8ayac/status/940922733088555008)に続き2年連続の優勝です。

この記事では、前述のコンテストの予選から最終審査会までの色々を書きたいと思います。

## コンテストについて

コンテストの概要は、[こちら](http://setten.sgec.or.jp/cooperation/060.html)のページに全て載っているので、必要に応じて参照して下さい。この記事では、競技内容に焦点を当てた紹介をしておこうと思います。

### テーマ

テーマは、「フォレンジック調査」でした。コンテストの設定は、公式に書かれている通りです。(以下参照)
> ある会社で開発したSNSのシステムにセキュリティ上の問題があると指摘されていたにも関わらずそのまま運用を続けていたところ、何者かに攻撃されてしまったようです。
> あなたのチームは、攻撃の全貌を解明できるでしょうか。

### 競技内容

このコンテストには、一次審査と最終審査があります。一次審査では、攻撃を受けたWebサイトのシステムと改ざんされる前のWebアプリケーションのソースコードを元に、「どのような攻撃を受けたか」「影響範囲はどのくらいか」を調査し、そのレポートを提出します。レポートを提出する相手には、攻撃を受けたWebサイトを運営する企業を想定するみたいでした。そして、一次審査で優秀なレポートを提出した上位10チームが最終審査会に進み、一次審査で提出したレポートに関する内容でプレゼンを行います。そのプレゼンと、一次審査のレポートに対する審査の総合点で最終的な順位が決定されます。

### 大会期間

大会期間は、以下の表の通りです。

| 内容                  | 期間                              |
| --------------------- | --------------------------------- |
| チームエントリー受付  | 2018年10月10日(水)～11月20日(火)  |
| 課題配布              | 2018年10月22日(月)～11月20日(火)  |
| レポート提出期限      | 2018年11月20日(火)                |
| 一次審査結果発表      | 2018年11月27日(火)                |
| 最終審査会            | 2018年12月12日(水)                |

課題配布期間内であれば、チームエントリーが済んだチームから課題が配布されます。課題の配布が始まる前にチームエントリーを済ませておけば、一次審査のレポート作成には最大で約一ヶ月ほどを充てることができます。最終審査会は一次審査の結果発表から約二週間後に行われます。

### 審査観点

審査観点については、公式のものを引用します。
以下のような審査観点に基づいて、レポートやプレゼンが採点されるようでした。

> #### 攻撃に使われた脆弱性
>
> どのような脆弱性を使って、どのような手順で攻撃を行ったのかがわからないと、サイト復旧後もまた同じ被害を受けます。(攻撃に使われなかった脆弱性は様々ありますが）まず何から対策に着手すれば良いのかの判断にも重要な情報です。
>
> #### 被害の範囲
>
> どのようなデータがどのくらい、漏えいや破壊がされたのかわからないと、事業に与えるインパクトが判断できません。またもしサイト利用者のデータに被害が及んでいる場合は、利用者に対して謝罪をする必要があるかもしれません。
>
> #### 対応方法
>
> 被害を受けた会社は今パニックになっているでしょう。直近で行うべき暫定対策や、長期的に取り組む恒久対策など、対応方法を提案してください。
>
> #### 調査で行った工夫
>
> ツールを使った・作った、チームメンバーの役割分担、調査手法など、解析を網羅的・効率的に実施するために行った工夫があれば、ツール名やソースなど具体的に記載しアピールしてください。

## 予選(一次審査)に関すること

### 気合

何事も「気合」が大事だというのが、文化系に見えてゴリゴリの体育会系である私達のサークルの教えです。2連覇を狙っていました。我々のチームは、部室で「優勝する人！」と言って手を挙げた人達同士で組んだチームです。同じ学校から出たMOFFU_MOFFU_ISCにも挙手していた人はいましたが、私達のチームは全員が「優勝する」と宣言したチームだということもあり、負けるわけにはいきませんでした。大会期間中、各チームの気合で満ちた部室は殺伐としていました。

### 調査の進め方

調査は、基本的には、各々の技術や知識に依った調査をバラバラに進めていき、それをスプレッドシートにまとめていくという進め方をしていました。そして、そのスプレッドシートを基にチームで疑問点などを解消していくことで、攻撃の全貌を明らかにしていきました。調査期間には一次審査で使える時間の約三分の二を費やし、残りの時間でスプレッドシートの内容を基にレポートを作成しました。

役割分担は、概ね以下の通りです。各人が以下に書かれている作業以外もしていますが、ここでは「主に担当した作業」についてまとめています。

- [@8ayac](https://twitter.com/8ayac)
  - チームリーダー
  - 攻撃者的な視点での作業全般
  - 攻撃の検証方法作成
  - 不足している証跡等の洗い出し
  - 自然言語担当(レポート作成)
- [@iria_piyo](https://twitter.com/iria_piyo)
  - フォレンジックのプロ
  - ファイル系の調査
  - タイムスタンプの紐づけ
- [@mnao_305](https://twitter.com/mnao_305)
  - 対策は俺に任せろ
  - 一般的な調査作業
- [@somebody_gp](https://twitter.com/somebody_gp)
  - ツールを使ったマルウェアの検出
  - ツールを使ったログ解析
  - 被害範囲の列挙

私達のチームは、Blue寄りの人間が多かったので、私は攻撃者的な観点から調査を支援していました。自己評価ですが、各々の知識や技術に依った調査が行き詰まってきた終盤で、かなり威力を発揮できたと思います。終盤では、その時点で出揃っている証跡を一つ一つ吟味して、攻撃の成功の可否や再現を行い、「こんな証跡があったら嬉しい」という情報を他のBlueなメンバーに渡して調査してもらいました。そして、その調査結果をまた吟味して、以降ループといった感じに調査を進めました。初めからこの手法で調査を進められていれば、もう少し余裕を持ってレポートの作成に移れたと思います。

### 正確性と詳細さ

個人的に、大会の公式ページに書かれていた「あなたのチームは、攻撃の全貌を解明できるでしょうか。」という一文に対して闘争心を強く持っていました。チームとしても、その思いは強く、全員が「必ず攻撃の全貌を明らかにする」という闘争心をメラメラと燃やしていたと思います。

攻撃の全貌を解明したことを示すために、レポートの内容は詳細に書くように心がけました。具体的には、以下の情報を載せるようにしました。

- 確認した事象
- 事象の発生日時
- 確認した事象の検証方法(再現方法)
- 裏付けとなる証跡

正確性にもこだわりました。その理由は「フォレンジックだから」と言ってしまえばそれまでなのですが、個人的な理由としては、去年の大会で「誤検知が多い」という酷評を受けていたからです。今年は、非の打ち所がないような報告書を提出しようと心に決めていました。他にも、正確性の観点でいえば、言葉の表現が厳密になるように気をつけました。例えば、確認できた事象が「明らかなこと」か「推測されることか」を適当に区別していました。

実際のレポートの雰囲気はこんな感じです。

![実際のレポートを一部抜粋した画像](img/win-the-1st-in-mbsd-cybersecurity-challenges-2018/actual_report_screenshot.png)

### OSINT(?)

最終審査会で審査員の方がお話していたことによれば、今回の一次審査の課題として配布されたシステムは、二年前に開催された[MBSD Cybersecurity Challenges 2016](http://setten.sgec.or.jp/cooperation/037.html)のシステムとほぼ同じものでした。そのことは、過去の大会の情報は収集していたので「もしかしたら、これ同じかも...?」ぐらいの見当は付けていましたが、我々のチームのメンバーに2年前の大会に参加していた人が誰もいなかったので、確信は持てていないような状態でした。

過去の課題と同じシステムであれば、インターネットに落ちている過去の大会の情報が調査の役に立つかもしれないと考え、実際にはMBSD Blogの[過去記事](https://www.mbsd.jp/blog/20161222.html)などを参考にしました。とはいえ、実際に参考にした時点では、今回の大会でもDirty COWやSQLiなどの脆弱性が使われていたことは知っており、ほとんどの内容は既知のものでした。この記事を読んで気づいたことといえば、Heart Bleedの脆弱性が今回の調査対象のシステムにも残っていたことぐらいです。しかし、実際に攻撃されたと思われる証跡は確認できず、実際のレポートでは、考察の章の中で以下のように少し触れる程度にしておきました。

> 今回の解析ではHeartbleedの脆弱性を悪用した攻撃の証跡を確認することができなかったがHeartbleedを悪用した攻撃ではそもそも証跡が残らないため、実際にはこの脆弱性を悪用した攻撃が行われていた可能性がないとは言い切れない。[^1]

### 工夫点

我々は対象のVMの調査を行う上で、FTK Imagerというツールを利用していました。これを利用すると、様々な恩恵があります。デジタルフォレンジックでは定番のこのツールですが、実際に使ったチームはとても少なかったらしく、「アピールしていれば、もう少し点数高かったのかな。」という講評をいただき、とても悔しい思いをしました。このツールを使ったことがアピールできる「工夫」だという認識はなかったので、その話を聞いたときにはとても意外でした。

私達のチームは、当初はApacheLogViewerやSplunkなどを用いて調査を行っていましたが、途中からはgrep、awk、sort、cut、sedなどのUNIXコマンドを用いて愚直に調査を行っていました。課題のログの分量と提出までの期間を考えても、十分だったと思っています。もっと大量のログであれば、ログ解析ツールなどを使って本格的に調査を進めた方が良かったかもしれません。同じ学校から出ていた別のチームのMOFFU_MOFFU_ISCは、ELK Stackを用いた解析を行っていて、かっこいいなと思いました。([MOFFU_MOFFU_ISCの記事](https://azara.hatenablog.com/entry/2018/12/14/110104))

## 本戦(最終審査会)に関すること

### 発表内容に関する考察

最終審査会での発表内容には毎年悩まされます。
最終審査会の審査観点も前述の四点だとすると、全てを盛り込んで十二分で喋るというのが難しいなと感じます。
他のチームはうまくやっていて、特に「NEthernet Ⅱ」さん(東北電子専門学校のチーム)の発表が上手に作られているなと感じました。
そのチームの発表では、最終的に今後の対応を提案する対象である経営層に合わせて、技術的な発表を避けて図や表を多く使用して事実(実際に攻撃に使われた脆弱性/被害範囲)に関する説明を端的に終えていました。
そして、残った時間で本題である対応方法の提案をしっかりと伝えており、その内容も説得力があって関心しました。
対応方法に関する質問にも、落ち着いて、説得力のある回答をされていたのが印象的です。
「NEthernet Ⅱ」さんの発表の点数は「表示エラー」さんのチームと同点で一番高かったのですが、発表内容には「調査で行った工夫」に関することは含まれていなかったので、必ずしも審査観点の全てを、発表内容に盛り込む必要はないのかもしれません。

### IPFactoryの発表内容

私達のチームの発表のテーマは、「正確な原因究明には多くの証拠が不可欠」というものでした。大筋は、「ログやその他の証拠が十分に取れていないと、誤検知や見逃しが発生する可能性があります。
さらには、それに気づかない可能性もあるので、ログやその他の証拠は普段から十分に集めておくことが重要です。
今後は証拠収集のポリシーやルールの策定を検討する必要があると思いますが、いかがでしょうか。」といった内容です。

結果としては、コケたなという印象です。事実、発表の点数は下から二番目でした。色々反省があるのですが、全体的に説得力のない発表内容になってしまったなという感想です。

### 発表スライド

実際の発表スライドは[こちら](https://speakerdeck.com/8ayac/mbsd-cybersecurity-challenges-2018-zui-zhong-shen-cha-hui-fa-biao-suraido)

## 大会を振り返って

まず、何よりも、やはり優勝できて嬉しい。去年も優勝したが、当時は先輩に頼りきりだったので、今年は自分たちの力で優勝を勝ち取れたことが何よりも嬉しい。
また、去年は「誤検知が多い」と酷評を受け、とても悔しかったが、今年は「一番精度が高かった」と好評をもらえて嬉しい。
しかし、「ほぼ真相を解明できていた」という好評を受けた一方で、一点の間違いがあったことが悔しい。
なぜ、その点を見落としたのか、その原因をよく考察して次回以降に繋げたいと思う。

次に、DFIRをテーマにした今回のコンテストに取り組んでみて変化した自身の心境についてだが、このコンテストを通じてBlueな観点からの情報セキュリティにも非常に興味を惹かれた。
攻撃者の悪意を持った行動を辿る楽しさには、こういう機会でもなければ気づかなかっただろうと思う。
攻撃者の行動を辿る中で、徐々に真実が解明されていくパズルを解いているような感覚がとても気持ち良かった。
また、今回のチームでは攻撃者的な視点の私と他の防御側視点のチームメンバーの間で、お互いに気づかないことを共有できたことで、情報セキュリティをやっていく上でRedとBlueの視点のどちらも必要であることを肌で感じる事ができたのは良い経験だと思う。
これからは、極端にRedに寄らず、Blue的な観点も持つことが重要だと感じた。

最後に、今回の優勝は、チームで勝ち取ったものだと思う。
誰か一人でも欠けていれば、優勝はできていなかっただろうと心から思う。チームメンバーに謝辞を述べたいところではあるが、最近Twitterで、謝辞はビッグバンに対して述べると良いらしいということを知った。
ということで、ありがとうビッグバン。

## おまけ

<blockquote className="twitter-tweet">
    <p lang="ja" dir="ltr">
        MBSD Cybersecurity Challenges 2018で優勝しました。2連覇です！😎😎 <a href="https://t.co/bWSVAkIhLc">pic.twitter.com/bWSVAkIhLc</a>
    </p>
    &mdash; 8ayac(Yoshinori Hayashi) (@8ayac) <a href="https://twitter.com/8ayac/status/1072787615525392384?ref_src=twsrc%5Etfw">December 12, 2018</a>
</blockquote>

## 実際に提出したレポート(2019/01/14 追記)

私達のチーム(IPFactory)が提出した[レポート](https://drive.google.com/file/d/1TqSTRwXYYWOqvguZ-Y2CxOxAb3iy_Slx/view)を公開しました。
今回の大会の成果物は、共有することに大きな意義があると考えました。
私達の公開したレポートが、今回の大会に参加していた学生の方々や、その他の様々な方のお役に立てれば幸甚の至りです。

<iframe src="https://drive.google.com/file/d/1TqSTRwXYYWOqvguZ-Y2CxOxAb3iy_Slx/preview" width="450" height="625"></iframe>

## 注釈

[^1]: 実際のレポートより抜粋: 考察の章の中でHeart Bleedを悪用した攻撃の可能性について触れている部分


:page_facing_up: Migrate articles from Hatena Blog.

:recycle: Modify the image's source path.

Revert commits to enable image optimization.

公式ロゴ

こんにちは、8ayacです。先日、MBSD Cybersecurity Challenges 2018というコンテストで優勝しました。去年に続き2年連続の優勝です。

この記事では、前述のコンテストの予選から最終審査会までの色々を書きたいと思います。

コンテストについて

コンテストの概要は、こちらのページに全て載っているので、必要に応じて参照して下さい。この記事では、競技内容に焦点を当てた紹介をしておこうと思います。

テーマ

テーマは、「フォレンジック調査」でした。コンテストの設定は、公式に書かれている通りです。(以下参照)

ある会社で開発したSNSのシステムにセキュリテ…

document.domainに起因するSame-Origin Policyのバイパス

## はじめに

`document.domain`に関わる面白いSOPバイパスの手法を検証した。

## 概要

`document.domain`は古くからSOPを緩和するために使われてきたようだ。
例えば、同じ親ドメインを持つ2つのオリジン(例: `foo.exapmle.com`と`bar.example.com`)があり、SOPに縛られることなく互いに通信を行いたいとする。このとき、双方で`document.domain`の値に`example.com`を設定することで、2つのドメインは互いのDOMにアクセスすることができるようになる。
今回検証したバイパス手法は、この挙動を利用したものである。

## 条件

以下の条件を満たしているとき、SOPをバイパスできる。

1. 対象のページのdocument.domainが上位ドメインに設定されている
2. 問題のあるページのサブドメインのコンテンツをクライアント側で制御できる

## 検証

まず、被害者のサイトに見立てて、以下のような`victim.example.com`というページを用意する。

```html

<meta charset="utf-8">
<script>
    console.log(document.domain);
    document.domain = "example.com";    // vuln
    console.log("document.domainの値は次のように設定されています。: " + document.domain);
    document.write("このテキストはvictim.example.comに書かれたものです。");
</script>
```

このコードでは、5行目で`document.domain = "example.com"`としている。
そのため、攻撃者の用意する以下のような`attacker.example.com`で同様に`document.domain = "example.com"`とすると、攻撃者のページからも`victim.example.com`のDOMへのアクセスが可能になる。
攻撃の成立にはサブドメインのコンテンツを制御できる必要があるが、一般的な例ではSubdomain Takeoverでそれが可能になる。

```html

<meta charset="utf-8">
<script>
    console.log(document.domain);
    document.domain = "example.com";
    console.log("document.domainの値を次のように設定します。: " + document.domain);
</script>
<iframe src="http://victim.example.com/" onload="alert(contentDocument.body.innerHTML)"></iframe>
```

実際に`attacker.example.com`にChromeでアクセスすると、`victim.example.com`のページの内容を`attacker.example.com`から取得できていることが確認できた。

![attacker.example.comにアクセスした際の画面](img/bypassing-the-same-origin-policy-via-document_domain/the_result_of_accessing_attacker_example_com.png)

## 脅威

検証では、`attacker.example.com`から`victim.example.com`の内容を読み出せた。
もし、FacebookやTwitterなどに同じ問題(バグ)があった場合には、ユーザのメッセージやその他の情報を読み出される可能性がある。
また、`document.domain`に最上位ドメインである`com`や`org`などが設定されている場合には、`victim.example.com`に対して、例えば`evil.com`からの攻撃が可能になる。なお、現在は`document.domain`に最上位ドメインを設定できる主要ブラウザはSafariのみで、その他の主要ブラウザではエラーになる。(詳細: [https://hackerone.com/reports/398163/])

## まとめ

上位ドメインを共有する2つのオリジンのdocument.domainに、共有している上位オリジンを設定すると双方のDOMにアクセスできるようになる。
これを利用して、問題のあるページのサブドメインのコンテンツをクライアント側で制御できるとき、SOPをバイパスしてそのページのコンテンツにアクセスすることが可能になる。また、サブドメインのコンテンツをクライアント側で制御できるようにする方法としてSubdomain Takeoverが挙げられるが、主要ブラウザの中でSafariのみは`document.domain`に`com`や`org`などの最上位ドメインを設定できるため、Subdomain Takeoverが不要なケースがある。

## 感想

このネタはTwitterで見かけたもので、検証が簡単だったので記事にしました。
(HackerOneで公開されたレポートは追うようにしているけど、今回の記事に関連するfiledescriptor氏の[レポート](https://hackerone.com/reports/398163)は見落としてしまっていたなあ...。)
書き終わってから思ったのですが、2つのオリジンで`document.domain`の値を変更して同一オリジンにしてるのを、SOPのバイパスと呼んで良いものか微妙ですね。

あと、Safariでは`document.domain`に最上位ドメインを設定できるってところ、実はMacを持っていないのでWindows版Safari(バージョン5.1.7)でしか検証できていません。
もし、最新版のMacで検証した人がいたら、結果を教えていただけたら幸いです。
Mac買いたいなあ...。

## 参考資料

- [Bypassing Same-Origin-Policy - document.domain](https://www.aa7ifs.com/bypassing-same-origin-policy-using-document-domain/)
- [https://hackerone.com/reports/398163](https://hackerone.com/reports/398163)
- [クロスドメイン制約 を document.domain の 変更 で 回避 - galife](https://garafu.blogspot.com/2013/09/documentdomain.html)

はじめに

document.domainに関わる面白いSOPバイパスの手法を検証した。

概要

document.domainは古くからSOPを緩和するために使われてきたようだ。
例えば、同じ親ドメインを持つ2つのオリジン(例: foo.exapmle.comとbar.example.com)があり、SOPに縛られることなく互いに通信を行いたいとする。このとき、双方でdocument.domainの値にexample.comを設定することで、2つのドメインは互いのDOMにアクセスすることができるようになる。
今回検証したバイパス手法は、この挙動を利用したものである。

条件

以下の条件を…

JavaScriptのPrototypeオブジェクトについて

> この記事は、[dharani jayakanthan](https://dev.to/danny)氏の[Intro To Prototype - JS](https://dev.to/danny/intro-to-prototype---js-35a)の翻訳記事です。

## Prototype

JavaScriptで関数を作ると、JavaScriptエンジンが2つのオブジェクトを作ります。

JSエンジンが関数を処理するときに作られる2つのオブジェクトは、

- その関数自体を呼び出す`Function`オブジェクト
- `Prototype`オブジェクト

## `prototype`とは

JSの`prototype`とは、主に継承のために利用され、関数の`prototype`プロパティにメソッドやプロパティを追加して、それらのメソッドとプロパティをその関数のインスタンスで利用できるようにします。

```js
function foo() {
    console.log("Hello!!");
}
// foo.prototype
```

JSエンジンが`prototype`オブジェクトを作ると、プロパティも同時に作られます。関数内のこの`prototype`プロパティを使用して、その関数用に作られた`prototype`オブジェクトにアクセスできます。

例えば、`prototype`オブジェクトを指す`prototype`という呼ばれるプロパティを持つ`foo`関数を見てきました。`prototype`オブジェクトを使用するには、`new`というキーワードを使用してオブジェクトを作成します。

```js
var myObj = new foo();
// myObj
```

`myObj`オブジェクトを作ると、JSエンジンはデフォルトで"`__proto__`"というオブジェクトを持つオブジェクトを作ります。これは、関数によって作られた最初の`prototype`オブジェクトを指します。

## `__proto__`を使ってみる

オブジェクトを生成すると、JSエンジンが`__proto__`オブジェクトを作ることがわかったので、それがどのように機能するかを見るために、`myObj`オブジェクト内に`Hi from myObj itself`という値を持つ`say`プロパティを作ってみましょう。

```js
function foo() {}
var myObj = new foo();
myObj.say = "Hi from myObj itself";
```

`myObj.say`にアクセスすると`"Hi from myObj itself"`という値が返されることがわかります。値の異なる同じ名前のプロパティを`__proto__`オブジェクトに作ります。

```js
function foo() {}
var myObj = new foo();
myObj.__proto__.say = "Hi from proto object";
```

> `myObj.__proto__.say`にアクセスすると、`"Hi from proto object"`が返されます。

```js
function foo(){}
var myObj = new foo();
myObj.say = "Hi from myObj itself";
// Hi from myObj itself
myObj.__proto__.say = "Hi from proto object";
// Hi from proto object
delete myObj.say;
// true
myObj.say
// Hi from proto object
```

しかし、`myObj.say`を削除してから、それにアクセスしたとき、JSエンジンは`say`というプロパティが存在するかを確認するために、`__proto__`オブジェクトを調べます。そして、`"Hi from proto object"`という値を持つプロパティ`myObj.__proto__.say`が発見され、その値が返されます。

> オブジェクトを作ると、JSエンジンは必ず`prototype`と呼ばれる別のオブジェクトを作ります。その`prototype`には、`.prototype`というキーワードを使用することでアクセスできます。しかし、`new`というキーワードを使ってオブジェクトを使ってオブジェクトを作った場合には、JSは`prototype`オブジェクトを指す`__proto__`を作ります。
>
> オブジェクト内のプロパティを探すと、JSエンジンがオブジェクト自体の中にそれを発見した場合、それが返されます。もし、そのようなプロパティが存在しない場合は、JSエンジンは`prototype`オブジェクトを調べます。


この記事は、dharani jayakanthan氏のIntro To Prototype - JSの翻訳記事です。

Prototype

JavaScriptで関数を作ると、JavaScriptエンジンが2つのオブジェクトを作ります。

JSエンジンが関数を処理するときに作られる2つのオブジェクトは、

その関数自体を呼び出すFunctionオブジェクト

Prototypeオブジェクト

prototypeとは

JSのprototypeとは、主に継承のために利用され、関数のprototypeプロパティにメソッドやプロパティを追加して、それらのメソッドとプロパティをその関数のインスタンス…

MBSD Cybersecurity Challenges 2017で優勝した

![公式ロゴ](img/win-the-1st-in-mbsd-cybersecurity-challenges-2017/mbsd_cybersecurity_challenges_2017_logo.jpg)

先日、[MBSD Cybersecurity Challenges 2017](http://setten.sgec.or.jp/cooperation/049.html)というコンテストで優勝しました。  
その時のことを色々と書きます。

## 1. 大会の概要

コンテストの概要を説明しておきます。  
詳細は[こちら](http://setten.sgec.or.jp/cooperation/049.html)まで。

- 設定
  - ある会社が運営するオンラインバンキングシステムにセキュリティ上の問題が発生
  - 参加者は、このセキュリティ上の問題を調査するチーム
- コンテストの目的
  - セキュリティへの興味喚起
  - 現実的な問題へのチャレンジ機会創出
- 競技の概要
  - 1チーム4名のチーム戦
  - オンラインWebサービスのシステム(Linux VM)とWebアプリケーションのソースコード(PHP)が配布
  - 配布されたシステムに潜む脆弱性を調査
  - 調査内容と検出した脆弱性のレポートを作成し提出
  - 提出したレポートによる1次審査で上位10チームで最終審査
  - 上位10チームは、最終審査会でプレゼンを実施
  - レポート内容とプレゼンで審査の総合点を算出
- 審査観点
  - 発見した脆弱性の種類と数
  - 脆弱性の再現方法や対策案
  - 脆弱性の再現
  - 脆弱性発見の工夫
- 大会期間
  - チームエントリー受付
    - 2017年10月10日(火)～11月14日(火)
  - 課題配布
    - 2017年10月16日(月)～11月14日(火)
  - レポート提出期限
    - 2017年11月14日(火)
  - 一次審査結果発表
    - 2017年11月28日(火)
  - 最終審査会
    - 2017年12月13日(水)

大体こんな感じ。

## 2. 予選(一次審査)のこと

予選では、約一ヶ月の間、ひたすらシステムを攻撃し診断を行いました。  
私達のチームは、幾つかの役割に分担して診断を行いました。  
筆者は、診断ツールを用いたネットワーク診断・ミドルウェア等のパッケージの診断などを行いました。  
最終的には79件の脆弱性を報告し、レポートの枚数は109枚になりました。

### 工夫した点

工夫した点は、以下の通りです。

- CVSSv3やCWEなどを用いることによる定量的な評価
- 潜在的な脆弱性の報告
- PHPは気合で読む
- 楽しむ

レポート作成が思っていたより大変でした。  
中でも、想定される被害や影響や対策を考えるのが特に大変でした。

## 3. 本戦(最終審査)のこと

最終審査は、先輩が後進育成などの意味でも、スライド作成から発表までを1年生に任せてくれました。
とても良い経験ができたと思っています。
筆者はチームの中に2人いる1年生でも、暇な方だったので、この件ではよく働こうと頑張りました。  

一次審査の結果が発表されたのは、11月28日でしたが、私達のチームは予選は突破すると信じて、予選のレポートを提出してからすぐに本戦のプレゼンの準備に取り掛かりました。  
おかげで本番まで約1ヶ月をプレゼンの準備に充てられました。  

私達のチームは、発表では他のチームと差別化したいという考えがあり、「実装などの技術的な問題よりも、もっと上流の設計の話とかをする。」という方針が初めから決まっていました。  
しかし、そういった上流のことを勉強をしながら作っていたので、早くに取り掛かったにも関わらず、プレゼン用の資料が完成したのは本番の前日でした。  

設計などのことは、先輩が色々教えてくれて、とても勉強になりました。  
最後の方は、自分でも面白い資料を発見したりして、追い込まれながらも、とても楽しく取り組んでいました。  
今回の発表の準備を通して、技術的なことと同じぐらい設計などの勉強もしたいなと思いました。  

発表当日は、自分の出番が近づくにつれて緊張しましたが、宇宙のことを考えてみたところ、かなり緊張がほぐれました。  
とはいえ緊張しており、終始 **"オタク特有の早口"** で発表してしまいました。  
それでも、前日に完成した割には、よくやったと思っています。

### 工夫した点

工夫した点は、以下の通りです。

- 発表の準備に早く取り掛かった(予選突破を信じて)
- 他のチームとの差別化を考えた内容の選定
- 緊張を和らげるために宇宙のことを考えた

準備を進めていく中で、勝ちたいという気持ちが強くなっていき、どんどん大変になっていきました。  
最終的には、発表点が(確か)1番良かったので、嬉しかった。

## 4. 発表したスライド

発表したスライドは[こちら](https://speakerdeck.com/8ayac/mbsd-cybersecurity-challenges-2017-zui-zhong-shen-cha-hui-ffa-biao-suraido)です。

## 5. 反省点

反省点は以下の通りです。

- 発見した脆弱性の精査が追いつかなかったこと
- どのように精査すべきなのかを知らなかったこと
- 検証が追いつかなかったこと
- レポートの進捗状況をチームで共有できなかったこと

最終審査会の後の講評でも、「網羅性が高いが、誤検知が多い」と言われてしまったので、来年の課題だと思います。

## 6. まとめ

情報セキュリティを極めるには多くの知識と技術が必要であることを学び、肌で感じることができました。

~賞品として、「Burp Suite Professional １年間ライセンス」「三井物産セキュアディレクションでのインターンシップ参加権」「MBSD Cybersecurity Challengesオリジナルステッカー(金)(完全にビックリマンチョコのシール)」「Kindle PaperWhite」「Amazon ギフト券5000円分」などがもらえた。嬉しかったです。(小並感)~

## 7. 感想

全体的に、とても勉強になったコンテストでした。  
色々と大変なこともありましたが、とても楽しく取り組むことができました。  
自身のセキュリティへの興味は以前より強まったことは間違いありません。

脆弱性の検討をつける手法や、実際に発見する方法など、診断の大まかな流れをなんとなく体験することができてよかったと思います。  
とは言え、筆者はセキュリティの仕事をしたことがないので、「現実的な問題へのチャレンジ機会創出」を目的にしているこのコンテストの課題が、どの程度現実的な問題なのかわかりませんでした。  
以前から、セキュリティ系のインターンに行ってみたいという気持ちはありましたが、今回のコンテストでそれがとても強くなりました。  

来年は、Webアプリの脆弱性についての勉強をもっと本格的にして行こうと思いました。(低レイヤーの勉強もやっていきたいので、どっちに重きを置くかは要検討)  
基礎的な学習も怠らず、手を動かしながら色々なことを学んでいこうと思います。  
そして、その勉強の成果を来年のこのコンテストでも発揮できるように頑張ります。  

今回のコンテストでは、先輩から色々なことを教えてもらいました。  
筆者も来年から入ってくる後輩に、色々なことを教えられるように情報セキュリティに対するアンテナを、もっと高く張らなければいけないなと感じました。  

個人的には **"圧倒的成長"** を得るために、このコンテストに参加したのですが、技術的な面以外でもまずまずの成長が得られたと思います。  
この先も無限に強くなりたいと思います。

## 余談

最近「[リーダブルコード](https://www.amazon.co.jp/%E3%83%AA%E3%83%BC%E3%83%80%E3%83%96%E3%83%AB%E3%82%B3%E3%83%BC%E3%83%89-%E2%80%95%E3%82%88%E3%82%8A%E8%89%AF%E3%81%84%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E6%9B%B8%E3%81%8F%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AB%E3%81%A7%E5%AE%9F%E8%B7%B5%E7%9A%84%E3%81%AA%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF-Theory-practice-Boswell/dp/4873115655)」読み始めました。


公式ロゴ

先日、MBSD Cybersecurity Challenges 2017というコンテストで優勝しました。
その時のことを色々と書きます。

1\. 大会の概要

コンテストの概要を説明しておきます。
詳細はこちらまで。

設定

ある会社が運営するオンラインバンキングシステムにセキュリティ上の問題が発生

参加者は、このセキュリティ上の問題を調査するチーム

コンテストの目的

セキュリティへの興味喚起

現実的な問題へのチャレンジ機会創出

競技の概要

1チーム4名のチーム戦

オンラインWebサービスのシステム(Linux VM)とWebアプリケーションのソースコード(PH…

Ubuntu16.04で脆弱性スキャナOpenVASを使った

今回は、OSSの脆弱スキャナであるOpenVASをUbuntu16.04LTSでいい感じに使えたので、まとめた。  
脆弱性スキャナという単語に対し、「ムズカシイ」というイメージを持っていたが、意外と簡単に使えて驚いた。  

> **OpenVASとは**
>
> > OpenVASとは、システムの脆弱性診断を行うためのソフトウェアです。
> > オープンソースソフトウェアとして公開されています。
> > そのため、OpenVASを使うと、脆弱性診断サービスなどを使わなくても、自分でシステムの脆弱性診断を行うことができます。
>
> 引用: <https://www.designet.co.jp/faq/term/?id=T3BlblZBUw> より

## 1.環境

使用する環境は、以下の通り。

```shell-session
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.3 LTS
Release:    16.04
Codename:   xenial

$ uname -r
4.8.0-36-generic
```

## 2.インストール

インストールは、[ここ](http://blog.amedama.jp/entry/2017/08/09/004706)を参考にした。  

以下のコマンドを上から順に実行していけば、インストールが完了する。  
まるごと貼り付けても動くが、心配であればひとつずつ実行していくと良いだろう。  

**(注意) tcpの873ポートで通信ができるようにしておくこと。[^1]**

```sh
# 必要なリポジトリを追加する
yes | sudo add-apt-repository ppa:mrazavi/openvas

# リポジトリの状態を更新する
sudo apt-get update

# oepnvas9をインストールする
sudo apt -y install openvas9
```

インストール中に、下の画像のような画面が出てきた場合は、「Yes」と答える。

![インストール中の画面](img/try-openvas-in-ubuntu16_04/installing.png)  

次に、脆弱性のテスト時に使用するデータを更新する。  
この処理は、30分～1時間ほど時間がかかる。

```sh
sudo apt -y install sqlite3
sudo greenbone-nvt-sync
sudo greenbone-scapdata-sync
sudo greenbone-certdata-sync 
```

## 3.実際に脆弱性スキャンしてみる

インストールが完了したら、実際に脆弱性スキャンをしてみる。  

### 1.事前準備

まずは、サービスを起動する。

```sh
sudo systemctl restart openvas-scanner
sudo systemctl restart openvas-manager
```

次に、OpenVASのデーモンの設定を初期化しておく。

```sh
sudo openvasmd --rebuild --progress
```

### 2.WebUIにアクセスする

事前準備が完了したら、localhostの4000番ポートでWebUIが利用できるようになる。  
実際に利用するには、任意のブラウザで「<https://localhost:4000>」にアクセスする。  
今回は、Firefoxを利用する。  

実際にアクセスすると、下の画像のように、安全な接続ではないという旨の画面が出てくることがある。  
その場合、次の手順で進む。  
(出てこない場合は、次の手順は飛ばして良い。)  

!['Your connection is not secure'と表示されている](img/try-openvas-in-ubuntu16_04/access_the_web_ui_01.png)

①「Advanced」の箇所をクリック  

!['Your connection is not secure'と表示されている](img/try-openvas-in-ubuntu16_04/access_the_web_ui_02.png)

②「Add Exception...」の箇所をクリック  

!['Your connection is not secure'と表示されている](img/try-openvas-in-ubuntu16_04/access_the_web_ui_03.png)

③「Confirm Security Option」の箇所をクリック

![Add Security Exceptionのダイアログが出現している](img/try-openvas-in-ubuntu16_04/access_the_web_ui_04.png)

すると、ログイン画面が出てくるので、デフォルトのIDとパスワードでログインする。  
デフォルトのIDとパスワードは、それぞれ`admin`。[^2]

![ログインページ](img/try-openvas-in-ubuntu16_04/login_page.png)  

ログインすると、このような画面になる。

![トップページ](img/try-openvas-in-ubuntu16_04/toppage.png)

### 3.脆弱性スキャンを実行する

WebUIにアクセスすることができ、ログインが済んだら、実際に脆弱性スキャンを実行する。  

> [注意]  
> **脆弱性スキャンは、自身の管理下にないコンピュータやネットワークに対して、決して実行しないこと。実行した場合には、罪に問われる可能性もある。**

今回は、自身(localhost)に対してスキャンを実行する。  
手順は以下の通り。  

①上のメニューから`Scans`を選び、その中の`Tasks`をクリックする。

![Scans > Tasks](img/try-openvas-in-ubuntu16_04/execute_scanning_step_01.png)

②以下のような画面が出てきたら、10秒間待つか、ダイアログの[x]を押して閉じてしまう。  
出てこなければ、この手順は飛ばす。  

![Scans > Tasks](img/try-openvas-in-ubuntu16_04/execute_scanning_step_02.png)

③左上の方の紫色のボタンを押し、`Task Wizard`をクリックする。[^3]  
紫のボタンの位置はは少しわかりづらいので、画像を参考にすると良い。  

![Scans > Tasks](img/try-openvas-in-ubuntu16_04/execute_scanning_step_03_01.png)

![Task Wizardボタン](img/try-openvas-in-ubuntu16_04/execute_scanning_step_03_02.png)

⑤すると、下の画像のような画面が出てくるので、`IP address or hostname`のフォームに`localhost`または`127.0.0.1`と入力する。  
入力したら、`Start Scan`をクリックすることで脆弱性スキャンが実行される。  

![対象ホストを設定するためのダイアログ](img/try-openvas-in-ubuntu16_04/execute_scanning_step_05.png)

⑥下の画像のような画面になるので、`Status`の欄が`Done`になるまで待つ。  
`Done`になったらスキャン終了。  

![StatusがRequestedになっている様子](img/try-openvas-in-ubuntu16_04/execute_scanning_step_06.png)

## 4.スキャン結果を確認する

脆弱性のスキャンが終わったので、その結果を確認する。  
手順は、以下の通り。  

①上のメニューから`Scans`を選び、その中の`Reports`をクリックする。  

![Scans > Tasks](img/try-openvas-in-ubuntu16_04/check_the_result_step_01.png)

②下の画像のような画面になるので先ほどスキャンした日付のものを選択する。  

![Scans > Reports](img/try-openvas-in-ubuntu16_04/check_the_result_step_02.png)

以上の手順で、下の画像のようにスキャンの結果のレポートが閲覧できる。

![Scans > Reports > Results](img/try-openvas-in-ubuntu16_04/result_page.png)

また、スキャン結果は分類されており、その各項目別の閲覧ができる。  

レーダーのようなマークの横にある小さな▼にカーソルを合わせると、分類されたスキャン結果の各項目が選択できる。  
例によって、少しわかりづらいので図示する。

![▼の場所を図示した画像](img/try-openvas-in-ubuntu16_04/sort_the_results_01.png)

各項目を選択することで、その項目のスキャン結果が閲覧できる。

![スキャン結果の項目](img/try-openvas-in-ubuntu16_04/sort_the_results_02.png)

## 5.スキャン結果をエクスポートする

スキャン結果は、htmlやpdf等の様々なファイル形式でエクスポートすることができる。  
今回は全体のスキャン結果をHTML形式でエクスポートする。  

手順は以下の通り。

①まずは、レーダーのようなマークの横にある小さな▼にカーソルを合わせ、`Report: Summary and Download`を選択する。

![ドロップダウンメニューが出てきている画面](img/try-openvas-in-ubuntu16_04/export_the_result_step_01.png)

②次に`Full report`の行にあるプルダウン形式のメニューでエクスポートしたいファイル形式を選択する。  

![ファイル形式がドロップメニューで表示されている様子](img/try-openvas-in-ubuntu16_04/export_the_result_step_02.png)

③そして、プルダウン式のメニューの横にある緑色の[↓]ボタンをクリックする。これにより、指定したファイル形式でスキャン結果がエクスポートされる。  

![画面上の緑色の矢印のボタンが矢印で指されている](img/try-openvas-in-ubuntu16_04/export_the_result_step_03.png)

④この後は、普段何かをダウンロードするときと同じように`Save File`を選択し`OK`と進めば、エクスポートされたスキャン結果をダウンロードすることができる。  

![画面の処理方法を選択させるダイアログ](img/try-openvas-in-ubuntu16_04/export_the_result_step_04.png)

今回はHTML形式でエクスポートしたものをダウンロードしているので、ダウンロードしてきたファイルを任意のブラウザで開けば、実際のスキャン結果が確認できる。  

## 6.まとめ(感想)

実際に脆弱性をスキャンしてみると、いくつかの脆弱性が見つかった。  
スキャン結果には、攻撃者がその脆弱性を利用すると、どのようなことができてしまうのかということや、それに対する解決策などが書かれていた。  

スキャン結果に、一通り目を通してみたが、おそらくメジャーであろう脆弱性についても自分では発見することはできないなと感じた。  
Webの脆弱性について(もちろんそれ以外の分野も)、まだまだ基礎の勉強が足りてないなと痛感した。  

今回はUbuntu16.04でOpenVASを使ったが、どうやらKali Linuxには最初からインストールされているようで、Ubuntuを使うよりもっと簡単に使えそう。  
今回Ubuntuを使ったのは、普段使い慣れたOSだからだ、「Kaliでやれよ」という声は/dev/nullに捨てることにしている。  

他の脆弱性スキャナでは、Nessusなども一応使うことができたが、Vulsは環境構築でハマってしまっている。  

がんばる

## 参考ページ

- <http://blog.amedama.jp/entry/2017/08/09/004706>
- <https://www.designet.co.jp/faq/term/?id=T3BlblZBUw>  
- <http://olivermarshall.net/how-to-install-openvas-9-on-ubuntu-16>  
- <https://www.itseclab.jp/security_info/security_intro/openvas_verification>

## 注釈

[^1]: インストールの過程で、脆弱性をテストするための情報を更新する。その処理のために、rsyncプロトコルを使用するため。
[^2]: 変更する際は、`sudo openvasmd --user=admin --new-password=admin_new_password`をターミナルで実行する。
[^3]: ここで「Advanced Task Wizard」を選ぶと、より詳細な脆弱性スキャンができる


今回は、OSSの脆弱スキャナであるOpenVASをUbuntu16.04LTSでいい感じに使えたので、まとめた。
脆弱性スキャナという単語に対し、「ムズカシイ」というイメージを持っていたが、意外と簡単に使えて驚いた。

OpenVASとは

OpenVASとは、システムの脆弱性診断を行うためのソフトウェアです。
オープンソースソフトウェアとして公開されています。
そのため、OpenVASを使うと、脆弱性診断サービスなどを使わなくても、自分でシステムの脆弱性診断を行うことができます。

引用: https://www.designet.co.jp/faq/term/?id=T3BlblZBUw …