自己紹介

東京工科大学に学部と大学院をあわせて6年通いました．所属していた研究室はクラウド・分散システム研究室です．高校生ぐらいからネットワークやサーバをはじめとした分散システムに興味があり，個人的にLinuxでWebサーバやDNSサーバを構築していました．大学の入学後もセキュリティ・キャンプやイベントNOCチームへ参加していました．

大学の入学当初

学部1年の入学当初から早く大学を卒業して就職するつもりでした．なぜなら，第一志望でなく浪人して入学したためです．入学当初は大学の良さが分からずにいました．就職を意識していたこともあり， 学部1年から3年まではいくつかの企業でインターンシップやアルバイトに勤しんでいました．特にヤフーでの黒帯インターンシップは自分の目標とするエンジニアに出会えた良い経験でした．企業でのインターンシップやアルバイトの経験を通じて自らの技術力を把握できました．また，就職する際のイメージを具体的にできました．

研究室への配属

ネットワークや分散システムに興味があるため，クラウド・分散システム研究室を選びました．指導教員は企業から大学に着任されたこともあり，グローバルで働いた経験や専門性で尊敬できる方でした．一方で要求されるレベルの高さに配属当初は苦労しました．研究室では個人ごとに半期に1本のテクニカルレポート（2段組み，6-8ページ）の執筆が要求されます．配属されるまで6-8ページにおよぶ技術的なレポートを執筆した経験がなく当初は戸惑いました．振り返るとテクニカルレポートの作成は良い経験だと思います．特に文章や図で的確に説明する能力は向上しました．

大学院(修士課程)への進学

ある程度実務の経験があるため，学部卒である程度のIT企業には就職できる自信がありました．自分の実力を伸ばすために時間とお金を費やして大学院に進学するのも良い良い気がしました．経緯や参考になった書籍は下記の記事で紹介しています．

就職すべきか進学すべきか、それが問題だ | クラウド・分散システム研究室

大学院(修士課程)を振り返り

大学院への進学はとても良い選択でした．特に英語力や専門性，論理的な思考力や精神的な強さが進学前に比べて格段に向上しました．いつも”苦労しながら障壁を超える経験”を繰り返し，成功体験や自信を重ねてきた結果だと思います．

研究のテーマ決めや論文執筆，実験やデータ解析は苦労の連続でした．特に英語で論文を執筆する作業は基礎的な英語のスキルが足らずに苦労した記憶があります．3時間で数行しか書けず挫けそうになったことをよく覚えています．足りない実力は時間でカバーしようと休日も含めて最大限に時間を費やしました．何事も出来ないままにせず，出来るように努力することが大切だと思いました．

インドにあるAmity University Mumbaiの学生との研究プロジェクトも苦労した経験でした．英会話をする経験が少なく最初は大変でした．一方でこのプロジェクトで英語での会話をする機会があったおかげか，ポルトガルで開催された国際会議では英会話への抵抗感がまったくなかったです．インドの学生から学ぶこともありました．インドの学生は成果を残そうとするモチベーションの高いです．彼らはたとえ大学へ進学しても成果物がなければ良い仕事につけないそうです．IT業界のグローバル企業でインド出身者が多い理由が分かった気がしました．

今後の展望

2023年3月に大学院を修了し，2023年4月からAWS Japanに新卒で入社しました．仕事でも分散システムやクラウドに触れていく予定です．大学院でやり残したことはあるため，社会人大学院への進学を考えています．自分が納得いくクオリティの成果を出したい気持ちがあります．ご飯や呑みの機会があればぜひ声をかけていただけると幸いです．

干し芋リスト

AWSのLambdaの裏側で動いているマイクロVMの論文を読んでみた．
4章はAWSでのLambdaの動作を知るには有益なので読んでみるとGoodかも．

URL) https://www.usenix.org/system/files/nsdi20-paper-agache.pdf

最初のLambdaではLinux Containerを使っていたのが意外だ．
顧客アカウント単位で単一のVM内で複数の関数を実行していたのか．

When we first built AWS Lambda, we chose to use Linuxcontainers to isolate functions, and virtualization to isolatebetween customer accounts. In other words, multiple func-tions for the same customer would run inside a single VM,but workloads for different customers always run in differentVMs.

出典) Firecracker: Lightweight Virtualization for Serverless Applications

AWSにおいて重要だったポイントは「density (密集度)」と「overhead (オーバヘッド)」の2つ
ねらい(たぶん)→関数が起動するまでの時間の削減，マルチテナンシー(収容率)の向上

Two key, and related, challenges of virtualization are density and overhead

出典) Firecracker: Lightweight Virtualization for Serverless Applications

QEMUの複雑さがエグい… 140万行のコードと270のシステムコール…

To illustrate this complexity, the popular combination of Linux Kernel Virtual Machine [29] (KVM) and QEMU clearly illustrates the complexity. QEMU contains 1.4million lines of code, and can require up to 270 unique syscalls [57] (more than any other package on Ubuntu Linux15.04). The KVM code in Linux adds another 120,000 lines. The NEMU [24] project aims to cut down QEMU by removing unused features, but appears to be inactive.

出典) Firecracker: Lightweight Virtualization for Serverless Applications

Rustで書いて96%のコード量をQEMUに比べて削減… 

Firecracker’s approach to these problems is to use KVM(for reasons we discuss in section 3), but replace the VMM with a minimal implementation written in a safe language. Minimizing the feature set of the VMM helps reduce surface area, and controls the size of the TCB. Firecracker contains approximately 50k lines of Rust code (96%fewer lines than QEMU), including multiple levels of automated tests, and auto-generated bindings. Intel Cloud Hypervisor [25] takes a similar approach, (and indeed shares much code with Fire-cracker), while NEMU [24] aims to address these problems by cutting down QEMU.

出典) Firecracker: Lightweight Virtualization for Serverless Applications

Lambdaの関数実行環境はコロコロ変わるけれど，コードの読み込みとコードの移動にかかるコストを抑えるために関数実行環境をSticky(2回目以降は1回目を使う)に割り当てるのか !!

The execution of the customer code happens on the Lambda worker fleet, but to improve cache locality, enable connection re-use and amortize the costs of moving and loading customer code, events for a single function are sticky-routed to as few workers as possible.

出典) Firecracker: Lightweight Virtualization for Serverless Applications

これらの違いが分からない．

• Zero Trust Proxy
• Identity Aware Proxy
• Single Sign On Proxy

具体的なソフトウェア名はわかる．

• (製品) Google Cloud IAP → IAP
• Pomerium → IAP
• OAuth2-Proxy→SSO Proxy
• BuzzFeed SSO→SSO Proxy

検索してみた．わからない．Zero Trust Proxyの実装のひとつがIdentity Aware Proxyなのだろうか．では従来のSSO Proxyとは何が違うのだろうか．

特に「ID認識型プロキシ（Identity Aware Proxy）」と呼ばれる仕組みを中心に据え、認証・認可を強化している。これは、アプリケーションやユーザーの場所を問わず、無理のない方法でアクセスさせる仕組みだ。アカマイのID認識型プロキシは、EAA（Enterprise Application Access）という製品として顧客にもサービスを提供している。

解説「ゼロトラスト」シフト：脱“境界セキュリティ”が進む2つの動き https://japan.zdnet.com/article/35134505/ より

CNCF Landscapeを見たが分からない．Pomerium, BuzzFeed SSO, OAuth2 Proxyあたりが該当するが違いについて触れられていない．

Google Cloudの説明を見てみる．これによるとAuthNに加えてAuthZが詳細に行えるように見える．Role Based Access Controlが従来のSSO Proxyよりも細かく行えるということだろうか?

やはりよくわからなかった．有識者各位もし補足や答えを知っていれば教えて下さい．

余談:

mixiの清水さんがSRE NEXT 2020で発表されていたスライドを見て感じたことをメモする．

ログの扱い

• ログに認証情報や個人情報をはじめとする機密情報を出力しない．
• ログを大量に出力するとコスト(お金)に影響が生じる．

koyamaの脳内

• 役立つログを適切な粒度で出力するよう適切な設定が必要になりそう．
• この粒度を適切に決めるのは，熟練したソフトウェア開発者しか出来ないのでは?
• 複数メンバーが参加するソフトウェアプロジェクトで認識を統一するのは難しい．
• 開発用のデバッグログもプロダクションで出力すると機密情報になるので，動作モードによって出力するログも制御すべきということかな．
• 開発環境→トークンをログに表示
• 本番環境→トークンをログに非表示

デフォルト設定を使わない

koyamaの脳内

• デフォルトVPCとセキュリティグループを使わないことをプラクティスにするのはイマイチな気がした．
• 全利用者にセキュアな状態をデフォルトで提供するために，明示的な指定を利用者に求めればいいのに．
• 利用者が簡単に使えること，デフォルトでセキュアな状態が作られることを両立してほしいな．
• AWSはクラウド事業者なので，簡単に使えることを優先しているのではないか?と思った．

IETFのメーリングリストを眺めていたら，httpbis-cacheのdraftの議論があったので眺めてみました．既存のRFC 7234からの変更点(Change Log)で気になったものピックアップしてみました．

この記事では，draft-ietf-httpbis-cache-08の段階での情報を書いています．今後の動向は最新のDraftを確認してください．

C.4. Since draft-ietf-httpbis-cache-02

Warningヘッダの非推奨

In Section 5.5, deprecated “Warning” header field
(https://github.com/httpwg/http-core/issues/139)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

個人的には，こんなヘッダがあることに驚きです．MDNによるとレスポンスヘッダに状況の説明として含めることが想定されているそうです．ヘッダの構造は以下で定義されています．

Warning: <warn-code> <warn-agent> <warn-text> [<warn-date>]

• Warning – HTTP | MDN
• RFC 7234 – Hypertext Transfer Protocol (HTTP/1.1): Caching

C.5. Since draft-ietf-httpbis-cache-03

リクエストヘッダのキャッシュ制御を削除

Remove requirements around cache request directives
(https://github.com/httpwg/http-core/issues/129)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

リンク先のGitHubでも書かれているとおり，リクエストヘッダのキャッシュ制御ヘッダがブラウザやWebサーバ，CDNで無視されている状況から取り除くことになったそうです．

• Hypertext Transfer Protocol (HTTP/1.1): Caching

Pragmaヘッダの非推奨

Deprecate Pragma (<https://github.com/httpwg/http-core/issues/140>)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

HTTP/1.1ではCache-Controlヘッダが同様の働きをするので非推奨になったようです．

• Pragma – HTTP | MDN

C.7. Since draft-ietf-httpbis-cache-05

キャッシュ可能メソッドのコンセプトを削除

In Section 3, remove concept of “cacheable methods” in favor of prose (https://github.com/httpwg/http-core/issues/54, https://www.rfc-editor.org/errata/eid5300)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

リンク先の表には，メソッドごとにSafe(安全性), Idempotent(冪等性)の2カラムが存在します．Safeはリクエストのメソッドがリソースの読み取り専用であるか(変更を伴うか)を表しています．Idempotentは，同時に同一のリクエストが複数あった場合と1つあった場合で影響が同一であることを表しています．

7.2ではSafeとIdempotent, Cacheについて触れられているものの，表にはSafeとIdempotentの2つのみ記載がありCacheは省略されていました．以下がGitHubのPull Requestです．

Get rid of “cacheable methods” by mnot · Pull Request #229 · httpwg/http-core

クオートで囲まれたキャッシュ制御ディレクティブの扱い

Change requirements for handling different forms of cache directives in Section 5.2 (https://github.com/httpwg/http-core/issues/128)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

執筆中

C.8. Since draft-ietf-httpbis-cache-06

Varyディレクティブが * の場合キャッシュを無効化

In Section 4.1, clarify that any “*” as a member of Vary will disable caching (https://github.com/httpwg/http-core/issues/286)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

執筆中

C.9. Since draft-ietf-httpbis-cache-07

明確: 他のキャッシュ要件を無視

In Section 5.2.2.6 and Section 5.2.2.7, make it clear that these directives do not ignore other requirements for caching (https://github.com/httpwg/http-core/issues/320)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

執筆中

先月あたりにヤフオクで購入したAllied TelesisのL3スイッチ9424T/SP-Eを静音化する。他のサイトを参考にしたので特筆すべきことはあまりない気がする。

ファンの購入

交換用のファンは秋葉原の千石で販売されているものを2つ買った。小さいファンでも産業機器へ使われるほどなので値段が高い。

取り付け

以下のサイトを参考に取り付けを行った。

アライドのL3スイッチ・CentreCOM 9424T/SP-Eの静音化: aji blog

CentreCOM 9424T/SP-Eを静音化してみた – ＠SRCHACK.ORG（えす・あーる・しー・はっく）

気をつけることは、「ファンの取り付け向き(吸気/排気)」と「ピンの並び」の2つだけだった。

ファンの取り付け向きを確認せずに取り付けてしまった。以下は間違えた時の向きで撮影した写真。

ピンの並びは、参考にしたサイトでも書かれているように異なるため自分で変える必要がある。ソケットの隙間にピンセットを差し込んで圧着してある端子を押し出すようにして取り出した。力の入れ方が難しかった。

黒と赤のケーブルの位置を入れ替えれば正常に動いた。怖かったのジャンパーケーブルとブレッドボードを使って慎重に配線して確認した。

配線したら接触不良で回らないときがあったので圧着部分の端子を少し調整して再度差し込んだところ正常に動作した。

余ったケーブルは結束バンドでまとめておいた。ファンを筐体に固定するときに、もともと固定していたビスが交換したファンに合わなかった。そこで、購入したファンに付属していたナットとボルトを使って固定した。

配線して通電してFAULTが点灯せず、ファンが回転していれば問題ない。かなり静音になったので運用にもっていきたいと思う。

母校の高校でワークショップを行いました。スライドは以下に公開しました。

//speakerdeck.com/assets/embed.js

配布した資料は以下のリンクからダウンロードできます。

パケットワークショップ配布資料

楽しみながらWiresharkの使い方やパケットの仕組みについて興味を持ってもらえたようで良かったと思いました。また、機会があればワークショップを行いたいと思います。

久しぶりにCTFやれる、まとまった時間が作れたので参加してみた。全体での順位は230ptで131/447だった。修行が足りなすぎる。

ObfuscatedPasswordChecker

配布されるsrc.zipを展開してみるとhtmlファイルとjsファイルが含まれている。htmlファイルをブラウザで開いてみるとパスワードフォームが表示される。ここに何かの入力値を入れると、何か起きそうだと考えた。

試しに開発者ツールのNetworkタブを開きながら、適当な文字列を入力してボタンをおしてみる。タブ内に変化はなく、リクエストは送信されていないと分かる。つまり、このhtmlとjsで構成されるクライアント側で完結するアプリだと考えられる。

次に、JavaScriptの挙動を追跡してみる。ブラウザの開発者ツールから「ボタンが押された時」に関するイベントを探してみる。

bundle.jsの1行目にボタンを押した時の処理があることが分かる。実際にbundle.jsを表示して整形してみる。

次にボタンが押された時に、「入力値がどのように判定されているか」を調べてみる。ボタンが押された後の処理は311行目から319行目までの範囲にかかれている。

この中にif文がふくまれている。このソース全体は軽めな難読化がされているのでif文の内部の処理を分析してみる。

ブラウザのConsoleで変数やメソッドなどを展開できるので、これを使って値の中身を確認する。するとsuccessという文字列が314行目で代入されていることが分かる。次に315行目ではcongraz! the flag is: という文字列と変数_0x256968の値が文字列結合されていることが分かる。

つまり、変数_0x256968がFLAGに関わっていると考えられた。この変数に着目すると313行目で変数_0x5d7c01と比較されており、305行目で宣言と代入が行われていることが分かる。

試しに305行目の代入値をConsoleで確認してみるとFLAGの中身であった。おそらく変数_0x5d7c01がブラウザのフォームでの入力値だったと考えられる。

HarekazeCTF{j4v4scr1pt-0bfusc4t0r_1s_tsur41}

Lost_data

ファイルlost_data.zipを解凍すると xxxxx.zip と data.zipが出てくる。さらに data.zip を解凍すると1, 2, 3というファイルが出てくる。テキストエディタなので開いてみるとファイルがバイナリファイルであることが分かる。

バイナリエディタやhexdumpなどで中身を覗いてみるとPNGファイルにみられるチャンクとよばれる構造が確認できる。ファイル構造を確認するとヘッダにPNGの特徴であるASCII表現された「PNG」が見られない。

hexdump -C 1
00000000  89 2e 2e 2e 0d 0a 1a 0a  00 00 00 0d 49 48 44 52  |............IHDR|
00000010  00 00 00 6f 00 00 00 6f  01 03 00 00 00 d8 0b 0c  |...o...o........|
00000020  23 00 00 00 06 50 4c 54  45 7d c7 ff ff ff ff 97  |#....PLTE}......|

そこで、バイナリエディタでその部分を書き換える。

hexdump -C ../../data/1
00000000  89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52  |.PNG........IHDR|
00000010  00 00 00 6f 00 00 00 6f  01 03 00 00 00 d8 0b 0c  |...o...o........|
00000020  23 00 00 00 06 50 4c 54  45 7d c7 ff ff ff ff 97  |#....PLTE}......|

そして、画像ビューワなどで開くと2次元コードの画像が計3枚でてくる。これらをスキャンして結合すると HarekazeCTF{Y0u_G0t_FuNNy_F1ag_?DF?_T?_is_xxxxx} が出てくる。

この後に xxxxx を置き換えることが必要になるが、ファイル xxxxx.zip が関連していることは分かったが何をすればいいのか方針が立たない。ひとまず放置しておいた。

後からヒントでファイルシステムという単語と xxxxx.zipに含まれるファイル一覧から何となく「FAT(16|32|64)」あたりで試したらフラグが落ちてきた。

HarekazeCTF{Y0u_G0t_FuNNy_F1ag_?DF?_T?_is_FAT32}

'OR 2=10-1OR3-2=22-(100-1)OR
id LIKE'5a%'
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
21313134-3413-3134-3143-311232131231
'OR 1=1;--222-2222-2222-222222222222
'OR id LIKE
'|| id LIKE '9e5a%' --    -    -    -
1=1 --222-2222-2222-22222222222'

21313134-3413-3134-3143-311232131231
'||1=100-1000-1000-1000-1||
'OR id/*-0000-0000-0000-*/9e5a

21313134-3413-3134-3143-311232131231
'OR id BETWEEN '9e5a0' AND '9e5a1'

21313134-3413-3134-3143-311232131231
'OR id LIKE '%e5a%';
'OR id LIKE CONCAT('%e5a%';

第2回の学生LT以来、久しぶりに参加してきた。参加者の層も前回よりも幅広くなった気がする。

第8回 学生エンジニア限定LT大会！！！ – connpass

基調講演でうみさまが話していた内容はかなり共感できることがあった。スキルがあっても自信がないとチャンスは生まれないと改めて感じた。少しでも踏み出すことの大切さは、先人のツイートやブログ、スライドでも上げられているし。

今回の会場のfreeeさんはスマートなプロダクトで素晴らしいなと紹介プレゼンを聞いて感じた。「JavaとJavaScriptはハムとハムスターぐらい違う」がかなり印象的だった。

（たしか）もっちーさんのIoTが実際の問題に対してはっきりとしたアプローチを提案しているあたりすごいなーと思った。あれ全国で欲しがっている人いると思う。ワナにひっかかる時間帯とか傾向をデータ化して共有したら面白そう。

N高校の@waritocomatta さんのLTが慣れた感じの技術系LTで面白かった。とくに某Y社のハッカソンが発表時間90秒という短さは意外だった。なんというか、その方面で突き抜けた感じ(分かる人には伝わるかな)があると思った。やっぱり未踏ジュニアなだけあるなと。

中学生でRails使ってWebアプリ作った@anharuさんもすごいなーと。中学生の時にここまで出来なかったよなぁと。特にDB設計、サーバサイド、フロントエンドという設計の順番を考慮しているあたり分かっているんだなと思った。

//speakerdeck.com/assets/embed.js

自分の発表はスライドがイベント始まってから完成するくらい遅かったので、内容が薄くなってしまったので反省してる…。時間の配分もまったく考えていなかったので気をつけたい。本当はXSSの入力値についてひたすら語るLTにしたかったけど、使えるほどの数の検証が出来ていなかったので断念。次はもっとクオリティの高いLTをやりたい。

お疲れ様でした && ありがとうございました