忙しい人のためのセキュリティ・インテリジェンス No.46 - 2021/08/09
今週のおすすめ/一言所管
SolarwindsのKaseya VISAは同じSupply Chainと言われつつ、アクターおよびその目的が全く異なる
異なるのに、同じような経路（信頼されていたサードパーティベンダー経由でくる）が利用されるということは、メールをつかったフィッシングや過去の水飲み場のように、応用可能な舗装されたローマ街道のようなもの
今後、どの組織もSupply Chainの整備に急がされるだろう
そのためには
Microsoft
AzureAD
Defender
Sentinel
Compliance
Intune/Windows10
他
AWS
Google
トラスト/ガバナンス/SupplyChain
SolarWinds系
Sunspot自体は新しいマルウェアじゃないけど、Solarwinds Orionのバックドア「Sunburst」の構成要素の１つでビルドプロセスに悪性コードを埋め込むやつ
「StellarParticleサプライチェーン攻撃と O365の悪用」
SUNSPOTがOrionパッケージのビルド中にSUBBURSTのソースコードを注入する。
それとは別途、リセラーがライセンス監査するために使う委任アクセスでO365 Phishingをしてeメールの権限を手に入れようとした（失敗）
SunburstのバックドアコードをOrionに埋め込んだSunspotはやっぱりAPT29（StellarParticle）製.
MsBuild.exeを監視、Orionコード（の場合）がコンパイラに読み込まれる前にソースコードを改変する。
どうこれが正規のビルドに混ぜ込まれたのかは不明
MicrosoftはSolarWinds, the SUNBURST backdoor, TEARDROP のコンポネントをまるめて「NOBELIUM」と命名。
SolorigateによってMicrosoft内の１つのアカウントがリポジトリ内のコードをみた
Microsoft自身は、脅威モデル内でソースコードへの知識を攻撃者が持つことを想定し、プロダクトのセキュリティはソースコードの機密性に依拠してない
SolarWindsはSolarwindsのマルウェアが17,000以上のOrion顧客にインストールされたと発表
https://scrapbox.io/files/61192e2acc1a20001d801ccc.png
44%のターゲットは次のようなIT部門を含んだ
SWファーム, ITサービス, equipment調達
https://scrapbox.io/files/61192e711961c60022411553.png
本記事の中で、脅威情報（intelligence）の共有と分析を強化する必要があるとする一文がある
Googleの脆弱性スキーマとか実はMicrosoftへの対抗だったりするんかね？
他のあまり興味ないSolarwindsのリファレンス
Solarwindsのキャンペーン中、全米の会計事務所から従業員の約８割のO365垢が侵害されたと米司法省
APTグループはAPT29/The Duke/Cozy Bear。
Kaseya VSA系
そこまで面白くはなかったかも（不謹慎
ランサムなので金銭目的であり、sunburstのようなstate fundedでないオペレーションでもsupply chainを付いてmassiveな問題を引き起こせるということか
supply chainなので、脅しの対象もスケールできてウハウハ
7000万ドル(約77億円)相当のBTCを要求したとリークサイト上に掲載。（SNS上では要求金額が5000万ドルに引き下げられたと報告するツイートもある。またMSP事業者向けには500万ドル、被害組織には44,999ドルの要求で対応するとした。）
CISAのレコメンデーション
REvil
Kaseya VSAにゼロデリを使って侵入
システム管理対象の端末上のにPowershellを配布してWindows Defenderを無効化
リアルタイム保護の無効化
既知の脆弱性悪用に対する保護の無効化
ダウンロードや添付されたファイルのスキャン無効化
スクリプトスキャンの無効化
制御されたフォルダーアクセスの無効化
ネットワーク保護を監査モード(悪性のIPアドレス、ドメインの非遮断)で動作
クラウドによる保護の無効化
詳細分析必要時のファイルサンプル送信無効化
この際にドロップされるのが、脆弱性のある古いWindows Defender
サイドローディング攻撃では、悪意のあるコードが、標的となる実行ファイルが必要とするものと同じ名前のダイナミックリンクライブラリ（DLL）に組み込まれ、通常は実行ファイルと同じフォルダに置かれるため、正規のコピーよりも先に発見されます。
で、暗号化
ENISA系文書
ENISAによる-Supply chain攻撃の分類を整理
SupplierとCustomerを定義し、それに対する攻撃（attack techniques）とターゲット（assets）を体系化
2020~2021にかける24のインシデントを上記の体系に当てはめて分析
最終的なターゲットを攻撃した62%はサプライヤーとの信頼チェーンを悪用
インシデントの66%はサプライヤーのコードを狙った
最終的な目的の58％はデータ
攻撃者のサプライヤー側の攻撃手法は16%はSWの脆弱性を突くもの。66%は不明
サプライチェーンの一貫性およびインテグリティを確保するため、チェーンの各構成要素の真正性や完全性を確認するための技術的対策や運用的対策が要求された（2015)
NIST系文書
Executive Order (14028)に基づいたNISTのアクション
以下のようなガイドラインのせいがゴール
ソフトウェアセキュリティ評価のクライテリア
開発者やサプライヤーのセキュリティ評価のクライテリア
セキュリティプラクティスへの準拠状態を計測（demonstrate）するツール・手法
NISTが定義したCritical Software
下記のような機能をもつ
特権保持
networkingかコンピュータリソースへの特権アクセス
データやot(op technology)の制御
trustへcriticalな機能
ソフトウェアカテゴリ
Critical SoftwareはICAM
Identity, credential, and access management (ICAM)しらなかったな
OS/ハイパーバイザ/コンテナ環境(ホスト?)
エンドポイントセキュリティ
ネットワーク制御
プロトコル・アルゴリズム・構成管理、制御機能、監視、セキュリティ機能
ネットワーク予防構成
運用監視・分析
リモートスキャン
リモート構成管理・リモートアクセス管理
バックアップと回復
ちとクリティカルの範囲でかすぎない？
上記のCritical Softwareを 利用 するときのセキュリティ対策
対象はCritical SWおよび及びCritical SWが実行される基盤
以下の目標を達成する各種対策が、リファレンス（例: CISA, NIST）とともに用意されている
Unauthorized（不正）なアクセスと利用からの防御
データのCIAからの防御
基盤および基盤にデプロイされるSWの特定とメンテ
脅威とインシデントからの迅速な検知・対応・回復
人的行動および理解の強化
それぞれの目標に対して対策
verifier impersonation-resistant という用語があり、読むと成りすまし防止のために、ログインするPrincipalだけでなくクライアントプラットフォームも対象になる impersonation-resistant という意味っぽい
attestation含む認証ですね
PDFでくれ...
同じくEOを基にNISTが作成したSoftware開発ライフサイクルにおけるSWのVerification（検証）の最小標準
以下を含む
脅威モデリング
自動テスト
SAST
脆弱性やコンプライアンス違反がないかのスキャン
ハードコードされたシークレット
DAST
ビルドインなチェックや予防が組み込まれたプログラム言語の利用
コードベースな構造テスト（結合テスト？） （Code-based structual test)
以前のバグをキャッチするためのテスト
Fuzzerの利用
インターネットフェイシングなアプリについては、web appスキャンなどを走らせること
パッケージやライブラリが、自前のコードよりセキュリティが低くないかチェック
バグフィックス
全文にはツール例も書いてある
とりあえず、この図だけは覚えておこう
https://scrapbox.io/files/61192cc181240800235b6a28.png
プルリクエストに関するパースを適切に行うのは困難であり、脆弱性を作り込みやすい箇所
DefinitelyTypedは、方定義パッケージごとにメンテナが存在する（リポジトリメンテナとは別）
これらのメンテナは、db-mergebot というbot経由でmergeすることができる
db-mergebotは中で、パッケージ単位の権限管理をしていると言って等しい。この権限管理を回避する話。
db-mergebot は、そのロジック上、101個以上のファイルに変更を加えた場合、101一個目以降のものについては、変更対象として権限チェックの対象とならない -> 権限管理の回避に成功
PyPIはpypa/warehouseというリポジトリで管理されている
mainブランチにpushすればpypi.orgにデプロイされる
github actionのワークフローで、Untrusted input を適切に処理しない記述を見つける
また当該ワークフローで、.git/configに書込み権限を持つGitHubアクセストークンがある
そういうリポジトリをワークフローがクローンしていた( actions/checkout ）
えっ、actions/checkout こわいな
ので、上記からクレデンシャルを取得するようなスクリプトを埋め込んだブランチ名を作成し、ワークフローの実行を待つ -> 完了するとGitHubアクセストークンが手に入る
mainブランチを直接変更
ブロックチェーン/Confidential Computing
脅威/脆弱性/インシデント
売られていたCokkieを使って、Slackへアクセス。
また、別の？退職者がSlackチャネルをリスト化したものをパブリッくリポジトリに残してた。
で、従業員になりすましてMFAを入手 -> プログラムをコンパイルするサービスを見つけてソースコード入手
金融
行政/会社/団体
ツール/サービス/OSS
コードリポジトリにおけるOSSFだしたGitHub App向けセキュリティベスプラの自動continuous enforcement
Scorecardsの続きで、特定のScorecardsのチェックを自動適用する
GitHub APIの状態やファイルコンテンツをセキュリティポリシーと照合し、必要なアクションを実行
これは変更だけでなく、issueの作成も含む
現時点では、以下のポリシー適用が可能
ブランチ保護（approvalを要求、レビュワーの数、mergeされないprから承認を剥がす）
外部コラボレータの管理者
バイナリなアーティファクトの検知と通知
今後は自動依存ライブラリの更新やライブラリのバージョン固定
「Package Hunter」: Sandboxないでプロジェクトの依存関係を実行し、悪意ある行動を検知する
Falcoを裏に使ってる
例えば、インストール時にネットワーク接続をしようとするようなパッケージを検知できる
この検知をもとにIPのチェックをするとか。。
イベント/勉強会/発表資料
その他