Written by
on 

Issue 1

🗞️ Articles

GitHub Code Scanning にサードパーティのセキュリティツールが追加

Announcing third-party code scanning tools: infrastructure as code and container scanning - The GitHub Blog

GitHub code scanning に SARIF をサポートする IaC / コンテナ向けのセキュリティツールを追加。

追加されるツールは次の通り。

API Testing Tool

Container Security Tool

Azure App Service における LFI と RCE

Kud I Enter Your Server? New Vulnerabilities in Microsoft Azure

Azure App Service で見つかった 2 つの脆弱性の解説。Azure App Services は Web アプリケーションをホストする PaaS 。

ユーザーが App Service を作成すると、Azure は Manager node と Application node の 2 つのコンテナを作成し、これは次のようなドメインになる。

この admin ページでは KuduLite https://github.com/Azure-App-Service/KuduLite が使われており、Docker のログや環境の情報などを提供するアプリケーションになっている。また、Manager node と Application node にそれぞれ SSH できる Web インターフェイスがある。

１つ目の脆弱性はこの Manager node の root 権限の取得が可能だったというもの。Manager node には権限の低いユーザでしかログインができず、 /home 以外のファイルには書き込みができない。しかし、https://github.com/Azure-App-Service/webssh/blob/27b5b0fb07e3e4263c5abb40dcbfac72849c8c64/index.js#L52 をみると root のクレデンシャルがハードコードされており、これを使って root として SSH ログイン可能であった。

これにより admin ページへのリクエストを盗聴したり、フィッシングページを設置することが可能。

2 つめの脆弱性は Application node のアプリケーションから SSRF で Kudu’s API へアクセスすることで任意ファイルの読み込みや任意コード実行が可能だったというもの。Kudu’s API には VFS API があり、任意のファイルを読み込むことができる。そのため、アプリケーションに SSRF などの任意エンドポイントへ HTTP リクエストを送信できる脆弱性がある場合に、 Kudu’s API に対してリクエストを発行することで任意ファイルの読み取りが可能。また、同様にコマンド実行も API 経由で可能。

Apple で見つかった脆弱性についてのレポート

We Hacked Apple for 3 Months: Here’s What We Found

11 個の Critical severity、29 個の Higjh severity、13 個の Medium severity, 2 個の Low severity で合計 55 個の脆弱性を見つけたというレポート。うち 12 個について解説が書かれている。Bounty の総額は \$51,500 らしい。

ソースコードから脆弱性を見つけるための Word について

How to Find Vulnerabilities in Code: Bad Words - WILL BUTLER

ソースコードから脆弱性を見つける際に意識するべき “Word” についての説明。

例えば raw , exec , system などはコマンドを実行するような関数などで利用されることは広く知られているが、他にも権限周りを示す privilege や permission の他、特定言語やライブラリで注意すべき Word について触れている。

DOMPurify のバイパス

Mutation XSS via namespace confusion - DOMPurify < 2.0.17 bypass - research.securitum.com

著名な HTML Sanitizer ライブラリの一つである DOMPurify < 2.0.17 の Bypass について。

Bypass できた PoC は下記の通り。

<form>
<math><mtext>
</form><form>
<mglyph>
<style></math><img src onerror=alert(1)>

DOMPurity.sanitize(html) すると html は DOMPurify によってパースされて HTML マークアップを生成する。その後ブラウザによってその HTML は再度パースされる。

このとき、DOMPurify でパースされた DOM Tree とブラウザによってパースされた DOM Tree は同じになるように見えるが、そうはならないケースがある。

例えば form の場合、ネストした子を持つことはできないと spec にある。

<form id="form1">
  this is form1
  <form id="form2">
    this is form2

<!-- 上記 HTML は次のように DOM Tree が生成される -->
<form id="form1">
  this is form1 this is form2

この仕様を利用して Bypass する。HTML パーサーは「HTML namespace」「SVG namespace」「MathML namespace」の 3 つの namespace を用いて DOM Tree を作成する。

通常、ほとんどの要素は HTML namespace に属するが、 <svg> や <math> タグが出現すると、それぞれの namespace に切り替わる。

例えば <style><a>ABC</style><svg><style><a>ABC という文字列があった場合は次のような DOM Tree になる(タグの先頭に namespace をつけている)。

<html style>
	ABC
<svg svg>
  <svg style>
    <svg a>
      ABC

style は子を持つことができないが、 svg の style は子を持つことができる。

ここで <svg> や <math> に含まれる要素はすべて HTML namespace には属さないように思えるが、 HTML integration point や MathML text integration points 呼ばれるものがあり、その子の要素を HTML namespace に属すことができる。

<math>
  <style></style>
  <mtext>
    <style></style>

<!-- これは次のような DOM Tree になる -->
<math math>
  <math style>
  <math mtext>
    <html style>

上記のように mtext は MathML text integration points であるので、その子は HTML namespace に属している。

しかし、ここでも例外があり、Math text integration points の子であっても HTML namespace に属さないものがある。それが <mglyph> と <malignmark> である。

<math>
  <mtext>
    <mglyph></mglyph>
    <a><mglyph>

<!-- これは次のような DOM Tree になる -->

<math math>
  <math mtext>
     <math mglyph>
     <html a>
       <html mglyph>

mtext の子である mglyph は MathML namespace にあり、さらに、HTML 要素の子である mglyph は HTML namespace にあることが分かる。

この知識をもとに DOM Purify の Bypass Payload を見直してみる。

<form><math><mtext></form><form><mglyph><style></math><img src onerror=alert(1)>

これは次のような DOM Tree になる。

<html form>
  <math math>
    <math mtext>
      <html form>
        <html mglyph>
          <html style>
            "</math><img src onerror=alert(1)>"

</math><img src onerror=alert(1)> は <style> の中の単なるテキストであるので、このままだと攻撃は成功せず無害である。

DOMPurify によってサニタイズされた HTML は次のようになる。

<form> 👈 第1のform
  <math>
    <mtext>
      <form> 👈 第2のform
        <mglyph>
          <style>
            </math>
            <img src onerror=alert(1)>
          </style>
        </mglyph>
      </form>
    </mtext>
  </math>
</form>

見ての通り、ネストされた <form> があるので、DOM Tree はブラウザによって再パースされるときに変更される。よって次のようになる。

<html form>
  <math math>
    <math mtext>
        <!-- ここにあった <html form> はネストしているので消える -->
        <math mglyph>
          <math style/>
  <html img src onerror=alert(1)>

2 番目の <form> は削除され、 <mglyph> は <mtext> の子になるため、MathML namespace になる。そのため、 <style> も MathML namespace に含まれているので、 </math><img src onerror=alert(1)> はテキストとして扱われない。よって </math> で <math> を閉じて XSS が生じる。

Hashicorp Vault の認証バイパスに関する脆弱性

Enter the Vault: Authentication Issues in HashiCorp Vault

Hashicorp Vault で aws / gcp auth メソッドを使っている場合に認証バイパス可能な脆弱性(CVE-2020-16250 / CVE-2020-16251) の解説。

CVE-2020-16250 : aws auth メソッドを使っている場合の認証バイパス

IAM Auth を使う場合、クライアントはログイン時に次のようなリクエストを送信する。

curl -X POST "http://127.0.0.1:8200/v1/auth/aws/login" \
			-d '{"role":"dev", "iam_http_request_method": "POST", "iam_request_url": "aHR0cHM6Ly9zdHMuYW1hem9uYXdzLmNvbS8=", "iam_request_body": "QWN0aW9uPUdldENhbGxlcklkZW50aXR5JlZlcnNpb249MjAxMS0wNi0xNQ==", "iam_request_headers": "eyJDb250ZW50LUxlbmd0aCI6IFsiNDMiXSwgIlVzZXItQWdlbnQiOiBbImF3cy1zZGstZ28vMS40LjEyIChnbzEuNy4xOyBsaW51eDsgYW1kNjQpIl0sICJYLVZhdWx0LUFXU0lBTS1TZXJ2ZXItSWQiOiBbInZhdWx0LmV4YW1wbGUuY29tIl0sICJYLUFtei1EYXRlIjogWyIyMDE2MDkzMFQwNDMxMjFaIl0sICJDb250ZW50LVR5cGUiOiBbImFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDsgY2hhcnNldD11dGYtOCJdLCAiQXV0aG9yaXphdGlvbiI6IFsiQVdTNC1ITUFDLVNIQTI1NiBDcmVkZW50aWFsPWZvby8yMDE2MDkzMC91cy1lYXN0LTEvc3RzL2F3czRfcmVxdWVzdCwgU2lnbmVkSGVhZGVycz1jb250ZW50LWxlbmd0aDtjb250ZW50LXR5cGU7aG9zdDt4LWFtei1kYXRlO3gtdmF1bHQtc2VydmVyLCBTaWduYXR1cmU9YTY5ZmQ3NTBhMzQ0NWM0ZTU1M2UxYjNlNzlkM2RhOTBlZWY1NDA0N2YxZWI0ZWZlOGZmYmM5YzQyOGMyNjU1YiJdfQ==" }'

これを受け取った Vault Server は AWS Security Token Service (STS) API の GetCallerIdentity を呼び出してリクエストを発行する。

このとき、リクエストの結果をパースする parseGetCallerIdentityResponse() では XML をデコードしようと試みている。STS のレスポンスはデフォルトで XML エンコードされているが、 Accept: application/json もサポートしているため、JSON エンコードでレスポンスを受け取ることも可能。

iam_request_headers パラメータに application/json を指定することで Vault は JSON で STS のレスポンスを受け取ることが可能になる。XML のデコードは前後に非 XML 文字列がある場合は無視するので、 { "foo": "bar<GetCallerIdentityResponse></GetCallerIdentityResponse>" } のようなレスポンスを返せることができれば、空の CallerIdentityResponse が生成されて認証バイパスができる。

ここで STS レスポンスにそのような任意の文字列(ここで必要とされるのは < や " などの文字列)を埋め込めるアクションが必要になるのだが、これは AssumeRoleWithWebIdentity アクションの SubjectFromWebIdentityToken に埋め込める。 AssumeRoleWithWebIdentity は、OpenID Connect（OIDC）プロバイダーによって署名された JWT を AWS IAMID に変換するために使用される。

そのため、自身で OIDC IdP を用意し IAM とのマッピングをおこうことで、サブジェクトクレームの一部として任意の GetCallerIdentityResponse を含む JWT を作ることができる。

{
 'iss': 'https://oidc-test-wrbvvljkzwtfpiikylvpckxgafdkxfba.s3.amazonaws.com/',
 'azp': 'abcdef', 'aud': 'abcdef',
 'sub': '<GetCallerIdentityResponse><GetCallerIdentityResult><Arn>arn:aws:iam::superprivileged-aws-account</Arn><UserId>XYZ</UserId></GetCallerIdentityResult></GetCallerIdentityResponse>',
 'exp': 1595120834, 'iat': 1594207895
}

その後、 https://sts.amazonaws.com/?DurationSeconds=900&Action=AssumeRoleWithWebIdentity&Version=2011-06-15&RoleSessionName=web-identity-federation&RoleArn=$ROLE_ARN&WebIdentityToken=$JWT_TOKEN を iam_request_url として送ることで認証バイパス可能。

CVE-2020-16251 : gcp auth メソッドを使っている場合の認証バイパス

IAM ではなく bound_service_accounts を指定しない gce での認証方式でバイパス可能。認証リクエストで使われる JWT トークンに含まれる compute_engine の値が、トークンを作成したサービスアカウントのものであるかを検証しないのが原因。攻撃者が任意のサービスアカウントを使って偽の compute_engine 構造体を含んだ JWT を作成することで GCE インスタンスに偽装することが可能。

AWS Access Key のフォーマットについて

AWS Access Key ID formats

AWS_ACCESS_KEY_ID として利用される AWS Access Key のフォーマットの考察。Access Key からアカウント ID を逆引き( aws sts get-access-key-info 相当) することが可能ということがわかった。

*google.com 上の CSRF について

The mass CSRFing of .google.com/ products.

URL 末尾に ;evil.pdf を追加すると Content-Type が何であれｂ，強制的に application/pdf としてロードできる。

Adobe Reader は %PDF-1 という文字列を探して、PDF ファイルの要件構造を満たしている場合に有効な PDF ファイルとして読み取る。つまり、PDF コンテンツと % < > " を挿入できれば、その URL の末尾に ;.pdf を追加することで PDF コンテンツを読み込ませることが可能らしい。Adobe Reader なのでおそらく IE 限定な気がする。

Cloudflare の API Shield について

Introducing API Shield

Cloudflare の API Shield https://developers.cloudflare.com/firewall/cf-firewall-rules/api-shield/ では mTLS や Schema Valdiation などの機能で API を保護できる。Schema Validation は OpenAPI Schema をもとにリクエストがそれに沿ったものかを検証するものになっている。JSON API だけでなく gRPC にも対応予定。

OAuth2.0 のセキュリティベストプラクティスに関する文書

OAuth 2.0 Security Best Current Practice

EKS Pod Identity Webhook の仕組み

EKS Pod Identity Webhook Deep-Dive

ZeroTrust の原則や作り方についての文書

Zero Trust Deployment Center

The state of Container Security in Red Hat Experience

The State of Container Security in Red Hat Experience

DevSecOps Days Tokyo 2020 の発表資料。コンテナセキュリティの運用やあり方について。

🧰 Tools

mxrch / GHunt

mxrch/GHunt

メールアドレスを入力するだけでその Google Account の情報を取得する OSINT ツール。

Portshift/kubei

Portshift/kubei

Kubernetes クラスタで動いている Pod のイメージの脆弱性を検出するツール。

Offensive Terraform

Offensive Terraform

EC2 上に reverse shell するインスタンスを作ったりなど、Offensive なツールなどをセットアップする Terraform module 郡。

filedescripter/Unicode-Mapping-on-Domain-names

filedescriptor/Unicode-Mapping-on-Domain-names

ドメインで使える Unicode 文字列。URL フィルタのバイパスなどで利用できる。

💣 CVE

CVE-2020-25613 : WEBrick における HTTP Reuqest Smuggling

CVE-2020-25613: Potential HTTP Request Smuggling Vulnerability in WEBrick

CVE-2020-15237 : Shrine における derivation_endpoint でのタイミング攻撃

Build software better, together

Shrine < 3.2.2 ではアップロードファイルを動的に処理する derivation_endpoint プラグインを利用している場合に、derivation URL のシグネチャをタイミング攻撃によって推測することが可能。

CVE-2020-8264 : Action Pack における XSS

Sign in - Google Accounts

Action Pack >= 6.0.0 において、Development Mode のときに XSS が生じる。修正コミットは https://github.com/rails/rails/commit/ddcca86f0ed5064140924c88cc5ad556d5ce32d4#diff-b110cedc61988d892438b5135a78437c 。

ActionableExceptions で action を実行するさいに、リダイレクト時にスキームの確認がされていないため javascript: スキームで XSS が生じるものと思われる。

💰 BugBounty

🚚 Intent to Ship