VSCodeのターミナルのフォントが全角でキモい

はじめに & 結論

Kali LinuxにインストールしたVSCodeがタイトルの通りの状況でした。結論、フォントを変えれば直ります。変更前はmonospaceというフォントになっていました。気持ちよく解決に繋がる記事が案外インターネットになかったので、転がしておきます。

before

after

手順

フォントをインストールする

Ricty Dminishedというやつにしました。

github.com

Zipファイルをダウンロードします。

以下、CLIで操作します。

### Zipファイルを展開する
$ unzip RictyDiminished-for-Powerline-master.zip

### 使いたいフォントを/usr/share/fontsへ移動する
$ cd RictyDiminished-for-Powerline-master
$ sudo mv RictyDiminishedDiscord-Regular.ttf /usr/share/fonts/

### フォントキャッシュを更新する
$ fc-cache -fv

### 使いたいフォントが反映されていることを確認する
$ fc-list | grep -i ricty

VSCodeのフォントを変える

• Ctrl + Shift + Pでコマンドパレットを開く
• 「settings.json」などと入力してsettings.jsonを開く
• "terminal.integrated.fontFamily": Ricty Diminished Discord を追加してCtrl + Sで保存する

AWS Lambdaの関数URLを使って、Prototype Pollution（プロトタイプ汚染）のサンプルを作ってみた

はじめに

kurenaifさんのプロトタイプ汚染解説動画の分かりやすさに感動して、復習がてら自分でも作ってみようと思い立ちました。

www.youtube.com

ついでに、AWS Lambdaが自前でURLを持てるようになったと聞いたので、それも試してみることにしました。

dev.classmethod.jp

リクエストに依存しない例

最初に想定していたのは以下のようなパターンだったのですが、うまくいきませんでした。

• POSTリクエストのボディに入っているJSONを受け取る
• そのJSONを既存のobjectにマージする（このタイミングでObjectが汚染される）
• objectを新しく作り、汚染されたかどうか確認する

試しに以下のような、リクエスト抜きで完結するパターンを試したら、ちゃんと汚染されていました（これを汚染と呼ぶのかは微妙なところですが）。

exports.handler = async (event) => {
    const obj1 = {};
    obj1.__proto__.polluted = 1;
    console.log("obj1.polluted: " + obj1.polluted);

    const obj2 = {};
    console.log("obj2.polluted: "  + obj2.polluted);

    const response = {
        statusCode: 200,
        body: JSON.stringify(obj2.polluted),
    };

    return response;
};

リクエストによって汚染される例

どうしてもリクエストによって汚染されてほしいです。もろもろ頑張った結果、以下のコードで汚染されることを確認しました。

exports.handler = async (event) => {
    const obj1 = clone(JSON.parse(event.body));
    console.log("obj1.status: " + obj1.status);

    const obj2 = {};
    console.log("obj2.status: "  + obj2.status);

    const response = {
        statusCode: 200,
        body: JSON.stringify(obj2.status),
    };

    return response;
};

function isObject(obj) {
    return obj !== null && typeof obj === 'object';
  }
  
  function merge(a, b) {
    for (let key in b) {
      if (isObject(a[key]) && isObject(b[key])) {
        merge(a[key], b[key]);
      } else {
        a[key] = b[key];
      }
    }
    return a;
  }
  
  function clone(obj) {
    return merge({}, obj);
  }

こちらの記事のコードを引用しました。おそらく merge() の merge(a[key], b[key]) のところを、自前で実装できていなかったようです。{"__proto__":{"status":"polluted!"}}のようなJSONを読み込む時、このように再帰しないとプロトタイプのプロパティを適切に設定できないのだと考えています。

jovi0608.hatenablog.com

調査

merge() のところで何が起きているか知りたかったので、ログを出すようにしてみました。

  function merge(a, b) {
    for (let key in b) {
      console.log(isObject(a[key]) + ", " + isObject(b[key]))
      if (isObject(a[key]) && isObject(b[key])) {
        console.log("o: " + key + ", " + a[key] + ", " + b[key])
        merge(a[key], b[key]);
      } else {
        console.log("x: " + key + ", " + a[key] + ", " + b[key])
        a[key] = b[key];
      }
    }
    return a;
  }
  
  function clone(obj) {
    return merge({}, obj);
  }

結果、このようなログが出ました。

つまり、以下のようなことが起きている……？

• merge({}, event.body)
  • 引数は {} と event.body
  • forループに入る
    • {}.__proto__ と event.body.__proto__ いずれもobjectなので、merge() が実行される
      • merge({}.__proto__, event.body.__proto__)
        • forループに入る
          • {}.__proto__.status と event.body.__proto__.status はいずれもobjectではないので、elseの処理が実行される
            • 前者はundefined、後者はstring（"polluted!"）
          • {}.__proto__.status に event.body.__proto__.status が代入される
            • {}.__proto__ はこの時点で汚染されている？
          • forループが終了し、{}.__proto__ （{status:"polluted"}）が元のプロセスへ返される
    • forループ終了が終了し、（汚染された？） {} が返される

システム開発におけるセキュリティガイドラインの理想について

会社でシステム開発・運用におけるセキュリティガイドラインを作っていて考えたことです。そういうものを作らなければならない人たちの参考になるかもしれません。

セキュリティガイドライン、徳丸本読んどけハイ終わりってしたい

— shinobe179 (@shinobe179) 2022年4月21日

何のために作るか

• セキュリティにおける、組織としての落としどころを明らかにするために作る
  • セキュリティは「やり過ぎ」と「やらなさ過ぎ」どちらも起きる可能性がある
  • 「やらなさ過ぎ」を気にして、一般的なことを書いてもしょうがない

何を書くか、書かないか

• 「会社として決めなければならないこと」だけ書きたい
  • 例
    • ログは何を、どれぐらいの期間保存しなければならないのか？
    • ユーザーのパスワードは何文字〜何文字を許容しなければならないのか？文字種は？
    • OSSの脆弱性にどう対応していくのか？
      • 全てのOSSを常に最新バージョンにはしておけない
• SQLiとかXSSとかはなくて当たり前なので書かない（書きたくない）
  • 何を以てそれらがないと判断するかは決めておく必要がある

誰に書くか

• 読者の想定レベルが重要
  • 「徳丸本の内容が理解できている」が一番ちょうどいい
    • SQLiとは？XSSとは？なんて、会社の資料で解説したくない
    • 徳丸本の内容を理解・実践できない開発者がシステム開発すべきでない（過激派）
    • 外注の場合はどうなるのか？
      • 発注担当者は徳丸本を理解していなければならないか？
        • それは望めない場合も多い
        • 責任転嫁するしかない
          • 自社の開発者、もしくは品質管理部門
          • 発注先の開発会社
          • 脆弱性診断の発注

何で書くか、どうやって検証するか

• ガイドラインが守られているかを検証するスキームが必要
  • セキュリティガイドラインは、何もしないと事故が起きてはじめて違反に気づくことになる
    • これでは遅い（組織に被害が出ているので）
• 何で書くかは、検証方法を見越して検討する必要がある
  • 遵守状況を可視化できるといい
  • WordやExcelだけで管理するのは文明人のふるまいではない
    • インターフェイスとしてそれらを使うだけならギリギリ許容できる（ただしWord、テメーはダメだ）
• なんかそういうSaaSあるのでは？

誰が書くか

• 徳丸本の内容が理解できるなら絶対に自分たちで作ったほうがいい
  • 外注はズブの素人でもない限りやめたほうがいい
    • 5000兆歩譲って外注するにしても、アウトラインだけとか
    • 個人的に非常に体験が悪かったので
      • お前が外注ヘタなだけじゃねえかと言われるとぐうの音も出ない

マジでもう二度と書類仕事外注しねえわ Wordまともに使えないのに受注すんな

— shinobe179 (@shinobe179) 2022年4月21日

「Visional Security Lounge Vol.3」に参加した

Visional Security Lounge Vol.3に参加しました。

d-cube.connpass.com

以下感想です。話していいこと・悪いことが分からないので、自己判断でぼやかします。

• セキュリティモニタリングの話
  • リスクシナリオ策定手法、とても参考になった。
  • 他にも色々聞けたけど、具体的な技術や施策の話なので書かないでおく。
    • ログ解析基盤の話もっと聞いてみたい（というか、してみたい）。
• インシデント対応
  • Log4Shellの対応7時間で完了ってすごい。
  • やること、どうやるか、やらないことがちゃんと決まっている。
  • 地肩（技術力）もある。
    • 公開された脆弱性やその対策の検証を手際よくやる能力。
  • プロダクトチームとの関わり方も、割とどこでも言われていることだけど、実践しているという点で参考になった。
    • セキュリティをプロダクトの品質としてポジティブに、同じ方向を向いてやっていけるのはよき。
    • プロダクト開発は内製なのか？外注だと対応クッソ遅かったりするので。

アンケートの最後「スライド共有して欲しいなら社名と個人名書いてね！」はちょっとこわかったです。そんなもんかね？

SSVCを参考にした脆弱性管理について本気出して考えてみている（進行中）

はじめに

ここ最近脆弱性管理についてずっと考えていたのですが、SSVCを知ってからというもの、かなりシンプルに考えられるようになりました。試み自体はまだ途上なのですが、以下のようなことを目的として、SSVCの概要や、現時点での経過や私の考えを文字に起こしてみます。

• アイデアを整理したい
• 脆弱性管理・運用に悩んでいる人と傷を舐め合いたい
• あわよくば有識者の目に止まってご意見を賜りたい（辛辣なのはイヤ）

SSVCとは？

Stakeholder-Specific Vulnerability Categolizationの略。CERT/CCが考案した脆弱性管理手法です。CVSSが「脆弱性の評価手法」であることに対して、SSVCは「脆弱性対応方針の判断手法」であると言えます。

たぶん今一番分かりやすい解説ページ。PWCだいしゅき！

www.pwc.com

実際の資料は、CERT/CCのGitHubリポジトリ内にあるファイル名に日付が降ってあるPDFのうち、一番新しいのを見るといいと思います。

github.com

（2022-12-24追記） OSS脆弱性管理製品である「FutureVuls」の開発元がSSVCの和訳を公開してくれています。ありがたや🙏原文も割と平易な表現で書かれていると思いますが、英語に抵抗がある方や時間がない方はこちらをおすすめします。

github.com

FutureVulsはたぶん世界で初めて、そしてたぶん現在世界で唯一のSSVCによる脆弱性評価を実装した鬼🆒な製品なので、脆弱性とかあんまよく分からなーいという方は、一度トライアルしてみるといのではないかと。

vuls.biz

よくある脆弱性対応方針の判断（n=1）

私の脆弱性情報収集から対応方針判断までのフローは、だいたいこんな感じです。

• JPCERT/CCの注意喚起やTwitterで騒がれている脆弱性情報をキャッチする
  • この時点で明らかにアチアチなこともある→即対応
• CVSSの基準値とAVを見て、大体のアツさ（=精読するかどうか）を判断する
  • AVはNだったら激アツ、LやPだったらひとまず安心しちゃう（よくない）
• AC、C、I、Aあたりを見て、最終的な方針を決める
• 「cve-xxxx-xxxxx poc」でググってみる
  • 「site:github.com」を付ける場合もある

人力かつ判断基準が明らかでないところが、属人化を招く点や説明性が低いという点でよくないと思っています。でもきっと多くの方がこんなもんだと思うんですよね……ちがう？

CVSSが全てじゃないよね

CVSSは脆弱性評価手法としてよく整理されていていい感じなのですが、判断基準が曖昧とか、現状評価基準の評価があんまりされていないとか、シブいところもあったりします。特に現状評価基準が運用されていないというのは、昨今の脅威ベースアプローチブームと矛盾してませんか？何なんすか一体。

……『脅威インテリジェンスの教科書』を拝読してからというものニワカ脅威インテリ厨なもんでイキってしまいましたが、きっと業界の先達にとって、脅威ベースの考え方は昨日今日始まったものではありませんよね。『脅威インテリジェンスの教科書』、めちゃいい本なので読んで欲しいです。

gihyo.jp

SSVCのココがすごい！

そこで脆弱性管理界のジャンヌ・ダルクことSSVCの登場です。SSVCの推しポイントを列挙します。

アウトプットが具体的なアクションである

CVSSのアウトプットがスコアや各属性の評価であることに対して、SSVCのアウトプットは脆弱性に対するアクションです。具体的には以下の4通り。

• defer（静観）
• scheduled（計画対応）
• out-of-cycle（計画外対応）
• Immediate（緊急対応）

アクションの判断基準を明確に提示している

SSVCは、アクションを導き出すまでにどういった判断材料があるのかを提示してくれています。我々のようなパッチを当てる立場、SSVCでいうDeployerの場合は、以下の4つです。それぞれが3〜4段階の分類を持ちます。

• Exploitation（脆弱性の悪用実績やPoCの公開状況がどの程度か）
• Exposure（システムの公開度合いはどの程度か）
• Utility（脆弱性の有用性=悪用によって得られる対価 * 悪用（自動化）のしやすさ）
• Well-being and Mission Impact（悪用された時のインパクト）

Deployerの判断木を見てみましょう（最新の資料ではPDF35ページ目）。見てもらうとわかる通り、4つの質問に答えた結果は予めプロットされています。要するに、「Exploitationは？」「Exposureは？」「Utilityは？」「Human-being and misson impactは？」という4つの問いに答えることで、「その脆弱性にどう対応すべきか？」という問いの答えが導かれるわけです。

ある架空の脆弱性の対応方針をSSVCに沿ってやってみると、こんな感じです。

• 調べたらGitHubにエクスプロイトが公開されていた、そのまま悪用に転用できそう
  • →Exploitation = active
• 対象システムはインターネットから隔離されている
  • →Exposure = small
• 悪用されたら機密情報抜かれるし、自動化も容易そう
  • →Utility = super effective
• 悪用されたらマジでエグい
  • →Well-being and Mission Impact = very high

結果はout-of-cycle、「優先度を上げて計画外対応をしよう！」ということになります。

このことには、以下のようなメリットがあります。

• 判断基準や経緯の説明がしやすい
• 最終的な対応判断がプロット済みである
  • 一番迷うところ（決めの問題、とよく言われる部分）を考えなくてよい
  • やってみて違うならいじればいい
• 実状と乖離した結果が出た場合に、調整しやすい

ついでに、これらの判断基準は、脆弱性に関わる複数の立場に対して異なるものが提示されています。

• Supplier（パッチを作る人、メーカー）
• Deployer（パッチを当てる人、利用者）
• Coodinator（……誰？）

ここまでのまとめ: SSVCは関数、CVSSは引数

前述の通り、CVSSはあくまで「脆弱性の評価手法」であって、そこから対応方針を導き出すための判断基準は、セキュリティ担当者が用意しなければなりませんでした。SSVCはまさにその基準になるわけです。CVSSをはじめとした脆弱性情報を引数、SSVCを関数の関係にプロットすると理解しやすいです。そう私は思っているんですが、図にすると途端に陳腐になるのなんなの？

運用するために必要なこと

最後に、SSVCを運用していくためにやらなければならなさそうなことを列挙します。

action毎の具体的な対応期限を決める

まずはscheduled、つまり脆弱性の計画対応はどれぐらいの期間毎にやるのかが決まっていないと、計画も計画外も緊急もないので、これらばかりは決めるしかありません。決めましょう。

判断ポイントの判断基準を決める

Exposureは（controlledの判断は迷うところですが）ほぼ自ずと決まるので置いておくとして、Exploitation、Utility、Well-being and Mission Impactを何に基づいて決めるかを決めなければなりません。

原著には「SSVC using Current Information Sources」という節がありまして、要するに「各判断ポイントにおける判断材料として、既存の情報源が一定有用である」といったようなことが書いてあります。個人的にこんな感じでいいんじゃないというのを書いておくので参考まで。

Exploitation

Exploitationの評価はactive > poc > noneで、脆弱性データベースが主な情報源です。個人的にはここでの評価が最も重要だと思っています。

• GitHubやExploit-DB、VulnDBを見てみる
  • 単なるPoCに留まるならpoc
  • 即・悪・用な感じならactive
• JPCERT/CCの注意喚起で、既に悪用が観測されているならactive
• CISAのKnown Exploited Vulnerability Catalogに載っていたらactive

Utility

Utilityは Automatable（自動化できるか）とValue Density（得られる対価）で決まります。AutomatableについてはCVSSのACやUIを参考にしてもいいですし、コードがあるということを一定自動化の余地があると解釈して、Exploitationの判断結果を流用してもいいと思います。Value Densityは、CVSSのCIAを参考にするといいのではないでしょうか。

Well-being and Mission Impact

CVSSのCIAがよさそうだと思っています。

判断を自動化する

全脆弱性をあのクソデカ判断木を見ながらトリアージするのはきっとしんどいので、コードにルールベースで判断させて、最初のうちは人間が目検して過小評価・過大評価が起きていないかを確認しながら調整していく必要がありそうです。自動化するためには、「判断ポイントの判断基準を決める」で、ある程度自動化を見越した基準を定めなきゃならないですね。

また、PoCの公開のような状況の更新に伴う判断のし直しも、考慮に入れなければなりません。これについても、定期的な脆弱性情報の更新、および状況の変化をトリガーとした再評価までが自動で行われてほしいです。

さいごに: 調整する

とりあえず決めて、回してみて、うまくいかなければ調整しましょう。調整しやすいというのもSSVCのいいところですから（自戒）。

TryHackMe2ヶ月目の報告

2022年2月7日にランクが0x9（Omni）になりました。現在こんな感じです。

Writeupなしでrootまでいける問題が増えてきました。

はじめてそれっぽいマシンを一切Writeup見ないで攻略下かもしれない。

— shinobe179 (@shinobe179) 2022年2月6日

※「攻略下」→「攻略した」

自力で解けた

— shinobe179 (@shinobe179) 2022年2月23日

直近の反省点は、gobusterなどで一度見つけたディレクトリの下を更に列挙するのを忘れがちなことです。最初幅優先でルート直下のみ掘りまくって、その後詰まったら掘り下げって感じでやっている（で、それをやり忘れる）んですが、皆さんどうしてるんでしょうか？

今月はeJPT挑戦月の予定。練習問題との対戦成績は芳しくありませんが頑張ります。

セキュリティ独学を数年続けた人が、TryHackMeを1ヶ月続けた感想と今年の抱負

はじめに

id:shinobe179です。2022年（令和4年）初めての投稿です。あけましておめでとうございます。

年末年始休暇の最中から、暇さえあればTryHackMeをやっていることが多くて、1ヶ月ほど経過した先日、ようやくランクが数字帯を抜け出して 0x8(HACKER) になりました。

そう呼ばれることに憧れて業界に入ってきたので、どうあれ（ネガティブな形でさえなければ）そういう扱いになるのは素直に嬉しいです。

今日はそんな私がTryHackMe（THM）を1ヶ月続けた感想と、今年の抱負です。

THMは初心者に優しい

この分野にはちびちびとリソースを投じ続けていて、そんな中で一昨年末のVirtual Hacking Labsサブスクリプション購入は、清水……とまでは言わないけど、マンションの3階から飛び降りるぐらいの覚悟ではありました。

https://www.virtualhackinglabs.com/

テキストはめちゃくちゃ勉強になりました。毎晩翻訳しながら読んでました。私のなけなしのスキルの礎は間違いなくこのテキストです。

VHLはラボサーバーを20台ぐらい解いてレポートを書くと、certificationがもらえます。しかし私は、一度の延長の末、挫折しました。一定以上のレベルになるとヒント（Writeup）が公開されていなくて。攻略に辞書攻撃が必要なのもモチベーションが下がる要素でした。「Try Harder」と言われてしまえばそれまでなのですが。

要は、当時の私にとって、VHLはちょっと実践寄り過ぎだったんだと思います。体系的な学びを、テキストだけではなく、手を動かして体得する必要があった。

その点、THMは有志のWriteupが公開されています。私はハマったらそこから5分なり10分なり制限時間を決めて、タイムアップしたら潔くWriteupを見るようにしています。正味かなり悔しいんですが、今はインプットの時期だと思っているので、唇を噛み締めながら確認してます。

TryHackMeは各単元に明確な目標があって、更にWriteupも公開されていて、挫折しにくい設計になっているところが好きです。ランクの仕組みも私の性癖にガッツリ刺さってます。

課題は情報整理

今の課題は、テクニックのバリエーションはもちろんですが、状況に応じた行動のデータベース、テンプレート化が十分でない、ということです。分かりやすいことで言うと、全ポートへのスキャンを忘れるとか。場当たり的で、思い出したことをぱっとやる感じです。学んだことの整理を定期的にやります。

THMは1台のサーバーとのタイマンですが、資格や実務は複数のサーバーを相手取ることもあるはずで、そんな時に情報の記録、参照であたふたしてたら取れるflagも取れません。

目標：2022年3月までにeJPT、年内にOSCP

OSCPを目指していて、TLの方々はバンバン取ってるけど、どうやらそんな簡単なものじゃないらしい、ということで、eLearnSecurityのeJPTから始めようと思います。年内にOSCPはとりあえず仮置きです。

さいごに

人生、配られたカードで勝負するしかないとはよく言ったもんだけど、まだとっておいてるつもりの手札を毎ターン1枚ずつ取り上げられる年齢に入った気がする。

— shinobe179 (@shinobe179) 2022年1月30日

こんなことを感じる年齢ではあるのですが、動く手さえあれば食いっぱぐれることはないと信じて、細々と学習を続けます。