ぶるーたるごぶりん

UI, UX, セキュリティとか😘

CodeBlue 2023 の登壇資料等が公開されました

公開されたのに宣伝忘れてました。

英語タイトル：
"filename" in Content-Disposition is a landmine vulnerability caused by ambiguous requirements

日本語タイトル：
Content-Disposition の "filename" という地雷 -曖昧な要件が原因となる脆弱性-

スライド： https://codeblue.jp/2023/result/pdf/cb23%EF%BD%B0filename-in-content-disposition-is-a-landmine-vulnerability-caused-by-ambiguous-requirements-by-motoyasu-saburi.pdf[

動画： www.youtube.com

ちなみに最終的な脆弱性発見数は以下になりました。

  • 1 Browser
  • 2 Programming Lang
  • 6 Web Framework
  • 5 HTTP Client
  • 2 Mailer Library

今年はフィッシングか脅威インテリジェンス的な研究ができたらいいなって思ってます。

SQL Injection を探せ！ 文字列テンプレートリテラル と Raw Query によるやらかし探し

はじめに

失敗記事です（SQLI 一個も見つかりませんでした）。

前回の記事では GitHub に漏れ出たコードを GitHub Code Search を使って検索しました。

brutalgoblin.hatenablog.jp

今回は少し特殊な SQL Injection を前回同様に GitHub Code Search の力を借りて探そうと思います。
特殊な SQLI とは、一般的な文字列結合ではなく、 文字列テンプレートリテラルを使った結合による SQLI です（後述）

失敗記事ではあるのですが、観点的には結構面白いと思うので、軽くまとめてみます。

また、今回は ORM に限定して探しましたが、限定しなければ結構見つかるのかもなーと思ってます。

続きを読む

GitHub に漏れ出た内部コードを探す ~ 上場企業 3900社編 ~

全１回、このシリーズは今回で最後です！

TL;DR

  • 上場企業 3900 社程に対して、すごく大雑把な「内部コード等の漏洩調査」を GitHub 上で行った
  • 結果としては、重要度の高いものから低いものまで 10社ほどで漏洩が確認された
  • 重要度の高いものとして、社外秘っぽそうなスプレッドシート、社員のハッシュ化パスワード(BCrypt)、 AWS Credential 等
  • 「大雑把な」調査を行ったが、より精度の高い方法等について記事内にて触れていく
  • 脅威インテルとか DLP みたいなエリアとかも、外部企業とかに頼るだけじゃなく「自分たちでも」頑張ってみるのがいいんだと思います
  • GitHub Code Search ... すげえぜ！
  • Google Dorks ならぬ、 GitHub Dorks + GitHub Code Search でまだまだいろいろできるはず。

はじめに

チャオ！

今回は「内部資料を誤って公開している人 / 会社って結構いるよね」という前提をベースに 「GitHub 上に内部コード（またはその他の機微情報等）を上げてる社員 / 会社がいるんじゃないか？」という観点で、漏洩してしまっている会社を探してみようと思います。

調査の切っ掛けとしては以下です。

  1. GitHub API を使って、大量のリポジトリから「脆弱性をもつコード」を探すという研究記事があった

  2. GitHub の新しい Code Search 機能を活かしたかった

  3. 脅威インテリジェンスの記事などでは、コンピューターを中心としたリスクがメインになりがちだけど「人間的なリスクの評価も大切だよね」って思い続けていた
    • 脅威インテリジェンスなどの記事では「会社としてリスクを適切に認識しようね」と言った言及は普通にされている
    • ただ MITRE ATT&CK みたいなのを活用する話が 99% になっており、「内部の脅威をしっかり分析しよう」みたいなのは１ページで終わるみたいなやつ
    • 内部の脅威なんてのは記事にしにくいから当たり前ではあるのだが...
    • MITRE ATT&CK : https://attack.mitre.org/
    • ちょっと別視点（人間的なリスク）で一回考えてみようかな？と思って今回の調査手法を閃いた
  4. このあと登場する調査手法を記事にしているところは多分ないのでやってみようと思った

内容自体はひどく簡単で、 Google Dorks みたいなものを GitHub でやってみるというものです。
このあたりの GitHub Dorks のパターンも、 Bug Bounty とかで成熟してきています。 ただ、新しい GitHub Code Search を活用した GitHub Dorks は、まだまだ発展途上だと思うので、今回チャレンジしてみます。

Google Dorks って？

「Google の検索エンジンのパワーを使って、漏洩情報等を検索しよう」みたいな手法です。

例えば、 filetype:pdf 社外秘 等で調べることで、 PDF でファイル内に"社外秘"が入っているファイルを検索できるみたいな感じです。 Google Dorks に関しては、調べればいっぱい出てくると思います。
気になる方は各自で調べてみてください。

続きを読む

(失敗した)CT LogのSANが大量に結びついた証明書を見つけてフィッシングサイトを検知する方法

年末にツイッターに書いたけど、特に記事にしていなかったので供養として一応記事に書いてみます。

失敗した内容ではあるんですが、おそらくこの観点で調査してる人が国内にいないだろうし、 （多少関連する内容について記載するので） ほんの少しは需要があると思って記載しておきます。

一応以下のやつを考慮に入れて検知を考えたけど失敗したって話です。

  • censys で SAN の数を元にした検索（検索がそもそもできない）
  • crt.sh で、 SAN の数を元にした検索 (検索がそもそもできない)
  • crt.sh が公開している PostgreSQL にアクセスして SAN の数を元に検索する方法（試してすらいない。大変。）
  • Certstream を使って SAN の数を元にフィルタする方法（最終的に実施して、このアプローチ自体が失敗したやつ）
続きを読む

Content-Disposition の filename という地雷。　(1個の観点で17個の脆弱性を見つけた話)

English ver:
https://gist.github.com/motoyasu-saburi/1b19ef18e96776fe90ba1b9f910fa714#file-lack_escape_content-disposition_filename-md

TL;DR

  • 1つのブラウザ、1つのプログラミング言語、15個の { Web Framework, HTTP Client ライブラリ, Email ライブラリ / Web Service 等} で脆弱性を見つけました。
  • 見つけた脆弱性は、全て 1つの観点で発見した (多分 50-80 くらいのプロダクトの調査をした)。
  • RFC の記載では、（かなりわかりにくく）この問題に対する要件が記載されており、WHATWG > HTML Spec の方はしっかりと書かれているといった状況にある。
  • この問題は、 Content-Disposition の filename, filename* というフィールドを明確なターゲットとしている。
  • この問題は、 HTTP Request / Response / Email の箇所で影響がそれぞれ変わる。
    • HTTP Request : リクエスト改竄（特にファイルコンテンツの改竄、他のフィールドの汚染等）
    • HTTP Response : Reflect File Download の脆弱性
    • Email : 添付ファイルの改竄（拡張子やファイル名の改竄と、潜在的なファイルコンテンツの改竄等）
  • これらの攻撃ベクトルの明確な攻撃対象として、 Content-Disposition (の filename, filename*) を見ている人は現在はあまりいない。
  • OWASP の刊行物でこのあたりをちゃんとまとめているのはパッと見ない。 ASVS ではこれに関する Issue が立てられている。
  • Content-Disposition の filename, filename* はちゃんとエスケープしましょう。
    • filename:
      • " --> \" or %22
      • \r --> \\r or %0D
      • \n --> \\n or %0A
    • filename*:
      • ちゃんとフォーマットを守って URL Encode する

はじめに

どうも、涼宮カルビの牛角です。

この記事では、2018-2022 のリサーチ結果で発見した 脆弱性に関して書いていきます。 リサーチ期間が非常に長くなっていますが、単純にやる気のアップダウン等が入り混じって調査していない期間が長くなっただけです。実際の調査期間は 3ヶ月-半年程度です。

リサーチの結果、以下のプロダクト(?)で脆弱性を発見しました。

  • 1個の ブラウザ
  • 1個の プログラミング言語
  • 15個の {Web Framework / Library / Web Service } （あえてぼかすために混ぜてます）

見つけた問題は大きく以下の3つに分かれます。

  1. HTTP Request における multipart/form-data > Content-Disposition 上の filename のエスケープ不足による、ペイロード生成時のコンテンツ改竄の脆弱性
  2. HTTP Response における Content-Disposition ヘッダ上の filename, filename* のエスケープ不足による、Reflect File Download の脆弱性
  3. Email の multipart > Content-Disposition における filename のエスケープ不足によるコンテンツ改竄の脆弱性
続きを読む

Meta(Facebook) の偽ECサイト (Phishing) 広告の自動検出

Phishing Security

はじめに

こん〜！

今回は、いつかやろうと思っていた Meta(Facebook) 広告上でばら撒かれまくっている悪性広告を自動検出する試みについて、 うまくいったこと・いかなかったこと・考察等をまとめていこうと思います。

先にまとめ

  • Facebook の GraphQL API だと、検索できる広告タイプが限られており、 Graph API を用いた自動化は（現在は）できない
  • 広告ライブラリAPI という Web Page 機能 からの API サーチだと広告の検索が可能であり、悪性広告を検索可能
  • 広告ライブラリAPI からの検索は、（多分）全文検索だと思われるので、特定のキーワード・ドメインをキーワードとした検索が可能
  • 作成したカスタムクエリの一つは、検索結果の２０件が全て悪性広告であった
  • 広告の先が悪性なECサイトであるかを判定する方法として、robots.txt を参照する方法を考案して実施した
  • Meta の広告審査方法はもう少し頑張っていただいて、よりよりプラットフォームになってほしい
続きを読む