はじめに#
前編からの続きである。読んでいない方はそちらから読むことをおすすめする。
4/1#
シンガポールはアジア一の金融の街として知られている。そこで金融関係の会社が大集合しているRaffles Placeと呼ばれている場所に散策に向かった。asu_paraさんは勤めているところがFintechの会社であるというのもあってだいぶ興奮していた。
asu_paraさん提供の写真
その後その近くにあったアジア文明博物館を見物するなどする。
そしてBlack Hat Asia 2025の会場にたどり着く。
ここでBlack Hat Asiaの会場はマリーナ・ベイ・サンズであるのだが、 マリーナ・ベイ・サンズというとおそらく大半の人は3つのビルと屋上のプールの組み合わさった様子を思い浮かべると思われる。
しかしこういったイベントの開催場所となっているのはその有名な建物の前にあるショッピングモールが併設された建物である。ということに現地で気づいてちょっとびっくりしていた。
さてたどり着いて上がってみたもののなんと既に入場時間を過ぎておりasu_paraさんは粘ってたもののセキュリティが厳しかったので結局会場には入れずじまいであった。
そこでその近くにあったGardens by the Bayに行って OCBCスカイウェイを歩くなどする。
その他夜にはマーライオンのところに行くなどする。昼間は遠目から見てもわかるほど激混みしていたのだが夜になると意外と空いていた。
さてこの日に至っても発表資料ができていないということで帰ったあとsisakulintといろいろ作業していたら 有効になっているはずの機能が無効になっていると判明して直す作業をしていた。
https://github.com/ultra-supara/sisakulint/pull/143
4/2#
この日はasu_paraさんはFinantial Service Summitに行っていた。 筆者は午前中はホテルでのんびりと過ごし午後はNetwork Operation Centerに見学に行くなどしていた。
なお大多数の人にとってはどうでもいい話であろうがこの写真について一言述べておく。 このNOCのためのOpen Network Detection and Resposneを提供しているcorelightが今回のやつで 提供していたZeekというソフトウェアがある。 実のところ筆者はSecHack365時代にbrgenというものを作っていたときに このZeekに付随しているSpicyという言語について調べていた時期がありそれもあって このZeekが使われているのを見ておおぉ使われてるんだぁとすごく興奮した。
なおこちら筆者が作っているbrgen(唐突な宣伝)。
4/3#
さていよいよこの日からがイベント本編といったところである。
午前中はBriefingsを1つ聞いたのとArsenalのあたりをうろちょろしていた。
まずはArsenalの会場の様子
そしてプログラム表(3:25 PMのところにsisakulintがある)
Think Inside the Box#
まずBriefingsを聞いた。
日本人発表者の講演であった。 要約するとWindows Sandboxの脆弱性をついたバックドアの事例についてとそれを検出する方法について述べられていた。
なおBlack Hatでは新規性というのが結構重要視されるらしいのだが応募してから講演までそれなりに間が空いているため その間に日本の警視庁及びNISCがこの事例について公表してしまっているという状態であったので探せば他にも記事がいくつか見つかる。
まず前提として現在Proエディション以上のWindows10/11では
- 別途VMなどをインストールしなくても使える
- ハイパーバイザーベースの
- 軽量な
- 分離された
- デスクトップ環境を提供する
Windows Sandboxという機能が使える。
またその設定は.wsbファイルというxmlベースの設定ファイルで記述することができる。例えばネットワークを有効化するか否かを記述するNetoworkingやサンドボックス内(Guest)と外(Host)のフォルダを共有するためのMappdedFolders、Windows Sandbox起動時に実行するコマンドを設定するLoginCommandといったものがある。(概念的にはdocker composeのdocker-compose.ymlに似ている)
しかし例えばいくらか制約もありたとえばHost環境でアンチウイルスソフトを動かしていてもGuest内では動かないといったような制約もある。
この前提を踏まえて実際のシチュエーションを見ると まず暗号化/圧縮されたmalwareをHostにどうにかして置く。(本事例ではANELバックドアを使用して設置したとしていた) その後Windows Sandboxが表示するUIによって気づかれるのを防ぐためにSYSTEMアカウントを使用してWindowsSandbox.exeを起動するようにschtasksを使って指定。 その時渡す.wsbファイルにはC2サーバーと通信するためにNetworksを有効にし、さらにHostに置いてあるユーザー情報など及び先程置いたmalwareが入ったディレクトリをMappedFoldersで指定してマルウェアの解凍用batchファイルをLoginCommandに設定して起動する。
Sandboxが起動するとマルウェアが多段階にわけて解凍され、NOOPDOORが出現しそしてSandbox環境内で起動される。
このようにするとEndpoint Protection Platform(EPP)やEndpoint Detection and Response(EDR)の検知をかいくぐれてしまったのである。
またこの事例では.wbsファイルがファイルベースであったが最近はwsb.exeというコマンドラインベースのツールが登場したらしくコマンドラインオプションで.wbsに書いてある設定を直接渡せるなどメモリベースでより起動フローをわかりにくくさせるということもできるようになりつつある。
では対策はあるのかと言うとまずログをきちんと取ればsigma rulesなどで不正な実行を検知したりすることができる。
またWindowsのGroup Policyを使ってNetworkやMappdedFoldersを無効化するなどができる。
さらにはWindows Sandbox内のリソースはHostからはvmmemSandbox.exeなどのプロセスのメモリ領域として見れるためそれをスキャンすることでmalwareの実行を検出することもできると述べられていた。
r0fuzz#
ここからはArsenalの話である。
https://www.blackhat.com/asia-25/arsenal/schedule/index.html#r0fuzz-a-collaborative-fuzzer-43908
発電所などで使われているIndstrual Control System(ICS)で使われているMODBUS,OPC,UA,DNP3等といったハードウェアネットワークプロトコルをfuzzingするためのツールである。
Mutation based fuzzing,Generation based fuzzing,AI driven coupus generationなどといった機能が統合されている。
なおこれ自体とはあんまり関係ないが現地では発電所に対してハッキングするCTFのようなものが行われていた。
https://www.blackhat.com/asia-25/arsenal/schedule/index.html#circuit-breaker-ctf-43220
といってもほとんど手順書通りにコマンドを打ち込むだけだったのだが なんというかリモート経由で発電所内に設置されている特定のレジスタの値を書き換えることで 発電所の挙動をいじったりショートさせたりするという感じであった。 以下のツールを使っていた。
kntrl#
kntrlはCI/CD上でeBPFベースで不審な通信を検出し拒否するようにできるツールである。 CI/CDではしばしばサードパーティのアクションというのものを使ったりするが、そこが乗っ取られて意図しない通信が行われ情報が抜き取られるなどといった攻撃をされるという事例は枚挙にいとまがない。さらにCI/CDは開発環境とみなされしばしば過剰な権限を付与されておりそれが脆弱性を引き起こすこともある。またそもそもとしてCI/CD上での通信を完全に把握するのは難しい。 そこでこのツールが役に立つ。
Open Policy Agentのrego言語を使ってpolicyを定義することができるためこういったツールの利用に慣れている人にはわかりやすい。
mantis#
https://www.blackhat.com/asia-25/arsenal/schedule/#mantis---asset-discovery-at-scale-43534
mantisは攻撃対象の発見、偵察、スキャンといった作業を自動化しさらにはDashBoardで表示すると言ったことまでできるツールである。 autoreconという似たようなツールを聞いたことはあったがこちらは分散ノードでスキャンしたりとかアラート機能がついてたりとかしている。 攻撃面の洗い出しと言った作業がより効率的にできるようになる可能性がある。
jary#
https://www.blackhat.com/asia-25/arsenal/schedule/#jary---a-modular-data-correlation-engine-43640
JARYはYARAに影響を受けたルール定義言語でありログデータなどを受け取ってそれを分析したり変更したりと言ったことができるエンジンである。開発当初はログデータの解析が主な目的ではあったらしいもののログの直接的な解析自体はユーザーの責務と割り切った設計になっているため例えば入力にhttp requestのjson bodyをパースしたものを入れて判定させるなどすることで入力検証などといった用途にも使えるとしている。
個人的には発表の流れが面白いなあと印象に残っている。あとリポジトリのreadmeとかにところどころ思想の強さを感じる…
nimplant#
https://www.blackhat.com/asia-25/arsenal/schedule/#nimplant-43204
nim言語とRustとPythonで書かれたCommand and Control(C2)を実行するためのimplant(攻撃対象のコンピュータで実行されるソフトウェア)及びそのサーバーである。 構成ファイルを記述することでimplantの挙動の書き換えができるようになっている。
リポジトリを見てみると面白そうなんだけど正直あんまり印象に残ってない….
sql-data-gurad#
sql data guardはSQL Injection等を防ぐためにsqlのアクセスしようとしているデータと条件に応じて検証しさらに可能であれば修正まで行うツールである。例えば
SELECT id,customer_name FROM orders WHERE 1 = 1のようなQueryが来ても例えばクエリにidとproduct_nameだけ許可するとかWHERE節にaccount_id=3がなきゃだめとかいう条件を記述することでこういったのを検知しさらにはSELECT id,product_name FROM orders WHERE account_id = 3に直したものも提供すると言った機能を備えている。
LLMによるSQL生成というのをひとつの焦点にしており、 既存のDBにはfine-grantedなcolmuns levelやrow levelのアクセス制御とかいうのがないのは 問題である的な話をしておりこのツールを使うことでそ言ったきめ細やかなアクセス制御が可能になると言ったようなことが述べられていた。
このセッションは3日と4日両方でやっていた。
他にも見たのがある全部書くとと長いので割愛…(気が向いたら追記されるかも…)
sisakulint#
そして午後は自分たちの発表であった。
asu_paraさんのslide https://speakerdeck.com/4su_para/sisakulint-ci-friendly-static-linter-with-sast-semantic-analysis-for-github-actions
発表の様子#
写真をいくらか撮ったものの普段そういった撮影をする技術を研鑽していないのがあだとなって
人が多少多いが発表者の顔が見切れているやつか人が少ないがそれなりの構図というパターンしか撮れていないので写真を統合してなんとなーく想像してほしい。
なお発表内容自体は上記のスライドを参照していただきたい バッサリ切っていくスタイル
触りだけ言うとGitHub Actions WorkflowのyamlファイルのlinterでありさらにはSAST的な機能やAutofixなどといった機能が盛り込まれている。
構図的にはスピーカーが写りつつ一番良かったやつ
人が多めなやつ
asu_paraさんはカンペを見るためにXREALを持っていっていたものの会場ではどうも文字が小さすぎて見えず結局カンペ無しで喋っていた。
スライドを見ず即興で喋っていたが聴衆の様子を見るにちゃんと伝わっていたようだ(なお筆者の英語に限らないがリスニング能力はだいぶ低いので本当に伝わっていたのかどうかは現地にいた人のみぞ知るである)
正直に言って自分は全くもって発表するって面では貢献できていないのでそちらについては割愛。
時間割当が75分の中で2回ほどサイクルを回してasu_paraさんがスライドを見せつつ喋ってという感じであっという間に終わりを迎えた。
なお日本人参加者もちらほら見かけることが多かった。
なお終わったあとこのArsenalのレビューボードの方と写真を取らせてもらったがあいにくそちらの写真はasu_paraさんしか持ってないので見たい方は彼に聞いて下さい。
その後#
Think Inside the Boxの講演をしていた原さんに遭遇して少し話を聞く。 BriefingsではSpeaker Coaching Programなるものが発表前にあるらしくJSACの選考委員などをやっていてそういった仕組みをJSACにも取り入れたいと思ったといったような話を聞く。
4/4#
とりあえず発表は終わったのでArsenalとBriefingsを見ていった。
Decoy Mutex#
Arsenalの話からする。
Decoy MutexはWindows環境においてマルウェアが同じマルウェアを複数同時に実行しないようにするためにある特定の名前のMutexを使うことを利用してあらかじめDecoy MutexによってMutexを保持しておくことでマルウェアの実行を防ぐというソフトウェアである。
正直これだけでも実際にマルウェアを阻止できているのを見ると結構有効な手段そうだなあと思った。
Silver Saml Forger#
Silver SAML ForgerはSAMLのレスポンスを作成するツールでありSilver SAML Attackの実装等にも使えるツールである。
Silver SAML AttackとはSAMLのIdPを侵害することで署名をつけた任意のSAMLレスポンス(Assertion)を生成できてしまう脆弱性であるGolden SAML Attackに対して署名を検証する側のService Providerを侵害して検証用の公開鍵を書き換えることで攻撃者による署名を付けたSAMLレスポンスを正常なものとして認識させてしまうという脆弱性につけられた名称である。企業内部でしばしばやりがちなといっても筆者は実際のところを知らないんですが自前の証明書チェーンをimportしてSAMLで使うというシナリオにおいてそのimportのプロセスで攻撃されて入るというような話であった。
実際に攻撃の様子を実演してみたりしていた
Casino Heist#
Ethereumというスマートコントラクトを実装したブロックチェーン上でそのスマートコントラクトを記述するための言語であるSolidityなどの脆弱性について学べるplaygroundである。これを作っている人がホスティングしているサイトもあればdockerで動かせるバージョンもある。
このplaygroundの動機はなんにもわからない完全初心者には既存のブロックチェーンのセキュリティの話を扱うコンテンツ(Walletが,Etherの送信が…,こういうツールを使え…WriteUpを読め…etc)がハードルが高すぎるという問題意識からきており初心者Lv1の人に対して初心者Lv1のためのPlaygroundを提供するという説明をされていた。
前に何かのCTFに一回参加したときにSolodityの脆弱性を使うやつを見たのだが大体わからんかったのでこういうのを見て勉強したい…
こちらも他にも見たのがあるが全部書くとと長いので割愛…(気が向いたら追記されるかも…)
Briefings#
CDN CannonとByzRPのBriefingsを聞く。 といってもほとんど聞き取れもせずだったのだが… ということで以下の内容は振り返りついでに公開資料を読んでまとめている。
CDN Cannon#
CDN Cannonの方は簡単に言うとCDNを使ってAmplification攻撃が出来てしまうという話であった。 例えばCDNの中にはimageを取ってくるときにCDN側で画像を切り取ったりしてサイズを変更してクライアントに送信できるという機能があるものがある。
-> GET /image.png?crop=100,100 -> -> GET /image.png ->
Client CDN Origin Server
<- 200 OK (100x100の画像) <- crop <- 200 OK (300x300の画像)<-
このとき例えば攻撃側がcropの値を1,1とすると
-> GET /image.png?crop=1,1 -> -> GET /image.png ->
Client CDN Origin Server
<- 200 OK (1x1の画像,数百byte) <- crop <- 200 OK (300x300の画像,数kB/数MB)<-
このようにOrigin ServerからCDNへの転送量がCDNからクライアントの転送量に対してだいぶ多くなる。 他にもドメインの所有についてきちんと検証しないヘッダの書き換えができるCDNを使って巨大なヘッダを含むリクエストを送りつけたり HEADをGETに変換する挙動をするCDNを使ってHEADリクエストを送りつけて大きな容量のデータをOrigin ServerからCDNに送らせるとか。あるいはクライアントからリクエストを送っておいてコネクションを切断するがOrigin ServerからCDNへはデータが送られるようにするとか。 もちろんこれら一つ一つだけでは大した事なさそうではあるが塵も積もれば山となるようで 検証した結果Client-CDN間が数kbpsレベルの転送量でCDN-Origin間に数Gbpsレベルの転送量を与えることが出来たそうである。
もちろんネットワーク帯域に対してかなりの負荷をかけるという面があるというだけではなく 発表自体では直接的な言及はなかったものの 例えばOrigin ServerがAWSなどのクラウド環境に置かれているとき そのOutbound転送には課金がされていることが大半である。それがCDNを使ってこのように大量の転送を引き起こすことができてしまうとコストを無駄にかけさせるという攻撃ができてしまうのである。
対策としてはRFCに準拠してHEADはHEADでProxyするようにするとか クライアントが切断したらCDN-Origin間も切断するようにするとかといったことが述べられていた。
ByzRP#
ByzRPの方はBGP(Border Gateway Protocol)のRPKIの仕組みを改善するためのアーキテクチャを提案しているものである。 まず前提としてBGP自体はスケールし効率的で素早くルーティング情報をネットワーク間に伝播させることを目的としている。しかしその設計自体にはセキュリティというのが組み込まれていなかったため 例えばルーティング情報の出どころが正しいことを保証するメカニズムがなく 過去には間違ったルーティング情報が流れて大規模障害が起こったりあるいはパケットを吸い上げて盗聴しようと意図的に間違ったルーティング情報を流されたりといったことが起こったりしている。(BGPハイジャック)
そこでRPKI(Resource Public Key Infrastructure)という仕組みを導入しルーティング情報の出どころを検証できるような仕組みが広まっている。 具体的には各地域レジストリ(RIR)などがPublication Point(PP)にてリソース証明書(IPアドレスやAS番号などの保有を証明するCA証明書やルーティング情報を広告する認可を表すRoute Origin Authorization(ROA)に署名するための秘密鍵に対応するEE証明書などがある)やCRL(失効リスト)などを配布しておりそれらをRelying Party(RP,ISP等及びそれらが使用するPPからの収集/検証/ルータへの適用を行うソフトウェア)がそれぞれ収集してROAによるRoute Origin Validation(ROV)を行いそれを各自の持っているBGPルーターのフィルタリングルール等に適用するなどすることで実現している。
一見良さそうではあるがこの仕組みには問題がいくつかある。
まずRPKI自体はoptionalな機能であるためRPがPPからROAなどを取得できないとその情報はないものとして扱われるという点がある。
例えばRPとPPの間の通信を妨害するあるいはPP自体を乗っ取ってレスポンスに長い遅延を含めてタイムアウトさせるなどすれば検証自体を無効化出来てしまうのである。
あるいはRPの実装の問題としてRPに不正な入力を入れてクラッシュさせてBGP Routerに情報を行かせないということもできてしまう。
そうでなくてもネットワークの障害等でコネクションエラー等が発生するとやはり無効化されてしまう。
総じてセキュリティの三要素の可用性に問題があるといえる。
そこでこのByzRPではWatchDogの追加と分散コンセンサスアルゴリズムに基づいたRPの実装を提案している。
まずWatchdog機構ではPPとRPの間のやり取りを監視しRPがクラッシュしたりあるいは通信遅延が異常に長かったりするのを検知するとそのPPをブラックリストに入れるといったことを行う。 これによってPPの乗っ取りやあるいはRPのクラッシュに対応ができるようになる。
またネットワークエラーによる無効化の対策にはビザンチンフォールトトレラント(ByzRPのByzはByzantionから来ている)な分散コンセンサスアルゴリズムを使って複数のRPで合意を取ることでたとえ1つのRPがネットワークエラーでPPからROAを拾って来れなかったとしても全体で見ればROAを拾って検証することができるようになる。
またこの仕組みを様々な人で共有してRP-as-a-Serviceのような形にすればより多くの人が個別でRPを用意するよりもより少ないトラッフィク量でより信頼性の高いRPが実現できるようになりよりRPKIの実装がしやすくなると主張されていた。
その他#
企業ブースのあたりをうろついてみたりNOC Presentationとか聞いていたりしたがあいにくリスニング能力なさすぎとかとかバイタリティが足りなすぎてあんまり聞けたりはしなかった…もったいなかったような気もする。
最後に終了講演を聞いてこの日が終わり こんな感じでBlack Hat Asia 2025は終わった。
4/5#
この日は朝チャンギ空港に向かって荷物を預けそして Tampinesあたりまで言ってそこのフードコートで板麺を食べるなどする。 その後シンガポール国立大学を見に行くなどしているうちにあっという間に時間が過ぎそして深夜の飛行機で日本へと帰っていったのであった…
まとめ#
1週間近くシンガポールに行って美味しいものを食っていろんなものを見て聞いてなかなか貴重な体験をしたんだろうなぁというのを感じる。いろんなセキュリティ系の技術を見てセキュリティの幅は広いなぁということを実感した。
なお他にもいい景色を見たり人に会ったりドリアンを食べたりと言ったエピソードもあるのだがそちらは省略されている。聞きたい人は現実の筆者に会ったときにでも聞いてほしい。
あとこの記事自体ではあまり触れていないが今回の一連の旅程ではasu_paraさんの行動力の高さに非常に感心した。
自分はなんというか性根が"Ask for forgiveness, not permission"ではなく"Ask for permission before acting"という感じであるため、まずダメそうかなぁという判断をしがちであったがasu_paraさんは臆することなく行動していて自分にはそういうとりあえず行動という精神が大いに欠けているなというのを思ったのであった。
なおこの話をasu_paraさん本人にしたところ「行動よりもコミュニケーション能力の問題だと思っていて、英語がペラペラであることよりも、伝わる英語が話せるかを意識している」と言っていたがあいにく筆者の英語リスニング能力が壊滅的なので実際伝わっていたのかどうかは判断できない(多分伝わってはいたと思うけれども)。しかしこのとにかく臆さず会話をしに行っていた姿勢は是非真似していきたいところである。
宣伝#
こういった経験ができたのもすべてasu_paraさんのお陰であると同時に元をたどせばSecHack365に参加したおかげである。ありがとうSecHack365。
セキュリティに興味がある人やなにかを開発したい人あるいは強強な技術者達に会いたい人はぜひぜひSecHack365に参加してほしい。
一年かけてものづくりしたりあるいは人と交流したりする中できっとなにか人生の糧になるような経験ができるであろう。
2025年度の締切は5月13日(火) 12:00までです。
詳しくはこちら👇️👇️👇️👇️👇️👇️
https://sechack365.nict.go.jp/requirements/
ぼやき#
⚠️ネガティブ節全開なボヤキなので見たくない人は飛ばしてください⚠️
一応隠していない部分についてはできる限りポジティブめのことを書いたつもりではあるが 一方である種の本心(ポジティブな部分が本心でないというわけではない)としてこういう感情を持っていた面もあるということを残しておく。この記録を書いていてこの経験をしたことについて振り返ったとき 正直外に出ること自体があまりないのと人に興味がないのといろいろあって体験していることが貴重なのかどうかという判断が本質的な意味ではそもそもつかないという感じがしている。
自分自身の判断として価値があると信じられているかと言うと「客観的な指標を参照すればおそらく価値があるであろうと推定される」みたいな捉え方に近いような認識になっているような主観(回りくどい)というのが正直なところでなんかもったいないなぁということを感じている。
あとこれらの発表されていた技術群を並べて見せられたとしても正直適切に評価するのは出来ていないだろうなぁというのを感じたりもする。無知であると情報がすべて等価に見えるというなんかで聞いたような言葉を強く実感する。後からするのが後悔だというがまさにそんな感じである。
感受性も解像度も低いしInputを言語化したり体系化するのが億劫でなにかと理由を付けては先延ばしにし4月の頭に行ったはずなのにもはや5月である。
他にも聞く気になれば翻訳アプリとか活用したりで聞けばよかったじゃんとも思ったりしたが後の祭りである。
あとその場にいても訊きたいことが思い浮かばなくてあとからああこれ訊きたいような気がするなぁと思ったりする。
事前に読み込んだりとか言う準備的なのをしておけばもっと楽しめたのかなぁというのをひしひしと感じたりもする…