こんにちは、もっと楽にセキュアなプロダクト開発/運用を実現できるようにしたい米内（@lmt_swallow）です。今週も Issue #3 までと同様に、普段の生活の中で気になった情報をざっと紹介していきます。

「Rust でアプリケーションを書く際に認可実装をコンパイル時検証可能にするためのフレームワーク」である Dacquiri に関するブログが出ていました:

Eliminating Authorization Vulnerabilities with Dacquiri

Over the last year I've taken a step away from my usual bug bounty work to focus more on building resync - my continuous reconnaissance platform. As part of that work, I've built, and made public, a high performance TCP SYN scanner named Armada and a unique authorization framework named Dacquiri.

かなり informal な表現を多用しつつ説明すると、Dacquiri は認可実装の漏れや不備を、以下の 2 つをもって（trait bound が unsatisified であるという形の）コンパイルエラーとして検出するためのフレームワークです:

• (1) “attribute”（例: 「このユーザは認証済である」）という概念を導入する
• (2) アプリケーション内での “操作” （例: 「あるユーザの口座からお金を引き出す」）の際に、その操作が必要とする “attribute” たち（≒ “entitlements”）の存在が確認されているかを trait boundary として表現するのをサポートする

もっと抽象化していうなら Dacquiri は「アプリケーション内の “操作” を定義する際に、その “操作” に関する事前条件が満たされていることを trait boundary として表現すること」をサポートしてくれる君である、というわけです。この手の発想は突飛なものではなく、自然なものですが、面倒な実装をフレームワークとして Wrap したという点がこのフレームワークの貢献だと捉えることができます。

認可などのセンシティブな処理を書く際にこのように静的に検証可能な領域が大きくしていくようなプラクティスは（大事なアプリケーションを書くときほど）実践していきたいものですね。

（認証・）認可のテストを網羅的に・自動的に行うことを目的としたツールは定期的に出てきますが、気がついたら以下のようなツールが登場していました:

GitHub - hahwul/authz0: 🔑 Authz0 is an automated authorization test tool. Unauthorized access can be identified based on URLs and Roles & Credentials.

🔑 Authz0 is an automated authorization test tool. Unauthorized access can be identified based on URLs and Roles & Credentials. - GitHub - hahwul/authz0: 🔑 Authz0 is an automated authorization test tool. Unauthorized access can be identified based on URLs and Roles & Credentials.

ざっと試してみたところ、まだ若干かゆいところに手が届かない感はありました。 Nuclei とかもそうなのですが、こういうテストのための定義を YAML で書く、というのは（表現力に乏しくて）難しい側面があると思うのだよな……。

このへんをいい感じに自動化したいと思っている勢力はたくさんいるはずなので、引き続き頑張っていってほしいところです。応援していきたい。

SpiceDB などの Schema （認可判定のための種々の定義）を Online Migration するためのチュートリアル記事が Authzed から出ていました:

Online Schema Migrations in SpiceDB

Data migrations are a fact of life for any application. Requirements change, features are added or removed, services are merged together or split apart. As the application evolves, so too must the data behind it. In this regard, the permissions information you store in SpiceDB is no different from any other data in any other database.

実際 SpiceDB のような一度運用に載せた後に止めにくい系ソフトウェアを本番投入するとなると、確かに Online Migration の難易度は気になるところです。この記事を見る限りは、少なくとも単純なケースではそんなに難しくなさそうですね。

自分自身はまだ Online Migration をしたいな〜というほど SpiceDB を触っていないですが、この手のマイクロサービスの Developer eXperience を考えるために今度自分でも深く考えてみたいなというところです。

弊社（株式会社 Flatt Security）のメンバーがログイン機能の実装において起きうる脆弱性と、その対策についてのブログ記事を書きました。2021/02/06 現在 680 はてブもの反響を頂いており嬉しい限りです。いい記事なので、よければぜひご一読ください！

Webサービスにおけるログイン機能の仕様とセキュリティ観点 - Flatt Security Blog

こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上 @0x003f です。 本稿では、Webアプリケーション上で実装される「ログイン機能」の実装パターンをいくつか示し、その「仕様の中で起きうる脆弱性」とその対策について解説していきます。 「ログイン機能」はToB、ToC問わず多くのWebアプリケーションで実装されている機能で、XSSやSQL ...

GuardDuty の EKS サポート！めでたい。AWS は静的な設定監査/ガードレール方面だけでなく、この手のランタイムモニタリング系の仕組みも手堅く拡張してきていていいですね。

Amazon GuardDuty now protects Amazon Elastic Kubernetes Service clusters

Posted On: Amazon GuardDuty has expanded coverage to continuously monitor and profile Amazon Elastic Kubernetes Service (Amazon EKS) cluster activity to identify malicious or suspicious behavior that represents potential threats to container workloads. Amazon GuardDuty for EKS Protection monitors control plane activity by analyzing Kubernetes audit logs from existing and new Amazon EKS clusters in your accounts.

AWS の利用に際して起こったセキュリティインシデントを、その根本原因や権限昇格の流れ、影響度などを整理しつつリストアップしてみたものが流れてきました:

GitHub - ramimac/aws-customer-security-incidents: A repository of breaches of AWS customers

Security is an exercise in managing risk. Reviewing the common root causes of security incidents is an effective way to guide prioritized remediation efforts. This repository seeks to index all publicly disclosed AWS customer security incidents with a known root cause. It will exclude incidents involving exposed data stores (e.g S3 bucket leaks, exposed managed or hosted databases).

よくある現実的なパターンの事例が多い（≒ 最近のバグバウンティ的な込み入った攻撃例は少ない）ので、チーム内で過去のインシデントから学びつつ意識を高める、といった目的には一定マッチしそうなリストですね。

OpenSSF から新プロジェクトとして、OSS のセキュリティを向上させていくためのプロジェクトである “Alpha-Omega Project” がアナウンスされました:

OpenSSF Announces The Alpha-Omega Project to Improve Software Supply Chain Security for 10,000 OSS Projects - Open Source Security Foundation

Following a meeting with government and industry leaders at the White House, OpenSSF is excited to announce the Alpha-Omega Project to improve the security posture of open source software (OSS) through direct engagement of software security experts and automated security testing. Microsoft and Google are supporting the Alpha-Omega Project with an initial investment of $5 million.

“Alpha-Omega Project” は “Alpha” と “Omega” の 2 つのプロジェクトからなります。このうち、前者の “Alpha” は OpenSSF の Securing Critical Projects ワーキンググループを中心に選定されるとりわけ重要な OSS プロジェクトへのサポートを行うためのものです。一方後者の ”Omega” はより広い範囲（最低 10,000 程度）のプロジェクトのサポートを行うためのプロジェクトとなっています。

個人的にはサポートされる OSS コミュニティ側がどういう反応を示すのかが気になるところです。社会的に重要度の高い OSS を上から並べてみたときに、その上の方にあるプロジェクトの全てがいい温度感で迎えくれてくれるかというと、どうなんだろうなあ。杞憂だとよいのですが。

以下の記事では sigstore が公開している Helm Charts に付加されるようになった Helm Provenance の利用方法や、Helm の sigstore プラグインの概要や用法が説明されています。Helm の Integrity の検証のための機能、知らなかった。

Provenance comes to the sigstore Project Helm Charts

Helm includes supports for packaging and storing charts within OCI registries and this architecture aligns well with the sigstore project as the cosign tool uses the same approach to store signatures as artifacts within registries. Note: As of the time of this writing, the OCI capabilities within Helm is marked as experimental.

Citi の Supply Chain Security 周りへの取り組みを概説する記事が Chainguard から出ていました。SLSA フレームワークなどをベースに、Tekton / Sigstore / Kyverno / Spire などを用いたリファレンス構成を考えてますよ、的なやつです:

How Citi is building the secure software factory with Sigstore and Tekton

Securing the software supply chain is of paramount importance to the tech industry today. However, it remains a big challenge as several best practices need to be implemented in order to successfully secure it. To give you an idea of the scale of the challenges, this whitepaper from the Cloud

Ruby/gem 方面のコミュニティと Sigstore プロジェクトとの協働も始まったようです:

Sigstore ❤ Ruby!

We started the Sigstore project with a goal of making key management, certificates, and digital signatures accessible and easy to use for every developer and language community. It's incredibly exciting to see our tooling and services used by new ecosystems, so we were thrilled to see the recent RFC from Shopify around improving the signing mechanisms on RubyGems using Sigstore.

以下は sigstore に関する 1 月のレポートです:

sigstore project update - January 2022

A new year and a new update blog on project sigstore! Lots of exciting events have happened (with a lot more on the horizon) to get the new year off to a great start. The good folks at shopify open...

“sigstore is now getting close to being operationally GA” というのにワクワクしますね。確かにコミュニティとしての成長も感じられる時期ですし、コードベースもだいぶ安定してきているし、cosign は最近 1.0 で GA を迎えたしで、いい流れを感じます。

以下はタイトルの通り cosign による署名検証を Admission Webhook で行うための実装です。これ sigstore 公式に既に存在してると思ってたけど、なかったんかい:

GitHub - appvia/cosign-keyless-admission-webhook: Kubernetes admission webhook that uses cosign verify to check the subject and issuer of the image matches what you expect

Kubernetes admission webhook that uses cosign verify to check the subject and issuer of the image matches what you expect - GitHub - appvia/cosign-keyless-admission-webhook: Kubernetes admission webhook that uses cosign verify to check the subject and issuer of the image matches what you expect

public な Sigstore インフラ（例: Rekor や Fulcio のパブリックインスタンス）を使いたくない場合、自前で用意した Root of Trust / Bring-Your-Own (BYO) TUF を用いて Sigstore インフラを組み立てられるよ、という記事が Sigstore から出ていました:

Sigstore: Bring-your-own sTUF with TUF

Authors: Hayden Blauzvern and Asra Ali, Google Open Source Security Team Users of Sigstore may want to leverage Sigstore tools and infrastructure, but may not want want to rely on Sigstore's root of trust or all of the components of the public infrastructure.

ひとまず「頑張れば公開インフラに頼らずに Sigstore 系ツールチェーンを使うためのインフラが作れる」という事実さえ覚えておけば日常生活に支障はないのですが、より細かい話を知りたい方や将来の自分向けに追加説明を置いておくと、TUF とは The Update Framework という「ソフトウェア更新に関するセキュリティを支えるためのフレームワーク」です。詳しくは以下の記事を読んでみてください:

The Update Framework and You

Why does it need to be so TUF? If you're anything like me and spend time reading blog posts and GitHub discussions around how to securely package and release software, you've probably heard of The Update Framework. Unfortunately, if you're actually anything like me it probably seemed overwhelming and confusing at first.

そして TUF は、Sigstore の公開インフラ類の Root of Trust を保護するために利用されています。これに関しては以下の Dan Lorenc 氏の記事で説明されているので、こちらを確認するとよいでしょう:

Using The Update Framework in Sigstore

This is a technical update on how we're integrating The Update Framework into the Sigstore projects and infrastructure. If you're not familiar with TUF, please consider reading this overview first! We use TUF in the Sigstore project to protect our own keys and infrastructure, but we're also hoping to make it possible for end users to use TUF on their own, using the Sigstore tools.

以下は OCI image の signature の位置が disconnected である (= 標準的な場所にない) ときの署名検証方法のチュートリアル記事です。これはめっちゃ面白いというわけではないですが、最近ちょっと入り用になったので、備忘録がてらここにリンクを置いておきます:

Managing Disconnected Signatures Using cosign

Cosign is a tool within the sigstore project that greatly simplifies how content is signed and verified by storing signatures from container images and other types in OCI registries. By storing signatures with a predictable name as a related OCI artifact within a registry, the content can be leveraged by both consumers and producers of the signed material.

Shopify が Dependency Confusion 対策を解説する記事を出していました:

How We Fixed the Dependency Confusion Vulnerability in Over 600 Ruby Applications

Shopify has grown significantly over the years, and our success makes us an attractive target for malicious actors. We take the safety of our merchants seriously, so we have a good reason to continuously improve the security at Shopify.

この記事の背景には、かつて Shopify は Bug Bounty にて Dependency Confusion 攻撃の可能性について報告を受けている、という過去があります。その詳細は、以下のバグハンター視点での記事で語られているので、興味があればこちらもあわせて読んでみるとよいでしょう:

Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies

Ever since I started learning how to code, I have been fascinated by the level of trust we put in a simple command like this one: pip install package_name

いくつかの “Google Drive Intergration”（Google Drive API を叩くような実装）が発行する Google Drive API へのリクエストに、何らかの方法でクエリパラメータを追加することで、当該 Integration から SSRF ができた的な事例についての Writeup です:

writeups/Hacking-Google-Drive-Integrations.md at main · httpvoid/writeups

Have you ever observed Google Drive integrations in your bug bounty targets and wondered what else might be there besides the OAuth CSRF? Is it possible to hack this integration a step further? That's exactly what we'll explore today. Before we go into the vulnerability, let's take a look at how Google Drive is typically integrated into applications.

HTTP/2 から HTTP/1.1 への変換時に、変換後のリクエストに改行文字列を含ませることで良い感じに Requst Smuggling できる場合がある、といった事例は去年しばしばバグバウンティ界隈で見られていた気がします。

最近見かけた以下の記事は、そんな Request Smuggling を用いた攻撃の事例でした:

A story of leaking uninitialized memory from Fastly

This post will go through a QUIC (HTTP/3) implementation bug in the H2O webserver. The bug is pretty interesting as it affected Fastly in a way that it allowed stealing random requests and responses from uninitialized memory of its' nodes, somewhat similar to CloudBleed (but unlike CloudBleed, this vulnerability required a specific actions from an attacker).

ここで語られている事例は (1) Fatsly への HTTP/3 なリクエストの際に :authority ヘッダを用いて Request Smuggling を行うことができ、(2) さらに Fastly 内部で HTTP/3 終端をしている存在が H2O であることが特定でき、(3) 最終的には H2O の QUIC 実装のバグを用いた exploit により他リクエストのデータをリークすることができた、というものです。

HTTP/2 に関連する諸実装に関しての諸リサーチの流れはそのまま、まあしばらくはこの手の Request Smuggling の実例は見つかりそうなものですね。HTTP/2 や HTTP/3 関連実装の運用をしている方は、引き続きこの手の情報をウォッチしつつ、適宜当該実装のアップデートをするようにしておきたいものです。

久々に日本発の SaaS 情報が出ていました:

ノーコードでWireGuardフルメッシュVPNを企業ネットワークに提供するSaaS「Wissy」がβ版ユーザー募集開始 | TechCrunch Japan

Notchは1月24日、SaaS型でWireGuardフルメッシュVPNを提供する新サービス「 Wissy 」のβ版ユーザーの募集を開始したと発表した。β版への登録は、公式サイトから電子メールで行う。 ...

LP などから読み取れる限りでは、WireGuard を良い感じに使うためのガワを作っているのだと思うので、いまのところは実質 Tailscale と同じことかそれに類することをしたいのかなと理解しています。今のところは正直差分が分かっていないのですが、今後事業フェーズが進むと（技術的なものか対象セグメント的なものかはさておき）差分も見えてくるだろうと思うので、続報を楽しみに待っておこうと思います。

vCISO サービスをやっている Cynomi がシードラウンドの資金調達をアナウンスしています:

Virtual CISO startup Cynomi raises $3.5M to help SMBs automate cybersecurity

Cynomi, an Israeli cybersecurity startup that has built a virtual CISO platform for SMBs and service providers, has raised $3.5 million in seed funding led by Flint Capital. Typically, virtual CISO - or vCISO - services take the form of an outsourced or on-demand security practitioner that works as...

vCISO 方面の事業には、もともと人材紹介/仲介的なモデルの事業が多いのではと思いますが、そこを ”AI” でどうにかするぜ的なソリューションらしいです。

ここでいう ”AI” というのが何を指すのかは置いておくとして（この事業のターゲット層を考えるとこういう語を敢えて選ぶほうが伝わりそうですし…）、実際とくにコーポレートガバナンスの文脈で「セキュリティは何から始めればいいか分からない」的な課題は尽きないところなので、実質どういうセグメントから・どういうタッチポイントで参入するかが楽しみですね。

（個人的にはこのへんハイタッチな入り口が多いけど、対象を中小に絞るなら、テックタッチな参入アングルもありそうだと思っていて、そういうのが出てくると面白いんじゃないかな〜と思っています。もっともオープンな採用情報があればタッチポイント設計とかは察しが付きそうなもんですが、なかったので、今どうしようとしてるのかは全く分からない）

SOC 方面向けのプラットフォームをやっている Hunters がSeries C の調達をアナウンスしています:

Hunters raises $68M Series C for its security operations platform

Cybersecurity startup Hunters today announced that it has raised a $68 million Series C round led by Stripes. New investors DTCP, Cisco Investments and Databricks also invested in this round, together with existing investors YL Ventures, Bessemer Venture Partners, Microsoft's venture fund M12, U.S....

僕はこの手の領域に疎いので、このリリースを受けて LP をざっと読んで見ましたが、うーん、この辺のソリューションがどう差別化をしているのか本当に分からない＞＜

領域的には ACV が高い/顧客ライフタイムは長めの製品なのだろうとは思いますし、はじめの顧客を握るところができれば Moat は作りやすいのではと思いますが、立ち上がりの戦略をどうしていたのかは気になります

“Systems Security Engineering” という概念をフォーマルに論じるための基礎的な概念類の定義・導入や、実際の取り組みを進める際の考慮事項などを整理する、”Trustworthy Secure Systems” (NIST SP 800-160 Volume 1) の Revision 1 が出ていました:

Engineering Trustworthy Secure Systems: Draft NIST SP 800-160 Volume 1 Revision 1 Available for Comment

NIST is releasing the draft of a major revision to Special Publication (SP) 800-160 Volume 1, Engineering Trustworthy Secure Systems . This publication is intended to serve as a reference and educational resource for engineers and engineering specialties, architects, designers, and personnel involved in the development of trustworthy secure systems and system components.

余談ですが、この手の文章に限らず、フレームワークチックな文書をセキュリティが専業でない方が（なんならセキュリティが専業な人でも）読むのがキツいですよね。上記のページでは ”Emphasizing that the responsibility for engineering trustworthy secure systems is not limited to security specialties” と言っているけれど、実際のところこれを非 security specialities の人に読んでくれ〜というのは多分厳しい。そんなことを思いながら「こういうパブセク系のアウトプットはちゃんと自分の中に腹落ちさせつつも、プロダクト開発の現場の 1 つ 1 つの課題を現場と同じ目線で考えられる人間でありたいな、バランスの取れる人間でありたいな」と思うのでした。

OMB から出ていたもの。ななめ読みしかできてないので細かい言及は控えますが、去年のパブコメの段階との差分を注視しておきたいところ:

Office of Management and Budget Releases Federal Strategy to Move the U.S. Government Towards a Zero Trust Architecture | The White House

Today, the Office of Management and Budget (OMB) released a Federal strategy to move the U.S. Government toward a "zero trust" approach to cybersecurity. The strategy represents a key step forward in delivering on President Biden's Executive Order on Improving the Nation's Cybersecurity, which focuses on advancing security measures that dramatically reduce the risk of successful cyber attacks against the Federal Government's digital infrastructure.

ここ最近は Software Supply Chain Security 方面において、堰が切れるかのように各プレイヤーのアウトプットが続いているように感じます。そんなこの瞬間は、筆者（米内）には「Identity Management や Ops に関する各種テクノロジの成熟が、Software Supply Chain をソフトウェア的な管理の対象として扱うことを可能にしてきたという技術的事実」と、「実際の Software Supply Chain に関連するインシデントの増加により、この領域に関連する脅威への対策が投資すべき対象になってきたというと社会的背景」が交差した結果訪れたターニングポイントであるように感じられており（こう抽象的に書くとフェイク野郎感がすごいですが）、だからこそ少しの間強めにこの領域に自分の身を投じてみるつもりです。

先週はお疲れさまでした。今週もはりきっていきましょう！