【俺が25人分になる Advent Calendar 2023】day2 攻撃者的思考というものへの徒然

アドカレって何でもいいっぽいと前回の投稿後に調べてわかったので、ノリでやっていきます。

俺が25人分になる Advent Calendar 2023 - Adventar

 

上げようと思ったのはSMTとかの解説なんですが、時間がかかっているのでお茶を濁すことにしました。

二日目でいきなり一日空いてるのですが、別に0時に限定されてないのでまだ戦える……はず!(このタイトルで1日で終了は悲しすぎる)

 

というわけでお得意の脆弱性関連のネタ書こうと思ったんですが……これ無限に書ける割にコアなネタなのが問題です。知らん人からは「だから何?」って感じでしょうし。

 

書くネタに困ったときに頼りそうなので、今回は一般的な脆弱性への自分が抱くフィーリングのようなものを共有してみます。

 

当然のことながら経験則ですのでご容赦を。また言うまでもなく勝手に稼働しているシステムを侵害することを推奨する記事ではないです。

 

# 攻撃者はシステムに何を思うか

 

よくやり玉に上がる「この言語は安全か」という面倒な議論があります。

これにズバリ答えることは困難ですが、実装が難解な言語による実装は攻撃者にとっても難解なのは間違いないと思います。脆弱性の利用というのはエクストリームプログラミングになりがちだからです。

 

例えば有名なSQLインジェクションも、インジェクション箇所がLIMIT以降に限定されたり、結果が目隠しだったりが重なれば結構簡単に自動化が困難なパズル実装になりますし、XSSCSSインジェクションも同様で、特殊なケースにおいて、バグから価値のある悪用を行いたいとなれば、それなりに難しいツジツマ合わせの実装を迫られます。JITの動的型システムのミスをつくType Confusionとかが攻撃コードまでナイトメアになる理由の一端です。

攻撃コードは普通に実装であるということで、バイナリの脆弱性というのも攻撃コードまで行くとメタにアセンブリを組んでるだけですし、WEBにおいてのSSRFなどのテクニックからの派生はいささか強引にRPC Proxyの実装と考えられないでしょうか?言葉遊びじみていますが、「大抵の攻撃は多段評価へのインジェクションである」という考え方をしてみれば、脆弱性は結構とらえ易くなります。

 

というものの、任意のアプリケーションで全ての入力は多層的評価パイプラインを移動しており、「入力がどのレイヤでどのように評価されるのか」という点で「開発者/ユーザーがコード上で思い描いていた合意」を越えたとき、バグや設定ミスというものは初めて脆弱性と攻撃ベクトルの可能性を形作る、という視座を持てるからです。

 

前回でもさらっと触りましたが、脆弱性や攻撃にはカテゴリがありMITREなどが割り振るオフィシャルな振り分けがあります。ただこの点で極論どの脆弱性も「どこで、どのような合意が破壊されるか」ということでしかありません(そして極論の多くは誤りかより優れた論があるので気持ちです)。

 

評価するコンポーネントの間で片方だけが入力を管理者扱いすれば特権昇格を起こしますし、文字列を片方だけがコマンドと扱っていたらコマンドインジェクションである蓋然性は高まるわけです。

 

侵入に成功できる攻撃者の多くは「このシステムは脆弱だろうか?」と考えるときに、入力が通過する解析器とその厳密な順序を頭に浮かべ(あるいは書き下し)、それを正確に裏付け、違反の手がかりを探すという手順を無意識に(優れてるほど意識的に)踏むのではないか思っています。

狙いに繋がる手順を列挙し、必要な仮定を満たしているか観察し、システムのパイプラインを逆構築するわけです。よく「OSSでないから安心」というのが成り立たない理由はこのあたりにあり、機能から実装は明らかにできるし、便利な機能ほど手がかりもミスも増えるからです。また攻撃者の最初の侵害目標がアプリケーションのコードになることも多いです。

そりゃコードがあったほうが楽ってこともありますが、ハードコードされた情報の隠匿は大抵甘くなるというのも大きいです。本質的には、現実で生きる開発者の動きやスキル、バックボーンもシステムを通した観察の対象となりうるということですね。

 

観念的かつ抽象的な話に終始したうえ尻切れトンボ感がありますが、今回はこのあたりで一旦畳みます。

個別のトピックは大掛かりになってくるし、どうせおいおい話すでしょう。

 

# 翻った防御

 

攻撃者について書きましたが、上記のことを踏まえたとき防御する側がするべきはなるべく手がかりを与えないことです。対戦ゲームでは相手の嫌なことをしましょうってことですね。この材料としての部分でオフェンシブセキュリティは余技より意義のある考察になります。

ただ一般的なユーザーや開発で邪魔にならない範囲で、というのは案外難しいし、バグがないことを目指すだけで自ずとセキュアに近づくということは忘れてはならないでしょう。セキュアにする目的の工夫が手がかりや脆弱性になるということも案外と多いです。

そういう意味で攻撃者にとって一番嫌なことは堅実なことでしょうか。それをどうすればええんやって話なですが、関わる各々が頭の隅にそういう観点を置くしかないと思うので読者に委ねます(雑)