サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
brutalgoblin.hatenablog.jp
はじめに 失敗記事です(SQLI 一個も見つかりませんでした)。 前回の記事では GitHub に漏れ出たコードを GitHub Code Search を使って検索しました。 brutalgoblin.hatenablog.jp 今回は少し特殊な SQL Injection を前回同様に GitHub Code Search の力を借りて探そうと思います。 特殊な SQLI とは、一般的な文字列結合ではなく、 文字列テンプレートリテラルを使った結合による SQLI です(後述) 失敗記事ではあるのですが、観点的には結構面白いと思うので、軽くまとめてみます。 また、今回は ORM に限定して探しましたが、限定しなければ結構見つかるのかもなーと思ってます。 見つけようとしたもの ご存知の通り、SQL Injection の一番良くあるミスは、 文字列結合した SQL を発行し、そのまま In
全1回、このシリーズは今回で最後です! TL;DR 上場企業 3900 社程に対して、すごく大雑把な「内部コード等の漏洩調査」を GitHub 上で行った 結果としては、重要度の高いものから低いものまで 10社ほどで漏洩が確認された 重要度の高いものとして、社外秘っぽそうなスプレッドシート、社員のハッシュ化パスワード(BCrypt)、 AWS Credential 等 「大雑把な」調査を行ったが、より精度の高い方法等について記事内にて触れていく 脅威インテルとか DLP みたいなエリアとかも、外部企業とかに頼るだけじゃなく「自分たちでも」頑張ってみるのがいいんだと思います GitHub Code Search ... すげえぜ! Google Dorks ならぬ、 GitHub Dorks + GitHub Code Search でまだまだいろいろできるはず。 はじめに チャオ! 今回は
年末にツイッターに書いたけど、特に記事にしていなかったので供養として一応記事に書いてみます。 CT Log の SAN が異常に多い CT Log は9割 Malicious なんじゃないか?と思って今 CT Log Streaming しながらフィルタかけてみてるけど普通のやつがかかりまくってきて推測が外れた。— もつに (@akroasis5150) 2022年12月23日 失敗した内容ではあるんですが、おそらくこの観点で調査してる人が国内にいないだろうし、 (多少関連する内容について記載するので) ほんの少しは需要があると思って記載しておきます。 一応以下のやつを考慮に入れて検知を考えたけど失敗したって話です。 censys で SAN の数を元にした検索(検索がそもそもできない) crt.sh で、 SAN の数を元にした検索 (検索がそもそもできない) crt.sh が公開してい
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-Dispo
はじめに こん〜! 今回は、いつかやろうと思っていた Meta(Facebook) 広告上でばら撒かれまくっている悪性広告を自動検出する試みについて、 うまくいったこと・いかなかったこと・考察等をまとめていこうと思います。 先にまとめ Facebook の GraphQL API だと、検索できる広告タイプが限られており、 Graph API を用いた自動化は(現在は)できない 広告ライブラリAPI という Web Page 機能 からの API サーチだと広告の検索が可能であり、悪性広告を検索可能 広告ライブラリAPI からの検索は、(多分)全文検索だと思われるので、特定のキーワード・ドメインをキーワードとした検索が可能 作成したカスタムクエリの一つは、検索結果の20件が全て悪性広告であった 広告の先が悪性なECサイトであるかを判定する方法として、robots.txt を参照する方法を考
GitHub の Reverse Proxy 型フィッシングサイトの発見と報告 こんにちは、でじこだにょ 今回は GitHub を狙った Reverse Proxy 型のフィッシングサイトを探していこうと思います。 (長いので、Reverse Proxy 型のことをプロキシ型と略しちゃいます) 結論から書くと、24件のフィッシングサイトを新規に発見して報告しました。 今回はそれらのフィッシングサイトの探し方のほか、フィッシングサイトの検出方法や、 セーフブラウジングなどの話をしつつ、 今回見つけたフィッシングドメインに対して、簡単ではありますが、調査と考察を行ってみたいと思います。 探そうとしたきっかけ 数日前、 Twitter を見ていたところ、こちらのツイートが流れてきました。 あっぶね GitHubだと思ったら全然違ったわ pic.twitter.com/SRtHUu3XDM— ./
はじめに 画像は記事に全く関係ないカニのフィギュアです👋 近年、善良なパッケージを騙ったマルウェアが配布されているケースが増えてきています。 これらのマルウェアはパッケージマネージャ上で配布され、開発者端末やそれをビルトインしたシステムを利用するユーザー端末で悪事を働きます。 これは俗にいうサプライチェーン型攻撃で、 これらの関連ニュースを目にする機会が増えてきていることを、多くの開発者が体感されていると思います。 ただ、これらのサプライチェーン型攻撃の記事は、 どうしてもエンドユーザー(パッケージを利用する開発者側・それらを組み込んだアプリを実行するユーザー側)の対策に焦点が当てられたものが殆どのように感じています。 そこで本記事では、このエンドユーザー側の対策だけではなく、 パッケージマネージャメンテナーたちがどう対策しているのかも含めて、 「パッケージマネージャ上で行われるマルウェ
ライブラリに擬態したマルウェアを見てく 今作ってるツールでどうしても複数の事例を知っておく必要があるので、 半分自分用に乱雑にまとめていく。 この記事では、主にPypi (Pythonのパッケージマネージャ)にて配布されていた 「ライブラリに似せた名前」のマルウェアのコードを見ていく。 とはいえ、かなりシンプルなものばかりだったので、 記事の内容的には微妙かも。 はじめに 近年、タイトルにある通りライブラリに擬態したマルウェアというのがそれなりに配布されていたりする。 これらは大抵の場合、 Typo Squatting と呼ばれる攻撃手法をベースにしてライブラリとして公開・配布されている。 これらのマルウェアは、インストール・使用した端末に対して、なにかしらの悪性なコードを実行させることを狙っている。 そもそも Typo Squatting とは、(大抵は)フィッシングサイトなどで悪用され
はじめに 前回に引き続き、 XSStrike という XSSスキャナーを読んでいきます。 github.com 前回は Fuzzing するところだったので、XSS スキャナーっぽくなくて個人的には面白くなかったです・・・。 なので、今回は「XSS可能かを評価するための DOM解析部分」を読んでいきます。 前回記事: brutalgoblin.hatenablog.jp 今回読んでいく部分(DOMの解析部分)は以下のファイルです。 XSStrike/dom.py at 0ecedc1bba149931e3b32e53422d5b7c089ba9dc · s0md3v/XSStrike · GitHub 前回も記載しましたが、 main 処理からの処理派生は以下の様になっています。 Main 大きく以下の4つの分岐 --> singleFuzz() --> bruteforcer() -->
はじめに めちゃくちゃイケてて最高なXSStrike の中身を読もうという記事です。 github.com 最近カメ並のスピードで最強のXSSスキャナーを目指して開発をしているのですが、 さすがに既存のXSSスキャナーが何をやってるのか把握していないのはまずいだろうということで、 今回は3、4回に分けてXSStrikeのロジックを読んでまとめていこうと思います。 ZAPは過去に読んだのですが、XSStrikeは未読なのでワクワクです。 ちなみに昨年ZAPのXSSルールを読んだ時は、こちらの記事の内容とほぼほぼ一緒でしたのでお勧めです。 OWASP ZAPのXSS(Cross-site scripting)診断は何をしているのか? – Web Application Security Memo 最強のXSSスキャナーを作るのであれば、 Burp, ZAP, Arachni, Nikto など
退職ポエムです。 退職エントリは退職日が来たら投稿します。 各年度でうまくいったこと、うまくいかなかったこと、 これをやれば良かったかなーと思っていることを書きます。 なんで辞めるのかとかは別の投稿にて。 やってたこと 1-2年目 : 採用管理サービスの開発 (Scala) 2-4年目 : 横断セキュリティチーム(脆弱性診断・ログ監視基盤の開発運用) 4-4年半 : 脆弱性DBの開発・運用 (Kotlin/Java) うまくやれたこと、やれなかったこと 1 - 2年目 1-2年目 : 採用管理サービスの開発 (Scala) 正直今の自分から見て何もかもがうまくいってなかったし、努力も人並み以下、スペシャリティや軸というものもないという状態だったのが反省点。 ただ結果的に次年度から持ち直したので、まあ良かったでしょう。 環境がすこぶる良かったのでそれに救われました。 良くなかった点 軸が無か
GitHubが狙う「ライブラリのバージョン管理問題」の解決と依存関係地獄の話 Githubが OSS Security Foundation に入りましたね。 大変興味深くて 関連するドキュメント なりについて会社のチームで雑談していたところ、 GitHubの「DependaBot」が何を狙い、どういう「大きな課題」を解決するのか? という話において、点と点が結びついた感じがあるので言語化してみます。 「この大きな課題」を説明する前に Dependency Hell について国内で言及してる記事がそれほどないので その辺りをまずは書いていきます。 ここのあたりが国内の開発者の中でも認識が広まっていくと、より一歩先のステージにいくのかなと思うので、 比較的ラフな感じで書いていきます。 ちなみに、このブログ記事は所属組織とかに関係なく個人で執筆しています。 なので1デベロッパーとして、
※ 2020/5/22 一部加筆 SASTとIterativeな開発の相性の悪さ 若干煽り気味なタイトルですが、チーム内で話していてなぜセキュリティ静的コード解析(Static Application Security Testing: SAST)と言ったセキュリティアプローチがDevOpsで回りにくいのかが言語化できた。 そもそも静的コード解析というアプローチによるセキュリティ担保は基本的に「教科書的なウォーターフォール型」において有効で、 理由としては「人月・工数」のみで考えられた「誰でもその作業ができ、セキュリティの知識がなくても良い」みたいな作業者の能力を考慮しないアプローチが基本だからである。 そう言ったアプローチだと「SASTのアラート全部直してくれな!そしたらセキュアだから!」という形に落とし込むことにより、 問題をある程度封じ込めれると。 ただ、これをDevOps、というよ
はじめに 本記事では、前回の記事(https://brutalgoblin.hatenablog.jp/entry/2020/02/15/153805)にてあまり触れられなかったWebアプリケーションにおけるDevSecOpsの所感や考え方、動向を個人的思想でまとめた記事になります。 本記事は個人の感想が多分に含まれているため、どこかしらで(何かしらに)寄った意見や 知識不足から来る誤った解釈などが含まれているかもしれません。 もし本記事で誤った箇所や違ったポリシー、事業のフェーズによって違う考え方を持たれている方がいらっしゃいましたら、是非コメントやリプライなどで意見をください。 というか、私自身が迷っている部分も多くあるため、そういった知見を頂けるのであればこの記事を書いた甲斐があるというものなので、是非是非フィードバックを・・・! 本記事は章組をした段階であまりにもデカくになってしま
発表しました。(すっかり書くのを忘れていました。) Webフレームワークの脆弱性パッチを読み、何が起きたのかをまとめたというやつです。 speakerdeck.com
はじめに SAML関連で診断をすることになったが、やんわりとした知識しかないため、 SAMLの攻撃事例を読んでそれをざっくりまとめる。 認証フローなどはネットに軽い奴がまとまっているのでそれらを参考に読むと良いのかも? ※2018/11/22 事例を1つ追加 ( XMLのコメントアウトを利用した認証バイパス の章) 思いつく攻撃 XMLをアップロードするのでそこでXML外部エンティティ参照とかがあるのかも? あとはアプリケーション自体がXMLファイルからidP(Identity provider、所謂認証サーバ?)へ認証リクエストを送るから そこを利用してSSRFなどのイントラネットへのリクエストが送れるかも? 上記2つはどちらかというと認証に対する攻撃とは別なので、認証部分の攻撃については 後述する事例で見ていく。 事例とざっくりまとめ SAML + HackerOne とかでググって引
セキュリティエンジニアになり、そこから2年間分の勉強内容と参考になった資料とか 自分の振り返りも兼ねて2年分の勉強内容とかをざっくりまとめようと思います。 新卒からバックエンド開発を2年程行い、その後セキュリティエンジニアとして横断セキュリティ部門に異動しました。 そこから更に2年が経ち、来月からセキュリティサービスの開発とかをすることになったので、 もし同じような人が居た際になんとなし参考になればいいかなという意図で書いてます。 ちなみにセキュリティ部門に異動するまでのセキュリティの知識レベルは「徳丸本を2回通しで読んでる」程度です。 セキュリティ部門に移ってからは脆弱性診断・ログ監視・開発ガイドライン周り・脆弱性管理とかをやってました。 本記事では自分自身がユーザ系の企業に属しているので、ベンダーとかそちら寄りの内容ではないです。 あとできる限り社内の事情を記載しません。何が問題になる
このページを最初にブックマークしてみませんか?
『brutalgoblin.hatenablog.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く