ぶるーたるごぶりん

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

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 の広告審査方法はもう少し頑張っていただいて、よりよりプラットフォームになってほしい
続きを読む

Google の OSV と CPE の課題解決について

OSV と CPE

炭治郎です。コロナ２日目です。

自分は知らなかったのですが、 Google が2021年2月に OSV (Open Source Vulnerabilities) と言う脆弱性DBを公開していました。

https://opensource.googleblog.com/2021/02/launching-osv-better-vulnerability.html

この OSV に触れた国内記事はそれほど多くなく、 記事の内容自体も OSS-Fuzz について触れているケースが多そうでした。

ただ、自分的にはその点よりも以下の CPE の課題を解決してくれる点というのが非常に良さそうだと思いました。

This comes from the fact that versioning schemes in existing vulnerability standards (such as Common Platform Enumeration (CPE)) do not map well with the actual open source versioning schemes, which are typically versions/tags and commit hashes.

意訳すると、 CPE などが package manager 上の package 名などと対応していない問題があり、 それを OSV によって解決するという感じです。

この点について、既存のCPEを元にしたパッケージの特定の限界と、 OSV が良さそうという話をしてみようと思います。

続きを読む